What is token optimization for AI coding agents?

Why do two similar tasks give your coding agent very different token bills?

AI coding agents are moving from experiment to daily tool, and the invoices are arriving. In a FinOps Foundation survey of 1,192 practitioners, 98% now manage AI spend, up from 31% two years earlier. Platform engineers, staff engineers, and the finance partners who review AI spend are asking the same question: why did this task cost so much more than that one?

The gap is real. A study of coding agents found that runs of the same task can differ by up to 30 times in total tokens, and that using more tokens does not mean getting a more accurate result. Much of the answer sits in how much code the agent has to read.

This article explains where coding agents spend their tokens, why codebase context drives so much of that spend, and how to reduce it without quietly trading away quality. Token optimization is the part of AI cost optimization that teams can change directly in agentic development. The article is written for the people who configure agents and the people who have to justify what those agents cost.

What does token optimization mean in practice?

Token optimization is reducing the number of tokens an agent uses to complete a coding task. The unit of cost is the completed, accepted change, not the individual request.

A token is a small chunk of text, roughly a word fragment, that a model reads or writes. Providers charge per token, so the cost of a task is the tokens used multiplied by the price of each one. An agent spends tokens reading files, calling tools, carrying context from step to step, and writing output.

The simplest way to hold the idea: you are not trying to make each token cheaper. You are trying to finish the job with fewer of them.

Why do cheaper tokens not make cheaper agent tasks?

Price is the part your team does not control. Usage is the part it does. A cheaper model that reads twice as much code, or needs three attempts, can cost more per finished task than a pricier model that gets there directly. Compare cost per completed task, not price per token.

Three things push usage up regardless of model price:

• Reading. Before an agent writes anything, it reads files, folder structure, related modules, and documentation. The more it must read to understand a change, the more input tokens it uses.
• Tool calls. Each search, file open, or command is a separate step, and every step sends the conversation so far back to the model. A single task can involve dozens of them.
• Repeated context. Files an agent opens stay in the conversation, so they are paid for again on every later step.

Sonar’s research describes the effect this way: the cost of a run is roughly the number of steps multiplied by the amount of context carried on each step.

Independent research points the same way. Bai et al. found that agentic coding tasks use about 1,000 times more tokens than code chat or code reasoning, that input tokens drive most of the cost, and that more tokens do not buy more accuracy. Models also tend to underestimate how many tokens they will use. That variability is the point. When runs of the same task can differ by up to 30 times, the price list stops being the number that matters.

Where do coding agents spend their token budget?

Input tokens versus output tokens

Input tokens are everything sent to the model on each step: the task prompt, the files read so far, tool results, and accumulated context. Output tokens are what the model writes back: code, explanations, and tool instructions.

For most coding tasks, input dominates. In the most expensive task Sonar measured, an agent used 18.8 million input tokens and 89 thousand output tokens, more than 200 times as much input as output. Sonar’s research report, citing earlier studies, puts the average at around 4 million tokens per task on a standard benchmark of real software tasks, with most of it input. That points optimization at what the agent reads, not only at what it writes.

Repeated file reads

Agents revisit the same files. An agent that cannot hold a clear picture of the codebase re-reads modules it already saw and reloads context it already had. Every revisit is paid for in full. In Sonar’s code-health study, file revisits showed the largest difference between healthier and messier code, which makes them one of the clearest signals that an agent is spending tokens to compensate for code that is hard to navigate.

Three other factors change the bill without changing the work:

• Caching. Providers can discount context that repeats between steps. How much you benefit depends on timing and varies from one user to the next.
• Context management. Some agent tools trim or summarize earlier steps to keep the carried context small. How much this happens depends on the tool and its settings.
• Model pricing. The rate per token sets the price of each token, not how many are used.

Because these factors vary, Sonar’s studies count every token at face value. That separates the work the agent did from the discount it received.

How does codebase context affect AI coding costs?

Codebase context decides how many files an agent opens before it finds the ones that matter. It is the information an agent needs to make a correct change: how files relate, what a function does, where a symbol is defined, and which parts of the system a change touches. The clearer that context, the less the agent has to read, infer, and retry.

