# OpenRouter Rate Limits: 20 RPM Caps, 429 Errors, and Agent Storage Workarounds

OpenRouter restricts free models to 20 requests per minute and 50 to 1,000 requests per day based on credit purchases, while paid models remove platform caps in favor of upstream provider capacity. Most HTTP 429 errors stem from downstream provider congestion rather than gateway throttling. For AI agents, dumping raw documents into prompts accelerates limits. Offloading files to indexed storage prevents redundant requests.

Source: https://fast.io/resources/openrouter-rate-limit/
Author: [Tom Langridge](https://fast.io/authors/tom-langridge/)
Last reviewed: 2026-09-13

## What Are OpenRouter Rate Limits and Request Tiers?

OpenRouter caps free model calls at 20 requests per minute and 50 requests per day for accounts under $10 in lifetime purchases, expanding to 1,000 requests per day once crossing that threshold, though HTTP 429 errors often originate from upstream providers rather than OpenRouter itself. Understanding where those boundaries live prevents broken client requests and failed agent runs.

An OpenRouter rate limit is a concurrency and request-frequency restriction imposed by the OpenRouter gateway or downstream model providers, governing requests per minute and daily credit burn.

Because OpenRouter aggregates hundreds of large language models across multiple hosting providers, it separates operational constraints into two distinct tiers: free model endpoints and paid model endpoints. You can monitor these limits directly in the [OpenRouter limits documentation](https://openrouter.ai/docs/api_reference/limits) and manage credentials via the [OpenRouter API keys dashboard](https://openrouter.ai/keys).

### Free Model Limits and Credit Scaling

Free models carry the `:free` suffix in their model identifier, such as `google/gemma-4-31b-it:free` or `nvidia/nemotron-3-super:free`. OpenRouter imposes strict platform-level constraints on these endpoints:

- **Requests Per Minute (RPM):** Every free model is restricted to a ceiling of 20 requests per minute. This rate limit applies globally across your account, meaning that generating multiple API keys does not multiply your per-minute throughput.
- **Requests Per Day (RPD) Without Credits:** Accounts that have purchased less than $10 in lifetime credits are restricted to 50 requests per day across all free models.
- **Requests Per Day (RPD) With Credits:** Accounts that purchase at least $10 in lifetime credits receive an expanded allocation of 1,000 requests per day across free models.

Earlier third-party articles frequently cited a flat allowance of 200 requests per day. Official OpenRouter documentation defines the explicit free model request split: 50 requests per day for users who have purchased under $10 in credits, expanding to 1,000 requests per day once $10 or more in credits have been purchased. Purchasing more than $10 in OpenRouter credits does not raise the free model limit beyond 20 requests per minute.

### Paid Endpoints and Upstream Provider Quotas

Paid model endpoints on OpenRouter, such as Claude 3.5 Sonnet, GPT-4o, or DeepSeek R1, operate without platform-level request caps from the OpenRouter gateway. There is no artificial 20 RPM ceiling or daily request cap imposed by OpenRouter on paid calls.

Instead, paid throughput depends on two variables:

1. **Account Credit Balance:** Your requests run as long as your prepaid balance remains positive and individual API key spending caps have not been reached.
2. **Upstream Provider Capacity:** Each underlying model host (such as Fireworks, Together, DeepInfra, or direct model labs) maintains its own internal queues and concurrency throttles.

### OpenRouter Access Tiers and Limits

| Access Tier | Requests Per Minute (RPM) | Requests Per Day (RPD) | Credit Requirement | Primary Throttling Source | Status Checked |
| --- | --- | --- | --- | --- | --- |
| Free (Unfunded) | 20 RPM | 50 RPD | Under $10 purchased | OpenRouter platform cap | September 2026 |
| Free (Funded) | 20 RPM | 1,000 RPD | At least $10 purchased | Upstream provider saturation | September 2026 |
| Paid (Per-Token) | Uncapped by gateway | Uncapped by gateway | Positive credit balance | Upstream inference host capacity | September 2026 |
| BYOK Routing | Direct provider tier | Direct provider tier | External provider account | Upstream account tier | September 2026 |

Cloudflare DDoS mitigation sits in front of the entire OpenRouter gateway, blocking abnormal traffic bursts that exceed standard programmatic thresholds.

## Why HTTP 429 Errors Happen on OpenRouter

When an API call fails with status code 429 Too Many Requests, developers frequently assume their OpenRouter account ran out of quota. In practice, 429 responses originate from two separate layers in the routing path. Distinguishing between them determines whether you need to wait, add credits, switch models, or reconfigure provider fallbacks.

### OpenRouter Platform Rate Limits

OpenRouter itself generates an HTTP 429 error when your application exceeds gateway-enforced policies:

- Exceeding the 20 requests per minute threshold on `:free` model variants.
- Reaching the 50 or 1,000 daily request ceiling on free models.
- Triggering Cloudflare perimeter protection through concurrent request flooding.

When OpenRouter issues a platform-level 429, the response headers contain diagnostic counters:

- `X-RateLimit-Limit`: The total request quota allocated for the current window.
- `X-RateLimit-Remaining`: The number of requests remaining before rejection.
- `X-RateLimit-Reset`: The Unix timestamp indicating when the current rate limit window resets.

Successful completion responses omit these `X-RateLimit-*` headers. They appear on rate-limited error responses so clients can pause execution until the reset window expires.

### Upstream Provider Congestion

The second source of 429 errors is the upstream inference host. Because OpenRouter routes requests to external providers, your request can fail even when your OpenRouter account has consumed zero requests in the current minute.

If the provider hosting a free or paid model experiences queue saturation, that provider rejects the incoming request with a 429 status code. When upstream providers like Google AI Studio or Poolside reach capacity, requests fail with a 429 from the upstream provider rather than because the account breached its daily request ceiling.

When an upstream provider throttles a request, OpenRouter inspects the failure:

1. OpenRouter attempts automatic failover to other configured providers hosting that identical model.
2. If all eligible providers are congested, OpenRouter returns an error payload containing `error.metadata.provider_code`, which holds the upstream provider's raw status code.
3. If every attempted provider supplied a retry hint, OpenRouter includes a standard `Retry-After` header indicating how many seconds to wait.

### Mid-Stream Rate Limit Failures

Streaming requests present a unique error scenario. When you stream tokens using Server-Sent Events (SSE), OpenRouter sends an initial HTTP 200 OK header as soon as the upstream connection opens.

If the provider encounters queue congestion or rate limiting after generation has started, the HTTP status cannot be rewritten to 429. Instead, OpenRouter emits an SSE chunk containing `finish_reason: "error"`:

```text
data: {"id":"cmpl-9x1","object":"chat.completion.chunk","created":1726210000,"model":"meta-llama/llama-3.3-70b-instruct","provider":"Together","error":{"code":429,"message":"Rate limit exceeded"},"choices":[{"index":0,"delta":{"content":""},"finish_reason":"error"}]}
```

Applications that only check the initial HTTP status code will miss mid-stream throttles. Your streaming parser must inspect chunk payloads for terminal error events.

### Credit Limits (HTTP 402) vs. Rate Limits (HTTP 429)

Credit limits restrict total spending, whereas rate limits restrict request speed and concurrency. If your prepaid credit balance drops to zero or goes negative, OpenRouter rejects requests with HTTP 402 Payment Required.

A negative credit balance also blocks access to free model variants. Accounts must maintain a zero or positive balance to route requests through `:free` models. Calling `GET https://openrouter.ai/api/v1/key` returns your current balance and per-key spending limits through `limit_remaining`.

## How to Resolve and Mitigate OpenRouter 429 Errors

Handling 429 errors requires defensive code in your API client, alongside intelligent routing configurations in your OpenRouter request payloads.

### 1. Implement Exponential Backoff with Jitter

When requests are throttled, avoid retrying immediately. A tight retry loop compounds queue congestion and prolongs the block. Read the `Retry-After` header if present; otherwise, apply exponential backoff with randomized jitter.

```python
import time
import random
import requests

def call_openrouter(messages, model="openai/gpt-4o", max_retries=4):
    url = "https://openrouter.ai/api/v1/chat/completions"
    headers = {
        "Authorization": "Bearer OPENROUTER_API_KEY",
        "Content-Type": "application/json"
    }
    payload = {
        "model": model,
        "messages": messages,
        "models": [
            model,
            "anthropic/claude-3.5-sonnet",
            "google/gemini-2.5-pro"
        ]
    }
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json=payload)
        if response.status_code == 200:
            return response.json()
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            wait_seconds = float(retry_after) if retry_after else (2 ** attempt) + random.uniform(0.5, 1.5)
            error_data = response.json().get("error", {})
            metadata = error_data.get("metadata", {})
            provider_code = metadata.get("provider_code")
            print(f"Throttled (Provider: {provider_code}). Retrying in {wait_seconds:.2f}s...")
            time.sleep(wait_seconds)
            continue
        response.raise_for_status()
    raise RuntimeError("Request exceeded maximum retry attempts.")
```

### 2. Configure Model Fallback Arrays

To declare fallbacks, OpenRouter allows clients to list secondary models directly inside the `models` parameter. If the primary model fails across all available hosts due to capacity constraints or rate limits, the gateway routes the request to the secondary model automatically before returning an error to your application.

### 3. Adjust Provider Routing Preferences

For provider selection, OpenRouter balances latency, pricing, and availability by default. If you configure strict provider sorting flags, you restrict the pool of eligible hosts. Relaxing provider pinning allows OpenRouter to dispatch requests to any active cluster hosting the target weights.

### 4. Supply Direct Keys via BYOK

Bring Your Own Key (BYOK) allows you to enter your direct provider credentials in OpenRouter account settings. When you call models through BYOK, your requests draw down your dedicated organization quota with that provider rather than OpenRouter's shared community allocations.

## The Agent Rate-Limit Multiplier: Why Prompt Stuffing Breaks Quotas

Autonomous AI agents, coding assistants, and multi-turn workflows run into OpenRouter rate limits far faster than conversational chat interfaces. This failure mode stems from the structural difference between single-prompt interactions and automated agent loops.

### How Agent Loops Compound Request Frequency

A human user submits a prompt, reads the response, and replies after thirty seconds. An autonomous agent (such as Cline, Cursor, Roo Code, or an OpenClaw worker) operates in a continuous execution cycle:

1. The agent inspects its objective and issues a tool call.
2. The local system executes the tool call and captures output.
3. The agent immediately transmits the entire updated conversation history back to the model.
4. The cycle repeats dozens of times without human pauses.

When an agent runs 15 tool operations in two minutes, it easily breaches the 20 RPM ceiling on free models. Even on paid endpoints, high-frequency tool invocations trigger upstream provider rate limits when requests hit the same inference cluster in rapid succession.

### Context Bloat and Token Multiplication

The more dangerous driver of rate limit failures is context bloat. Developers building agents often dump raw reference files, entire codebase directories, system manuals, or database schemas directly into system prompts.

Consider an agent tasked with auditing three 50-page PDF documents or a set of technical specifications. If the agent prepends the entire document corpus to every single execution step:

- Step 1 sends 80,000 prompt tokens.
- Step 2 sends the tool response plus the original 80,000 prompt tokens.
- By Step 10, the agent has transmitted nearly a million cumulative tokens for a single task.

This rapid token consumption creates three cascading problems:

1. **Tokens-Per-Minute (TPM) Exhaustion:** Upstream providers enforce tokens-per-minute limits alongside requests-per-minute limits. Massive prompt payloads exhaust TPM allocations in two or three turns.
2. **Rapid Credit Depletion:** Processing hundreds of thousands of redundant input tokens burns prepaid credits at an accelerated pace, triggering HTTP 402 Payment Required errors mid-task.
3. **Context Window Saturation:** Feeding entire document libraries degrades model reasoning and tool-calling precision. Real-world platforms frequently hit capacity barriers, as project knowledge is limited by the context window (30MB per file in Claude Projects), driving developers to search for cleaner external file handling patterns.

Creating extra API keys does not solve this problem. OpenRouter governs capacity globally across accounts. The sustainable solution is changing how agents access reference files.

## Using Persistent Workspace Storage Instead of Raw File Attachments

Instead of cramming large document collections into every prompt payload, production agent architectures decouple storage from model inference. The agent retains only its immediate instructions in active prompt memory and retrieves relevant reference material on demand.

### Centralizing Documents in Persistent Workspaces

A persistent workspace acts as external long-term memory for your agentic team. Rather than uploading files directly to OpenRouter API calls or local agent directories, you store reference documents in a centralized workspace.

[Fast.io workspaces](/product/workspaces/) provide persistent environments built for collaboration between humans and AI agents. Within a workspace, documents can be organized into structured folder hierarchies, shared across multiple agent workflows, and maintained under complete version control.

Fast.io supports direct file uploads as well as cloud synchronization from Dropbox, Box, and OneDrive. Google Drive imports today, with sync coming soon. This allows engineering and operations teams to centralize documentation from existing enterprise drives into an agent-accessible workspace without manual copying.

### Intelligent Indexing and Semantic Retrieval

Once files land in a Fast.io workspace, enabling Intelligence Mode activates automatic background indexing. The platform indexes the contents for hybrid search, combining full-text keyword matching and semantic meaning.

This architectural shift changes how your agent interacts with data:

- **Without Workspace Storage:** The agent attaches dozens of megabytes of raw manuals, contracts, and code files to every OpenRouter call, burning tokens and hitting upstream 429 limits.
- **With Workspace Storage:** The agent queries the workspace search endpoint, retrieves the specific three paragraphs needed for the immediate tool step, and passes only those relevant excerpts to OpenRouter.

Prompt payloads shrink from 100,000 tokens down to 2,000 tokens. By reducing token volume by an order of magnitude, the agent operates well below provider TPM limits and preserves prepaid credits.

### Connecting Agents via Model Context Protocol (MCP)

Agents connect to Fast.io workspaces using standard Model Context Protocol (MCP) configuration. Fast.io hosts a remote MCP server accessible over Streamable HTTP at `https://mcp.fast.io/mcp` (or `https://mcp.fast.io/mcp/key` when using Bearer authentication), alongside legacy SSE transport at `https://mcp.fast.io/sse`. You can review the complete setup instructions in the [Fast.io agent storage guide](/storage-for-agents/).

Here is an example MCP configuration for an agent client:

```json
{
  "mcpServers": {
    "fastio": {
      "url": "https://mcp.fast.io/mcp/key",
      "headers": {
        "Authorization": "Bearer FASTIO_API_KEY"
      }
    }
  }
}
```

Through this consolidated MCP toolset, agents search indexed workspace files, read specific documents, write generated deliverables, and organize folder structures. When an agent finishes drafting a report or processing a data pipeline, it saves the output file directly back to the workspace.

### Team Visibility and Ownership Transfer

When an agent generates files inside a Fast.io workspace, every modification is tracked. Fast.io maintains complete per-file version history, enabling humans to review edits, compare changes, and roll back revisions. An append-only audit log records every action taken by both human users and connected agents.

When agents build out workspace assets for human clients or internal managers, Fast.io supports ownership transfer. An agent can set up the workspace, populate indexed documentation, generate output files, and transfer organizational ownership to a human colleague while maintaining scoped administrative access.

### Practical Limits and Boundaries

Fast.io does not modify, override, or raise OpenRouter's internal rate limits. An OpenRouter free tier request is still subject to OpenRouter's 20 RPM policy and upstream provider availability.

The workspace integration eliminates the structural causes of rate-limit failures: prompt bloat, repetitive context transmission, and runaway credit consumption. By querying indexed workspace documents through MCP, your agents complete complex workloads reliably while staying within OpenRouter's operational parameters.

Every organization starts with a 14-day free trial, which requires a credit card. Plans are Starter at `$29/mo`, Business at `$99/mo`, and Growth at `$299/mo` on [Fast.io pricing](/pricing/).

## Frequently asked questions

### What are the rate limits on OpenRouter?

OpenRouter rate limits depend on whether you use free or paid models. Free model endpoints ending in :free are restricted to 20 requests per minute, with daily request caps of 50 requests per day for unfunded accounts and 1,000 requests per day for accounts that have purchased at least $10 in lifetime credits. Paid models have no gateway-level request caps from OpenRouter, scaling based on your account credit balance and upstream provider capacity.

### Why am I getting a 429 error on OpenRouter when I have credits?

An HTTP 429 Too Many Requests error often originates from the upstream inference provider rather than your OpenRouter credit allowance. When a downstream provider like Google AI Studio, Fireworks, or Together experiences queue congestion, it rejects the request. Inspect the error.metadata.provider_code field in the response JSON to verify whether an upstream provider triggered the throttle.

### How can I increase my rate limits on OpenRouter?

On free models, purchasing at least $10 in lifetime credits raises your daily cap from 50 to 1,000 requests per day, though the 20 requests per minute limit remains unchanged. To eliminate platform-level request caps entirely, switch to paid model variants. You can also configure model fallbacks in your API payload or add your own provider keys via Bring Your Own Key (BYOK) to route requests through direct provider quotas.

### What is the difference between an OpenRouter 402 error and a 429 error?

An HTTP 402 Payment Required error indicates that your account credit balance is zero or negative, or that an individual API key has exhausted its spending cap. An HTTP 429 Too Many Requests error indicates that request frequency or concurrency limits were exceeded, either by OpenRouter platform policies or upstream provider queues. Check GET https://openrouter.ai/api/v1/key to verify your remaining credit balance.

### How do mid-stream rate limits work on OpenRouter streaming requests?

When streaming responses with Server-Sent Events, OpenRouter sends an initial HTTP 200 OK header before token generation begins. If an upstream provider rate limit occurs mid-stream, the connection cannot change the HTTP status code to 429. Instead, OpenRouter delivers an SSE chunk with finish_reason: error containing a rate limit error object. Streaming parsers must inspect chunk contents to detect these mid-generation failures.

### How does storing agent reference files in Fast.io help prevent OpenRouter rate limits?

Autonomous agents that repeatedly send large document collections in every prompt turn consume massive token volumes and rapidly trigger provider rate limits and credit exhaustion. By placing reference documents in a Fast.io workspace with Intelligence Mode enabled, files are automatically indexed for search. Agents connect through the remote Fast.io MCP server (documented at [/storage-for-agents/](/storage-for-agents/)) and retrieve only relevant excerpts, keeping prompt payloads small and avoiding 429 errors.

## Sources

- [OpenRouter Free Tier Limits 2026: 19 Free Models, Tested](https://klymentiev.com/blog/openrouter-free-tier) — Free model endpoints on OpenRouter are capped at 20 requests per minute and 50 requests per day for users who have purchased under $10 of credits, expanding to 1,000 requests per day once $10 or more in credits have been purchased.
- [OpenRouter Free Tier Limits 2026: 19 Free Models, Tested](https://klymentiev.com/blog/openrouter-free-tier) — In live benchmark testing across 19 free models on OpenRouter, 13 answered successfully, 4 were refused with a 429 by their upstream provider, and 2 only work inside agent tools.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server at https://mcp.fast.io/mcp, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli.