How to Cut Your Claude API Bill: A Checklist for Caching, Batching and Routing

To cut your Claude API bill, work down this list in order: measure by token type, cap output, cache the stable prefix, route easy traffic to a smaller model, send anything nobody is waiting on through the Batch API, and put a spend cap on the whole thing. On a made-up but typical support workload, those steps took a computed $980 month down to about $139 in the best case, and I show exactly how below.

Two honest caveats before the numbers. First, every price here is from Anthropic's own pricing page, which I fetched on 2026-10-09; prices move, so rerun the script with fresh ones. Second, the workload is invented, so your percentages will differ. What transfers is the method and the traps. If you want the underlying formula first, read LLM API cost per 1,000 requests. This post is the order of operations.

What do the Claude prices look like today?

From the Anthropic pricing page on 2026-10-09, in dollars per million tokens (MTok):

Three details in that page change the arithmetic:

• Cache reads cost 0.05 times input on Opus 5.5 and Sonnet 5.5 (0.1 times on most others). A 5-minute write is 1.25 times input and a 1-hour write is 2 times.
• The Batch API takes 50 percent off both input and output. Fast mode is not available with it.
• Haiku 5.5 is priced by prompt length: over 100,000 tokens, its input price jumps to $0.50. Cache reads count toward that length.

One more line from the same page: Claude 4.7 and later models use a newer tokenizer that produces roughly 30 percent more tokens for the same text than the previous one. If you migrate from an older model, compare cost per task, not price per token.

Step 1: where does the money actually go?

Before changing anything, split one day of real traffic by token type. Every response has a usage block. Log input_tokens, cache_creation_input_tokens, cache_read_input_tokens and output_tokens per request, per feature. Anthropic's docs give the identity to use: total input is the sum of the three input-side fields.

Then ask four questions, because each maps to one lever:

If you are guessing instead of measuring, you will optimise the wrong line. The sibling post on token budgeting for agents covers the case where one runaway loop, not average traffic, is the problem.

Step 2: cap output before anything clever

Output costs 5 times input on every model in the table. It is also the cheapest thing to fix, because you control it with a parameter and a sentence in the prompt.

• Set max_tokens to what a good answer needs, not the model maximum.
• Ask for the format you will use: a label, a JSON object, three bullets.
• Lower reasoning effort for simple tasks. The effort parameter post explains the setting, though its model names are from the older generation.

In my script, trimming the average output from 300 to 225 tokens (a 25 percent cut, which is an assumption for the example) saved $75 a month on 100,000 Sonnet 5.5 requests. That is before any other lever, and it required no infrastructure.

Step 3: cache the stable prefix, but check your traffic first

Prompt caching reads a prefix of your request (tools, then system, then messages) back from cache at a fraction of the input price. Per Anthropic's caching docs, the rules that bite are:

• Minimum length. 512 tokens for Opus 5.5, Sonnet 5.5, Haiku 5.5 and several others; 1,024 for Sonnet 5 and Sonnet 4.6; 4,096 for Opus 4.6, Opus 4.5 and Haiku 4.5. Below the minimum nothing is cached and no error is returned.
• Lifetime. 5 minutes by default, refreshed each time the entry is used; 1 hour costs more to write.
• Prefix match. The breakpoint must sit at the end of text that is identical across requests. Put anything that varies (a timestamp, the user message, retrieved chunks) after it.

The docs also say a top-level cache_control field turns on automatic caching, which is the recommended starting point; older posts on this site, such as prompt caching for Claude, show the same idea with older model names and a flat 10 percent read price. On Sonnet 5.5 and Opus 5.5 the read price is 5 percent, per the pricing page today.

Now the part most guides skip: whether it pays depends on how often the prefix is reused before it expires. I simulated Poisson arrivals over a 30-day month with a fixed seed (7), a 3,000-token stable prefix, 400 variable input tokens and 300 output tokens, all on Sonnet 5.5. Real output:

1. Prompt caching (5-minute TTL), simulated Poisson arrivals, seed 7
   100,000 req/month (~1 every 26 s): no cache $980.00 | 5-min $410.01 (1 writes) | 1-hour $410.01 (1 writes)
   5,000 req/month (~1 every 8.6 min): no cache $49.00 | 5-min $40.24 (2741 writes) | 1-hour $20.54 (3 writes)
   1,000 req/month (~1 every 43 min): no cache $9.80 | 5-min $10.42 (878 writes) | 1-hour $6.94 (243 writes)

Read it carefully:

• At high volume, caching is the biggest single saving here: $980 down to $410, about 58 percent. The "1 write" is a simulation artefact. Real traffic has quiet nights, deploys that change the prefix, and cache misses, so treat this as a ceiling.
• At about one request every 8.6 minutes, the 5-minute cache saves roughly 18 percent but pays for 2,741 writes. The 1-hour cache saves 58 percent. The extra write cost is tiny when writes are rare.
• At one request every 43 minutes, the 5-minute cache costs more than no cache ($10.42 versus $9.80). That is the break-even trap. The 1-hour cache still wins, at $6.94.

The break-even table from the same run, for one 3,000-token prefix, in dollars per 1,000 prefixes:

   N= 1: no cache $  6.00 | 5-min write $  7.50 | 1-hour write $ 12.00
   N= 2: no cache $ 12.00 | 5-min write $  7.80 | 1-hour write $ 12.30
   N= 3: no cache $ 18.00 | 5-min write $  8.10 | 1-hour write $ 12.60
   N= 5: no cache $ 30.00 | 5-min write $  8.70 | 1-hour write $ 13.20
   N=10: no cache $ 60.00 | 5-min write $ 10.20 | 1-hour write $ 14.70

One use loses and two uses win for the 5-minute cache. The 1-hour write needs three uses to beat no cache (at two it is still $12.30 against $12.00), but it earns its keep when gaps between requests run past five minutes. The pricing page says the same in words: a 5-minute write pays off after one read, a 1-hour write after two.

The core of the simulator, in case you want to adapt it (the full file also prints the stacking table below):

import random

def simulate_cache_windows(n, hours, ttl_s, seed):
    rng = random.Random(seed)
    rate = n / (hours * 3600.0)
    t, last, writes, reads = 0.0, None, 0, 0
    for _ in range(n):
        t += rng.expovariate(rate)
        if last is not None and t - last < ttl_s:
            reads += 1          # hit refreshes the TTL
        else:
            writes += 1         # miss: pay the write price
        last = t
    return writes, reads

Confirm it in production, not in a spreadsheet. If cache_creation_input_tokens and cache_read_input_tokens are both 0, the docs say the prompt was probably under the model's minimum length.

Step 4: route easy traffic to a smaller model

Haiku 5.5 is priced at a twentieth of Sonnet 5.5 on input and output. If a share of your traffic is classification, extraction, or templated replies, it does not need the bigger model. The Haiku 5.5 page line in Anthropic's table describes it as the choice for classification, extraction and routing.

The savings are arithmetic. The quality is not. I assumed, without testing, that 60 percent of realtime traffic could go to Haiku 5.5 with the same token shape. That assumption decides everything. Before you route:

1. Label 100 to 200 real requests with the answer you want.
2. Run them through both models and score the cheap model per category.
3. Route only the categories where it passes, and count the router's own cost and error rate.

Choosing a model by routing and the LiteLLM and OpenRouter routing guide cover the mechanics.

Step 5: batch whatever nobody is waiting on

Per Anthropic's batch docs on 2026-10-09: a batch holds up to 100,000 requests or 256 MB, whichever comes first; most batches finish within an hour; results are available when all requests finish or after 24 hours, and batches expire if they do not complete in 24 hours; results stay downloadable for 29 days. Our older Batch API guide quotes a 10,000 request limit and older model names, so use the docs' numbers when they differ.

Two traps matter for cost:

• Cache hits inside batches are best-effort. Requests run concurrently and in any order. The caching docs suggest a 1-hour cache: send one request with the shared prefix first, wait for it, then submit the rest.
• You lose fast mode and streaming in a batch.

Now the stacking result. Same workload, 30 percent of requests moved to batch:

2. Stacking levers (steady traffic)
   caching only                                                $   410.01  ( 58.2% below baseline)
   caching on 70% realtime + 30% batch (no cache credit in batch) $   434.20  ( 55.7% below baseline)
   (best case, batch also gets cache hits: batch slice at 0.5 x cached) $   348.71  ( 64.4% below baseline)
   + route 60% of realtime to Haiku 5.5                        $   278.82  ( 71.5% below baseline)
   + the batch slice also on Haiku 5.5                         $   139.17  ( 85.8% below baseline)

The surprise: moving 30 percent of traffic to batch made the bill go up from $410 to $434, because those requests lost their cache hits and batch's 50 percent off the uncached price is not as cheap as a cache read at 5 percent. Batch only wins clearly when the prefix is not heavily reused, or when the cache hits still land. For a heavily cached workload, keep latency-tolerant work in the realtime path with caching, or accept best-effort hits and test the real hit rate.

Step 6: cap the spend itself

Every lever above lowers the expected cost. None stops the unexpected one. Set a monthly limit in the Anthropic Console, give each service its own key, and alert at half the cap. For loops that call the API repeatedly, add a per-task budget in code. The next post in this series, token budgeting for agents, has a guard I ran on a stub agent, and LiteLLM budgets and virtual keys do the same job at the gateway.

The checklist

Copy this into your repo and tick it off per service:

1. Logged usage by token type for one full day, per feature.
2. Output capped with max_tokens and a format instruction; average output measured before and after.
3. Stable text first, varying text last; no timestamps or request IDs before the cache breakpoint.
4. Prefix is above the model's minimum cacheable length (512 tokens on the 5.5 generation).
5. Chose 5-minute or 1-hour cache from your real gap between requests, not from habit.
6. Confirmed cache reads appear in usage in production.
7. Easy categories identified and tested on a smaller model with a labelled set.
8. Non-urgent jobs identified; batch cost computed with and without cache credit.
9. Tokenizer change considered if you moved to a 4.7 or later model.
10. Spend limit set, alert at 50 percent, one key per service.

What I did not verify

I did not call the Claude API in this session, so the savings are computed from published prices and a simulated traffic pattern, not billed. The routing quality assumption is untested. Anthropic's pages were read from the docs HTML; where a rate or limit matters to you, open the pricing page, the prompt caching docs and the batch docs yourself. Other vendors have their own discounts and thresholds, which I did not check here.