An agent can use a lot of tokens for a change of a few lines. It looks for the right file, reads its dependencies, runs tests, examines their output, then starts again after a first fix. The code it produces tells only a small part of the work you pay for.
When usage climbs, switching to a cheaper model looks simple. But faced with a difficult diagnosis, a less capable model makes more attempts. And a context cut down too far deprives the agent of the information it needed to succeed.
We start from a principle: the most capable model goes to the steps that call for judgement, preparatory reading and repetitive work can go elsewhere, and the tooling makes that split hold. To apply it, you need to know what the agent consumes at each step and what that step contributes to the result.
What a session makes the model read
A token is a unit of text processed by the model, sometimes a word, sometimes a fragment. In a coding session, the model reads far more than the initial request: project instructions, files opened, earlier replies and tool results.
The agent alternates between calls to the model and actions. The result of a search or a test feeds the next decision: this loop, described in the Claude Code documentation, is what lets it correct its own work.
With each call, Claude Code sends the retained conversation again. A large test log therefore keeps weighing on the session long after the diagnosis that prompted reading it.
The simplest lever is to give the agent precise access to information. A file path and a function name make a better starting point than open-ended exploration.
Take a hypothetical case: a login test fails. We start with the error message and the test concerned, then widen to the code it calls. If that isn’t enough, the exploration continues. We avoid needless reads without stopping the agent from looking for the dependencies it needs.
The same logic applies to command output. A summary of the failures, with access to the full log, is often enough for a first diagnosis. Cutting off the last lines arbitrarily, on the other hand, risks hiding the error that matters.
Caching changes the price of rereading
Rereading doesn’t always cost the same. Prompt caching reuses the shared beginning of requests: the part already seen is reread at a reduced rate, provided the content hasn’t changed and the cache is still valid.
The Claude Code page on costs draws a concrete consequence from this. In a session left open all day, a one-line question draws usage for the whole conversation, at the cached rate. After a break longer than the cache lifetime, the first message reprocesses the full context at the standard rate.
Two sessions with the same input volume can therefore cost different amounts. To compare them, you need to separate new input, cache writes and reads, and the model’s output.
The right split follows the work to be done. Starting from scratch after every action means rebuilding context that’s still useful. Keeping a whole day of unrelated topics weighs down every exchange. Changing subject justifies an empty session: the /clear command costs nothing. Summarising the conversation with /compact keeps continuity, but that summary is itself a large request, since the model rereads everything it condenses. We keep what’s needed to finish the task, then pass a useful summary on to the next one.
Splitting work between models
The choice of model is made at the level of the subtask. Extracting a list of parameters from a documented file and diagnosing an intermittent defect don’t call for the same capabilities.
Dimitri Mazmanov, Product Manager for Portal at Spotify, describes their own use of Claude Code in a Spotify Engineering article. A cheaper model reads large files and returns a summary; Claude keeps the reasoning. A hook blocks full reads of any file longer than 350 lines, an adjustable threshold, and points to delegated reading. Reading an excerpt remains possible.
Across four scenarios in a Java repository, the article reports around 90% fewer tokens read by Claude for these delegated reads.
It also sets out the limits. The cost of the reading model still has to be added, and the quality of answers based on summaries isn’t measured. The smaller model missed a subtle concurrency bug, which Claude found once it had the right context. Each delegation adds 10 to 30 seconds. Before changing the code, Claude rereads the exact excerpt, because a summary doesn’t give reliable line numbers. Finally, the article comes from the person responsible for the product it presents.
We draw a working rule from this: delegate a bounded task first, one whose output is easy to check, and keep the most capable model where an omission could derail what follows. Summarising code already means choosing what to keep. So the line between reading and judgement needs testing on the team’s real tasks.
A subagent uses tokens too
A subagent explores in its own context and passes on only a summary: the main conversation stays lighter. But it makes its own calls, which count towards usage. Its model is configured separately, as the subagent documentation explains.
The saving is therefore calculated across the whole: what the subagent reads, the price of its model, its summary and the reads the main agent will have to redo. A summary that’s too vague often means redoing the exploration.
Before delegating, we specify the question and the shape of the answer. For example: find the places where a permission is checked, with the file paths and the cases not covered. The main agent then gets material it can check.
Parallelising meets a different expectation: reducing lead time. Several agents searching at once speed up the work and increase usage. We decide whether the time saved justifies that cost. The article on organising AI agents’ work details the conditions for useful parallelisation.
Making the tooling enforce the choices
An instruction written into the project’s guidance can be ignored. That’s why Mazmanov chose a hook: the rules in the CLAUDE.md file were “advisory, not enforced”, and Claude could ignore them. The hook, by contrast, runs on every read, whether or not the agent thinks of it.
A useful policy specifies which files to read directly, when to ask for a summary and which checks to keep. Writing “save tokens” gives the agent nothing to work with.
Hooks, scripts the tool runs before or after certain actions, apply these checks. Skills, written procedures the agent loads when it needs them, save it from exploring to rediscover a method. Anthropic shows, for example, a hook that only lets a test suite’s failures through, to limit what enters the context.
Every check must leave a way to get the work done. If a full read is refused, the agent must be able to get an excerpt or a summary. If it’s missing information, it must be able to go back to the source. A block that triggers repeated attempts cancels out the expected gain.
A size threshold remains a starting setting. Whether it fits depends on the repository, the tasks and the models used: it gets adjusted through use, like the rest of the tooling.
Comparing on finished work
To begin, we take a few representative tasks: a fix with a reproducible test, a change following an existing pattern, a search in an unfamiliar module. We keep the same starting point and the same success criteria to compare two ways of handling them.
The record can stay simple:
| What we observe | What it lets us check |
|---|---|
| Usage per model, cache shown separately | Where the budget goes and where it shifts |
| Number of attempts and amount of rework | Whether the initial saving holds through to the result |
| Checks passed, remaining defects | Whether the work keeps the expected quality |
| Time elapsed and human intervention | Whether the token saving imposes another cost |
We then change a single lever: targeted reads, log filtering or the subagent’s model. On important tasks, we repeat the trial so as not to mistake an isolated success for a reliable rule.
A counter has to be read with its scope. On our own sessions in June and July 2026, rtk, an open-source tool that filters command output before it reaches the agent, counted 62 million tokens saved over 16,405 commands, or 84%. But 59 million of those come from code searches alone, whereas a search is reduced by only 11% on average: the largest results make up most of the total. And the counter compares raw output with filtered output. It says neither what the agent would actually have read, nor whether the filter made it lose useful information.
The gain also reads differently depending on the contract. On a subscription, it translates into more work within the available quota, with no drop in the monthly fee. With usage-based billing, it shows up directly in spending. Session counters and the bill don’t always mean the same thing.
To get started, a team picks a single point: exploration that rereads too many files, logs that are too large, or a repetitive task given to the most expensive model. It keeps the setting if the gain shows up on finished tasks, with the expected checks, and drops it otherwise. The cost that matters is still that of an acceptable result, rework included, as we discussed in the article on AI agent autonomy.
Our training for engineering teams devotes a section to these settings, worked through from the situations the team encounters.