在多轮交互场景中，智能体每一轮均需重复提交相同的系统提示、工具定义、架构规范及策略指令。即便一个6轮对话中，仅用户最新输入或工具返回结果发生变化，开头那段冗余内容仍可能被计费6次。OpenRouter近期上线的 Prompt Caching 功能，结合 Sticky Routing 机制，正是为应对这一隐性成本漏洞而设计。

Prompt Caching 的核心原理在于：服务提供商从本地缓存中读取提示中稳定不变的部分，而非每次都按完整输入价格计费。Sticky Routing 则通过将整个会话绑定至已加载热缓存的同一提供商节点，确保该优化在跨轮次中持续有效。

缓存读取成本仅为常规输入的 0.1 至 0.5 倍

不同供应商对缓存读取的定价存在差异。以 Anthropic Claude Sonnet 4.6 为例，缓存读取单价为每百万 token 0.30 美元，而标准输入费用为 3.00 美元，恰好为 0.1 倍。DeepSeek 与阿里通义千问亦提供同等 0.1 倍折扣；OpenAI 区间为 0.25–0.5 倍；Gemini、Grok 及月之暗面统一为 0.25 倍；Groq 则为 0.5 倍。

但缓存并非零成本方案。首次请求需承担缓存写入开销，且部分厂商的写入费率甚至高于普通输入。Anthropic 默认 5 分钟 TTL 的写入费用为输入价的 1.25 倍，若选择 1 小时 TTL，则升至 2.0 倍——若该缓存从未被复用，总支出反而高于不启用缓存的情形。OpenAI GPT-5.6 及后续版本写入成本为输入价的 1.25 倍；Google Gemini、Grok、月之暗面与 Groq 的写入操作则完全免费。

热缓存背后的隐藏风险：提供商漂移

一旦完成缓存写入，若下一轮请求被调度至另一家提供商，原有热缓存即失效。OpenRouter 当前接入超 70 家模型服务商，第二轮命中冷端点的概率不容忽视。这正是 Sticky Routing 的关键价值所在——当检测到某提供商的缓存读取单价低于其常规输入价时，后续请求将被强制路由回该节点；仅当该节点不可用时，才降级至下一个可用节点，而非直接失败。

默认情况下，OpenRouter 依据对话首条系统消息与首条非系统消息的哈希值识别会话。然而智能体常在轮次间动态重写初始消息（例如更新状态摘要、调整工具上下文顺序），导致哈希值变动、会话标识错乱。推荐解法是显式传入 session_id。设定后，OpenRouter 直接以其作为粘性路由键，粘性策略自首次成功请求起即生效，无需等待缓存命中才启动。session_id 可置于请求体顶层字段，或通过 x-session-id 请求头传递，须在整个对话生命周期内保持唯一且稳定，长度不超过 256 字符。

缓存未命中的四大常见诱因

其一为提示长度未达最低阈值。Anthropic Claude Opus 4.5–4.8 与 Haiku 4.5 要求至少 4096 token；Haiku 3.5 需 ≥2048 token；Sonnet 4/4.5/4.6 与 Opus 4/4.1 均需 ≥1024 token；OpenAI 同样要求 ≥1024 token；Gemini 2.5 Pro 设定为 ≥4096 token，Flash 版本则为 ≥1024 token。

其二系缓存过期。Anthropic 默认 TTL 为 5 分钟，支持手动延长至 1 小时；Gemini 实施隐式缓存，有效期约 3–5 分钟，且读取行为不会刷新 TTL。

其三为提示头部内容频繁变更。应将固定要素（如系统指令、工具声明、交互模式、参考材料）前置，而将易变内容（如用户提问、时间戳、工具执行结果）后置。若第一条系统消息中嵌入实时时间戳，会导致每轮提示被视为全新输入，此类字段如无必要，建议移至后续消息中。

其四为请求被分发至不同提供商。智能体工作流务必设置 session_id 并依赖粘性路由，以维持会话始终运行于已预热的提供商之上。若手动指定 provider.order 参数，将覆盖粘性路由逻辑。

成本节约效果随轮次递增显著。针对多轮对话，若重复内容随交互自然增长，可启用自动缓存；若明确知晓哪些大块文本需长期复用（如检索所得文档、长篇参考资料、角色设定卡、结构化 CSV 数据），宜采用显式缓存断点；对于智能体对话、客服工单、实时聊天线程、自动化工作流等场景，尤其当开场消息存在轮次间动态变化时，必须使用 session_id；对于较长的 Anthropic 会话，若默认 5 分钟缓存易过期，应主动配置 1 小时 TTL。

验证缓存是否生效，可通过响应体中 usage.prompt_tokens_details.cached_tokens 字段判断——数值大于零即表示命中；cache_write_tokens 显示本次写入量；cache_discount 则反映单次生成所获成本减免。上述指标亦可在 Activity 页面或 /api/v1/generation 接口响应中获取。