Back to Blog
Illustration of a coding agent session billed across cached and uncached model calls, with a router selecting the model at the start of the trace.

How to Reduce AI Coding Agent Costs

|By Joshua Martin|

As the price of intelligence falls, consumption rises. Requesty's twelve-month study of production gateway traffic puts average spend at $92 per active coding-agent user per month by April 2026, up 3.8x over the year while per-call cost stayed flat across that period. The increase came from volume, companies are seeing their developers using more tokens, and so many CFOs and CTOs are looking for ways to reduce their spend. Uber, for example, recently exhausted its 2026 AI coding budget in four months and now caps spend at $1,500 per employee per agentic coding tool.

Beyond net increases in usage inflating token bills, many are seeing the writing on the wall regarding the major labs pricing of coding agents. Companies like Anthropic and OpenAI provide heavily subsidized coding plans for Claude Code and Codex, and that can't last forever. So what should a company do to ensure their developers can make use of AI without a constantly increasing bill?

The cost in an agent session

Most tokens are input tokens. To generate a response, coding agents process the system prompt, tools, project instructions, the conversation so far, and the results those calls returned. The next turn sends all of it again plus the most recent message. That stable front portion of the request is the prefix, and it is re-computed fresh each time.

Output tokens cost two to five times more than input, with much of that going to reasoning tokens. So a large portion of the cost for any given call is directly correlated with which model answered, and how much that model's output tokens cost.

This gives us two main axes for controlling costs, reducing the price of the high volume input, and reducing the cost to generate responses. Both can be achieved without reducing quality of responses or developer experience.

Input: Prompt caching

The most effective way to reduce the cost of input tokens is through prompt caching. Prompt caching allows long prefix inputs (system prompt, tool results, prior turns) to remain in memory with the model provider so the next turn can be computed from the prefix point. Providers charge substantially less for cached tokens, on the order of a tenth of the fresh input rate, though it is not free. Cache writes are charged at a slightly higher rate, but in a session that resends the same context on every turn, the write pays for itself on the next call. Measured on long-horizon agentic tasks across four models, Don't Break the Cache puts the savings between 41 and 80 percent.

The cache only works when the prefix is identical to the one sent last time. Change anything in it and the next request pays full price for those tokens and writes a new cache entry. DigitalOcean measured a 12-turn agent session holding a 98.7 percent token hit rate, then reran it with a request ID and timestamp injected above the stable block. The hit rate fell to 0.7 percent and mean time to first token went from 40ms to 326ms. Any change mid run will drop cache hit rates.

Cached prefixes have a lifespan, called a TTL, Anthropic's default prompt cache lasts five minutes measured from the start of the request, so a call that spends four minutes generating leaves about one minute for the next request to land on a warm cache. In our own terminal-bench runs the median call reads back 15 percent of its input from cache. In the real world, hit rates are often even lower since any pause while a developer reads the output runs against the TTL clock.

Prompt caching is handled by the harness. Claude Code, Cursor, and Codex build their requests to hold the prefix stable and mark cache breakpoints, so a developer working inside one of them is already paying cached rates on a large share of their input.

So the best approach is to keep prefixes stable and to hold one model and provider while the cache is warm. A switch inside that window pays the full prefix write again. Once the window has expired there is nothing left to protect, and moving to a different model costs no more than continuing on the current one.

Output: Smart Model Routing

To address the output cost, the most viable approach is to select the most appropriate model for each task. This can be done by hand, or with a smart router that sits in front of a pool of models, evaluates each incoming request, and sends it to the model matched to what that request requires.

Databricks reports better than 30 percent average task cost reduction from request-level routing while roughly matching the quality of the most expensive model in its working set, and Kilo published about a third off average cost per request from its own Q1 2026 production traffic.

Not all routers are created equal. As we covered in our previous post, a router needs to do four things well:

Economy

The combined cost of running the router and the models it selects must land substantially below what the same traffic would have cost against a frontier model.

Latency

Routing happens before generation begins, so the routing decision must be faster than the fastest model in the pool, so that the router does not add perceptible latency.

Quality

Output quality from the routed system must match or exceed what sending every request to a single frontier model would have produced. A router that downgrades slightly too aggressively produces acceptable output on ordinary requests and degraded output on the difficult tail.

Durability

The router has to stay current as new models are released, and it has to do so without accumulating maintenance work that offsets what it saves.

Many of the common approaches and commercially available routers fail to meet at least one of these. Sansa's smart router, Sansa Auto, meets all four. Costs are marginal compared to savings, routing decisions are made in under 20ms, it beats all frontier models on benchmarks, and it is architected for continuous model additions so it is always serving the frontier of cost and performance.

Caching, subagents, and routing

