Research-backed calculator guide

Claude Message Batches Prompt Cache TTL Break-Even Calculator

Calculate when Claude Message Batches, 5-minute caching, or 1-hour prompt caching is cheapest by combining TTL survival, cache hit rate, token mix, and batch pricing.

What the calculator should compare

The calculator’s unit is one model run, not a monthly bill. Multiply the result by the number of requests in your workload after you have chosen a realistic batch window and cache-survival assumption. The formula uses USD per million tokens (MTok), matching the pricing pages checked on 2026-11-02. Prices are vendor list prices, not an invoice quote, and they can change.

Start with these inputs:

• Requests: total requests in the batch or comparison period.
• Shared prefix tokens: stable tools, system instructions, examples, or documents placed before the cache breakpoint.
• Unique input tokens per request: the changing user or document portion after the shared prefix.
• Output tokens per request: the generated response counted for billing.
• 5-minute hit rate and 1-hour hit rate: the fraction of eligible repeated prefixes that are read from cache rather than written again or charged as ordinary input.
• Model rates: base input, 5-minute write, 1-hour write, cache read, and output rates in dollars per MTok.
• Batch factor: 0.5 for the documented 50% Message Batches price, or 1.0 for a synchronous comparison.

Anthropic describes prompt caching as covering the full prefix in order through the block marked with cache_control. A cache read is not the same meter as ordinary input, and a cache write is not free. ^[2] Keeping those meters separate prevents the common mistake of multiplying only the base input line by a discount while leaving writes, reads, or output out of the estimate.

A compact comparison model is:

ordinary_input_cost = requests × unique_input_MTok × base_input_rate
output_cost         = requests × output_MTok × output_rate

cache_cost =
  first_prefix_MTok × selected_write_rate
  + cache_hits × prefix_MTok × cache_read_rate
  + cache_misses × prefix_MTok × base_input_rate
  + ordinary_input_cost
  + output_cost

batch_total = cache_cost × batch_factor

The first prefix write is shown explicitly. If your application warms a cache outside the measured period, include that warm-up cost in the period that paid for it rather than silently dropping it. If every request is a miss, do not call the shared prefix “cached” in the estimate: it is ordinary input after the write attempt fails or the entry expires.

Worked cost example

Assume a Claude Sonnet 5.5 workload with 100 requests. Each request contains a 100,000-token stable prefix, 2,000 changing input tokens, and 500 output tokens. The example uses the USD rates shown on Anthropic’s pricing documentation as checked on 2026-11-02: $2 per MTok for base input, $4 per MTok for a 1-hour cache write, $0.10 per MTok for a cache read, and $10 per MTok for output. ^[3] These are list-price assumptions. They do not include taxes, account-specific terms, regional multipliers, retries, failed items, tool charges, or application infrastructure.

Assume the first request writes the 1-hour prefix. Of the remaining 99 requests, 80 are cache hits and 19 are misses. Batch is used for all 100 requests, so every applicable token charge is multiplied by 0.5.

This result is an original calculation from the stated inputs. It is not a quote from Anthropic and it is not a promise of a $2.95 invoice. Relative to the $20.90 real-time baseline, Batch alone saves $10.45 in this small workload, while the assumed Batch-plus-cache case saves $17.95. The comparison is useful because it shows where the saving comes from: the 50% Batch factor applies broadly, while the cache changes the price of the repeated 100,000-token prefix from repeated base input to one write, 80 reads, and 19 ordinary-input misses.

The hit-rate convention matters. If you instead define an 80% hit rate across all 100 requests, use 80 hits and 19 misses only if the first write is counted separately and the remaining request count is rounded for presentation. A production worksheet should use integer request events, or retain fractional expected values and label them as an estimate. If the hit rate is 80% of the 99 follow-up requests, the expected cost is $3.03 after rounding, not $2.95. That difference is small here, but it demonstrates why the worksheet should document its denominator.

5-minute versus 1-hour TTL break-even

The 5-minute write is cheaper than the 1-hour write. For a model with a 1.25× 5-minute write, a 2× 1-hour write, and a 0.1× read, compare the two TTLs on the same prefix. Let k be the number of follow-up opportunities after the first write, h5 the number of 5-minute hits, and h1 the number of 1-hour hits. In units of the base input price for one prefix, the costs are:

5-minute: k + 1.25 - 0.90 × h5
1-hour:   k + 2.00 - 0.90 × h1

The 1-hour option is cheaper when:

0.90 × (h1 - h5) > 0.75

In other words, the 1-hour TTL needs more than 0.8333 additional hits per prefix-equivalent under the simple one-prefix model if the units are interpreted as one hit opportunity; with a normalized hit-rate comparison over many requests, the extra hit share needed is 0.75 / 1.90 = 39.47% of the opportunities that would otherwise be misses. The second expression is the practical rate comparison: each 1-hour hit replacing an ordinary-input miss saves 0.9 base-price units, and the longer write costs 0.75 extra units.

This is why cadence matters more than the label “1 hour.” If a stable prefix is used repeatedly within five minutes, the 5-minute cache can refresh without paying the more expensive 1-hour write. Anthropic positions the 1-hour option for prompts used less often than every five minutes but more often than every hour, or when a follow-up may arrive after five minutes. ^[2] For a Batch workload, the longer window may be operationally sensible because requests do not run in your preferred order, but the hit rate remains best effort. ^[1]

