野生码农
我,39 岁,高速公路施工单位上班,业余用 AI 搭了个"数字员工团队"干活。我用的是 Kimi Code 套餐,每周限额我基本都要干到 100%。
但有个事一直很难受:这一周到底烧了多少 token,官方后台不给你数。 只有个额度百分比,至于这些额度对应多少 token、花在了哪个项目上,一笔糊涂账。
上周我把这个数字窟窿补上了——方法很直接:让 Kimi Code 自己去翻它自己的会话日志,把账算出来。
一个 GEO 博客,烧掉 3.2 亿 token?
先交代背景。我最近用数字员工团队(产品设计、后端、测试、调度四个岗)给我的博客做了一次推倒重建:老站二开,从前台九个页面、后台文章板块,到部署、备份、验收,最后切换到 www.wdmeng.cn 正式上线。全程 16 张任务卡,四个岗位流水作业,9 月 14 日深夜开工,9 月 15 日傍晚上线,一天多跑完【实测:任务卡时间戳】。
上线当晚我问军师(我对团队调度岗的称呼):"统计下我们开发 geo 博客到上线,总共花了几亿 token?"
它翻出交付报告,报了个数:约 2.7 亿。
我一看就觉得不对——那个数是中午的快照,下午又干了五个多小时才上线。我原话怼回去:"这个是限额以前的,限额后,还干了很久呢。"
军师被将了一军,回头把本地所有会话日志重新逐条解析,按时间线重排。真相是:中午 12:26 快照时是 2.7 亿,之后到 17:46 上线又烧了 4600 万。整个 GEO 博客从二开到上线,累计处理约 2.84 亿 token;按当天账户总处理量算是 3.2 亿左右【实测:wire.jsonl 全量求和】。
顺手我还让它算了另一笔账:同一天晚上花 4 小时做的一个 Windows 小工具(浏览器里划词,按 Alt+Q 直接朗读英文、配音标、翻中文),总处理量 756 万 token【实测】。
为什么"亿"这个数看着吓人,其实没那么贵
3.2 亿 token,第一反应是"这得多少钱"。这里有个关键口径问题,也是这次统计最大的收获。
Kimi Code 每轮对话,会把之前的上下文全量重发给模型。会话越长,每轮重发的量越大,像滚雪球。这些重发的内容走缓存命中,计费是折价而不是免费,但跟全新输入不是一个价。
所以 token 账要拆开看:
- 总处理量(全口径):GEO 博客 2.84 亿。这里面包了海量缓存命中——会话日志里光一个"后台文章板块改造"任务卡,缓存读就滚了 4852 万【实测】;
- 非缓存实耗(新输入+输出):整个 GEO 项目只有约 490 万【实测】。这才是成本的主要贡献项。
两个口径差了近 60 倍。只报 3.2 亿是吓唬自己,只报 490 万又严重失真——之前团队调度岗就犯过这错:它第一版成本报告拿"非缓存 350 万"当总成本,我发现当天 20% 周额度被烧穿、数字对不上,质疑之后才按四字段全量重算。这条教训已经进了故障台账:成本统计必须用全口径列全四个字段,禁止拿非缓存口径冒充成本。
账是怎么算出来的(可直接抄)
Kimi Code 官方后台不给 token 明细,但它自己把每次请求的用量都写在了本地日志里,只是没给你看。日志位置:
C:\Users\<你>\.kimi-code\sessions\<工作区>\<会话>\agents\*\wire.jsonl
每条 usage.record 记录一次请求的四个字段:inputOther(非缓存输入)、output(输出)、inputCacheRead(缓存读)、inputCacheCreation(缓存建)。全量求和就是总账。我用的统计脚本核心就这么点:
import json, glob, os
io=oc=cr=cc=0
for f in glob.glob(os.path.expanduser(
'~/.kimi-code/sessions/*/session_*/agents/*/wire.jsonl')):
for line in open(f, encoding='utf-8', errors='replace'):
if '"usage.record"' in line:
u = json.loads(line)['usage']
io+=u.get('inputOther',0); oc+=u.get('output',0)
cr+=u.get('inputCacheRead',0); cc+=u.get('inputCacheCreation',0)
print(f"非缓存={io+oc:,} 缓存读={cr:,} 总计={io+oc+cr+cc:,}")
再按会话的首条指令和时间戳给每个会话贴上项目标签,就能拆出"每个项目各花了多少"。整个统计过程我是用嘴完成的:让 Kimi Code 自己读自己的日志、自己写脚本、自己出数——包括"这次统计本身花了多少"它也能答:约 101 万总处理量,非缓存 6.4 万【实测】。
拿走的三条
- 官方不给的数,日志里有。 Kimi Code 的 wire.jsonl 逐请求记录四字段用量,本地可算,脚本 20 行,每周额度花在哪从此有账可查。
- 报成本必须全口径。 缓存读是折价计价不是免费,长会话全量重发上下文是滚雪球主因;但只报非缓存增量会少报一个数量级。两个数一起列,谁也别装谁。
- AI 报数要敢于质疑。 这次 2.7 亿 → 3.2 亿的修正,就是一句"限额后还干了很久"逼出来的。AI 算账快,但快照时点、口径选择这些坑,它不会主动告诉你。
素材点
- GEO 博客重建:16 张任务卡、四岗流水线、一天上线,全过程有任务卡和交付报告存档,可单开一篇"数字员工团队实战";
- 口径更正事件:非缓存 350 万 → 全口径 2.7 亿,已入故障台账,是"AI 自报成本不可尽信"的现成案例;
- 划词翻译工具 4 小时 756 万 token 的账,可作"小工具开发成本"参照系;
- 统计脚本可整理成独立小工具,给同样用套餐的读者直接用。