route-switch vs. OpenRouter
OpenRouter is a hosted LLM aggregator with a unified API across 200+ models. Route-Switch is a self-hosted Go gateway with prompt optimization. They overlap in 'one endpoint for many models' and diverge in almost everything else.
| Dimension | route-switch | OpenRouter |
|---|---|---|
| Deployment model Different operational shapes. Pick the one that matches your data residency story. | Self-hosted single Go binary. You run it; you own the SQLite + DuckDB files. | Hosted SaaS. OpenRouter operates the endpoint; you call api.openrouter.ai. |
| Model coverage OpenRouter owns the provider relationships; route-switch is BYO API key per provider. | Whatever providers gollm supports — OpenAI, Anthropic, Google, Ollama, Cohere, Mistral, and others — using credentials you provide. | 200+ models from many providers behind a single API key, with usage routed through OpenRouter's accounts and unified billing. |
| API surface | OpenAI-compatible /v1/chat/completions plus /status, /health, /v1/prompts/{id}/stats, /v1/system/analytics. | OpenAI-compatible chat-completions endpoint plus models list and credits/usage endpoints. |
| Routing logic OpenRouter routes between providers for the same model. Route-Switch routes between combinations you registered. | Strategies (round_robin, weighted, performance_based) over registered prompt+model+provider combinations, with fallback when success rate drops. | Per-request routing preferences (provider order, allow/deny lists, price/throughput sort) set on each call or via account defaults. |
| Prompt management | First-class. Templates registered via CLI; variables rendered server-side; optimizer can rewrite them. | Prompts are part of the request payload; no built-in template registry. |
| Automatic prompt optimization | MIPROv2 with goptuna Bayesian search; runs on demand or in background; scored against captured dataset via Similarity / ExactMatch / KeywordMatch (or your custom evaluator). | Not in scope. OpenRouter is a routing layer, not an optimization layer. |
| Analytics | DuckDB-backed local analytics store: success rate, latency, cost per prompt and globally. | Hosted dashboard with per-request logs, spend, and provider breakdowns inside the OpenRouter console. |
| Streaming | Yes; OpenAI chunk format; usage totals in final chunk. | Yes; OpenAI-style SSE streaming. |
| License We do not cover OpenRouter's pricing here. See their site. | MIT. | Proprietary service. Free tier exists; usage is billed. |
| Best fit | Teams that want self-hosted, want prompt templates as a first-class object, and want a closed loop between traffic and prompt rewrites. | Teams that want zero-ops access to a wide model catalogue and unified billing across providers. |
Where they overlap
Both projects sit between your application and the underlying LLM providers and present an OpenAI-compatible endpoint. Both let your existing OpenAI client keep working while you swap which model serves a given request. Both are useful in the same first-order sense: you stop coding to one provider SDK.
Where they diverge
OpenRouter’s shape is a hosted aggregator: one endpoint, one API key, hundreds of models, unified billing, and routing decisions that live inside the request payload (“prefer this provider, fall back to that one, sort by price”). The mental model is “a marketplace with a load balancer in front of it.”
Route-Switch’s shape is a self-hosted gateway with state: prompt templates and their datasets are first-class objects the gateway owns; the optimizer is part of the same binary as the router; analytics are local DuckDB you can query. The mental model is “a closed loop between production traffic and prompt quality.”
When to pick which
Pick OpenRouter when the value is breadth of model access and zero
operational overhead. If you want to try qwen-2.5-72b next to
claude-3-5-sonnet without provisioning a Together account and a new API
key, that is exactly what OpenRouter is for. If unified billing across many
providers is a feature you’re willing to pay a margin for, the
trade is straightforward.
Pick Route-Switch when you want the prompt template, the dataset, and the optimizer in one process you control. The closed loop — traffic captured, dataset accumulated, optimizer rerun, prompt updated — is the thing OpenRouter doesn’t do because it’s a routing service, not a prompt platform. If your data residency story rules out sending traffic through a third-party endpoint, that decision is made for you.
They aren’t directly substitutable; they’re solving adjacent problems and the “OpenAI-compatible endpoint” surface area disguises the difference.