Of course we are all guessing, but both things can be true: they don't want you to hit the cache, because cache writes are more profitable than cache reads, and

Of course we are all guessing, but both things can be true: they don't want you to hit the cache, because cache writes are more profitable than cache reads, and they are supply limited on the compute. Pre-filling input tokens is very different from decoding, so when they claim they are supply limited on compute, do they mean mostly for decode or also for pre-fill (or only for pre-fill)? I can imagine there are coding tasks where small edits to an existing huge codebase mostly consists of some small tool calls + processing a lot of input tokens, in e.g. a 20 to 1 ratio of input to output tokens. https://github.com/anthropics/claude-code/issues/63930 https://github.com/anthropics/claude-code/issues/63930 This issue suggests that 74% of the charged input tokens could actually have been cache reads if claude code hadn't busted the cache. On the input side of things, this increased the cost (or count towards allowance) by ~3x (given that cost of cache write is 1.25 the unit price, and read is 0.1x the unit price). OpenAI has a different cache pricing strategy, where cached reads are only 0.5x the cost, but cache writes do not cost extra. Not sure how the unit economics play out claude vs openai, but it's safe to say that caching costs play a huuuge factor in this. It seems to be one of anthropic's USPs as a frontier-AI lab. They charge a premium for cache-writes (on top of the inflated token usage compared to OpenAI that was recently reported), but significantly discount the cache reads. The lack of care in tackling issues related to cache-busting is therefore really bad and suspicious.