OrcaRouter provider support for the OpenAI CLI (optional OpenAI-compatible backend)

The OpenAI CLI is the official command line for the OpenAI REST API. Its resource-based command structure turns API work into typed, scriptable commands - openai responses create --model gpt-5.5 for model calls, @file arguments for uploads, and admin commands such as openai admin:organization:usage completions for usage reporting. For developers and platform admins who automate OpenAI from the terminal, this makes repeatable workflows far more maintainable than hand-rolled curl scripts.

Because the CLI keeps transport configuration separate from its commands - an API key via --api-key/OPENAI_API_KEY and a backend via --base-url/OPENAI_BASE_URL - it can already talk to any OpenAI-compatible endpoint. That is the natural place an optional provider would give its users a useful new choice.

Proposal

I'd like to propose OrcaRouter as an optional provider for the OpenAI CLI - concretely, an OpenAI-compatible backend that requires no change to the CLI's request semantics. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so a user would point --base-url (or OPENAI_BASE_URL) at OrcaRouter and set their OrcaRouter API key, and the existing command set would work unchanged. This would not replace or alter the current OpenAI endpoint path in any way; it would simply be an additional option for teams that want it.

For the CLI's users, the OrcaRouter capabilities that seem most relevant are:

• One OpenAI-compatible endpoint in front of multiple chat, reasoning, image, and video models, so a team standardized on this CLI can reach models beyond a single vendor without juggling separate CLIs or base URLs.
• Automatic model routing and provider failover, which makes unattended scripts and scheduled jobs more resilient when one upstream provider degrades.
• Usage tracking and budgets, complementing the CLI's admin usage commands with per-key spend visibility across every model a request routes to.

OrcaRouter is already used in the open-source ecosystem - projects such as promptfoo, goose, and models.dev / OpenCode integrate with it - and more examples are on our built-with page.

Transparency

I'm an engineer on the OrcaRouter team. We run an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Joining that program is not a condition for integration, and I'm glad to comply with whatever disclosure or governance rules this project prefers.

If maintainers see value in this, I'd welcome feedback on the approach above - and on approval I'd be happy to open an implementation PR.

The issue names no files, tests, or implementation entry points; start by determining whether provider support belongs in the CLI scope and what approval or integration requirements apply. Done is not defined beyond maintainer approval of an optional OrcaRouter backend, so implementation details and acceptance tests remain to be specified.