钱怎么花、模型怎么选：Token、Budget、Routing 与 Cost / Quality

前置：延迟到底花在哪里：Latency Decomposition 与 TTFT
核心问题：不同任务该用哪个模型、最多花多少钱，Routing 怎样同时考虑能力、成本、风险和当前容量？

ContextManager 估算 20K，provider 实际计费 21K；两者都记录可用于预算和账单对账。研究 Agent 达到 $2 上限后停止额外搜索并返回当前证据，或询问是否继续。

Token Accounting

Token Accounting 是对每次模型调用输入、输出、缓存命中、reasoning 等 provider 可计费维度进行规范化计量，并向 Run/tenant 聚合真实用量；它回答“实际消耗了多少”。

估算与 provider billable usage 需区分。

Cost Budget 是在执行前后约束一个 Run、用户或时间窗口允许消耗的最大成本/Token，并在剩余预算不足时触发降级、停止或请求确认；它回答“最多允许花多少”。

Cost Budget 给 Run/用户/任务设置可消费上限，并在每次模型/Tool 前预测剩余预算。预算耗尽应降级、询问或终止，而不是事后报表。

Module 02 已解释通用 Model Routing；这里增加的是成本与容量约束：在满足任务质量和 capability 的候选模型中，再把剩余预算、provider quota 与目标 latency 纳入选择。

需要 eval 证明路由没有把难任务错误降级。

“更强模型更贵”只是表面现象。真正要比较的是：多花的成本换来了多少任务成功率提升。

例如在固定 Eval Set 上：

text

Model A: $0.03/run, success 82%
Model B: $0.11/run, success 94%

如果失败一次会触发两轮 retry + 人工处理，便宜模型的最终总成本可能反而更高。因此 Routing 应比较 expected cost per successful task，而不是只看单次 token 单价。

同理，更多 retrieval、critic/reviewer、长 reasoning 都需要用 eval 证明边际收益；否则只是把“可能更好”转成稳定更贵。

症状： 每轮只记账不 enforcement。

为什么危险： 长循环或 retry 远超预算。

处理： 每次 model/tool 前检查 remaining cost/token/time，支持降级或终止。

Case	断言
Run 耗尽 Budget 仍继续 Agent Loop	极低 budget 下持续请求下一步，超限前确定停止。

任务很短但风险很高，按 token 长度直接路由到最便宜模型为什么可能是错误策略？
Routing 决定调用前选谁，Fallback 是失败后恢复。两者为什么都必须保持 structured output/tool capability 语义兼容？