ModelPlane for teams: orgs, workspaces & shared keys

The moment a second engineer joins your project, the "just use my API key" approach to LLM infrastructure breaks. Someone commits a key to a repo, another person rotates it, and suddenly production is down because the key that was working yesterday is gone. You need multi-tenancy, but you don't need the complexity of building it yourself.

ModelPlane treats team access as a first-class routing problem, not an afterthought. The gateway separates identity, resources, and billing into distinct entities, gives you scoped keys that can't leak upstream, and lets an organization share credits across every workspace. This is the difference between a gateway that works for one developer and a gateway that works for a team.

The multi-tenant mess you're actually in

Most teams start with a single shared key. It's pragmatic until it isn't. You can't tell which teammate burned through the budget, you can't revoke access for one person without breaking everyone, and you definitely can't enforce different routing policies for different services.

Hard-coding a provider key in your backend is worse. That key is a direct line to your provider account, and it gets forwarded with every request. If it leaks, someone else can spend your money. If you need to rotate it, you're redeploying services.

The abstraction that fixes this is the same one that fixes provider lock-in: the model group. Your application sends requests to a model group like prod-chat, and the gateway decides which backend answers. Team access works the same way — you manage who can call that group, not which provider key they hold.

Three entities, one clean boundary

ModelPlane's multi-tenancy model separates three concerns that most systems conflate:

Entity	Responsibility
User	Login identity, audit actor
Workspace	Resource owner — API keys, backends, model groups, usage
Billing Account	Plan, credits, transactions

A user is who you are. A workspace is what you own. A billing account is how you pay. When these are the same thing, you get the single-developer experience. When they're separate, you get teams.

The workspace is the unit of isolation. Every resource — every API key, backend, model group, and usage log — belongs to a workspace. This means you can have a staging workspace and a production workspace with completely different routing configurations, and the keys for one can't touch the other's resources.

Organizations take this further. An organization requires a paid plan and can have multiple workspaces. Crucially, an organization's workspaces share the organization's credits. Your team gets one billing surface, not a dozen individual accounts to reconcile.

Key scopes: private vs. shared

The gateway API key is the credential your code actually uses. It's a gw-* bearer token that authenticates the request to ModelPlane. Two properties make it fundamentally safer than a raw provider key:

1. It's never forwarded upstream. The gateway strips the Authorization header carrying your gw-* key before making the upstream call. Your provider credentials are resolved server-side from encrypted storage. A leaked gateway key can't be used to call OpenAI directly.
2. Only the hash is stored. The plaintext key is returned exactly once at creation. If you lose it, you create a new one. There's no database of recoverable secrets to steal.

Keys come in two scopes, mirroring how your team actually works:

• Private keys — personal and member-scoped. Every user, including org members, can create these. They're yours, and they're tied to your identity for audit purposes.
• Shared keys — available to organization owners and admins. These are workspace-scoped credentials that multiple services can use without being tied to one person's account.

This is the key insight: shared keys are for machines, private keys are for humans. A CI pipeline gets a shared key scoped to the workspace it deploys to. A developer debugging locally uses their private key, and their usage shows up in audit logs under their identity.

Setting up an organization

The portal keeps tenant context visible before every resource action — you always know which org and workspace you're operating in. The flow is straightforward:

1. Create an organization (requires a paid plan).
2. Invite members with owner, admin, or member roles.
3. Create workspaces for different environments or product lines.
4. Add backends and model groups per workspace.
5. Issue shared keys for services, private keys for people.

A free user gets one auto-created default workspace. Paid users can have multiple personal workspaces. Organizations are where the real team structure lives.

Routing that respects team boundaries

The point of all this structure is that routing policies become team-manageable. Consider a typical setup:

• A prod-chat model group in the production workspace with a fallback chain across three providers.
• A staging-chat group in the staging workspace pointing at cheaper models.
• A data-extraction group with a system prompt injected for structured output.

Each group has its own backends, its own routing strategy, and its own usage accounting. The team that owns the data pipeline can change its routing without touching the chat application's configuration. The billing account sees one consolidated view of credits consumed across all workspaces.

This is what "LLM gateway for teams" actually means: not just a shared endpoint, but shared infrastructure with per-team control planes.

Code: one client, scoped by key

Here's how a service uses a shared key to talk to a model group. The code is identical to calling OpenAI directly — only the base_url and model name change.

from openai import OpenAI

client = OpenAI(
    base_url="https://modelplane.dev/v1",
    api_key="gw-your-shared-key-here",  # workspace-scoped, never forwarded upstream
)

response = client.chat.completions.create(
    model="prod-chat",  # a model group, not a provider model id
    messages=[
        {"role": "user", "content": "Summarize the incident report."}
    ],
)

print(response.choices[0].message.content)

The same code works for a developer using their private key. The gateway resolves the model group prod-chat to the appropriate backend, applies the routing strategy, and accounts the usage to the workspace that owns the key.

If the production workspace's primary provider has an outage, the fallback chain kicks in — the application doesn't need to know, and the developer doesn't need to change anything. The model group abstracts away both the provider and the team's access policy.

Billing that doesn't require a spreadsheet

The shared-credits model is the operational win. When an organization's workspaces share credits, you eliminate the monthly ritual of collecting individual usage reports and trying to figure out who owes what.

The gateway records usage per API key, per model group, and per model. You can see at a glance:

• Which workspace consumed the most tokens this month.
• Which model group is driving cost.
• Whether the staging group is accidentally handling production traffic.

This visibility turns billing from an argument into a report. And because the gateway handles the routing, you can also make cost a routing criterion — prefer cheaper models for internal tools, escalate to premium models only for customer-facing features.

The honest limitations

Multi-tenancy is a design goal, and the rollout is a process. The full org/workspace model is a v1 target, and some edge cases — like per-workspace concurrency limits surfacing billing atomicity gaps — are still being hardened. If you're evaluating ModelPlane for a large enterprise, it's worth confirming the specific org features you need are fully live.

For most teams, though, the core value is immediate: separate workspaces, scoped keys, shared billing, and routing policies that don't require a shared credential or a shared fate.

Stop sharing keys, start sharing infrastructure

The single most important step for any team building on LLMs is to stop treating provider keys as team infrastructure. They're not — they're a liability. ModelPlane replaces them with a routing layer that gives you the isolation of separate accounts and the simplicity of a shared one.

Create an organization, set up your workspaces, and issue scoped keys. Your future self, debugging a production incident at 2 AM, will thank you.

CTA: Create an organization.

---

This post is part of a series on building production-grade LLM infrastructure. Here's what else we've covered and what's coming:

• One endpoint, every model — why we built ModelPlane
• Routing strategies, explained — fallback, load-balance, conditional
• Model groups — the one abstraction that decouples your app from providers
• Bring your own keys, safely — how BYOK encryption works
• High availability for LLM apps — a fallback playbook
• Stop paying twice — route your coding-plan quota into production
• Price-aware routing — cut your LLM bill without changing models
• Credits, usage & billing, explained — one transparent bill
• 1600+ models, one API — the provider catalog
• One gateway, two regions — routing to global and China models
• ModelPlane for teams — orgs, workspaces & shared keys (you are here)
• Meet the assistant — an AI helper in your gateway dashboard
• Inside the routing engine — how a request flows from auth to upstream
• One thinking parameter, every model — unified reasoning
• The system prompt belongs at the router — not in your app