An LLM router sits in front of several models and decides which one answers each request — usually to trade cost against quality. It's how teams cut their API bill without hand-picking a model for every call. Most routers — LiteLLM, Portkey, Martian, the cloud model-routers — still route between models you name and configure. You trade one decision (which model?) for another (which routing rules?).
TierUp is a router that deletes the decision. You don't route between models; you request a performance tier and we route the call to what we assess as the best-value model in that class. No model names, no routing rules to maintain, no migrations when a better model ships.
Send an OpenAI-compatible request with model set to tier-1 through tier-4 — Speed, Balance, Intelligence, Reasoning:
curl https://tierup.ai/v1/chat/completions \
-H "Authorization: Bearer $TIERUP_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "tier-2",
"messages": [{"role": "user", "content": "Summarize this ticket."}]
}'tier-2 to a backing model server-side and forward the call. When a better model enters the balance class, your tier upgrades — zero code changes on your end.A lot of routers pitch "we pick the cheapest model per request." TierUp routes to the best value model inside a quality class, not the globally cheapest token regardless of output. The tier is the promise: tier-2 stays balance-class whatever model is behind it.
On price: per-tier rates run ~50% below the retail price of the models we route to, and tier 1 is currently free. The honest caveat, which we make everywhere: that discount is a transparent subsidy during our public beta — capped by a daily spend guardrail, not secret efficiency — and we route through OpenRouter today. This is an abstraction on top of existing infrastructure, not our own GPU fleet. If out-cheaping every token is the whole goal, a raw model marketplace is a closer fit; TierUp optimizes value within a class and hides the model-churn work.
| TierUp (tier routing) | Typical LLM router / gateway | |
|---|---|---|
| What you configure | A performance tier (tier-1…tier-4). No model names, no per-model routing rules | Model names, weights, fallbacks, and routing rules you write and maintain |
| Who owns model choice | TierUp. Tier→model mappings are versioned server-side; your tier upgrades with zero code changes when a better model ships | You. New model ships, you evaluate it and update your routing config |
| Routing signal | Performance class you asked for (speed / balance / intelligence / reasoning) | Rules you define: cost caps, latency, model allow-lists, prompt-complexity heuristics |
| Model names in responses | Stripped on purpose, so code can't depend on a specific checkpoint | Exposed — you see and can pin the exact model |
| Change management | Every tier change is versioned, announced ≥14 days ahead (material), and CI-enforced against a public changelog | You track upstream model deprecations and price changes yourself |
| Pricing | Flat per-tier, ~50% under the retail price of the underlying models. Transparently subsidized during our public beta; tier 1 currently free | Varies by tool — self-hosted (your infra cost) or pass-through of each model's price plus the gateway's fee |
| Setup | Change two strings in an OpenAI SDK; nothing to run | Config files, and for self-hosted gateways, a service to run and keep alive |
| Maturity | Very early — built solo, public beta this year, ~zero production users. That's the honest state of it | LiteLLM/Portkey/cloud routers are mature and widely deployed. If maturity decides it, they win today |
Handing model choice to a router raises a fair worry: won't the thing behind my tier change under me? It can — that's the point of outsourcing "which model is best value now." What we commit to is that it won't change silently. Every model/price/free change to a named tier is versioned, announced at least 14 days ahead for material changes, machine-checkable via GET /v1/tiers/changelog, and CI physically refuses to let a tier drift without a changelog entry. A named TierUp tier is a stable contract, not a moving target — read how that works on the Tier Changelog.
To be clear about what this is not: it isn't a guarantee that a tier's outputs are byte-for-byte identical over time (no router can honestly promise that), and it isn't a generic model-deprecation feed. It's an advance-notice contract on the named tier you code against.
If your real requirement is "cheap and fast," "balanced," or "smartest available" — a performance class, not a checkpoint — tier routing is the shorter path.
An LLM router sits in front of several models and decides which one handles each request, usually to trade cost against quality. Most routers (LiteLLM, Portkey, Martian, cloud model-routers) route between models you still name and configure. TierUp is a router where you never name a model at all: you request a performance tier and we route the call to what we assess as the best-value model in that class.
You send an OpenAI-compatible request with model set to tier-1 through tier-4 (Speed, Balance, Intelligence, Reasoning). We map that tier to a backing model server-side and forward the call. The mapping is versioned and can be upgraded to a newer model without any change on your side. Responses strip the provider and model name on purpose, so your code can't grow a dependency on a specific checkpoint.
Within a tier, we route to the model we assess as the best value for that performance class — not the globally cheapest model regardless of quality. The tier is the promise: tier-2 stays balance-class whatever model is behind it. If your goal is strictly 'cheapest token that returns anything,' a raw model marketplace is a closer fit; TierUp optimizes value inside a quality class, not price alone.
Because we're subsidizing it, on purpose, during product–market-fit discovery — not because of secret efficiency. Per-tier prices run ~50% under the retail price of the models behind them, capped by a daily spend guardrail and disclosed everywhere including here. Tier 1 is currently free. We route through OpenRouter today, so this is an abstraction on top of existing infrastructure, not our own GPU fleet.
Two strings, if you already use an OpenAI SDK: point the base URL at TierUp and set model to a tier. Streaming, error shapes, and the rest follow the OpenAI conventions your client already expects.
The model behind a tier can change — that's the feature; you're outsourcing the 'which model is best value now' question. What we commit to is that it won't change silently: every model/price/free change to a named tier is versioned, announced at least 14 days ahead for material changes, machine-checkable via GET /v1/tiers/changelog, and CI physically refuses to let a tier drift without a changelog entry. See the Tier Changelog for how that contract works.
Also see: Best LLM routers in 2026 · How to reduce LLM API costs · TierUp vs OpenRouter · LLM API cost calculator · Tier pricing & details
Route a request through a tier before you believe any of this.
The playground at tierup.ai/try works without signing up. If you like it, signup gets you $25 in credit, no card required.