Which saves more, prompt caching or the batch API?

It depends on whether your workload is interactive. Batch APIs typically cut cost about 50% on both input and output but require you to tolerate delayed results, so they are unusable for anything a user is waiting on. Prompt caching cuts only the repeated input portion, but it applies to live traffic — and the discount is steep, typically 0.1x the input rate on Anthropic models and as low as 0.025x on Claude Fable 5.1 as of September 2026. For a chat or agent product, caching is usually the larger real-world saving because batch is simply unavailable.

Does context compaction save money?

Yes, and it is the only lever that reduces tokens rather than repricing them — but it works against caching. Compaction rewrites conversation history into a shorter summary, which cuts input tokens permanently. The catch is that changing the prefix invalidates your cache, so every compaction forces a cache write at full price or above. Compact when a conversation would otherwise exceed context or when the cached prefix has grown large enough that even discounted reads dominate the bill.

Why is my bill high when my prompts are short?

Almost always because of repetition, not length. In a multi-turn agent loop the system prompt, tool schemas and file context are re-sent on every single turn, so a 20,000-token prefix over 30 turns is 600,000 input tokens for one task. The fix is prompt caching, which prices those re-reads at a fraction of the base rate. Teams routinely chase a cheaper model when the actual problem is an uncached prefix.

What order should I apply these in?

Measure first, then cache, then batch what can tolerate delay, then compact. Caching usually delivers the biggest saving for the least behavioural change, and it does not alter output quality at all. Batch is a large win but only for asynchronous work. Compaction changes what the model can see, so it carries a real quality risk and belongs last.

Quick Answer

Prompt Cache vs Batch API vs Compaction: Cut LLM Costs

Published: September 2, 2026

The Short Answer

Three levers exist for cutting LLM API spend without switching to a weaker model. They work on different parts of the bill:

Prompt caching — repriced repeated input. Applies to live traffic. Typically 0.1x the input rate.
Batch API — repriced everything, in exchange for latency. Typically ~50% off.
Context compaction — fewer tokens outright. The only lever that shrinks the workload rather than discounting it.

Most teams downgrade their model first. That is usually the worst available option, because it trades quality for savings when two of the three levers above cost no quality at all.

Last verified: September 2, 2026.

Side by Side

	Prompt caching	Batch API	Compaction
What it changes	Price of repeated input	Price of everything	Token count
Typical saving	0.1x on cache hits	~50%	Varies (30-80% of history)
Works on live traffic?	Yes	No	Yes
Latency cost	None (usually faster)	Hours	Small (summarisation call)
Quality risk	None	None	Real — information is discarded
Best for	Agents, chat, long system prompts	Evals, bulk classification, offline jobs	Long conversations near context limit
Interacts badly with	Compaction (invalidates cache)	Anything user-facing	Caching (invalidates prefix)

Prompt Caching: The Default Answer

Caching stores a prefix of your prompt server-side so repeat requests re-read it at a discount instead of reprocessing it.

Why it matters more than it looks: agent workloads are structurally repetitive. A coding agent re-sends its system prompt, tool definitions and file context on every turn. Across a 30-turn session, a 20,000-token prefix becomes 600,000 input tokens — one task, six hundred thousand tokens, almost all of it identical.

The economics as of September 2026:

Anthropic models generally price a cache hit at 0.1x the input rate, with a 5-minute cache write at 1.25x and a 1-hour write at 2x.
Claude Fable 5.1, released September 1, 2026, prices cache reads at 0.025x — $0.25 per MTok against a $10 input rate, a 75% cut versus Fable 5 and the lowest cache-read multiplier in the Claude line.
Cache writes cost more than normal input, which is the trap: caching a prefix you read once is a loss.

The break-even rule: with a 1.25x write and 0.1x read, you profit from the second read onward. Cache anything read twice; never cache a one-shot prompt.

Structural requirement: the cached portion must be a stable prefix. Put the system prompt, tool schemas and static context first, and put anything that changes per request — user message, timestamp, retrieved chunks — last. A single changed token near the front invalidates everything after it. This is the most common implementation mistake and it silently turns a caching strategy into a pure cost increase.

Batch API: Large Savings, Narrow Window

Batch endpoints accept a job, process it when capacity allows, and return results later — typically at around 50% off both input and output. On Claude Opus 5, for example, batch rates run $2.50/$12.50 against the standard $5/$25.

Where it wins outright: eval suites, bulk classification and tagging, embedding generation, offline content processing, dataset labelling, nightly report generation. Anything where the result is consumed by a process rather than a person.

Where it is useless: anything a human is waiting on. There is no partial credit here — a 50% discount is worth nothing if the product requires an answer in two seconds.

The under-used case: running your eval suite. Teams often skip comprehensive evals because running them across many test cases is expensive, then discover regressions in production. Evals are the ideal batch workload — fully asynchronous, high volume, and precisely the thing you should be doing more of. Halving their cost is how you justify running them on every change.

Compaction: The One With Real Risk

Compaction replaces accumulated conversation history with a shorter summary. It is the only lever that reduces actual token count.

The tension nobody mentions: compaction and caching fight each other. Caching depends on a stable prefix; compaction rewrites the prefix. Every compaction event invalidates the cache and forces a full-price write. Compact too eagerly with caching enabled and you can increase spend.

The workable policy is threshold-based rather than periodic:

Compact when approaching the context limit — at that point it is mandatory, not an optimisation.
Compact when the cached prefix has grown large enough that even discounted reads dominate the bill.
Do not compact on a fixed turn count. That guarantees cache invalidation on a schedule regardless of whether it saves anything.

The quality risk is genuine. Summarisation discards information, and you cannot reliably predict which discarded detail the model needed on turn 40. Preserve decisions, constraints and file state verbatim; summarise the narrative around them.

The Order to Apply Them

Measure. Split spend into input, output and cache categories. Most teams cannot answer “what fraction of my input tokens are repeated?” — and that single number determines everything else.
Cache. Biggest win, no quality cost, no latency cost. Restructure prompts so static content sits in a stable prefix.
Batch everything asynchronous, starting with evals.
Compact only at real thresholds, tuned against cache behaviour.
Only then consider a cheaper model — and validate the switch with the evals you can now afford to run.

The reason this order matters: steps 2 through 4 change your bill without changing your output. Step 5 changes your product. Exhaust the free options before spending quality.