OpenRouter 上线响应缓存，相同请求零 token 计费

你现在可以在 chat completions、responses、messages 或 embeddings 请求中添加 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，这样你就能确切了解缓存的表现。

它最有帮助的场景

Agent 重试。当 agent 工作流在中途失败时，你可以从头重试。已缓存的步骤会即时且免费地返回，因此你只需为新工作付费。

测试套件。反复运行基于 LLM 的测试而无需消耗 token。第一次运行填充缓存后，后续运行是确定性的且免费。

重复的上下文处理。如果你的应用向同一模型发送相同的提示（相同的系统提示、相同的用户输入、相同的参数），只有第一次调用会产生费用。

现已在大多数生成端点上可用

缓存的作用域限定在你的 API 密钥。不同的密钥（即使在同一账户下）不共享缓存条目。

该功能适用于 /chat/completions、/responses、/messages 和 /embeddings。其他端点——旧版 /completions、/audio/speech（TTS）、/audio/transcriptions（STT）、/rerank 以及视频生成——尚不支持。它目前处于 beta 阶段，我们正在观察其表现，然后再确定 API 接口。

缓存命中不计入提供商的速率限制（因为请求从未到达提供商），并且它们会在你的活动日志中显示，并带有缓存指示器，便于监控。

完整详情见文档。