Agent 的账单不能用“输入字数 × 单价”粗算。系统提示词、工具定义、仓库内容、历史对话、缓存写入、缓存读取、输出以及失败重试，都会影响最后的扣费。

先定义真正要算的指标

最有用的不是每百万 Token 单价，而是：

有效任务成本 = 完成任务期间的全部费用 ÷ 成功完成的任务数

如果五次调用只有四次成功，第五次失败但产生了费用，也应计入分子。

为什么对话越长越贵

多轮会话会反复携带历史上下文。项目文件越多、工具定义越长，每轮输入越大。简单任务最好开启新会话；大型任务则应及时总结已完成内容，移除无关上下文。

缓存不是一句“支持”就够了

第一次发送稳定前缀可能产生缓存写入，后续重复使用才可能形成缓存读取。只比较两次总 Token 看不出问题，应保存 Usage 中对应字段，并保证系统提示词、工具列表和前缀没有变化。

用一张账单做例题

说到价格，TeamoRouter 官网目前标示部分模型低至官方标价 1 折，按量计费，余额也不会按月清空。这确实能降低高频调用的门槛，但不能直接把“一折”当成一次 Agent 任务的结算结果：提示缓存、输出长度、辅助调用和失败重试都会改变账单。好在它能查看 Usage 和调用记录，正好可以拿来把标价与实际任务费用逐项对上。

把费用对应到一次具体任务

假设一个重构任务表面只输入了一条指令，后台却依次发生了规划、读取文件、生成修改、运行测试后的修正。记录时应把这些调用归到同一个任务编号下，再统计总成本。否则后台的辅助调用会散落在账单中，看起来像“不明扣费”。

前面的计费样本适合用来说明字段如何读取，但不同模型、服务档位和缓存规则会变化。真正比较两个方案时，应使用相同仓库快照和完成标准，并把失败费用算进去；只截取最便宜的一次，会明显低估日常使用成本。

最常见的四种浪费

1. 把无关文件长期留在上下文；
2. 稳定前缀频繁变化，缓存无法复用；
3. 失败后盲目重试，没有先判断是否部分完成；
4. 用简单问答成本推算长时间重构。

建议的记录表

每个任务记录开始/结束时间、模型、请求数、输入、缓存写入、缓存读取、输出、失败次数、实际扣费和是否完成。连续记录一周后，才有资格讨论“哪个方案更省”。

优化成本时的正确顺序

先减少明显无关的上下文，再稳定可缓存前缀，然后处理失败重试，最后才考虑更换模型或计费入口。因为前面三项属于工作流浪费，换到任何服务仍然会存在。每做一次优化，都用相同任务复测，并同时观察完成质量；如果费用降低但人工修正次数翻倍，就不能算真正节省。

对于团队，还应把预算按成员或项目拆分。共用一个 Key 虽然方便，却很难判断是哪类任务造成增长，也无法在异常时只停用一个使用者。

别忽略人的时间

有效成本还应包含人工检查和返工。一个方案每次少花几元，却需要开发者多检查二十分钟，团队总成本可能更高。把人工干预次数和耗时放到账单旁边，结论会更接近真实工作。