烧了 $1486 才搞懂的 AI 编程省钱套路

AI 编程的成本，不是"用了多少 token"，而是"有多少 token 是全价计费的"。

前言

前阵子整理了一下过去 7 周的 AI 编程账单，合计消费 $1486，总 token 消耗 28.8 亿。

第一反应是 woc，怎么这么多。第二反应是不对啊，28.8 亿 token 如果全价计费，按市场均价早破万美元了，这里一定有猫腻。

于是我把 token 用量和费用两张表拉到一起拆开看，还把自己这两个月对 opencode 工具链做的每一轮配置调整也叠上去，按时间线一对，发现每个改动都在账单上留下了痕迹。这篇文章就把这个过程拆给你看。

先看账单长啥样

先上一张表，这是 7 周的 token 汇总：

92.69% 的 token 是缓存读取。缓存读取的计费和新鲜输入不是一回事——各家的缓存命中都有折扣，DeepSeek 官方缓存命中价是未命中的 1-2%，Claude 是 10%，Gemini 是 10-25%。不过我这边走的是阿里云代理的 DeepSeek 服务，价格比官方高一些，折扣没官方那么狠，但缓存命中比未命中便宜很多这个结论还是成立的。我的账单上 cache 这一项费用列虽然是 0，但那是因为供应商把缓存读取的费用合并进了 input cost 里，并不是真的不计费。

再看费用拆解：

输入占 56%，输出占 31%。这个比例符合 AI 编程的典型场景：每次对话你要把整个代码库的相关部分、历史对话、工具定义全塞进去，但模型回你的可能就几百字。输入费用自然是大头。

从这两张表能看出一个大概——缓存是省钱的头号功臣。但光靠缓存不够，真正让账单从"破万美元"压到 $1486 的，是接下来这两个月里一轮一轮的配置调整。下面按时间线讲。

6 月初：混沌期，日均 $58

6 月前两周是账单的高峰期。6/8 到 6/14 那一周花了 640，单日峰值 6/9 达到 217。

这段时间配置基本是出厂状态：主模型用 Claude Sonnet 4.6，轻量任务用 Claude Haiku 4.5，还没做什么针对性优化。Haiku 有个韩文污染的问题——偶尔会用韩文回复，虽然不影响功能但挺烦人。Sonnet 单价贵，但因为没怎么调路由，什么活都往它身上扔。

费用高的原因很直接：大量新鲜输入走全价计费。那段时间我在做新模块的探索，上下文一直在变——每读一个新文件、每搜一次函数，前缀都在膨胀和变化，缓存根本建立不起来。全价输入 × 高价模型 × 大 token 量，费用自然飙上去了。

这段混沌期让我意识到一件事：光靠模型自己便宜是不够的，得让缓存能命中，得让便宜模型干该干的活。

6 月 22 日：第一次降级，日均降到 $29

6 月 22 日这天我做了第一轮调整。

先是把 opus-4-8 降级成 sonnet-4-6。Opus 单价太高，大部分任务用 Sonnet 就够了，Opus 留在 fallback 链里兜底就行。这一步省得不多，但开了个头。

真正的转折点是 6 月 26 日——我弃用了 Haiku 4.5，把 small_model 换成 DeepSeek V4 Flash。原因之一是韩文污染，原因之二是价格：Haiku 是 Claude 系列里最便宜的，但 DeepSeek V4 Flash 比它还便宜一个量级。标题生成、简单分析这类杂活，用 V4 Flash 完全够用，没必要用 Haiku。

这一轮之后，周费用从 640 降到 205，日均从 58 降到 29，砍了一半。

注：small_model 看起来不起眼，但它处理的是标题生成这类高频低复杂度的活，量大了累计费用很可观。把它从 Haiku 换成 V4 Flash，是这轮降幅最大的一刀。

7 月 1 日：规则体系 + 模型路由 + mem 插件，日均砸到 $9

7 月 1 日这天干的事最多，也是整个时间线上降幅最大的一天。

规则体系重构。之前我的全局规则都堆在一个文件里，长到滚屏要滚一会儿。这天我把总文件拆成目录，规则按性质分成三类：人格设定（personality-*）、硬规则（rule-*）、流程规范（workflow-*）。总文件只负责索引，加了一张速查卡放在最开头，覆盖最常触发、最容易忘的规则。还加了一张触发词映射表，让规则在该出现的时候出现。

