Spend Controls

​

The Two Layers

• Workspace Budgets
• Guardrails

​

Set a Maximum on the Workspace Default Guardrail

1. Put model, provider, privacy, and region policy on the workspace default guardrail.
2. Set the default guardrail budget to the highest per-member or per-key limit you want to allow.
3. Use a separate workspace budget for the pooled team cap and the final emergency stop.
4. Create additional guardrails with lower budgets for teams, roles, or individual users.
5. Assign each person to one additional tier when they need a lower limit. Remove the additional assignment when they need the default maximum.

• Workspace budget: the pooled limit for the whole workspace. Use it as the “everything is on fire, shut it down” limit for lost keys, runaway agents, or an unexpectedly large workload.
• Default guardrail: the highest per-member or per-key limit, plus the workspace-wide model and provider policy. Use it as the “this user or key is on fire, shut it down” limit.
• Additional guardrails: lower per-member or per-key tiers for teams, roles, or individuals.

​

Tiered Member Budgets Pattern

$50/day   → assigned to entry-level members
$200/day  → assigned to special users
$500/day  → assigned to power users

Workspace budget       → $10,000/month
Default guardrail      → $1,000/day per user
Power-user guardrail   → $500/day per user
Special-user guardrail → $200/day per user
New-user guardrail     → $50/day per user

• A member guardrail aggregates usage across all eligible org-owned keys that member has created. A single engineer using multiple keys still shares the same member budget.
• Usage counts toward the guardrail reset window (daily, weekly, monthly). There is no manual reset, only the configured interval rollover.
• Raising a member guardrail limit does not reset its counter. It changes the threshold; the member is unblocked only if their accumulated usage is below the new limit.

​

Budget Attribution and Key Ownership

• When an org member creates an API key, that key spend is attributed to that member guardrail budget.
• When an admin creates a workspace-owned key (system key with no creator_user_id), it does not resolve to any member guardrail. These keys must use a direct key guardrail assignment or the workspace default guardrail budget if they need a limit.
• Direct key guardrail assignments create an independent per-key budget check in addition to any member-level checks. A single key can have its own guardrail, but only one guardrail can be directly assigned to a key at a time.

• A shared admin-owned key used by an entire team draws against the admin member budget, not against each user who calls it. For per-person enforcement, each person needs their own key.
• A workspace-owned key with no creator is unattributed at the member level. Assign a key guardrail to it if it needs a budget.
• When a member creates a new key to bypass a rate limit, that key still counts toward the same member guardrail budget. A new key does not reset the member-level counter.

​

BYOK and Budget Accounting

• BYOK spend uses OpenRouter’s recorded inference-cost value for each request, not necessarily the amount your provider invoices you. A guardrail budget of $500/month with BYOK spend enabled counts that recorded value toward the limit.
• The workspace-level Include BYOK spend toggle applies the same recorded BYOK usage to workspace budget checks.
• Enabling the toggle on a workspace budget is independent from enabling it on any guardrail. Set both separately if you want both layers to count BYOK spend.

​

Terraform Pattern

resource "openrouter_guardrail" "budget_100_weekly" {
  name           = "budget-100-weekly"
  limit_usd      = 100
  reset_interval = "weekly"
}

resource "openrouter_guardrail" "budget_500_weekly" {
  name           = "budget-500-weekly"
  limit_usd      = 500
  reset_interval = "weekly"
}

​

Common Pitfalls

​

Related Guides

• Workspace Budgets
• Guardrails
• BYOK
• Terraform Provider