Why cache minimums are not monotonic, and why it matters

The assumption every engineer brings to a spec table by default

Hand an engineer a table of numbers that vary by product generation, and the first thing most people do — often without noticing they're doing it — is look for the trend. Newer usually means better, or at least different in a predictable direction: more capacity, lower latency, a looser constraint. That instinct is right often enough that it becomes a habit, and habits are exactly what stop getting questioned. The minimum-cacheable-prefix table is one of the places on this site where that habit produces a wrong answer, and it's worth asking why an API would ship a figure that doesn't cooperate with the pattern-matching instinct everyone brings to it.

This isn't the only place the current lineup breaks a "should trend one way" assumption

Cache minimums aren't a lone exception, either. Fast-mode support was available on one Opus generation, removed entirely on the next, and restored on the one after that — not a steady march toward more capability, a genuine round trip. Thinking defaults flip between generations too, sometimes on and sometimes off by default, with no consistent direction across the lineup as a whole. None of these individually is a huge surprise once you know about it. Collectively, they describe a lineup where "capability only ever expands in a straight line" is a comfortable assumption and a wrong one, more than once.

Why a fast-moving API is more likely to produce this than a stable one

A product that changes rarely can afford to make its evolution monotonic almost by definition — there's time to smooth out any generation-to-generation weirdness before the next release. A product iterating as fast as the current model lineup does not have that luxury: different teams optimising different constraints on different timelines produce a sequence of releases where each one made sense on its own terms, and the sequence as a whole doesn't have to add up to a tidy trend line. That's not a criticism of the pace of iteration — it's a genuine, structural reason to expect exactly this kind of non-monotonic detail to keep showing up as the lineup keeps moving, not a one-off quirk that gets cleaned up once and stays clean.

The failure this produces is specifically the quiet kind

What makes this worth an entire post, rather than a footnote on a reference table, is the shape of the failure it causes. A capability that got worse in an obvious way — a request that used to succeed and now visibly fails — gets noticed and fixed fast, because something is actively broken. A capability that quietly stopped applying, with the request still succeeding normally, survives far longer, because nothing about the system is complaining. The cache-minimum case is a clean example of that second shape: everything about the request looks fine, the bill just reflects a different reality than the one that was assumed when the system was built.

What this argues for, as a general habit rather than a specific fix

The practical response to "cache minimums aren't monotonic" is on this site's own reference table, and the mechanics of guarding against it are covered in full on the prompting side of this site. The broader point worth taking away is upstream of any single fix: wherever a system is built on an assumption about how a fast-moving dependency behaves across its own versions, that assumption is worth stating explicitly and re-checking on a schedule, rather than absorbed silently as "how things work" the first time it happened to be true. A dependency that changes faster than your own review cycle will eventually falsify an assumption nobody wrote down, and the falsification won't announce itself.

Why this site treats the fix as infrastructure, not vigilance

It would be easy to conclude the right response is "be more careful" — read the docs more closely, check more often. That's not what this site actually does about its own version of the same problem, and it's worth naming the difference. Every calculator here reads cache minimums and every other version-specific figure from one maintained module rather than from a page author's memory of the last time they checked, which means a non-monotonic jump on a future model release updates every dependent page automatically instead of depending on someone noticing and manually chasing down every place the old figure was quoted. Vigilance doesn't scale across a fast-moving dependency; a single source of truth does.

See the minimum-cacheable-prefix table for the current figures themselves, and why your prompt caches on one model and not another for how to build a caching setup that doesn't depend on guessing which direction this table moves.