LLM API Prompt Caching Compared: OpenAI, Anthropic, DashScope, and DeepSeek Handle Cache Hits Differently

Every major LLM API provider now caches repeated prompt prefixes, but they all do it differently. OpenAI caches automatically and recently added explicit breakpoints with write fees. Anthropic requires cache_control markers and charges for writes. DashScope offers both an explicit cache (with write fees) and a free implicit cache. DeepSeek caches to disk automatically with no write fee. The pricing discounts range from 80% to 90% off base input cost, the TTLs range from 5 minutes to 24 hours, and the minimum token thresholds range from 256 to 1,024.

If you route requests across providers, these differences directly affect your cost model: a prompt that gets 90% cache-read savings on one provider may pay a 25% write surcharge on another, and a TTL mismatch can turn expected cache hits into full-price misses.

This post compares the four providers side by side, with code examples, pricing math, and a decision matrix for choosing the right caching strategy for your workload.

OpenAI-compatible means a provider exposes a chat-completions endpoint whose request and response shape matches the OpenAI API contract closely enough that an unmodified OpenAI SDK call works against it after swapping three values: API key, base URL, and model name. The minimum surface in practice is POST /v1/chat/completions with messages, model, and an OpenAI-shaped streaming response.

Sources: OpenAI Prompt Caching docs, retrieved 2026-08-05; DashScope Context Cache docs, retrieved 2026-08-05; DeepSeek Context Caching docs, retrieved 2026-08-05; Anthropic Prompt Caching docs, retrieved 2026-08-05 (search snippet); DashScope Model Pricing, retrieved 2026-08-05.

---

TL;DR comparison table

---

OpenAI: automatic caching with explicit breakpoints on GPT-5.6

OpenAI's prompt caching is automatic for prompts of 1,024 tokens or longer. The system routes requests to servers that recently processed the same prefix using a hash of the first ~256 tokens. No code changes are needed for basic caching.

With GPT-5.6 and later, OpenAI introduced explicit cache breakpoints and a cache write fee (1.25× base input). The implicit breakpoint lands on the latest user or tool message by default. If that message contains variable content (timestamps, tool-call history), the prefix at the breakpoint changes between requests, and cached_tokens can be 0 even though thousands of tokens are shared.

To control this, add prompt_cache_breakpoint at the end of your stable prefix and set prompt_cache_options.mode to explicit to disable the implicit breakpoint:

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-5.6-sol",
    prompt_cache_key="repo-review-v1",
    prompt_cache_options={"mode": "explicit"},
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": "You are a code reviewer. Repository contents:\n\n<repo>...</repo>",
                    "prompt_cache_breakpoint": {"mode": "explicit"},
                }
            ],
        },
        {"role": "user", "content": "Review the auth module for security issues."},
    ],
)

usage = response.usage
print(f"Cached: {usage.prompt_tokens_details.cached_tokens}")
print(f"Written: {usage.prompt_tokens_details.cache_write_tokens}")

Key details:

• prompt_cache_key combined with the prefix hash routes requests to the same cache. Keep traffic per key under ~15 RPM to avoid cache overflow.
• TTL defaults to 30 minutes for explicit breakpoints on GPT-5.6.
• Extended retention (up to 24 hours) is available on GPT-4.1, GPT-5, GPT-5.1, GPT-5.2, GPT-5.4, and GPT-5.5 series for non-ZDR organizations.
• Each request can create up to 4 new cache writes; up to 50 breakpoints are eligible for reads.

Source: OpenAI Prompt Caching docs, retrieved 2026-08-05.

---

Anthropic: explicit cache_control with write fees

Anthropic's prompt caching is fully explicit. You mark content blocks with cache_control to tell the system which prefixes to cache. The first call with a given prefix pays a 1.25× write fee; subsequent calls that hit the cache pay only 10% of the base input price (90% discount).

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a code reviewer. Full repo contents:\n\n<repo>...</repo>",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {"role": "user", "content": "Review auth module for vulnerabilities."}
    ],
)

usage = response.usage
print(f"Cache write: {usage.cache_creation_input_tokens}")
print(f"Cache read:  {usage.cache_read_input_tokens}")

Key details:

