Is Rails token efficient code? Counting what an agent has to read

Most ai context rails advice is about what to put in the context. The harder question is what a codebase forces an agent to read before it can answer anything, and that number is measurable. The @rails account's positioning line makes the claim directly: "Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write, and still beautiful for humans to review."

Worth taking seriously, and worth counting rather than agreeing with. What follows is a rails token count of a real Rails 8.1.3.1 application, the SaaS boilerplate this site sells, measured file by file.

Counting a real application instead of arguing about it

Every number below came from tiktoken's o200k_base encoding, run over the working tree. That encoding is OpenAI's rather than Anthropic's or Google's, and the absolute counts would shift by a few percent on another tokenizer. The ratios between file types, which is what the rest of this page turns on, do not.

Tree	Files	Characters	Tokens
app/views/**/*.erb	131	409,024	124,934
spec/**/*.rb	170	303,554	76,611
app/models/**/*.rb	47	114,892	28,559
config/** (rb and yml)	32	107,543	25,329
Gemfile.lock	1	39,183	19,492
app/controllers/**/*.rb	51	66,831	15,636
app/services/**/*.rb	40	52,692	12,246
db/schema.rb	1	14,536	3,972

app/, config/ and spec/ together are 292,397 tokens. A frontier coding model now ships a million token window, so the old framing, that a Rails app does not fit, is dead. A rails context window is no longer one budget for the repository. It is one budget per turn, and a twenty turn session that re-reads the same trees pays for them twenty times.

The ordering is the interesting part. Markup outweighs the models, controllers and services combined by better than two to one. The specs on their own cost more than all three. Whatever Rails is doing well or badly, it is doing it to the smallest rows in that table.

Characters lie and lines lie worse

Chars per token is not a constant, and treating it as one is how people end up surprised by a bill.

File or tree	Characters per token
config/locales/en.yml	4.42
app/services/**/*.rb	4.30
app/controllers/**/*.rb	4.27
app/models/**/*.rb	4.02
spec/**/*.rb	3.96
db/schema.rb	3.66
views containing <svg	2.93
Gemfile.lock	2.01

A byte of Gemfile.lock costs 2.2 times what a byte of en.yml costs. The reason is that version strings, hashes and hyphenated gem names shatter into single character tokens, while English prose and Ruby identifiers do not. So Gemfile.lock is 7.5 times the size of Gemfile on disk and 14 times its token cost, and any agent that globs the repository root to "check the dependencies" has spent 19,492 tokens answering a question the 1,397 token Gemfile answers better.

The practical consequence is that file size is not a proxy for context cost, and lines of code are worse than file size. db/schema.rb is 345 lines. app/views/admin/_icon.html.erb is 50. The 50 line file costs more.

The icon partial that outweighs the schema

app/views/admin/_icon.html.erb is 8,988 bytes and costs 5,638 tokens. db/schema.rb is 14,536 bytes and costs 3,972. A file 62 percent of the size costs 42 percent more.

All of that partial is Heroicons path data behind a case statement. One path element:

<path stroke-linecap="round" stroke-linejoin="round" d="M3.75 6A2.25 2.25 0 0 1 6 3.75h2.25A2.25 2.25 0 0 1 10.5 6v2.25a2.25 2.25 0 0 1-2.25 2.25H6a2.25 2.25 0 0 1-2.25-2.25V6Z" />

121 tokens. For comparison, has_many :messages, dependent: :destroy is 10 tokens and class User < ApplicationRecord is 5. One icon costs what twelve associations cost.

Across the view tree, 18 of 131 files contain an <svg, and those 18 hold 35,956 of the 124,934 view tokens. Fourteen percent of the files, 29 percent of the cost. Strip them out and the remaining 113 views run at 3.41 characters per token instead of 2.93.

Nothing about this is a Rails problem, which is the point. A team that moves icon paths into a sprite, a helper backed by a hash, or anything else an agent can skip has cut 29 percent off its most expensive tree without touching a line of application logic. The same is true of a Tailwind utility string: <div class="flex items-center justify-between gap-3 rounded-lg border border-gray-200 px-4 py-3"> is 25 tokens of styling wrapped around content the agent came for.

Where the token efficient code claim holds

Terseness is not the mechanism, and people who defend Ruby on line count are defending the wrong thing. has_many :messages, dependent: :destroy is cheap in a context window for a reason that has nothing to do with its length: the agent already knows what it does. Every consequence of that line, the reader method, the collection proxy, the callback that deletes children, the foreign key convention, was in the training data thousands of times. Zero tokens of the repository are spent explaining it.

An in-house DSL of the same shape gets none of that. broadcasts_to :account, via: :fanout is 11 tokens, one more than the has_many, and an agent has to open its implementation to learn anything at all, which is frequently a file larger than the model that called it. Same terseness, opposite cost.

