The reading bill

$2.82. $3.14. $4.28. Those are the median list prices for Opus 5.5 to build the same Pokémon app in Nuxt, Next.js and SvelteKit, from Nolan Lawson's benchmark of twelve JavaScript frameworks, each run up to five times. Lawson built it to test the claim that some frameworks are "better for agents," a claim he says gets made without evidence. "Did anyone think to ask the agents?"

The SvelteKit number is the odd one. On the measures that reach a user, SvelteKit's apps were among the best in the test: 36 KiB of JavaScript to Next.js's 142, zero milliseconds of blocking time to 71, a largest contentful paint of 1,130 ms to 2,090. A better product with a higher bill. Lawson's diagnosis fits in one sentence:

That isn't a SvelteKit problem. It's what software costs when an agent writes it: whatever the model doesn't already know, it pays to read, in tokens, in every session, until a model trained after the change ships. Lawson's other expensive outlier shows the same thing from a different side. With Gracile the issue was obscurity rather than recency. The agents "didn't know the framework very well" and either cloned its repo or read its compiled source out of node_modules. Two different reasons for being absent from the weights. Same bill.

The obvious fix is to hand the agent the docs, and the Svelte team did. Its Claude Code plugin was called in all five SvelteKit runs, and the agents read the migration guide in all five anyway. Nuxt's MCP server was never touched once, and Nuxt was the third-cheapest build in the test, at 3.9 million tokens to SvelteKit's 8.5 million. Tooling can point an agent at the right page. It can't make the page free to read.

Two different reasons for being absent from the weights. Same bill.

That flips an old incentive. A breaking release used to cost a framework's users one migration, done once, by people. Now it also hands a reading assignment to every agent session that touches the codebase, until the weights catch up. That makes the newest version the most expensive one to build on, and the cost signal points away from the framework that shipped users a quarter of Next.js's JavaScript.

The fair objection is that this is a timing artifact, and a small one. The next model will have read SvelteKit 3, and $1.46 a build over Nuxt is lunch money next to an engineer's hour. Both true. It isn't noise, though: SvelteKit's cheapest of five runs, $3.59, cost more than the median Next.js build. And the tax doesn't expire. It moves. There is always a newest release, and it is always the one the model hasn't read, so the bill lands on whoever changed most recently, every cycle. Lawson ends by telling teams that have gone hands-free to rethink "what you type after npm install" on evidence like this. On this evidence, the cheapest choice is the framework that hasn't changed lately.

Lawson quotes Rich Harris, Svelte's creator: "Frameworks are not tools for organizing your code; they are tools for organizing your mind." The mind doing the building now stopped reading on a fixed date. Anything a framework changes after that date gets reread, and billed, in every session.