Prompt caching and the minimum that is not monotonic

Caching is the biggest cost lever that does not change your architecture. It is also the one feature in this course that fails silently, which makes its details worth more attention than its share of the exam suggests.

Every other trap in this course is a smoke alarm going off. This one is the smoke alarm with the battery quietly removed: nothing sounds, nothing looks different, and you find out from the bill.

The economics in one paragraph

Mark a prefix of your request as cacheable. The first request pays a write premium. Every subsequent request that matches that prefix exactly pays a read price of 0.1 times normal input.

Writes cost 1.25 times for a 5-minute TTL and 2 times for a 1-hour TTL.

The break-even falls straight out of that arithmetic, and it is worth doing once so you never have to guess:

5-minute TTL. Two uses costs 1.25 plus 0.1 equals 1.35, against 2.0 uncached. Ahead from the second use.

1-hour TTL. Two uses costs 2.0 plus 0.1 equals 2.1, against 2.0 uncached, so still behind. Three uses costs 2.2 against 3.0. Ahead from the third use.

The pricing docs state the same result counted the other way, as cache reads rather than total uses: one read at the 5-minute TTL, two at the 1-hour. Two uses is one write plus one read, and three uses is one write plus two reads, so the numbers agree. Watch which unit a question is using, because "two" and "three" become "one" and "two" the moment someone counts reads instead of uses, and the gap between those two framings is the easiest place to lose a mark you actually understood.

So the cheaper TTL wins on short bursts and the longer one wins on anything reused across a session. Neither is a default.

What is actually cacheable

Prefix matching, exact bytes, from the front. Which means the only worthwhile candidates are the parts that never change: the system prompt, tool definitions, and any long static document you attach to every call.

The newest user message can never hit, because it is different every time. In a long conversation you can also cache the accumulated history, since turn twenty's prefix contains turn nineteen's prefix, and that is where multi-turn chat gets dramatically cheaper.

The minimum, and why it is the best question on this topic

The consequence that makes this a superb exam item: a 3000-token prefix caches on Opus 5 and does not cache on Opus 4.6. Same prompt, same cache_control, same code, different model id, and one of them saves you 90 percent while the other saves you nothing.

It fails silently, and that is the real lesson

Every other trap in this course is a 400. This one is not.

Send a below-minimum prefix and the request succeeds. No error, no warning field, no signal in the response body that says "you asked for caching and did not get it". Your bill just stays at full price while your architecture diagram says caching is on.

The general form of this is worth carrying out of the course entirely: ask of any check what single fault would make it quieter rather than louder. A feature whose failure mode is silence needs an assertion pointed at it, because nothing else will ever tell you.

How it composes with everything else

Caching is a multiplier on input tokens, so it stacks with Batches, which is a multiplier on the whole job. A batched job over a cached prefix gets both. It does not interact with the output side at all, so a workload that is expensive because it generates a lot of text is not a caching problem, it is an effort and prompt-design problem.

And one platform note that belongs here rather than in module five: automatic prompt caching is available everywhere except Bedrock. If your deployment target is Bedrock, that is a line in your cost model, not a footnote.

{ "model": "claude-opus-5", "system": [ { "type": "text", "text": "...3000 tokens...", "cache_control": { "type": "ephemeral" } } ] }

{ "model": "claude-opus-4-6", "system": [ { "type": "text", "text": "...3000 tokens...", "cache_control": { "type": "ephemeral" } } ] }

{
  "model": "claude-sonnet-5",
  "system": "You are a policy assistant.",
  "messages": [
    { "role": "user", "content": "...30k of policy documents..." },
    { "role": "assistant", "content": "Understood." },
    { "role": "user", "content": [
        { "type": "text", "text": "What is the notice period?", "cache_control": { "type": "ephemeral" } }
    ]}
  ]
}