TLDR overview
- Token optimization means reducing unnecessary model work without reducing output quality. For coding agents, that includes the context they read, the responses they generate, the reasoning they perform, and the repeated turns they need to complete a task.
- Token count and token efficiency are not the same thing. Simply removing context can make results worse; improving efficiency means preserving the signal the agent needs while eliminating repetition, noise, and avoidable rework.
- Code quality affects agent usage. In Sonar’s initial matched-pair study, agents working on cleaner code used 7.2% fewer input tokens, 8.5% fewer output tokens, and revisited files approximately 34% less often.
- Sonar Vortex improves efficiency inside the coding loop. It guides agents with relevant project context, replaces noisy text-search reconstruction with semantic navigation, and verifies changes in real time before the pull request.
- The return extends beyond the token bill. Earlier issue detection can reduce failed CI reruns, review churn, context switching, and the long-term maintenance cost of AI-generated code.
Why do AI coding agents use so many tokens?
Usage-based pricing is no longer a footnote on the AI invoice—it is the invoice. In the last two years, the share of FinOps survey respondents actively managing AI spend has jumped from 31% to 98%. AI cost has moved into the same meetings as the cloud bill, and coding agents are an increasingly important part of that discussion.
Modern coding agents don’t send one prompt and get one answer. They run multi-step loops: read a file, grep the repository, plan an edit, re-read what they just wrote, run a test, revise. In one 2026 study of OpenHands on SWE-bench Verified, an agentic coding task averaged 4.17 million tokens per run across eight frontier models, including tool calls, file reads, edits, retries, and reasoning. OpenRouter has analyzed over 100 trillion tokens collected across approximately two years.
Most of those tokens are not the code the agent writes. They’re the code the agent reads—repeatedly—to figure out where to write. That is where token optimization comes in.
What is token optimization?
Token optimization is the discipline of reducing the number of tokens an AI system consumes to complete a task without degrading the quality of the output.
In an agentic coding context, that means eliminating model work that does not improve the result: irrelevant context, repeated file reads, unnecessary tool calls, overly long outputs, and avoidable retry loops.
What is the difference between input, output, cached, and reasoning tokens?
Each token category affects context, billing, and performance differently. The exact accounting varies by provider and model, but the practical distinctions are:
- Input tokens — Everything sent to the model each turn: the user request, the system prompt, the growing tool-call transcript, and every file the agent has pulled into context.
- Output tokens — Everything the model generates: plans, code, tool arguments, and explanations.
- Cached input tokens — Previously processed prompt content that qualifies for a provider’s cache. Cache hits are usually billed at a discounted input rate rather than being free, and eligibility depends on the provider’s cache rules.
- Reasoning tokens — Additional internal computation used by some reasoning models before answering. How these tokens are exposed and billed varies by provider and model.
Context is a budget, and every re-read, every over-broad grep result, and every unused tool definition loaded into the prompt draws it down. Token optimization is what happens when teams start treating that budget the way they treat their cloud budget.
Why does token optimization matter for AI costs?
Three forces have converged.
Pricing has decoupled from output. Prices per million tokens have fallen across many model families, but the relative cost of wasteful usage remains—and agents can inflate usage faster than unit prices fall. A cheaper token still costs real money if you burn ten times more of them.
Agents multiply everything. A single developer prompt can turn into many model calls under the hood. Any inefficiency compounds across every turn.
Coding is the workload. Coding agents are a growing category of AI spend inside engineering organizations, and unlike chat, they can run unattended. Nobody notices a 3× token blow-up on a coding task until the invoice arrives.
Usage-based pricing is here to stay. Optimizing what you send to the model is now a first-class engineering concern, not a nice-to-have.
What is the difference between reducing tokens and improving token efficiency?
Reducing tokens means lowering the raw number of tokens sent to or generated by the model. That may involve shortening a prompt, removing context, limiting output, or ending a task earlier. It can reduce the cost of an individual request, but it can also remove information the model needs and create worse results, more retries, or additional review work.
Improving token efficiency means getting the same or better result from less model work. The agent still receives the context it needs, but irrelevant files, repeated searches, duplicated instructions, unnecessary turns, and avoidable corrections are removed from the workflow.
The difference is the outcome. A shorter prompt is not more efficient if it causes the agent to fail and try again. A workflow is more token-efficient when it lowers the cost per successfully completed task while maintaining—or improving—correctness, security, and maintainability.
Does code quality affect LLM token usage?
Yes. The structure and maintainability of a codebase affect how much work an agent has to perform before it can make a correct change.
What Sonar’s research found
Sonar initially reported a controlled study—540 agents run across six matched pairs of repositories that ship the same application, pass the same tests, and use the same dependencies. The only difference between each pair was code quality: how the code was factored, named, nested, and whether it carried the kinds of issues SonarQube flags. A later arXiv paper expanded the experiment to 660 trials across 33 tasks.
On the cleaner side of every pair in the initial study, the same agent used:
- 7.2% fewer input tokens
- 8.5% fewer output tokens
- 11.1% less estimated reasoning effort (derived from event-stream characters because Anthropic did not expose reasoning-token counts directly)
- Approximately 34% fewer file revisits after the agent had already edited a file
- 3.6% fewer turns before the first code change
- No meaningful change in whether the task got done
The mechanism is the same one that matters for human readers. When an agent hits a 400-line function with branchy control flow, cryptic names, and deep nesting, it has to work harder—more reading, more re-reading, and more reasoning before it touches anything. Clean code gives it shorter paths to the same answer, so it commits and moves on instead of circling back.
The takeaway: code quality is now an AI infrastructure cost lever, not just an engineering best practice. Teams already investing in maintainability may also reduce the operational work their coding agents perform, although the measured effect varied by task and has not yet been established across all models and production environments.
How Sonar Vortex improves token efficiency across the coding workflow
Clean code is the floor. Sonar Vortex is the ceiling.
Vortex works inside the agent’s coding loop as one continuous Guide + Verify process: give the agent the right context and constraints before it writes, then analyze every change while the work is still in progress.
Guide: give agents the right context before they write
Before the first line of code, Vortex supplies task-relevant repository context and the constraints the output has to respect. That includes the current and intended architecture, coding standards, SonarQube quality profiles, security policies, dependency guidance, team conventions, approved libraries, and API contracts.
Instead of relying on a static prompt file or making the agent reconstruct the codebase one file at a time, Vortex filters the available context down to what the task needs. The agent starts from the same standards the organization already enforces, reducing irrelevant context, repeated prompting, and architectural drift.
Navigate: replace text-search reconstruction with structural context
Vortex’s graph-based navigation engine gives the agent a semantic map of supported code—a single in-memory graph of modules, classes, methods, and fields, with edges representing calls, references, implementations, and inheritance relationships. Every node carries its file path and line.
When the agent needs to find every real edit site for a change, it asks the graph and gets a deduplicated list of file-path and line-number targets. No grep storm. No reading twenty files to figure out which of the 461 name matches actually matter.
In Sonar’s benchmarks against real merged commits from popular open-source repositories:
- Model-usage cost was up to 36% lower per run on selected navigation-heavy refactoring tasks.
- Six selected tasks across four languages—Java, Python, TypeScript, and C#—showed a lower mean or median cost, although one task’s mean rose 5% while its median fell 20%.
- One task—Apache Commons Collections’ BloomFilter self-typing change—cut input tokens from 18.8 million to 12.9 million, a 31% drop, while landing the correct 16 edit sites hidden inside 461 grep matches. That is a noise-to-signal ratio of approximately 29:1.
- The SQLAlchemy compiler-keyword-arguments task contained 47 real override sites among 1,152 grep hits, a noise-to-signal ratio of approximately 24:1. Mean cost fell 20% and median cost fell 29%.
Three mechanics drive the navigation savings. First, one structural query can replace many grep-and-read cycles, so there are fewer turns. Second, the agent can avoid pulling unrelated files into context to disambiguate, lowering the resident-context floor on subsequent turns. Third, the graph work runs locally and in-process, so it does not itself consume model tokens.
Vortex can also surface the “invisible site” case that text search may miss: edit locations that do not contain the searched interface name, indirect calls, and sites connected through dynamic dispatch. That is a correctness win as much as a cost win—a silent bug that ships is more expensive than any token bill.
Like other structural analyses, graph resolution is not infallible. Sonar notes that some call edges are approximated rather than resolved with compiler-level precision.
Verify: analyze and detect issues inside the agent workflow
Navigation is only part of Vortex. As the agent writes, Vortex verifies each change in real time using SonarQube’s algorithmic analysis and full project context. It can detect security vulnerabilities, reliability bugs, maintainability issues and code smells, duplication, test-coverage gaps, and quality-gate failures—including issues that depend on relationships across files.
Those findings arrive before the pull request. The agent can use the specific, rule-based feedback to correct the code and verify it again while the task context is still active, instead of handing avoidable issues to CI or a human reviewer.
Vortex connects through SonarQube agent plugins, the SonarQube CLI, or the SonarQube MCP Server. That lets teams apply the same SonarQube rules, quality profiles, and governance across different coding agents, models, IDEs, and command-line workflows.
From token savings to long-term ROI
Vortex does not replace CI, and teams should continue running their established pipeline and review controls. It moves feedback earlier. When issues are detected and corrected inside the agent loop, fewer broken changes should reach CI, which can mean fewer failed builds and reruns, less back-and-forth in review, and less context switching for developers.
The value therefore extends beyond the token reduction measured in the navigation benchmarks. Guided generation helps agents produce code that fits the repository from the start. In-workflow verification catches security, reliability, and maintainability issues before handoff. Over time, fewer retry loops, cleaner pull requests, less architectural drift, and more maintainable AI-generated code can improve the long-term return on AI-assisted development—not just the price of an individual model run.
Baseline savings—cleaner code means the agent has less to understand—guided context, navigation savings, and real-time verification address different sources of cost and rework. These gains may stack, although their combined financial impact has not yet been measured in a single controlled study.
For an engineering organization running coding agents at scale, reducing the context processed per call, unnecessary model calls, failed CI reruns, and avoidable review cycles can help turn AI from a growing usage line item into a more durable engineering investment.
How do I start optimizing token usage for AI coding agents?
If your agents work on real codebases—the kind with legacy, drift, and a long tail of maintenance—token optimization starts with three questions: Is the code clean enough that the agent isn’t paying tax to understand it? Does the agent have the right context and a real map of the codebase? Are issues caught while the agent is still working rather than after handoff?
Sonar answers all three.
Start free with SonarQube — Measure your codebase and start addressing maintainability issues that can increase the work coding agents perform.
Explore Sonar Vortex — Bring governed context, semantic navigation, and real-time code verification into your agent workflow to reduce token use, rework, and downstream feedback cycles.