规则优化对成本的影响是间接的——规则清楚了，AI 就不用反复试错。少了试错，就少了重复的来回对话，每轮对话的 token 都是真金白银。一条规则如果能避免一次返工，省下的可能就是几万 token。

模型路由大调整。同一天我把 omo 插件的模型配置也改了：explore 和 librarian 这两个探索类 Agent，主模型从 V4 Pro 降级成 V4 Flash。理由是基准测试显示两者性能差距只有 1.6 个百分点，但价格差 3 倍（V4 Flash 0.14 vs V4 Pro 0.435）。探索任务对推理能力要求不高，用 Flash 就行。同时给关键 Agent 补了三层 fallback 链，开了 runtime_fallback——API 报错时自动沿回退链切换，不用人工干预。

mem 插件换模型。7 月 2 日，我把 opencode-mem 的后台模型从 GPT-5.4 mini 换成了 DeepSeek V4 Flash。mem 插件在后台做记忆捕获和上下文压缩，这些活不需要强模型，用便宜模型就行。这一步省的是"看不见的 token"——后台处理虽然不直接出现在对话里，但每次都在计费。

这一轮之后，周费用从 205 砸到 64，日均从 29 降到 9，又砍了 84%。

注：7 月 1 日这天同时动了规则、路由、mem 三件事，效果叠加。但如果非要排个贡献，模型路由调整（explore/librarian 降级）是直接省钱的大头，规则优化是间接省钱的长尾，mem 换模型是省"看不见的钱"。

7 月 7 日：sonnet-5 实验，日均反弹到 $22

降到这里之后，我做了一个实验——把 7 个主要 Agent 的主模型升级成 Claude Sonnet 5。

想法是：Sonnet 5 比 4.6 强，是不是能提高单轮完成率，减少来回次数？结果费用反弹了。7/6 到 7/12 那一周花了 154，日均 22，比前一周翻了一倍多。

原因很直白：Sonnet 5 单价是 $2/百万 token，比 V4 Pro 贵了 4 倍多。虽然模型强了，但我的大部分任务并不需要那个级别的推理能力——探索代码、改脚本、跑校验，V4 Pro 完全够用。用 Sonnet 5 处理这些，就像用跑车送外卖。

这次实验让我认清了一件事：模型不是越强越好，是够用就好。强模型的正确用法是放在 fallback 链里兜底，而不是当主模型天天跑。

7 月 16 日：切回 V4 Pro，日均回到 $10

认清之后，7 月 16 日我把 9 个主要 Agent 的主模型切回 DeepSeek V4 Pro，Sonnet 4.6 降到 fallback 第一顺位。

这一轮之后，周费用从 154 降到 74，日均从 22 回到 10。基本回到了 7 月 1 日那轮的水平。

切回 V4 Pro 的逻辑是：V4 Pro 有 1M 上下文窗口（Sonnet 4.6 只有 200K），单价便宜，缓存命中率高，干活的性价比最高。Sonnet 留在 fallback 里，只有 V4 Pro 挂了才顶上。

注：这次来回折腾验证了一个判断——对我这种"大量读代码 + 少量写代码"的场景，DeepSeek V4 Pro 是甜点位。Claude 系列的优势是推理质量和工具调用稳定性，适合放在兜底层，不适合当主力烧钱。

7 月 21 日：规则精修，日均稳定在 $9

最后一轮是 7 月 21 日到 22 日，做了两次规则层面的精修。

21 日新增了 R17 规则——所有时间相关操作优先走 TimeUtil。这事看起来和成本无关，但实际有关：之前时间操作散落在各处，有的用 os.time，有的用 GetServerTimeNow，AI 每次遇到都要判断该用哪个，判断不准就返工。统一走 TimeUtil 之后，AI 不用猜了，返工少了，token 就省了。

22 日把 R07 规则从"全面禁止 subagent"改成"分级委派"。之前因为 subagent 频繁超时，我一刀切禁了。后来做了极限测试，发现单次探索和大范围遍历其实是稳定的，只有多步串行长链条才超时。改成分级委派后，能并行的探索就并行，该主代理直连的就直连，减少了串行等待的 token 消耗。

这一轮之后，周费用稳定在 27（7/20-7/22，只有 3 天），日均 9。和 7 月 1 日那轮的低位持平，但这次是靠规则优化托住的，不是靠模型降级硬压的。

把时间线拉平了看

