Onlist vs OpenRouter
A direct, non-marketing comparison: pricing model, provider routing, reviews, payment methods, migration cost.
Bottom line
OpenRouter for the largest catalog of curated frontier models. Onlist for an open marketplace with per-provider reviews and crypto-native billing.
At a glance
| Onlist | OpenRouter | |
|---|---|---|
| Endpoint | https://onlist.io/v1 | https://openrouter.ai/api/v1 |
| SDK compat | OpenAI · Anthropic · Gemini | OpenAI · Anthropic |
| Billing | Prepaid wallet, per call | Prepaid wallet, per call |
| Crypto top-up | Stablecoin (USDT) via NowPayments | Crypto credit purchases |
| Provider model | Open marketplace of independent operators | Curated catalog managed by OpenRouter |
| Reviews | Real-usage ratings per provider per model | Aggregate uptime/perf telemetry, no reviews |
| Provider self-listing | Yes, with verification | No |
| Failover | Layered trust signals + cooling state | Internal availability ranking |
| Migration cost | Two-line code change | (existing user) |
Where each one wins
OpenRouter wins
- Catalog size and stability. OpenRouter contracts upstream relationships directly. The model list grows with frontier launches, with consistent pricing per model across providers.
- Track record. Trillions of tokens served, long operational history, established enterprise customers.
- Single-throat-to-choke. When something goes wrong, there is one party responsible: OpenRouter.
Onlist wins
- Per-call transparency. Each model listing on Onlist names the specific provider behind it. Buyers can pin requests to providers they trust.
- Real-usage reviews. Provider ratings are anchored to settled calls. No way to leave a rating without paying for usage first.
- Marketplace economics. Independent providers compete on price openly. Listings can include the same model from multiple providers at different prices.
- Stablecoin-first crypto. USDT top-ups work for buyers in regions where card payment to a US-based service is impractical.
- Self-listing. If you operate an AI API and want to sell access, you can apply, get verified, and start listing without contracting through a single gatekeeper.
Migration
Two lines:
- base_url: https://openrouter.ai/api/v1
- api_key: sk-or-...
+ base_url: https://onlist.io/v1
+ api_key: sk-...
Model IDs follow the same <vendor>/<model> convention. Provider pinning syntax differs slightly; see the migration guide for header and error envelope details.
When to stay on OpenRouter
If you primarily call frontier OpenAI / Anthropic / Google models, do not need per-provider routing transparency, and your billing setup already works on OR, staying put is a reasonable call. Onlist's advantages mostly become real when you care about provider identity, reviews, or alternative payment methods.
When to switch to Onlist
- You want to see and reason about which specific provider is serving each call
- You need stablecoin payment
- You want to read reviews left by other paying buyers, not just vendor marketing
- You yourself want to list an AI service