See where your OpenRouter spend actually goes
OpenRouter routes one API key across dozens of model vendors and draws it all from a single prepaid balance. That convenience buries the question that matters — which model spent what. Here is how the billing works, and how to turn OpenRouter's own per-model figures into a running total and a forecast beside everything else you run.
OpenRouter's pitch is one endpoint for every model: point a single key at it and your calls fan out to Anthropic, OpenAI, Google, and a long list of open-weight hosts, all paid from one prepaid balance. The catch is in what you give up to get it. When every model draws on the same balance, the number going down tells you the level and nothing about which model is pulling it.
OpenRouter already keeps the figures that answer that, model by model. The work left is pulling them into a running total and a forecast before the balance runs low.
Where do you check your OpenRouter credits?
The balance is on the Credits page in your account settings, the same page where you buy more and switch on auto top-up. What spent those credits is on a separate page: Activity breaks usage down by model, provider and API key, and exports what you’ve filtered to CSV or PDF. Card top-ups go through Stripe, so the receipt for each one arrives as an email from Stripe rather than as an invoice inside OpenRouter.
| Where | What it answers | What it leaves out |
|---|---|---|
| Settings → Credits | Credits left, past purchases, auto top-up | Which model used them; it’s a single figure for the whole account |
| Activity | Spend, requests and tokens by model, provider and key, over any range | How long the remaining credit lasts, and the card fee on each top-up, which never lands on a model |
| GET /api/v1/credits | Total credit bought and total used, for a script | Any per-model split; it answers only a Management key and refuses the rest with a 403 |
How does OpenRouter pricing work?
OpenRouter runs on a prepaid balance. You add credit to your account, and most calls deduct from it as you go. There’s no monthly invoice and no seat to reason about, just a balance that falls. Behind that one balance sits a router that forwards each request to whichever model you asked for, across many providers at once, and bills them all to the same account.
Most calls are metered the way token APIs are: by the input tokens you send and the output tokens the model generates back, with output often the pricier side. The per-token rate then depends on which model the request was routed to, and that can be anything from a cheap open-weight model to a flagship reasoning run. Some models add their own units on top — a per-request charge, an image, a web-search call — but for most text work it’s the input and output tokens that move the bill. A blended bill across a dozen models is the normal case here.
On the inference itself, OpenRouter charges pass-through rates: you pay what the underlying provider charges, with no markup added to the per-token price. Where OpenRouter makes its money is around the edges of that. Buying credits by card carries a 5.5% fee with a minimum charge per purchase, while crypto is a flat 5% with no minimum. On card, that minimum matters more than the percentage if you top up in small amounts, because a floor applied to a small purchase works out as a much larger share of it. Topping up in fewer, larger amounts is the cheaper habit. The second edge is bring-your-own-key routing: on pay-as-you-go, the first $25,000 a month of BYOK usage, counted at list-price inference cost rather than by request, carries no fee, and past that OpenRouter takes 5% of what the same call would have cost on its platform. OpenRouter has said it plans to replace that 5% with a fixed monthly subscription, with the price not yet set.
The credit-purchase fee is the one worth holding on to, because it’s charged at top-up rather than at inference, so it sits outside the per-model usage feed entirely and never shows up in any model’s row. (Exact rates and fees live on OpenRouter’s pricing page and have changed before, so treat any figure you’ve memorized as provisional.)
One mechanism works in your favor, carried straight through from the upstream providers. OpenRouter passes provider prompt-caching pricing through on the models that support it: when a later call reuses a prompt prefix the model has already seen, that portion bills at the cheaper cached rate. Some providers cache automatically; others want you to mark the reused prefix explicitly, so it’s worth checking how the model you route to handles it. Keep your stable prefixes consistent across calls — long system prompts and reference material especially — and a slice of your input cost moves to the cheaper tier.
So a single day of OpenRouter usage can draw on several different prices at once:
| What you’re paying for | How OpenRouter handles it |
|---|---|
| Input / output tokens | The routed model’s own per-token rate, pass-through |
| Cached input | The cheaper cached rate on supported models, passed through |
| Credit purchases | 5.5% by card with a minimum per purchase, 5% by crypto — outside per-model usage |
| Bring-your-own-key routing | No fee up to a monthly allowance at list price, then 5% |
Why is OpenRouter spend hard to keep ahead of?
The routing that makes OpenRouter convenient is also why the spend resists a quick glance. For a solo developer running it next to three or four other providers, the routing layer is usually the part that surprises you most. The difficulty comes down to what one shared balance hides:
- One balance, many models. A falling balance tells you the level, not which model pulled it down or how fast. By the time the number looks low enough to notice, the routing that drained it is already behind you.
- Routing can shift the blend silently. Change which model handles a job, or let a fallback route send traffic to a pricier model when your first choice is busy, and the bill moves while your request volume sits flat.
- One request can now bill as several models. OpenRouter’s subagent tool lets the model you called hand mechanical sub-tasks — summarizing, reformatting — to a cheaper worker model partway through generating. Your request count doesn’t move, but the spend splits across two models at two different rates.
- The fee sits off to the side. Inference is pass-through and itemized by model. The credit-purchase fee isn’t attributed to anything in the usage feed, so it leaves your balance with no row of its own.
- OpenRouter is rarely your only provider. Even though it fronts many models, you likely also call Anthropic for Claude directly, build on OpenAI, run Google, reach for DeepSeek, or route another slice through a fellow gateway like Atlas Cloud, plus whatever you spend on inference hosts and serving, so the OpenRouter balance is one slice of a bill you otherwise stitch together by hand from a stack of dashboards.
That per-model split is what makes delegation legible. When a frontier model hands part of a job to a cheaper worker, both bill at their own rate and both land in the model aggregates separately — so the breakdown shows you the orchestrator and the worker side by side. That’s the only view that answers the question delegation actually raises: whether the work you moved down-market saved more than the orchestrating cost you added. A single balance can’t tell you, because both halves drain the same pool.
How can you reduce your OpenRouter bill?
Tracking shows you where the balance goes. A few levers slow the drain:
- Right-size the route. OpenRouter’s whole point is that you can send the easy, high-volume calls to a cheap model and reserve a flagship for the work that needs it. The per-token spread across models is wide, so that one routing choice usually moves the bill more than anything else you can do.
- Watch the per-model split. A ranked list catches a creeping shift toward a pricier model within days. The balance alone shows it only once you’re nearly dry.
- Keep stable prefixes consistent. On models that support caching, long system prompts and reference documents that don’t change land on OpenRouter’s pass-through cached rate, which costs a fraction of full input.
- Keep outputs tight. Output is usually the pricier side. Trimming verbose responses and capping how much the model generates cuts the part of the bill that grows fastest, across whichever model the request routes to.
How do you forecast next month’s OpenRouter bill?
Forecasting a prepaid balance comes down to a burn rate. Take your spend over the last several days, turn it into a daily average, and project that across a full month.
CostCompass does this. It scales your trailing seven-day burn rate to the number of days in next month and adds any fixed subscriptions you’ve entered, and the result is one forward number for what next month costs if the current pace holds. Seven days is the window. It’s long enough that one heavy day doesn’t throw the average, and short enough to pick up a recent change, like a route that started leaning on a pricier model. OpenRouter reports cost exactly, so that projection rides on real figures rather than estimates. The same engine runs across every provider you’ve connected, so OpenRouter folds into one whole-stack number.
How does CostCompass track your OpenRouter costs?
CostCompass connects to OpenRouter with a Management key and reads two things: your daily model analytics, with request counts, input, cached-input, and output tokens for each model, and your prepaid balance. Each daily model row already carries the total cost OpenRouter worked out from the usage it routed, so CostCompass records that figure as reported and doesn’t recompute it. Cached input is kept as a separate usage signal under the same model without adding a second cost. The per-model number you see stays tied to the aggregate OpenRouter reported.
OpenRouter issues two kinds of key, and only one of them works here:
| Key type | What it does | Works with CostCompass |
|---|---|---|
| Inference key | Authenticates your API calls to route models | No |
| Management key | Reads account activity, usage, and credit balance | Yes |
You make one in the OpenRouter dashboard under Settings → Management API Keys. If you set this up a while ago, that’s the page OpenRouter used to call Provisioning keys — same credential, current name, and the old link still redirects. Paste an inference key by mistake and CostCompass can’t read your activity, so it flags the key as the wrong type.
That gives you the breakdown a single balance can’t: which model spent what, day by day, ranked. When you first connect, CostCompass pulls the completed days in the current month and leaves out the day still in progress. Each refresh queries that completed-day window again, so if OpenRouter revises or drops something it already reported, your history follows it down instead of holding the old figure. The credit-purchase fee is the one piece no usage feed itemizes; it leaves your balance without a model to attribute it to. That fee sits outside the per-model running total, which CostCompass builds from your usage — but CostCompass reads your prepaid balance too, and that balance reflects every drop, the fee included.
Two things make that practical for a solo developer. Your key is encrypted in your browser before anything is stored. The Management key you paste is sealed with your vault password on your own device, and only the sealed version is ever saved, a blob CostCompass can’t open because the vault password stays with you. When it’s time to read your activity, your browser unseals the key and passes it to a relay that uses it for that one call to OpenRouter and is built not to log or keep it. What we hold at rest is locked ciphertext. The key your account runs on never reaches us in usable form.
And OpenRouter doesn’t sit alone. The same dashboard rolls its running total up with every other AI and compute provider you’ve connected, from Claude and OpenAI to Google and your hosting, into one figure with a forecast. How you reach that cross-provider number is its own decision, whether you do it by hand or read straight from each billing API; the ways to track AI costs across providers lay the options out side by side.
Getting started takes three steps:
- In OpenRouter, create a Management key under Settings → Management API Keys — the kind that can read your account activity, rather than the inference key you make calls with.
- Paste it into CostCompass. It’s encrypted in your browser before it’s stored, so the server only ever holds ciphertext.
- Click Refresh. CostCompass reads your per-model activity and balance, and from there your running total, forecast, and by-model breakdown roll up, OpenRouter included in the whole-stack number.
Frequently asked questions
- Is OpenRouter more expensive than calling the providers directly?
- On the inference itself, no. OpenRouter passes the underlying provider's pricing straight through with no markup, so a routed call costs what the same model would cost you direct. What it charges around that is 5.5% when you top up credits by card, with a minimum fee per purchase that hits small top-ups hardest, or a flat 5% by crypto with no minimum. Bring-your-own-key routing adds a fee of 5% once your BYOK usage passes a monthly allowance, which OpenRouter measures at list-price inference cost. CostCompass shows the pass-through per-model cost exactly as OpenRouter reports it; the credit-purchase fee falls outside that per-model feed and leaves only through your balance, which CostCompass reads too — so you see both the model-by-model spend and the balance the fee comes out of.
- Why did a request route to a pricier provider than I expected?
- Because the same model is often served by several providers, and OpenRouter load-balances and fails over between them — if your cheapest provider is rate-limited or having an outage, the request shifts to a costlier one, and the bill moves while your request volume sits flat. You can sort or pin providers by price to rein that in. This is exactly the silent blend-shift a single balance hides, so CostCompass ranks OpenRouter's daily per-model totals and names the providers that actually served each model (Claude via Amazon Bedrock, say), which is how you catch a model that quietly went upmarket.
- Are OpenRouter's free models actually free, and what's the catch?
- Yes — the variants whose slug ends in :free draw nothing from your balance. The catch is throughput and privacy, not money. OpenRouter rate-limits the free tier to around 20 requests a minute and a small daily cap that only lifts once you've bought at least 10 credits, and some free endpoints may log your prompts under the upstream provider's policy. Because free usage costs nothing, it adds nothing to your running total — the moment you route the same job to a paid model, the spend starts showing up in your per-model breakdown.
- Does OpenRouter train on or log my prompts?
- Not by default. OpenRouter doesn't store your prompts or completions unless you opt in to logging, and you can enforce zero-data-retention so requests only reach endpoints that keep nothing. The exception is some free endpoints, which may log under the upstream provider's terms. None of this changes what CostCompass sees, which is usage figures — model, token counts, and cost — and your credit balance, never the contents of a prompt or a response.
- Do my OpenRouter credits expire?
- OpenRouter reserves the right to expire unused credits a year after purchase. That matters less for your tracked spend than you might expect — CostCompass builds your OpenRouter total from the daily model analytics, not from the drop in your balance, so an expiry would lower the balance it displays without inventing spend that never happened. The running total stays tied to the calls you actually made.
- Does CostCompass count bring-your-own-key (BYOK) inference in my OpenRouter total?
- No, by design. BYOK inference is billed straight to the upstream provider against your own key, not to your OpenRouter balance, so it isn't part of the OpenRouter figure at all. What CostCompass shows for OpenRouter is what OpenRouter actually charges you — the routed request plus its bring-your-own-key fee. If you also track that upstream provider in CostCompass, the inference lands there, where it's billed, rather than being double-counted under OpenRouter.
- I use OpenRouter Workspaces — does CostCompass break spend out by workspace?
- No, and OpenRouter doesn't bill that way either. Workspaces separate your projects and teams, but they all draw on one shared credit balance rather than a pool each, so there is a single account-wide bill underneath them. CostCompass's analytics query is account-wide and grouped by model, not by workspace, so the OpenRouter card reports your whole account as one figure broken out by model. If you need per-workspace attribution, OpenRouter's own dashboard is where that lives.
- My model delegated part of a job to a cheaper one — how does that show up?
- As two models, which is what you want. OpenRouter's subagent tool lets the model you called hand a self-contained sub-task to a smaller, cheaper worker model while it's still generating, and each one bills at its own rate. Both appear in the daily model aggregates, so CostCompass's per-model breakdown shows the orchestrator and the worker separately rather than blending them into one number. That's what lets you see whether delegating actually paid for itself.
- Does CostCompass store my OpenRouter key?
- Not in any form we can read. Your Management key is encrypted in your browser with your vault password before it leaves your device, and what CostCompass stores is only the resulting ciphertext — an opaque blob it can't decrypt, since your vault password never leaves your browser. When it's time to read your activity and credit balance, the key is unsealed in your browser and forwarded to OpenRouter through a relay that holds it only for the length of that one call and is built not to log it. So the request does pass the key through our infrastructure, but the plaintext is never written to our database or our logs. What we keep at rest is ciphertext that's useless without your vault password.
- How do I see my total OpenRouter spend, or pull it from the API?
- Two ways. OpenRouter's dashboard has an activity page that shows your per-model usage after the fact, and a Management key (which OpenRouter used to call a Provisioning key) — a different credential from the inference key you make calls with — reads daily model aggregates and your credit balance over the API. That programmatic door is the one CostCompass connects through, turning the dashboard's own totals into a running total and a forecast.
- Why use CostCompass instead of OpenRouter's activity page?
- OpenRouter's activity page shows what you've already spent through OpenRouter, after the fact, for OpenRouter alone. It won't tell you how fast your balance is falling or where your spend is heading, and it says nothing about the rest of your bill. CostCompass turns that same per-model usage into a running total and a forecast, and rolls OpenRouter up with Claude, OpenAI, Google, and your hosting into one view. It updates the moment you click Refresh, rather than a number you go read and a slope you work out yourself.
About the author
Joubert Berger builds CostCompass, a spend-intelligence dashboard that pulls usage from AI and compute providers into one month-to-date total, a forecast, and a per-provider breakdown. This guide reflects how CostCompass reads each provider's own usage API — see the security model for how your keys are handled.
Stop watching one balance fall for a dozen models
Connect OpenRouter once and turn its per-model usage into a running total, a forecast, and a breakdown by routed model, rolled up with every other provider in one click.