I spent most of October rebuilding a side project, and somewhere in the middle of it I noticed my Claude Code bill creeping up faster than it had on the last one. Same amount of work, roughly the same hours, noticeably more tokens burned. The only real difference was the stack. The old project was a boring server-rendered thing with a sprinkle of vanilla JS. The new one was React with the usual pile of dependencies.
That got me paying attention to something I’d never really thought about before: the framework you pick doesn’t just shape your bundle size and your runtime. It shapes how much your AI assistant costs to run, and how good its output is. Framework choice has quietly become an AI cost decision, and almost nobody budgets for it that way.
Why the framework shows up in your token bill
Here’s the mechanical part. An AI coding assistant doesn’t reason about your code in the abstract. It reads files, holds them in a context window, and generates tokens. Every file it pulls in to answer a question costs you input tokens. Every line it writes costs you output tokens. The more code it has to look at to do one small thing, the more you pay.
React, in a typical setup, spreads a single feature across a lot of surface area. A component here, a custom hook there, a context provider two folders up, a reducer, a types file, maybe a test. When I ask the assistant to change how a form submits, it goes and reads all of that before it feels confident enough to edit. That’s the right instinct. It’s also five or six files worth of tokens for what should be a ten-line change.
I noticed it on the same feature built two ways: a filterable list with a bit of state. In the React version the logic was split across a component, a hook, and a context file, so asking Claude Code to add a sort option meant it read all three before touching anything. The Svelte version kept it in one file and the same request barely left that file. I didn’t run a formal benchmark, but the context it had to load was visibly a fraction of the React version, and the result was the same either way.
Multiply that across a few hundred edits in a working week and it stops being a rounding error.
Boilerplate is a tax you pay twice
Everyone already knows React has ceremony. What I hadn’t connected is that you now pay for that ceremony a second time, in generation tokens.
When the assistant writes a new React component it produces the import block, the type definitions, the hook wiring, the memo calls someone told it to add, and only then the actual logic. A big chunk of the output is scaffolding that exists purely because the framework demands it. Svelte and vanilla JS skip most of that, so a larger share of the tokens you’re paying for is the thing you asked for.
I’m not making a performance argument here, to be clear. I don’t care that React re-renders. I care that a simple instruction turns into a wall of generated boilerplate that I then have to read and approve. The review burden on me goes up right alongside the token count.
Where heavy frameworks actually pay off
It would be dishonest to pretend this all points one way. There’s a real upside to a popular, verbose framework when you’re working with AI, and it’s worth being fair about it.
Models have seen an enormous amount of React. The patterns are everywhere in the training data, so the assistant is genuinely more fluent in it. When I ask for something idiomatic in React, I get working code on the first try more often than I do in, say, Svelte 5 with runes, which is new enough that the model occasionally invents syntax that doesn’t exist. So you trade one cost for another. React costs you more tokens per edit but fewer failed attempts. A newer framework costs you fewer tokens per read but more retries when the model guesses wrong.
From what I’ve seen, the token overhead of React is the more consistent, predictable cost. The retry problem with newer frameworks is spikier and more annoying when it hits, but it’s getting better fast as the models absorb more recent code. Six months from now I’d expect that gap to mostly close.
What I’ve started doing about it
None of this made me rip React out of anything. That would be a silly overreaction to a few dollars of tokens. But it did change a few habits.
- I keep related logic in fewer, larger files than the React community generally recommends. One slightly chunky file the assistant can read in a single pass beats five tidy ones it has to chase across the tree.
- I’m more deliberate about what I tell the assistant to read. Pointing it at the two files that matter instead of letting it explore cuts the input cost hard, and the output is usually better for the focus.
- For genuinely simple projects, I now reach for server-rendered HTML with a little JS before I reach for a framework at all. The AI handles that stack beautifully and cheaply, and half my side projects never needed a SPA in the first place.
That last one surprised me the most. A lot of the complexity I’d been carrying was there to make AI-assisted development smoother, and it was doing the opposite.
The part nobody’s pricing in yet
Teams obsess over bundle size, Lighthouse scores, time to interactive. Those still matter. But if your engineers are running AI assistants all day, and most of them now are, the framework is also setting the floor on your AI spend and shaping how much code those tools can safely touch at once.
I haven’t seen a single architecture discussion where someone raised this. We’ll argue for an hour about whether to adopt a new state library and never mention that the decision changes the per-edit token cost for every developer on the team for the life of the project.
I don’t think the answer is to pick frameworks based on how AI-friendly they are. That’s letting the tool wag the dog. But it belongs on the list of tradeoffs now, somewhere below developer experience and above bundle size. Right now it’s not on the list at all, and that’s the gap worth closing. It’s not the deciding factor and it shouldn’t be. But it’s a real line item now, and pretending it’s zero is just going to show up on someone’s bill.