The minimum-cacheable-prefix table

The table that exists nowhere else

Every current and recent Claude model supports prompt caching, but the minimum prefix length a request must clear before anything can be cached at all is not the same number across generations, and it is not monotonic — it does not simply shrink or grow as models get newer. The pattern, reading the table below low to high: the newest generation of models sits at the floor. A cluster of mid-generation models sits one step above that. One specific Opus generation breaks the run entirely, landing above every neighbour on either side of it in the release sequence — genuinely stranded in the middle rather than settling toward either end. And the top of the table is held by a small group that includes both an older Opus generation and the current lineup's cheapest model, which is not a pairing a reader would predict from price or release order alone.

Why this shape matters more than any single figure in it

Because the sequence doesn't move in one direction, a rule of thumb like "newer models have a lower floor" or "cheaper models have a lower floor" is wrong often enough to be actively dangerous to plan around. The only safe way to know where a given model sits is to check this table directly for that model — assuming a position from its generation, its price, or its release date is exactly the kind of shortcut this page exists to head off.

Why this bites in practice

A prompt engineered and tuned against one model's floor does not necessarily clear a different model's floor. If you built a system prompt against a model near the bottom of this table, and a downgrade, a fallback, or a routing change points the same prefix at a model near the top of it, that prefix can fall below the new floor — and nothing about that failure is visible in the response. There is no error, no warning field, no rejected request. The request succeeds normally; it simply never caches, and every request bills as if caching were never configured at all. The only way to notice is to actively check the usage block against what you expected.

What to do about it

Size a shared prefix against the most demanding floor in your actual routing set, not the most lenient one — a prefix built to clear the table's highest entry caches correctly everywhere below it, while one sized only to the lowest entry caches reliably on a narrower slice of the lineup. If you're comparing this table against your own prefix size, the prompt-caching savings calculator applies the correct floor for your chosen model automatically, so there's no manual cross-referencing required.

The table

Grouped by minimum cacheable prefix, low to high. See each model's own reference page for its full pricing and platform availability.