Amazon Bedrock Prompt Caching: When Does It Pay Off?

Amazon Bedrock prompt caching pays off when successful reuse of a stable prompt prefix saves more than creating that cache costs. The useful question is how much of your traffic reuses the same content before it expires, and how much of your bill that content represents.

For the Claude pricing ratios used below, one write followed by one cache hit makes a five-minute cache cheaper than sending the same prefix twice at the standard input rate. A one-hour cache needs two subsequent hits to beat that baseline. Those are calculated break-even points under specific assumptions, not guaranteed savings.

This guide focuses on explicit caching for Claude Sonnet 4.5/4.6 using on-demand inference through Bedrock's Converse API. Other models can have different eligibility and prices. Start with the calculation, then check it against your workload.

Price the reusable prefix first

A reusable prefix might be a document that stays unchanged while users ask different questions about it. The question itself still adds input, and the model still generates output. A large discount on the cached document therefore does not describe the entire request bill.

AWS's prompt-caching walkthrough supplies these example ratios relative to standard input pricing:

Processing the same prefix	Cost multiplier
Standard input	1.00×
First cache write, five-minute TTL	1.25×
First cache write, one-hour TTL	2.00×
Successful cache read	0.10×

TTL means time to live. Treat these ratios as the assumptions for the examples, then substitute the Bedrock prices for your model, Region and inference configuration. Do not apply them to every model or import another platform's dollar prices into an AWS estimate.

Calculate how many uses repay the write

Let B be what one unchanged prefix would cost at the standard input rate. Let N be the total number of times you use it, including the request that creates the cache. Let w be the write multiplier and r the read multiplier.

If the first request writes the prefix and every later request hits that cache:

Standard-prefix cost = N × B
Cached-prefix cost   = B × [w + (N − 1) × r]
Prefix saving        = 1 − [w + (N − 1) × r] / N

With a read multiplier below 1, caching beats the baseline when:

N > (w − r) / (1 − r)

The resulting comparison is small enough to use without a spreadsheet. Each baseline prefix use costs one unit; these are calculated examples, not measurements.

Total uses of the same prefix	Standard cost	Five-minute cache cost	Five-minute saving	One-hour cache cost	One-hour saving
1	1.00	1.25	−25.0%	2.00	−100.0%
2	2.00	1.35	32.5%	2.10	−5.0%
3	3.00	1.45	51.7%	2.20	26.7%
10	10.00	2.15	78.5%	2.90	71.0%

A negative saving means an extra cost. Ten uses produce a 78.5% reduction for the fixed prefix under the five-minute assumptions: one 1.25-unit write plus nine 0.10-unit reads, compared with ten standard units.

The table's most important assumption is one write. If your ten requests create ten different prefixes, or keep arriving after expiration, use the observed write and read counts instead. Repeated calls alone do not establish reuse.

Translate prefix savings into bill savings

Suppose, as a hypothetical example, the repeated prefix accounts for 60% of your original token bill. If it becomes 78.5% cheaper and every other cost remains unchanged, the whole token bill falls by:

60% × 78.5% = 47.1%

That calculation leaves uncached input and output in the bill. It also assumes the same number of requests and unchanged costs outside the prefix. If you change output lengths, models or traffic at the same time, compare those changes separately. The caching discount cannot explain the entire difference.

Choose the TTL from the gaps between requests

A successful cache hit refreshes the TTL. Frequent reuse can therefore keep a five-minute cache useful throughout a session longer than five minutes. Claude's cache-duration guidance recommends evaluating one-hour retention for gaps that exceed five minutes but remain within an hour. Longer-TTL checkpoints must precede shorter-TTL checkpoints when both appear in one request.

Two hypothetical schedules show why counting questions is insufficient:

• Ten questions, three minutes apart: if all nine follow-up requests hit, the first table applies. Five-minute retention has the lower write cost.
• Six questions, ten minutes apart: assume five-minute entries expire between requests, while the one-hour entry survives and all five follow-ups hit. Five-minute caching costs six writes, or 7.50 prefix units. One-hour caching costs one write plus five reads, or 2.50 units. The uncached baseline costs 6.00 units.

Under that second schedule, one-hour caching saves 58.3% of prefix cost against the uncached baseline; repeatedly recreating a five-minute entry costs 25% more. These figures depend on the specified hits and misses. They are not predictions about an account's cache behavior.

Your request pattern	Sensible first evaluation
Same eligible prefix, reliably reused within five minutes	Start with the five-minute option and measure reads.
Same prefix, repeated gaps above five minutes but below an hour	Compare one-hour writes with the five-minute rewrites they could avoid.
Little reuse of the chosen prefix	Do not assume a cache-write premium will be recovered.
Some content changes frequently while another prefix stays stable	Test a boundary that preserves the genuinely reusable portion.
Token cost falls, but the request's latency target still fails	Treat latency as a separate acceptance condition.

For an initial experiment, use one TTL. Mixed-duration caching adds a second write price and makes the result harder to diagnose.

Check eligibility before interpreting a miss

The current AWS caching guide lists a 1,024-token minimum per checkpoint for Sonnet 4.5 and 4.6. Check the actual model entry rather than assuming that threshold applies across Claude versions.

Below the minimum, inference can still succeed without caching the prefix. An accepted request is consequently not proof of a cache hit. AWS also notes that eligible requests are not guaranteed to hit, and cross-Region inference can increase cache writes. Prompt caching is supported only on on-demand inference endpoints, not through Bedrock's batch inference API.

Put stable content before the cache boundary and changing content after it. This illustrative Converse message fragment shows the boundary; the document placeholder must be replaced with real content meeting your model's threshold:

