Add OpenRouter Advanced Provider Routing Support to Codex CLI

Resolved 💬 3 comments Opened Sep 18, 2025 by InduwaraSMPN Closed Jan 17, 2026

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:

  1. Provider-specific routing - Use provider.only: ["amazon-bedrock"] to route through specific providers
  2. Intelligent fallbacks - Automatic failover when providers are unavailable
  3. Cost/performance optimization - Route based on price, throughput, or latency
  4. 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:

  1. Extending the ConfigToml struct to support OpenRouter routing preferences
  2. Modifying request construction logic to include provider-specific routing parameters
  3. 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