OpenCode Go接入GLM-5.2疑似无缓存致费用异常

背景

在当前的 AI 开发工作流中，开发者经常需要整合多种模型服务以优化成本或获取特定能力。本文分享者构建了一条复杂的中转线路：通过自建的 newapi（兼容 OpenAI 格式）接入 GLM-5.2 模型，再经由 cc-switch 中转至 Claude Code 使用。然而，在实际使用中，开发者发现调用成本异常高昂（每次约 0.5 美元），且频繁触发周额度上限。这一现象与预期中的模型缓存机制失效或计费模式异常有关，引发了关于 OpenCode Go 环境下 GLM-5.2 缓存行为及中转链路对缓存影响的探讨。

核心内容

分享者详细描述了其技术栈与遇到的问题。首先，其架构包含三个关键组件：

1. newapi：作为自建的中转服务，提供 OpenAI 兼容格式的 API 接口。
2. GLM-5.2：实际提供推理能力的模型，通过 newapi 接入。
3. Claude Code：最终被调用的开发助手工具，通过 cc-switch 连接到上游服务。

在配置过程中，分享者遇到了 cache_control 参数报错的问题。为了解决这一兼容性问题，在 Claude Code 侧开启了 "DISABLE_PROMPT_CACHING": "1" 的配置，即强制禁用提示词缓存。

尽管采取了上述措施，分享者发现每次 API 调用的费用依然高达 0.5 美元左右。这一成本显著高于预期，特别是与 DeepSeek V4 Pro 等模型相比显得极不划算。此外，由于高频调用且无缓存节省，分享者很快达到了平台的周调用上限。

基于此，分享者提出了两个核心疑问：

1. 在 OpenCode Go 环境中，GLM-5.2 模型是否默认缺乏缓存机制，导致每次调用都按完整的输入输出量计费？
2. 这种经过 newapi 进行 OpenAI 格式到 Claude Code 格式转换的中转方式，是否破坏了原有的缓存逻辑，导致缓存失效？

关键要点

• 架构复杂性：使用了 newapi + cc-switch 的多层中转架构，将 GLM-5.2 模型映射给 Claude Code 使用。
• 配置冲突与妥协：因 cache_control 参数报错，被迫在 Claude Code 中禁用提示词缓存（DISABLE_PROMPT_CACHING: 1），这可能直接导致无法利用上下文缓存降低 Token 消耗。
• 成本异常：单次调用成本约为 0.5 美元，远高于同类模型（如 DeepSeek V4 Pro）的常规预期，且迅速耗尽周额度。
• 缓存机制质疑：
  • 怀疑 OpenCode Go 对 GLM-5.2 的默认实现不支持缓存。
  • 怀疑格式转换（OpenAI 格式转 Claude 格式）的中转过程破坏了缓存键或上下文识别，导致缓存无法命中。
• 计费模式推测：当前的高成本暗示系统可能正在按每次完整的输入输出进行全额计费，而非利用缓存减少重复计算的 Token 数。

意义与影响

此案例揭示了在混合使用不同厂商模型和开发工具时，API 兼容性与缓存机制之间的潜在冲突。

1. 缓存失效的风险：cache_control 参数是许多现代 LLM API 用于实现高效上下文缓存的关键。当开发者因兼容性原因禁用缓存或经过非原生格式转换时，可能无意中放弃了大幅降低推理成本的机会。
2. 中转链路的透明度：使用 newapi 等中间件进行格式转换时，开发者需警惕其是否完整保留了原 API 的高级特性（如缓存）。如果中转服务未能正确传递或处理缓存指令，将导致计费逻辑回归到最昂贵的“无缓存”模式。
3. 成本控制的必要性：对于高频使用的 AI 开发工作流，理解底层模型的缓存行为及中转工具的配置影响至关重要。盲目配置或忽视缓存参数可能导致不可控的成本飙升，影响项目的可持续性。

该分享为其他尝试类似架构的开发者提供了警示：在追求模型灵活性的同时，必须仔细验证缓存机制是否正常工作，并监控实际调用成本，以避免因配置不当导致的资源浪费。