How to Check Claude API Prompt Cache
Build a stable long prefix, compare cache_creation_input_tokens with cache_read_input_tokens, and diagnose missing Claude prompt cache evidence through API relays.
Quick Answer
Send two requests that share an identical cacheable long prefix. The first should report cache_creation_input_tokens; the second should report cache_read_input_tokens. Faster latency or a lower bill is not enough by itself: preserve the usage fields as direct evidence.
Key Takeaways
- Look for cache creation on the first request and cache reads on the second.
- The cacheable prefix must remain byte-for-byte stable.
- Use usage fields as primary evidence, not latency alone.
- A relay may remove or rewrite native Anthropic cache fields.
What Claude prompt caching reuses
Prompt caching reuses a stable prefix across requests, such as a system prompt, tool definitions, long documents or conversation history. A cache hit can reduce repeated long-context processing cost and improve time to first token.
The goal of a check is not merely to show that the second request was faster. Network jitter, queueing and output length also affect latency; usage fields provide more direct evidence.
Fields to inspect
SDK naming can vary, so retain the raw Anthropic usage object. It makes cache and billing investigations reproducible.
| Field | Meaning | Expected change |
|---|---|---|
| input_tokens | Ordinary input not read from cache | Usually falls after a hit |
| cache_creation_input_tokens | Input written into the cache | Should be above zero on the first request |
| cache_read_input_tokens | Input read from the cache | Should be above zero on the second request |
| output_tokens | Generated output | Not direct cache-hit evidence |
Designing the paired requests
Prepare a stable prefix long enough for the selected model and apply supported cache_control to the intended content block. Keep the model and system/tool/document prefix unchanged; vary only a short final question.
- Request A creates the cache; save usage and TTFT.
- Send request B shortly afterward with the same cacheable prefix.
- Verify that B reports cache_read_input_tokens above zero.
- Compare A's creation tokens with B's read tokens.
- Change one prefix character in request C to confirm the read falls or misses.
Why the second request may still miss
Common causes include an unsupported model, a prefix below the minimum token threshold, misplaced cache_control, whitespace or JSON-order changes, expiration, or a changed account or region.
Through a relay, also check whether it converts Anthropic requests into OpenAI format, strips cache_control or removes cache usage fields from the response.
Interpreting latency and cost
Separate TTFT, end-to-end latency and usage. A cache hit may reduce prefix processing while output generation and upstream queueing still dominate total time.
Calculate ordinary input, cache write, cache read and output costs separately using the official price effective on the test date.
Retesting before production
Use real system prompts, tools and document templates. Repeat across time windows and measure hit rate rather than celebrating one hit. For relays, test whether account-pool switches and 429 recovery preserve cache behavior.
Frequently Asked Questions
Does cache_read_input_tokens equal to zero mean Claude lacks cache support?
Not necessarily. The prefix may be too short, cache_control may be wrong, the prefix may have changed, the cache may have expired, or a relay may have removed the field.
Is a faster second request proof of a cache hit?
No. Network and queueing also change latency. Use cache_read_input_tokens and related usage fields as primary evidence.
Can Claude prompt cache be tested through a relay?
Yes, if the relay preserves Anthropic cache_control and usage fields. Missing fields are themselves a protocol-compatibility risk.
Continue Reading
Run a Check with a Real API
Use a temporary key to inspect connectivity, latency, cache, rate limits, model purity and token cost.