Use two hit-rate columns rather than one blended guess. Estimate h5 from the cadence you would get with a five-minute TTL and h1 from the cadence and batch processing shape you expect with a one-hour TTL. If the observed improvement is less than the break-even threshold, choose 5-minute caching or no caching. If the improvement is larger, include the 1-hour write premium and verify that the workload can wait for Batch.

How to apply the model to a real workload

First, stabilize the prefix. Put repeated tools, system instructions, examples, and durable reference material before the cache breakpoint. Keep the block identical across requests. Small changes to the prefix, a changed tool definition, or a changed ordering can turn the supposed hit into a write or ordinary input charge. The exact cache boundary and usage fields should be checked against the current prompt-caching documentation before implementation. ^[2]

Second, separate synchronous and asynchronous traffic. Make one scenario with a batch factor of 0.5 and another with a factor of 1.0. The batch scenario is valid only when users, downstream jobs, or an SLA can tolerate asynchronous completion. Anthropic says batches can take up to 24 hours and may expire if they do not complete; many finish sooner, but “most finish within an hour” is not a guarantee. ^[1] Do not convert a latency requirement into an assumed average.

Third, log the billing meters. The prompt-caching response example exposes cache_creation_input_tokens, cache_read_input_tokens, and input_tokens, with cache creation broken down by TTL. ^[2] Store those fields with the request ID, model, batch ID, and cache-control version. Compute an observed hit ratio from reads and writes using one documented denominator. Compare expected and observed values by batch rather than replacing the estimate with one monthly average.

Fourth, model retries and failures as separate rows. A failed request can still affect your usage depending on where it failed and whether it was retried. Batch results are itemized, and request order is not a safe cost-allocation key. Allocate costs by custom ID or another stable request identifier, then reconcile total token meters to the provider usage export.

For a broader model-rate comparison, use the model pricing comparison page. To normalize input and output token volumes before applying Claude rates, use the AI token cost calculator. If the question expands from one batch to monthly agent traffic, the LLM cost calculator can carry the per-run estimate into a workload model. These tools answer different layers of the same budgeting problem; none removes the need to validate actual cache survival.

Common decision rules and limitations

Choose Batch only when the prefix is not repeated, when cache hits are too uncertain, or when the workload is large but mostly unique. You still receive the documented asynchronous price reduction without paying a cache-write premium.

Choose 5-minute caching plus Batch when requests share a stable prefix and the cadence is dense enough to refresh the cache. This is often the conservative cache case because the write multiplier is lower. It still depends on enough repeat traffic and identical cache blocks.

Choose 1-hour caching plus Batch when the batch’s timing and ordering would otherwise push repeated requests outside five minutes, and when measured or scenario-tested extra hits exceed the write premium. Treat the hit rate as a range, not a guaranteed 98% outcome. Anthropic describes batch cache hits as typically ranging from 30% to 98% depending on traffic patterns, which is evidence for scenario analysis rather than a forecast for your workload. ^[1]

Choose real-time caching when a person or interactive agent is waiting for each response. The cache decision can still reduce repeated-prefix input cost, but the batch factor should be 1.0. Conversely, do not select Batch merely because the arithmetic is cheaper if a 24-hour tail would violate the product requirement.

The calculator excludes taxes, currency conversion, account-level discounts, platform pass-through fees, tool-specific charges, embeddings, storage, network costs, developer time, and the value of delayed results. It also assumes the model and price schedule remain unchanged during the measured period. Update the rates when Anthropic changes the pricing page, and show the checked date beside any saved estimate.

FAQ

Does Claude Batch automatically make prompt caching cheaper?

No. Batch applies a 50% usage factor, while prompt caching changes the price of the repeated prefix through a write and read schedule. Anthropic states that the discounts can stack, but the cache hit is best effort inside asynchronous batches. ^[1] If most prefixes miss or expire, Batch may be the clearer saving. Compare Batch-only with Batch-plus-cache using your expected hit rate.

Is the 1-hour cache always better for a batch?

No. The 1-hour write costs more than the 5-minute write. It becomes attractive when it produces enough additional cache reads after five minutes to offset that premium. The answer depends on request cadence, batch ordering, prefix identity, and the observed hit rate. Use separate 5-minute and 1-hour scenarios instead of assuming every batch needs the longer TTL.

What tokens should be counted as cache reads?

Count only the prefix tokens actually returned as cached in the provider usage fields. Changing input after the cache breakpoint remains ordinary input, and a miss for the shared prefix should be charged at the base input rate in the estimate. Do not classify all input tokens as cached just because one block has cache_control.

Can I use Batch for an interactive Claude feature to get the discount?

Usually not. Message Batches are asynchronous and can take up to 24 hours, even though many finish sooner. ^[1] If a user, agent step, or synchronous API request is blocked on the answer, model it as real time. Batch is better suited to backfills, evaluations, enrichment, classification, and other work with a deadline rather than an immediate response requirement.

How should I budget an uncertain cache hit rate?

Create at least three cases: a low-hit case, a planning case based on observed logs, and a high-hit sensitivity case. Keep the hit-rate range visibly labeled as an assumption. Do not copy a published range into your forecast without testing your own workload. Record cache writes, cache reads, ordinary input, output, model, and TTL per request so the estimate can be replaced with measured usage.