OcHub 的成本不是供应商账单，而是根据请求记录中的 Token、模型价格和倍率计算出的本地估算。 OcHub 不维护一套自己的内置价格；模型 ID、价格或计价来源不一致时，请求可以成功但成本会 显示为 0。
成本由什么决定
一条请求可能同时有三个模型名称：
| 名称 | 含义 |
|---|---|
| 请求模型 | 客户端发送的模型或别名 |
| 模型 | 上游响应或实际处理的模型 |
| 计价模型 | OcHub 最终查价格表使用的模型 |
模型供应商做模型改写时，这三个值可能完全不同。例如客户端请求
claude-sonnet-current，路由成 anthropic/claude-sonnet-4-6，计价模型应根据你的账单
口径选择其中一个真实可定价的 ID。
模型定价表包含四项每百万 Token 价格：
- 输入
- 输出
- 缓存读取
- 缓存写入（内部统计也称缓存创建）
总成本按四项基础成本相加后再乘倍率。OcHub 会根据应用的数据语义处理缓存 Token：Claude 风格的输入通常已经是新输入；Codex / OpenAI Responses 风格的输入可能包含缓存读取，计算时 会先扣除缓存读取再按普通输入价计费。
价格来源与同步
安装包会包含一份在 CI 中从 LiteLLM 官方数据筛选、校验并固定到具体版本的离线价格目录。 因此首次启动不需要联网，也不是由 OcHub 人工维护一套价格。应用在后台每天最多发起一次 条件更新；也可以在用量 → 模型定价配置中选择“立即同步”。更新失败时会继续使用上一份 有效目录，不会清空价格。
价格查找遵循以下原则：
- 用户保存的手动覆盖始终优先，目录同步不会修改或删除它。
- 自动目录优先匹配完整的 Provider / 区域模型 ID，再尝试直接模型 ID。
- 只有同一别名对应的所有候选价格完全一致时，才会自动使用别名价格；存在价格歧义时不猜测。
- 请求实际使用了缓存 Token、但目录没有对应缓存单价时，不把缺失值当成
0。
有 Token 但仍无法可靠定价的模型会汇总在一个缺价提示中，不会为每条历史记录反复弹窗。 同步或新增手动覆盖后，OcHub 会尝试补算 Token 大于 0 且成本仍为 0 的历史请求；已有非零 成本不会被批量改写。
先找到正确模型 ID
不要从宣传页猜模型 ID。先产生一条真实请求：
- 打开用量 → 请求日志。
- 选择一条 Token 不为 0 的记录。
- 记录“请求模型”“模型”和“计价模型”。
- 到供应商价目表确认哪个名称对应实际收费模型。
- 回到 OcHub，用那个 ID 建立定价。
如果日志中的计价模型是自定义别名，先决定是：
- 改成按响应模型计费，让上游真实模型命中价格；或
- 为客户端别名单独创建等价价格；或
- 调整模型供应商模型映射，使计价模型稳定。
最可靠的方式是让“计价模型”直接等于价格表中的模型 ID。
新增手动价格覆盖
-
展开“模型定价配置”。 打开 OcHub 的“用量”页面，找到手动价格覆盖表。
-
填写模型 ID。 必须能匹配请求详情中的计价模型；大小写、供应商前缀和版本后缀都可能影响匹配。
-
填写显示名称。 这是用量界面的人类可读名称，不参与请求路由。
-
填写四项价格。 单位都是每百万 Token 的美元价格。供应商没有缓存写入或缓存读取价格时，根据其计费规则填写
0，不要留成无法解析的文本。 -
保存。 价格必须是非负数字。保存同一个模型 ID 会更新已有记录。
-
刷新用量。 再次打开刚才的请求，核对计价模型、各项成本和总成本。
保存手动覆盖后，OcHub 会尝试为该模型回填历史中 Token 大于 0、但总成本仍为 0 的请求。 已经存在非零成本的历史记录不会因为改价而全部重算，因此改价前后可能出现两个历史口径。
选择请求模型还是响应模型
“计费默认配置”目前为 Claude 与 Codex 提供计价模型来源：
| 选择 | 使用场景 | 风险 |
|---|---|---|
| 按响应模型计费 | 上游会返回实际模型；存在别名或路由改写 | 某些上游回显空值或仍回显别名 |
| 按请求模型计费 | 客户端名称稳定且与价目表一致 | 模型映射后可能按错误模型收费 |
选择方法：
- 对普通直连请求，比较请求模型与响应模型。
- 对经过模型映射的请求再比较一次。
- 选择能稳定命中真实价格的来源。
- 保存默认配置。
- 发起新请求并检查“计价模型”。
不要只看模型统计列表，因为它已经按计价模型聚合。请求详情能同时展示三个名称，更适合校准。
Claude Desktop 没有独立的默认计费项，会继承 Claude 的应用默认倍率和计价来源。
设置成本倍率
倍率用于把公开模型价换算为供应商实际结算价。默认 1 表示不调整。
常见例子：
| 结算规则 | 倍率 |
|---|---|
| 与官方价相同 | 1 |
| 统一加价 20% | 1.2 |
| 按官方价 8 折 | 0.8 |
| 只统计 Token，成本暂不参与汇总 | 0 |
倍率作用于输入、输出和缓存基础成本相加后的总价，而不是改变 Token 数。输入非负数字后保存 “计费默认配置”，再通过新请求确认请求详情中的“成本倍率”。
如果供应商对不同模型采用不同加价，单一应用倍率无法完整表达。更稳妥的做法是为这些模型
直接填写结算后的每百万 Token 价格，并保持倍率为 1。
手工复核一次计算
假设某请求记录：
| 项目 | Token | 每百万价格 | 基础成本 |
|---|---|---|---|
| 新输入 | 10,000 | $3.00 | $0.03000 |
| 输出 | 2,000 | $15.00 | $0.03000 |
| 缓存读取 | 20,000 | $0.30 | $0.00600 |
| 缓存写入 | 5,000 | $3.75 | $0.01875 |
基础成本合计为 $0.08475。若倍率为 1.2，总成本应为：
$0.08475 × 1.2 = $0.10170复核时使用请求详情里的实际 Token，不要把“真实 Token”首页汇总直接代入单条请求。对于 Codex / Responses，界面已经按其缓存语义计算普通输入，无需再次手工把缓存读取加进输入。
校准到供应商账单
本地估算与账单对不上时，按以下顺序排查：
- 统一时间范围。 时区和账单日边界要一致。
- 筛选同一 Provider。 不要把官方登录、直连和模型供应商请求混在一起。
- 核对请求数量。 失败请求、重试和探测是否计费取决于上游。
- 核对计价模型。 模型别名是否命中了正确价格。
- 核对 Token。 上游是否把系统提示、工具定义或推理 Token 单独处理。
- 核对缓存。 输入是否已经包含缓存读取，价格是否分别填写。
- 核对倍率。 是否存在统一加价、折扣或汇率换算。
- 抽样单条请求。 先让一条明细接近，再比较日汇总。
供应商可能按账户套餐、阶梯价、批处理、区域或最低消费计费，这些规则不一定能用单一模型价 和倍率精确表达。此时把 OcHub 成本作为请求级估算，并以供应商账单为结算依据。
不同数据来源的限制
用量可能来自网关请求、Claude 会话、Codex 数据库或会话、OpenCode 会话，以及手动同步。
| 数据来源 | 通常具备 | 可能缺少 |
|---|---|---|
| 模型供应商请求 | 请求 ID、状态、模型、Token、延迟 | 上游未返回的字段 |
| CLI 会话 | 模型、部分 Token、会话时间 | 网关级首 Token、HTTP 状态 |
| 旧版本地请求 | 历史 Token 与成本字段 | 当前计价模型语义 |
| 同步会话 | 会话文件实际记录的信息 | Provider 或精确缓存拆分 |
来源字段不足时，OcHub 不会凭空补出可靠成本。成本为 0 先检查 Token 和计价模型；两者缺失 时，即使增加价格也无法计算。
常见问题
| 现象 | 优先检查 | 处理 |
|---|---|---|
| Token 有值但成本为 0 | 缺价提示、计价模型、缓存价格 | 同步目录或用详情中的 ID 新增手动覆盖 |
| 新请求价格正确，旧请求仍不对 | 旧记录已有非零成本 | 把改价时间作为统计分界 |
| 缓存成本过高 | 输入与缓存读是否重复计算 | 确认应用类型和上游 Token 语义 |
| 路由后套用客户端别名价格 | 计价来源选择了请求模型 | 改为响应模型或补别名价格 |
| 同一模型成本突然变化 | 倍率、版本后缀、价格更新 | 对比请求详情中的计价模型与倍率 |
| 总成本与账单略有差异 | 舍入、时区、失败请求或套餐规则 | 抽样单条，再按同一时间范围汇总 |
| 保存价格失败 | 空显示名、负数或非数字 | 补齐名称并使用非负十进制数 |
配置完成后，用一条已知模型的新请求验收，并把价格来源与更新时间记录在团队自己的变更说明 中。日常筛选和请求下钻方式见查看会话与用量。