写 Claude Code 有一段时间的朋友应该都有过这种经历明明只是让它改了一个小函数结果月底看账单吓了一跳。Token 到底被谁吃掉了是我让它读的文件太多还是工具调用本身在反复搬运大段代码标题里的那几个关键词——“Token”“Claude Code”“消耗监控统计”几乎是每一个重度用户早晚都会撞上的问题。这篇文章不扯虚的我把自己在实际开发里用过的四种 Token 监控方法全部摊开讲从 Claude Code 自带的命令行统计到官方控制台再到社区开源工具最后是自己写脚本解析本地日志。每种方法我会讲清楚它能解决什么问题、有什么局限以及我踩过的坑保证你照着做就能把“Token 花在哪了”这件事彻底弄明白。1. 为什么每次对话都感觉“钱”在流失1.1 一次看似简单的请求背后到底消耗了多少 Token很多人以为让 Claude Code“帮我改一下某个文件的样式”就只消耗一次请求的量事实远没有这么简单。CLI 工具为了完成一次修改一般会经历“读取文件 → 分析内容 → 调用工具修改 → 再读取结果”等多个来回每个来回都是一次完整的 API 调用而每次调用都要把当前上下文里攒下的全部内容重新发送给模型。我举一个最典型的场景你让 Claude Code 修改一个 500 行的文件它要先调用 Read 工具读文件这 500 行成了输入 Token然后它给出修改建议这算输出 Token接着它调用 Edit 工具把修改后的整个文件或大段 diff 再写进上下文又产生一轮输入 Token。你以为是一次请求实际上往往是四五次请求的叠加而且每一次请求的输入里面都带着前面所有轮次的对话历史。这就是 Claude Code 这类 Agent 型工具和普通网页聊天的本质区别Agent 需要在一个“上下文窗口”里维护完整的工作状态你问得越多、让它读的文件越多、工具调用链越长单次请求的输入 Token 就会越来越庞大最后变成指数级的成本增长。1.2 Claude Code 的成本构成输入、输出、缓存和思考要监控 Token先得知道 API 计费的四个维度不然你连账单上的数字都看不懂。计费项白话解释Claude Sonnet 4 参考价Claude Opus 4 参考价输入 Token无缓存每次请求发送给模型的全新内容3 美元/百万15 美元/百万输入 Token缓存读取命中缓存、重复读取的相同前缀内容0.3 美元/百万1.5 美元/百万输入 Token缓存写入把内容写入缓存的那一次计费3.75 美元/百万18.75 美元/百万输出 Token模型生成的所有文本和代码15 美元/百万75 美元/百万注意价格这块官方定价一直在调整我这边只是给你一个量级参考最终以官方价格页为准。但你可以清楚地看到输出 Token 和缓存读取 Token 之间差了整整 50 倍。这就是为什么 Claude Code 要拼命做 prompt cache——把系统提示和对话前缀缓存起来后续请求只按缓存读取计价能帮你省下一大笔钱。还有一个隐藏成本项是 thinking token。当模型处于扩展思考模式时它在输出正式答案之前先要生成一大段内部推理内容这些内容同样按输出 Token 计费只是你不会在对话界面上直接看到。监控的时候如果不把这一项算进去你永远会觉得自己“根本没让模型说那么多话”。1.3 真正的吞金兽上下文压缩、工具调用与系统提示我最初以为 Token 消耗大头是“我要它写代码的那段输出”后来把日志导出来一看完全不是。真正的吞金兽有三个第一个是系统提示。Claude Code 每次请求都会携带一整套预置指令这套指令加在一起有好几千 Token。虽然它会被缓存但第一次写入缓存的那一下按缓存写入价格计费不算便宜。第二个是工具调用链。Claude Code 每操作一个文件就要把工具名称、参数、文件内容全部塞进请求里。改一个项目经常涉及十几二十个文件每次工具调用的输入 Token 加起来比最终输出多出好几倍。第三个是上下文压缩。当对话超过上下文窗口上限时Claude Code 会自动把前面的内容压缩成摘要这个过程会消耗一次较大的输出请求而且压缩后的摘要作为后续输入又占用了新的 Token 空间。所以你会看到明明是同一个会话越到后面 Token 消耗越快因为里面塞的摘要越来越多。理解了这三个大头你就知道为什么需要监控了不是要斤斤计较快那几分钱而是要搞清楚自己的使用习惯里到底有没有“无意识的浪费”。2. 方法一自带命令零成本上手监控2.1 用 /cost 看会话总账Claude Code 内置了/cost命令这是最快最直接的监控方式。在任意会话里输入/cost它会显示当前会话累计消耗的输入 Token、输出 Token以及估算出来的美元费用。我在实际使用中一般这样用每完成一个比较大的任务或者感觉对话有点长了就敲一下/cost看看当前这个会话已经烧了多少钱。如果数字不小我会冷静一下考虑是不是该开个新会话把上下文清空或者把任务拆细一点再继续。这个命令的局限也很明显它只管当前会话不关心历史会话。你上午开了一个会话下午又开一个晚上再开一个每个会话各自有各自的/cost数据它不会帮你汇总。所以/cost适合做“现场快照”但不适合做“月度统计”。2.2 用 /usage 看上下文窗口占用/usage是另一个内置命令它会显示当前会话的上下文窗口占用比例。你可能会看到一个类似于容量条的展示绿色部分表示已经用掉的上下文空间旁边还有 Token 数字明细。这个命令的价值在于“预防”而不是“核算”。当上下文占用达到 80% 以上时你就该意识到接下来每次请求的输入量已经非常大了因为系统要把 80% 的上下文内容全部重新发送一遍。我自己的习惯是上下文占用超过一半就果断用/compact压缩上下文如果超过 80%直接考虑开新会话。很多新手忽略了这个指标结果一个会话里塞了太多内容后面每个问题都花几倍于平时的输入 Token一个月下来账单直接翻倍。2.3 --debug 模式和细粒度日志如果你需要看到每一次请求的 Token 使用详情内置命令就不够了。可以试试用--debug模式启动 Claude Code会在终端里输出更详细的运行时日志其中包括每次请求的输入输出统计。启动方式很简单claude --debug这样启动之后Claude Code 会在本地写入更完整的日志文件具体路径和普通模式不太一样。你在里面翻一翻能找到每次 API 调用的记录。这种方法适合技术人员做深度排查比如怀疑某次工具调用异常消耗了大量 Token 时用 debug 日志能精确锁定是哪一次请求出的问题。不过说实话--debug模式输出的信息比较原始日常监控用它效率不高我更多是把它当“手术刀”用而不是当“血压计”用。3. 方法二Anthropic 官方控制台全局用量仪表盘3.1 打开 Usage Dashboard如果你注册了 Anthropic 账号并且用的是官方 API最权威的全局统计入口就是 Anthropic Console 里的 Usage 页面。这个仪表盘会把你账号下所有 API Key 的 Token 消耗汇总起来展示总输入、总输出、缓存费用等维度还能按小时、按天、按周看趋势曲线。它的优势是数据源完全来自服务端不管你换了多少台电脑、删了多少本地日志它都在云端记了一本完整账。只要账号没换历史数据就丢不了。3.2 按 API Key 与时间维度拆分控制台支持按 API Key 筛选数据这一点对团队很友好。你可以给不同成员或不同项目分配不同的 API Key然后在控制台里分别看每个 Key 的消耗情况谁用得多、谁的项目费 Token一眼就能比对出来。时间维度上我习惯按天看基线按周看趋势。如果某一天突然出现峰值我会顺藤摸瓜回忆一下当天是不是跑了什么批量任务或者是不是哪个项目留下了异常长的会话没关。这种“先看曲线、再查原因”的排查方式比对着一堆数字硬猜效率高得多。3.3 控制台统计的局限性官方控制台不是万能的它的一个显著短板是“粗细不均”。对于个人用户来说它只能看到账号级别的总量无法自动按项目、按目录拆分。如果你想回答“昨天写支付模块那个项目花了多少钱”这种问题控制台给不了答案。还有一个体验问题控制台的数据刷新有一定延迟不是实时的。有时候你刚跑完一个大任务去控制台看数字还在原地不动过十几分钟甚至更久才跳出来。这是因为服务端需要聚合大量计费数据属于正常的最终一致行为。只要你记住它看的是“历史账本”而不是“实时水表”就不会被这个延迟搞晕。4. 方法三社区统计工具 ccusage一行命令跑出报表4.1 为什么社区工具能统计得这么细官方控制台做不到按项目拆本地日志里有完整信息那社区开发者自然就会做工具来补齐这个缺口。ccusage是这几个人气比较高的开源工具之一它的核心思路很简单读取 Claude Code 存放在本地的 JSONL 会话日志把里面的 Token 字段解析出来按本地已有的价格表算成费用然后按项目、按日期、按模型维度输出报表。说白了它就是一个帮你把散落日志翻译成人类可读账单的小助手。4.2 安装与配置ccusage依赖 Python 环境确保你的机器有 Python 3.9 以上版本然后直接用 pip 安装pip install ccusage安装完成之后什么都不用配置就能跑一个初始统计。不过如果要让成本估算更准确建议设置一个可选参数来匹配你的实际账户状态按照工具的提示操作即可。这个工具主要是靠本地日志算账所以不需要把 API Key 暴露给任何第三方服务器隐私方面比较稳。4.3 常用命令与报表解读ccusage的日常用法非常口语化直接看几个我常用的命令# 看今天的消耗统计 ccusage # 按天看历史消耗 ccusage --daily # 按项目维度看 ccusage --project my-project # 按自然月统计 ccusage --monthly执行之后终端会输出一张表格里面有项目名、会话数、输入 Token、输出 Token、总成本这些列。我特别喜欢按项目看因为它能直接回答“哪个项目在偷偷烧钱”。有一回我发现一个 demo 项目的消耗竟然比正式项目还高查了半天才意识到是那个目录下放了一个特别大的全局文件Claude Code 每次会话都要读它导致输入 Token 飙升。这种“异常定位”能力是官方控制台给不了的。4.4 ccusage 的边界和注意点社区工具再方便也有边界。第一个硬条件是它只能统计“当前这台机器上”产生的会话日志。你在办公室电脑上用 Claude Code 跑的消耗回到家用 ccusage 是看不到的——除非你把~/.claude/目录同步过去。第二个坑是价格表滞后。Claude Code 模型的价格不是固定的官方一调价ccusage 如果没有及时更新价格数据估算出来的费用就会有偏差。我通常把它当作一个“相对趋势参考”而不是“精确账单”真要精确看还是以官方控制台为准。5. 方法四自己写 Python 脚本解析 JSONL 日志做“定制仪表盘”5.1 JSONL 日志在哪里长什么样如果你不只满足于现成工具想要完全掌握数据那就得自己动手解析 JSONL 日志。Claude Code 会把每一次会话完整记录在本地路径大致是~/.claude/projects/项目路径转义/会话ID.jsonl项目路径转义的意思是原始路径里的斜杠会被替换成别的符号。你在~/.claude/projects/下能看到一堆目录名对照你自己的项目路径很容易认出来。用文本编辑器打开任意一个 JSONL 文件会发现每一行都是一个 JSON 对象。其中比较关键的字段一般在 assistant 类型的行里面长这样{ type: assistant, message: { usage: { input_tokens: 456, cache_creation_input_tokens: 12300, cache_read_input_tokens: 3200, output_tokens: 88 } } }这里input_tokens是普通输入cache_creation_input_tokens是写入缓存所用的 Tokencache_read_input_tokens是命中缓存读取的 Tokenoutput_tokens除了正文之外还可能包含思考 Token。把这些字段按天、按项目累加就能得到你自己的精细化账单。5.2 一版开箱即用的统计脚本下面这个脚本可以按天统计所有本地会话的 Token 消耗并估算成本。我自己在日常用的版本比这个复杂不少但核心逻辑就是它了。import json import glob from collections import defaultdict from datetime import datetime # 价格表单位美元/百万 Token按需修改 PRICING { input: 3.0, cache_write: 3.75, cache_read: 0.30, output: 15.0, } stats defaultdict(lambda: {input: 0, cache_creation: 0, cache_read: 0, output: 0, cost: 0.0}) for filepath in glob.glob(f{glob.glob(~/.claude/projects/)[0]}/**/*.jsonl, recursiveTrue): with open(filepath, r, encodingutf-8) as f: for line in f: try: obj json.loads(line) except json.JSONDecodeError: continue if obj.get(type) ! assistant: continue usage obj.get(message, {}).get(usage) if not usage: continue ts obj.get(timestamp, ) day ts[:10] if ts else unknown input_tokens usage.get(input_tokens, 0) cache_creation usage.get(cache_creation_input_tokens, 0) cache_read usage.get(cache_read_input_tokens, 0) output_tokens usage.get(output_tokens, 0) cost ( input_tokens / 1_000_000 * PRICING[input] cache_creation / 1_000_000 * PRICING[cache_write] cache_read / 1_000_000 * PRICING[cache_read] output_tokens / 1_000_000 * PRICING[output] ) stats[day][input] input_tokens stats[day][cache_creation] cache_creation stats[day][cache_read] cache_read stats[day][output] output_tokens stats[day][cost] cost for day in sorted(stats.keys()): s stats[day] print( f{day} input{s[input]:10,} cache_write{s[cache_creation]:10,} fcache_read{s[cache_read]:10,} output{s[output]:10,} cost${s[cost]:.4f} )这个脚本最实用的地方在于你能完全掌控计算逻辑。如果你觉得某些模型用 Sonnet 价格算不准可以在 PRICING 字典里再加一层按 model 区分的价格如果只想统计某个项目可以把 glob 路径限定到那个项目的目录下。我自己的版本还加了按“项目”维度聚合的逻辑会在输出里多列一列项目名这样每天扫一眼就知道钱花在哪个库里了。5.3 扩展思路预算告警与自动报告解析到了 JSONL 数据之后能做的事就不只是“看一眼”了。你可以在这个基础上加一层自动告警每天定时跑一次脚本一旦当天成本超过设置的阈值就通过企业微信、飞书或邮件发一条消息给自己。写告警的逻辑非常简单无非是在脚本最后加一个判断threshold 5.0 # 每天 5 美元阈值 today max(sorted(stats.keys())) if stats[today][cost] threshold: print(f注意今日成本 ${stats[today][cost]:.4f} 已超过阈值 ${threshold}) # 这里可以接上你常用的通知工具把脚本丢给 crontab 或者系统计划任务定时执行你就能在完全不上第三方平台的情况下获得一套属于自己的监控告警系统。这是我最推荐进阶用户做的事情因为它是真正按你自己的使用习惯定制的不会受工具更新频率和价格表滞后的影响。6. 常见问题排查与避坑速查6.1 token 失效、登录失败类报错在实际使用中很多人会撞到类似sign-in could not be completed token exchange failed或者your access token could not be refreshed的报错。看到这类信息先不用慌绝大多数情况下是本地登录凭证失效了和你的代码、项目本身没有关系。我的排查顺序是这样先重新登录一次在 Claude Code 里退出当前账号再重新登录。如果还不行就检查自己环境变量里有没有设置ANTHROPIC_API_KEY这个变量如果指向一个过期或者没有权限的 Key会直接导致 token 相关的校验失败。还有一个容易被忽略的原因某些网络出口或者代理环境本身就会导致认证服务器的请求被拒绝。如果你换了网络之后突然开始报这类错误可以先回忆一下是不是网络环境变了。这里我不展开讲绕过方案正规做法是按照服务商的官方区域授权和网络要求来安排运行环境。6.2 数据对不上的几个常见原因“为什么 ccusage 统计的和我控制台看到的差那么多”这个问题我被问了无数次。最常见的三个原因第一时间口径不一样。本地日志的会话时间是“产生时间”控制台账单的结算时间可能会出现延迟两者的日期会有偏移。第二价格表不同。如果你用的模型在本地工具里没维护对应的价格本地算出来的成本当然会和官方差异。第三跨设备问题。本地 JSONL 只记录当前机器的使用量控制台则把所有设备的用量全算进去了。两台设备加起来自然大于其中一台。理解这三点之后你就能判断哪些差异是正常的、哪些确实是有问题需要去查询的。6.3 监控命令失灵时的排查顺序如果你发现/cost只显示 0或者 ccusage 跑出来没有数据不要慌按下面顺序排查确认你确实通过 Claude Code 发生过真实的 API 调用纯本地脚本不产生消耗检查~/.claude/projects/下是否有 JSONL 文件如果为空说明你的日志路径被修改过或者权限有问题看看文件权限确保当前系统用户有读取权限对于 ccusage确认安装版本不是太老老版本可能还没有兼容最新的 JSONL 格式。这几步能覆盖掉九成以上的“工具没反应”问题。7. 我自己是怎么用这套组合拳的说了这么多方法最后分享一下我日常的固定流程给你做一个组合参考。白天写代码的时候我不太会频繁打断自己去看统计但每完成一个阶段性任务我会敲一下/cost快速确认这个任务在当前会话里消耗了多少。如果数字明显偏高我会想想上下文是不是太臃肿了然后决定要不要开新会话。每天晚上收工之前我会跑一遍ccusage --daily把当天的项目级消耗扫一眼。发现哪个项目异常就翻一下对应的 JSONL 日志看看是不是工具调用链太长了或者是不是有哪些常量级的大文件不应该被反复读。每周抽一天时间对一下官方控制台的周数据校准本地工具的价格估算偏差。至于我自己写的 Python 解析脚本我把它当成“定制化数据库”需要做归类统计、做趋势对比、跨项目拆账的时候才会用。它不像 ccusage 那样开箱即用但灵活度是最高的最近我还在里面加了“按模型拆开统计”的逻辑这样每个模型分别烧了多少钱就一目了然。最后想多说一句监控 Token 的目的不是把自己逼到抠抠搜搜不敢用而是把每一分钱都花在明处。清楚自己的消耗构成之后你反而会更放心地让 Claude Code 干重活——因为你知道什么时候该冲什么时候该省。这种掌控感才是监控工具能带来的最大价值。