Build with NeverMetered
Everything you need to send your first request, stay within your parallel limits and get the most from prefix caching.
Quickstart#
Point any OpenAI or Anthropic client at the gateway. Your prompts, tools and streaming code stay the same.
- 1Create an API key — it's shown once, so store it in your secret manager.
- 2Set the base URL to
https://api.nevermetered.com/v1(Anthropic SDKs:https://api.nevermetered.com). - 3Send a request. Pick a model id from
GET /v1/models.
curl https://api.nevermetered.com/v1/chat/completions \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8-27b",
"messages": [{"role": "user", "content": "Hello!"}]
}'Authentication#
Send your key with either header — both work on every endpoint.
Authorization: Bearer nfk_…
# or
x-api-key: nfk_…Endpoints#
| Method | Path | Notes |
|---|---|---|
| GET | /v1/models | List the models your key can call. |
| POST | /v1/chat/completions | OpenAI Chat Completions — streaming, tools, images. |
| POST | /v1/responses | OpenAI Responses API. previous_response_id follow-ups are routed to the engine holding the state. |
| POST | /v1/messages | Anthropic Messages API, streaming and non-streaming. |
| POST | /v1/messages/count_tokens | Anthropic token counting. Not queued; rate limited per minute by plan. |
Parallel limits & queueing#
Tokens are unlimited. Your plan controls how many generations run at the same time across all your keys.
- 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_exceededimmediately. - 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. max_tokensis capped (and defaulted) by your plan's max output tokens, and a single stream may have a maximum duration.
Free tier#
Every account can send 10 generation requests a day for free, with the same unlimited tokens per request as paid plans. Paid plans have no daily request limit.
- 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.
| Response header | Meaning |
|---|---|
| x-ratelimit-limit-requests | Your free requests per UTC day. |
| x-ratelimit-remaining-requests | How many are left today, after this request. |
| x-ratelimit-reset-requests | Seconds until the allowance resets, e.g. 18720s. |
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: 10
x-ratelimit-remaining-requests: 3
x-ratelimit-reset-requests: 18720s
HTTP/1.1 429 Too Many Requests
retry-after: 18720
x-ratelimit-remaining-requests: 0
{
"error": {
"message": "You've used all 10 free requests for today. The allowance resets at 2026-09-15T00:00:00Z. …",
"type": "rate_limit_error",
"param": null,
"code": "daily_quota_exceeded"
}
}x-ratelimit-remaining-requests and stop scheduling work at 0 instead of retrying — retries before the reset return 429 again. Compare plansGetting the most out of caching#
Requests in the same conversation are routed to the same engine for a while, so a prompt prefix it already processed can be served from cache instead of recomputed. Cache hits show up as cached input tokens and as your cache hit rate on the dashboard, and usually shorten time to first token.
- 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 stableprompt_cache_keyper conversation. - A conversation that sits idle for a while loses its engine; the next request simply runs cold once.
How tokens are counted#
Every request reports three numbers, both in API responses and in your dashboard.
Everything in the prompt: system prompt, tools, history and the new message. Includes cached input.
The part of the input served from the engine's prefix cache instead of being recomputed.
Generated tokens, including any reasoning tokens the model produced before answering.
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.
Errors#
| Status | Code | Meaning | Retry? |
|---|---|---|---|
| 401 | — | Missing, unknown or revoked API key. | No |
| 403 | — | The key is valid but not allowed to use this model, or the account is suspended. | No |
| 403 | email_verification_required | Free requests need a verified email address. Click the link in your verification email, or upgrade. | No |
| 403 | free_tier_unavailable | Free requests are turned off for this account. Upgrade to a paid plan or contact support. | No |
| 429 | concurrency_limit_exceeded | All your parallel streams are busy and your queue allowance is full. | With backoff |
| 429 | daily_quota_exceeded | Today's free requests are used up. Retry after the reset in retry-after (00:00 UTC), or upgrade. | After reset |
| 503 / 504 | request_queue_timeout | The service stayed busy longer than the queue timeout. Nothing was generated. | With backoff |