Ruby, Rails & AI Weekly Roundup: Rails 7.2 Reaches End of Life, the Agents on Rails Benchmark, and HTTP QUERY (Aug 9–15, 2026)

The week of August 9–15 shipped no Ruby or Rails security patch, which makes the deadline that did land the most urgent item on the list: Rails 7.2 fell out of security support on the 9th. Alongside it, the Rails Foundation published the first hard numbers on how coding agents perform against real Rails code, HTTP QUERY routing is up for review, and a long-running governance argument turned into an actual fork.

Rails 7.2 left security support on August 9

The Rails maintenance policy gives each minor series two years of security fixes from the first release in that series. For 7.2.x the clock ran out on August 9, 2026. There is no grace period: the next CVE disclosed against Action Pack or Active Record gets patched on the 8.0 and 8.1 lines, and 7.2 simply carries it.

The destination matters as much as the decision to move. Rails 8.0.x stopped receiving bug fixes on May 7, 2026, and its security support ends November 7, 2026 — under three months out. Landing on 8.0 buys you a quarter and a second upgrade project. Rails 8.1.x is covered for bug fixes until October 10, 2026 and for security until October 10, 2027, which makes it the only target that leaves room to breathe.

If a two-minor jump is a multi-sprint project, hop through 8.0 by all means — just book the 8.1 leg in the same plan, because 8.0 is itself three months from end of life.

Agents on Rails: the Foundation put numbers on agent-written Rails code

On August 12 the Rails Foundation announced Agents on Rails, a benchmark measuring how coding agents perform on real Rails applications, commissioned from Evil Martians. The first report followed a day later.

Stage 1 covers atomic tasks — small, self-contained problems that isolate one capability. Twenty-one of them run against Writebook v1.2.1, three runs each: 63 runs per model, 504 across eight frontier and open-weight models, scored on accuracy, median run time, mean tokens, mean cost, and Rails API recall.

On accuracy, Claude Opus 5 took the top spot at 92% (58 of 63 runs). Fable 5 scored around 95% but refused security-related tasks outright. GPT-5.6 Sol came in at 84%, and Luna at 73% on default reasoning settings. Cost is where the table gets uncomfortable: Luna finished all 63 runs for $0.91, while Opus cost roughly 132 times as much for 19 percentage points of accuracy. Median wall time ran from 3.3 minutes per task for Luna to 5 minutes for Sol and 16 minutes for Muse, which spent 82% of that thinking.

The finding worth carrying into your own tooling decisions is that framework knowledge, not raw capability, did the separating. Rails API recall ranged from 8% for DeepSeek V4 Flash to 35% for Fable 5, and runs that reached for the correct Rails API succeeded 92% of the time against 87% for hand-rolled equivalents. A model that does not know normalizes exists will write you a before_validation callback that mostly works.

The corpus is public at rails/ai-evals under MIT, with a canary GUID embedded in each task instruction to keep the benchmark out of training sets. The Ruby harness, lemans, is being open-sourced. The leaderboard is live and already carries more models than the original report. Stage 2 moves to multi-step work — feature additions and building apps from scratch.

HTTP QUERY is up for review, and Active Record picked up a batch of changes

This Week in Rails on August 14 led with a pull request adding HTTP QUERY support — still open at the time of writing, so treat it as direction rather than API. It adds a query routing helper, match via: :query, request.query?, request.request_method_symbol, a query helper in integration tests, and exempts QUERY from forgery protection the way GET and HEAD are. The use case is the search endpoint whose filter payload outgrew the URL and became a POST — safe and idempotent in reality, unsafe and non-cacheable as far as every proxy in the path was concerned. QUERY gives that request an honest verb.

Several other merges are worth knowing about before they surprise you in an upgrade:

• find_by_sql and count_by_sql now use bind parameters for array-form arguments, routing them through Arel::Nodes::BoundSqlLiteral instead of eagerly interpolating via sanitize_sql — consistent with where, better for statement caching, and a smaller injection surface on the raw-SQL escape hatch. In the same area, the adapter's create alias is deprecated in favour of insert.
• The MySQL sql_mode default changed from appending STRICT_ALL_TABLES to appending TRADITIONAL. This one matters most on RDS and Aurora MySQL, where an empty server-side default meant NO_ZERO_IN_DATE, NO_ZERO_DATE, and ERROR_FOR_DIVISION_BY_ZERO were silently absent. If you want the old behaviour, set variables: { sql_mode: "STRICT_ALL_TABLES" } explicitly in database.yml.
• Schema readers accept multiple tables — indexes, primary_keys, foreign_keys, check_constraints, exclusion_constraints, and unique_constraints all take a table list and return a hash. Fewer round trips in schema-introspection code.
• normalizes now runs before type validation, so a value like " Pending " is no longer rejected before the enum normalization gets a chance at it.
• Migration CommandRecorder commands are now 4-element tuples — [cmd, args, kwargs, block] instead of three with kwargs bundled into args. If you have custom reversible migration helpers, they will need updating.