• Minimum cacheable tokens: 1,024 for Claude Sonnet 5, 2,048 for Claude Opus.
• Default TTL: 5 minutes (ephemeral). An optional ttl parameter extends this to 1 hour.
• Up to 4 cache_control breakpoints per request.
• Cache write tokens: 1.25× base input price. Cache read tokens: 0.1× base input price.
• Caching applies to system messages, user messages with images/documents, and tool definitions.
• Each cache hit resets the TTL.

Source: Anthropic Prompt Caching docs, retrieved 2026-08-05 (via search snippet — direct fetch failed).

---

DashScope: explicit and implicit modes

DashScope (Alibaba Cloud Model Studio) offers two caching modes that are mutually exclusive within a single request:

Explicit cache

Works like Anthropic's approach: add cache_control: {"type": "ephemeral"} markers to your messages. Cache writes cost 1.25× base input. Cache reads cost 10% of base input (90% discount). TTL is 5 minutes, reset on each hit. Minimum 1,024 tokens. Up to 4 markers per request.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

response = client.chat.completions.create(
    model="qwen3.7-max",
    messages=[
        {
            "role": "system",
            "content": [
                {
                    "type": "text",
                    "text": "You are a financial analyst. Report:\n\n<report>...</report>",
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        },
        {"role": "user", "content": "Summarize key revenue metrics."},
    ],
)

# Cache status in usage.prompt_tokens_details.cached_tokens
print(response.usage)

Implicit cache

Enabled by default when explicit markers are not present. The system automatically detects common prefixes across requests and caches them. No write fee — cache creation tokens are billed at the standard input rate. Cache read tokens are billed at 20% of base input (80% discount). Minimum 256 tokens. TTL is indeterminate; the system periodically clears unused cache data.

Supported models (as of Aug 2026): Qwen3.7-Max, Qwen3.7-Plus, Qwen3.6-Flash, Qwen3.5-Plus, Qwen3.5-Flash, Qwen3-Max, Qwen-Plus, Qwen-Flash, DeepSeek-V3.2 (via DashScope), Kimi-K2.7-Code, Kimi-K2.6, Kimi-K2.5, GLM-5.1, and Qwen VL/Coder variants.

Source: DashScope Context Cache docs, retrieved 2026-08-05.

---

DeepSeek: automatic disk-based caching

DeepSeek's "Context Caching on Disk" is enabled by default for all users. No code changes needed. Each request triggers cache construction, and subsequent requests with matching prefixes hit the cache automatically.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "You are a financial analyst. Report:\n\n<report>...</report>"},
        {"role": "user", "content": "Summarize key revenue metrics."},
    ],
)

# Check cache performance
usage = response.usage
print(f"Cache hit tokens:  {usage.prompt_cache_hit_tokens}")
print(f"Cache miss tokens: {usage.prompt_cache_miss_tokens}")

Key details:

• Cache prefix units are created at request boundaries (end of user input + end of model output), at fixed token intervals for long inputs, and when the system detects common prefixes across requests.
• Cache matching requires an exact full match of a persisted prefix unit. Partial prefix overlap does not hit.
• For multi-turn conversations: the second request can match the first request's full cache unit. For varied questions about the same document: the system detects the common prefix after 2+ requests and persists it; the third request hits.
• TTL: best-effort, "a few hours to a few days." No explicit TTL control.
• No write fee. Cache hit tokens are billed at the discounted rate (approximately 90% off).
• The cache is best-effort; 100% hit rate is not guaranteed.

Source: DeepSeek Context Caching docs, retrieved 2026-08-05.

---

SiliconFlow: no documented caching

As of August 2026, SiliconFlow's public API documentation does not describe a prompt caching mechanism. The /v1/chat/completions endpoint follows the OpenAI-compatible schema but does not expose cached_tokens or equivalent fields. If SiliconFlow performs internal caching, it is transparent and not reflected in billing or response metadata.

For workloads that benefit from caching, routing through a provider with explicit caching support may reduce costs compared to SiliconFlow, even if SiliconFlow's base per-token price is lower.

---

Pricing math: when does caching save money?

Caching saves money only when cache read savings outweigh cache write costs over enough requests. Here is the break-even math for each provider:

OpenAI (GPT-5.6)

