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.

Whoa. Is Claude coming in here and generating responses about itself.

https://stopsloppypasta.ai/en/

Yep I was going to say - this is just bad design. This kind of approach is inherently fragile, you are unavoidably destroying information in some sense by mixing things together