Introducing Workspaces
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:
- a developer building multiple distinct projects on one OpenRouter account
- an enterprise shipping across multiple teams
- an agent with multiple environments, e.g. staging and production
Separate workspaces for projects, teams, or agents
Each workspace has independent settings for:
| Setting | Description |
|---|---|
| API keys(opens in new tab) | Create and manage keys scoped to a workspace. |
| Guardrails(opens in new tab) | Set policies that govern all keys and members in the workspace, within your account-level restrictions. |
| BYOK(opens in new tab) | Bring your own provider keys per workspace or share across workspaces. |
| Routing(opens in new tab) | Optimize provider routing for cost, latency, throughput, or tool-calling quality. |
| Presets(opens in new tab) | Save shortcuts for system prompts, model configs, and request parameters. |
| Plugins(opens in new tab) | Configure different default plugin behavior for API requests in each workspace. |
| Observability(opens in new tab) | Connect different integrations per workspace, or send all traces to the same integration. |
| Members(opens in new tab) | 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(opens in new tab), click the workspace picker → Create Workspace(opens in new tab) → name it and add a description. You can also create and manage workspaces programmatically using the management API(opens in new tab).
See more detail in our docs(opens in new tab).
Account level visibility, billing, and controls
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:
- Activity(opens in new tab) & Logs(opens in new tab): View everything, with optional workspace filtering.
- Credits & Billing(opens in new tab): One bill across all workspaces.
- Organization(opens in new tab): Manage roles and workspace assignments.
- Management Keys(opens in new tab): API keys for cross-workspace configuration.
- Privacy(opens in new tab): Top-level restrictions apply to all workspaces and can't be overridden at the workspace level.
Frequently Asked Questions
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(opens in new tab).
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.
Share feedback with us
Tell us what you're building and any questions or feedback: we're on X(opens in new tab), Discord(opens in new tab), and LinkedIn(opens in new tab).