Windows, budgets and the cache that fails silently

Two separate things get muddled under "context costs money". Untangle them now, because the exam treats them as different sub-skills and so should you.

Window sizes, and the premium that does not exist

The current models, claude-opus-5, claude-sonnet-5 and claude-fable-5, carry a 1M token context window and 128k output. claude-haiku-4-5-20251001 is 200k context and 64k output.

And the part people get wrong: there is no long-context pricing premium. Filling a 1M window does not move you onto a different rate card. A token near the end of a huge prompt costs the same as a token near the start of a small one.

The three multipliers

Prompt caching prices in multiples of the base input rate.

• Cache write, 5 minute TTL: 1.25x
• Cache write, 1 hour TTL: 2x
• Cache read: 0.1x

A cache read costs a tenth of an ordinary input token. That is the whole reason anyone bothers.

Run the arithmetic yourself rather than trusting a rule of thumb, and be careful setting up the comparison, because there is an off-by-one waiting in it.

The trap is comparing the wrong two things. A cached run of one write plus N reads is N plus 1 requests, so it has to be measured against N plus 1 uncached calls, not against N. Write it the wrong way and you will conclude caching needs one more read than it really does.

Set up properly, with the 5 minute TTL at 1.25x write and 0.1x reads:

1.25 + 0.1N < 1 + N, which solves to N > 0.28. One read is enough. Concretely: write plus one read costs 1.35 against 2.0 for two uncached calls.

With the 1 hour TTL at 2x write: 2 + 0.1N < 1 + N, which solves to N > 1.11. Two reads. That is 2.2 against 3.0.

Those are the same numbers the pricing docs give when they say caching pays off after one cache read at the 5 minute TTL and two at the 1 hour TTL, which is a useful check on your own algebra. Stated as total uses of the prefix rather than reads, it is two and three, which is how the Foundations course puts it. Same fact, and the only thing that changes is whether you are counting the write.

That is a strikingly low bar, and it is why caching is close to free money for any prompt with a stable prefix. It is also why the failure mode in the next section is so expensive: the wins are large enough that you assume you are getting them.

The minimum that fails silently

Here is the one that will actually cost you money in production.

Every model has a minimum cacheable prompt length, and a prompt below it silently does not cache. No error. No warning. Nothing.

It behaves like a minimum order value that the shop never mentions. You hand over a basket that is a pound short, the transaction completes, you get a receipt, and the discount you thought you had arranged simply is not on it. Nothing failed. You just paid list price and were never told.

The values are not monotonic across the lineup, so you cannot reason your way to them:

Minimum	Models
512 tokens	Opus 5, Fable, Mythos
1024 tokens	Opus 4.8, Sonnet 5, Sonnet 4.6
2048 tokens	Opus 4.7
4096 tokens	Opus 4.6, Opus 4.5, Haiku 4.5

Read that table twice. Opus 5 has the lowest minimum in the list. Haiku 4.5 has the highest. Any intuition of the form "bigger model, bigger minimum" or "newer model, lower minimum" gets contradicted somewhere in that table. It is a lookup, not a derivation.

Now stack that against the silent failure. You mark a 900-token system prompt as cacheable, you ship it against Haiku 4.5, and it has never cached once. Every request is full price. Your latency looks normal. Your logs look normal. The only symptom is a bill that is roughly ten times what you modelled, and you will blame traffic before you blame this.

The habit that saves you

Two checks, both cheap, and both worth running against your own production traffic this week rather than only in an exam.

One: look up the minimum for the exact model you are calling, every time you change models. Switching from Opus 5 to Haiku 4.5 raises your minimum by a factor of eight, and nothing in your code will complain.

Two: verify caching from the usage numbers, not from the fact that you set the marker. The request tells you what was written and what was read. A cache marker is an intention. The usage figures are the measurement, and they are the only thing that can tell you the intention failed.

input tokens             3120
cache creation tokens       0
cache read tokens           0
errors                   none