Paste two API request bodies. See the first block that changed, the shared prefix size and whether it meets the minimum cacheable length.
To find why a prompt cache missed, compare the two requests from the start, in the order the provider caches them, and look for the first block that differs: everything before it can be read from the cache, and everything from it onward is processed again. This tool does that for you. Paste the JSON body of two consecutive calls. It detects the format (Anthropic Messages, OpenAI Chat Completions or OpenAI Responses), turns each request into a list of blocks in cache order, and compares them one by one. For Anthropic the order is tools, then system, then messages. For OpenAI it is the prompt as serialized, with tools first. The report names the first changed block by its path, such as system[0] or tools[2], shows the characters around the change, and counts the characters and estimated tokens before it. Settings that the providers include in the cache key, such as model, tool_choice and thinking for Anthropic, are compared too.
In the sample, the first request has one tool, one system block that ends with Current time: 2026-10-14T09:00:00Z, and one user message. The second request has the same tool and a system block that ends with 09:00:07Z, followed by two more messages. The tool block is identical, so 1 block is shared: 162 characters, or about 41 tokens at the 4-characters-per-token estimate. The first difference is system[0], at character 115, and the changed text is a timestamp. Both requests also place a cache_control breakpoint on system[0], the very block that changed, so no breakpoint sits inside the shared prefix and no cache hit is expected. The fix is to move the time into the last user message, so system[0] reads the same on every call.
Anthropic caches up to a block marked with cache_control, or wherever the API places the breakpoint when you set cache_control at the top level of the request. You can set up to 4 breakpoints (a top-level cache_control uses one of them, and the API returns a 400 error if no slot is left), and the API looks back at most 20 blocks from each one for an earlier entry, so a breakpoint more than 20 blocks past the last cached one can miss. The minimum cacheable prompt is 512, 1,024, 2,048 or 4,096 tokens depending on the model; a shorter prompt is not cached and no error is returned, so check cache_creation_input_tokens and cache_read_input_tokens in the response (Anthropic prompt caching guide, platform.claude.com/docs/en/build-with-claude/prompt-caching). OpenAI caches the longest matching prefix on its own by default, and GPT-5.6 and later also accept explicit mode, where only the prompt_cache_breakpoint markers you set are cached and a request with none is not cached. Its guide gives 1,024 visible input tokens as the minimum for its newest models and says earlier models vary with settings such as tools and images (developers.openai.com/api/docs/guides/prompt-caching).
A date or time in the system prompt is the usual cause: move it to the last user message. A request id, session id or turn counter has the same effect. Tools that come from a dictionary, a set or several MCP servers can arrive in a different order on each call, so sort them by name. A JSON schema built by a serializer that does not fix key order produces different text for the same content, so sort keys. Editing a tool description, or adding and removing a tool, changes the tools block that sits first in the cache order. Trimming old messages from the start of the history every turn breaks the cache every turn; trim once, then keep appending. Changing model, thinking or tool_choice between calls also invalidates entries, and each case is listed in the report with a fix.
The analyzer compares text; it does not talk to the provider, so it cannot tell whether an entry has expired or whether another request wrote it. Anthropic entries last 5 minutes by default, refreshed by each hit, or 1 hour when you ask for it. For OpenAI, the guide gives 30 minutes for its newest models. Token counts are estimates at 4 characters per token, so a prefix close to the minimum needs the real count from the usage fields of the response. Anthropic counts a run of consecutive tool_use or tool_result blocks as one position in the 20-block lookback; this tool counts every block, so it can be stricter than the API near that limit. Images and thinking blocks are compared as written in the JSON.
Three causes cover most cases: the prompt is under the model's minimum of 512, 1,024, 2,048 or 4,096 tokens, a block before your breakpoint changed between calls (a timestamp in the system prompt is typical), or the breakpoint sits on the block that changes. Paste both requests and the report names which one applies.
For Anthropic it depends on the model: 512, 1,024, 2,048 or 4,096 tokens, and the Anthropic minimum option on this page lets you pick one. OpenAI documents 1,024 visible input tokens for its newest models. A shorter prompt is not cached and the API returns no error.
On Anthropic, read cache_creation_input_tokens and cache_read_input_tokens in the response usage. If both are 0, the prompt was not cached. Use this page to see why, by comparing the request that wrote the cache with the one that should have read it.
Yes. Tools come first in the cache order for Anthropic, and a change to tool definitions invalidates tools, system and messages. OpenAI's guide says changing tool names, descriptions, schemas or ordering changes the prefix. Sort tools by name before every call.
On Anthropic it invalidates the cached messages only; tools and system stay valid. The report marks such a change and shows how many blocks stay shared. OpenAI's guide suggests tool_choice none or allowed tools instead of removing tool definitions.
No. The text is processed in your browser, in this tab, and not uploaded. Your choices on this page are saved in this browser; the text you paste is not.