How to Reduce AI Agent Costs Without Sacrificing Quality
Most advice about cutting AI spend is really advice about buying less intelligence. Use a smaller model. Cap the output. Turn off reasoning.
That advice works, in the sense that the bill goes down. It also tends to hand back the thing you were paying for.
There is a better category of change: cuts that remove overhead rather than capability. An agent session spends most of its tokens on resent transcript, tool output, and turns that repeat themselves. None of that is intelligence. All of it is compressible.
Short answer: Cut agent costs by making the prompt prefix cacheable, tuning reasoning effort per route instead of disabling it, narrowing the tool surface and filtering tool results, scoping edits and output to what the task needs, and routing model choice per turn. These target overhead, not capability, which is why they do not trade quality for cost.
The tradeoff is weaker than most teams assume
The assumption behind "you get what you pay for" is that cost and quality sit on one axis, so every dollar saved costs you accuracy.
Agent workloads do not behave that way, because a large share of spend buys no accuracy at all. We tested this directly: 89 Terminal-Bench 2.1 tasks, identical Claude Code harness, identical infrastructure, with the only difference being how model calls were served.
Configuration | Tasks solved | Accuracy | Total cost | Cost per solved task |
|---|---|---|---|---|
Entelligence Router | 71 / 89 | 79.8% | $65.75 | $0.93 |
Claude Opus 5 | 63 / 89 | 70.8% | $190.62 | $3.03 |
Claude Opus 4.8 | 58 / 89 | 65.2% | $155.33 | $2.68 |
Turn-level routing was cheaper and more accurate than running every turn on a frontier model. Not a wash, not an acceptable compromise: better on both axes.
That is one benchmark on one harness, single seed, with observed run to run variance of roughly two tasks, and it is not a universal model ranking. The full methodology and its four limitations are worth reading before you generalize from it.
The mechanism generalizes further than the number does. If a chunk of your spend is buying overhead, removing it cannot cost you quality, because it was never buying any.
Sort your changes before you make them
The single most useful habit is separating the two kinds of cut:
Kind of change | What it removes | Quality effect |
|---|---|---|
Overhead cut | Resent context, redundant tool output, duplicate reasoning, verbose responses | None, or positive |
Capability cut | Model tier on hard turns, context the task needs, output length on complex answers | Real, and often delayed |
Capability cuts are not always wrong. They are just a different decision, with a different owner, and they should never be made accidentally while chasing a cheaper invoice.
Everything in the next five sections is an overhead cut.
Lever 1: Make the prefix cacheable
This is the highest-leverage change in most codebases and usually the cheapest to ship.
Agents resend the entire transcript every turn. Prompt caching makes that resend cheap: on Anthropic's published rates, cached reads cost about 0.1x the base input price against a 1.25x write premium at the default five minute TTL, so a stable prefix pays for itself by the second request.
The failure mode is not forgetting to enable caching. It is enabling it and then silently invalidating it.
Caching is a prefix match, so one changed byte invalidates everything after it. Render order is tools, then system, then messages, which means anything volatile near the front is expensive:
Invalidator | Why it breaks the cache | Fix |
|---|---|---|
| Prefix differs every request | Move it into the latest user turn |
Session or user ID interpolated up front | No sharing across users | Put it after the last breakpoint |
Unsorted JSON serialization | Byte order varies run to run | Sort keys |
Tool set that varies per user | Tools render at position zero | Declare one stable set |
Switching models mid-session | Caches are model-scoped | Keep the main loop on one model |
Verify, do not assume. Read cache_read_input_tokens on the response. If it is zero across repeated requests with what should be an identical prefix, you have an invalidator, and no amount of added cache_control markers will help until you find it.
Lever 2: Tune reasoning effort, do not switch it off
Reasoning is billed as output, so it is a tempting target. Disabling it outright is the wrong tool.
The effort parameter is the right one. It controls reasoning depth and overall token spend on a scale, rather than as a switch, and lower settings also produce fewer and more consolidated tool calls.
Route | Suggested effort | Why |
|---|---|---|
Classification, extraction, short lookups | Low | Nothing here needs multi-step reasoning |
Routine chat and summarization | Low to medium | Quality holds well below the default |
Most application work | Medium to high | The usual balance point |
Agentic coding and long-horizon tasks | High to extra high | Deep reasoning pays for itself in fewer retries |
Correctness over cost | Max | Reserve it, do not default to it |
Two things make this a genuine overhead cut rather than a capability cut. Lower effort removes deliberation the task could not use, and it is set per route, so hard work keeps the depth it needs.
Watch for responses that stop on a token limit instead of a natural finish. That is reasoning eating the output budget, and the fix is a higher ceiling or lower effort, not both.
Lever 3: Narrow the tool surface, filter the results
Tool schemas render before the system prompt, so a catalog of forty tools is a fixed tax on every turn whether the agent calls one or none.
Tool results are the larger problem. A repository-wide grep or a full file read enters the transcript verbatim and stays there, resent on every subsequent turn for the rest of the session.
Change | Mechanism | Where it pays |
|---|---|---|
Tool search with deferred loading | Schemas load on demand and append rather than swap, preserving the cache | Large tool catalogs |
Chained calls run in code; only the final result enters context | Multi-step tool chains with big intermediates | |
Clears stale tool results from the transcript | Long sessions | |
Scoped reads instead of whole files | The file never enters context permanently | Every coding agent |
Batch API for offline work | 50% off standard pricing | Anything not latency sensitive |
The last row is the one teams most often miss. If a workload does not need an answer in the next few seconds, half the bill is available for the cost of an async code path.
Lever 4: Scope the output
Output tokens are priced several times higher than input. Claude Opus 4.8 runs $5 per million in against $25 per million out, and most frontier models are shaped similarly.
Verbose output is also billed twice, because the response joins the transcript and gets resent as input for the rest of the session.
Three changes, in order of payoff:
Scoped edits instead of whole-file rewrites. A targeted replacement pays for the changed lines. A rewrite pays for the entire file, in output tokens, at the output rate.
A conciseness instruction in the system prompt. One paragraph. Prompting is far cheaper than changing models, and it is the correct fix for verbosity.
Length guidance for written deliverables. Reports and summaries drift long unless told otherwise.
Positive instructions beat prohibitions here. Describing the output you want works better than listing the habits you do not.
Lever 5: Route the turn, not the session
The first four levers reduce how many tokens move. This one changes what each token costs, and it is the largest single lever.
A coding session is not one kind of work. Interpreting an instruction, searching a repository, reading code, forming a hypothesis, editing a file, running tests, reacting to the result: some of those turns need the strongest available model and most do not.
Our three-model analysis found the useful split is three lanes rather than two:
Lane | The work it fits | Cost of getting it wrong |
|---|---|---|
Efficient | Renames, file reads, test reruns, mechanical continuations | Frontier pricing on work a cheap model finishes identically |
Middle | Long-horizon, repo-scale work needing real code comprehension | Overspend by defaulting up, or underserve by dropping down |
Frontier | Ambiguous requirements, architecture, security-critical reasoning | Quality gaps that surface in production |
Entelligence Model Router makes that choice per turn rather than per session: the least expensive model that can handle the current turn, escalating when the trajectory shows a stall, stepping back down when progress returns.
One detail separates this from naive routing. Caches are scoped to a model, so switching mid-session means re-ingesting the transcript from scratch. Deep into a long session, staying on a warm model for one more turn can cost less than moving to a nominally cheaper one, so cache warmth has to be priced before any switch.
If you would rather evaluate the category than adopt a product, our comparison of nine LLM routers covers the options including self-hosted ones.
Five cuts that cost more than they save
These are the ones that look like savings on a dashboard and show up as spend somewhere else.
The cut | What actually happens |
|---|---|
Trimming context the task needs | The model fills gaps with generic defaults, you retry, and the retry costs more than the context did |
Capping | Answers truncate mid-thought and get retried from scratch, paying twice for one response |
Disabling reasoning to save output tokens | Tool-calling reliability degrades on some models, and a silently skipped tool call is worse than an expensive one |
Forcing every turn onto a cheap model | The quality gap appears in production, where it is most expensive to fix |
Over-compressing the system prompt | Removing context is not the same as removing waste; too-short prompts produce generic output |
The pattern is the same in all five: the saving is immediate and visible, the cost is delayed and lands in a different column. A retry loop does not appear on the line item you were optimizing.
The honest test for any cost change is not whether the invoice fell. It is whether cost per completed task fell. Those move in opposite directions more often than teams expect.
The order to do this in
Sequencing matters, because the cheap changes make the expensive ones measurable.
Stage | Do this | Why here |
|---|---|---|
1. Measure | Track tokens and cost per session, not per request | Every later change is unverifiable without it |
2. Fix the cache | Freeze the prefix, move volatile values, confirm cache reads are non-zero | Largest saving, lowest risk, no quality surface |
3. Tune the cheap knobs | Effort per route, a conciseness instruction, scoped edits | Prompt and config changes, reversible in minutes |
4. Change the plumbing | Tool search, result filtering, batch for offline work, per-turn routing | Worth doing once the baseline is stable enough to attribute against |
Do not start at stage 4. Routing on top of an invalidated cache will show a smaller saving than it should, and you will draw the wrong conclusion about the lever.
Start with measurement, and with the five metrics worth tracking. Entelligence research across more than 1 million pull requests and 2,444 organizations estimates that about $0.18 of each dollar spent on AI coding tools becomes shipped product. That is vendor produced research rather than a universal benchmark, but it points at the same gap this article does. Agent Insights is where we put that visibility, broken out by outcome, project, and model, including the untracked spend sitting in projects with no budget attached.
Frequently asked questions
Can you really cut AI agent costs without hurting quality?
For the overhead portion, yes, because that spend was not buying quality in the first place. Resent context, redundant tool output, and duplicated reasoning are compressible with no capability effect. Cutting model tier on genuinely hard turns is a different decision and does trade quality.
What is the fastest change with the biggest payoff?
Fixing prompt cache invalidation. It is usually a few lines of prompt-assembly code, it has no quality surface at all, and on a long-running agent it is often the largest single saving available.
Does using a cheaper model always reduce quality?
Not per turn. Most turns in a coding session are mechanical, and a cheaper model completes them identically. The quality loss comes from using a cheaper model on the turns that actually need reasoning, which is an argument for routing per turn rather than for picking one model.
Should I turn off extended reasoning to save money?
No. Lower the effort level instead. Disabling reasoning entirely can degrade tool-calling reliability, and a tool call that silently never runs costs far more to debug than the reasoning tokens saved.
How do I know a cost change did not hurt output?
Track cost per completed task, not total spend. Total spend falls when quality falls, because failed work gets abandoned. Cost per completed task only falls when something genuinely improved.
Is prompt caching enough on its own?
It is the biggest single lever and it is not sufficient. Caching reduces what resent tokens cost without reducing how many are sent, and it does nothing about turns that repeat, tool output that never leaves the transcript, or frontier pricing on routine work.
Cut overhead, keep capability
The reason cost and quality look like a tradeoff is that most cost advice targets capability, which is the one part of the bill that is actually buying you something.
Target the overhead instead. Make the prefix cacheable, set effort per route, narrow the tool surface, scope the output, and let model choice follow the difficulty of each turn. Then measure cost per completed task, which is the only number that tells you whether a change worked.
If you want the routing handled at the gateway rather than in your prompts, see Entelligence Model Router in action.