OpenRouter Pricing: How the Invoice Is Assembled

An OpenRouter bill starts with two separate economic events. Credits are purchased under a platform fee, then requests consume those credits at the price attached to the selected model and provider. The live OpenRouter pricing page lists a 5.5% Standard platform fee and an 8% Business platform fee as of 12 October 2026. It also says provider inference prices pass through without an inference markup.

That structure is straightforward until one application can choose among multiple models, providers, and routes. Then the invoice total answers "what was charged," while the request history has to answer "which policy and route produced the charge." I want to separate those questions cleanly.

TL;DR

• OpenRouter lists a 5.5% Standard platform fee and an 8% Business platform fee.
• Provider inference prices pass through without an inference markup.
• Requests consume purchased credits according to the selected model and provider price.
• BYOK is free up to OpenRouter's stated monthly allowance, then carries a 5% fee.
• Cost governance needs a request record beside the invoice total.

Credit purchase and platform fee

Buying credits adds a platform fee. OpenRouter's current pricing page publishes 5.5% for Standard and 8% for Business. Those percentages should be kept separate from the inference charge attached to a model and provider.

For finance and platform teams, this creates a basic reconciliation rule: record the amount of credits purchased, the applicable platform plan, the fee applied to that purchase, and the date of the transaction, then treat inference consumption as a second ledger. Combining the two into one "LLM cost" field makes it harder to explain why a month changed, especially after a plan change or a shift in model usage.

My mildly unpopular view is that a blended cost-per-token dashboard causes more arguments than it resolves. It hides the commercial mechanics under an average. A controller reviewing the October statement needs the platform charge and request consumption separated, even if the engineering dashboard prefers one tidy number.

Model and provider inference charge

The second component is request consumption. The OpenRouter FAQ says requests use purchased credits according to the selected model and provider price. OpenRouter's pricing page states that provider inference prices pass through without an inference markup, so the selected route determines the realized charge.

The operational record should identify the model and provider selected for a request, plus the time and application that initiated it. Without those fields, a team can reconcile the credit balance but struggle to attribute spend to a service, environment, or business owner. A monthly total lacks the resolution needed for policy review.

Model routing cost optimization is an engineering discipline as well as a procurement calculation. The commercial schedule supplies the unit economics, while the routing layer supplies the actual sequence of selections. Preserve both records because a price page can change over time and an application's routing decision can change between adjacent requests.

Routing and fallback change realized cost

When an application or routing configuration changes the model or provider choice, the selected model and provider price becomes the relevant charge for the request. Any cost review therefore needs to reconstruct the route actually used, rather than the route an architecture diagram says should have been used.

Picture a platform engineer with an invoice on the left monitor and a request trace on the right. The useful join keys are time, calling service, selected model, provider, and request outcome. Without a join between the two screens, finance sees consumption and engineering sees behavior, while the line item remains unexplained to the application owner.

Retries and fallback policies deserve the same treatment. Teams should preserve which requests were sent and which selections occurred before attempting an average. The LLM multi-model routing decision is also a cost-allocation decision each time it changes the destination.

BYOK allowance and overage

Bring Your Own Key, or BYOK, changes which provider credential is used. OpenRouter's current FAQ says BYOK usage is free up to its stated monthly allowance, after which a 5% fee applies. The allowance and the overage rule belong in the commercial record for any deployment that mixes purchased credits with customer-supplied provider keys.

A defensible monthly review separates BYOK requests from requests funded through purchased OpenRouter credits. It should also record when the allowance boundary was crossed and which requests fell after it. The 5% figure comes from the current FAQ, so a future pricing review should re-check the live page rather than preserve the percentage in a spreadsheet indefinitely.

BYOK also creates an ownership question at the request boundary. The credential alone identifies access to a provider. Cost allocation usually needs the authenticated user or service acting through it, the approved model destination, and the policy applied to the request. That context belongs in an independent decision record, particularly when several internal teams share one route.

Pricing evidence and policy evidence

OpenRouter's invoice and usage records serve a commercial purpose. An identity-aware policy record serves a separate governance purpose. For one routed HTTP request, the latter can record the supplied identity, role, data classification, approved destination, policy version, decision, and timestamp. Joining those records lets a team connect consumption to an authorized action.

An AI gateway and LLM router evaluation should separate these functions. Routing decides where a request goes. Identity-aware enforcement decides whether this caller may send this classified content to that destination under the active policy. A deployment may need both functions on the same HTTP path.

DeepInspect leaves OpenRouter's 5.5%, 8%, and 5% published fees unchanged, and provider price schedules remain outside its control. Its role is recording and enforcing the organization's policy before deliberately routed traffic reaches the OpenRouter endpoint. That record explains the organization's decision, while OpenRouter's pages and billing data explain the commercial charge.

DeepInspect

DeepInspect sits between authenticated users or agents and deliberately routed HTTP-based LLM endpoints, including an OpenRouter endpoint. It evaluates identity-aware policy before the request proceeds and produces a per-decision audit record containing the supplied context, policy version, action, and timestamp.

That record can help a platform team explain who was authorized to use a route and which destination policy applied. OpenRouter remains the authority for its platform fees, credits, BYOK allowance, provider selections, and inference charges.

Book a technical deep dive at deepinspect.ai.