始终设置 x-grok-conv-id（Responses API 使用 prompt_cache_key），将请求路由到同一个 Server，最大限度提高 cache hit rate。
使用稳定的 conversation ID — UUID 或应用的 session ID 都是合适的选择。
绝不要修改先前的 message — 只能追加新的 message。任何编辑、删除或重新排序都会破坏 cache。
将静态内容前置 — 将 system prompt、few-shot 示例和参考文档放在开头，形成稳定的 prefix。
监控 cached_tokens — 如果始终为 0，请检查 conversation ID 和 message 顺序。
妥善处理 cache miss — Cache 清除和请求路由意味着无法保证 cache hit。应用在没有 cache 的情况下也应正常工作。

支持的模型

Prompt Caching 适用于所有 grok language model。请查看价格页面，了解支持 caching 的模型及其具体 cached token 价格。

FAQ

不会。Caching 只会加速 prompt 处理阶段。无论 prompt 是从 cache 提供还是从头计算，模型输出都完全相同。

Cache entry 可能因 Server 负载或重启而随时被清除。请使用 x-grok-conv-id 将请求路由到同一个 Server，最大限度延长保留时间。

可以，使用不同的 x-grok-conv-id，或完全省略该 header。这会将请求路由到另一个可能没有该 prompt cache 的 Server。

支持。Prompt Caching 同时支持 streaming 和 non-streaming 请求。Stream 中的第一个空 token 对应 cache lookup 和 prefill 阶段。

支持。可缓存的 prefix 包括截至 Tool Call Result 在内的所有 message。只要 prefix 保持不变，后续请求就能受益于 caching。