Skip to content
Compare· Verified 2026-09-10

Lobstack vs OpenRouter

A single API in front of hundreds of models, sold on breadth and on taking no cut of inference.

The short version

OpenRouter will tell you which models it considered and which one it picked. It will not tell you what the others would have cost.


Five questions, asked of everyone
01

Does it pick a model for you?

OpenRouter

The Auto Router classifies a prompt into roughly thirty task types, then ranks models by what the OpenRouter community spent on them over a trailing seven days. That is a popularity prior, not a cost objective — and the docs say so plainly. A tier setting picks a band; inside the band, ranking is still by spend share.

“powered by the market: the aggregate spend of millions of people”

The separate Pareto Router does minimise cost — “the cheapest model that is currently available” within a tier — but it is scoped to coding.

openrouter.ai/docs/guides/routing/routers/auto-router

LobstackYes — complexity tiers with a spend ceiling

02

Does it tell the caller why?

OpenRouter

Yes, and this changed in 2026. Send `X-OpenRouter-Metadata: enabled` and the response carries an `openrouter_metadata` object: the routing strategy, a one-line human-readable summary, the candidate endpoints considered with a flag on the one selected, and the Auto Router's classified task type. It is off by default, absent on cache hits, and stripped on 500s.

“Human-readable one-liner describing the routing decision”

What you get is a strategy label, a sentence and a candidate list — not a numeric score, a quality tier, or a complexity number. There is none in the schema.

openrouter.ai/docs/guides/features/router-metadata

LobstackYes — on every response, no opt-in

03

Is the cost in the response?

OpenRouter

Yes, always, with no opt-in. Every completion returns `usage.cost`, alongside cached and reasoning token breakdowns. The parameters that used to gate this are deprecated and now have no effect.

“cost: The total amount charged to your account”
openrouter.ai/docs/use-cases/usage-accounting

LobstackYes — response headers

04

Does it price the model it did not choose?

OpenRouter

No. The candidate list in `openrouter_metadata` names the provider and model of each endpoint considered and marks the selected one — and carries no prices. The words price, cost and savings do not appear in any field description on that page, and a search of the complete published docs corpus returns nothing for a counterfactual of any kind.

There is one near-miss: budget docs describe what OpenRouter “would have charged had the request not used your own provider key”. That is BYOK against list price for the same model and the same provider — not a comparison with a model it did not choose.

openrouter.ai/docs/guides/features/router-metadata

LobstackYes — per request, on the response

05

What does it cost?

OpenRouter

5.5% on credit purchases by card ($0.80 minimum), 5% by crypto, and no markup on inference itself. BYOK is free up to $25,000 a month of list-price inference on pay-as-you-go and $200,000 on Enterprise, then 5%.

“$25,000 of list price inference / month with no fees, 5% fee after”

The allowance is metered by list price of inference, not by what you spent. “Free up to $25k of spend” is the wrong reading.

openrouter.ai/pricing

LobstackNo cut of inference. Either a plan that includes dollars of model spend at our published rates, or BYOK — your provider keys, a flat monthly fee.

Where OpenRouter is better than us

The part we had the least incentive to write.

Zero markup on inference is a real position, not a framing

You pay list price for tokens and OpenRouter takes its cut when you top up credits. For anyone whose spend is concentrated and predictable, that is straightforwardly cheaper than a percentage of inference, and it is the honest reason a lot of teams start here.

Candidate transparency nobody else ships

Router metadata returning the endpoints it considered — not just the one it used — is more than any other gateway in this comparison discloses about its own decision. We would rather point at it than pretend it is not there.

Breadth, and the operational work behind it

Provider failover, in-region routing, and Auto Exacto reordering providers on tool-calling requests by measured tool-call success rate. That is a lot of unglamorous reliability engineering.

Where we think there is a gap

Narrow, specific, and only what we checked.

Not capabilities OpenRouter lacks — places a documented behaviour stops short of what a caller needs.

The routing objective is popularity

Ranking by trailing community spend share means the Auto Router follows what is fashionable and well-funded. That is a defensible heuristic and it is not a cost objective, which matters if you adopted a router to spend less.

The rationale is off by default

A per-request opt-in header means the decision is invisible to anyone who has not gone looking for it — including in the logs of a team that adopted the router before the feature existed.

Candidates without prices

You can see it considered five endpoints and chose one. You cannot see what the other four would have charged, so you cannot check the choice.

What changed in 2026

If you have read an older comparison of OpenRouter, these are the parts of it that are now wrong.

An opt-in routing rationale in the response. This is the change that makes most 2025-era comparisons of OpenRouter wrong, including one we wrote.

A genuinely cost-minimising router — cheapest available model in a chosen tier, gated on a coding percentile. Coding-scoped, so a general-purpose cost objective is still absent, but “OpenRouter has no cost-aware router” is now false.

`usage: {include: true}` and `stream_options: {include_usage: true}` are deprecated and inert; full usage comes back on every response.

And us

Lobstack returns the counterfactual on the request that caused it. The response carries what it cost, what tier answered, the complexity score behind that, whether it was routed — and what the baseline model would have charged for the same tokens.

Two limits, better read here than found after you integrate. On stream: true those figures move to the final frame, because our headers go out before the provider has counted a token. And a like-for-like saving needs a model you named — ask for auto and the baseline is the most expensive model your plan allows, the most flattering one available to us, so baseline_reason reads plan_ceiling and travels with every figure. The metering docs.

Every figure here was checked against OpenRouter’s own pages on 2026-09-10 and linked so you can check it too. Where we could not verify something either way, it says so rather than guessing.