Hooking up an API used to be a craft. Every new vendor meant reading its auth scheme, its error codes, its streaming protocol, until your code was a forest of if-else branches. By 2026 that job has been largely eaten by one category of tool: the AI gateway. You tell it "unify every model behind the OpenAI format," and it takes care of key management, load balancing, cost tracking, and failover. The problem is there are now dozens of them on GitHub, and picking is a chore. This piece compares four of the most representative open-source gateways side by side and gives you a per-scenario verdict instead of a vanity ranking.
One thing up front: every comparison below is a representative comparison based on each project's official README, description, and public star count, not a benchmark I ran myself. Star counts are as of 2026-07-29 and move daily; by the time you read this the numbers will have drifted, so don't treat them as a contract.
1. Why everyone is running an AI gateway in 2026
An AI gateway is, plainly, a translator plus a butler. The translator part unifies the babel of vendor API protocols into one shape, usually OpenAI's, so your application only learns one interface. The butler part sweeps up the chores: key distribution, usage billing, load balancing, rate-limit guardrails, failover.
The reason this category turned essential in the last couple of years comes down to three things. First, there are too many models. You use Claude today, switch to DeepSeek tomorrow, want to try Qwen the day after, and rewriting the call site each time will drive anyone mad. Second, cost matters: the same job can cost fifty times more on one model than another, and a gateway can auto-route each task to the cheaper one. Third, key safety. Hardcoding a vendor key into a frontend or handing it out to colleagues is an incident waiting to happen; a gateway funnels everything and hands out temporary keys on demand.
Hold those three in your head and the design tradeoffs of the four gateways below start to make sense. Each is betting on a different one of them. One upfront call before we go further: not everyone needs a gateway. If you only integrate one vendor, it is just you using it, and you are not cost-sensitive enough to route by task, calling the official SDK directly is simpler; bolting on a gateway only adds an ops layer you then have to babysit. A gateway pays off only when you have many models, many people, and a real need to manage cost and keys. The four below are all built for that second situation.
2. The four contenders (star counts as of 2026-07-29, moving daily)
Here is the lineup. Data is from the GitHub API, as of 2026-07-29.
| Gateway | Repo | Stars | Forks | Primary lang | License | Last push |
|---|---|---|---|---|---|---|
| LiteLLM | BerriAI/litellm | 54961 | 10169 | Python (Rust core) | NOASSERTION | 2026-07-29 |
| one-api | songquanpeng/one-api | 36020 | 6759 | JavaScript | MIT | 2026-01-09 |
| OmniRoute | diegosouzapw/OmniRoute | 33334 | 4305 | TypeScript | MIT | 2026-07-29 |
| Portkey | Portkey-AI/gateway | 12585 | 1227 | TypeScript | MIT | 2026-05-25 |
Two details to call out now, because they are hard selection metrics, not footnotes. one-api's last push sits at 2026-01-09, so it has gone several months without an update. Portkey's sits at 2026-05-25, nearly two months silent. A pause is not the same as death, but maintenance activity directly determines whether someone fixes the bug you hit. LiteLLM and OmniRoute both pushed today, which is about as active as it gets.
3. Eight dimensions side by side: who is strong where
Lay the official descriptions flat and line them up across eight dimensions. This table is a representative comparison based on official READMEs and descriptions, not a hands-on benchmark; the provider and model counts are self-reported by the projects.
| Dimension | LiteLLM | one-api | OmniRoute | Portkey |
|---|---|---|---|---|
| Positioning | Fastest, lightest universal gateway | LLM API management & distribution | Free AI gateway | Blazing-fast gateway + integrated guardrails |
| Unified format | OpenAI format | Mostly OpenAI format | OpenAI-compatible | OpenAI-compatible |
| Providers/models | 100+ LLM APIs | 10+ domestic + overseas | 290+ providers / 500+ models | 1600+ LLMs |
| Headline feature | Cost tracking/guardrails/LB/logging | Key mgmt & secondary distribution | 90+ free providers / 15-95% token compression | 50+ AI guardrails |
| Deployment | Self-host / proxy service | Single binary + Docker one-click | Desktop / PWA / self-host | Self-host / cloud |
| Toolchain fit | Bedrock/Azure/VertexAI/vLLM/NIM | Full domestic vendor coverage | Claude Code/Codex/Cursor/Cline etc | Guardrails focus |
| Maintenance activity | Pushed today (active) | Months silent (note) | Pushed today (active) | ~2 months silent (note) |
| Best for | Production-grade universal pick | Domestic key distribution & aggregation | Free models for coding tools | Enterprise guardrails |
Mind the apples-to-oranges: Portkey claims 1600+ LLMs routed, LiteLLM claims 100+ LLM APIs, OmniRoute claims 500+ models. Those are different units, some count LLMs, some count providers, some count models, so you can't just pick the bigger number. OmniRoute's "90+ free out of 290+ providers" is its sharpest selling point, and we will come back to it.
4. One by one: each gateway's best range
LiteLLM: the production-grade universal pick
54961 stars, the most of the four, pushed today. The official one-liner is "fastest, lightest AI gateway," unifying 100+ LLM APIs into OpenAI format and folding in cost tracking, guardrails, load balancing, and logging. Named vendors include Bedrock, Azure, OpenAI, Anthropic, VertexAI, vLLM, and Nvidia NIM, essentially the full overseas big-vendor roster.
Its bet is "universal plus production." Universal means it tries to recognize whatever vendor you throw at it. Production means it bakes the operational must-haves, cost tracking, load balancing, logging, into the gateway itself instead of leaving you to wire them up. Primary language Python with a Rust core, so the "light and fast" claim has a performance floor under it. The license is NOASSERTION, which is not MIT; read the actual terms before assuming it is free for commercial use.
Best for: teams running production, integrating the major overseas vendors, with real needs around cost and load balancing. Solo developers can tinker locally too, but its sweet spot is production.
one-api: domestic key distribution and multi-model aggregation
36020 stars, a domestic project, JavaScript, MIT. Its last push sits at 2026-01-09, the only clear stall among the four, so go in with eyes open. The official positioning is "LLM API management & distribution system," and its weapon is a single executable plus a Docker image for one-click deploy, with key management and secondary distribution layered on.
Where it clicks hardest is full domestic-vendor coverage: OpenAI, Azure, Anthropic, Gemini, DeepSeek, ByteDance Doubao, ChatGLM, ERNIE Bot, iFlytek Spark, Tongyi Qianwen, 360 Brain, Tencent Hunyuan. That list is genuinely useful for Chinese teams that routinely wire up several domestic models side by side for comparison or failover; one-api bundles that work. Secondary key distribution is its other card: you hold one master key, hand out sub-keys with quotas, and watch usage, which maps directly onto team management.
Best for: domestic teams that need to distribute keys with quotas to many people while wiring up a stack of domestic models. The cost is that maintenance has fallen behind, so expect to fork-and-fix yourself when you hit a wall.
OmniRoute: free models for Claude Code and friends
33334 stars, TypeScript, MIT, pushed today. The official one-liner is "free AI gateway," one endpoint to 290+ providers, of which 90+ are free, covering 500+ models including Kimi, Claude, GPT, Gemini, GLM, DeepSeek, and MiniMax. Its hardest punch is making "free" the core product.
But what actually hooks developers is the toolchain-compat line: it works with Claude Code, Codex, Cursor, OpenCode, Cline, and Copilot. Meaning you can use it as a shim to route tools like Claude Code, which normally want a paid subscription, onto the free models in that 90+ pool. It backs that with two proprietary tricks: RTK plus Caveman compression, claiming 15% to 95% token savings, and quota-aware automatic failover that switches when a free quota runs out. There is also MCP/A2A support, a desktop app and PWA, and 500+ contributors.
Best for: solo developers who want to drive Claude Code or Cursor without paying a subscription and can tolerate "good enough" stability from free providers. It has engineered free-riding into a product, which makes it the outlier in this lane. But the 90+ free providers are inherently uneven; free things can disappear at any moment, so don't run production-critical paths on it.
Portkey: enterprise guardrails
12585 stars, TypeScript, MIT, last push 2026-05-25, silent for nearly two months, another maintenance signal to watch. The official positioning is "blazing-fast AI gateway + integrated guardrails," routing 1600+ LLMs with 50+ AI guardrails. Its bet is different from the other three: where they compete on "how many models, how many tokens saved," Portkey competes on "guardrails."
Guardrails here mean the checks that run before a request hits the model and after the response comes out, things like content safety, compliance, and privilege interception; 50+ of them is not a small number. For finance, healthcare, or government-adjacent work where compliance is non-negotiable, guardrails are a hard requirement, not a nice-to-have. Its star count is the lowest of the four, but that is more a function of positioning than quality. Enterprise-grade guardrails are a narrow audience by definition.
Best for: enterprise teams with hard compliance constraints that need content-safety and privilege checks enforced at the gateway layer. If you only want to unify API formats and save some money, Portkey's guardrails are overkill.
5. A decision tree: which one for you
Don't pick by stars; pick by the job. Here is a path to slot yourself into.
You are going to production, wiring up the major overseas vendors, and you need cost tracking and load balancing. Pick LiteLLM. That is its sweet spot, the most stars and a push today, so production maturity is the safest bet.
You are a domestic team that needs to hand out keys with quotas to a bunch of people while wiring up a stack of domestic models. Pick one-api. Domestic-vendor coverage and secondary key distribution are its home turf, and the single-binary deploy is painless. The caveat is that it has been silent for months, so be ready to fork when something breaks.
You are a solo developer who wants to run Claude Code or Cursor without a subscription and can live with flaky free providers. Pick OmniRoute. It has productized free-riding, and the token compression plus auto-failover is the honest version of "free."
You are an enterprise team where compliance is a hard constraint and you need content-safety and privilege checks at the gateway. Pick Portkey. Its 50+ guardrails are differentiation nobody else offers; the low star count is because the lane is narrow, not because it is bad.
Two common combos. One, run LiteLLM as the base for general routing and layer Portkey's guardrails on top for compliance; they are not mutually exclusive. Two, use OmniRoute as a personal free-riding entry and one-api for the team's real keys, and keep them separate. Run production on real keys, tinker on free, and drawing that line cleanly saves you most of the headaches.
6. Three pitfalls: maintenance activity, free stability, key safety
First, maintenance activity matters more than star count. one-api and Portkey both show stall signals, one for months and one for nearly two months. Stars are accumulated history; activity is future insurance. Before you pick, scan the last six months of commits and check whether anyone is replying in the issue tracker; that is far more reliable than star count. A 36000-star project that has been idle half a year isn't necessarily a better fit than a 5000-star project that pushes daily. On these two specifically: one-api is a domestic project, so there is some chance a community fork keeps it alive, but the official main repo not moving is still not moving; Portkey has a commercial company behind it, so the stall more likely means the team's attention shifted to its cloud product and the open-source edition became a lead-gen funnel. Betting on the open-source edition in that case means betting they are willing to keep maintaining it, and you own that risk.
Second, free-provider stability is inherently shaky. OmniRoute's 90+ free providers are its biggest draw and its biggest uncertainty. Free things can get rate-limited, change their API, or go dark at any time. Fine for personal tinkering; a gamble for production-critical paths. If you genuinely want to save money, the steadier play is OmniRoute as a fallback and paid real keys for anything that matters. Don't tie your production lifeline to a free provider.
Third, key safety is the first job of any gateway. The whole point of funneling keys is to stop them from flying around. But funneling isn't the same as securing: sub-keys you hand out should have quota caps, usage logs, and revocation on demand. one-api's secondary distribution and LiteLLM's cost tracking are both there to help you manage keys. Conversely, if a gateway can't even do basic key isolation cleanly, no amount of stars justifies putting it in production. And don't wire the vendor's master key straight to the gateway backend; give the gateway a sub-key with a quota cap, so if the gateway itself leaks, the blast radius stays bounded.
7. Don't worship stars; look at your own job
Four gateways, four bets: LiteLLM universal, one-api domestic, OmniRoute free, Portkey guardrails. None of them is the all-rounder. Star count gives a rough heat read, but the selection key is your scenario: production wants activity and load balancing, domestic teams want key distribution and domestic coverage, solo savers want free providers and toolchain compat, enterprise compliance wants guardrails.
One more time, out loud: the comparisons here are representative, drawn from official READMEs, descriptions, and public star counts, not from benchmarks I ran. If you are going to production, pull the thing down and run it against your real traffic; that beats a hundred reviews. An AI gateway in 2026 is infrastructure-grade selection. Pick wrong once and the migration cost later is not small, so get it right by scenario the first time.
References
- LiteLLM: https://github.com/BerriAI/litellm
- one-api: https://github.com/songquanpeng/one-api
- OmniRoute: https://github.com/diegosouzapw/OmniRoute
- Portkey gateway: https://github.com/Portkey-AI/gateway