Most of your coding-agent tokens are not spent on your problem. They're spent on overhead, stale history, and files the agent re-reads because nobody told it not to. Once I understood that, cutting my bill by around 90% turned out to be mostly hygiene, not sacrifice.
This one's practical. No axe to grind, just what worked.
See where the tokens go first
You can't cut what you can't see. When I actually logged the traffic, the split was ugly: a large chunk of every request was scaffolding, not task. That matches what others found in 2026, when a widely-shared analysis showed one popular agent harness sending roughly 33,000 tokens of overhead before reading the prompt, against about 7,000 for a leaner alternative. Spotify's engineering team reported a tooling change that cut their coding-agent token usage by about 90%, which is the number that made me go looking in the first place.
If your harness lets you inspect requests, do it before you optimise anything. The waste is usually not where you think.
Scope the context, then clear it
The biggest lever is the dumbest one. Start a fresh session per unrelated task. Every turn you keep, you re-send the whole growing transcript, and you pay for it again. A twenty-turn session isn't twenty small requests, it's twenty increasingly large ones.
Then scope what you load. Point the agent at the three files the change touches, not the repo. Models get worse with long noisy context, so a tight window is cheaper and usually smarter. Long context is a cost multiplier disguised as thoroughness.
Route work to the cheapest model that can do it
Not every step needs your most expensive model. Renaming a symbol, writing a test stub, reformatting a block: that's mechanical, and a cheap fast model does it fine. Save the frontier model for the reasoning-heavy parts. If your tooling supports subagents, push the mechanical steps down to a cheaper tier and keep the expensive one for architecture.
Routing through a gateway helps here too, because you can set a hard price ceiling and fall back to a cheaper host when the expensive one isn't earning its rate.
Use caching on purpose
Prompt caching is real money if you use it deliberately. Keep the stable part of your context (the system setup, the files that aren't changing) in a cacheable prefix so it bills at the cache-read rate instead of fresh input on every turn. Just know the cache can expire faster than you expect, so a long idle gap between messages can quietly cost you a full re-read.
Pick a lean harness
The last one is a choice you make once. Harness overhead is a fixed tax on every single request, so a tool that sends 7k of scaffolding instead of 33k saves you on turn one and every turn after. I stopped treating the default as the only option and started weighing the harness by what it sends on my behalf, not just how it feels to use.
Stack these and the 90% isn't dramatic, it's just what happens when you stop paying to re-send context the model didn't need. The task was always the cheap part.
Top comments (0)