这篇记录的是一次很典型的“我明明没怎么用，额度怎么自己飞了”的排查过程。
起因是在看 CC-Switch 数据时，突然发现 OpenClaw 多了接近 600 条新增会话，密密麻麻全是消息。再一看 Codex 的额度消耗，明显不太对劲。
现象
- CC-Switch 里出现大量 OpenClaw 新增会话。
- 会话看起来不像手动发起，而是后台机制自动产生。
- Codex 额度消耗速度明显偏快。
当时第一反应很简单：我草！
问题本质
最后查下来，主要有两个来源：
- Heartbeat 心跳机制
OpenClaw 更新后新增/启用的后台心跳巡检机制。
- Dream 梦境/记忆整理机制
用来做记忆归纳、自我改进、长期偏好沉淀一类的后台整理。
这两个机制本意都不坏。Heartbeat 是为了让 Agent 定期自检，Dream 是为了让 Agent 从历史记忆里提炼长期规律。
但如果你用的是按 API token 计费的模式，而不是固定订阅额度，那它们就可能从“贴心后台功能”变成“安静但持续的烧钱机器”。
Heartbeat 到底在做什么
Heartbeat 不是你手动发的消息，而是 OpenClaw 定时注入的一类后台提示。
它大概会做这些事：
- 每隔一段时间自动触发一次。
- 让 Agent 做轻量检查，比如有没有待跟进事项、状态是否变化、要不要做自维护。
- 没有新情况时回复
HEARTBEAT_OK。 - 有新情况时再继续执行后续动作。
- 这些系统消息后续还可能进入记忆汇总流程，所以会在日志里继续出现。
所以它本质上是在做“自检和保活”。问题是：如果每 30 分钟跑一次，并且每次上下文又不小，那 token 消耗就不会小。
Dream 又是什么
Dream 看起来更像一套“记忆整理 / 反思日志”机制。
它会从历史 memory 里提取高频主题，生成候选结论，尝试归纳所谓的“长期真相”，有时还会把记忆片段改写成一种偏文学化的 dream diary entry。
简单说就是：
读取旧记忆 -> 提取高频主题 -> 归纳长期规律 -> 生成梦境式整理文本这种东西对“塑造持续人格”和“形成长期助手风格”确实有意义。但如果目标是提高任务完成效率、减少遗忘、降低 token 成本，它未必划算。
尤其是当它开始写得像一位会作诗的记忆整理器时，我的评价是：气质有了，账单也有了。
成本粗算
我让 AI 按本地会话日志做了一次统计，结论大概是：
单次 heartbeat（有实际模型消耗的那种）平均约 4.9 万 tokens。
单次费用均值约 0.067 美元，中位数约 0.044 美元。
较高分位可到 0.157 美元。
如果稳定每 30 分钟一次，每天约 48 次，且都发生有效调用：
约 3.2 美元/天，约 96 美元/月。
历史里有不少心跳失败或零消耗。
按全部历史样本折算，大约 1.46 美元/天，约 44 美元/月。所以结论很明确：会烧，而且高频心跳场景下会烧得比较明显。
我的处理方案
1. 降低 Heartbeat 频率
在 openclaw.json 的 agent 默认配置里增加 heartbeat 配置：
"heartbeat": {
"every": "8h",
"lightContext": true,
"isolatedSession": true,
"target": "none"
}这里几个点比较关键：
every: "8h"：把心跳频率从半小时级别拉长到 8 小时。lightContext: true：尽量减少上下文携带，降低 token 消耗。isolatedSession: true：让心跳尽量隔离运行，避免拖着主会话历史一起跑。target: "none"：不主动外发提醒，只做内部检查。
原始记录里我写过 “every: 3h 是关键间隔控制”，但这次实际更倾向于 8 小时。除非你真的需要 Agent 高频主动巡检，否则没必要半小时烧一次。
2. 关闭 Dream
Dream 我个人建议直接关。
不是说它完全没用，而是它的收益比较偏长期、偏人格、偏记忆风格；如果你当前最关心的是成本和效率，它的优先级就没那么高。
我的处理方式是：
直接去 Dashboard 面板里关掉 Dream。结论
这次问题不是 OpenClaw “坏了”，而是一些默认变聪明的后台机制，在 API 计费模式下变得有点贵。
如果你也遇到类似情况，可以按这个顺序排查：
- 看看是否有大量自动会话或后台消息。
- 检查 Heartbeat 频率。
- 检查 Dream / 记忆整理相关功能是否在跑。
- 如果按 token 计费，优先降低频率、开启轻上下文、关闭非必要后台整理。
一句话省流：Heartbeat 别太勤，Dream 不急着开。
