How to reduce tokens in coding agents - Claude, Codex, Cursor

Coding agents investigate repositories, modify files, run commands, and fix errors. That autonomy accelerates development, but it also grows the context: reads, tool outputs, and previous turns can all be forwarded to the model. To reduce tokens in coding agents, you need to decide what information each agent needs and for how long.

Bai et al. (2026) studied eight frontier models on SWE-bench Verified and found that agentic coding consumes orders of magnitude more tokens than reasoning or dialogue about code. The cost comes mostly from input, varies widely between runs, and does not automatically produce higher accuracy. The opportunity lies in designing a better context flow.

This article compares a monolithic agent with an architecture made up of Planner, Researcher, Implementer, Reviewer, and Tester. The hypothesis is that quality depends more on delivering the right context to each agent than on sharing the entire repository.

Why token consumption grows so fast

In a monolithic flow, the same agent researches, plans, implements, reviews, and tests. The task, conversation, files, searches, logs, changes, and tests accumulate even when part of them is no longer useful.

Bai et al. (2026) link cost to input growth and context reuse. The most expensive runs showed more repeated reads and edits, while accuracy plateaued at intermediate levels. Spending more may indicate unproductive exploration, not better reasoning.

It is worth distinguishing four sources of consumption:

· Initial context: instructions, architecture, conventions, and files.
· Accumulated context: previous responses and tool outputs.
· Exploration: searches, reads, and re-reads that do not end up influencing the change.
· Reasoning and output: planning, explanation, code, and reports.

This separation changes the question. Instead of asking how much context fits, the team asks what minimum evidence allows the next decision to be made without losing confidence.

To analyze performance, the following instruction was run with a monolithic agent based on GPT-5.6 Sol with xHigh reasoning level.

Result of the monolithic run with GPT-5.6 Sol and xHigh reasoning

Instruction used

Architecture for reducing tokens in coding agents

The alternative divides work by responsibility. Each stage receives a compact package and delivers an explicit result, without dragging along the full history of the other agents.

Planner and Researcher

The Planner interprets the task, identifies constraints, breaks down the work, and defines acceptance criteria. It can use the highest-capacity model, but its output should focus on the required research and acceptable evidence.

The Researcher answers targeted questions. It queries the project map, searches for specific symbols, and delivers a package with relevant files, contracts, constraints, commands, and risks.

Implementer

The Implementer receives the task, the plan, the context package, and the affected files. It produces the minimal change and returns ambiguities without restarting a broad exploration.

Reviewer and Tester

The Reviewer analyzes requirements, changes, and minimal context looking for regressions, risks, and unnecessary work. The Tester validates behavior and only expands coverage when a risk signal appears.

Graph-based engines materialize this pattern through sequences, routing, parallel tasks, cycles, concurrency, and isolated histories. This makes handoffs, retries, and human approval points visible (Klopfenstein & Maddula, 2026).

Diagram of the Planner, Researcher, Implementer, Reviewer, and Tester flow

Context, isolation, and compact handoffs

A context index that documents architecture, conventions, commands, constraints, and routes is also essential. It does not replace reading the code: it guides the search and prevents rediscovering the same structure.

A useful context package should include:

· Objective and the decision the next agent must make.
· Relevant files and symbols, with a sentence about their function.
· Contracts that cannot be broken and acceptance criteria.
· Risks, uncertainties, and still-open questions.
· Validation commands and expected output.

The package transfers decisions and evidence, not full logs or all the reasoning. A stable output contract reduces rework and makes it possible to measure which context was useful.

Real evidence on active compression

Active compression complements isolation between subagents. Verma (2026) compared a reference agent with Focus, which retains learnings and removes already-summarized explorations. Across five SWE-bench Lite cases with Claude Haiku 4.5, Focus reduced consumption by 22.7%, from 14,920,555 to 11,526,418 tokens, while maintaining the same success rate: 3 out of 5 tasks, or 60%.

Focus performed 6.0 compressions and discarded 70.2 messages per task. It saved between 18% and 57% in four cases. In matplotlib-26020, both agents passed the tests and consumption dropped from 4.0 to 1.7 million tokens (Verma, 2026).

The benefit was not universal. In pylint-7080, Focus consumed 110% more: 4.3 million versus 2.1 million tokens, because it removed information that it later had to explore again. The study uses five cases and one model; it does not prove that every multi-agent architecture is more efficient (Verma, 2026).

Context index excerpt.

Reproducible experiment: monolithic versus subagents

The variants must use the same repository, branch, task, environment, acceptance criteria, and tests. Since consumption varies between runs, each variant should be repeated and the distribution compared, not just the average.

Variants

1. Monolithic agent: investigates, plans, implements, reviews, tests, and fixes within the same history.
2. Orchestrated architecture: Planner, Researcher, Implementer, Reviewer, and Tester receive isolated context.
3. Optional variant: the orchestrated architecture consults the context index before performing targeted searches.

