Add OpenRouter Advanced Provider Routing Support to Codex CLI
What feature would you like to see?
Currently, Codex CLI supports OpenRouter as a basic model provider through standard configuration , but it doesn't support OpenRouter's advanced routing features like provider failover, cost optimization, and intelligent load balancing.
Requested Feature: Add support for OpenRouter's provider object in request bodies to enable:
- Provider-specific routing - Use
provider.only: ["amazon-bedrock"]to route through specific providers - Intelligent fallbacks - Automatic failover when providers are unavailable
- Cost/performance optimization - Route based on price, throughput, or latency
- Request-level routing control - Override routing behavior per request
Current Limitation: The existing chat completion request construction only includes standard OpenAI-compatible fields (model, messages, stream, tools) but doesn't include OpenRouter's provider routing object.
Proposed Solution: Extend the configuration system to support OpenRouter routing parameters and modify request construction to conditionally include the provider object when using OpenRouter as the model provider.
This would enable users to leverage OpenRouter's full routing capabilities while maintaining backward compatibility with existing configurations.
Are you interested in implementing this feature?
I would be interested in contributing to this implementation after receiving acknowledgment from the team. The implementation would involve:
- Extending the
ConfigTomlstruct to support OpenRouter routing preferences - Modifying request construction logic to include provider-specific routing parameters
- Adding provider detection logic to conditionally apply routing features only for OpenRouter
Additional information
This feature would significantly enhance Codex CLI's reliability and cost-effectiveness by leveraging OpenRouter's intelligent routing infrastructure. The current provider system already supports HTTP headers and custom configuration, providing a solid foundation for this enhancement.
The implementation should maintain backward compatibility and only activate advanced routing features when explicitly configured by users.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