Claude Code 的账单，钱到底去了哪？

每一行都是三个数字

一次编码 Agent 请求按三个组成部分计费。要养成的反射是：账单让你意外时，别问哪个模型贵——把明细拉出来，问三个数字里哪一个动了。

1. 提示词 token——模型读到的一切：系统提示、项目上下文、此前的对话、工具结果。长会话里这几乎从来不是「你的问题」，而是你的问题加上 Agent 为了回答而重读的全部内容。
2. 补全 token——模型写回的部分：代码、推理、工具调用。通常只占 Agent 账单的小头。
3. 缓存读/写——提示词缓存的计价。读是大幅折扣的命中，写是填充缓存的成本。你的工具和接入点缓存用得好不好，会剧烈影响实际单价。

安静的主角：上下文每轮重发

Claude Code 这类 Agent 在协议层无状态：每一轮，客户端都会把整段对话重新发一遍——系统提示、文件上下文、之前的工具结果全在内。会话里第 15 条消息的计费，等于你把 15 条一次性问了出去。这不是缺陷，是协议的工作方式；但它解释了两个反直觉的事实：

便宜模型的长会话可能贵过贵模型的短会话。而 ROI 最好的解法通常是管理上下文——清理过期的工具输出、让会话保持聚焦、让缓存干活——而不是到处找折扣。

三根杠杆，按诚实的程度排序

在动价格表之前，先看这几根按「省得有多实在」排序的杠杆：

1. 按任务选对模型。模板化的改动和全文检索用不着旗舰，难的架构级任务才配得上。按任务分流是最大的一笔诚实节省。
2. 让缓存真正生效。提示词缓存的读比冷提示 token 便宜一个数量级。稳定的系统提示和会话结构，比任何价格表都管用。
3. 订阅还是按量——按你自己的形状算账。用量集中砸在一个模型上时套餐划算；一旦负载多样、偶发、或分散在多个工具上，按量就赢。没有万能答案，只有你自己的算术。

问任何服务商的三个问题

无论用哪个接入点，这三个问题能把黑盒变成审计记录：

1. 能不能看到每笔请求的费用、token 和延迟——而不只是月度总额？而且要能导出。
2. 有没有机器可读的价格表，让脚本能在下单前算出成本？无需登录的公开 JSON 接口是我会拿来要求任何服务商的及格线。
3. 没用完的余额到底会怎样——过期政策、退款规则、手续费？「反正一直躺在那」应该是一条写在纸面上的政策，而不是一种氛围。

隐私——毕竟你的代码要经过这个接入点

问清楚什么会被留存。Teapot Router 只保留计费元数据，不归档提示词和响应——而对任何供应商（包括我们）的「零日志」宣传，你都该去验证，而不是相信。