Mosscap: a community LTS fork of Rails 8

On August 9, Lucas Dohmen published Rails is done, announcing a fork initially codenamed Amiko and now called Mosscap. The pitch is a community-maintained Rails 8.x LTS: minor improvements without breaking compatibility, particular attention to the asset pipeline, and stability chosen over innovation. His technical premise is that Rails' core — Zeitwerk excepted — has not changed materially since 6.0, and that most recent additions are optional components rather than framework evolution. His stated motivation is governance rather than code.

Whatever you make of the framing, the operationally interesting question is narrow: can a fork actually absorb and ship security patches on the Rails 8 line? That is the only thing that would make it a viable target for an app that cannot keep pace with the upgrade treadmill, and a launch announcement cannot demonstrate it. Ryan Bigg's counter — that Hanami already exists — is worth weighing.

GPT-5.6 makes the same argument the Rails benchmark does

OpenAI's builder's guide to GPT-5.6, published August 13, is worth reading next to the Rails report because it reaches the same conclusion from the vendor side. The family splits into Sol (flagship, with reasoning settings), Luna (cost-optimised for volume), and Terra. The Responses API additions are the substantive part for anyone wiring agents into a Rails app: reasoning persistence across turns, native compaction of long conversations, multi-agent orchestration, programmatic tool calling where the model writes JavaScript to orchestrate tools outside the context window, and prompt caching with a 30-minute minimum TTL and deterministic cache breakpoints.

The numbers OpenAI leads with make the cost argument directly — Luna hitting 98% of GPT-5.5's extraction accuracy at one-eighteenth the cost, and matching it on BrowseComp (84.04% against 84.36%) for $1.33 versus $33.27. Their framing is that work which "once required a frontier model at every step" can now be routed to smaller models with tuned reasoning effort. Two independent measurements pointing the same way is a stronger signal than either alone.

Claude output gets a text watermark

Anthropic described how Claude's text watermark works on August 14, shipping in future models under EU AI Act commitments. It biases the randomness used when the model picks between equivalent word choices, keyed so the pattern is verifiable with the key and invisible without it; images get C2PA credentials instead. The caveat matters more than the mechanism if you were eyeing this for a review pipeline: watermarking is sparse or absent in highly constrained text, and code is named explicitly as a case with little room to encode anything. A detection API is promised but not shipped. It will not tell you whether a pull request was agent-written.

Editorial pick: "Ruby and Rails Performance Roundup: The Backlog Edition"

Maciej Mensfeld's performance roundup, published August 12, walks 40 performance PRs across Ruby and Rails with benchmark numbers attached. The standout is a JSON::ResumableParser fix that had been fully re-decoding incomplete numbers on every chunk: a 128,000-digit number fed in 128-byte chunks went from 3.07s to 8.13ms. Also in there, per-Ractor garbage collection cuts the cost of scaling 1 to 16 Ractors from 10.17x single-Ractor wall time to 3.32x, and a params-hash mutation fix drops a 200-entry, 3-level hash from 5,825 allocations to 1,612. Twenty minutes well spent if you want to know where the runtime is actually getting faster.

Action items for the week

• If any production app is on Rails 7.2, schedule the upgrade now — it is receiving no security fixes as of August 9, and target 8.1 rather than 8.0.
• Check your Rails 8.0 apps too. Security support there ends November 7, 2026; put the 8.1 upgrade in a sprint before Q4 planning closes.
• Grep for custom reversible migration helpers that unpack CommandRecorder commands as 3-element arrays, and for adapter calls to create rather than insert.
• If you run MySQL, confirm nothing depends on the current STRICT_ALL_TABLES default before TRADITIONAL becomes the baseline.
• Pull the rails/ai-evals corpus and run your own model choice against it. Your codebase is not Writebook, but the API-recall metric transfers.
• Re-price your agent pipeline against the cost columns in both the Rails benchmark and the GPT-5.6 guide. Routing atomic tasks to a cheaper model is now a measurable saving rather than a guess.