OpenRouter API key limits: what they cap, and what they don't

The short version

• Put a credit limit on every key, with a daily, weekly or monthly reset if you want a rolling allowance. OpenRouter itself recommends a limit on every key: a key with no limit can spend your entire balance, including any auto top-ups.
• If you use BYOK (your own OpenAI/Anthropic/other provider keys through OpenRouter), turn on “Include BYOK usage in limit”. It is off by default.
• For agents in an organization, add a workspace budget as a pooled cap. Workspace-owned keys are not covered by member guardrails.
• A cap blocks the next request, not the ones already running, and it stops your own app just as firmly as an attacker.

1. Set a credit limit on a key

In the dashboard, open the key on the Keys page and use Key limit: a credit limit in USD, a reset interval, and (once you have BYOK provider keys configured) the “Include BYOK usage in limit” toggle. Per-key limits are available on every plan, according to OpenRouter's guide to capping shared agent keys.

The same three fields can be set with a Management API key (it can manage keys but cannot make completion calls):

curl -X PATCH https://openrouter.ai/api/v1/keys/$KEY_HASH \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit": 20, "limit_reset": "daily", "include_byok_in_limit": true}'

limit_reset can be daily, weekly, monthly or null (API reference). Windows are UTC: daily resets at 00:00 UTC, weekly on Monday at 00:00 UTC, monthly on the 1st at 00:00 UTC. With no reset the limit is a lifetime cap. Keys OpenRouter creates for you during onboarding come with a $100 credit limit and expire after 180 days.

Pick the reset to match how the key is used. A daily limit a little above a normal day is the tightest ceiling on a runaway loop; a monthly limit alone lets a loop spend the whole month's allowance in an afternoon. Since the Management API can disable or delete any key in your account, give that key an expiration date (OpenRouter recommends it) and keep it out of your app.

2. What happens when the limit is hit

Requests on that key are rejected before they reach a provider until the window resets or you raise the limit. OpenRouter's limits page lists the key's own limit both under 402 credit errors and under 403 budget errors, and the capping guide describes a 403 Forbidden with a “Key limit exceeded” message. Either way error.metadata.limit_source is openrouter_key_limit, so check that field rather than the status code, and don't retry in a loop: a spent window won't clear until its reset time.

3. The BYOK gap

If OpenRouter routes your requests through your own provider keys (BYOK), that spend is billed by your provider, and OpenRouter charges a fee on it (BYOK docs). By default it does not count toward any OpenRouter cap:

• include_byok_in_limit defaults to false, so “a key that only uses BYOK providers never reaches its limit”.
• Workspace budgets and guardrail budgets also count only OpenRouter credit spend unless you turn on Include BYOK spend on each one. The key, the workspace and each guardrail have separate toggles.
• When BYOK spend is counted, OpenRouter uses its own recorded inference cost, not necessarily what your provider invoices (spend controls guide).

So for BYOK traffic, the provider's own controls still matter: see OpenAI hard limits and Anthropic workspace limits.

4. Balance, auto top-up and requests already running

OpenRouter is prepaid, so your credit balance is a natural ceiling, unless auto top-up keeps refilling it. Review the threshold and amount on the Credits page for agent workloads.

OpenRouter charges a request when it finishes. Its docs explain that many requests running at once could commit more than your balance covers before any of them settles, which is why some accounts also get an “in-flight spending budget” (a 402 with limit_source openrouter_in_flight_budget and a Retry-After header). The practical lesson for every cap: it is checked when a request starts, so requests already in progress can still finish and add to the bill.

5. Teams and agents: workspace budgets and guardrails

• Workspace budgets cap a whole workspace per day, week, month or lifetime. They're on every plan and only organization admins can change them. Once any configured budget is reached, the next request gets a 403.
• Guardrail budgets follow the key's creator, not whoever calls it. A shared key created by an admin draws on that admin's member budget.
• Workspace-owned keys (created with Owner set to Workspace, typical for agents and CI) have no creator, so member guardrails never apply. Cap them with the key's own credit limit, a guardrail assigned to the key, the workspace default guardrail or a workspace budget.
• Budgets are checked in order: guardrail budgets, then workspace budgets, then the key's own limit. The first one that's spent blocks the request.

6. Check where a key stands

Any key can read its own limits and usage:

curl https://openrouter.ai/api/v1/key \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

The response includes limit, limit_reset, limit_remaining, usage_daily/usage_weekly/usage_monthly, the separate byok_usage* fields, and budgets with an effective_budget: the budget that will block this key first.limit_remaining: null means the key has no limit of its own.

Checklist

1. One key per app or agent, so you can cap, read and revoke them separately.
2. Every key has a credit limit, with a daily reset for anything automated.
3. BYOK users: “Include BYOK usage in limit” is on for each key, and Include BYOK spend is on for workspace and guardrail budgets.
4. Auto top-up is off or small for accounts that run agents.
5. Agent and CI keys are workspace-owned and capped by their own limit or a workspace budget, not left relying on a member guardrail.
6. The Management API key has an expiration date and lives outside your app.
7. Your code handles 402/403 with limit_source without retrying in a tight loop.

Want to check all three providers in one go? Run the free AI key limit audit (no sign-up, no key needed).

What these limits don't do

• They don't tell you a key is spending unusually before it reaches the cap. A $50 monthly limit can be used up in an hour without any warning in between.
• A leaked key stays usable up to its limit. OpenRouter is a GitHub secret scanning partner and emails you if it determines a key was compromised; then delete the key and create a new one (see our leaked key response plan).
• A cap that's hit stops your own app too. That is the trade-off of any hard limit.

Where KeyBark fits (and where it doesn't)

KeyBark reads the same /api/v1/key usage figures from our servers (or /api/v1/keys/{hash} with a Management key) about every 15 minutes during the beta, and alerts you when a daily or monthly threshold you set is crossed or when today's spend jumps above your 7-day average. On paid plans you can opt in to a kill switch (beta) that disables a key you name through OpenRouter's API when a threshold is crossed. Once a day, leak watch also searches public GitHub code for the key you connected.

Limits, honestly: checks run on a schedule, so an alert can come after money has been spent; KeyBark reads OpenRouter credit usage and does not count BYOK usage; it is not a proxy, so it can't stop a request already in progress; and it never rotates keys for you. Set OpenRouter's own credit limit first. KeyBark is a second line of warning on top of it.

FAQ

Sources (read 29 Oct 2026): OpenRouter Authentication, Limits, Capping shared agent keys, Spend controls, BYOK and Management API keys. KeyBark is not affiliated with OpenRouter.