Environment
- OmniRoute version: 3.8.49 (npm global install)
- OS: macOS (Darwin)
- Node: v26.4.0
- npm: 11.17.0
- Providers connected: Google AI (
google, api-key) and OpenRouter (openrouter, api-key), both added via omniroute setup --add-provider interactive wizard
Summary
After connecting two API-key providers (Google AI, OpenRouter), the model catalog for both stays empty/placeholder-only in both the CLI and the dashboard's Combo Studio, which blocks building a priority routing combo entirely. Separately, model: "auto" silently routes to a free-tier provider instead of the connected paid providers, and provider status endpoints return contradictory results depending on which command is used.
Steps to Reproduce
npm install -g omniroute, omniroute serveomniroute setup --add-provider → add Google AI (api-key) → succeeds ("✓ Provider configured: Google AI")- Repeat for OpenRouter (api-key) → succeeds
omniroute providers list → both show upomniroute providers test-all → both report OK ... provider test passedomniroute models google → "No models found."omniroute models openrouter → only returns a single placeholder row, Auto (Best Available), no real models- Dashboard → Combinations ("Kombinationen") → Create Combo → Steps → select Provider
google → Model dropdown never populates, stays on "Select model" — impossible to add a step, impossible to build a priority combo
omniroute providers status (and --output json) → No provider connection data available. / {"count":0,"connections":[]} — contradicts providers list (2 connections) and providers test-all (both OK) run moments earlieromniroute restart (and a full manual process kill + omniroute serve restart) → no change in any of the above
Additional finding — auto-routing bypasses connected providers
Sending a real request:
curl http://localhost:20128/v1/chat/completions -d '{"model":"auto","messages":[{"role":"user","content":"..."}]}'
returned a successful response, but response headers showed x-omniroute-provider: felo, x-omniroute-model: felo-chat — i.e. auto routed to the free "Felo" provider instead of either connected (paid) provider, silently, with no indication this would happen.
Additional finding — direct model addressing resolves to unrelated third-party relays
Trying to address Google directly by ID to work around the broken dropdown:
model: "google/gemini-2.5-pro" → {"error":{"message":"No active credentials for provider: vercel-ai-gateway", ...}}model: "google/gemini-2.5-flash" → {"error":{"message":"No active credentials for provider: api-airforce", ...}}model: "gemini-2.5-pro" (no prefix) → {"error":{"message":"Ambiguous model 'gemini-2.5-pro'. Use provider/model prefix (ex: in-ai/gemini-2.5-pro or t3chat/gemini-2.5-pro)", ...}}
None of the suggested/resolved prefixes (vercel-ai-gateway, api-airforce, in-ai, t3chat) correspond to the google or openrouter connections that were actually configured. It's unclear whether these are unrelated free-tier catalog entries that happen to share a model name, or whether the catalog is meant to disambiguate this better. Either way, there's no discoverable way to address the specific, connected google/openrouter provider by model ID once the dashboard dropdown is broken.
Expected Behavior
omniroute models <provider> should list the real models available for a successfully-tested provider connection.- The Combo Studio model dropdown should populate for any provider that passes
providers test.
providers status should not contradict providers list/providers test-all run at the same point in time.auto routing should not silently prefer an unconnected free-tier provider over explicitly connected, tested, paid providers without clear documentation/control over that precedence.
Also noticed (possibly related, lower priority)
CLI write operations (e.g. omniroute compression configure --engine none) return 401 even with a freshly created, non-expired CLI access token (Zugriffstoken) exported as OMNIROUTE_API_KEY — tested with two separately generated tokens, same result both times. Unclear whether restricted CLI tokens are simply not permitted to write config, and if so this isn't documented anywhere I could find in the shipped npm package (the docs/ folder referenced throughout the README is not included in the npm package).
Environment
google, api-key) and OpenRouter (openrouter, api-key), both added viaomniroute setup --add-providerinteractive wizardSummary
After connecting two API-key providers (Google AI, OpenRouter), the model catalog for both stays empty/placeholder-only in both the CLI and the dashboard's Combo Studio, which blocks building a
priorityrouting combo entirely. Separately,model: "auto"silently routes to a free-tier provider instead of the connected paid providers, and provider status endpoints return contradictory results depending on which command is used.Steps to Reproduce
npm install -g omniroute,omniroute serveomniroute setup --add-provider→ add Google AI (api-key) → succeeds ("✓ Provider configured: Google AI")omniroute providers list→ both show upomniroute providers test-all→ both reportOK ... provider test passedomniroute models google→ "No models found."omniroute models openrouter→ only returns a single placeholder row,Auto (Best Available), no real modelsgoogle→ Model dropdown never populates, stays on "Select model" — impossible to add a step, impossible to build a priority comboomniroute providers status(and--output json) →No provider connection data available./{"count":0,"connections":[]}— contradictsproviders list(2 connections) andproviders test-all(both OK) run moments earlieromniroute restart(and a full manual process kill +omniroute serverestart) → no change in any of the aboveAdditional finding — auto-routing bypasses connected providers
Sending a real request:
returned a successful response, but response headers showed
x-omniroute-provider: felo,x-omniroute-model: felo-chat— i.e.autorouted to the free "Felo" provider instead of either connected (paid) provider, silently, with no indication this would happen.Additional finding — direct model addressing resolves to unrelated third-party relays
Trying to address Google directly by ID to work around the broken dropdown:
model: "google/gemini-2.5-pro"→{"error":{"message":"No active credentials for provider: vercel-ai-gateway", ...}}model: "google/gemini-2.5-flash"→{"error":{"message":"No active credentials for provider: api-airforce", ...}}model: "gemini-2.5-pro"(no prefix) →{"error":{"message":"Ambiguous model 'gemini-2.5-pro'. Use provider/model prefix (ex: in-ai/gemini-2.5-pro or t3chat/gemini-2.5-pro)", ...}}None of the suggested/resolved prefixes (
vercel-ai-gateway,api-airforce,in-ai,t3chat) correspond to thegoogleoropenrouterconnections that were actually configured. It's unclear whether these are unrelated free-tier catalog entries that happen to share a model name, or whether the catalog is meant to disambiguate this better. Either way, there's no discoverable way to address the specific, connectedgoogle/openrouterprovider by model ID once the dashboard dropdown is broken.Expected Behavior
omniroute models <provider>should list the real models available for a successfully-tested provider connection.providers test.providers statusshould not contradictproviders list/providers test-allrun at the same point in time.autorouting should not silently prefer an unconnected free-tier provider over explicitly connected, tested, paid providers without clear documentation/control over that precedence.Also noticed (possibly related, lower priority)
CLI write operations (e.g.
omniroute compression configure --engine none) return401even with a freshly created, non-expired CLI access token (Zugriffstoken) exported asOMNIROUTE_API_KEY— tested with two separately generated tokens, same result both times. Unclear whether restricted CLI tokens are simply not permitted to write config, and if so this isn't documented anywhere I could find in the shipped npm package (thedocs/folder referenced throughout the README is not included in the npm package).