OpenRouter Credits & Fees: How Billing Works (2026)
If you have ever topped up a balance on OpenRouter, watched your credit count tick down, and then wondered exactly what you just paid for, you are not alone. OpenRouter credits work differently from a direct provider account, and the billing model has several distinct fee components — not just one. This guide explains how OpenRouter billing works end to end: what credits are, how they are drawn down, where fees appear when you top up, and how the BYOK (bring-your-own-key) path compares. Because exact fee percentages change over time, this article covers the structure — for current figures, always check OpenRouter's pricing page directly.
What Are OpenRouter Credits?
OpenRouter is a hosted LLM aggregator. Rather than giving each customer direct access to provider accounts, it maintains its own relationships with upstream providers — OpenAI, Anthropic, Google, Meta, Mistral, and others — and resells inference through a single unified API. The currency that funds this is credits.
Credits are a prepaid balance. You deposit money via card (or other supported payment method), and the platform converts that deposit into a credit balance. Every API request you make draws down that balance at a per-token rate set by OpenRouter. When the balance hits zero, requests start failing.
This is conceptually similar to a prepaid phone plan: you load value upfront, and usage eats into it. The per-token rates you see in OpenRouter's model list represent what you spend from that credit balance per million tokens — input tokens (your prompt) and output tokens (the model's reply) are priced separately, with output typically costing several times more.
Fee Components: Where OpenRouter Payment Fees Appear
The phrase "OpenRouter fees" is often used loosely, but there are really several distinct places in the billing chain where cost can be added. Understanding each helps you figure out where your money actually goes.
1. The payment-processing or top-up fee
When you top up OpenRouter credits, the amount of credit you receive may not equal the amount you paid. Card networks charge interchange fees; platforms charge a processing or convenience component on top. The result is a spread between the cash you deposited and the credit units you receive — meaning effective per-token costs are slightly above the raw per-token rate listed for each model.
The size of this component, and whether it applies uniformly or only above or below certain deposit amounts, is a current-pricing detail. OpenRouter's pricing page is the authoritative source.
2. The underlying model's per-token rate
This is the bulk of most bills. Each model on OpenRouter carries an input price and an output price, expressed per million tokens. These rates are set to approximate — or slightly exceed — what the upstream provider charges. For models available from multiple upstream hosts (for example, an open-weight model served by several inference providers), the rate can vary depending on which backend serves your request.
3. The BYOK surcharge (if applicable)
OpenRouter also offers a bring-your-own-key mode where you attach your own provider API keys. Requests are then routed through your keys, so the underlying tokens are billed to your provider account rather than drawn from OpenRouter credits. This removes one source of cost — you pay provider list price directly — but OpenRouter's BYOK option may carry its own per-request or percentage surcharge for the routing and convenience layer. Whether this applies, and what it costs, is again something to verify on the pricing page before assuming BYOK-through-OpenRouter equals provider list price with no additions.
How OpenRouter Billing Actually Works: A Walkthrough
Here is a simplified flow for a standard credits-based request:
- You deposit cash. After any processing fee, a credit balance appears in your account.
- Your application sends a request to OpenRouter's API, specifying a model (e.g.,
anthropic/claude-3-5-sonnet). - OpenRouter routes the request to an upstream provider using its own account with that provider.
- The provider returns a response and bills OpenRouter's account for the tokens consumed.
- OpenRouter debits your credit balance based on its published per-token rate for that model.
- Your usage dashboard shows the credit drawdown, though mapping it back to an exact provider invoice line is abstracted away.
The key insight: you never have a direct billing relationship with the upstream provider on the credits path. OpenRouter holds that relationship. This is both the convenience and the trade-off.
Billing Concepts at a Glance
| Concept | What it is | Where fees appear |
|---|---|---|
| Credits | Prepaid platform balance used to fund API calls | Loaded by card; possible processing fee on deposit |
| Per-token rate | Credit cost per million input / output tokens, per model | Set by OpenRouter; reflects upstream cost plus any margin |
| Payment / top-up fee | Fee applied when converting cash into credits | Check OpenRouter pricing page for current amount |
| BYOK (credits path) | N/A — credits are OpenRouter's, not yours | Standard credit drawdown applies |
| BYOK (own-key path) | Your provider key is used; provider bills your account | Possible surcharge for routing layer — verify on pricing page |
| Provider list price | What the provider would charge if you called them directly | Baseline for BYOK gateways that charge zero markup |
How to See Where Your Money Goes
OpenRouter's dashboard shows credit usage per request, along with the model used and token counts. This is useful for spotting which models or features are driving spend. However, there are a few limits to the transparency:
- You see credits debited, not upstream invoice lines. The dashboard does not show what OpenRouter paid its provider for that specific call.
- Routing choices are abstracted. When a model is served by multiple upstream providers at different costs, the routing decision and its cost impact are not surfaced to you.
- Processing fees are folded into the credit conversion. If you deposited $100 and received $97 in credits, the $3 difference may not be itemized separately.
For teams that need cost attribution by feature, team, or environment, this abstraction can be a challenge. Exporting usage data and reconciling against your deposit history is the closest you can get to a line-by-line audit on the credits path.
The BYOK Alternative: Paying Providers Directly
The structural alternative to the credits model is to skip the intermediary's billing relationship entirely. With a bring-your-own-key gateway — one that uses your own provider API keys rather than a pooled credit balance — the billing chain looks different:
- You create API keys with each provider (OpenAI, Anthropic, Google, etc.) directly.
- You register those keys with a gateway.
- Requests go through the gateway using your keys; the provider charges your account.
- The gateway earns revenue from its service layer, not from marking up your tokens.
Under this model, there is no credit middleman, no top-up fee, and the per-token cost is exactly what the provider publishes. Your enterprise pricing or negotiated discounts carry through automatically because your keys are being used. Provider invoices serve as a direct audit trail.
The trade-off is setup: you need an account with each provider you want to use, which takes time and may involve eligibility requirements. You also handle key management yourself. For teams already at scale, this overhead is usually worth it; for teams just getting started, the friction of a credits-based aggregator may be preferable. See the full comparison in BYOK vs credits.
Is OpenRouter Fair Value?
Yes, for what it offers. OpenRouter solves a genuine coordination problem: access to a broad model catalog through one API, without setting up accounts across a dozen providers. The credit model and its associated fees are the price of that convenience, and they are not hidden — they are on the pricing page if you look. The question is whether the convenience is worth the cost at your scale and use case.
For side projects, prototyping, and early-stage products where breadth and speed of access matter more than marginal token cost, credits are often the right call. For production workloads where LLM spend is a meaningful budget line, the math frequently tips toward direct provider billing — and the routing, fallback, and observability features that a gateway provides can come without the markup.
For a deeper look at how OpenRouter's pricing model is structured, see OpenRouter pricing explained.
Summary
OpenRouter credits are a prepaid balance that funds API calls at OpenRouter's published per-token rates. Fees can appear at the point of deposit (payment processing), in the per-token rate itself (which covers OpenRouter's costs and margin), and — if you use the BYOK option within OpenRouter — possibly as a surcharge on routed traffic. Because these figures change, always verify on OpenRouter's current pricing page before building cost models around them.
If transparent, zero-markup billing matters to your project, flo2 is a developer-first LLM gateway that routes requests using your own provider keys, charges no token markup, and is free during beta. You pay providers directly — exactly what they publish, nothing more.