中转站余额为什么掉得快？我拆了一次 AI 编程任务的真实消耗

中转站余额为什么掉得快？我拆了一次 AI 编程任务的真实消耗

最近很多人开始高频使用 Claude Code、Codex、Cursor、OpenCode 这类 AI 编程 Agent。

用起来确实很爽：一句话丢过去，它能读项目、找文件、分析报错、改代码、跑命令，最后再给你一个总结。

但用得多了，另一个问题也开始明显起来：

中转站余额掉得真快。

有时候明明只是让它修一个小 bug，或者开一次 Code Plan，让它先分析一下项目，结果额度消耗比想象中高很多。

这时很多人的第一反应是：

• 是不是中转站扣量不准？
• 是不是模型太贵？
• 是不是 Agent 偷偷请求了很多次？
• 是不是 plan 模式也在大量消耗 token？

这些问题不能靠感觉判断。

如果想知道钱到底花在哪里，就得把一次 AI 编程任务拆开看。

所以我最近开始用一个更笨但更有效的方法：把一次 Agent 任务的每一轮请求拆开看。先看一张图。

这里我用到的工具是 ccglass。它不是另一个 AI 编程助手，而是可以帮你观察 Claude Code、Codex 等工具每一轮真实请求的本地工具。对成本敏感的人来说，它最直接的价值是：

看清一次 Agent 任务到底烧了多少上下文、多少 token、多少 cache、多少 latency。

这张图里，模型最终只输出了 34 tokens，但顶部已经显示 24,660 in，估算成本约 $0.0930。请求概览里还能看到 31 tools、cache write 24,654 tokens、latency 2.40s。

也就是说，真正值得关注的不是最后输出了多少字，而是这一轮请求背后带了多少上下文。

不是你的错觉，Agent 任务确实比普通聊天重

普通聊天的成本比较容易理解。

你问一句，模型答一句：

用户输入 -> 模型输出

输入多少 token，输出多少 token，大概还能估。

但 AI 编程 Agent 完全不是这个结构。

你输入一句：

帮我分析这个 bug，并修复相关代码。

背后可能发生的是：

第 1 轮：模型理解任务
第 2 轮：搜索相关文件
第 3 轮：读取代码
第 4 轮：分析调用关系
第 5 轮：运行测试
第 6 轮：带着测试输出继续分析
第 7 轮：修改文件
第 8 轮：再次验证
第 9 轮：总结结果

这不是一次请求，而是一串请求。

每一轮都可能有 input token 和 output token。更重要的是，后面的请求往往会带上前面产生的上下文。

所以你看到的是"修一个小 bug"，实际消耗的是"多轮上下文 + 工具调用 + 文件内容 + 命令输出 + 模型回复"。

这就是 Agent 类工具比普通聊天更烧额度的根本原因。

真正贵的，往往不是最后生成的那几行代码

很多人以为 AI 编程的成本主要花在"生成代码"上。

但实际拆开看，经常不是。

下面这张图更直观。这里用户输入的只是一个简单的 hello，但请求流里已经出现了 system reminder、Agent 类型说明，以及 31 tools offered to the model。

这就是 AI 编程 Agent 和普通聊天最大的区别。

普通聊天里，你可能只是在发一句话。

但 Agent 请求里，模型同时会看到一整套运行上下文：系统提醒、工具说明、可用能力、当前环境、历史消息，以及后续可能调用的工具。

真正重的内容通常包括这些：

• system prompt；
• developer 指令；
• tools schema；
• 历史消息；
• 当前工作目录信息；
• 搜索结果；
• 文件内容；
• 测试日志；
• 命令输出；
• 前几轮 assistant 的分析；
• tool call 和 tool result；
• Code Plan 阶段生成的规划上下文。

其中最容易被忽略的是 tools schema 和工具结果。

Agent 能读文件、写文件、跑命令，是因为它把可用工具的定义发给了模型。工具越多，schema 越复杂，这部分上下文就越重。

Agent 读文件以后，文件内容也可能进入下一轮请求。

Agent 跑测试以后，测试输出也可能进入下一轮请求。

Agent 搜索代码以后，搜索结果也可能进入下一轮请求。

