Your team’s AI bill is the total of every key each engineer holds. One developer creates a key for a side experiment. Another wires a few keys into a CI pipeline. Someone else pastes a token into a notebook, gets the prototype working, and forgets the key is still active.

None of that is careless on its own, but add it up and the bill gets hard to explain. OpenRouter has 6 controls that bring order to it, and this article walks through each one, the team it suits, and the plan it needs.

The controls layer on top of each other. So start with the cheapest one that covers your risk, and only add more when you need them. When two controls overlap, the stricter one applies. Allowlists intersect and the lower budget blocks first.

What’s the fastest way to govern team AI spend on OpenRouter?

Pick the cheapest control that fits your team’s risk, then layer up. A small team often only needs per-key limits plus the Activity dashboard on day 1.

Each control does one of three jobs. Budgets and per-key limits decide how much can be spent. Model and provider allowlists decide what it can be spent on. The Activity dashboard shows who spent it. The 6 controls split across those three jobs and work together, so you rarely need all 6 at once.

The control comparison table

Read down from the top. The controls that block spend come first, and the ones that track it come last. All of them are available on free and pay-as-you-go plans except workspace budgets, which need Enterprise.

Control	What it caps or restricts	Where it’s set	Who can set it	Plan tier	Blocks or tracks
Per-key credit limit	Total credits one API key can spend	Dashboard or Management API	Key owner	Free / PAYG	Blocks (rejects over limit)
Guardrails	Budget + model/provider allowlist + privacy, per member or key	Settings › Privacy	Account owner (org admin in an organization)	Free / PAYG	Blocks (403 at budget cap)
Workspace budgets	Total spend for a whole workspace	Workspace settings or Management API	Organization admin	Enterprise	Blocks (403 at limit)
Presets	The model, routing, and config a request uses	Presets settings	Organization member (admin to share org-wide)	Free / PAYG	Tracks (a default, not a hard cap)
Organizations and roles	Who holds spending authority; shared credit pool	Organization settings	Org admin	Free / PAYG	Tracks (structure, not a cap)
Activity dashboard	Nothing; it reports	Activity page	All organization members (visibility)	Free / PAYG	Tracks (usage + export)

A practical setup usually pairs at least one blocking control with one reporting control. For example, a production service key gets a monthly limit, and the Activity dashboard tells you whether that service is actually where the spend is going. If one developer needs a tighter model allowlist or budget than everyone else, add a guardrail for that member.

What are you actually paying for?

Before you set up any controls, it helps to know what the spend actually is. We don’t mark up provider pricing, so the price in the model catalog is what inference costs. The platform fee is charged when you buy credits (5.5% on card top-ups for standard pay-as-you-go, minimum $0.80), not on each request. A request that fails doesn’t bill at all.

So there’s no hidden markup to police. The job of these controls is simply to cap how much real inference your team runs.

The model catalog lists the per-model rates you’ll be capping.

Bring-your-own-key (BYOK) spend behaves differently

BYOK spend doesn’t always count where you’d expect, so you’ll want to check this before you build controls around it. When you route through your own provider keys, we charge a 5% fee on the model cost, waived for the first 1 million BYOK requests per month.

Both workspace budgets and guardrail budgets count only OpenRouter credit spend by default, so if your team runs mostly on its own provider keys, a budget covers less of the bill than it looks like it does. Each has an Include BYOK spend setting (include_byok_in_budgets) you can turn on so BYOK inference counts toward the limit too.

Making each request cheaper is a separate topic from capping your team’s spend. For that, see provider routing for cost and prompt caching.

How do you cap spend on a single API key?

A per-key limit is the simplest hard cap. It limits one API key, and you don’t need an organization to use it.

Use it when you want to cap one engineer, service, environment, prototype, or contractor key. A staging key might get a small daily limit. A production service key might get a larger monthly one. A temporary evaluation key might reset weekly, so the experiment stops spending after the review ends.

You can set limits in the dashboard or through the Management API, which can create, rotate, update, and disable keys. That means an internal provisioning flow can issue every key with a limit from day one instead of relying on someone to add one later.

The weakness is that a per-key limit caps the key, not the person. If one person owns 5 keys, each with its own daily limit, they can spend the sum of all 5. The key doesn’t know about the others. Per-key limits also say nothing about which models or providers a caller can use.

Start with per-key limits. When you need a rule that follows a person, or one that combines a budget with model, provider, or privacy restrictions, move on to guardrails.

How do guardrails control budgets, models, and privacy?

A guardrail is a policy that follows a person or a key.

One guardrail can contain a budget limit, a model allowlist, a provider allowlist, Zero Data Retention rules, prompt-injection and jailbreak detection, sensitive-info handling, and custom regex filters. Assign it to an organization member and it becomes the baseline for all of that member’s keys. Or assign a guardrail directly to a single API key for tight control.