{
  "role": "user",
  "content": [
    {"text": "<your unchanged document>"},
    {"cachePoint": {"type": "default", "ttl": "5m"}},
    {"text": "<the question that changes between requests>"}
  ]
}

This is a message fragment, not a complete runnable request. The Converse reference shows the surrounding messages array and modelId parameter. The CachePointBlock schema defines type and ttl. Select a supported model or inference profile, confirm access, and use an SDK version that accepts the fields before trying it in your environment.

If a request fails validation, resolve the model, field or SDK mismatch first. A failed request gives you no successful-cache observation. If it succeeds without cache reads, inspect eligibility, prefix stability, timing and routing before declaring the feature ineffective.

Turn response usage into a cost worksheet

For Converse caching, AWS's response guidance distinguishes standard input from cache reads and writes: inputTokens contains the non-cached portion, not all the input you sent. Add the three input categories to reconstruct total input; do not price that sum at the standard rate and then add caching charges again.

Worksheet quantity	Response field	Rate to apply
I: standard input	usage.inputTokens	Standard input
R: cached input read	usage.cacheReadInputTokens	Cache read
W5 / W60: input written for each TTL	usage.cacheWriteInputTokens for a known single TTL; usage.cacheDetails for its TTL breakdown	Five-minute / one-hour write respectively
O: generated output	usage.outputTokens	Output

The TokenUsage schema makes the cache fields optional. Keep a missing field as unknown until you confirm the response format. A request can also have both reads and writes, so record token quantities rather than forcing each real request into a single hit/miss label. Streaming calls expose these observations in the ConverseStream metadata event.

For mixed TTLs, each CacheDetail has a ttl and nested inputTokens for writes at that duration. These nested counts split the aggregate write count; they are not additional standard input or another charge on top of it. Reconcile their sum with cacheWriteInputTokens before pricing the breakdown. If it is missing or inconsistent, resolve the observation rather than guessing a write rate.

Copy the applicable model, Region, inference configuration and rate-card date beside your totals. With prices P expressed per million tokens, calculate each group of requests sharing those rates as:

Token cost = (I × P_input + R × P_read
              + W5 × P_write5 + W60 × P_write60
              + O × P_output) / 1,000,000

All-standard counterfactual = ((I + R + W5 + W60) × P_input
                              + O × P_output) / 1,000,000

Saving = 1 − Token cost / All-standard counterfactual

Calculate a percentage only when the baseline is positive. This counterfactual reprices the same input and output quantities; it is not a measured no-cache run, a complete account bill, or evidence of lower latency. For a measured baseline, use comparable requests and confirm no cache reads or writes in the usage. Omitting explicit cache controls alone does not prove that caching was absent.

Worked example: hits, expiry, and a changed document

Consider a synthetic six-request trace, not an AWS capture. Each request has a 4,000-token prefix, 200 other input tokens and 300 output tokens. Use a five-minute TTL. Assume the exact outcomes below; document B has no reusable cached prefix from A. Real routing or partial reuse can produce different counts.

Minute	Prefix	Assumed result	Standard input	Cache write	Cache read	Output
0	A	First write	200	4,000	0	300
2	A	Hit; refresh expiry to minute 7	200	0	4,000	300
9	A	Expired; write again	200	4,000	0	300
10	A	Hit	200	0	4,000	300
11	B	Changed prefix; new write	200	4,000	0	300
12	B	Hit	200	0	4,000	300
Total			1,200	12,000	12,000	1,800

For example, the selected usage fields for the minute-2 row would look like this. This is a hypothetical fragment, not a complete response:

{
  "usage": {
    "inputTokens": 200,
    "cacheWriteInputTokens": 0,
    "cacheReadInputTokens": 4000,
    "outputTokens": 300
  }
}

Its total input is 4,200 tokens, but only 200 receive the standard-input rate.

To make the arithmetic easy, use currency-free teaching rates, not an AWS quote: 1 cost unit per 1,000 standard-input tokens, 1.25 per 1,000 five-minute writes, 0.10 per 1,000 reads, and an invented output rate of 3 per 1,000 tokens. The first three retain the earlier example ratios; the output rate is solely an illustration.

Category	Tokens	Units per 1,000 tokens	Cost units
Standard input	1,200	1.00	1.20
Five-minute writes	12,000	1.25	15.00
Cache reads	12,000	0.10	1.20
Output	1,800	3.00	5.40
Total			22.80

The all-standard counterfactual is 25,200 input tokens at 1 unit per 1,000, plus the same 5.40 output units: 30.60 units. The saving is 1 − 22.80 / 30.60, or 25.5%, rounded. Prefix-only saving is 32.5%; the whole-token-cost saving is lower because the other input and output still cost the same.

Six calls did not produce five cache reads. Expiration and the edit caused two extra writes. That is why the ideal one-write table is a planning aid, while the category worksheet is the accounting method.

Use the result to choose the next change

Record one representative request family, including pauses and edits, with the counters, prices, prefix version, timestamps and user-facing latency. Keep model, routing and output settings comparable. Then choose the intervention that matches the observation:

• Rewrites after long gaps: compare one-hour write costs with the five-minute recreations they might avoid; longer retention will not fix document edits.
• Rewrites after prefix changes: move volatile content behind a stable boundary where the model permits it, then measure again.
• Few writes but little whole-request saving: inspect how much of the bill is uncached input or output before changing the TTL.
• Little repeat use overall: the write premium may not be worthwhile. Reconsider the cached portion rather than assuming more checkpoints help.
• Lower token cost but failed latency target: investigate latency separately; savings do not establish a faster application.

Keep caching when a representative, correctly priced workload meets your cost and latency requirements. The useful result is a defensible decision for that workload, not the largest discount in a pricing table.