Why I Built on Top of OpenRouter Instead of Building a Model Gateway from Scratch
By Hossein Shahrokni | March 2026
The most common comment I get on Komilion: "Isn't this just a wrapper around OpenRouter?"
Yes, partly. And that's a deliberate choice. Here's the reasoning.
What OpenRouter actually gives you
OpenRouter is a model marketplace — one API key, 400+ models, provider-level pricing. You call openrouter.ai/api/v1, pick any model by ID, pay the provider rate directly. No markup on the models.
What it does not give you: routing logic. You still decide which model handles which request. OpenRouter is the menu. You're still the waiter.
That's a real gap for most production AI apps, and it's the gap Komilion was built to fill.
Why build on top instead of building from scratch
When I started Komilion, I had two options:
Option A: Build a full model gateway. Direct integrations with Anthropic, OpenAI, Google, Mistral, Groq. Manage API keys, rate limits, failover, billing, and model availability for each provider separately. Full control, zero dependency.
Option B: Build on top of OpenRouter. Use their unified API, inherit their model coverage, focus engineering time on the routing classification layer.
I chose Option B for three reasons:
1. OpenRouter solves the hard operational problems. Provider failover when Anthropic is down. Model availability checks. New models added within hours of release. Billing unified across providers. These are real engineering problems — I've seen teams spend 3-4 months building and maintaining this layer. Building on top means that time goes to the routing logic instead.
2. Model coverage compounds. OpenRouter has 400+ models from 30+ providers. Building direct integrations means constantly adding new providers when a good model ships on an unfamiliar platform. With OpenRouter as the foundation, when Groq releases a new model that benchmarks well for frugal tasks, it's available immediately. No new integration work.
3. The value I'm adding is in the classification, not the API plumbing. Komilion's routing has four layers: a regex fast path for obvious simple requests, an LLM classifier for ambiguous ones, benchmark-scored model selection based on task type, and provider failover. That's the hard part. The model access itself is a solved problem.
What Komilion adds
When you send a request to neo-mode/balanced, here's what happens before a model ever sees your prompt:
Regex fast path — if the request matches a known simple pattern (file reads, summaries, commit message boilerplate), it routes immediately without running a classifier. Sub-100ms overhead.
LLM classifier — ambiguous requests go through a lightweight classifier that determines task complexity and category. This is where most routing decisions happen.
Benchmark-scored model selection — the classifier output maps to a model pool ranked by benchmark performance and current provider pricing. The cheapest capable model wins.
Provider failover — if the selected model's provider returns an error, the request falls through to the next ranked option automatically. Your app doesn't see the failure.
None of this requires you to think about which model you're using. You set a quality floor — frugal, balanced, or premium — and the router handles the rest.
The honest trade-off
Komilion charges a markup on top of OpenRouter's provider-level pricing (~25%). You're paying for the routing automation and the ops you're not running.
Whether that's worth it depends on your call volume and team. At 10,000 calls/month, the markup is a rounding error compared to the cost of routing incorrectly or maintaining your own routing layer. At 10 million calls/month, the math changes and you should probably evaluate self-hosted options.
The alternative to Komilion isn't free — it's your time maintaining routing rules, updating model selections as the landscape changes, and handling the edge cases when a model you hardcoded gets deprecated. That cost is real, it just doesn't show up on an invoice.
The one thing you should know if you're evaluating this
Komilion is built on OpenRouter, and that's not a secret. The routing logic and the classification layer are where the value is. The benchmark data at komilion.com/compare-v2 is the proof — 30 calls, 10 real developer tasks, every output published unedited.
If you want to evaluate the routing, that's where to start. If the routing doesn't hold up for your workload, I'd rather you know that before you integrate than after.
komilion.com — DM for test credits.
Top comments (0)