OpenRouter 工作区与预算：把团队的花销切开

2026-08-18

一、账单来了，没人说得清是谁花的

团队用同一个 OpenRouter 账号，通常是这么长起来的：一个人申了个 key 跑通了，另一个项目顺手复制了同一个 key；再后来测试和生产都在跑，还有人拿它接了内部 Agent 做批处理。等到某个月账单突然翻倍，你打开用量记录，看到的是混在一起的一整坨调用，想回答「哪个项目花的」只能靠猜。

OpenRouter 官方文档的 Workspaces 那一页把这件事定义成了「环境隔离」问题。文档原文写的是：workspace 让你把 OpenRouter 项目组织成彼此独立的环境，每个环境有自己的 API keys、routing 默认值、guardrails 和可观测性配置，用来隔离团队、项目或者部署阶段（文档举的例子是 staging 与 production）。

这里有个容易被忽略的前提：你现有的一切已经在一个叫 Default 的 workspace 里了。文档明说，你已有的 API keys、guardrails、BYOK provider keys、routing 策略、presets、plugins、可观测性集成全都在 Default workspace 中；不需要多个 workspace 就照旧用，什么都不会变。对组织账号，所有成员会被自动加入 Default workspace。

二、前置条件：谁能建、在哪一层、要什么套餐

这一段是本篇最该先看清的，因为「工作区」和「预算」两件事的门槛完全不一样。

建工作区的权限：官方文档在 Workspaces 页用 Note 明确写了，只有 organization admins 能创建和删除 workspace。普通 org member 只能在被加入的 workspace 里活动，可以在自己所属的任一 workspace 里创建自己的 key。

预算功能的门槛：Workspace Budgets 那一页开头的 Note 写得很直白——workspace budgets 属于 Enterprise plan 的能力，并且在 dashboard 里只有 Organization Administrators 能创建、编辑、删除预算；其他工作区成员可以查看预算和当前花销，但不能修改。文档还给了一条获取路径：联系 sales。所以如果你不在 Enterprise plan 上，本文第三节往后的内容对你不成立，这一点值得先确认，别照着配了半天才发现入口不属于你。

编程方式操作预算需要的凭据：文档写明，程序化的预算管理使用组织的 management API keys，而这类 key「operate at the account level」——在账号层面生效，不是某个 workspace 内部的普通 key。这里有点反直觉：操作的是某一个 workspace 的预算，用的却是账号级的管理密钥。对应文档页是 openrouter.ai/docs/guides/overview/auth/management-api-keys。

入口在哪一端：预算的路径，文档给的是工作区设置页 https://openrouter.ai/workspaces/<slug>/settings；工作区本身的创建入口是 openrouter.ai/workspaces。工作区也可以通过 management API 程序化创建与管理。

三、工作区隔离了什么，没隔离什么

配之前先搞清楚边界，否则很容易误以为「建了工作区就万事大吉」。

Workspaces 页用两个列表把这件事划得很清楚。按工作区独立的设置共 9 项（这个数字是照着文档那一节的条目数过的）：API Keys、Guardrails、BYOK、Routing、Presets、Plugins、Observability、Members、Budgets。其中几条文档给了额外说明：

API Keys：每一个 API key 都归属于某个 workspace。对组织账号，admin 可以创建归 workspace 所有、而非归个人所有的 system keys。
Guardrails：每个 workspace 有自己的 guardrail 来约束 API key 与成员的行为，它继承账号级策略，只能在其约束内追加更严格的规则。文档在 FAQ 里把这条讲得更绝对：账号级策略是上界，单个 workspace 只能更严，不能更松。
BYOK：既可以按 workspace 各配各的 provider key，也可以让多个 workspace 共用同一把。

账号级、跨所有工作区生效的设置共 6 项：Activity 与 Logs（可按 workspace 过滤）、Credits & Billing、Organization、Management Keys、Privacy、Preferences。

这个划分里最该记住的是 Credits & Billing 是账号级的，文档的说法是「Unified billing across all workspaces」。工作区解决的是「谁在花、花在哪」的归属与限额问题，不是把账单拆成几份分别付款。你要的如果是分别开票，文档里我们没有找到对应说明。

四、预算：四个 interval 与那条严格递减规则

Workspace Budgets 页写明，每个 workspace 最多可以有四个预算，一个 interval 一个。四个 interval 与文档给出的重置规则如下：

