Cut Claude Agent Token Cost: Caching, Batching, Speed

An agent that works but costs three dollars per run and takes ninety seconds is a prototype, not a product. The gap between a demo and something you can put in front of thousands of users is almost entirely a cost-and-latency story. The good news is that agent economics are highly tunable: most of the spend in a typical Claude agent goes to re-reading the same tokens over and over, and most of the latency comes from doing serially what could be done in parallel. This post is about squeezing both out without quietly degrading quality.

Where the money actually goes

Before optimizing anything, instrument the run. For each step, record input tokens, output tokens, which model handled it, and wall-clock time. When teams do this for the first time they are usually surprised: the expensive part is rarely the model's clever reasoning. It is the giant, unchanging preamble — system prompt, tool definitions, retrieved documents, and the entire growing conversation history — that gets re-sent on every single turn. In a ten-step agent loop, a 20,000-token preamble is paid for ten times. That repetition, not intelligence, is your bill.

Output tokens cost several times more than input tokens, so verbose agents are doubly expensive. If your agent narrates every thought in long prose, you pay a premium for prose nobody reads. The two biggest levers, then, are obvious once measured: stop paying for the same input repeatedly, and stop generating output you do not need.

Prompt caching: stop paying for the same tokens

Prompt caching is the highest-leverage optimization available to Claude agents, and it directly attacks the repetition problem. You mark a stable prefix of your request — system prompt, tool schemas, long static context — and on subsequent calls the model reuses that cached prefix at a steep discount instead of reprocessing it. Cache reads typically cost a small fraction of normal input tokens, so a stable 20,000-token preamble that you hit ten times goes from full price ten times to near-full price once and a token deal nine times.

The trick is ordering. Caching works on a prefix, so everything you want cached must come first and must be byte-identical between calls; anything that changes belongs after the cache breakpoint. Put your immovable instructions and tool definitions at the top, then your slowly-changing context, then the live conversation. A single reordered word in the prefix invalidates the cache and you pay full freight, so treat the cached region as frozen. Prompt caching is a feature that stores a stable prefix of the prompt so repeated requests reuse it at a reduced token cost.

flowchart TD
  A["Agent step starts"] --> B{"Prefix unchanged & cached?"}
  B -->|Yes| C["Reuse cache: pay fraction of input cost"]
  B -->|No| D["Process full prefix & write cache"]
  C --> E{"Many similar tasks queued?"}
  D --> E
  E -->|Yes, not urgent| F["Batch into one async job"]
  E -->|No, interactive| G["Route to right model by difficulty"]
  F --> H["Lower cost per task"]
  G --> H

Batching the work that doesn't need to be live

Not every agent task is interactive. Nightly enrichment, bulk classification, generating summaries for ten thousand records — these can run asynchronously. Batch processing trades immediacy for a meaningful discount: you submit a large set of requests as one job and collect results when ready, often at roughly half the per-token price of synchronous calls. The mental shift is to separate "a user is waiting" work from "a queue is waiting" work and push everything in the second bucket into batches.

Batching also unlocks parallelism in multi-agent designs. If an orchestrator needs five independent sub-investigations — say, researching five competitors — running them concurrently collapses five sequential latencies into roughly one. The caveat from the multi-agent literature holds: parallel subagents multiply token usage even as they cut wall-clock time, so reserve fan-out for tasks where the work genuinely decomposes and the speed is worth the spend. For a tightly sequential task, more agents just means more cost.

Compaction: keep the context window from bloating

Every tool result an agent reads stays in the window and gets re-sent on the next turn unless you intervene. A long run can balloon to hundreds of thousands of tokens, which is both slow and expensive — even with a 1M-token context, you do not want to pay to re-read a 500KB log forty times. Context compaction summarizes and prunes the history at natural boundaries: when a sub-task finishes, replace its verbose tool transcript with a tight summary of what was learned and what to do next.

Pair compaction with selective retrieval. Instead of dumping an entire file or API response into context, have the agent fetch only the slice it needs, or store large artifacts externally and pass a reference the model can re-open on demand. The discipline is to treat the context window as expensive working memory, not a junk drawer. Agents that stay lean stay fast, and they also stay smart — a tighter window reduces the context-rot problems that make long runs degrade.

Routing to the right model

Using your most capable model for every step is the most common waste in agent design. A practical pattern is tiered routing: a cheaper, faster model like Claude Haiku 4.5 handles classification, extraction, routing decisions, and simple tool calls, while a stronger model like Opus 4.8 is reserved for genuinely hard planning or synthesis. In an orchestrator–subagent system this maps cleanly — a capable orchestrator delegates well-scoped subtasks to cheaper workers. The result is that you pay top-tier prices only for the small fraction of steps that actually need top-tier reasoning, often cutting blended cost substantially with no visible quality loss.

Whatever you change, gate it behind an eval. Each optimization — a smaller model here, an aggressive compaction there — is a quality risk. Run your representative test suite before and after, watch the success rate alongside the cost, and only keep changes where the savings do not move quality. Cheap-and-wrong is more expensive than expensive-and-right, because it ships bad outcomes to users.

Frequently asked questions

What is the single biggest cost lever for a Claude agent?

Prompt caching. Most agent spend is re-sending an unchanging preamble — system prompt, tool schemas, static context — on every turn. Marking that prefix as cacheable lets the model reuse it at a fraction of the input cost, which often cuts the bill dramatically.

When should I use batch processing instead of live calls?

Whenever no user is actively waiting: nightly enrichment, bulk classification, large summarization jobs. Batch APIs typically run around half the synchronous per-token price in exchange for asynchronous, higher-throughput delivery.

Do multi-agent systems save money?

They save time, not money. Parallel subagents cut wall-clock latency but multiply token usage, so use fan-out only when the task genuinely decomposes into independent pieces and the speed justifies the extra spend.

How do I keep cost optimizations from hurting quality?

Gate every change behind an eval suite. Measure success rate and cost together before and after, and keep only the optimizations — model downgrades, compaction, routing — that preserve quality while reducing spend.

Making every call affordable and instant

CallSphere applies these same economics to voice and chat agents — cached prompts, tiered models, and lean context so an assistant can answer every call and message fast without runaway cost. 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.