Support opt-in provider manifests for custom model catalogs

Open 💬 0 comments Opened Jul 22, 2026 by sergio-oai

Custom Responses providers currently inherit Codex's bundled OpenAI model catalog. This can show models the provider cannot serve and expose service tiers such as /fast that the provider rejects.

This is especially painful for self-hosted or air-gapped deployments, because users need both a custom config.toml and a separately distributed static model catalog.

Proposal: add an optional provider_manifest_path setting:

[model_providers.venado]
provider_manifest_path = "codex/provider-manifest"

When configured, Codex would fetch a same-origin, versioned manifest using the provider's existing auth, headers, and query params. The manifest would only contain safe model metadata: model IDs, display names, context limits, reasoning levels, and service tiers.

The feature would be fully opt-in. Providers without provider_manifest_path would keep the current /models, bundled catalog, cache, and /fast behavior.

Would this be an acceptable direction for custom providers? If so, would the Codex team be open to reviewing an implementation PR?

View original on GitHub ↗