Rate limits

Three different things are called "limits" here. Conflating them makes 402 and 429 impossible to tell apart.

Balance limit

Every inference request checks the balance before doing anything else. If the balance is below the debt floor, the request is rejected. The floor is a service policy value, 5,000 KRW by default, so requests stop once the balance reaches −5,000 won.

The buffer exists because we cannot know what a request will cost until it has run. Cutting off exactly at zero would mean one long answer always leaves a negative balance and every following request fails.

{
  "error": {
    "code": 402,
    "message": "크레딧이 부족합니다.",
    "metadata": { "error_type": "insufficient_credits", "balance_krw": "-5200.000000" }
  }
}

When the balance falls to zero or below, the account's keys are suspended automatically and released automatically when you top up. See Credits and payment.

Check the current state with GET /credits.

curl https://openrouter.myip.co.kr/api/v1/credits \
  -H "Authorization: Bearer $MYIP_API_KEY"

{ "data": { "total_credits": 50000, "total_usage": 12750.482 } }

total_credits is everything ever added by top-ups and bonuses; total_usage is everything deducted or expired. Both are in won (₩), and the balance is the difference.

Key limits

Each key can carry a spend limit, expressed as limit (won) and limit_reset (never, daily, weekly, monthly). Period boundaries are computed in Asia/Seoul.

The check runs before the request goes upstream. If usage in the current period is at or above the limit, you get 402 immediately.

{
  "error": {
    "code": 402,
    "message": "키 사용 한도를 초과했습니다.",
    "metadata": {
      "error_type": "key_limit_exceeded",
      "limit_krw": "50000.000000",
      "usage_krw": "50000.000000"
    }
  }
}

Remaining headroom is on GET /key.

{
  "data": {
    "limit": 50000,
    "usage": 12750.482,
    "limit_remaining": 37249.518,
    "limit_reset": "monthly",
    "usage_daily": 820.4,
    "usage_weekly": 4102.9,
    "usage_monthly": 12750.482
  }
}

A null limit means the key has no cap of its own and only the account balance applies. Change a limit with a management key via PATCH /keys/{hash}.

Request rate limit

Across all of /api/v1/, we allow 30 requests per second per client IP, with a momentary burst of up to 60. Beyond that you get 429.

{
  "error": {
    "code": 429,
    "message": "요청이 너무 잦습니다. 잠시 후 다시 시도하세요.",
    "metadata": { "error_type": "rate_limit_exceeded" }
  }
}

The rate_limit field on the GET /key response ({"requests":1000,"interval":"1h"}) is a fixed value kept for openrouter shape compatibility and is not an enforced limit — the response says so itself in its note. The real limit is the 30 requests per second above.

Concurrency

There is no per-account or per-key concurrency cap. Local GPU slots do have finite capacity, though, so piling concurrent requests onto the same local model builds a queue and raises latency. It gets slower; it does not error.

If you need throughput, offer several candidates via models[] or use provider.sort: "throughput" (see Provider routing).

Time and size limits

If a prompt exceeds a local model's context, that candidate is dropped from the chain before we send anything — spending a cold start only to fail is worse. If another candidate can take it, we go there; if not, the result is 404 no_endpoints_found.

Our local GPU models:

For live values read context_length and top_provider.max_completion_tokens from GET /models.

What to do when you hit a limit

Related: Usage limits and 402, How costs are calculated.