See where your OpenRouter spend actually goes

How does OpenRouter bill for usage?

OpenRouter runs on a prepaid balance. You add credit to your account, and every call deducts 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: a small percentage fee when you buy credits, and a bring-your-own-key fee if you route high volumes through your own provider keys rather than OpenRouter’s. The credit-purchase fee in particular is charged at top-up and sits outside the per-model usage feed, so it’s a line that doesn’t show 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	A small percentage fee when you top up — outside per-model usage
Bring-your-own-key routing	A percentage fee above a free monthly threshold

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.
• 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 Gemini, or reach for DeepSeek, 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.

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 Provisioning key and reads two things: your activity feed, itemized one day at a time by the endpoint each call was routed to, with input and output tokens for each, and your prepaid balance. Because one model can be served by several providers, CostCompass rolls those endpoint rows up per model. Each row already carries the cost OpenRouter worked out from the tokens its upstream providers processed, so CostCompass records that figure as reported and doesn’t recompute it. The per-model number you see is the sum of what OpenRouter charged against your balance.

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
Provisioning key	Reads account activity, usage, and credit balance	Yes

You make a Provisioning key in the OpenRouter dashboard under Provisioning keys. 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 about the last month of completed days. OpenRouter’s activity feed reaches back roughly thirty days and leaves out the day still in progress, so your history starts a month back rather than at your account’s first call, and each refresh pulls in any newly completed days. 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 Provisioning 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 Gemini 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:

1. In OpenRouter, create a Provisioning key, the kind that can read your account activity rather than the inference key you make calls with.
2. Paste it into CostCompass. It’s encrypted in your browser before it’s stored, so the server only ever holds ciphertext.
3. 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.