提示词缓存
缓存命中的输入只按新输入的零头计费。一个请求能不能命中，取决于你的代码怎么组织它。
服务商会缓存提示词的开头。之后的请求只要以完全相同的 token 开头，这部分就按缓存输入计费，价格只是普通输入的零头。OhMyGPT 把你组织好的提示词原样交给服务商，所以命中率取决于你自己的代码：每次提示词的开头是否稳定，服务商能否认出哪些请求属于同一个对话。
用 anthropic/claude-haiku-4-5 对同一段 9,150 token 的对话实测：
| 请求 | 缓存 | 费用 |
|---|---|---|
| 第一轮 | 写入 9,147 token | 3,168 Credits |
| 开头相同的下一次请求 | 读取 9,147 token | 275 Credits |
| 同样的提示词，不走缓存 | 无 | 2,535 Credits |
查看命中率
- 单个请求：请求明细里的
usage.cache_read_tokens与usage.cache_creation_tokens。 - 一段时间：用量页的「缓存读取」列，或
GET /v1/usage/summary（需要管理员 Key）返回的tokens.cache_read，可按模型或 API Key 分组。
一次性请求命中率低是正常的。对话和 agent 循环每一轮都会重发之前的内容，大部分输入应当来自缓存。
让提示词的开头保持不变
缓存从第一个 token 匹配到第一处不同为止，之后的内容都按新输入计费。
- 不变的内容放前面：系统提示词、工具定义、长篇参考资料；用户的新消息放最后。
- 系统提示词逐字节保持不变。里面带时间戳、请求 ID、用户名或随机排序的示例，每次都会打断命中；这些内容放进最新一条消息。
- 对话只往后追加。修改、裁剪或总结之前的消息，会让那条消息之后的缓存全部失效，所以少做，要做就一次多处理一些。
- 每一轮发送相同的工具、相同的顺序，JSON 序列化时键的顺序固定。
- 同一个对话里不换模型，每个模型的缓存各自独立。
- 太短的提示词不会被缓存，最短长度因模型而异。
标出哪些请求属于同一个对话
每一轮都发送同一个会话级的值，服务商才能把重复的提示词送到同一份缓存：
| 端点 | 字段 |
|---|---|
| Chat Completions、Responses | prompt_cache_key 或 provider.conversation_id（不超过 256 字节） |
| Anthropic Messages | metadata.user_id |
curl https://api.ohmygpt.com/v1/responses \
-H "Authorization: Bearer $OHMYGPT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "openai/gpt-5.4-nano", "prompt_cache_key": "conv-8f2c", "instructions": "<the same long instructions every turn>", "input": "Hi"}'用 8,351 token 的提示词连发两次，第二次响应的 usage.input_tokens_details 里是 "cached_tokens": 7936。
Claude 只缓存请求里标记过的内容。通过 Chat Completions 或 Responses 调用 Claude 时，多轮请求（带会话标识，或历史里已有助手回合）由 OhMyGPT 代为标记；单轮请求不标记，因为写入缓存比普通输入贵，上表里不走缓存的就是去掉助手回合的同一个请求。通过 Anthropic Messages 调用时，请求原样到达 Claude，需要自己加 cache_control。Claude Code 会加，并在每个请求里带上会话 ID，开箱即用。