Refactoring cut Claude Code's token cost for the same task by 83%
A Thoughtworks technologist built a roughly 150,000-line application, about 120,000 of it Rust with the rest in TypeScript and Terraform, almost entirely through coding agents (mostly Claude Code, with some Cursor), reviewing the generated code only occasionally out of curiosity. Left unchecked, the data access layer grew into a single Rust file of 17,155 lines with no de-duplication and almost no extracted functions or classes, though it kept a clean external interface.
That file became the subject of an experiment: since agents do not carry memory between sessions, the same representative task, a prompt to add a new ItemWatchStore trait with three async methods to the Firestore layer, could be handed to a fresh sub-agent after every single refactoring step, with the resulting change thrown away each time and only the token cost recorded. Because Claude does not expose reliable live token counts, the sub-agent reported characters sent and received, converted to tokens with tiktoken's rough chars-divided-by-four approximation.
Input tokens for the identical task stayed roughly flat through the early refactoring steps, then fell sharply once the largest file itself started shrinking, described in the piece as tokens "falling off a cliff." By the end, the file had been split into 19 Rust files and input tokens for the same change dropped from a baseline of 159,564 to 27,360, a reduction of 132,204 tokens, or 83%. At the Sonnet 5 pricing quoted in the piece, $3 per million input tokens, that is a saving of about 39.7 cents on this one change, but the saving recurs on every future change that touches the data access layer.
The total volume of code in the data access layer barely changed; it was reorganized, not shrunk. So the saving came from the agent needing to read far less of it: reviewing Claude Code's thinking and file-read summaries showed the sub-agent progressively narrowing in on the smallest relevant subset of files rather than scanning everything. The author argues that simply chopping the file into arbitrary smaller pieces would not have produced the same effect, since the agent would still have had to search through many files for the relevant code; the earlier refactoring steps, extracting duplication into a shared core, were what made that later precision possible. Output tokens, the cost of the code the agent actually wrote, barely moved across the whole experiment, so the saving showed up entirely on the input side, which the piece notes is priced at a fifth of the output rate.
The experiment also surfaced limits. Claude did not identify refactoring opportunities on its own: a standing refactoring step built into the author's agent workflow never flagged this file, and the plan had to be produced by explicitly invoking Martin Fowler's definition of refactoring and prompting the agent to examine the file against it, with a human choosing the sequence of steps. Claude Code proposed extract-function as a first step, while Claude.ai, used to draft the same plan, went further and identified an entire client class to extract. Mechanically applying the refactorings, done with Python scripts wrapping grep and sed, was also unreliable and often mishandled indentation, and the single most valuable refactoring step was missed on the first pass and had to be reapplied afterward.
The full experiment took about eight hours, mostly unattended, with one manual intervention after six hours forty minutes when an agent had silently skipped a step; a bloated Cargo build cache, not the hotel WiFi the author initially suspected, was later found to have been slowing test runs. The author never separately measured the tokens spent designing and running the refactoring itself, only estimating an upper bound of five million tokens across the whole effort, and stresses this is a single experiment on one greenfield, single-developer codebase, meant as a first data point rather than a general result.
Key facts
- A ~150,000-line application (about 120,000 lines of Rust, the rest TypeScript and Terraform) was built almost entirely by coding agents, mainly Claude Code with some Cursor, and its data access layer grew unchecked to a single 17,155-line Rust file.
- A controlled experiment ran the same representative task, adding an ItemWatchStore trait, through a fresh sub-agent after every refactoring step, discarding the change each time and recording only the token cost.
- Input tokens for the identical task fell from a baseline of 159,564 to 27,360 by the end of refactoring into 19 Rust files, a drop of 132,204 tokens, or 83%.
- The saving came from the agent reading a smaller, more precisely targeted subset of files, not from any reduction in the total amount of code in the layer, which stayed roughly constant.
- Claude did not identify refactoring targets on its own; a human had to direct the plan using Martin Fowler's definition of refactoring, and the mechanical grep/sed scripts used to apply it frequently mishandled indentation.
Why it matters
It puts a number on something agentic-coding teams have mostly argued about qualitatively: whether refactoring pays for itself when the code is written and read almost entirely by AI agents rather than humans. Here it did, dramatically, because the cost that refactoring reduces is not human reading time but the tokens an agent burns loading context for every subsequent change, and that cost recurs on every future task that touches the same code.
Who it affects
Anyone running or evaluating agentic engineering workflows where agents like Claude Code or Cursor write large volumes of code with little or no human review, and anyone maintaining a codebase that has grown the way this one did, with a single file absorbing feature after feature until it becomes a bottleneck. It is also relevant to teams estimating the ongoing token budget of AI-assisted development, since the effect compounds with every change made after the refactor.
How to use it
The recipe demonstrated is to benchmark a representative, realistic change before touching the code, then refactor in discrete steps and rerun the identical prompt on a fresh sub-agent after each one, so nothing is tainted by an agent remembering prior steps. The catch is that the refactoring plan itself was not something the agent produced unprompted; it took explicitly invoking Fowler's strict definition of refactoring and a human choosing which steps to apply and in what order, and the mechanical application via scripted grep and sed was unreliable enough to need a follow-up pass.
How solid is it
It is one experiment on one codebase, built by a single developer, still in a greenfield state, so the result is a data point rather than a general finding. Token counts rest on an approximation, characters divided by four, because the author found no reliable way to get live token counts directly from Claude; output-token variance across runs was described as noisy enough to obscure any effect from the refactoring, and the author never separately tracked how many tokens the refactoring process itself consumed, only estimating an upper bound of five million across the whole effort.
Risks and caveats
The 83% figure applies to one specific, moderately simple representative change; the piece explicitly leaves open whether the same saving shows up in debugging or more complex feature work, and whether refactoring the rest of the codebase would find similar gains or cost more than it returns. The process also required real skill and time to guide, Claude did not flag the file as needing refactoring on its own even with a standing refactoring step in the workflow, and the scripted mechanics of applying the changes introduced their own errors.
“Claude is unable to look at code, look at refactorings in general and work out which are suitable to apply: a human needs to actively guide it.”
— the author, in the article's notes on the process