OpenRouter launches Workspaces with BYOK and per-project routing controls

• OpenRouter has shipped Workspaces, a way to split projects into separate environments with their own keys, routing, guardrails, plugins, and observability, according to OpenRouter's launch post and OpenRouter's announcement.
• The per-workspace settings list is fairly broad: OpenRouter's feature breakdown includes API keys, data policies, BYOK, provider routing preferences, presets, plugins, observability integrations, and team access.
• OpenRouter positioned the feature for teams running multiple projects or staging versus production setups, while OpenRouter's rollout thread says existing users are left in a Default workspace so nothing changes automatically.
• Isolation stops at configuration, not finance: OpenRouter's billing note says billing and activity remain unified at the account level, with admins getting cross-workspace control.
• Workspaces are available from the dashboard and through a management API, per OpenRouter's API note and the docs page.

You can read the full announcement, jump straight to the docs, and the launch thread is unusually concrete about what actually gets isolated, from routing preferences to org-level visibility.

OpenRouter's core pitch is simple: one account, multiple project environments.

According to OpenRouter's feature breakdown, each workspace can carry its own:

• API keys
• Guardrails and data policies
• BYOK settings
• Provider routing preferences
• Presets and plugins
• Observability integrations
• Team member access

That makes Workspaces less like a cosmetic folder layer and more like a control plane split for different apps, customers, or deployment stages.

The migration story is intentionally low drama. OpenRouter's rollout thread says every existing setup stays in a Default workspace, so current configurations do not get reshuffled unless users choose to create new environments.

OpenRouter also names the obvious use cases directly: developers juggling multiple projects, enterprises shipping across teams, and agents running separate staging and production environments.

Workspace boundaries do not create separate bills. OpenRouter's billing note says billing and activity stay unified at the account level, with full visibility across workspaces.

The permission model splits along role lines instead. Org admins get cross-workspace control, while members see only the workspaces they need. That is a notable design choice for teams that want configuration isolation without fragmenting spend or reporting.

OpenRouter did not keep Workspaces as a dashboard-only feature. OpenRouter's API note says teams can create them programmatically through the management API, and the docs are already live.

For teams already automating key rotation, routing presets, or environment setup, that API hook is the part worth bookmarking, because it turns Workspaces into something infrastructure can stamp out instead of something an admin clicks together by hand.