Skip to main content
Prompt Caching is an important mechanism used to reduce model inference costs. By caching previously processed prompt content, it can be reused in subsequent requests, thereby reducing redundant computations, lowering costs, and improving response efficiency.

Principle

When you send a request with prompt caching enabled, the system checks if the prompt prefix has been cached from recent queries. If found, it uses the cache, reducing processing time and costs; otherwise, it processes the full prompt and caches the prefix after the response begins. This is particularly useful in the following scenarios:
  • Prompts containing numerous examples
  • Extensive context or background information
  • Repetitive tasks with consistent instructions
  • Long multi-turn conversations

Core Mechanism

Different model providers have varying support for caching:

Automatic Caching

Automatic caching requires no additional configuration; the system automatically identifies and caches reusable content, applicable to models like OpenAI, DeepSeek, etc.

OpenAI

  • Minimum prompt length: 1024 tokens; caching applies automatically when the prefix matches exactly
  • Models before GPT-5.6: cache writes have no additional fee; cache reads are billed at the model’s cached-input rate
  • GPT-5.6 and later (official scope: “GPT-5.6 models and later model families”, currently gpt-5.6-sol / terra / luna): cache writes are billed at 1.25x the input rate and cache reads at 0.1x; the family adds prompt_cache_key and explicit cache breakpoint parameters
  • For usage, billing, and cache-hit troubleshooting, see GPT Prompt Caching

Gemini

  • Implicit context caching is enabled by default, and caching is automatically effective without manual configuration.
  • Caching is only effective when the content, model, and parameters are identical; any differences will be treated as a new request and will not hit the cache.
  • The cache validity period is set by the developer, and it can also be left unset. If unspecified, it defaults to 1 hour. There are no minimum or maximum duration limits, and costs depend on the number of cached tokens and cache duration.

DeepSeek / Grok / Moonshot / Groq

  • Cost: Writing to cache is free or at the same price, reading from cache is below the original price

Claude Model Explicit Caching

  • Enabled via cache_control: a top-level field in the request body sets the breakpoint automatically (moving forward as the conversation grows), or content-block-level breakpoints give fine-grained control over cache placement
  • Supported on all active Claude models, with uniform rates across the lineup: cache writes at 1.25x for the 5-minute tier and 2x for the 1-hour tier, cache reads at 0.1x
  • Applicable to Anthropic Claude models
Claude sets a minimum cacheable token threshold per model (512 / 1,024 / 2,048 / 4,096, and not proportional to the model version number): for example, Claude Opus 4.8 is 1,024, Claude Opus 4.7 is 2,048, Claude Opus 4.6 / 4.5 and Claude Haiku 4.5 are 4,096, and Claude Fable 5 is 512. A prefix below the threshold will not be written to the cache even if marked with cache_control, and no error is returned — this is the case when both cache_creation_input_tokens and cache_read_input_tokens are 0 in the response. See the full breakdown and troubleshooting in Claude Prompt Caching.

OpenAI Compatible Interface

You can set caching breakpoints in system, user (including images), and tools using the cache_control field. The following examples only show the key structure: System Message Caching (default 5 minutes TTL):
User Message Caching (1 hour TTL):
Image Message Caching:
Tool Definition Caching: Place the cache_control at the top level of the tool object (at the same level as type and function):

Anthropic Compatible Interface

Caching Duration

  • Default: 5 minutes
  • Optional: 1 hour (“ttl”: “1h”)
For more information, please refer to: Claude Prompt Caching

Usage Recommendations

  1. Maintain Stable Prefixes
Place fixed content at the beginning of the prompt, recommended structure:
  1. Cache Large Texts
Prioritize caching the following content:
  • RAG data
  • Long texts
  • CSV / JSON data
  • Role settings
  1. Control TTL
  • Short sessions → 5 minutes
  • Long sessions → 1 hour (more cost-effective)
  1. Reduce Cache Writes

Avoid frequently changing content from entering the cache. Do not cache timestamps, user input variables, high-frequency changing data, etc.

Last updated: 2026-07-10