整机历史官方重算
¥49.00
按 MiniMax 官方 M2.1 单价重算，时间窗为 2026-03-15 00:00 之后。
OpenClaw 账面值
¥332.51
来自 session 文件里的 `usage.cost.total`。这个值由本地模型单价配置驱动，明显高估。
客户这条 Feishu 线
≈ ¥8.0 + Doubao 小额
可证实的 MiniMax 部分约 ¥7.99；当前 Doubao 部分日志不落 usage，估计只在几毛到 1 元量级。
核心结论
- 如果看整台机器，自 2026-03-15 起 MiniMax 历史消耗按官方价重算约为 ¥49.00；如果看 OpenClaw 本机账面，则被写成 ¥332.51。
- 如果只切客户这条 Feishu 直聊线（`ou_870111713fbc6ba5c9523c6ef9bb5d1a`），可证实的 MiniMax 历史成本约 ¥7.99，不是 20 元级别。
- 当前 Doubao 会话本身没有在 OpenClaw 账本里落 `usage`，所以后台显示 0；但从 `session_status`、文本体量和缓存命中率看，这段会话更像是 几毛到 1 元左右，不是 20 元。
- “模型说只花 3 毛”并非完全胡说。真正的问题是：前台估的是当前对话边际成本，后台如果看的是整机历史或 OpenClaw 配置高价，两个数字根本不是同一个口径。
直接证据
取自远端日志与会话文件
MiniMax 定价写高
远端配置 `MiniMax-M2.1` 的单价被写成：
- 输入 `15 / 百万 token`
- 输出 `60 / 百万 token`
- 缓存读 `2 / 百万 token`
- 缓存写 `10 / 百万 token`
而官方文档里对应的是 `2.1 / 8.4 / 0.21 / 2.625`，OpenClaw 本机账面因此被系统性放大。
整机视角：后台账面为什么会看起来很吓人
同一批 MiniMax token，OpenClaw 配置价 vs 官方价
| 口径 |
输入 |
输出 |
缓存读 |
缓存写 |
成本 |
| 整机 MiniMax 历史累计 |
16,438,082 |
154,649 |
22,036,716 |
3,258,628 |
¥49.0006 官方重算 / ¥332.5099 OpenClaw 账面 |
| 客户 Feishu 直聊线 |
2,218,032 |
29,586 |
4,684,209 |
799,813 |
¥7.9896 官方重算 / ¥52.4122 OpenClaw 账面 |
| 其它会话合计 |
14,220,050 |
125,063 |
17,352,507 |
2,458,815 |
¥41.0111 官方重算 / ¥280.0977 OpenClaw 账面 |
要点：如果客户看到账户里“已经花了二十多”，很可能混进了同机其它会话；如果看的是 OpenClaw 自己的账本，那它又把 MiniMax 单价写高了。
最贵的会话文件
按官方 MiniMax 单价重算；对比同文件里 OpenClaw 自己写入的账面值
当前 Doubao 会话并不贵
- 2026-03-23 04:36 的 `session_status` 显示：95% cache hit、20k cached、1.1k new。
- 当前两段 Doubao 会话里，用户文本约 23,438 字符，助手可见正文约 12,078 字符，隐藏 `thinking` 约 23,097 字符。
- 按火山引擎 `doubao-seed-2.0-pro` 官方在线推理价粗估，这段对话更接近 几毛到 1 元，而不是 20 元。
- OpenClaw 对 Volcengine 目前没有正确落 usage：当前配置里 Doubao 的 `cost` 全是 `0`，日志里的 `lastCallUsage` 也是 `0`。
这意味着：当前 Doubao 部分只能做保守估算，不能做严格对账。
为什么“前台 3 毛”会和“后台很多”打架
- 口径不同 前台通常估的是“当前一段对话”的边际成本；后台可能看的是“同 API Key / 同机器全部历史”。
- 冷启动很贵 2026-03-15 21:54 的 `session_status` 显示这条线曾出现 0 cached / 81k new，说明首次冷启动把大段系统提示一次性吃进去了。
- 隐藏 thinking 当前 Doubao 会话里隐藏 `thinking` 比可见正文多约 1.91x，用户没看到，但模型确实生成了。
- 工具流量 当前 Doubao 会话里还有 17 条 `toolResult`，文本累计约 17,449 字符，会继续回灌到模型输入。
- 配置价过高 MiniMax 本地单价高于官方，直接把后台“账面金额”放大。
冷启动成本为什么高
来自 2026-03-22 21:18 的网关日志摘要
| 组件 |
字符数 |
说明 |
| systemPrompt |
38,762 |
含项目上下文 17,213 字符，非项目上下文 21,549 字符。 |
| skills prompt |
8,825 |
挂载的 skills 列表。 |
| tools schema |
23,258 |
工具定义和 schema。 |
| 合计基线 |
70,845 |
用户一句话还没算进去，冷启动就先带着一大坨上下文。 |
这也解释了为什么短消息看起来很便宜，但在新会话、reset 后、或者缓存没命中时，后台 token 会突然冲高。
建议修复项
- 把远端 `MiniMax-M2.1` 的本地计价修正成官方值，否则 OpenClaw 自带账本永远会夸大。
- 给 `volcengine/doubao-seed-2-0-pro-260215` 配上真实单价，并确认 provider adapter 能把 Ark 的 usage 正确写回 session。
- 压缩系统提示、skills 列表和工具 schema；70k 字符的冷启动基线太重。
- 如果业务上不需要隐藏推理，关掉或裁剪 `thinking` 持久化；目前它对成本和日志体积都有明显放大。
- 做账时必须分两层看：`整机总额` 和 `单客户会话额`，否则很容易把别人的消耗算到当前客户头上。
证据位置
- 远端配置：`/root/.openclaw/openclaw.json`
- 远端日志：`/tmp/openclaw/openclaw-2026-03-22.log`、`/tmp/openclaw/openclaw-2026-03-23.log`
- 客户 Feishu 会话：`/root/.openclaw/agents/main/sessions/515726a0-42fe-4429-a4da-9d9c6c895301.jsonl.reset.2026-03-16T11-59-57.453Z`、`/root/.openclaw/agents/main/sessions/5cee7bd9-6982-4e3c-b951-a82663e37650.jsonl.reset.2026-03-22T08-28-46.047Z`、`/root/.openclaw/agents/main/sessions/bc23a7c4-a0b3-4bba-927e-7b72363c06b0.jsonl`
- 官方计价：MiniMax M2.1、火山引擎 Doubao 计费
- 原始数据 JSON：/reports/openclaw-cost-20260323.json