Paste two consecutive request bodies and find the exact byte where your cached prefix broke, whether your breakpoints are even legal, and whether caching is paying for itself at your request rate.
Scope. This models Anthropic prompt caching as documented in the Anthropic Messages API. Other providers implement caching differently (different render order, different minimums, different economics) and are out of scope here. Nothing on this page is a general cross-provider claim.
Everything runs in your browser. No request is sent anywhere, no API key is used, and no backend exists. This tool measures nothing about your actual traffic - it reasons about the bodies you paste. See How to measure it for real.
Synthetic sample loaded. These two bodies were written by hand to demonstrate four separate cache traps in one click. They are illustrative - not real traffic, not a benchmark, and not measured from any running system. Replace them with your own logged request bodies to get an answer about yours.
model field when possible.This tool estimates. The API measures. Read these fields from the usage object on the response (or from the message_start event when streaming):
| Field | What it actually is |
|---|---|
| cache_creation_input_tokens | Tokens written to the cache when creating a new entry. |
| cache_read_input_tokens | Tokens served from the cache on this request. |
| input_tokens | Only the tokens after the last cache breakpoint. This is the field teams misread. |
| cache_creation.ephemeral_5m_input_tokens | Per-tier breakdown of the write: the 5-minute portion. |
| cache_creation.ephemeral_1h_input_tokens | Per-tier breakdown of the write: the 1-hour portion. |
The diagnostic that matters. If cache_read_input_tokens is zero across repeated requests that you believe share a stable prefix, a silent invalidator is at work. There is no error and no warning - the number simply stays at zero. That is the case this tool exists to localize.
A second silent case: if both cache_creation_input_tokens and cache_read_input_tokens are zero, the prompt was not cached at all, most often because the prefix fell under the model's minimum. Again, no error is returned.
Every priced number and every floor verdict on this page is computed from the block below. Nothing is hardcoded in the logic. If a value changes, edit it here and the answers change with it - including the break-even count, which is derived from the multipliers rather than baked in.
Confirmed 2026-08-07 against platform.claude.com prompt caching and platform.claude.com rate limits. A stale row here produces a visibly stale answer that you can fix yourself. It cannot make the byte-level diagnosis above wrong.
Render order is tools, then system, then messages. A change at one level invalidates that level and every level after it. valid means that tier survives the change; broken means it does not.
| What changes | Tools cache | System cache | Messages cache |
|---|---|---|---|
| Tool definitions (names, descriptions, parameters, order) | broken | broken | broken |
| Web search toggle | valid | broken | broken |
| Citations toggle | valid | broken | broken |
| Speed setting (fast vs standard) | valid | broken | broken |
| Tool choice | valid | valid | broken |
| Images added or removed anywhere in the prompt | valid | valid | broken |
| Thinking parameters | model-specific | model-specific | broken |
| Effort setting | model-specific | model-specific | broken |
| Non-tool results passed to extended thinking requests | valid | valid | model-specific |
Do not read the thinking and effort rows as green. The documented table marks the tools and system columns for both of those rows as model-specific, not as preserved. The configuration is rendered into the prompt, so it always invalidates message blocks; whether it also invalidates tools and system depends on whether the model renders that configuration ahead of them. Setting effort explicitly to the model's default is equivalent to omitting it and does not invalidate.
Two escape hatches worth knowing, both documented: on the models that support it, appending a {"role": "system"} message to messages adds an instruction mid-conversation without invalidating the system or message caches, whereas editing the top-level system field does invalidate them. And a model switch has no escape hatch at all - cache entries are scoped to a model.
tools in array order, then system, then every content block of every message in order.tiktoken are wrong for Claude and this tool does not use one. Nor does it embed a Claude tokenizer - it has no network access and ships no model files.count_tokens endpoint.On the render. The byte offsets reported here are offsets into this tool's own deterministic serialization of your body, not into the provider's internal wire format. What matters for diagnosis is that the serialization is stable and order-preserving, so a difference in it corresponds to a real difference in your request. Object keys are emitted in the order they appear in your JSON and are never sorted, because a non-deterministic serializer on your side is itself a real invalidator this tool needs to be able to name.
On cache_control. Markers are treated as caching directives rather than prompt content, so they are excluded from the compared bytes and tracked separately. Moving a marker changes which entry gets written; it does not change the prompt text.
No headline savings percentage appears anywhere on this page. The economics panel prints the formula and solves for the break-even request count instead, because a percentage without a request count is not a claim you can act on.