How does OpenAI's Responses API prompt-cache prewarming work?

A prompt cache only helps on the request that reuses it. The first request on a cold cache still pays full latency, and if that first request is the one your user is waiting on, caching has not saved them anything. OpenAI’s Responses API just shipped a field built specifically to move that cost earlier, and because it landed inside a beta SDK release with no accompanying blog post, almost nothing has explained what it actually does.

What does OpenAI’s Responses API prewarm field do?

openai-python v3.15.0, released 18 September 2026, adds a prewarm boolean to ResponseCreatePromptCacheOptions. The SDK docstring is explicit: it “prepares the prompt cache without generating output” and “overrides the generate field to false” when set true. The field arrived alongside a second new feature in the same release, managed Responses WebSocket sessions, and prewarm lives inside that mechanism rather than as a parameter on the plain POST /v1/responses endpoint. A client opens a persistent WebSocket connection, then sends a ResponseCreate client event, which the SDK describes as carrying “the same top-level fields as POST /v1/responses, plus WebSocket-only envelope metadata” such as a stream_id. Setting prompt_cache.prewarm to true on one of those events writes the cache and returns nothing, by design.

A prewarmed turn inside a Responses WebSocket session

Show as text

A prewarmed turn inside a Responses WebSocket session. Sequence diagram between Client and Responses API. 1. Client to Responses API: ResponseCreate, prompt_cache.prewarm=true. 2. Responses API to Client: cache write completes, empty content. 3. Client to Responses API: ResponseCreate, real user turn. 4. Responses API to Client: response served from warm cache.

#	From	To	Message
1	Client	Responses API	ResponseCreate, prompt_cache.prewarm=true. generate forced to false
2	Responses API	Client	cache write completes, empty content. billed as a cache write
3	Client	Responses API	ResponseCreate, real user turn
4	Responses API	Client	response served from warm cache. faster first token

How does prewarm interact with the generate field?

The interaction is a one-way override rather than an independent flag. generate normally controls whether a ResponseCreate event produces model output at all, and the prewarm docstring states that setting prewarm true forces generate to false regardless of what you passed. There is no combination that primes the cache and returns a real answer in the same call: you cannot ask for both. That matters for how you wire it into an application. A prewarm call has to be treated as a side effect you fire and never read from, sent on its own client event, ahead of the request whose output you actually want. Sending it as an afterthought attached to a real turn does nothing, because by definition that combination never generates a response for the user to see.

What do the mode and ttl fields on the cache options control?

Two more fields sit on the same ResponseCreatePromptCacheOptions object. mode is a literal "implicit" or "explicit" that controls whether the API creates cache breakpoints automatically as a conversation grows or only where the caller places them, independent of whether a given call prewarms. ttl is typed to accept only the literal string "30m", which the docstring calls “the minimum lifetime for cache breakpoints.” No shorter or longer value is defined in the SDK today. A fourth field, comparison_response_id, lets a caller reference an earlier response for diagnostic purposes when checking whether a cache actually reused work. Together these four fields are a more explicit cache control surface than a single boolean, but the fixed TTL is a real constraint: there is currently no way to request a shorter window for a tight request loop or a longer one for a slow-moving conversation.

Prompt cache TTL by provider and tier

Show data

Prompt cache TTL by provider and tier. Bar chart. OpenAI Responses, fixed: 30 minutes. Claude, default: 5 minutes. Claude, extended: 60 minutes.

Item	Value (minutes)	Note
OpenAI Responses, fixed	30	only value the field accepts today
Claude, default	5	ephemeral, no extra cost
Claude, extended	60	costs 2x the write price

How does this compare with Claude’s own cache priming?

Anthropic documents the same effect through a plain request rather than a dedicated field: set max_tokens to 0 and put cache_control on the prefix you want stored. The call returns immediately with an empty content array and stop_reason of max_tokens, and usage.cache_creation_input_tokens confirms the write. Claude’s TTL is configurable rather than fixed: 5 minutes by default at no extra cost, or 1 hour at twice the normal cache-write price if you need the window open longer. OpenAI’s version is newer, self-documenting through a named field instead of a side effect of max_tokens=0, and it sits inside a session model built for reuse across many turns. Claude’s version has existed since prompt caching launched and gives you a price-versus-duration choice that OpenAI’s fixed 30 minutes does not.

When does prewarming actually change what a user experiences?

Prewarming only pays off when you can predict a turn before it arrives and the gap before it lands fits inside the TTL. A support widget that starts loading a session the moment a user opens a chat window, a voice agent that knows a caller is about to speak, or a batch job that primes a shared system prompt before fanning out to workers are all real cases. A one-shot API call with no advance signal is not, because there is nothing earlier to prewarm ahead of. The session model changes covered when Claude added on-demand compaction point at the same shift: both vendors are building explicit controls around what used to be an implicit side effect of normal traffic, and prewarming is the caching half of that move. Treat the fixed 30 minute window as the real limit on OpenAI today, and budget Claude’s paid 1 hour tier only where the gap between turns actually needs it.