support LiteLLM /model/info for provider model discovery
What variant of Codex are you using?
cli
What feature would you like to see?
What problem are you trying to solve?
When using Codex with an OpenAI-compatible enterprise gateway such as LiteLLM, /v1/models only exposes model IDs. Codex can
discover the slugs, but it has to fall back to generic/static model metadata, so provider capabilities such as context window,
vision support, web search, tool calling, verbosity, and reasoning effort support are not represented accurately.
LiteLLM exposes richer per-model metadata via /model/info or /v1/model/info, including fields like mode, max_input_tokens,supports_vision, supports_web_search, supports_function_calling, supports_tool_choice, supported_openai_params, and
explicit reasoning effort flags.
Proposed solution
Add a provider model discovery format for LiteLLM, e.g.
[model_providers.example.model_discovery]
enabled = true
path = "/v1/model/info"
format = "litellm" The discovery implementation could:
- parse LiteLLM data[*].model_name / model_info.key
- filter non-chat/non-responses models such as audio transcription models
- skip blocked or inaccessible models
- map stable LiteLLM metadata into Codex model metadata:
- context window from max_input_tokens
- image modality from supports_vision
- web search from supports_web_search
- parallel tool calls from supported_openai_params
- verbosity from supported_openai_params
- reasoning efforts only from explicitly supported LiteLLM flags
Why this matters
This would make Codex work better with managed enterprise gateways where the available model set and capabilities are owned by the
gateway rather than by a static local config.
I have a small prototype branch implementing this mapping:
Prototype branch: https://github.com/mfulz/codex/tree/feat/provider-model-discovery
I would appreciate being granted permission to open a PR if this direction is aligned with the project.
Additional information
_No response_