Teardownspublic

OmniRoute

I didn't skip this 41,856-star gateway over performance. Its tier 1 is my own subscription accounts, disguised and sent upstream.

There were seven things worth learning from this design, and I adopted none of them. OmniRoute bundles 291 AI providers behind a single local endpoint. 41,856 stars, 211,769 npm downloads a month. But the first tier it routes to is my own Claude Code and Codex subscription accounts, and the way it gets them there is TLS fingerprint spoofing and client-name obfuscation. The repository itself models “permanent account suspension” not as an exception but as a normal operating state, and ships ban detection as a product feature.

the path one request takes — tried top to bottom, in order 33 IDEs and CLIs — Claude Code · Codex · Cursor · Cline · Copilot all of them point at localhost:20128/v1 and nothing else OmniRoute — one local process · twelve compression engines Session-Dedup · RTK · Headroom · Caveman · LLMLingua-2 … code, URLs and JSON are held back by a preservation layer T1 subscriptions Claude Code · Codex T2 API keys DeepSeek · Groq · xAI T3 cheap GLM $0.5 · MiniMax $0.2 T4 free Kiro · Qoder · Pollinations ⚠ the first box is my own subscription — the rest can be perfect and this one box still blocks adoption
Walking down the tiers in order is a clean structure. The problem is what sits in the first position.

What it actually is

An OpenAI-compatible proxy that runs on your own machine. npm i -g omniroute opens localhost:20128/v1, and every IDE and CLI points at that one address. Behind it a router picks a provider, and when one fails it drops to the next. Three things are on the box — four-tier automatic fallback, twelve-engine token compression, three-layer resilience.

The scale is real. This is not a repository that filled in a catalogue.

Part Measured
Source 11,091 files total — .ts 7,133 · .tsx 1,023
Tests 4,240 files — unit 3,991 / integration 124 / e2e 42
Docs 1,460 files, but 1,215 of those are translations into 43 languages, so ~245 originals
Distribution npm global · Docker · Electron · Termux · PWA
Machine interfaces MCP 104 tools / 31 scopes · A2A · REST · webhooks · 80+ CLI commands

211,769 npm downloads a month, 288 versions in six months. This thing genuinely runs.

The techniques — this part is genuinely good

It refuses to treat failure as one thing. The same “error” is split three ways. L1, the circuit breaker, cuts a whole provider (only on 408 and 5xx, then half-opens a probe after 60/30/15 seconds). L2, cooldown, rests a single key (5-second base with exponential backoff, honouring Retry-After on 429). L3, lockout, locks a single model. When something breaks, which layer died is a distinct answer.

And it keeps a category for failures you must not retry. From the docs: “terminal states (banned, expired, credits exhausted) are for the operator; they are not cooldown material.” Failures that cannot recover never enter the retry queue — they go to a human.

The other five. Changelog fragments — every PR adds one new changelog.d/<issue>-<slug>.md, merged at release time. Nobody edits the same file, so merge conflicts are structurally zero. Five nightly CI jobs — mutation testing, property-based, OpenAPI schema fuzzing, resilience, LLM security. A discipline of publishing the method next to the number — the headline sits beside its dedup rule, its re-audit cadence, and the line “these numbers move in both directions.” Wrapping the tool in 45 skills. A preservation engine — a layer in front of all twelve compressors that protects code, URLs and JSON byte-for-byte.

What broke when I checked

“89.2% average token savings” is one multiplication. The formula is 1 − (1−0.80) × (1−0.46), which is only true if the two compressors eat different redundancy. In practice the first strips structural repetition in tool output and the second strips lexical redundancy in prose — they overlap. The repository contains no measurement of that independence.

“291 providers · 25,000+ tests” doesn’t survive arithmetic. Counting the test files, the round-trip categories are e2e 42 and integration 124. A test that actually exercised all 291 providers cannot exist. Most of them are catalogue entries, not verified paths.

“500+ contributors” paged out to 368. The API cap is 500, so it wasn’t truncated. And of 6,225 commits, 3,822 (61%) belong to one person; second place has 216. Tenth on the contributor list is Antigravity Assistant with 45 commits, and one week peaks at 572 commits — 80 a day. A large share of these commits is machine-written.

the three headline numbers — every one re-counted by hand 89.2% average token savings the two compressors overlap — independence never measured 291 providers · 25,000+ tests round-trip coverage is e2e 42 · integration 124 500+ contributors 368 by full paging · 61% of commits are one person ⇒ none of the three are false so much as unverified — quoting them means measuring again myself And none of it decided adoption. What blocked adoption was the shape of tier 1, not the numbers 7 candidate techniques · 0 adopted — a good design still arrives attached to the body it lives in
Verifying numbers and deciding adoption are separate axes. This repository failed on both, for unrelated reasons.

Why all of it was rejected

What blocked this was structure, not performance. Four things stacked up.

  • Routing around subscriptions is tier 1. A zero-width joiner (U+200D) is inserted after the first letter of each client name. The stated purpose in the docs is “so upstream filters cannot grep it.” Another module imitates a Firefox TLS fingerprint exactly; a third reconstructs requests to be “indistinguishable from official CLI traffic.” The same document opens by saying it is “not for ToS violation” — the disclaimer and the code disagree.
  • Bans are treated as a constant. There is a feature that scans upstream responses for suspended and deactivated and drops that connection to a permanent banned state, with a settings card in the dashboard. Ban detection as a product feature means bans are not exceptional.
  • It installs a root CA into the OS trust store. Around 60 files of local HTTPS decryption. It ships disabled and the repo warns about it, but that is a security-approval question, not a personal call.
  • Both safety nets fail quietly. PII masking is “fail-open; exceptions never block traffic” — if the masker throws, the raw text goes out. The audit log “swallows failures silently.” A log whose gaps are invisible cannot be used as evidence.

And I rejected the seven techniques along with the tool. That is the judgement this page paid for. Three-layer failure isolation and the terminal-state split both fit my overnight QA loop exactly — but harvesting good pieces is itself what keeps a repository open in front of you. To port a piece you keep referring to the original, and referring to it slides into “surely this much is fine on my own machine.” The boundary belonged at the repository, not at the piece.

Verdict

Item Call
Adopt the tool Blocked. Not worth revisiting
Harvest the 7 techniques All rejected. Not even piecemeal
Re-propose No. This document is not grounds for another attempt
Reopen when Only if I explicitly pull this repository back out

In fairness, this repository does dangerous things and documents the danger rather than hiding it. Fifteen security documents — egress policy, error sanitisation, supply chain, incident response, each its own file. That is better than the alternative. But disclosing a risk is not the same as removing one.

One last note on health. 61% of commits from one person, one npm maintainer — bus factor of one. 288 versions in six months is 1.5 releases every two days, which makes regression risk structural. 41,856 stars do not cover either of those.