Skip to main content
Prompt Caching reuses repeated context across requests to reduce repeated processing of the same input. It is commonly used for long system prompts, fixed tool instructions, long-document question answering, multi-turn conversations, and codebase analysis. Prompt Caching does not change the model’s generation logic. It only affects how repeated context is processed, request latency, and usage reporting. The model still generates a new response based on the full context in the current request.

Use Cases

  • Long system prompts: Multiple requests reuse the same role definition, output rules, safety boundaries, or product instructions.
  • Fixed tool definitions: In Function Calling scenarios, the tool list, parameter schemas, and tool descriptions remain stable across multiple turns.
  • Long-document follow-up questions: Users ask multiple questions about the same document, contract, paper, or meeting notes.
  • Codebase analysis: Multiple requests reuse the same code snippets, project structure, or constraints.
  • RAG follow-up questions: The first request passes in long retrieval results, and later requests continue asking about the same material.

Supported Models

Prompt Caching support may vary by model and API entry point. Before using it, check the model details on the Models page and confirm in the API guides whether caching is supported, whether it needs to be enabled explicitly, and how cache hits appear in usage reporting.

How It Works

Prompt Caching usually works around repeated context. When an application keeps the same or highly consistent context prefix and message order across multiple requests, the model service may reuse previously processed context where a cache hit is possible. A reusable request usually includes:
  • A stable system prompt.
  • Fixed tool definitions, output formats, or constraint descriptions.
  • Reused long documents, code snippets, knowledge base content, or retrieval results.
  • A user question, small amount of new context, or conversation update that changes on each request.
A typical workflow is:
  1. Put long-lived reusable content in the first half of the request and keep its order stable.
  2. Put the user question or temporary context that changes on each request after the stable content.
  3. Reuse the same prefix and message order across requests, and avoid unnecessary rewriting, reordering, or insertion of dynamic metadata.
  4. Use the response usage or usage page to check whether cache-related fields appear.
  5. Based on latency, cost, and hit behavior, decide whether to continue using long context, switch to RAG, or adjust how context is organized.
Cache hits usually depend on whether the context can be reused. Even if a model supports Prompt Caching, frequently changing prompts, randomly inserted metadata, or constantly reordered messages may reduce cache effectiveness. Hit timing and hit scope may vary by model. Do not assume a specific request will always hit the cache.

Relationship with Long Context and RAG

Prompt Caching, Long Context, and RAG solve different problems: If every request follows up on the same long material, Prompt Caching may work well together with Long Context. If the knowledge base is large and each question only needs a few snippets, use RAG first to reduce irrelevant context.

Key Fields

  • messages: Carries system prompts, history, and reusable context. To improve the chance of reuse, keep the reusable part stable in content, order, and structure.
  • model: Selects the model. Prompt Caching support, hit rules, and usage fields may vary by model.
  • usage.prompt_tokens: The input token count for the request. Long-context requests usually increase this value.
  • usage.prompt_tokens_details.cached_tokens: If returned, this field can help you observe how many input tokens may have hit the cache. Some models may not return this field. Use the API guides as the source of truth for field meaning and billing.
When stream=True is used, cache-related usage information may also appear in the final usage object at the end of the streamed response. Returned fields may vary by model, so the client should handle fields based on whether they are present. Use the API guides as the source of truth for complete request parameters, response fields, and billing rules. This capability page only explains the basic usage pattern and application-side organization principles for Prompt Caching.

Usage Recommendations

  • Keep reusable content and message order stable: Put system prompts, tool definitions, long documents, or fixed constraints in the first half of the request, and keep their content, order, and structure consistent across requests.
  • Put dynamic content later: Put the current user question, timestamps, temporary variables, retrieval additions, or new conversation content after the stable prefix.
  • Avoid unnecessary rewrites: Frequent changes to whitespace, headings, field order, or tool descriptions may reduce the chance of cache hits.
  • Control repeated context size: Caching can reduce repeated processing cost or latency, but it should not be used as a reason to put unlimited content into the context.
  • Observe usage and latency together: If the response returns cached_tokens, or if the usage page shows cache-related metrics, evaluate effectiveness together with request latency and cost.
  • Use with RAG when appropriate: For large knowledge bases, retrieve the most relevant snippets first, while keeping reusable system prompts, tool definitions, or fixed materials stable.
  • Reserve output budget: Prompt Caching mainly applies to input context. Generated output still consumes the max_completion_tokens budget.

Limitations

  • Prompt Caching does not guarantee a cache hit for every request. Hit behavior may be affected by the model, request content, message order, API entry point, and server-side scheduling.
  • The first request, or the first few requests, may not return cached_tokens. Even when later requests hit the cache, hit timing and hit scope may vary by model.
  • Prompt Caching does not make the model remember content outside the request. Materials the model needs must still be provided in the current request, or referenced through a confirmed caching mechanism.
  • Prompt Caching does not change response quality and does not guarantee identical output for the same input.
  • cached_tokens can be used as a signal for observing cache hits, but it is not a complete billing rule. Cache lifetime, whether explicit enablement is required, whether additional fees apply, and how cache hits are billed must be checked in the API guides and model details.
  • If the input exceeds the model’s context limit, Prompt Caching does not replace the context window. You still need to reduce the input, split the task, or choose a model with a larger context window.
  • Do not put sensitive information, one-time credentials, or private user data that should not be reused in reusable context.

Example

The example reads the API Key from an environment variable so the key is not written into code.
This example does not demonstrate a specific cache-enabling parameter. It only shows how to organize stable context that is easier to reuse:
  1. Put fixed rules and long material first.
  2. Put the question that changes on each request later.
  3. Reuse the same stable_context across requests.
  4. If the response returns cached_tokens, print it for observation.
The model in the example is only used to demonstrate the calling pattern. For production use, check the Models page to confirm whether the model supports Prompt Caching and whether the response returns cache-related usage fields.
If you do not see cached_tokens on the first request, send several requests with the same stable prefix and observe the result. Do not rely on any single request to always hit the cache.