It's not "Open".<p>I wish this had another name.<p>I love the idea of fire and forget to a central AI aggregator. This one for LLMs, Fal for image and video. You don't need to juggle dozens of API keys or API integrations.<p>But these aren't open, despite it being in the name.<p>I want the ability to pull it all on-prem if I so choose.<p>I probably won't. But if I want to, I should be able to.<p>Don't use the name "Open" like this.<p>OpenAI, OpenRouter, OpenArt... Just stop already.<p>This isn't even fair source, let alone open. It's totally closed and opaque.<p>I'm half minded to make an "ActuallyOpenRouter".<p>(I know there are local routers, but I want hosted and managed with the ability to self-manage.)
While not solving everything (such as a single bill), I implemented borgllm[0,1] as a way to get some of that convenience and development speed with no lock-in or even infra.<p>Perhaps you’ll find it interesting.<p>0: <a href="https://github.com/omarkamali/borgllm" rel="nofollow">https://github.com/omarkamali/borgllm</a><p>1: <a href="https://borgllm.com" rel="nofollow">https://borgllm.com</a>
Use Hugging Face inference providers for this: <a href="https://huggingface.co/docs/inference-providers/en/index" rel="nofollow">https://huggingface.co/docs/inference-providers/en/index</a>
At this point, I'm starting to see "Open" prefix for any product/project as almost an signal for the opposite. Projects that actually are about some sort of openness (the way I see it at least), don't usually prefix their name with it, they just operate "openly" and ensure it stays that way.
The founder named it OpenRouter because his previous startup was OpenSea.<p>Some founders choose a prefix, then tend to use it everywhere :)
Should make a "ClosedRouter", "ClosedAI", "ClosedArt" instead, but be actually open.