上个月某个下午，Claude Code 回了我一句用量到顶，然后就是一堵墙。
第一反应照例是"我最近也没怎么用啊"。这个判断后来被证明是错的，而且错得挺难看——不是我用得多，是我不认为那算"我在用"。
先把话撂这儿：用量失控的案子，真凶十有八九是自动化。不是模型贵，也不是哪个 MCP 服务器偷偷吃你的 context。模型和 MCP 只是最好抓的替罪羊。
我去翻了一圈，翻到一个叫 tare 的小工具，干的就是这个：读本机上已有的 Claude Code 会话日志，做用量取证。它 README 里那个诊断示例，我第一眼看到还以为是照着我写的——
某天，99% 的用量来自用户自己跑的一个工具。那天那工具在一个网站项目里起了 1,553 个短会话，产生 9,022 次请求，峰值同时跑 51 个会话。同一天，人手敲的，93 次。
差了快两个数量级。而这个人八成跟我当时一个心态：我就用了一点点。
先说我自己那件蠢事
触限之后我第一个动作是自己数日志。十几行 Python，挨个 jsonl 文件累加 usage 字段，跑出来一个数，拿着它对着配额算了半个晚上，越算越觉得平台在坑我。
import glob, json, os, collections
cost = collections.Counter()
for path in glob.glob(os.path.expanduser("~/.claude/projects/**/*.jsonl"), recursive=True):
for line in open(path):
try:
rec = json.loads(line)
except json.JSONDecodeError:
continue
msg = rec.get("message") or {}
usage = msg.get("usage")
if usage:
cost[msg.get("model")] += usage.get("output_tokens", 0)
这段代码语法上一点问题都没有。问题在于它回答的不是我那个问题。
Claude Code 的日志格式会把同一份 API 响应记不止一次，直接计数一定虚高。tare 的作者在他们的数据上量到过 86% 的虚高幅度。我那个脚本大概也是这个量级，具体多少我没去复算——反正结论是，我拿着一个错了将近一倍的数字，理直气壮地怀疑了平台三天。这大概是我今年缴得最冤的一笔智商税。
所以看见 tare 第一件做的事不是"统计用量"，而是"正确地去重"，我对它的信任就上来了。愿意在最前面处理这种事的人，一般是真被自己数出来的假数字骗过。
会话说到底是最贵的那种循环体
讲清楚为什么短会话这么要命，比介绍工具本身有用得多。
每个新会话都要从零重建上下文——system prompt、CLAUDE.md、工具定义、你打开的那几个文件，全部重来一遍。你要是把 Claude Code 当成一个可以被 for 循环调用的函数，那成本模型从根上就是错的。你付的不是"一次调用"，是"一次冷启动 + 一次调用"。
1,553 个会话，就是 1,553 次冷启动。
而且上下文是带复利的。tare 有一个归因逻辑我特别认：它不满足于统计工具返回了多少内容，而是按工具造成的成本归因。这两个数能差好几倍。
举个例子。一次 grep 返回 200 行，第一轮你付 200 行，这个谁都懂。但在那之后的每一轮对话里，那 200 行还躺在上下文里，跟着每条消息重发一遍。读过一次的文件不是花一次钱，是从读进来那一刻起，每条消息都在给它交租金。
我以前的心智模型是"读文件是本地操作，不花钱"。离谱。读文件确实是本地操作，但读进来的内容立刻变成上下文的一部分，从此按轮次计费。
扯远了，回正题。这套东西的实用价值在哪——它改变了你怎么写自动化。
窗口不因为你合上电脑就重置
这条我以前完全没意识到：限制是滚动的。四小时前干的活还老老实实占在窗口里，你下楼喝杯咖啡，它不会少一格。
tare 里我常用的一个命令就是看当前窗口：
/tare window
它会告诉你这个 5 小时窗口到现在用掉了多少，以及现在适不适合直接开一个大重构。以前我习惯下午四点左右开大重构，"反正晚上还有额度"——现在我会先问一句再动手，因为这个决定开弓没有回头箭。
命令行那套它也给全了：/tare full、/tare usage、/tare report 7、/tare tools 7、/tare share、/tare why，不带参数就是全量诊断。我日常就两个，why 和 window。前者问"昨天为什么触限"，后者问"我现在还能浪多少"。
让实习生自己去翻报销单
tare 的形态是它有意思的地方：它不给你仪表盘。
装完开一个新会话，直接用自然语言问它"为什么昨天触限""触到的是 5 小时限制还是周上限""这周 token 花在哪了"，它自己去读日志、给结论。门槛低到不需要学任何东西，这是我认的。
npx skills add kelviq/tare -g -y --copy --agent claude-code
装完得开个新会话，在斜杠命令列表里确认 tare 出现了。装不上的话 README 会让你去看 INSTALL.md——从没装过 skill 的机器上，安装器有时候会漏掉它，这个我遇到过一次。
但"让 Claude Code 读自己的日志来算自己的账"这件事，我还是留了个心眼。画外音：像让实习生自己填报销单——他没有动机骗你，但也没能力保证每一栏都对。所以它给的数字我会抽查，尤其是那几个跟我直觉不符的。
它还有一些我觉得挺克制的设计。比如可分享摘要，只带总量、日期和工具名，不含 prompt、文件路径、命令、会话标识符。SECURITY.md 里逐项列了每个文件读什么写什么发什么，还丢给你一条 grep 让你自己验证"不建立网络连接"这个说法。声明谁都会写，敢让你自己去搜一遍的没几个。
不感冒的也有。它生成的 HTML 报告和表格导出我大概率不会打开——我要的是归因结论，不是又一份报表。只读 Claude Code 日志是硬边界，我哪天换主力工具它就当场瞎一半。不过眼下这台 Mac 自带 Python，跑起来零成本，这个门槛正好卡在我能接受的边上。
一个我到现在也没想明白的地方
tare 解决的问题是真问题——归因。但归因完之后呢？
那次触限我查出来的结论是：一个我自己写的、给每个文件单独起一个会话做批处理的脚本，占了绝大部分。我当时的第一反应是"那以后不用了"，第二反应是"那这活还得干"。最后还是回去把脚本改成复用会话加并发上限，而不是不跑。
所以这类工具真正的价值，我现在倾向于认为不是教你省钱，是让你知道钱花在谁头上。省不省是后话，很多活该跑还得跑，你只能让它便宜一点跑。至于这个判断对不对，我还没被验证过——等我下次再触限再说。
一条以后我会遵守的规则：写任何批量自动化之前，先算一遍单次会话的固定开销 × 你要起的会话数；算不出来就先跑 10 个测，别一把梭 1,500 个。
那个脚本现在老实多了。不是我想通了，是我的额度先想通了。