• Write cost: 1.25× base input
• Read discount: varies by model (up to 90% off, i.e., read at 0.1× base)
• Break-even: If a 10,000-token prefix is cached once and read N times:
  • Write cost: 10,000 × 1.25 = 12,500 token-equivalents
  • Savings per read: 10,000 × 0.9 = 9,000 token-equivalents saved
  • Break-even at N = 2 reads (12,500 write overhead / 9,000 savings per read ≈ 1.4)

Anthropic

• Write cost: 1.25× base input
• Read: 0.1× base input (90% off)
• Break-even: same math — roughly 2 reads per write.

DashScope explicit

• Write cost: 1.25× base input
• Read: 0.1× base input (90% off)
• Break-even: roughly 2 reads per write.

DashScope implicit

• Write cost: 1.0× base input (no surcharge)
• Read: 0.2× base input (80% off)
• Break-even: always saves money from the first cache hit, since there is no write surcharge.

DeepSeek

• Write cost: 1.0× base input (no surcharge)
• Read: ~0.1× base input (90% off)
• Break-even: always saves money from the first cache hit.

The routing implication: DashScope implicit caching and DeepSeek disk caching have no break-even threshold — every cache hit saves money from the first reuse. OpenAI (GPT-5.6+), Anthropic, and DashScope explicit caching require at least 2 cache reads per prefix to break even on the write fee. For one-shot or low-frequency prompts, the write surcharge can make caching more expensive than skipping it.

---

Cache behavior differences that affect routing

TTL and cache affinity

If you route requests across multiple providers, cache state does not transfer. A prefix cached on OpenAI is not cached on Anthropic. Routing the same repeated prefix to different providers on each request means no provider builds up cache state, and you pay full input price everywhere.

For cache-heavy workloads, provider pinning (routing the same conversation or prompt template to the same provider) is more cost-effective than round-robin routing. This is a design trade-off: pinning improves cache hit rates but reduces your ability to fail over to a different provider.

Prefix structure matters

All providers match on exact prefix. If your variable content comes before the static content, caching will not trigger on any provider. Structure prompts with static content first:

✅ system prompt (static, long) → user message (variable, short)
❌ user context (variable) → system prompt (static)

On DeepSeek, the matching is stricter: a cache unit must be fully matched. If request 1 sends A + B and request 2 sends A + C, request 2 does NOT hit (unlike OpenAI/Anthropic where the common prefix A would match). DeepSeek detects the common prefix A after both requests and persists it; a third request A + D then hits. This means DeepSeek caching has a cold-start delay of 2+ requests for varied-suffix workloads.

Response field names

Each provider reports cache status differently. If your logging or cost-tracking system relies on specific fields, you need provider-specific parsing:

---

Decision matrix: which caching strategy for which workload

---

TheRouter note

When TheRouter routes requests across OpenAI, Anthropic, DashScope, and DeepSeek, caching is handled by each provider independently. A request that hits OpenAI builds cache on OpenAI; if the next request for the same prompt is routed to Anthropic, it starts cold.

For workloads where caching is a significant cost lever, consider configuring model fallbacks to prefer a single provider for specific prompt templates, with fallback to alternatives only on rate limits or errors. This preserves cache affinity while maintaining reliability.

Prompt caching does not change the routing decision itself — the router does not inspect or manage provider cache state. The optimization is on the prompt and routing configuration side: structure prompts for caching, pin cache-sensitive traffic, and monitor cache hit rates in each provider's response metadata.

---

FAQ

Can I use prompt caching through an OpenAI-compatible gateway? Yes. OpenAI automatic caching works transparently. For Anthropic and DashScope explicit caching, the cache_control parameter must be passed through by the gateway. DeepSeek caching is fully transparent.

Does caching affect output quality? No. All providers state that caching affects only input processing (KV cache reuse). The model still generates output through full computation, and output randomness (controlled by temperature) is unaffected.

What happens when the cache expires? The next request with the same prefix pays the full input price (or the write price, for providers with write fees). On Anthropic and DashScope explicit, each cache hit resets the TTL, so actively used caches stay warm. On OpenAI (GPT-5.6), explicit breakpoint caches use a 30-minute TTL; extended retention is available on older model series.

Can I cache tool definitions and images? OpenAI: yes (tools and images are included in prefix matching). Anthropic: yes (tool definitions and image content blocks can carry cache_control). DashScope: yes (multi-modal content blocks support cache_control in explicit mode). DeepSeek: tool definitions are part of the prompt prefix and cached automatically.