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 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.5for model calls,@filearguments for uploads, and admin commands such asopenai admin:organization:usage completionsfor 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_KEYand 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(orOPENAI_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:
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.