The cost model
The pricing of an LLM router is usually the least interesting part of adopting one, and that is the point — the router’s cost model should be boring and predictable. OrcaRouter is one platform built around this pattern.
What you pay for
The router itself is the layer; the models underneath are billed at the vendor’s list price, passed through with no markup. That is the honest cost model: you pay for the routing layer and the models cost what they cost, no middleman margin. The alternative — a reseller adding a per-token surcharge — makes routing to a cheap model save less than it should.
How the bill behaves
The bill reflects the work, not the most expensive model. Cheap-first routing keeps tolerant traffic on economical models, so the monthly number tracks your task mix rather than your most capable model’s rate. Failover removes retry waste. Per-team budgets keep the total predictable. The bill is smaller, and it is predictable, which is what matters for planning.
What to watch
The router’s pricing should be transparent: no surprise fees per model, no hidden markup, clear per-call records so you can verify the bill against the logs. Ask how the router prices before you commit — the models are cheap, the layer should be too, and the combination should be boring.
The transparency check
The router’s pricing deserves the same scrutiny as its features. Ask for a bill that reconciles against the per-call records: every model, every token, every dollar, itemised. A router that cannot produce that is hiding something, and a router that can makes the pricing a non-issue. The models themselves are commodity-priced; the layer should be transparent on top of them. When you can verify the bill against the logs, cost is a number you own rather than a surprise you receive.
What the bill should look like
The bill from a transparent router has a shape you can verify: a line for the routing layer, then the models at their list prices, itemised per call. The verification is the point — you should be able to take the router’s log for any day and reconcile it against the bill, model by model, token by token. A bill that cannot be reconciled is the sign of a hidden markup or a fee structure you did not read. Ask the vendor directly: is there any markup on the model tokens, and can I reconcile the bill against the per-call record? The first question tests the pricing; the second tests the honesty. The models are cheap and getting cheaper; the layer should be transparent on top of them. When the bill reconciles against the logs, cost is a number you own.
The comparison that saves the most
The pricing conversation about a router has an underappreciated side: the router itself is a tool for comparing prices. The per-call record shows what each model actually costs per finished task on your workload, which is a better number than any rate card. Two models at the same token price can differ severalfold on cost per completed task, because reasoning models bill thinking as output and retries multiply. The router’s record surfaces that difference, so the pricing decision becomes data rather than speculation. A model that looks cheap on the rate card and expensive on your tasks gets demoted; a model that is mid-priced and efficient on your work earns a wider share. The router makes the model pricing a measured decision, which is worth more than any single discount.
The check that catches the trap
The one check that catches most pricing traps is reconciliation: take the router’s log for any day and verify it against the bill, model by model, token by token. A bill that reconciles is transparent. A bill that does not is hiding a markup or a fee you did not read. Ask for that reconciliation before you commit, and the pricing question stops being a trust exercise. The models are cheap; the layer should be transparent on top of them.
The final test
The final test of a router’s pricing is whether you would trust it with a large bill. Transparency is the test: a bill that reconciles against the logs is one you can audit, defend and plan against. A bill that does not is a risk you carry. Ask for the reconciliation before you commit, and you will know which one you are buying. The models are cheap; the layer should be boringly transparent on top of them.
The takeaway
The cost model of an LLM router should be boring: pay for the layer, models at list price with no markup, and a bill that reflects the work rather than the most expensive option. Cheap-first routing, failover without retry waste and per-team budgets make the total smaller and predictable. Transparency is the thing to check — the models are cheap, and the layer should be too.
Sourcing note: this article describes the LLM-router category and OrcaRouter’s implementation. Routing, failover, cost and latency claims are OrcaRouter’s own published descriptions, checked August 2026.
