2026 年 3 月 16 日Claude Code

Claude Code 卡住会消耗 Token 吗？

Claude Code 转圈不动的时候到底烧不烧 Token？答案分两种情况——单纯的网络等待不烧，但很多"看起来卡住"实际是 Agent 在静默循环。这篇用 session 数据告诉你区别。

群里有人问：「我 Claude Code 转圈半小时了一直不动，是不是一直在烧 Token？」

直觉上的答案是「肯定在烧啊」。但实际上——分情况。

真正的"卡住"和假"卡住"

Claude Code 跑任务时你看到的"在转圈"其实有两种状态：

状态 A：等待网络响应

你发出 prompt，请求已经在 API 那一端处理。你这边只是等 HTTP 响应到达。这种状态本身不烧 Token——Token 是请求发出和响应到达时一次性结算的。

如果你 Ctrl+C 在响应到达前——那次请求的 output Token 你也照付（因为模型已经在生成了），但不会越等越多。

状态 B：Agent 在工具调用循环

Claude Code 跑 Agent 模式时，模型可能正在做 read_file、execute、list_directory 这些工具调用。每次工具调用都是一次完整的 LLM 请求——发出当前上下文、收到响应、解析、再发出下一次。

你看到的"转圈不动"其实是它在循环。每次循环都在烧 Token。这就是真正的 Token 黑洞。

怎么区分： 看 Claude Code 的 status bar 或日志——如果它在显示「Reading file...」「Running command...」这种活动，是状态 B；如果什么都没显示就是不动，多半是状态 A 的网络等待。

我看 Vibe Usage 上 Claude Code 的 session 数据，p90 单 session 消息数是 128 条。也就是 10% 的会话里，模型循环超过 100 次工具调用。

每次循环的 input Token 大概是当前上下文长度（10-50 万 Token），按缓存价计算每次 0.03-0.15 美元。100 次循环就是 3-15 美元。

如果一次任务"卡住"半小时，实际可能是 Agent 在 50-200 次工具调用中循环——你停下手不管的成本可能就是几美元到十几美元。

你看到 Agent 循环超过 30 分钟还没结果，多半已经走偏。征兆：

正确的做法：

多数 Agent 跑岔是约束不够，不是模型笨。

我有过一次最离谱的经历：让 Codex 修一个测试报错，跑了 40 分钟没看输出。回来一看 Token 数——单次任务 800 万 Token，单次任务费用 12 美元。最后它生成的修复方案我看完发现是错的，重新让 Claude Code 5 分钟改好了。

12 美元，原本可能 0.5 美元的事。

那次之后我立了规矩：Agent 任务超过 15 分钟没结果就停。多数时候 15 分钟内能搞定的事，超过 15 分钟说明走偏了——和 Token 烧多少无关，和你做事方向有关。

Claude Code 自带的 /cost 只能看会话累计，看不到"过去 5 分钟烧了多少"这种近实时趋势。

我自己的方案是打开 Vibe Usage 的实时面板——它每分钟同步一次数据，能看到当前会话过去 N 分钟的消耗速率。如果发现某个会话突然冒尖（一分钟 50 万 Token 这种），立刻去看是不是循环陷阱。

这个用法 Vibe Usage 没有专门做 UI，但你按"今天 / 这小时"过滤一下就能看出来了。

很多人为了"避免卡住"会主动 Ctrl+C 重试。但其实——

重启 session 的成本比让它继续跑高。新 session 要重建上下文（CLAUDE.md、文件树、对话历史），10-30 万 Token 起步。不如让原 session 跑完（哪怕跑岔），然后下一条 prompt 里加约束让它走对方向。

例外：如果你判断它已经进入死循环（重复读同样文件 30 次以上），那就立刻停。死循环的成本只会更高。

总结：