OpenRouter has been a popular API gateway for large language models (LLMs), but until now, users had to manage all projects under a single default environment. On April 22, 2026, OpenRouter announced Workspaces, a feature that lets you organize your projects into separate environments—each with its own API keys, guardrails, routing defaults, and observability. This article breaks down what’s changed, how it works, practical use cases, and current limitations, drawing directly from OpenRouter’s official announcement and documentation.
What Changed: From One Default to Many Workspaces
Previously, every OpenRouter user had a single “Default workspace.” All API keys, routing preferences, guardrails, and members operated under the same umbrella. That worked for solo developers but became unwieldy for teams juggling multiple projects, environments (staging vs. production), or agents. Workspaces introduce environment isolation within one account. Your existing setup remains untouched in the Default workspace, and you can create additional workspaces as needed.
According to OpenRouter’s blog, “Workspaces give you organization, flexibility, and control.” They are designed for “a developer building multiple distinct projects on one OpenRouter account,” “an enterprise shipping across multiple teams,” or “an agent with multiple environments, e.g. staging and production.”
How It Works: Two Layers of Control
Workspaces separate settings into two tiers: account-level (global or inherited) and workspace-level (per environment).
Account-Level (Shared Across Workspaces)
These settings can apply across workspaces or define inherited constraints:
- Activity & Logs (can be filtered by workspace)
- Credits & Billing (single bill across workspaces)
- Organization management (roles and workspace assignments)
- Management Keys (API keys for cross-workspace configuration)
- Privacy policies (top-level data-retention restrictions that workspaces cannot loosen)
Workspace-Level (Independent Per Environment)
Each workspace has its own isolated settings for:
- API keys: scoped to that workspace only
- Guardrails: policies that govern all keys and members, within account-level restrictions
- BYOK: bring your own provider keys per workspace or share
- Routing: optimize for cost, latency, throughput, or tool-calling quality independently
- Presets: save shortcuts for system prompts and model configs
- Plugins: configure default plugin behavior per workspace
- Observability: connect different integrations or send all traces to the same one
- Members: control which team members access each workspace
Where a workspace inherits account-level data, provider, model, or guardrail policies, it can make those inherited constraints more restrictive but cannot loosen them. This one-way rule does not apply to every workspace setting: API keys, routing, presets, plugins, and other workspace-specific controls remain independently configurable.
Practical Use Cases and Implementation
Use Cases
- Staging vs. Production: Keep development API keys and routing separate from production. Staging can use cheaper models; production can prioritize latency.
- Multi-Project Development: Each project gets its own API keys and guardrails, reducing cross-project contamination.
- Team Collaboration: Assign members to specific workspaces. For example, Researcher A only has access to the “Research” workspace, while Developer B works on “Production.”
How to Create a Workspace
From 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. This is key for infrastructure-as-code workflows: spin up a temporary workspace for CI/CD, run tests, then delete it.
Management keys operate at the account level and can administrate all workspaces via the API, meaning one key is enough to manage settings across environments.
Member Permissions Details
- Workspace members can create and manage their own API keys within that workspace and see other members and roles. They can belong to multiple workspaces.
- Org admins are superusers across all workspaces: they can view and edit everything (API keys, guardrails, routing, etc.) and are the only ones who can create or delete workspaces or control member access.
- Removing a member: Before removal, you must delete any API keys they created in that workspace. Their access to other workspaces remains. Crucially, “all org members retain access to the Default workspace as long as they remain in the org.” That means you cannot lock someone out of the Default workspace while keeping them in the organization; if you need full isolation, you may need to remove them from the org entirely.
Limitations and Trade-Offs
No first version is perfect. OpenRouter’s announcement and FAQ acknowledge the following:
- Chat and Fusion selection. Chat and Fusion can be selected with the workspace switcher in the sidebar. Their usage and data scope should still be checked against current product behavior before treating them as strict environment boundaries.
- Inherited policy boundaries. Account-level data-retention, provider/model, and guardrail policies can constrain workspaces. A workspace may tighten an inherited policy but cannot loosen it; other workspace-specific settings remain independent. If the account policy permits retention, a production workspace can still apply a tighter guardrail while staging uses different logging or retention settings where the product allows it.
- Member management nuances. The Default workspace is always accessible to all org members, which may complicate strict access control for sensitive projects.
These are not deal-breakers for most teams, but they are worth considering before migrating complex workflows.
Concrete Takeaway
Workspaces is a foundational infrastructure upgrade rather than a flashy AI feature. It transforms OpenRouter from a solo developer tool into a team-governable LLM gateway. Here’s when you should adopt it:
- Immediately, if you already feel pain from shared API keys across projects, manual routing changes between staging and production, or lack of member access control.
- Soon, if you plan to scale your LLM usage across multiple teams or environments.
- Not yet, if you’re a solo developer using only the Default workspace—it remains fully functional.
To get started, visit your home dashboard, create a workspace, and experiment with one separate environment. Check the official docs for detailed guides. And if you encounter edge cases, OpenRouter encourages feedback on X, Discord, or LinkedIn. This is a feature that will likely iterate quickly based on user input—so your voice can shape its evolution.
In summary, Workspaces address a genuine pain point for teams serious about LLM infrastructure. They provide clean isolation, granular control, and programmatic management—all essential for production-grade deployments.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.