当订阅产品没有逐请求账单时，把本地 token 乘以公开 API 费率可以得到一个有用的参照值。但这个数字必须被明确叫作估计，否则很容易被误读成实际消费。
基本公式
estimated_api_value =
input_tokens × input_rate
+ cached_input_tokens × cached_rate
+ output_tokens × output_rate费率必须绑定模型和生效日期。模型未知时不要擅自套用最高价；可以显示“无法估计”，或者使用清楚标注的保守假设。
缓存输入需要供应商特定处理
缓存写入、缓存命中和普通输入可能使用不同费率，供应商记录字段也不一致。先保留原始分类，再在展示层应用费率表，避免把所有 input token 当成同一种成本。
Token 量和 API value 回答不同问题
Token 量描述处理规模；API value 加入了模型价格，便于比较不同模型组合。某天 token 更少但使用更贵的模型，估计值仍可能更高。
为什么估计可能不完整
本地记录可能缺行、供应商可能调整费率、某些内部 token 不对外计费，订阅套餐也不是按 API 单价结算。因此页面应同时显示数据来源、费率日期和缺失范围。
这个数字允许表达什么
可以说“按某日公开 API 费率估算，本地记录对应约 X 的 API value”。不能把它写成订阅账单、节省金额、收入、ROI 或供应商向你收取的真实费用。
工作台账如何从本地记录生成，见构建本地 AI 工作台账。
页面上应该同时显示哪些口径
一个可审计的 API value 视图应同时给出 token 分类、模型或费率档、费率生效日期、估计币种和缺失数据提示。只有最终金额而没有这些输入，用户无法知道变化来自工作量、模型切换还是费率表更新。
一个简单示例
假设本地记录包含普通输入、缓存命中和输出三类 token，就分别乘以对应公开费率后求和。若其中一段记录没有模型名，这段可以保留 token 数量，但不应偷偷使用另一模型的价格。最终文案应写“公开 API 费率下的估计值”，而不是“本周花费”。