How to Cut Coding Agent Token Costs: What the Research Shows

Coding agents are expensive in a way chat is not. A study of agentic coding runs found they use about 1,000 times more tokens than code chat or code reasoning tasks, mostly input tokens, and that two runs of the same task can differ by up to 30 times in total tokens (Bai et al., 2026). The same study found that spending more tokens did not buy more accuracy: accuracy tends to peak at moderate cost and then flattens out.

So there is room to save. The question is where, and which savings leave results intact. This post summarizes what recent research says, with most of the detail from one new paper, TokenEconomizer (Li et al., 2026), from UC Berkeley, Microsoft Research and Microsoft Security. It then shows how to find the same savings in your own Claude Code and Codex data.

Why agent tokens are different

On every turn, an agent sends the model its system prompt, the definition of every loaded tool, and the whole conversation so far. Prompt caching makes the repeated part cheaper, but it doesn't make it free. TokenEconomizer's authors report that in an agent loop about 90% of raw tokens are cache reads, and they price every token by type: for Claude models, a cache read costs 0.1 of a normal input token, a cache write 1.25, and an output token 5.

This changes what counts as a saving. Counting raw tokens overstates the value of trimming cached context and understates the cost of extra output and retries. When you evaluate any technique below, measure cost with cache-aware pricing for the exact model, and include the cost of whatever the technique itself calls.

Where the money leaks

The TokenEconomizer authors profiled 60 SWE-Bench tasks across six repositories with Claude Code and found three large sources of waste.

• Tools nobody calls. All 23 tool definitions were sent on every turn. No repository used more than 7 of them, 16 were never called, and 3 tools made 98% of all calls.
• Failed runs. Failures were 17% of tasks but 32% of spend, and 51% of spend came after a run's first repeated failure. Repetition alone isn't proof of being stuck, though: 36 of 50 successful runs also repeated a failure at some point.
• Rediscovering the same facts. The share of tool calls that repeated something an earlier task in the same repository had already done rose from 14% early on to 30% after five or more tasks. With another repository's history as a control it was 7%, so the repetition is specific to each repository, and learnable.

They also tested popular fixed tricks (output compression, semantic code navigation, repository maps). Each lowered cost in some repositories and raised it in others.

The main families of techniques

Family	What it does	Evidence	Watch out for
Trim tool definitions	Send only the tools the task is likely to use	Retrieving tools per query cut prompt tokens by more than half and raised tool-selection accuracy from 13.6% to 43.1% (Gan and Sun, 2025); pruning was the largest single lever in TokenEconomizer	Changing tools mid-conversation invalidates the prompt cache
Manage the context inside a run	Hide or compress old tool output	Simply masking old observations halved cost on SWE-bench Verified and matched LLM summarization (Lindenbauer et al., 2025); learned compression cut peak tokens by 26–54% (Kang et al., 2025)	Summaries that drop a detail the agent needs later
Compress prompts	Remove low-information tokens from long prompts	Up to 20x compression with little performance loss on several benchmarks (Jiang et al., 2023)	Code and exact identifiers compress badly
Route to cheaper models	Send easy requests to a smaller model	Learned routers cut cost by more than 2x on some benchmarks without lowering quality (Ong et al., 2024); cascades matched a top model at a fraction of the cost (Chen et al., 2023)	Harder to apply inside one agent run than per request
Lower reasoning effort	Use the model's medium or low effort setting	17–46% cheaper in TokenEconomizer's baselines	Cost 1.8 to 10.3 points of success rate
Learn from past runs	Change what the next run pays for, based on earlier runs in the same repository	18–31% cheaper with success held or improved (TokenEconomizer, below)	Needs a history of runs, and guardrails against stale lessons

The last row is the newest idea, and the one that fits coding agents best, because developers run them on the same codebase over and over.

How TokenEconomizer works

TokenEconomizer treats the agent as a black box. It doesn't change the model or the agent's code. It works only through three things agents already read: text added at the start of a session, the list of loaded tools, and hooks that run after each tool call. After each finished session in a repository, it updates three mechanisms.

1. Micro-skills: facts the agent keeps rediscovering. For example, "pytest is missing here; python -m pytest works." Each candidate fact must be confirmed in three tasks that edited different files before it is used. It is retired as soon as evidence contradicts it, and injected only while it is still needed. The block is capped at 4 facts and 150 tokens.

2. Tool pruning: drop definitions that are never called. Core tools (shell, read, write, edit, search) are never removed. Other tools are dropped after several tasks without a call, and the full set is restored every few tasks to re-check. The released plugin only writes changes after the repository has been idle for an hour, because changing tools mid-conversation would force an expensive cache write.

3. Failure-loop guard: catch a turn going in circles. A free, rule-based check after every tool call looks for repeated failure signatures, dense errors, or a turn running much longer than this repository's successful turns usually do. If a judge model agrees the turn is stuck, the agent gets one redirect message. The released plugin never stops a turn on its own.

Results

Across 277 SWE-Bench tasks, six repositories and five agent and model setups (Claude Code, Codex and GitHub Copilot CLI), average cost fell by 18.4% to 30.9%. It was cheaper in all 30 repository and setup combinations, and Pass@1 went up in four of the five setups and down 1 point in the fifth.

