Cutting Claude agent costs: caching, batching, cheaper runs

Every founder building on Claude eventually has the same uncomfortable meeting: the agent works beautifully, users love it, and the inference bill is growing faster than revenue. Agent runs are token-hungry by nature — each turn re-sends the whole conversation, tool results pile up, and a multi-agent system can quietly use several times the tokens of a single agent. The good news is that agent cost is mostly an engineering problem, not a pricing problem, and the same optimizations that cut cost usually cut latency too.

This is the playbook we use to keep runs cheap and fast without dumbing the agent down. None of it is exotic; all of it compounds.

Where the tokens actually go

Before optimizing, instrument. The biggest mistake teams make is optimizing the wrong thing — trimming a system prompt by 200 tokens while a single tool dumps 40,000 tokens of raw JSON into context on every call. Log input and output tokens per turn, per tool, and per run. Once you can see the distribution, the expensive offenders are obvious: oversized tool results, redundant context re-sent every turn, and unnecessarily capable models doing trivial work.

A useful mental model: in an agent loop, your input tokens grow roughly quadratically with conversation length because each turn re-sends everything before it. That's why a 20-turn agent run can cost far more than 20 times a single turn. Controlling context growth is therefore the highest-leverage cost lever you have.

Prompt caching is the cheapest win you're not using

Anthropic's prompt caching lets you mark a stable prefix of your request so Claude reuses the computed representation instead of reprocessing it. Prompt caching is a feature that stores the processed form of a repeated prompt prefix so subsequent requests skip re-encoding it, cutting both cost and latency on the cached portion dramatically. For agents this is transformational, because the system prompt, tool definitions, and skill instructions are identical across every turn of a run — exactly the stable prefix caching is built for.

The trick is structuring your messages so the cacheable part comes first and stays byte-identical: system prompt, then tool schemas, then any long reference documents, then the volatile conversation. If you interleave changing content into your prefix, you invalidate the cache and pay full price. Order your context for cacheability deliberately, and the savings on a long-running agent are immediate.

flowchart TD
  A["Incoming agent turn"] --> B{"Stable prefix cached?"}
  B -->|Yes| C["Reuse cached prefix"]
  B -->|No| D["Encode prefix & write cache"]
  C --> E{"Task simple?"}
  D --> E
  E -->|Yes| F["Route to Haiku"]
  E -->|No| G["Route to Sonnet/Opus"]
  F --> H["Trim tool results & respond"]
  G --> H

The flow shows the two decisions that drive most savings: cache the stable prefix, then route by task difficulty before generating. Both happen on every turn.

Batch the work that doesn't need to be live

Not every Claude call needs an answer in two seconds. Overnight enrichment, bulk classification, evaluation runs, and content generation are all latency-tolerant. Anthropic's Message Batches API processes large volumes asynchronously at a substantial discount versus real-time calls. The pattern for an AI-native startup is to split your workload into two lanes: interactive (cheap-but-fast caching, smaller models) and batch (maximum discount, run on a schedule). Moving even a third of your volume into the batch lane can reshape your unit economics.

Batching also forces a healthy architectural habit: separating the synchronous conversation from asynchronous heavy lifting. The live agent decides what needs doing; a batch job does the bulk processing later. That separation makes the system both cheaper and more resilient.

Right-size the model for the job

Using Opus for everything is like hiring a principal engineer to reset passwords. Claude's model family — Opus 4.8, Sonnet 4.6, Haiku 4.5 — exists precisely so you can match capability to task. Route classification, formatting, extraction, and routing decisions to Haiku; reserve Sonnet and Opus for genuine reasoning, planning, and ambiguous judgment. In an agent, this often means a cheap model triages each turn and only escalates the hard ones.

Model routing pays off twice: Haiku is both cheaper per token and faster, so trivial turns get cheaper and snappier. The engineering cost is a small router — a quick heuristic or a tiny model call that decides which tier handles the next step. Build it once and it pays rent forever. Measure quality per tier so you can push more traffic down to Haiku without users noticing.

Trim context like your bill depends on it

It does. The largest avoidable cost in most agents is bloated tool results sitting in context. A database tool that returns full rows when the model needs three fields, a web-fetch tool that dumps an entire HTML page, a file reader that returns 5,000 lines when 50 were relevant — each of those payloads then rides along in every subsequent turn. Summarize, paginate, or filter tool outputs before they enter the conversation. Return the answer, not the haystack.

For long-running agents, also compact the history. Once a sub-task is complete, replace its verbose turn-by-turn exchange with a short summary of the outcome. Claude Code and the Agent SDK support this kind of context management, and it keeps the quadratic growth of conversation tokens in check. The goal is a context window that holds what the model needs to act, and nothing it doesn't.

Set budgets and watch for cost regressions

Treat tokens like any other production resource: set per-run budgets, alert on outliers, and track cost-per-task as a first-class metric. A prompt change that quietly doubles average run length is a cost regression even if quality is unchanged — and you'll only catch it if you're watching. Wire token-cost dashboards next to your latency and error dashboards so cost is visible to the whole team, not just whoever opens the billing console.

Frequently asked questions

Does prompt caching change the model's answers?

No. Caching reuses the processed representation of an identical prefix; the model behaves exactly as if it had reprocessed it. You only get the cache hit when the prefix is byte-for-byte the same, so structure your requests with the stable content first.

When should I use the Batches API instead of real-time calls?

Whenever the result isn't needed immediately — bulk classification, enrichment, evals, and content generation are ideal. You trade latency for a meaningful discount, so move every latency-tolerant workload into the batch lane and keep real-time calls for interactive moments.

Is multi-agent always more expensive?

Generally yes — multiple agents coordinating use several times the tokens of a single agent because of duplicated context and inter-agent messages. Use multi-agent when the parallelism or specialization genuinely pays off, and keep simpler tasks single-agent to control cost.

What's the single biggest lever for cutting agent cost?

Controlling context growth. Because each turn re-sends the conversation, trimming tool results and compacting history attacks the quadratic cost directly. Pair that with prompt caching of the stable prefix and you've addressed the two largest line items.

Bringing agentic AI to your phone lines

Keeping runs cheap and fast is exactly what makes real-time voice viable. CallSphere applies these agentic-AI cost patterns — caching, model routing, and tight context — to voice and chat agents that answer every call and message and book work 24/7. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.