实测：给记忆系统降推理档，账本上通常不省钱（24h 观测 + 三臂对照）

[maozhuoshushu]

TL;DR：给你的记忆系统降推理档，账本上通常不省钱。我把 reasoning_effort 从默认降到 off，每次请求成本反而 +10.5%——思考 token 归零后模型把预算挪去吐正文。真正省钱的只有「点名关掉不该思考的那条链路」：只对一条记忆抽取链路降档，每次 −71%。

完整报告与可复现方法：https://github.com/maozhuoshushu/reasoning-cost-audit

---

我在自建的 OpenViking 上做了一次 24 小时生产观测 + 三臂对照（不改代码、只改运行参数），顺手踩完了几个很贵的坑，写下来给同样觉得 token 账单不对劲的人参考。所有数字来自真实账本与插桩日志，没有估算。

五条结论

1. 降档不省钱。全局降到 off：每次 $0.0140 → $0.0155（+10.5%）。思考归零了（reasoning 2,593 → 225），但 completion 和输入都涨了，总量没降。
2. 点名关链路才省钱。只对 long_term_memory_extraction 一条链路降档：每次 $0.016731 → $0.004796（−71%）。同一条链路的思考从 7,119 → 0。
3. 覆盖面比幅度重要。我第一版补丁的白名单只覆盖 28.65% 的调用，而 87.05% 的思考 token 在另一条被漏掉的链路上（long_term_memory_extraction）。不先修覆盖面就开实验，等于白跑三天。
4. 账面变便宜 ≠ 变高效。某一个窗口的 $/1k 输出比上一窗低 17.85%，做结构/强度分解后发现 99.76% 来自流量搬去更便宜的平台（opendesign 的价基恰为 command-code 的 0.5 倍），真实效率提升只有 0.24%。
5. 「24 小时」不等于「24 小时有效观测」。机器重启、网关换进程、计划任务抢端口都会让窗口出缺口；不剔除缺口按墙钟算速率，结果能差 34%。

三个值得单独说的坑

坑一：开关设了，参数一次都没发出去。
openai_vlm.py 的 _is_reasoning_model() 只按前缀白名单判断，我的模型名是别名（auto/xxx），不在前缀表里 ⇒ kwargs["reasoning_effort"] 那行永远进不去。2,136 条调用里带参数的是 0 条。补丁写好了、环境变量也设了，全靠这个「静默不发」白跑。

坑二：金额单位错了 1000 倍。
价基是「美元/百万 token」，我按「/千 token」算，于是整份报告里所有金额都放大了 1000 倍。自查方法很简单也很值得抄：拿单笔中位数和自己对账单的量级对一下，对不上就是单位错了。

坑三：白名单漏了最大的那条链路。
补丁的判断是 op.startswith("memory") or op in (...)，而实际调用里最大的 op 叫 long_term_memory_extraction，既不以前缀命中、也不在四个别名里。覆盖率算下来：archive_summary 只占 7.09% 的 reasoning token，漏掉的那条占 87.05%。

方法与可复现性

• 插件侧插桩，一次调用一条 JSON（pid / operation / caller / token / 耗时 / finish_reason / usage 是否缺失），start 与 end|err 用稳定键配对；
• 用 balance = start − end − err 判断段是否干净收尾（<0 才是丢事件，>0 是在飞）；
• 观察期按「有效观测时长」而不是墙钟做分母，缺口单列不摊平；
• 三臂：A 不设参数 / B low / C off，每臂按调用数而不是小时数收口（夜间采样率只有白天的 1/6，按墙钟会跑出噪声）；
• 天然对照组：约 33% 的调用拿不到 operation 标签、注定不受补丁影响，它们的读数在同时段几乎不动（−0.5%），用来证明「另外两条链路的降幅不是时间/负载drift 造成的」。

一个不容易注意到的副作用

off 之后 archive_summary 的 completion 从约 1,600 涨到 19,752（还有一条顶到 max_tokens 上限的 finish=length）。省思考 ≠ 省总量，真实风险是截断而不是质量——能力差分（12 条固定输入 ×3 档）里 off 反而全对（123/123），但那是「短文本进、摘要出」，跟生产上「长上下文 + 工具调用」的形态不同构，不能外推。

想问的

1. 有没有人测过 OpenViking 里 long_term_memory_extraction 这条链路在真实长上下文下的降档风险（截断率）？
2. 那条 33% 拿不到 operation 标签的调用，官方有没有推荐的打标方式？我看到 openai_vlm.py 里 op 来自 retry-guard 的 contextvar，没设就为空。
3. 前缀白名单那条（别名模型不发 reasoning_effort）算不算 bug？如果算我另外提 issue。

[maozhuoshushu]

补一条自我更正，免得维护者重复 triage：

我帖子里说的「别名模型不发 reasoning_effort」，不是新 bug——上游已经确认并在 #4690 修了（我顺着 #4686 找到的：#4686 就是这个根因，9 月 4 日确认、9 月 9 日关闭，PR #4690 让「显式配置的值」在非 OpenAI reasoning 家族模型上走 extra_body）。

我这边装的是 openviking 0.4.19（commit gf3afef11），openai_vlm.py 里仍然只有前缀门 _REASONING_MODEL_PREFIXES = ("gpt-5","o1","o3","o4")，没有 #4690 的 extra_body 兜底，所以在我这个版本上它依然是「设了不生效」。

结论修订：这条不用另外提 issue，升级到含 #4690 的版本即可。我帖子里保留它，是因为「参数静默不发」这件事对做成本实验的人是最贵的一个坑——你会拿着空转的补丁得出「降档没用」的结论，而账户里一分钱没省。