一次代码修复的三轮账单

一次代码修复，便宜的模型先给出补丁，测试失败；补充报错，再改一次；最后把相关文件重新发过去。另一种模型的令牌单价更高，却在第一轮完成了修复。比较账单时，应该比较哪一次调用，还是比较这项工作最终花了多少钱？

更大的模型不一定更便宜。只有当它减少的重试、上下文消耗或人工处理，足以抵消较高的单价时，这个判断才成立。这里的“大”指更高能力档位，不推断供应商未公开的参数规模。

§ 先把比较单位定为完成一项任务

较轻的模型：单次调用通常更容易控制预算。对于格式固定、答案可验证、上下文短的工作，即使偶尔重试，总成本也可能更低。

更强的模型：单次价格可能更高，但在跨文件修复、复杂约束或模糊需求中，可能减少反复解释和补丁返工。这需要用自己的任务验证，不能由模型档位直接推导。

例如，可以把 Claude Haiku 4.5 与 Claude Sonnet 5.5 放入同一组代码修复评测。比较时固定仓库、测试、工具权限和停止条件，不要给其中一个更多提示，再把差异归因于模型。

假设有一百项修复任务，验收标准相同：相关测试通过，而且没有引入已知回归。以下金额仅用于演算，不是 Vana API 或任何模型的实际报价。

方案甲，较低单次成本：首轮调用一百次，其中四十项需要第二轮，二十项还需要第三轮，最终全部验收通过。共一百六十次调用，按实际输入、输出令牌折算后的平均每次费用为零点零三元，总费用为四点八元。
方案乙，较高单次成本：首轮调用一百次，其中十项需要第二轮，最终全部验收通过。共一百一十次调用，平均每次费用为零点零四元，总费用为四点四元。

方案乙每次贵约三分之一，完成同样任务的调用费用却低约百分之八。差异来自更少的重试，而不是更低的令牌单价。这个例子也没有计入人工时间，因此只能说明调用费用上的结果。

在平均每次费用稳定的简化条件下，方案乙的调用次数必须低于方案甲的四分之三，才会更便宜。真实工作流中，重试往往携带更多上下文，所以不能一直用固定的单次费用估算。

上下文：较轻的模型若需要反复接收文件、报错和历史补丁，输入令牌会累积。更强的模型若一次读入大量无关文件，也可能更贵。两边都应使用同样的上下文筛选策略，并分别记录缓存命中情况。

输出与工具：简短答案不等于低成本，长答案也不等于高质量。记录实际输出令牌、适用的推理令牌，以及工具调用带来的后续模型请求；搜索、执行环境等外部费用另算。不要只看最终展示给用户的文字。

人工复核：较轻的模型若需要更多人检查，差价可能很快被人工成本覆盖。但节省了多少时间必须实测，不能默认更强模型的输出无需审查。涉及安全、权限或资金的改动，两边都应保留相同的复核要求。

通过 Vana API，可以在同一个兼容 OpenAI 的端点切换模型，按实际令牌付费，没有月费，适合做小批量对照实验。接口统一能减少接入工作，但并不意味着不同模型的参数、工具行为或缓存规则完全相同，测试前仍需核对。

可以创建一个 Vana API 账户，先选取一小组真实任务重复测试。每项记录验收结果、总令牌费用、重试次数、耗时和人工复核时间；达到重试上限仍未完成的任务也必须保留，不能从账本中删除。

最终同时看成功率、每项成功任务的平均成本，以及少数困难任务的最高开销。如果简单任务占大多数，让较轻的模型先处理、失败后升级，可能更合适；如果升级前已经消耗了大量上下文和时间，直接使用更强的模型反而划算。所谓便宜，应该是把工作可靠地做完之后，账单仍然更小。