如果你要找每请求成本记录与 Key 级上限的产品说明，请看 LLM 成本追踪。本文介绍如何用独立 Key 隔离工作负载、按 Key 查看花费、为更细的归因保存请求 ID，再把应用活动与网关账单核对起来。
月度总额不能说明是哪个应用、agent 或同事产生了费用。Router One 按发起请求的 API Key 记录每次模型请求，并执行每把 Key 的消费上限，所以给每个工作负载一把独立 Key，控制台就能直接给出按工作负载拆分的费用；比 Key 更细的归因——终端客户、单次运行、某个功能——需要由你的应用提供身份标签。
每个工作负载使用独立 Key 并设置合适的消费上限，在控制台 → 用量里按 Key 查看花费，对账时把这把 Key 的日志导出为 CSV。比 Key 更细的归因，就把请求 ID 和自己的标签一起保存，无需另外维护价格表估算费用。
为什么各家供应商的控制台不够用
如果你直接调两三家供应商，开销就散落在两三个控制台里，各有各的更新节奏、币种处理方式，连"一次请求"的定义都不一样。更麻烦的是，归因止步于账号层面：控制台能告诉你整个账号花了多少，却说不清是你的哪个服务调的——除非你给每个服务单开一个账号，那是在成倍增加账务负担，不是在减少。
常见的变通办法是在应用侧自己记日志：包一层 SDK 调用、估算 token 数、乘以一张手工维护的价格表，再祈祷没人调用你忘了录入的模型。它能用，直到某次价格调整或者有人新接了一家供应商，然后悄无声息地坏掉。
第一步：每个工作负载一把 Key
Router One 位于应用与模型目录之间，记录模型用量与每请求费用。先为每个应用、agent 或环境创建独立 API Key，让每个工作负载有自己的消费上限，也在用量报表里单独占一行。
- 名为
prod-chatbot的 Key 给生产环境的助手 batch-pipeline给每晚跑的批处理任务claude-code-alice给同事的 coding agentstaging给所有预发布环境
控制台 → 用量按 Key 名称列出花费，控制台 → 日志在每条请求上标出 Key 名称，所以请按工作负载给 Key 命名。在应用或客户端日志中保存工作负载标签、模型、时间与返回的请求 ID，不要记录 Key 密钥。例如，为 LlamaIndex 管线配置独立 Key（接入指南），并把请求 ID 关联到管线运行。
第二步：先按 Key 看花费，再看请求日志
控制台 → 用量可按 API Key 查看所选时间段的花费、Token 和请求数，并跳转到该 Key 的日志；控制台 → 日志支持按模型、API Key、状态和日期筛选，API Key 列与请求详情会标出发起请求的 Key（网页端调用不带 API Key，单独标注）。每条记录包含模型、输入输出 token、成本、延迟与状态。
对账时，把日志（按当前筛选）导出为 CSV，钱包流水（所选时间段）也可以一并导出。同一把 Key 之内，再用应用保存的请求 ID 按终端客户、单次运行或功能拆分这把 Key 的总额：控制台的归因到 Key 为止，更细的一层靠你的标签。
成本按各模型公开费率的按量付费 token 价位计算——也就是模型页上公布的每百万 token 单价——FX 和支付通道费在结账时单独展示。没有需要你维护的价格表，你也不必自己估算：trace 记录的就是这条请求实际结算的费用。客户端在 /v1/chat/completions 或 /v1/responses 上取消一条已经开始输出的流、而网关没拿到最终 usage 时，这笔费用包含对上游未报告部分的估算（截至 2026-10-13），所以这条请求在控制台 → 日志里可能显示 0 token、费用却不为零——见 LLM 流式输出。计量使用 token 数和请求元数据。Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。
第三步：在出血之前设上限
只有归因、没有强制，你还是要等账单出来才在事后读到事故。每把 key 可以设置一个消费上限，并受两道平台限额约束：
- maxSpend —— 这把 key 最多能从钱包扣多少钱的硬上限
- rateLimit —— 每分钟请求数，平台默认值，可联系支持申请调高
- tokenLimitTpm —— 每分钟 token 上限，平台默认值，可联系支持申请调高
staging 环境里按量计费的重试循环撞到 staging key 的上限就停了，生产照常运行。泄漏的 key 被自己的上限兜住，而不是掏空整个钱包。可用额度归零时，套餐覆盖范围外的请求返回 HTTP 402（见错误码速查页），而不是默默累积意外欠费——计费语义在计价方法论页有详细文档。
Key 用量达到 maxSpend 的 80% 及触顶时，控制台会发送站内通知，失控的工作负载不必等账单出来才被发现。这些是站内通知，不是邮件或 webhook 告警；想在服务端盯住钱包余额，见余额监控。
第四步：按周复盘，而不是按月
每周复盘工作负载费用：先看控制台 → 用量里这一周按 Key 的花费，再对比请求数量、模型分布和 token 用量，并按需要调整各 Key 的上限。匹配不到自己标签的请求应单独列出，不要把费用随意归入某个工作负载。客户可见字段见 LLM 成本追踪和请求级可观测。
常见问题
如何按应用或按同事追踪 LLM API 开销？ 为每个应用、agent 或同事创建独立 Key，并按工作负载命名。之后控制台 → 用量会按 Key 显示所选时间段的花费、Token 和请求数，控制台 → 日志可按这把 Key 筛选，日志与钱包流水都能导出 CSV 用于对账。比 Key 更细的归因，在自己的日志中保存标签与请求 ID，再到请求日志核对。
网关会为每条请求记录什么？ 每条请求都会记录模型、发起请求的 API Key、输入输出 token 数、按公开费率计算的成本、延迟、状态与请求 ID。计量使用 token 数和请求元数据。Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。
每条请求的成本是怎么计算的？ 成本按各模型公开费率的按量付费 token 价位计算——也就是模型页上公布的每百万 token 单价——FX 和支付通道费在结账时单独展示。没有需要你维护的价格表，你也不必自己估算：trace 记录的就是这条请求实际结算的费用。客户端在 /v1/chat/completions 或 /v1/responses 上取消一条已经开始输出的流、而网关没拿到最终 usage 时，这笔费用包含对上游未报告部分的估算（截至 2026-10-13），所以这条请求在控制台 → 日志里可能显示 0 token、费用却不为零——见 LLM 流式输出。
能给单独一把 API key 设消费上限吗？ 可以。给这把 key 设置 maxSpend。每把 Key 的消费上限（maxSpend）限的是这把 Key 能从钱包扣的钱：累计扣费到上限后，这把 Key 上需要钱包付费的请求返回 HTTP 402。套餐额度覆盖的请求从账户共用的套餐额度里扣，不计入任何 Key 的上限。每把 key 还按平台默认的 rateLimit（每分钟请求数）和 tokenLimitTpm（每分钟 token 上限）运行，可联系支持申请调高。泄漏的 key 会被自己的上限兜住，而不是掏空整个钱包。
Key 快到上限时会有提醒吗？ 会，在控制台里：Key 用量达到 maxSpend 的 80% 及触顶时，控制台会发送站内通知。Key 额度提醒只在站内，也没有 webhook 告警；需要在服务端盯住钱包，可以轮询 GET /v1/balance（见余额监控）。
额度用完会发生什么？ 可用额度归零时，套餐覆盖范围外的请求返回 HTTP 402，而不是默默累积意外欠费。计费语义在计价方法论页有详细文档。
结论
独立 Key 用来控制消费风险，也让每个工作负载在用量报表里单独占一行；请求 ID 把更细的归因和费用连起来。在应用中维护工作负载对应关系，在控制台按 Key 看花费，再用导出的 CSV 与自己的标签核对，才能得到有依据的成本报告。
从每个工作负载一把 Key 开始，入口在 router.one；账本具体记录什么，见成本追踪概览。