从 58 到 9，整体降了 84%。中间有个 sonnet-5 的反弹，但那是一次有价值的实验——它帮我确认了 V4 Pro 是甜点位。

三个底层套路

时间线讲完了，把这些改动背后的原理拆出来，其实就三个底层套路。

Prompt Caching

所有 LLM API 都是无状态的——每次请求必须重新发送完整上下文。但多轮对话中前缀几乎不变，Caching 就是让 API 复用这些重复前缀的计算结果，按折扣价计费。

三家厂商对比：

我的账单缓存命中率 95.36%。但缓存有个坑：前缀中任何一个 token 变了，缓存全部失效。常见的缓存杀手——system prompt 塞时间戳、对话中途切模型、修改工具定义、JSON 序列化 key 顺序不稳定。6 月初费用高，很大一部分原因就是探索阶段上下文一直在变，缓存建不起来。

注：监控 cache_hit_tokens 和 cache_miss_tokens，命中率低于 80% 就该排查了。

模型路由

不是所有任务都配用最贵的模型。我的配置是两级路由：第一级按任务类型分 Agent，探索类走只读 Agent 用小模型，开发类走全权限 Agent 用大模型；第二级接复杂度路由器，根据 prompt 复杂度自动选模型。

opencode 的配置大概长这样：

{
  "model": "deepseek/deepseek-v4-pro",
  "small_model": "deepseek/deepseek-v4-flash"
}

model 是主模型干重活，small_model 是轻量模型处理标题生成这类杂活。omo 插件里还能给每个 Agent 单独配 fallback 链，API 报错时自动回退。

路由最大的风险是：便宜模型失败了中途切回贵模型，前面便宜模型消耗的 token 全浪费。所以路由策略的关键是把任务边界划清楚——明确的、可验证的任务给便宜模型，模糊的、需要反复迭代的任务一开始就上贵模型，反而更省。

Memory 插件

AI Agent 的 token 消耗是平方级增长的——50 步的 agent loop，第 50 步的上下文是第 1 步的 50 倍。76% 的 agent token 花在"读代码 & 导航"上。

Memory 插件的逻辑是：花少量 token 存储上下文，省大量重复探索的 token。

无 Memory：
  每次新会话 → 重新探索代码库 → 5000-20000 tokens 探索开销

有 Memory：
  每次新会话 → memory_search（~100 tokens）
             → 检索结果（~800 tokens）
             → 跳过探索，直接干活

我的用法是每完成一个任务记一条，内容含原始诉求、改了哪些文件、关键逻辑变更、校验结果、待办、架构发现。下次新会话第一步先 memory search 恢复上下文。

但 memory 是参考不是权威——摘要会丢细节，会固化错误理解。正确的用法是拿 memory 当线索定位"这件事有记录、在哪条记录里"，再去原始文档、代码核实。两者矛盾时，原始文档优先。

三个套路怎么配合

把三个套路放一起看，它们作用在不同环节：

┌─────────────────────────────────────────────────┐
│  每轮对话的 token 构成                            │
│                                                   │
│  [缓存命中的前缀]  ←── Prompt Caching             │
│  [Memory 注入的上下文] ←── Memory 插件            │
│  [本次新增输入]    ←── 模型路由（选谁处理）       │
│  [模型输出]        ←── 模型路由                   │
└─────────────────────────────────────────────────┘

Caching 省"前缀"，Memory 省"探索"，Routing 省"模型"。但时间线告诉我，它们不是并列的，是有先后顺序的：Memory 先把探索成本降下来，上下文稳定之后 Caching 才能命中，最后 Routing 决定用哪个模型处理增量。顺序反了，效果会打折。

三个加一起的效果：我的账单里，真正按全价计费的 token 只有 4.95%（新鲜输入 + 输出），其余 92.69% 的缓存读取走折扣价，2.35% 的缓存写入费用也低。最终混合均价 $0.52/百万 token。这个数字如果不做任何优化，至少是 5-10 倍。

写在结尾

折腾这套工具链前前后后两个月，期间也没少怀疑自己是不是在配置上花的时间比省下来的钱还多。

但把账单按时间线拆开看的那一刻，感觉还是值得的。从日均 58 到 9，每个改动都在账单上留下了痕迹，没什么比这个更实在的了。

还有一些没想清楚的地方，比如怎么在多人协作里共享这套配置，规则文件本身怎么做版本管理。等有空了再琢磨。

感谢你看完了我的这点絮叨。