How code health changes the work agents do

Code health describes how easy code is to read, change, and test. Four traits plausibly change how much an agent has to read before it can act:

• Naming. Clear names let an agent understand a function from its signature. Cryptic names force it to read the body, and often the callers too.
• Function size. Small, focused functions are cheaper to read. A 400-line function with many branches means more reading, re-reading, and reasoning before the first edit.
• Structure. Well-organized code lets an agent find what it needs and stop. Tangled structure sends it searching.
• Unnecessary file revisits. When relationships are implicit, agents re-read files to rediscover them.

These are explanations, not separate findings. Sonar’s study measured their combined effect.

Sonar tested that effect with six pairs of repositories. In each pair, both sides ship the same application, pass the same tests, and use the same dependencies. They differ in how the code is factored, named, and nested, and in the issues SonarQube flags. An agent (Claude Code with Sonnet 4.6) ran each of 27 tasks ten times on each side, about 540 runs. On the healthier side:

• About 7% fewer input tokens
• 8.5% fewer output tokens
• About 11% less reasoning text, an estimate based on counting characters because the model provider does not report reasoning tokens
• 34% fewer returns to files the agent had already edited
• No meaningful change in whether the task was completed (down 0.9 percentage points, within noise)

The finding is about efficiency, not success. Code health did not decide whether the agent finished. It changed how much work the agent did to finish. Report it that way, because overstating it invites exactly the skepticism you are trying to avoid.

The averages hide a wide spread. Across the 27 tasks, the change in input tokens ranged from 47% fewer to 44% more, with a median of 4.5% fewer. The healthier side used fewer input tokens on 16 tasks and more on 11. The effect was strongest on 14 tasks that spanned several modules and close to absent on 13 tasks centered on one dense area of code. The agent also opened slightly more files on the healthier side overall, so the savings came from less revisiting and less code carried in context, not from opening fewer files.

Read these as averages, not promises. The study covers one agent and one model, with each run done in a single pass. Sonar defined and measured code health with SonarQube, so this is not a third-party study. The full research report is on arXiv.

Give agents the right context, not the entire repository

The instinct to hand an agent everything is expensive. More context is more tokens, and much of it is noise for the task at hand. The goal is targeted context: the specific files, relationships, and standards a change requires.

A task description says what should change, not where. So the agent builds its own map: search for a name, open the files that match, work out how they relate, then search again. Text search matches characters and cannot tell which matches matter. On one Java task Sonar measured, a search for the relevant type name returned about 461 matches. Only 16 were places that needed to change. The agent opened file after file to sort one group from the other, and every file it opened stayed in the conversation.

Text search tends to fail in three ways: too many matches, places to change that share no text with the search term, and matches that point at a different thing with the same name.

Use targeted navigation and dependency relationships

A better approach lets the agent ask how the code fits together: which classes implement this interface, what calls this method, what refers to this symbol. The answers come back as exact file and line locations, so the agent opens only what it needs to edit. Structural understanding of what depends on what also lets an agent make complete changes without rediscovering the relationships on every run.

Sonar Vortex provides this through a live map of the code that updates as the agent edits. It supports Java, Python, JavaScript and TypeScript, C#, and Rust. Sonar tested it on six tasks from open source projects in Java, Python, TypeScript, and C#, with ten runs per side. A run counted only if it built and passed the tests. The median cost per run fell between 6% and 34% across the six tasks. The largest average saving, 36% on one Java task, is a ceiling, not an expectation. On one C# task the typical run was 20% cheaper while the average was 5% higher, because a few unusually long runs pulled it up.

Scope your project guidance

Most coding agents read a project instruction file at the start of a session. Short, specific guidance saves exploration: how to build and test, how folders are organized, naming rules, and which areas to leave alone. Keep it scoped. Put guidance for one service in that service’s folder instead of loading one large file for every task, because everything loaded is carried on every step. Sonar’s token studies did not measure this directly. It follows from the same cost mechanism.

Know when context is not the bottleneck

