Roundup
Ruby and Rails have a personality, and it trips up AI models in a specific way. Ruby prizes expressiveness and convention — "convention over configuration" is the whole Rails philosophy — so the difference between working code and idiomatic code is larger here than in most languages. A model can produce Ruby that runs but reads like translated Python: explicit where Ruby would be implicit, verbose where a block would do, ignoring the Rails conventions that make a codebase feel like Rails. There's no Ruby benchmark to rank this directly, so we go by general ability plus how well each model handles Ruby's idioms, and then tell you to test on your own app. The live board is at /benchmarks.
The general board, read for Ruby
These are cross-language scores — SWE-bench Verified is heavily Python, so it's a proxy for "good in a real repo," not a Ruby ranking. Rails work is repo-surgery across models, controllers, views, and migrations, which SWE-bench approximates well. But idiom quality — does it write Ruby that reads like Ruby — is invisible in every column, so weight the table lightly and lean on your own testing.
| Model | SWE | LCB | TB |
|---|---|---|---|
| 95.0 | 89.8 | 83.1 | |
| 88.6 | 87.8 | 78.9 | |
| 85.2 | 82.4 | – | |
| 80.6 | 85.3 | 83.4 | |
| 79.3 | 87.6 | 76.2 | |
| 77.6 | 87.5 | – |
A dash means the lab hasn't published that suite. There's less Ruby than Python or JavaScript in most training data, so idiom quality varies more between models here than the tight score spread suggests — another reason to test yourself.
The pick for Ruby and Rails: Claude Opus 4.8
For Rails work, Opus 4.8 is our default. In our hands it has the best feel for Ruby idioms on the board — reaching for blocks and enumerable methods instead of C-style loops, respecting the fat-model-skinny-controller instinct, using ActiveRecord the way Rails intends rather than dropping to raw SQL. Its 88.6 SWE-bench score means it also handles the cross-file reality of a Rails app: change a model and it knows the migration, the controller, and the view that come with it. Fable 5 (95.0) is the step up for a hard job — a gnarly service-object refactor, a data migration, untangling a fat model that grew for a decade. Rails convention rewards a model that has genuinely absorbed the framework, and the Claude family is strongest at that here.
The budget pick: DeepSeek V4 Pro
A lot of Rails work is routine: a scaffolded resource, a standard migration, a validation, a background job. That volume doesn't need a frontier model. DeepSeek V4 Pro at $0.435 / $0.87 per million tokens is a strong everyday pick — capable enough for the mechanical majority of Rails plumbing at roughly a tenth of frontier cost. Run it two-tier: Opus (or Fable for the hard bits) on the tricky work, DeepSeek grinding the routine. Sonnet 5 (85.2) is the other value option and tends to write cleaner Ruby idioms than the cheapest models, which matters more in Ruby than in most languages. The full budget tier is in the cheapest coding models roundup.
What benchmarks miss about Ruby
The biggest gap is idiom. Ruby's culture cares deeply about how code reads, and a benchmark that scores "did the test pass" is blind to whether the solution is idiomatic or an ugly transliteration that happens to work. A model can score well and still write un-Rails-y code you'll want to rewrite. The second gap is the meta-programming and DSL-heavy corners of Rails — the framework's magic (implicit rendering, callbacks, method_missing tricks in gems) is exactly where models are most likely to guess wrong, because the behavior isn't in the code you can see. So the human job in Ruby leans toward idiom review: is this the Rails way, would a senior Rails dev write it like this, does it fight the framework anywhere. That review is where a benchmark can't help you.
Test it on your own app
Because idiom is the whole game and no benchmark scores it, your own bake-off is essential. Take real tasks from your Rails app — add a resource that touches models and controllers, write a service object, do a non-trivial migration — and give the identical prompt to two or three models. Judge them on: is the Ruby idiomatic or transliterated, did it follow Rails conventions and your app's existing patterns, and how much did you have to rewrite to make it feel like the rest of the codebase. Run the test suite on the output too — Rails apps usually have good coverage, and that's your fastest correctness signal. The model that produces the most Rails-y code with the fewest rewrites wins, regardless of its SWE-bench line.
What we'd run for Ruby
One model: Opus 4.8 for its idiom feel, Fable 5 for the hard refactor. Two-tier for volume: Opus driving, DeepSeek V4 Pro or Sonnet 5 grinding routine Rails plumbing. Whatever you run, review for idiom and convention, not just correctness — that's the Ruby-specific tax. Bring your own keys to pay the lab's real per-token rate: bring your own keys. The board moves monthly at /benchmarks, and the best coding model roundup plus best AI for backend are the natural next reads.