Metrics

Record per stage input, output, cache, and reasoning tokens; cost, time, reads, searches, commands, and tests. Also count files with no effect on changes and repeated operations.

The primary metric is tokens per correctly solved task. The rubric must be identical for all variants and include correctness, tests, regressions, maintainability, and unnecessary changes.

Interpretation criteria

An architecture does not win if it saves tokens but fails the criteria. Bai et al. (2026) show that cost is difficult to anticipate; Verma (2026) records savings of 18% to 57% and one case with 110% overhead. Therefore, repetitions, dispersion, configuration, tests, and limitations must be reported.

To continue the practical comparison, the same instruction was run with a multi-agent architecture. GPT-5.6 Sol with xHigh reasoning acted as orchestrator, and each subagent used GPT-5.6 Luna with xHigh reasoning, a lower-cost model.

Result of the same instruction with the multi-agent architecture and GPT-5.6 Luna xHigh

How to interpret the results and avoid over-architecture

Summary of the results obtained

In the local comparison, the monolithic agent processed 656,120 tokens and the multi-agent architecture processed 474,285. The difference was 181,835 tokens, equivalent to a 27.7% reduction. The most significant change occurred in non-cached input: it dropped from 244,390 to 71,847 tokens, 70.6% less. At the same time, cache utilization rose from 62.6% to 84.8%.

Output increased from 2,418 to 3,078 tokens, and reasoning tokens went from 232 to 253. This increase was small compared to the input savings and suggests that subagents produced somewhat longer responses while reusing context much more effectively. The total reduction did not come from reasoning less, but from forwarding less new information to the model.

The qualitative review was also favorable. Both approaches identified the main tests, continuous integration before deployment, repository cleanup, Node.js versions, and event logging. The multi-agent architecture also highlighted static backend review, PostgreSQL scripts, and the npm verify command; the monolithic agent, for its part, flagged TODO and FIXME markers. With a single run per variant, these results are evidence for the analyzed case, not a general guarantee.

The results are consistent with the technique described: the greatest benefit appeared when isolating and reusing context, not when reducing analysis quality. However, the report should separate consumption by stage to identify which decision produced the improvement and repeat the test before generalizing.

Coordination also costs. If handoffs are ambiguous, the next agent will repeat the research; if context is trimmed too aggressively, it will lose critical constraints. Using a high-capacity model in every role only fragments spending.

A reasonable operational rule is to scale orchestration with uncertainty:

· Simple, localized task: one agent with clear tests.
· Medium task: Planner, Implementer, and Tester.
· Complex or cross-cutting task: Planner, Researcher, Implementer, Reviewer, and Tester.

Before adding a role, it is worth asking what context it will isolate, what decision it will make, and what risk it will reduce. If there is no verifiable answer, it will likely add coordination cost without delivering value. Below are the comparison of results obtained, both token usage and the outcomes of the prompt used.

Token usage comparison

Qualitative comparison of results - What suggestions did each test identify?

Enterprise applications

In an organization, optimizing tokens allows allocating budgets by stage, reserving the most capable model for difficult decisions, and using cost-effective alternatives for deterministic tasks. It also improves traceability of files, decisions, and tests.

Isolation facilitates security controls: read access for the Researcher, limited editing for the Implementer, controlled execution for the Tester, and human approval before sensitive actions.

To operate this approach, it is advisable to version the index, define handoff contracts, log metrics per role, and audit unused context without losing necessary information.

Conclusion

The strategy for reducing tokens in coding agents, regardless of the codex, claude, or cursor environment, is not about imposing minimal instructions at any cost. It is about treating context as an architectural resource: select, isolate, summarize, transfer, and measure. The Planner defines the plan, the Researcher finds evidence, the Implementer modifies the code, the Reviewer reviews changes, and the Tester validates behavior.

Available evidence warns that more tokens do not guarantee more quality and that actual spending can vary between runs (Bai et al., 2026). It also shows that consolidating learnings and removing obsolete history can reduce total consumption by 22.7% without changing accuracy on a small set of tasks, although one iterative task showed 110% overhead (Verma, 2026). The local experiment reinforces that direction with a 27.7% reduction, but it must be repeated before turning the result into a general rule.

At Kranio, we design AI solutions applied to engineering processes with a focus on efficiency, security, and verifiable results. If your company wants to evaluate and optimize coding agent workflows, you can contact us at www.kranio.io.

References

Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., & Pei, J. (2026). How do AI agents spend your money? Analyzing and predicting token consumption in agentic coding tasks [Preprint]. arXiv. https://arxiv.org/abs/2604.22750

Klopfenstein, T., & Maddula, S. K. (2026, June 30). Build reliable multi-agent applications with ADK Go 2.0: Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration. Google Developers Blog.

Verma, N. (2026). Active context compression: Autonomous memory management in LLM agents [Preprint]. arXiv. https://arxiv.org/abs/2601.07190