DeepSeek 崩了一天，一堆编码 agent 集体停摆

DeepSeek 今天崩了，连带一批依赖它的编码 agent 集体停摆。

这类故障暴露的东西比故障本身有意思。过去一年很多 agent 产品的架构是这样的：调度和工具链自己做，推理全部外包给一个性价比最高的 API。DeepSeek 的价格在同档能力里一直是最低的那一档，所以成了默认选择。

然后单点故障就有了。上游一断，整个产品的核心能力归零——不是变慢、不是降级，是彻底不工作。用户那边看到的是自己的工具坏了，不是 DeepSeek 坏了。

CommandCodeAI 的创始人第一时间借势推荐用户迁过来，摆的条件是 60 美元用量额度和 99% 以上的缓存命中率，顺带点了 OpenCode 一句额度更低、缓存成本更高。这个动作很快，也很懂时机。

缓存命中率被摆在营销位上是个信号。编码 agent 的请求里有大量重复内容——同一个仓库的文件、同一份系统提示、同一段上下文会被反复发送。缓存命中价和未命中价通常差好几倍，所以对这类产品来说，命中率直接决定毛利，比模型单价更关键。

真正该做的事是多上游。同一套 agent 框架挂两三家 API，按可用性和价格自动切换，成本大概是多写一层适配和多维护一份 prompt 兼容性。做了的产品今天没事，没做的今天在 X 上道歉。

另一个角度，Command Code 上周刚上线了三款新模型——DeepSeek V4.1 Flash、支持最大推理能力的 Muse Spark 1.3，以及免费的 Ling 3.0 Flash Sante。多一个选择就多一条退路，这轮宕机大概会让不少团队重新看一眼自己的上游列表。

顺带说，DeepSeek 恢复之后这些用户会不会迁走，取决于他们有没有在今天真的丢过活。