Use a guardrail when “cap this key” isn’t enough and the rule you actually want is “this person can only use these models, within this budget, under these privacy rules.”

Platform teams usually reach this point because different groups need different things. One group at your organization uses frontier models in production, where reasoning accuracy matters more than price; another runs batch jobs that depend on high volume and can work with cheaper models; a third team needs to handle inputs that may contain sensitive information and needs ZDR. Guardrails let you set those rules once instead of asking every application team to write policy into their code.

We follow one simple layering rule: stricter always wins. In the diagram, the layers included in a request are your account’s settings, your workspace’s defaults, the guardrail assigned to a member’s account, and the guardrail assigned directly to an API key. All layers combine into one effective request policy.

When more than one guardrail applies to a request, its access is limited by the strictest rules. Model and provider allowlists work on the same basis. For example, if the account baseline allows for 10 models but the API-key guardrail allows only three of those models, the key gets three models, not ten. The same applies for provider allowlists. For ZDR, if any layer turns it on for a model group, it’s on.

When multiple layers set a sensitive-info filter, they all apply, and if one of those filters blocks a request while another redacts it, the blocking rule wins. Budgets are checked separately too. If a team sets a member-level budget and a key-level budget, they don’t merge into one pool, which means a request has to pass both budgets.

For guardrails that control budgets, enforcement is per-user and per-key, and not shared. That means a guardrail budget applies independently to each member and key that you assign it to. If you give the same daily budget guardrail to three members, each of those members gets that budget separately; they don’t share one big pool. When a key makes a request to OpenRouter, usage counts toward both the key’s budget and the budget of the member who owns the key.

This is the main reason to use guardrails instead of only per-key limits. With guardrails, you can very easily cap the spending of a person across all their keys, while still having the ability to tighten a limit on one key if a particular application needs a smaller cap.

A few things to know. In an organization, only admins manage guardrails (a personal account can create guardrails for its own keys too). Keep in mind that your allowlists need some upkeep as your model policy changes. And when a budget runs out, the caller gets a 403, not a warning beforehand.

When should you use a workspace budget?

Use a workspace budget when you need a hard cap on an entire workspace, no matter how many keys live inside it. Set a USD limit for a daily, weekly, monthly, or lifetime window, and OpenRouter blocks requests with a 403 at the limit. This caps the whole environment at once, so you don’t have to police every key inside it.

Plan tier restrictions

Workspace budgets are an Enterprise feature, and they are created and managed by your organization’s admins. Per-key limits and guardrails work on both free and PAYG plans, but workspace budgets don’t. If you’re not on Enterprise, a per-member guardrail budget is how you cap your team’s spend instead.

How workspaces fit

A workspace keeps one team’s setup separate from another’s. Each workspace has its own keys, guardrails, BYOK, routing, presets, plugins, observability, members, and budgets. However, billing, management keys, and privacy settings live at the account level, and Activity and Logs are account-level views that you can filter by workspace. Because of this, a workspace budget effectively caps everything routed through that workspace at once, and only an admin can create or delete a workspace.

A few limits to know about:

• Each shorter window must have a smaller budget. A lifetime budget must be bigger than a monthly one, which must be bigger than a weekly one, which must be bigger than a daily one.
• BYOK requests. Requests that use your own provider key (BYOK), and thus don’t spend any OpenRouter credits, don’t count toward the budget by default. Enable the workspace’s Include BYOK spend setting to count them.
• Requests already in flight. Requests that are already in flight when a budget is hit will be allowed to finish. So actual spend can run slightly over before the next request is blocked.
• No email or webhook alerts yet. Callers will get a 403 when a request is blocked, and you can check the state of your budget by navigating to your workspace settings.

For the full set of rules and implementation details, see the workspace budgets documentation and the enterprise quickstart.

Can a preset control what a team spends?

Not directly. Presets set the defaults for what a request does, but don’t automatically put a cap on what it costs. That’s why they sit below the three hard caps above them: per-key limits, guardrail budgets, and workspace budgets.

A preset is a named configuration, referenced as @preset/slug, that can hold a model choice, fallback models, provider routing, a system prompt, and generation parameters. Instead of hard-coding those choices in every service, teams point requests at a shared preset and change the configuration in one place.

A lot of wasted AI spend starts with stale configuration. One service pins an expensive model for a task that no longer needs it. Another forgets to sort providers by price. A third keeps an old prompt that burns tokens on context nobody uses. Presets give platform teams one place to fix the default.

For example, a team could create a “support-triage” preset that uses a cost-appropriate model, sets provider: { "sort": "price" }, and keeps the system prompt consistent across apps. When the team needs to change the model or routing policy, it can update the preset instead of shipping code across multiple services.