interval	重置时机
`daily`	每天 UTC 午夜
`weekly`	每周一 UTC 午夜
`monthly`	每月 1 日 UTC 午夜
`lifetime`	从不重置

注意这张表里的时区：文档写的是 midnight UTC。如果你的团队按本地时间对账，日预算的切换点和你心里那个「一天」不是同一个时刻。

限额是有序约束的。文档给出的规则是限额必须随 interval 收窄而严格递减：

lifetime > monthly > weekly > daily

文档同时说明，你不必四个都设，只有你实际设了的那些需要满足这个顺序。服务端会校验这条规则，若新的限额会破坏严格递减关系，请求返回 400 Bad Request，错误信息会点名是哪两个 interval 冲突了。

至于金额本身：本文一概不写具体数额，只写「可以设上限」这个能力，以及上限之间的约束关系。

触发时会发生什么：文档写明，请求进来时 OpenRouter 会拿工作区当前花销去比对每一条已配置的预算，只要任意一条达到或超过限额，请求就返回 403 Forbidden，错误信息里会点名「最宽的那个被突破的 interval」，让使用者知道是哪一层限额挡住了。

五、按官方文档写明的步骤配一遍

5.1 界面路径（文档写明的步骤）

Workspace Budgets 页给出的操作序列是：进入工作区的 Settings 页（地址形如 https://openrouter.ai/workspaces/<slug>/settings）→ 找到 Budgets 区块 → Add budget，选一个 interval 并填入金额 → 对其它 interval 重复 → Save。文档另外注明这几步需要 Organization Administrator 角色。

文档还提到，Enterprise 的 org admin 可以在创建工作区时就把预算配好——创建表单里有一个可选的 Budgets 区块，可以在任何 key 被签发之前先把限额定下来。对新项目来说这个顺序更稳：先立规矩，再发钥匙。

以上是文档文字写明的步骤，本文不描述这些页面长什么样。

5.2 API 路径

预算端点位于 /api/v1/workspaces/{id}/budgets。列出当前预算：

curl https://openrouter.ai/api/v1/workspaces/{workspace_id}/budgets \
  -H "Authorization: Bearer $MANAGEMENT_KEY"

创建或更新用 PUT，interval 放在路径里；文档写明，若该 interval 已有预算则会被更新（也就是 upsert 语义）：

curl -X PUT https://openrouter.ai/api/v1/workspaces/{workspace_id}/budgets/monthly \
  -H "Authorization: Bearer $MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit_usd": <你的上限金额>}'

合法的 interval 值就是前面那四个：daily、weekly、monthly、lifetime。上面这个 <你的上限金额> 是我们刻意替换掉的占位——官方文档的示例里写的是一个具体数字，那只是示例，照抄进你的脚本没有意义。

删除某个 interval 的预算：

curl -X DELETE https://openrouter.ai/api/v1/workspaces/{workspace_id}/budgets/monthly \
  -H "Authorization: Bearer $MANAGEMENT_KEY"

文档写明删除是幂等的：删一个本来就不存在的预算也返回成功。

返回体这边有个细节值得先看清。文档给的示例里，list 端点的 data 是一个数组（每个 interval 一条），upsert 端点的 data 是刚被写入的那一条，是个对象；两者装的单条预算字段是一样的，都包含 id、workspace_id、limit_usd、reset_interval、created_at、updated_at。写解析代码时别按同一个形状去取 data，list 要遍历，upsert 直接读。而 include_byok_in_budgets 不在每一行预算上，而是与 data 并列放在外层。文档专门解释了这个位置：因为它作用于整个 workspace，不是某一个 interval 的属性。

5.3 Windows 侧的写法差异

上面几条命令抄自官方文档，用的是 POSIX shell 写法：反斜杠续行、$MANAGEMENT_KEY 取环境变量。在 Windows PowerShell 里这两处都不通用——续行符是反引号，环境变量要写成 $env:MANAGEMENT_KEY，-d 里的单引号 JSON 也要按 PowerShell 的引号规则处理。这一段属于 shell 通用知识，不是 OpenRouter 官方文档的内容；最省事的做法是在 Windows 上用 Git Bash 或 WSL 直接跑原样命令，避免转写引入错误。密钥不要硬编码在脚本里，用环境变量传入。

