Flux vs OpenRouter vs LiteLLM: run-level budgets vs per-request routing
OpenRouter, LiteLLM and Flux all expose an OpenAI-compatible endpoint and can route requests across model providers. They differ in where they run and in what a budget is attached to. This page compares them on five points, based on each project's public documentation.
Last updated: . Competitor details last checked [DATE].
The short version
To our knowledge, OpenRouter and LiteLLM make routing and budget decisions one request at a time, and their spend limits attach to API keys, teams, users or customers. Flux attaches a budget to an entire agent run: every call that shares an X-Flux-Run-Id header, including retries and subagents, draws from the same budget, and routing gets more cost-sensitive as that budget is consumed.
That makes the tools complementary more often than competing. A per-key limit protects an account. A run-level budget controls what one piece of agent work is allowed to cost.
Side-by-side comparison
| Capability | Flux | OpenRouter | LiteLLM |
|---|---|---|---|
| Self-hosted | Yes. Runs in your own infrastructure; requests go straight to the providers you configure. | No, to our knowledge. OpenRouter is a managed, hosted service. | Yes. The LiteLLM proxy can be self-hosted. |
| Budget scope | An entire agent run: every call sharing an X-Flux-Run-Id, including retries and subagents. Per-tenant daily ceilings as well. | Per API key credit limits, drawing on one account balance. | Per virtual key, team, user, organization and end customer, with reset windows. |
| Adaptive degradation mid-run | Yes. Degrades to cheaper models from 70% of the run budget, warns at 90%, hard-stops with a 429 at 100%. | Not to our knowledge. Requests are rejected once a key's limit is exhausted. | Not to our knowledge. Requests are blocked at the cap; models configured as zero-cost can still be served. |
| Routing basis | Per request and per agent step: task type, capability and quality floor, then cost, weighted by how much of the run budget is left. | Provider selection by price and uptime by default, or sorted by price, throughput or latency; optional Auto Router for model selection. | Routing across configured deployments: load balancing, fallbacks and strategies such as lowest-cost routing. |
| OpenAI-compatible | Yes | Yes | Yes |
How the budget scopes differ
Per-key and per-team limits
OpenRouter lets you set a credit limit on an individual API key; when the key's limit is exhausted, requests are rejected. LiteLLM's proxy supports budgets on virtual keys, teams, users, organizations and end customers, with reset windows, and blocks requests at the cap. Both are effective ceilings. Neither, to our knowledge, changes which model a request goes to as a limit approaches.
Run-level budgets
Flux tracks cumulative spend for each run ID. Below 70% of the run budget, calls route to the cheapest model that meets the quality floor. From 70%, Flux shifts to cheaper capable models; at 90% it raises a warning; at 100% it hard-stops with a 429. Degradation is the primary mechanism and the hard stop is the last resort. The per-run budget example in the docs shows the parameters.
How routing decisions differ
OpenRouter's default provider routing balances price and uptime across the providers serving a model, and can be sorted explicitly by price, throughput or latency. LiteLLM routes across the deployments you configure, with load balancing, fallbacks and cost-based strategies. Flux classifies each request and agent step by task type, filters to models that meet capability and quality-floor requirements, scores the remaining models on cost against quality, and factors in how much of the run budget is left. Planning and final-answer steps can keep a higher quality floor than mechanical steps such as tool-result summaries.
Routing decisions in Flux are pure heuristics with no LLM call in the path; the benchmark methodology covers how routing latency and estimated savings were measured.
When OpenRouter or LiteLLM may fit better
- You want one hosted API for a very wide model catalog and don't want to run infrastructure. OpenRouter is a managed service.
- You need a widely adopted self-hosted proxy with an admin UI, virtual keys and many provider integrations. LiteLLM covers that.
- Your workloads are single requests rather than multi-step agent runs, so a per-key cap is the control you need.
Flux is aimed at teams running agents where a single run can retry, spawn subagents and swing between easy and hard steps. If that describes your workload, talk to the Flux team or ask about early access. Flux custom plans are priced per governed run and tenant.
Sources
- OpenRouter provider routing documentation
- OpenRouter API credit and rate limits
- LiteLLM budgets and rate limits
- LiteLLM getting started and proxy overview
- Flux documentation and Flux FAQ
Product capabilities change. If something here is out of date, email vandith@flux-llm.com and we'll correct it.