The limit is that presets guide behavior rather than enforce it. A request can override any preset value by sending its own parameters. So presets are good for standardizing well-behaved applications, not for stopping a caller who sends different parameters.

How do organizations and roles control who can spend?

An organization puts everyone’s spend into one shared credit pool and decides who controls it. All members draw from central billing. Only admins can buy credits and set billing, provider, and privacy configuration. Members create their own keys and see only their own.

Create an organization when more than one or two people share AI spend and you want one bill and one set of admins.

There are two roles, Admin and Member. Admins hold the spending authority, and members work within it. There are no finer-grained permissions for sub-teams. Org-wide presets and guardrails let admins set defaults that apply to the whole organization.

Organizations have some limitations you should know about:

• An organization caps at 10 members - contact support to push the limits higher.
• Transferring personal credits into an organization is self-serve from the credits page, with eligibility rules (account and membership age, recently purchased credits, and cooldowns). Organizations billed by invoice can’t receive transfers.
• You can’t convert a personal account into an organization.
• Isolation inside an organization comes from workspaces, not roles. Each workspace gets its own keys, guardrails, and budgets while the org keeps one bill.

What can the Activity dashboard show about team spend?

The Activity dashboard is the reporting layer under every other control. Every API response includes a usage object with token counts and cost, plus each key exposes daily, weekly, and monthly usage totals. And in an organization, the Activity dashboard shows usage across members, with exports grouped by Model, API Key, or Creator (the org member). That’s where you find out who spent what on which model.

One thing to know: in organization context, the activity feed shows every member’s usage metadata to every member. That covers model, cost, and timing, but never prompts or responses. Members can’t scope the feed to just their own activity, which is good for shared accountability but can surprise teams expecting privacy inside a shared org.

One aside: adding more keys or accounts doesn’t raise your rate limits. Rate limits are a separate topic from spend limits; see the rate-limits reference.

Which controls fit your team?

Here’s a decision heuristic to match the controls below to your situation. Default to the cheapest one that fully covers the risk, unless there’s a reason not to. Only reach for Enterprise workspace budgets when you truly need a hard cap on a whole environment. Each line below is one decision:

• Solo or side project. A per-key credit limit with a monthly reset is all you need.
• Small team, one bill (under 10 people). An organization for the shared pool, per-key limits, and the Activity dashboard to see who’s spending what. Add a guardrail when one person’s access or budget needs to differ.
• Multiple teams, or staging-versus-prod. Workspaces to keep them separate, a guardrail per member or key for budgets, a model allowlist, and presets to standardize configuration. Add workspace budgets if you’re on Enterprise.
• Regulated or sensitive data. Guardrails with ZDR per model group, PII filters, and a provider allowlist. We’re SOC 2 Type 2 compliant but don’t offer a HIPAA business associate agreement (BAA), so a health-data workload that needs a BAA isn’t a fit for that specific requirement today.

Whatever your team looks like today, start simple. Set per-key limits now, and add guardrails and workspace budgets when team size or compliance actually calls for them.

Frequently asked questions

Can I set a spending limit per API key on OpenRouter?

Yes. Every API key can have a limit in credits and a limit_reset of daily, weekly, or monthly on any plan, free or paid. Requests past the limit get rejected, and you can read the remaining balance through GET /api/v1/key.

How do I cap spend for a whole team?

It depends on your plan. On free and pay-as-you-go plans, assign a guardrail with a budget to each member or key. Each member and key gets its own budget, and requests past it get a 403. On Enterprise, a workspace budget caps an entire workspace at once.

Can I restrict which models my team can use?

Yes, through a guardrail’s model allowlist (and a provider allowlist alongside it). An empty allowlist means all models are permitted. When multiple guardrails apply, the allowlists intersect, so the strictest one wins.

Can organization members see each other’s spend?

In an organization, the Activity feed shows all members’ usage metadata (model, cost, and timing) to all members. We don’t store prompts or responses, so the content of requests is never visible. The feed can’t be scoped to just your own activity in org context.

How many people can be in an OpenRouter organization?

Organizations are capped at 10 members. If you need more than that, let us know!

Does OpenRouter have per-team cost attribution?

At the moment, yes, but only at the member level. The Activity dashboard exports usage grouped by Creator (the org member), and each key reports daily, weekly, and monthly totals. There is no per-sub-team attribution.

Does OpenRouter alert me before I hit a budget?

Not yet. When you hit a cap, requests get a 403, and there’s no email or webhook warning beforehand. You can check current status in the dashboard. This applies to per-key limits, guardrail budgets, and workspace budgets alike.

Is OpenRouter HIPAA compliant for a healthcare team?

We don’t offer a HIPAA business associate agreement (BAA) today. We are SOC 2 Type 2 compliant, so for a health-data workload that requires a BAA, you’ll need a different path for that specific workload.