We launched workspaces to organize your OpenRouter projects into separate environments, each with its own api keys, routing defaults, guardrails and observability.
Workspaces give you organization, flexibility, and control. Consider them if you are:
Each workspace has independent settings for:
| Setting | Description |
|---|---|
| API keys | Create and manage keys scoped to a workspace. |
| Guardrails | Set policies that govern all keys and members in the workspace, within your account-level restrictions. |
| BYOK | Bring your own provider keys per workspace or share across workspaces. |
| Routing | Optimize provider routing for cost, latency, throughput, or tool-calling quality. |
| Presets | Save shortcuts for system prompts, model configs, and request parameters. |
| Plugins | Configure different default plugin behavior for API requests in each workspace. |
| Observability | Connect different integrations per workspace, or send all traces to the same integration. |
| Members | Control which team members have access to each workspace. |
Your existing OpenRouter setup lives in a Default workspace. If you don’t need multiple workspaces, just keep working as usual.
To create a new workspace, navigate to your home dashboard, click the workspace picker → Create Workspace → name it and add a description. You can also create and manage workspaces programmatically using the management API.
See more detail in our docs.
Some of your OpenRouter settings will still matter for all of your workspaces. Think of them like global account settings. Here’s what’s shared across workspaces:
1. What can my workspace members see about a workspace?
Within a workspace, members can create and manage their own API keys, and view other members and their roles. Members can belong to multiple workspaces. All org members automatically have access to the Default workspace. At the account level, members can view Activity and Logs.
2. What can my organization admins see? What can they edit?
Org admins have admin permissions across all workspaces: they can view and manage everything in every workspace, including API keys, guardrails, BYOK, routing, presets, plugins, observability, members, and settings. Only org admins can create or delete workspaces and control members’ access to each workspace. At the account level, org admins manage billing and credits, organization membership and roles, management API keys, and account-level data policies and allowed providers/models.
3. Can management keys be used across workspaces?
Yes. Management keys operate at the account level and can be used to perform administrative actions across all workspaces via the management API.
4. Can workspaces have different data policies?
Workspaces inherit account-level data policies and allowed providers/models. Within those constraints, each workspace can set more granular guardrails to further restrict API key and member activity. The account-level policy is the ceiling; individual workspaces can only be more restrictive.
5. What happens when I remove someone from a workspace?
When a member is removed from a workspace, they lose access to it. Before removing them, you must first delete any API keys they created in that workspace. Their access to other workspaces is unaffected. Note: all org members retain access to the Default workspace as long as they remain in the org.
6. Is my chatroom/fusion usage in a workspace?
Yes. All chatroom and fusion usage is in the Default workspace.
Tell us what you’re building and any questions or feedback: we’re on X, Discord, and LinkedIn.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。