A cache read costs a tenth of what a model charges for fresh input, so the cheaper the model, the cheaper the read. So when routing selects a less expensive model, the savings from prompt caching compound, as long as the router does not break prompt caching in the process.

Caches are scoped to a specific model and provider, so the two only stack when one model is used for the duration of the cache window. If a different model is selected at turn nine, and the cache is warm, the cache built up on the first model cannot be read by the second, and the accumulated context is written again at the new model's write rate. At current prices, on a trace with a 100,000-token prefix warm on Opus 5:

Action at turn nine Input cost for that turn
Continue on Opus 5, cache read at $0.50/M $0.050
Switch to Haiku 4.5, cache write at $1.25/M $0.125
Switch to Opus 5 from Haiku, cache write at $6.25/M $0.625

The saving therefore depends on the router keeping its own decision. A router that alternates pays a full prefix write on each change. Sansa Auto reads the cache key on the request. When one is present and the cache is still warm, we do not re-route the trace. When a cache has expired, that call is reevaluated and becomes eligible for re-routing when a different model can handle the task and cost less.

Subagents can further multiply savings from routing. A harness that lets an orchestrator delegate part of the work to a subagent creates a second trace, with its own prefix, its own cache, and its own routing decision. Many of the popular harnesses, Codex, Cursor, and OpenCode include subagents. Trivial work moves to a less expensive model. The subagent starts cold and pays a full prefix write on its first call, which is less costly than having a more expensive orchestrator do the same work. On high-output work the write is covered immediately: 50,000 tokens of generated file content costs $1.25 on Opus 5 and about a cent on a small model, against roughly $0.25 to write the prefix.

Example Session

Consider an hour-long session of 40 calls averaging 83,341 input and 11,949 output tokens per call:

Configuration Session cost Savings
Opus 5 pinned, no caching $28.62 0%
Add prompt caching $15.12 47%
Add routing across runs $0.25 99%

Caching removes the input side. What remains is mostly output, and output is what routing moves: Opus 5 charges $25 per million for it, against $0.32 for a mix weighted toward gpt-oss-120b and DeepSeek V4 Flash.

What you can do

  • Keep dynamic values out of CLAUDE.md, AGENTS.md, and rules files. A timestamp, a ticket ID, or a generated status line in a project instruction file sits above the stable block.
  • Leave the MCP server set alone once a session starts. Tool definitions sit at the front of the request, so a changed tool list is a new prefix and a cache miss.
  • Stop switching models by hand mid-session. /model and the model picker write the accumulated prefix again at the new model's rate.
  • Use a smart router to cut output spend. Sansa Auto sends each task to the model matched to it, so frontier output rates are paid on the work that needs them.
  • Use a router that respects the cache. Sansa Auto does not re-route mid trace while the cache is warm, unlike Cursor Router, which documents that the model can vary between turns.

Key takeaways

  • Most tokens in a coding session are input, but output costs two to five times more per token, so a coding bill has two separate axes: the price paid for high-volume input, and the rate paid to generate responses.
  • Prompt caching is the lever on input. It works only on a byte-identical prefix, and a single dynamic value placed above the stable block can take a measured hit rate from 98.7 percent to 0.7 percent.
  • The cache window is shorter than it looks. Anthropic's default runs five minutes from the start of the request, so a call that generates for four minutes leaves about one minute for the next one to land warm.
  • Routing is the lever on output. Once caching has removed the input side, what remains is mostly output, and output is priced by whichever model answered.
  • A cache is scoped to one model, so the two compound only while one model holds the trace. After the window expires there is no warm prefix left to protect, and re-routing costs nothing.
  • Subagents create a second trace with its own prefix, cache, and routing decision, which moves generation onto a cheaper model without switching models inside a warm trace.

Frequently asked questions

Why do AI coding costs rise while token prices fall?

Consumption grows faster than unit price falls. Requesty's gateway data shows per-call cost holding flat across twelve months while spend per active user rose 3.8x, driven by call volume.

How much does prompt caching save on a coding agent?

Published measurements run from 41 to 80 percent across models on long-horizon agentic tasks, with a production report of 59 percent on a full agent bill. The result depends on prefix stability, session depth, and how much time passes between turns.

What does switching models mid-session cost?

The accumulated prefix bills at the new model's cache write rate, since caches are scoped to a specific model. At current prices on a 100,000-token prefix, switching to Haiku 4.5 costs $0.125 against $0.050 for a cache read on Opus 5, and switching up to Opus 5 costs $0.625. A switch repays itself only if enough turns remain on the new model before the cache expires.

How much does routing save on agentic coding?

From 30 to 99% depending on the router, base model being compared to, and the harness. Sansa Auto regularly achieves 80%+ cost savings without reducing performance.

#ai-coding#cost-optimization#prompt-caching#model-routing#coding-agents#llm-costs#agentic-coding

One backend
for better AI