The comparison with effort settings is the useful one for practitioners. Medium and low effort save similar amounts of money, but they lose success rate in every setup. Learning from past runs saves comparable money without that loss.

Tool pruning was the largest single lever, facts came close behind, and the loop guard saved single digits: it fires on only about one task in ten, but each catch is expensive. The method also carried over to web development tasks (16–21% cheaper) and security auditing (6–20% cheaper, without facts, since each task used a new repository).

Limits worth knowing

• SWE-Bench tasks are independent bug fixes. The authors expect more reuse in real day-to-day work, but that remains to be shown.
• The released plugin is more conservative than the paper's setup (no model calls by default, slower pruning, no forced stops), so expect smaller savings out of the box.
• The plugin learns on one machine. Every developer on a team relearns the same facts from scratch.

What you can do this week

You don't need a new tool to apply most of this:

1. Audit your tools and MCP servers. List what's loaded in each repository and what was actually called in the last month. Disable the rest in project settings, and make the change between sessions, not during one.
2. Write down what agents keep rediscovering. Test commands, environment quirks, paths that don't exist. A few lines in CLAUDE.md or AGENTS.md save those exploration turns in every future session.
3. Set a turn budget. Look at how many turns successful tasks usually take in each repository, and treat runs well past that as candidates for a redirect or a human check.
4. Trim old tool output. If you build your own agent, mask or truncate old observations before reaching for LLM summaries.
5. Keep the prompt prefix stable so caching works, and check your cache-read share per session.
6. Measure before and after with cache-aware cost and a quality check, because several popular tricks raise cost in some repositories.

Finding the savings in Anosys

Steps 1 to 3 need data most teams don't have in one place: which tools each session loaded and called, which commands failed and were retried, how many turns successful tasks take, and what each turn cost. The Anosys Claude Code and Codex hooks send all of this for every developer and repository: tool calls and their results, shell commands and exit codes, files written, turns, input, output, cache-read and cache-write tokens, and estimated cost per model.

Because Anosys sees every developer's sessions, the analysis covers a whole team rather than one laptop. A fact three colleagues' sessions have already confirmed applies to the fourth on day one.

Ask the AI Assistant for token-saving recommendations

Open the AI Assistant, select your coding tools endpoint, and choose the Reduce token spend prompt starter. The assistant analyzes the last 30 days of sessions with the same three lenses the research uses, and returns recommendations per repository, each with its evidence and an estimated monthly saving:

• Tools to remove: tools and MCP servers that are loaded in every session but rarely or never called, with the number of sessions that carried them.
• Facts to add: commands that fail and are then rewritten the same way across sessions and developers, as ready-to-paste CLAUDE.md or AGENTS.md lines.
• Loop-prone work: turns that kept running after a repeated failure, the cost spent after that point, and the turn budget that successful tasks in that repository stay within.
• Cache misses: sessions with a low cache-read share, and what changes at the start of their prompts.

An answer looks like this (illustrative):

payments-api · 412 sessions · 9 developers

1. Disable 2 MCP servers (browser-tools, jira). Loaded in all 412 sessions, called in 3. Estimated saving: $310 per month.
2. Add to CLAUDE.md: "Run tests with make test-unit; pytest alone misses the env file." Seen in 61 sessions from 7 developers.
3. Turn budget: successful tasks finish within 38 turns. 23 sessions ran past 60 turns after repeating the same failing test; they cost $540 after the first repeat.

Each recommendation links to the sessions behind it, so you can check the evidence before changing anything. Ask follow-ups such as "Show me the sessions behind recommendation 3" or "Chart cost per session for this repo before and after last Monday."

Check that the change worked

After applying a recommendation, compare cost per session and per completed task before and after on a dashboard, and keep an eye on quality: task success, reverted edits or an evaluation score. To compare properly, run an Experiment with the change on for some repositories or developers and off for others. Set an alert on cost per session per repository so a regression shows up the week it happens, not on the invoice.

See Track AI and coding spend to connect your coding tools.

Free plan, no credit card

Start tracking your token cost for free

Connect Claude Code, Codex or your own agents in a few minutes. See cost per session, per repository and per developer, and get specific recommendations to cut consumption without hurting task success.

Start tracking for free Learn how to optimize consumption →

References

1. Li, A. J., Xu, W., Singh, C., Chen, Z., Inala, J. P., Siska, C., Tamersoy, A., Yu, B., Stoica, I., Galley, M., Gao, J. TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents. arXiv:2610.22732, 2026. Code: microsoft/TokenEconomizer.
2. Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., Pei, J. How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750, 2026.
3. Lindenbauer, T., Slinko, I., Felder, L., Bogomolov, E., Zharov, Y. The Complexity Trap: Simple Observation Masking Is as Efficient as LLM Summarization for Agent Context Management. arXiv:2508.21433, 2025.
4. Kang, M., et al. ACON: Optimizing Context Compression for Long-horizon LLM Agents. arXiv:2510.00615, 2025.
5. Gan, T., Sun, Q. RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv:2505.03275, 2025.
6. Jiang, H., Wu, Q., Lin, C.-Y., Yang, Y., Qiu, L. LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. arXiv:2310.05736, 2023.
7. Ong, I., et al. RouteLLM: Learning to Route LLMs with Preference Data. arXiv:2406.18665, 2024.
8. Chen, L., Zaharia, M., Zou, J. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176, 2023.