Ragmux vs OpenRouter: self-hosted gateway or hosted router?

“Self-hosted AI gateway comparison” and “OpenRouter alternative” overlap heavily in what people actually search for, but the honest answer starts by saying they’re not really alternatives to each other. OpenRouter is a hosted router: you send it requests over the network and it picks a model and a provider for you. Ragmux is a self-hosted gateway: you run the binary, and it’s your infrastructure that answers /v1/chat/completions. Neither is a strict upgrade over the other — they solve different problems, and the right one depends on whether “run nothing yourself” or “keep everything on infrastructure you control” is the actual requirement.

What each one is

OpenRouter’s own documentation opens with: “OpenRouter gives you access to hundreds of AI models through a single API endpoint. It handles fallbacks automatically and picks the most cost-effective option for each request.” Its quickstart confirms OpenAI SDK compatibility — “You can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement,” at the base URL https://openrouter.ai/api/v1 — and nowhere in either page is there a container image, a Helm chart or a “self-host” section. There is no infrastructure of your own involved at any point.

Ragmux is the opposite shape: a single Go binary you deploy, backed by one PostgreSQL database, that adds retrieval-augmented generation as part of every request instead of requiring a separate system. See What is an AI gateway? for the fuller version.

Feature comparison

When a hosted router is genuinely the right answer

Say this plainly rather than only implying it through the table: if what you actually want is model access with nothing to operate — no container, no database, no image to patch, no capacity to plan for — OpenRouter is the correct choice, and none of the self-hosted options in this comparison set, Ragmux included, is a real substitute for that trade-off. Cost-based routing across “hundreds of AI models” (OpenRouter’s own phrase) is work Ragmux does not do at all — a route spreads requests only across the targets you listed, by weight and priority, not across a catalog it picks from for you. A prototype, a small team without infrastructure to spare, or a workload that genuinely needs the breadth of “call whichever provider is cheapest or fastest right now” is better served starting there than standing up Postgres for a gateway that won’t do that job either.

When self-hosting is the requirement instead

Ragmux exists for the opposite set of constraints: documents, request logs and provider credentials that need to stay inside infrastructure you control rather than a vendor’s, retrieval that has to be part of every request rather than a separate pipeline, and per-project token budgets enforced by something you operate rather than trusted to a third party’s dashboard. None of that is available from OpenRouter at any price, because there is no self-hosted version of it to point at your own database or your own network boundary. A team that has already decided it needs to self-host is not actually choosing between Ragmux and OpenRouter — it has already ruled OpenRouter out on that basis alone, and the real comparison is against another self-hosted gateway; see Self-hosted AI gateway comparison for that version of the question.

A specific overlap worth knowing about

The two aren’t mutually exclusive in one narrow sense: OpenRouter’s OpenAI-compatible API means it can sit behind Ragmux as a model connection through the custom_openai provider type, the same pattern documented for LiteLLM and vLLM. A project could route through OpenRouter for its breadth of models while Ragmux adds retrieval and per-project token budgets in front of it — though at that point the request still leaves your infrastructure for OpenRouter’s, so it does not satisfy a requirement to keep everything self-hosted end to end.

A worked example: two teams, two different right answers

Take two teams evaluating LLM infrastructure in the same week. The first is a two-person side project prototyping a writing assistant: no compliance requirement, no documents to ground answers in, and a real cost to any time spent operating a database instead of shipping the feature. Pointing the OpenAI SDK at https://openrouter.ai/api/v1 and picking a model is the entire infrastructure decision — there is no Ragmux deployment that beats “nothing to run” for that team, and suggesting one would be the wrong advice.

The second is an internal-tools team building a support assistant that has to answer from an actual internal knowledge base, keep request logs on infrastructure the security team already audits, and report token spend per requesting team at the end of the month. None of that is available from OpenRouter regardless of budget, because there’s no self-hosted version of it to point at an internal document store or a network boundary the team controls. That’s the Ragmux case, and it has nothing to do with which project offers more models — it’s a different set of requirements entirely.

What “self-hosted” actually costs, concretely

It’s worth being specific about what “more operational work” means rather than leaving it abstract. Ragmux’s default image bundles PostgreSQL 17 with pgvector in the same container as the gateway — one container, one volume — so a single-host evaluation is one docker run away, not a multi-service stack to assemble first. Scaling past one replica needs nothing extra either: every replica shares rate limits, budgets, sessions and the document-ingestion queue through that same database, so a plain load balancer in front of several containers is the entire scaling story, no Redis or session affinity required. That’s genuinely less than some self-hosted alternatives ask for, even though it’s still more than OpenRouter’s zero. The honest comparison isn’t “self-hosted is hard,” it’s “a team that has decided to self-host for real reasons should also expect a real, if small, operational baseline that a hosted router has no equivalent of at all.”

Where Ragmux is not the answer

• PostgreSQL with pgvector is mandatory, and OpenRouter needs none of that — running Ragmux is strictly more operational work for a team that only needed model access.
• No cost-based routing, and fallback only across targets you configured. A route can fall back from one connection to the next, but only to targets you added by hand; if every one of them is down or expensive right now, Ragmux does not go looking for another provider the way OpenRouter does.
• Ragmux is pre-1.0. The current release is 0.5.0, with SSO/OIDC login and dollar-denominated budgets listed on the roadmap as not scheduled.
• AGPL-3.0-or-later carries a network-use clause that has no equivalent for a hosted service you never modify or redistribute in the first place.
• Reference docs are in English; guides are mostly in English too, with a few in Turkish, and Ragmux’s install base is far smaller than an established hosted router’s user community.