How Inferbase compares
Inferbase routes each request to the best model and serves it through one OpenAI-compatible API. Here is how that differs from the routers and aggregators you might be weighing.
The LLM routing landscape
Most tools sit in one of a few buckets. Inferbase is the one that both decides and delivers.
OpenRouter
AggregatorOne API to hundreds of models. Routing is an add-on, and its Auto Router is outsourced to NotDiamond.
LiteLLM
OSS gatewayA self-hosted gateway to 100+ providers. It balances hosts for the model you named; its beta auto-router adds complexity tiers, with the tier-to-model mappings still in your config.
Portkey
Hosted gatewayA control panel over your own providers: observability, guardrails, and routing rules that key on metadata you attach, never the prompt itself.
NotDiamond
Routing brainRecommends the best model per prompt, then leaves you to run the inference with your own providers.
RouteLLM
OSS frameworkA free, self-hosted strong-vs-weak router you install, calibrate, and operate yourself.
Inferbase
Routes and servesPicks the best model per request across a curated catalog and runs it, through one OpenAI-compatible API, with a decision you can audit. First-party, end to end.
Why route at all
No single model is the right choice for every request. Routing turns model selection from a standing decision into a per-request one.
The right model is not the same from one request to the next:
- A frontier model is overkill for easy work. Classification, short summaries, and simple Q&A do not need a top-tier model, so paying for one wastes money on the bulk of your traffic.
- A small model falls short on hard work. Complex reasoning and long-context analysis need a stronger model, so a lean default quietly loses quality where it matters most.
- A single default leaves both on the table. Routing picks a model per request instead, so spend and quality each track the difficulty of the work.
This page compares Inferbase against the routers, gateways, and aggregators teams usually weigh, OpenRouter, LiteLLM, Portkey, NotDiamond, and RouteLLM, and the criteria that distinguish them. If you are still weighing the categories themselves, start with our breakdown of gateways versus routers.
How to choose an LLM router
Four questions that separate the categories, and where the real quality and cost gains hide.
Does it pick the model, or just the host?
Optimizing the provider for a model you already chose is not the same as choosing the right model per request, which is where the quality and cost gains are.
Does it run the inference, or just decide?
A router that only recommends leaves you to operate providers, keys, and fallback. Routing plus serving is one system instead of two.
Can you see why it chose?
Without a per-request decision trail, routing is a black box. An auditable decision matters for trust and for debugging what ran.
Managed, or yours to operate?
Self-hosted frameworks are free, but you own the server, the threshold calibration, and the upkeep as frontier models change.
At a glance
The capability split, in one view. Honest cells, the full, sourced breakdowns are linked below.
| Inferbase | OpenRouter | LiteLLM | Portkey | NotDiamond | RouteLLM | |
|---|---|---|---|---|---|---|
| Picks the best model per request | First-party | Via NotDiamond add-on | Beta tiers you map by hand | No, rules you define | Yes | Strong vs weak only |
| Routes and serves in one API | Yes | Yes | Proxies via your providers | Proxies via your providers | No, you run it | No, self-hosted |
| Per-request decision audit | Yes | No | Logs and cost tracking | Deep logs and traces | Recommend-side | Build your own |
| Nothing to self-host or calibrate | Yes | Yes | No | Hosted, rules are yours | Yes | No |
| Model breadth | Curated catalog of open models | Hundreds of models | 100+ providers, your keys | 1,600+ models, your keys | Your chosen pool | Two models |
How Inferbase approaches it
Model selection as a per-request decision, with execution and an audit trail in the same place.
Inferbase treats model selection as a per-request decision: each prompt is classified, scored on the objective you set, and routed to the best model, with a fallback if one fails. What sets it apart is what happens around that decision.
- It serves, not just decides. Unlike a routing brain, Inferbase runs the chosen model, so you get one endpoint, one bill, and one record per request.
- Routing is first-party. Unlike an aggregator, model selection is benchmark-grounded rather than outsourced to a third-party router.
- Nothing to operate. Unlike a self-hosted framework, there is no router server to run and no cost-quality threshold to calibrate by hand.
The same call that picks the model also serves it and records why. See how the routing works in more detail.
Read the full comparison
Each one leads with the routing-philosophy difference, then a side-by-side table and where each tool fits.
Routing is a NotDiamond-powered add-on.
Read the comparisonHosts balanced; tier maps are yours to write.
Read the comparisonRules key on metadata, not the prompt.
Read the comparisonRecommends a model; you run it.
Read the comparisonSelf-host and calibrate it yourself.
Read the comparisonFrequently asked questions
The routing landscape, in plain terms.
A router decides which model to use for each request. A gateway like LiteLLM or Portkey unifies many providers behind one API, with the model choice staying in config or rules you write. An aggregator like OpenRouter is one hosted API to many models, where routing is an optional add-on. Inferbase is routing-first and also serves the model, so the decision and the inference come from one place.
With a routing brain like NotDiamond, a gateway like LiteLLM or Portkey, or a framework like RouteLLM, yes, you bring your own providers and keys and run the inference yourself. With Inferbase, no, it routes and serves through one OpenAI-compatible API.
When your traffic is mixed, yes. Simple prompts do not need a frontier model, so routing each request to the smallest model that clears the bar cuts cost without dropping quality. A single hard-wired model leaves both quality and cost on the table.
They are OpenAI-compatible to varying degrees, so switching is mostly a base URL and key change. Moving to Inferbase needs no provider keys and no routing SDK in your code, you just set model="auto".
With a recommend-only router or a self-hosted framework, inference runs on your own providers with your own keys, so the routing layer may never see your outputs. An aggregator or a managed platform like Inferbase processes the request in order to run the model. The tradeoff is operating providers yourself versus getting routing and serving from one place.
Your AI stack shouldn't stand still.
Every month new models become cheaper, faster, and more capable. Inferbase ensures your application automatically benefits without changing a single API call.