The navigation savings came from one shape of work: the same small change repeated across every implementation of a shared interface or base class, where a text search cannot list the places cleanly. Where finding code is not the hard part, there is little to save. If a task is dominated by a slow build and test loop, by a large number of mechanical edits, by hard reasoning, or by an unclear request, better context changes little. In Sonar’s tests on tasks like that, cost stayed within a few percent of the same task without navigation.

Results also depend on the model. The headline tests used Opus 4.8. In wider testing the pattern held on Sonnet, while a smaller model used the tool less consistently and left some savings unclaimed.

How do you measure token savings without hiding quality regressions?

A cheaper run that fails review is not a saving. Compare similar tasks before and after a change, and track these five signals together:

Repeat each task. Agents are noisy. In Sonar’s code-health study, the most expensive of ten repeats of the same task typically cost about 2.5 times the cheapest, and in 72% of task groups it cost more than twice as much. The authors note that a single per-task difference of around 10% may be agent noise. In the navigation study, one Python task looked 92% more expensive with navigation when averaged over two runs. Over ten runs per side, it was 20% cheaper on average and 29% cheaper at the median. Ten runs per side was the minimum Sonar found stable enough to show the direction of an effect.

Report the median and the spread, not one favorable run. The median is the middle result when you sort runs by cost, so a few unusually long runs do not distort it. Show the range next to it. A change that lowers median tokens while holding completion rate steady is a real improvement.

Count a run only if it passes. A change that lowers tokens but drops completion rate has moved cost from the model bill to your engineers. Put completion rate beside every cost number.

A practical token optimization checklist

Work the problem in order. Each step depends on the one before it.

1. Baseline usage. Pick a representative set of tasks and run each at least ten times. Record input tokens, output tokens, billed cost, file revisits, and completion rate, and keep the median and spread for each task.
2. Identify expensive navigation patterns. Read the logs of your costliest runs. Look for long chains of searches, the same file opened repeatedly, and names that return many matches when only a few matter. These are where better context pays off most.
3. Improve context. Add targeted navigation for tasks that must find many places. Scope your project guidance. Fix the hardest-to-read code that agents keep returning to.
4. Retest and compare. Re-run the same tasks under the same conditions. Compare medians across all five signals. Keep a change only if tokens drop and completion rate holds.

One limit to keep in view: an efficient attempt can still be expensive if it repeatedly fails. A run that uses fewer tokens but needs three tries costs more per accepted change than one that succeeds the first time. The cheapest token is the one spent on a change that ships. Cost per attempt is the starting point. Cost per accepted change is the next question.

How does Sonar help agents work more efficiently?

Sonar Vortex works inside the agent’s coding loop on the two things that drive token waste: poor context going in and rework coming out.

Before the agent writes, Sonar Vortex injects project context and constraints, such as repository and architecture rules, coding standards, security policies, and team conventions. Its navigation engine answers structural questions directly, such as what implements an interface or what calls a method, and returns exact file and line locations. Sonar’s navigation benchmark measured this part.

As the agent writes, Vortex checks each change with SonarQube’s algorithmic analysis, so issues surface before the pull request instead of after another round of generation. Sonar’s token studies did not measure this part. It is designed to reduce rework, so confirm the effect on your own tasks with the method above.

Vortex is available through the SonarQube CLI and through agent plugins for tools such as Claude Code, Codex, GitHub Copilot, Cursor, and Antigravity. For agents without a plugin, the SonarQube MCP Server connects them to SonarQube analysis.

Give agents the right context, then verify what they write

Sonar Vortex gives coding agents project context and structural navigation before they write, and SonarQube verifies what they produce. Teams get lower token use on navigation-heavy work and code they can trust.

See how Sonar helps agents work efficiently

Next steps

• Cut your coding agent’s cost with Sonar Vortex: how structural navigation reduces agent token spend, with results by task.
• A cleaner codebase results in less token usage: Sonar’s research on how code health affects input tokens, output tokens, and file revisits.
• SonarQube MCP Server: connect SonarQube analysis to your agentic workflows.