This turned out to be a bug. https://x.com/om_patel5/status/2038754906715066444?s=20

One reddit user reverse engineered the binary and found that it was a cache invalidation issue.

They are doing some hidden string replacement if the claude code conversation talks about billing or tokens. Looks like that invalidates the cache at that point.

If that string appears anywhere in the conversation history, I think the starting text is replaced, your entire cache rebuilds from scratch.

So, nothing devious, just a bug.

It's more structural than a simple bug. The cch mechanism embeds a sentinel string (cch=00000) in the serialized request body, which gets replaced by a hash computed in Bun's native runtime (compiled Zig). The hash covers the entire JSON body, so it functions as request integrity verification. The fragility comes from doing string replacement on the payload itself. If cch=00000 appears anywhere in the conversation history — discussing billing code, quoting source, even this thread — the replacement can hit the wrong occurrence, corrupting the body and invalidating the prompt cache. This is a known anti-pattern in protocol design: mixing your signaling channel with your data channel. The standard approach is to put integrity hashes in a request header (e.g., HMAC in Authorization), keeping the signature completely outside the body it covers. That way no payload content can collide with the signing mechanism. The choice to embed it in the system prompt was presumably to avoid API surface changes, but it created a category of bugs that can't be fully fixed without moving the hash out of the body.

I'm not sure this is the issue. I asked Claude Code a simple question yesterday. No sub agents. No web fetches. Relatively small context. Outside of peak hours. Burned 8% of my Max 5x 5hr usage limit. I've never seen anything like this before, even when the cache is cold.

> BUG 2: every time you use --resume, your entire conversation cache rebuilds from scratch. one resume on a large conversation costs $0.15 that should cost near zero.

I use it with an api key, so I can use /cost. When I did a resume, it showed the cost from what I thought was first go. I don't think it's clear what the difference is between api key and subscription, but am I believe that simply resuming cost me $5? The UI really make it look like that was the original $5.

Nothing devious, but is Anthropic crediting users? In a sense, this is _like_ stealing from your customer, if they paid for something they never got.

your linked bug is a cherry pick of the worst case scenario for the first request after a resume.

While it should be fixed, this isn't the same usage issue everyone is complaining about.

That bug would only affect a conversation where that magic string is mentioned, which shouldn't be common.

Anecdotally when Claude was error 500'ing a few days ago, its retries would never succeed, but cancelling and retrying manually worked most of the time.

That is a summary and a picture of https://old.reddit.com/r/ClaudeAI/comments/1s7mkn3/psa_claud... it looks like?

https://xcancel.com/om_patel5/status/2038754906715066444