[Proposal]: OrcaRouter provider support for ai-cli

ai-cli is one of the few AI tools I reach for from the terminal and keep reaching for: ai image, ai video, ai audio speak|transcribe, and ai text with stdin piping, repeatable reference images, and predictable artifact output. Backing it with the Vercel AI SDK and AI Gateway is a smart call - one tiny command line opens up hundreds of models, and the -m "openai/gpt-image-1,bfl/flux-2-pro" multi-model mode turns comparisons into a one-liner that automation can build on.

That automation angle is why more model choice matters here. The CLI already accepts an AI Gateway key or a provider-specific key such as OPENAI_API_KEY, and ai models <id> surfaces per-provider latency, throughput, and uptime for the same model. Your users clearly value provider flexibility, not just model breadth. Adding one more optional, OpenAI-compatible entry point would give them a wider model selection with built-in failover, while leaving the default untouched.

Proposed change

Add OrcaRouter as an optional provider for ai-cli, following the existing provider-key pattern. It would not replace or change any current provider, key, or default model. Concretely, the CLI would recognize an ORCAROUTER_API_KEY the same way it recognizes OPENAI_API_KEY today, so OrcaRouter-hosted models become selectable through the existing -m creator/model resolution and AI_CLI_*_MODEL overrides. To be clear, this is a proposal for maintainers to evaluate; no code has been written or tested.

For ai-cli's users, three OrcaRouter capabilities seem most relevant:

• Multiple chat/reasoning/image/video models behind one endpoint, which pairs naturally with the multi-model -m comparison flow.
• Automatic model routing with provider failover, which speaks directly to the uptime/latency data already shown in ai models.
• Usage tracking with budgets, useful for scripting batch generations and seeing spend per run.

Implementation notes

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the provider/API-abstraction layer ai-cli already uses for provider-specific keys and the model catalog; no new auth scheme or SDK dependency should be required. Again, this describes where an integration would fit, not work that is already done. OrcaRouter is already present in the open-source ecosystem through integrations such as RAGFlow, Dify, goose, and promptfoo, and a gallery of projects is available at https://www.orcarouter.ai/built-with.

Disclosure

I'm an engineer on the OrcaRouter team. OrcaRouter also runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integrating, and I'm happy to follow this project's governance requirements. This issue is first and foremost a provider request. If you'd like to take it forward, I'd be glad to help prepare patches or a PR for maintainers to review, since PRs are limited to collaborators.

Start with the existing provider-specific key handling and model catalog used by ai-cli, then trace how OpenAI-compatible providers reach model resolution and AI_CLI_*_MODEL overrides. Done means OrcaRouter can be selected with ORCAROUTER_API_KEY without changing current defaults, providers, or authentication behavior, with the existing CLI flows still working.