Your AI coding bill is mostly reading: where agent tokens go, and how to stop paying frontier prices for them

Put an AI coding agent on a real task and watch what it does. Before it writes a line, it opens files, searches for symbols, reads the callers, and pulls the surrounding code into its context. Every token of that context is billed at the rate of whatever model is driving the session. When that model is a frontier model, you are paying reasoning prices for what is mostly reading.

Four jobs, one price

• Reading large files to find the handful of lines that matter.
• Scanning the repository: search, grep, and “where is this used?” loops that re-read the same code turn after turn.
• Writing boilerplate: tests, types, config, and other predictable code.
• Making decisions: architecture, debugging, and novel problems.

Only the last job needs a frontier model. The first three are high-volume, low-judgment, and easy to verify, and they can run on models that cost a small fraction as much per token.

What Spotify found

In September 2026, Spotify Engineering described routing Claude Code's routine work to cheaper worker models: a bulk reader for opening many files and a code writer for predictable snippets, while Claude handled only novel reasoning. In their tests on a Java monorepo they reported Claude Code token usage falling by about 90%. One detail stands out: files over a set size were blocked from the expensive model entirely, because hard blocks at the routing layer worked where prompt-level guidance did not.

Telling an agent to use a cheaper model is a suggestion. Routing is a rule.

Why prompts aren't enough

It's tempting to fix this with instructions: “use a smaller model for reads.” Agents drop instructions under pressure, and a single missed read of a large file can erase the savings from dozens of good ones. Durable savings come from enforcing the route outside the agent, where it can't be skipped.

How much will you save?

It depends on your mix. Teams working in large, old codebases spend more on reading and save more. Teams doing mostly greenfield design spend more on reasoning and save less. Spotify's figure is a data point, not a promise, so the first step is always to measure your own sessions.