如果某一轮读了一个很大的文件，或者测试输出很长，后续几轮的 input token 就可能明显上升。

这时你以为自己只是在让它"改几行代码"，但实际上模型每轮都在背着一大包上下文继续工作。

Code Plan 为什么看起来没写代码也会贵

很多人对 Code Plan 或 plan mode 的消耗尤其困惑。

因为它看起来还没开始写代码，只是在"想一下"。

但对 Agent 来说，plan 不等于空想。

一个比较完整的 plan 阶段，可能会做这些事：

• 读取项目结构；
• 分析 README 或配置文件；
• 搜索相关模块；
• 理解已有代码风格；
• 判断任务影响范围；
• 推断需要修改哪些文件；
• 生成分步骤执行计划；
• 保留这些分析给后续实现阶段使用。

这些动作都会消耗 token。

尤其是当项目比较大、任务描述比较宽泛时，plan 阶段为了建立项目地图，可能会读很多上下文。

所以 Code Plan 贵，不一定是异常。

它的本质是：在正式动手前，先花 token 买一次理解和规划。

这个成本值不值，取决于任务复杂度。

如果是大重构、跨模块修改、复杂 bug，plan 阶段很有价值。

如果只是改一个很小的样式或文案，反复开 plan 就可能显得浪费。

中转站倍率会放大这种体感

如果你用的是中转站、聚合 API 或第三方模型网关，成本体感会更明显。

因为它通常不是简单看"请求次数"，而是跟这些因素有关：

• 模型倍率；
• input token；
• output token；
• cache 计费方式；
• 上下文长度；
• 是否使用高价模型；
• 是否多轮请求；
• 是否有长输出和长工具结果。

高倍率模型本身就贵。

如果再叠加长上下文和多轮请求，余额下降会非常明显。

这也是为什么同样是"修一个 bug"，有时很便宜，有时很贵。

任务表面看起来相似，但背后的请求链路可能完全不同：

• 一个任务只读了 2 个文件；
• 另一个任务读了 15 个文件；
• 一个任务只跑了单个测试；
• 另一个任务跑了全量测试并返回大量日志；
• 一个任务 cache 命中不错；
• 另一个任务每轮都在创建新上下文；
• 一个任务很快收敛；
• 另一个任务来回尝试了很多轮。

如果没有工具观察，你只能看到余额变少。

但你不知道是哪一轮、哪个文件、哪个工具结果把成本拉上去的。

用 ccglass 拆一笔账

ccglass 的实用性就在这里。

它可以在本地作为代理，记录 Claude Code、Codex、OpenCode 等 AI 编程工具实际发给模型 API 的请求和响应，并通过 Dashboard 展示出来。

对成本分析来说，重点不是看热闹，而是看这些信息：

• 一次任务到底有几轮请求；
• 每一轮 input token 多少；
• 每一轮 output token 多少；
• cache creation 有多少；
• cache read 有多少；
• latency 是否异常；
• messages 数量是否增长；
• tools 数量是否很大；
• 哪一轮请求突然变重；
• 哪个工具结果进入了后续上下文；
• 是 plan 阶段贵，还是实现阶段贵；
• 是读文件贵，还是测试输出贵。

再看 response 里的 usage 明细。

这次请求里，input_tokens 是 6，output_tokens 是 34，但 cache_creation_input_tokens 达到了 24,654，cache_read_input_tokens 是 0。

这个例子很适合说明一个成本误区：用户输入和模型输出本身都不长，但 Agent 请求仍然可能携带大量可缓存上下文。对于中转站或聚合 API 用户来说，这类上下文最终都会反映到额度消耗、倍率成本或延迟体感上。

有了这些信息以后，很多问题就能从"感觉"变成"证据"。

比如你可以看到：

第 1 轮 input 不高，只是任务和系统上下文。
第 2 轮 tools schema 很大。
第 3 轮读了一个大文件，input 开始上涨。
第 4 轮测试输出很长，后面几轮都变重。
第 5 轮 cache 没怎么命中，所以延迟和消耗都上去了。

这时你就知道，余额掉得快不是玄学。

它可能是因为 Agent 读了太多无关文件，也可能是测试日志太长，也可能是 plan 阶段上下文太宽，也可能是模型倍率太高。

看清成本以后，怎么省？

ccglass 本身不会替你省钱。

它的作用是告诉你钱花在哪里。真正省钱，还要调整使用习惯。

下面这些方法通常很有效。

1. 小任务不要开太大范围

不要动不动就说：

帮我优化这个项目。

这类 prompt 会鼓励 Agent 大范围搜索和读取上下文。

更好的写法是：

只检查 src/auth 目录下 session 相关逻辑，先分析问题，不要修改代码。

范围越清楚，Agent 乱读文件的概率越低。

2. 直接给关键文件

如果你已经知道问题大概在哪，就直接告诉它。

问题大概率在 src/auth/session.ts 和 src/auth/session.test.ts。
请优先检查这两个文件。

这比让它全项目搜索更省。

3. 控制测试日志

测试日志很容易变成长上下文。

如果你把完整 CI 日志丢给 Agent，或者让它反复跑全量测试，token 会涨得很快。

更好的方式是：

• 先给失败测试名；
• 给核心报错；
• 给关键调用栈；
• 让它按需运行单个测试；
• 避免把无关日志全部塞进去。

4. 不要反复开 plan

Plan 很有用，但不是所有任务都需要。

如果只是小改动，反复进入 Code Plan 可能不划算。

可以把 plan 用在这些场景：

• 跨模块修改；
• 大重构；
• 复杂 bug；
• 不熟悉的项目；
• 需要评估风险的任务。

简单任务可以直接限定范围，让 Agent 小步执行。

5. 低价值任务用低倍率模型

不是所有任务都值得用最强模型。

比如：

• 改文案；
• 补简单类型；
• 生成重复样板代码；
• 改格式；
• 写简单测试；
• 查找明显错误。

这类任务可以考虑低倍率模型。

高价模型留给真正需要复杂推理的任务。

6. 定期看异常任务

如果你是重度用户，建议偶尔用 ccglass 看几次典型任务。

不用每次都盯着看，但可以定期做成本体检：

• 哪类任务最耗 token？
• 哪个 Agent 请求轮数最多？
• 哪个模型 latency 最高？
• 哪些任务 cache 命中差？
• 哪些工具结果特别大？
• 哪些 prompt 容易导致全项目搜索？

看几次以后，你会更清楚自己怎么用 Agent 最划算。

ccglass 的定位：不是抓包玩具，而是成本观察入口

如果只是偶尔用 AI 补一段代码，可能不需要 ccglass。

但如果你已经开始高频使用 Claude Code、Codex、Code Plan，或者你用的是中转站、聚合 API、第三方模型网关，那成本就不是小问题。

这时你需要的不只是"能不能完成任务"，还要知道：

• 它请求了几轮；
• 它每轮带了多少上下文；
• 它为什么突然变贵；
• 它有没有重复发送无效内容；
• plan 阶段到底花了多少；
• cache 有没有帮上忙；
• 高倍率模型是否用在了值得的地方。

ccglass 解决的就是这个可见性问题。

它不会替你决定用哪个模型，也不会替你优化 prompt。

但它可以把一次 AI 编程任务的消耗摊开，让你知道钱到底花在哪里。

总结

AI 编程不是不能花钱。

真正的问题是：钱花得明不明白。

Claude Code、Codex、Code Plan 这类 Agent 工具，本来就比普通聊天更重。它们会多轮请求、携带工具定义、读取文件、保留历史、处理测试输出，还可能在 plan 阶段建立大量上下文。

如果你用中转站，这些都会变成非常真实的额度消耗。

所以，与其只盯着余额下降，不如拆开看一次任务：

• 哪一轮最贵；
• 哪些上下文最重；
• 哪些工具结果被反复带入；
• cache 有没有命中；
• plan 阶段是否值得；
• 模型倍率是否匹配任务价值。

这就是 ccglass 对成本敏感用户的实用价值。

它让 AI 编程成本从一笔糊涂账，变成可以观察、分析和优化的工程指标。

一句话总结：

不是少用 AI，而是少烧无效上下文。