缓存写入为什么要单独计费：created_cache_tokens 拆解

如果你按 OpenAI 的文档去对账，会发现缓存这一栏永远对不上。原因是 OpenAI 的响应里只有 usage.prompt_tokens_details.cached_tokens，表示这次请求命中了多少缓存 token。而缓存的写入量——也就是这次为了让你下次命中而预先存进去的量——OpenAI 根本不返回。

两个字段的区别

{
  "usage": {
    "prompt_tokens": 90,
    "prompt_tokens_details": {
      "cached_tokens": 0,        // 命中：读取已有缓存，便宜
      "created_cache_tokens": 0   // 写入：新建缓存条目，按完整输入计价
    },
    "completion_tokens": 166,
    "total_tokens": 256
  }
}

cached_tokens 是收益侧，created_cache_tokens 是成本侧。一次请求可能只命中不写入（纯读取，最便宜），也可能写入但不命中（首次调用），也可能两者都有（长会话的前缀复用）。把这三个场景混成一个数字看，账单就没法解释了。

实际影响

缓存策略的核心权衡是：写入有成本，命中有折扣。短会话反复调用同一段系统提示词，缓存写入摊薄之后很划算；每次内容都变的场景，写缓存纯亏。所以看到 created_cache_tokens 长期为 0 而你以为自己开了缓存，多半是没开。

前缀稳定性是缓存命中率的决定因素。系统提示词、工具定义、few-shot 示例这些固定部分要放在最前面，可变内容放后面。顺序一变，缓存全部失效，而且从 usage 上看不出原因——你会看到 created_cache_tokens 突然涨上去。