以上为按官方文档中的参数语义组合的示例，未经实测，以官方文档与 --help 的实际输出为准。

六、边界：几处文档明说、但很容易踩的地方

BYOK 花销默认不算数。文档写明，默认只有 OpenRouter 信用额度的花销计入预算；用你自己的 provider key 走 BYOK 的请求默认不计入。要把它算进来，得把 include_byok_in_budgets 设为 true，文档对计入口径的描述是：按「若这次请求没用你自己的 key，OpenRouter 本来会收的那个金额」计。这个字段有两条文档明说的坑：一是它作用于整个 workspace，请求 URL 里那个 interval 不会限定它的作用范围；二是不打算改就别发这个字段，省略表示保持现状，显式发 false 是关闭。

超支不是硬截断。FAQ 写得很实在：预算检查发生在请求被路由到 provider 之前，已派发出去的在途请求会跑完，所以实际花销可能略微超过限额；超支被识别之后的下一个请求才会被拦。

没有主动通知。FAQ 原文写的是「There are no proactive email or webhook notifications yet」——目前没有邮件或 webhook 的预告通知，用户感知到的方式就是那条 403，预算状态要去工作区设置页看。这个 yet 意味着以后可能有，但今天你不能指望它，得自己在监控侧兜一层。

成员不能自行放宽。只有 org admin 能改预算，程序化修改需要组织的 management API key；被挡住的成员只能找 org admin 抬限额。

移除成员前要先删他的 key。Workspaces 页的 FAQ 写明：把某人从一个 workspace 移除时，你必须先删掉他在那个 workspace 里创建的所有 API key，否则移除不了；他在其它 workspace 的访问不受影响。另外，只要人还在组织里，就始终保留 Default workspace 的访问权。

切换工作区会掐掉正在流式输出的回复。Switching Workspaces 页用 Warning 标出：在聊天回复还在流式返回时切换工作区会取消这次回复，切换前会要求确认；Fusion 的运行不受影响，它会在后台继续流式输出，并保存到发起时所在的 workspace。关键在于文档那句「active workspace 决定这些请求由哪个工作区的 keys、routing 默认值、guardrails 和 budgets 管辖」——切错工作区不只是记录归错档，连限额和路由策略都换了一套。切换器只列出你已加入的工作区；你的选择会跨会话记住，直到下次再切。

dashboard 可能显示旧值。文档有一条 Note：通过 API 改动会立刻对预算执行生效，但一个已经打开着的工作区设置页可能仍显示改动前的值，直到重新加载。排查「改了没生效」时，先排除这一条。

以上这些页面里，我们没有看到 beta、preview 或 deprecated 的标注；预算功能标的是 Enterprise plan 限定，这是套餐门槛不是实验状态，两者别混为一谈。

七、怎么验证配对了

按文档语义，能自查的点有这么几个，都不依赖界面：

列一遍：对目标 workspace 调 GET /api/v1/workspaces/{id}/budgets，确认返回的 data 里包含你打算设的那些 interval，reset_interval 与 limit_usd 是你预期的值。
确认 BYOK 口径：看返回体外层的 include_byok_in_budgets 是不是你要的那个布尔值。文档写明这个值在 list、upsert 两个端点以及工作区资源本身（GET /api/v1/workspaces/{id}）上都会返回，三处都能核。
确认顺序约束：分多次设置多个 interval 时，服务端会用严格递减规则校验，全程没有收到 400 Bad Request 就说明这组限额是自洽的。
确认归属：新建的 key 确实建在目标 workspace 下，而不是习惯性地又落回 Default workspace。key 落错地方，后面的限额与 guardrail 全都对不上号。
确认 Chat/Fusion 的 active workspace：文档写明这两处的请求跑在成员的 active workspace 里，初始值是 Default workspace。想让某人的日常对话也计入某个项目工作区，光把他加进去还不够，他自己得切过去。

最后一句老生常谈但确实必要：该平台迭代频繁，文中涉及的端点、字段名与角色要求随版本变动，配置前请以官方文档最新内容为准。

本文依据 OpenRouter 官方文档（openrouter.ai/docs）于 2026-08-18 的公开内容整理。该平台闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观与运行表现的任何描述。该平台的供应商、模型与路由策略随时变动，文中不列具体供应商名单与模型清单；价格、额度与限流的具体数值请以官方定价页与用量说明为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。