So the honest version of the claim is not that Rails is terse. Rails is token efficient code because its vocabulary is pretrained and its file layout is predictable enough that an agent can find app/models/user.rb without a directory listing. Why conventions are the context is the same argument from the framework's side.

What would overturn this: a measurement showing that agents open framework source in a Rails codebase at a similar rate to a bespoke one. If an agent reads activerecord to understand has_many, the pretraining premise is wrong and the cost is just hidden a level down.

Where the claim stops holding

The pretraining premise has an expiry date, and the enum syntax is the cleanest example in Rails. Defining an enum with keyword arguments was deprecated across Rails 7 and is gone in 8. The signature in ActiveRecord 8.1.3.1 is:

def enum(name, values = nil, **options)
  values, options = options, {} unless values
  _enum(name, values, **options)
end

name is positional and required. Run the old form against it and you get ArgumentError: wrong number of arguments (given 0, expected 1..2), which is exactly what a model that learned Rails from a decade of pre-7.0 code will write. The current form, enum :role, { member: 0, admin: 1 }, default: :member, costs 20 tokens. The wrong form costs 20 tokens and a failing boot. A convention is only free when the weights hold the current one, and freshly changed conventions are the most expensive text in the repository because they cost tokens twice, once to write wrong and once to correct.

The second failure has nothing to do with the framework. app/models/setup.rb in this application is 222 lines and 2,623 tokens, and it holds a table of SMTP providers, a field definition, a step definition and the wizard object that walks them. An agent asked to change the SMTP list reads all four, because from outside the file there is no way to tell which 40 lines matter. Rails does not prevent that file, and the phrase "convention over configuration" does nothing about it. A fat model with three hundred lines of callbacks is not token efficient code in any framework, and the boilerplate in a repository is not what makes it expensive.

The part of the claim DHH is not betting on

Reported out of the Rails World 2026 keynote in Austin, which nobody here watched, HEY 2.0 is being rebuilt as native apps on every platform over a Rust backend, written by agents under the direction of programmers and designers. DHH's line on the language, as it was quoted afterwards, was that Rust is amazing "if you never, ever, EVER have to look at it yourself."

Read that next to the @rails sentence and the two halves come apart. "Easy for agents to write" and "beautiful for humans to review" are not the same requirement, and the Rust backend is what the first half looks like when you drop the second. Rails is the bet that you still want to read it. The page you are on is only worth writing under that bet, because if nobody reviews the code then the cheapest representation wins and it is not Ruby. What DHH actually said covers the keynote itself.

Five changes that measurably shrink the read

All five were measured on the application above, and all five state what they cost.

1. Annotate models with their columns. annotaterb writes a schema comment block into the model file. Average cost across the 21 tables here is 170 tokens per table. The question it answers, "what columns does this have", otherwise pulls in the 3,972 token db/schema.rb alongside the 1,201 token model. The cost is staleness: the annotation is regenerated by a rake task after db:migrate, and a branch that skips it ships a comment that lies, which is worse than no comment.
2. Keep icon and illustration data out of ERB. Worth 35,956 tokens here. The cost is one layer of indirection between a designer and an icon.
3. Put user-facing copy in config/locales/en.yml. A copy question then reads one 11,682 token file instead of grepping 131 views, and <%= t("admin.users.index.title") %> is 11 tokens in the view. The cost is that an agent changing a screen now reads two files instead of one, so this trades many shallow reads for two deep ones and only wins if copy questions outnumber layout questions.
4. Write the orientation file and keep it short. The AGENTS.md here is 66 lines and 1,086 tokens, and it names where forms, services and copy live so the agent does not glob app/. AGENTS.md for a Rails app goes through what belongs in it. The cost is a second source of truth that no test checks.
5. Never let Gemfile.lock into context. 19,492 tokens that answer a resolver's question rather than yours. There is no cost to this one.

The rule underneath all five: cheapness comes from what the agent can skip, not from what it reads quickly.

What this page does not cover

Prompt caching, which genuinely changes the arithmetic. A prefix that does not change between turns is billed at roughly a tenth of a fresh read across the major providers, so the twenty turns paying twenty times above is a ceiling rather than a bill. The files an agent is actively editing are the ones that do change, and those are the ones that miss the cache.

Retrieval. Embedding a repository and fetching the relevant chunks is a real answer to the same problem, with its own failure mode, and it is a different page.

Test suites, which are the second largest number in the first table and were left alone here. 76,611 tokens of specs are a cost an agent pays and also the main thing that makes its output checkable, and treating that number as waste gets the trade backwards. Testing what an agent wrote takes up that side of it.

Whether any of this changes what a model produces. Everything measured here is input cost and nothing more. The claim that a smaller context yields better code is plausible, widely repeated, and not something this application has run an experiment on.