你现在可以在聊天补全、响应、消息或嵌入向量请求中添加 `X-OpenRouter-Cache: true`,以开始缓存完全相同的调用。首次调用会访问模型提供商并按正常方式计费。此后每次完全相同的调用都会在极短的时间内返回相同的响应,且不产生任何 token 费用。
它的作用
响应缓存位于模型提供商之前。当你发送一个启用了缓存的请求时,OpenRouter 会将请求体、模型、API 密钥和流式模式哈希成一个缓存键。如果之前有过相同的请求且尚未过期,缓存的响应会立即返回。无需调用提供商,不消耗 token,不产生费用。
流式和非流式请求均可使用。缓存的流式响应会通过相同的管道重放,因此你的客户端代码无需更改。文本、图像、音频、文档和工具调用均可正常缓存。多模态输入(base64 图像、音频片段、文件附件)也会包含在缓存键的哈希中。一个注意事项:内部为处理而卸载的非常大的多模态负载不符合缓存条件。标准大小的请求可以正常缓存。
响应缓存与提示词缓存是分开的。提示词缓存(许多提供商原生支持)在消息共享共同前缀时降低提示词部分的成本。响应缓存则完全绕过提供商,从 OpenRouter 的边缘缓存返回完整响应。
将响应时间从秒级降至毫秒级
缓存的响应在 80-300 毫秒内返回,其中大部分时间是序列化和网络传输。缓存查找本身平均耗时 4 毫秒。作为对比,一个典型的未缓存请求,Gemini 2.5 Flash 大约需要 1.3 秒,Kimi K2.6 需要 4.6 秒,GPT-5.5 需要 9.1 秒。缓存命中不计费:无提示词 token、无补全 token、无费用。
通过请求头或预设启用
在你希望符合条件的每个 API 调用中添加 `X-OpenRouter-Cache: true` 请求头:
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-H "X-OpenRouter-Cache: true" \
-d '{
"model": "google/gemini-2.5-flash",
"messages": [{"role": "user", "content": "What is the meaning of life?"}]
}' 预设。通过在预设配置中设置 `cache_enabled: true`,为使用特定预设的所有请求启用缓存。单个请求上无需添加请求头。
您可以通过 `X-OpenRouter-Cache-TTL` 控制响应的缓存时长(1 秒到 24 小时,默认 5 分钟)。需要全新响应?发送 `X-OpenRouter-Cache-Clear: true` 即可清除该特定请求的缓存。
响应标头会告知您缓存状态:`X-OpenRouter-Cache-Status: HIT` 或 `MISS`,外加 `X-OpenRouter-Cache-Age` 和 `X-OpenRouter-Cache-TTL`,让您精确了解缓存的运行情况。
最适用的场景
智能体重试。当智能体工作流中途失败时,您可以从头开始重试。已缓存的步骤会即时返回且完全免费,因此您只需为新的计算付费。
测试套件。反复运行基于大语言模型的测试,而无需消耗模型 token。首次运行填充缓存后,后续运行将具有确定性且完全免费。
重复的上下文处理。如果您的应用向同一模型发送相同的提示词(相同的系统提示词、相同的用户输入、相同的参数),则只有首次调用会产生费用。
现已适用于大多数生成端点
缓存范围限定在您的 API 密钥内。不同的密钥(即使属于同一账户)不会共享缓存条目。
该功能适用于 `/chat/completions`、`/responses`、`/messages` 和 `/embeddings` 端点。其他端点——旧版 `/completions`、`/audio/speech`(TTS)、`/audio/transcriptions`(STT)、`/rerank` 以及视频生成——暂不支持。目前该功能处于测试阶段,我们正在观察其表现,之后再确定最终的 API 接口。
缓存命中不计入提供商速率限制(因为请求从未到达提供商),并且在您的活动日志中会显示缓存指示器,便于监控。
完整详情请查阅文档。
You can now add X-OpenRouter-Cache: true to your chat completions, responses, messages, or embeddings requests to start caching identical calls. The first call hits the provider and gets billed normally. Every identical call after that returns the same response in a tiny fraction of the time, with zero tokens billed.
What it does
Response caching sits in front of the model provider. When you send a request with caching enabled, OpenRouter hashes the request body, model, API key, and streaming mode into a cache key. If an identical request was made before and hasn’t expired, the cached response comes back immediately. No provider call, no token consumption, no charge.
Both streaming and non-streaming requests work. Cached streaming responses replay through the same pipeline, so your client code doesn’t need to change. Text, images, audio, documents, and tool calls all cache normally. Multimodal inputs (base64 images, audio clips, file attachments) are included in the cache key hash. One caveat: very large multimodal payloads that get offloaded internally for processing aren’t eligible for caching. Standard-sized requests cache fine.
Response caching is separate from prompt caching. Prompt caching (which many providers offer natively) reduces the cost of the prompt portion when messages share a common prefix. Response caching skips the provider entirely and returns the full response from OpenRouter’s edge cache.
Reduces response times from seconds to milliseconds
Cached responses come back in 80-300ms, most of which is serialization and network. The cache lookup itself averages 4ms. For comparison, a typical uncached request to Gemini 2.5 Flash takes about 1.3 seconds, Kimi K2.6 takes 4.6 seconds, and GPT-5.5 takes 9.1 seconds. Cache hits are billed at zero: no prompt tokens, no completion tokens, no charge.
Enable it with a request header or with presets
Add the X-OpenRouter-Cache: true header to each API call you want to be eligible:
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-H "X-OpenRouter-Cache: true" \
-d '{
"model": "google/gemini-2.5-flash",
"messages": [{"role": "user", "content": "What is the meaning of life?"}]
}' Presets. Enable caching for all requests using a specific preset by setting cache_enabled: true in the preset config. No header needed on individual requests.
You can control how long responses stay cached with X-OpenRouter-Cache-TTL (1 second to 24 hours, default 5 minutes). Need a fresh response? Send X-OpenRouter-Cache-Clear: true to bust the cache for that specific request.
Response headers tell you what happened: X-OpenRouter-Cache-Status: HIT or MISS, plus X-OpenRouter-Cache-Age and X-OpenRouter-Cache-TTL so you can see exactly how the cache is performing.
Where it helps most
Agent retries. When an agent workflow fails partway through, you can retry from the top. Cached steps return instantly and for free, so you only pay for the new work.
Test suites. Run your LLM-backed tests repeatedly without burning tokens. After the first run populates the cache, subsequent runs are deterministic and free.
Repeated context processing. If your app sends the same prompt to the same model (same system prompt, same user input, same parameters), only the first call costs anything.
Available now across most generation endpoints
The cache is scoped to your API key. Different keys (even under the same account) don’t share cache entries.
The feature works across /chat/completions, /responses, /messages, and /embeddings. Other endpoints — legacy /completions, /audio/speech (TTS), /audio/transcriptions (STT), /rerank, and video generation — are not yet supported. It’s currently in beta, and we’re watching how it performs before locking down the API surface.
Cache hits don’t count toward provider rate limits (since the request never reaches the provider), and they’re visible in your Activity log with a cache indicator for easy monitoring.
Full details in the docs.