Summary: OpenRouter introduced Workspaces on April 22, 2026 to separate projects, teams, and environments within one account, with independent API keys, guardrails, routing, presets, plugins, observability, BYOK, and members. Account-level billing, organization management, management keys, and privacy policies remain shared, and workspaces may tighten inherited data, provider, model, or guardrail policies but cannot loosen them. Default workspace access persists for all organization members, and Chat or Fusion boundaries need checking against current product behavior.
OpenRouter has long been a go-to API gateway for large language models (LLMs), but one constraint shaped it until recently: every project lived inside the same default environment. That changed on April 22, 2026, when OpenRouter unveiled Workspaces, a way to organize projects into separate environments—each carrying its own API keys, guardrails, routing defaults, and observability. Drawing on OpenRouter’s official announcement and documentation, this piece walks through what shipped, how the mechanics work, where the feature earns its keep, and where it still falls short.
From One Default to a Whole Fleet of Workspaces
Until now, every OpenRouter account came with exactly one “Default workspace.” Every API key, routing preference, guardrail, and member sat under that single roof—workable for a solo developer, chaotic for teams juggling several projects, environments (staging against production), or agents. Workspaces bring environment isolation inside a single account. Nothing about your current setup moves: it stays put in the Default workspace, and you can spin up additional workspaces whenever the need arises.
As OpenRouter’s blog puts it, “Workspaces give you organization, flexibility, and control.” The feature targets “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.”
The Mechanics: Control Split Across Two Tiers
Settings divide into two tiers: account-level (global or inherited) and workspace-level (tied to one environment).
Account-Level Tier (Shared Across Workspaces)
These apply across workspaces or set inherited constraints:
- Activity & Logs (filterable per workspace)
- Credits & Billing (a single bill covering all workspaces)
- Organization management (roles plus workspace assignments)
- Management Keys (API keys built for cross-workspace configuration)
- Privacy policies (top-level data-retention restrictions that no workspace may relax)
Workspace-Level Tier (Independent Per Environment)
Within each workspace, the following live in isolation:
- API keys: valid only inside that workspace
- Guardrails: policies binding all keys and members, bounded by account-level restrictions
- BYOK: bring your own provider keys per workspace, or share them
- Routing: tune independently for cost, latency, throughput, or tool-calling quality
- Presets: keep shortcuts to system prompts and model configs
- Plugins: set default plugin behavior per workspace
- Observability: hook up different integrations, or funnel every trace into one
- Members: decide which team members can enter each workspace
Wherever a workspace inherits account-level data, provider, model, or guardrail policies, it can tighten those constraints but never loosen them. The one-way rule ends there, though: API keys, routing, presets, plugins, and the other workspace-specific controls stay independently configurable.
Putting Workspaces to Work
Where It Pays Off
- Staging vs. Production: Hold development API keys and routing apart from production. Staging can lean on cheaper models; production can chase latency.
- Multi-Project Development: Hand each project dedicated API keys and guardrails, so one project’s mess never bleeds into another.
- Team Collaboration: Seat members in the workspaces they belong in—Researcher A sees only the “Research” workspace, while Developer B works on “Production.”
Creating a Workspace
Open your home dashboard, use the workspace picker → Create Workspace, then give the workspace a name and a description. You can likewise build and administer workspaces through code with the Management API—the backbone of infrastructure-as-code workflows: raise a temporary workspace for CI/CD, run your tests, then tear it down.
Management keys operate at the account level and can administrate every workspace through the API, so one key is all it takes to manage settings across environments.
The Fine Print on Member Permissions
- Workspace members can create and manage their own API keys within that workspace and view fellow members and their roles. Holding seats in multiple workspaces at once is allowed.
- Org admins act as superusers across every workspace: they can view and edit all of it (API keys, guardrails, routing, etc.), and they alone can create or delete workspaces or decide who gets in.
- Removing a member: first delete any API keys that person created in the workspace. Their access to other workspaces carries on untouched. And crucially, “all org members retain access to the Default workspace as long as they remain in the org.” You cannot shut someone out of the Default workspace while keeping them in the organization; true isolation may mean removing them from the org altogether.
Current Limits and Trade-Offs
No first version covers everything. OpenRouter’s announcement and FAQ name these:
- Chat and Fusion selection. The workspace switcher in the sidebar covers Chat and Fusion. Before treating either as a hard environment boundary, check their usage and data scope against current product behavior.
- Inherited policy boundaries. Account-level data-retention, provider/model, and guardrail policies all bind workspaces: tighter is allowed, looser is not, while the remaining workspace-specific settings stay independent. Where the account policy permits retention, a production workspace can still impose a stricter guardrail even as staging runs different logging or retention settings wherever the product allows.
- Member management nuances. Every org member can always reach the Default workspace—an obstacle to strict access control around sensitive projects.
None of these should stop most teams outright, but each deserves a weigh-in before complex workflows migrate.
The Bottom Line
Treat Workspaces as foundational infrastructure work rather than another flashy AI feature: they turn OpenRouter from a solo developer tool into an LLM gateway a team can actually govern. Timing depends on where you stand:
- Right away, if shared API keys across projects, hand-editing routing between staging and production, or missing member access controls already hurt.
- Before long, if your LLM usage is set to grow across multiple teams or environments.
- Hold off, if you develop alone on the Default workspace—it keeps working exactly as before.
To begin, head to your home dashboard, create a workspace, and try out one separated environment. The official docs carry detailed guides. Hit an edge case? OpenRouter welcomes feedback on X, Discord, or LinkedIn—a feature like this should iterate quickly on user input, and your voice can steer where it goes.
All told, Workspaces tackle a real pain point for teams that take LLM infrastructure seriously: clean isolation, granular control, and programmatic management—the very ingredients production-grade deployments demand.