feat(ai): add OpenRouter provider routing support

[v01dpr1mr0s3]

What this is

Following #843 , this adds support for OpenRouter provider selection as described in the issue.

What it does

These changes allow custom models to specify which upstream providers OpenRouter should route requests to via the openRouterRouting field in model definitions. Which model/provider combinations to use is completely up to you.

Why it is so incomplete

1. I wanted to keep it minimal.
2. Nobody else asked for it yet.
3. Probably nobody needs it aside from me and other secret OpenRouter provider sommeliers.
4. It's a tiny hint at how OpenRouter provider routing support could be extended in the future, if need be.

Limitations

⚠️ This is specifically designed to handle {one OR model} x {one provider} binding. No load balancing, priority selection or other OR features.

The idea is that for maintaining quality of inference and cache intact, you should stick to the single provider anyway, and routing between them is not desired.

How it works

The only introduced OpenRouter provider payload fields are:

• only: list of provider slugs to exclusively use
• order: list of provider slugs to try in order

Both of these should be used in tandem to ensure provider selection. In my testing, sometimes OpenRouter ignores the only parameter alone, but works when only and order are present.

So, the idea is that you:

• ask pi to create a custom openrouter config of your favorite model
• it will live in ~/.pi/models.json
• it will look like this:

... and the rest of the infrastructure would be handled by pi. It should correctly identify if you have OpenRouter API key for a model, it should work with /scoped-models and so on.

The only funky part of this code is the detection of a model by baseUrl and not provider, but it's intentional: it allows to create custom "virtually provided models" with openrouter-bedrock, openrouter-novita-fp8 etc labels in the UI and they all get the routing and API key pickup seamlessly.

[github-actions]

Hi @v01dpr1mr0s3, thanks for your interest in contributing!

We ask new contributors to open an issue first before submitting a PR. This helps us discuss the approach and avoid wasted effort.

Next steps:

1. Open an issue describing what you want to change and why (keep it concise, write in your human voice, AI slop will be closed)
2. Once a maintainer approves with lgtm, you'll be added to the approved contributors list
3. Then you can submit your PR

This PR will be closed automatically. See https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.md for more details.

[v01dpr1mr0s3]

Once a maintainer approves with lgtm, you'll be added to the approved contributors list

badlogic 6 hours ago
lgtm

!