Build with NeverMetered

Or call the API directly

Point any OpenAI or Anthropic client at the gateway. Your prompts, tools and streaming code stay the same.

1. 1Create an API key — it's shown once, so store it in your secret manager.
2. 2Export it as NEVERMETERED_API_KEY, replacing YOUR_API_KEY with your key. The examples below read it from there.
3. 3Set the base URL to https://api.nevermetered.com/v1 (Anthropic SDKs: https://api.nevermetered.com).
4. 4Send a request. Pick a model id from GET /v1/models.

export NEVERMETERED_API_KEY="YOUR_API_KEY"

curl https://api.nevermetered.com/v1/chat/completions \
  -H "Authorization: Bearer $NEVERMETERED_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-27b",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

• Within your limit, a request is scheduled onto an engine slot as soon as one is available.
• Over your parallel limit, up to max queued extra requests wait for one of your streams to finish. Beyond that you get 429 concurrency_limit_exceeded immediately.
• When the whole pool is busy, requests queue fairly: users with less recent usage go first, recent usage decays over time, and waiting raises a request's priority over time.
• If a request waits longer than the queue timeout it fails with 503/504 request_queue_timeout. Nothing was generated, so it is safe to retry.
• Every generation response carries x-queue-ms: how many milliseconds it waited for a free slot before it started. The one exception is a streamed response that had to wait more than about 10 seconds: it is answered with keep-alive events while it waits (so your client doesn't time out), which means its headers are sent before the wait is known, and it carries no x-queue-ms. The status page shows the typical wait over the last hour.
• max_tokens is capped (and defaulted) by your plan's max output tokens, and a single stream may have a maximum duration.
• Your plan's context window covers input plus output. When a request is close to it, max_tokens is lowered so the answer fits; when the conversation itself is too long, the request fails with 400 context_length_exceeded before anything runs. The check uses an estimate of the prompt, so requests right at the boundary may pass or fail by a few percent.

• Verify your email first. Until you do, free requests return 403 email_verification_required.
• Resets at 00:00 UTC. Requests that fail before generating anything (for example a queue timeout) aren't counted.
• One allowance per person. Free requests are shared between accounts used from the same browser or device, and between accounts calling from the same network. Most people never notice; if you're on a shared office or campus connection and run out early, a paid plan removes the limit.
• Model listing and token counting (/v1/models, count_tokens) don't use the allowance.

Every successful free request carries these headers. When the allowance is used up you get a 429 with the time it resets:

HTTP/1.1 200 OK
x-ratelimit-limit-requests: 20
x-ratelimit-remaining-requests: 13
x-ratelimit-reset-requests: 18720s

HTTP/1.1 429 Too Many Requests
x-ratelimit-reset-requests: 18720s
x-ratelimit-remaining-requests: 0

{
  "error": {
    "message": "You've used all 20 free requests for today. The allowance resets at 2026-09-15T00:00:00Z. …",
    "type": "rate_limit_error",
    "param": null,
    "code": "daily_quota_exceeded"
  }
}

• Keep the system prompt and tool definitions byte-for-byte stable between turns — no timestamps or random ids at the top.
• Append new messages to the end of the history instead of rewriting or reordering earlier ones.
• With the Responses API, chain turns with previous_response_id, or send a stable prompt_cache_key per conversation.
• A conversation that sits idle for a while loses its engine; the next request simply runs cold once.

Uncached input is input minus cached input. Streams you cancel before the engine reports usage are estimated and marked est. in the request log. Usage is informational — tokens are never billed.