Claude API 账单里 17 个隐藏项目，我拆了三个月才搞清楚

三月那张账单发下来的时候我愣了一下。$2,847.12，比二月多了快四成，但流量没涨。我打开 Anthropic Console 想看看到底哪里漏钱了，Usage 页面上一堆柱状图我看不懂。

于是把 CSV 下载下来用 Excel 打开，列标题有 17 个。我当时就懵了，不是说好只有 input / output 吗。

后来花了整整三个月，一边做业务一边摸，才算把每项弄明白。中间还顺手写了个 pandas 脚本做分账，下面讲的都是亲身踩出来的。

表面只有五项，实际分模型又分 TTL

Anthropic 官方定价页上写得挺清爽：input、output、cache write 5m、cache write 1h、cache read。五项。

但 CSV 里不是这样。每一项还要乘以模型。我同时在用 Claude Opus 4.5、Sonnet 4.5、Haiku 4.5，等于五项 × 三模型 = 15 行。然后再乘以 tool use 和 non-tool use —— 因为 Anthropic 在我那个 workspace 里把带工具调用的请求单独切出来算。

光这一层展开，17 行就有了。

我一开始以为 cache write 5m 和 1h 是同一个池子按时间切，后来发现不是。5m TTL 走的是标准缓存池，1h TTL 是 extended cache，后者单价贵 84.3%，但对于一小时内会被多次 hit 的 prompt 反而更划算。关于这块的取舍我在 Prompt Caching 深度指南 里写得比较透，这里不展开。

那些不写在首页的小项

真正坑人的是首页定价表没写的几样：

extended thinking 的 output 单独计。 这个我是看账单看出来的。Sonnet 4.5 开 thinking budget 之后，thinking token 按 output 价格算，但不会显示在 UI 的「回复」里。我有个复杂推理任务，用户看到的 output 才 312 字，账单里 output token 却记了 4127 个。中间 3800 多个就是 thinking。

tool_use 的 output 占比失控。 当模型决定调工具的时候，它要吐出 JSON 结构的 tool_use block，这部分算 output。如果你在一个 agent loop 里它调了 11 次工具，每次 tool_use block 大概 80-200 token，一轮下来纯工具调用就吃掉两三千 output token。这个值在我的客服 agent 里一度占到总 output 的 37%。

prompt eval（预评估）。 Batch API 提交后会做一次 prompt evaluation，按 input 单价收一次。通常可以忽略，但我有次提交了个错误的 schema，被连续 reject 了 4 批，prompt eval 累计扣了 $6.42。小钱但恶心。

batch 折扣不是全量折扣。 50% off 只对 input 和 standard output 生效，cache read 部分本来就便宜，batch 不会再打折。我一开始以为改了 batch 全部成本 × 0.5，结果实际只省了 41.8%。

Console Usage 报表的七个维度

搞懂了有哪些项之后，Console 里那几个下拉菜单才开始有意义。我常用的筛选维度有七个：

1. 按模型（Opus / Sonnet / Haiku 4.5）
2. 按 API key（我一个 key 对应一个项目）
3. 按 workspace（org 下能建多个 workspace）
4. 按 token 类型（input / output / cache 三大类）
5. 按 TTL（5m / 1h）
6. 按时间粒度（hourly / daily / monthly）
7. 按 batch / real-time

前四个在 UI 上都有，后三个得靠 CSV 自己切。我后来养成了每周一上午拉一次 CSV 的习惯，顺便看看有没有哪个 key 昨天突然飙高。

分账要用 org > workspace > key 三层

刚开始我所有项目共用一个 API key，账单拆不开。后来客户投诉说他那个定制功能到底花了多少钱，我才发现这事得从源头解决。

现在的结构是：org 一个，里面建了 4 个 workspace 对应四类业务（SaaS 主产品、B 端定制、内部工具、实验沙箱）。每个 workspace 下再按项目细分 API key，大概十来把。

这样 CSV 拉下来能直接 groupby key 看每个项目的成本。定制客户那边我甚至能按月出一份他那条业务线的纯账单。

要注意的是，workspace 级别的 budget alert 只能设一个阈值，不够精细。我是在代码层面自己包了一层，每个 key 额外塞了一个月度上限，超了直接 403。代码在 Agent SDK 生产部署 那篇里有片段。

一张 $2,847.12 账单的真实拆解

回到开头那张账单。拆完之后大概是这样：

• Sonnet 4.5 input（real-time）：$412.38
• Sonnet 4.5 output（real-time）：$1,284.72 —— 最大一项
• Sonnet 4.5 cache read：$87.14
• Sonnet 4.5 cache write 5m：$63.29
• Sonnet 4.5 cache write 1h：$148.03
• Haiku 4.5 合计：$94.27
• Opus 4.5 合计（一个疑难任务专用 key）：$631.49
• batch 相关合计：$126.80

中间 output $1,284.72 这一项看得我心疼。后来复盘发现里面大概 39% 是 agent 自动回复场景里冗余的「让我帮您分析一下」这种开场白和「希望对您有帮助」的结尾。改了 prompt 明令禁止客套话之后，四月 output 直接砍了 28%。相关的做法我另外写了一篇讲 output 控制的思路。

Opus 那 $631 也值得说。那是一个合同审查场景，平均一次调用 14k input + 2.8k output + 开 thinking。单次成本 $0.37。跑了 1247 次就这个数。后来我把它改成 Haiku 先抽取字段、Opus 只在「疑似有风险条款」时介入，单次降到 $0.09，整体省了 73%。这个思路就是典型的 Haiku 路由降本 玩法。

自建账单解析脚本

Console 的 UI 看趋势可以，做深度分析还是 CSV 实在。我写的脚本大概是这么个骨架：

先用 Anthropic 的 Usage API（或者手动下 CSV）拉当月数据，pandas 读进来之后做五件事：

1. 按 key 聚合，算每个项目的总支出和环比
2. 按 token 类型拆，看 output 占比是不是偏高
3. 找出「单次成本 top 20」的请求 ID，看哪些长尾大调用值得优化
4. 计算 cache hit rate（cache read token / 该 key 总 input token），低于 50% 的 key 标红
5. 生成一个每周邮件摘要

第 3 条最有用。我经常在 top 20 里发现一些离谱的请求，比如有一次某个脚本 bug 把整本 400 页 PDF 塞进去调了 Opus，单次 $4.73。定位修掉之后当月立刻省了一两百刀。

cache hit rate 那条也救过我。有个 key 从 68% 掉到 12%，查出来是部署的时候系统 prompt 里多了个动态时间戳，把缓存 key 给打散了。关于 cache key 稳定性，Prompt Caching 深度指南 里专门有一节讲这个。

一点碎碎念

账单这事，很多人觉得看看总数就行了，反正 API 就这么点钱。但当月成本过了四位数之后，里面的结构就开始有意义了。我现在每月花在账单分析上的时间大概两小时，换回来的优化空间稳定在 15-25%。

另外一个建议：别等到三月那种「突然贵了」的时候才拆。一开始业务小的时候就养成拆账习惯，后面流量上来你会感谢自己。