Feature: add a separate OpenAI Codex provider for OAuth-specific model limits #3183

Activity

1. github-actions commented on Jul 10, 2026

   

   github-actionsBot

   on Jul 10, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue needs maintainer review, and no automated fix was opened.

   This is a feature/architectural proposal rather than a concrete catalog data fix. The core ask is to create a new provider entity (openai-codex) to represent a distinct serving surface, and the issue itself explicitly defers the design to maintainer preference ("The exact provider ID and integration metadata can follow maintainer preference"). Specifically:

   1. New provider creation is a blocker-level change. Per AGENTS.md, every new provider must ship a compliant providers/<id>/logo.svg, and adding a provider is a structural decision that warrants maintainer sign-off — not something to auto-generate.
   2. It's a policy/product discussion. Whether Codex OAuth warrants a separate provider versus another representation (e.g., a documented limit override mechanism) is a design call, not a factual correction to existing metadata.
   3. The cited limits are not from authoritative provider documentation. The values come from OpenCode's codex debug models CLI output and OpenCode's internal override history, not from OpenAI's first-party API docs or pricing/model pages. They reflect one client's handling rather than a provider-published catalog I can independently verify.

   If a maintainer decides to proceed with a separate openai-codex provider, the follow-up work (provider TOML + logo + base_model-backed model entries with overridden [limit] blocks) would be actionable, but it should be scoped after that decision.
2. nabilfreeman commented on Jul 10, 2026

   

   nabilfreeman

   on Jul 10, 2026

   ContributorAuthor

   More actions

   @rekram1-node I'd like to hear your thoughts on this. You worked on both the previous GPT-5.5 Codex limit handling and the GPT-5.6 models in models.dev, so your perspective on whether a separate Codex provider is the right long-term approach would be especially useful.
3. timrichardson commented on Jul 13, 2026

   

   timrichardson

   on Jul 13, 2026

   Sponsor

   More actions

   openai changes the context limits at will to address token consumption problems it seems. Getting this wrong causes grief in opencode if using the plans
4. jimsimon commented on Aug 6, 2026

   

   jimsimon

   on Aug 6, 2026

   Last edited by jimsimon

   More actions

   I believe this would also allow harnesses that leverage codex (CLI or OAuth) to list "Ultra" as a reasoning_option for models that support it
5. ngvoicu commented on Nov 9, 2026

   

   ngvoicu

   on Nov 9, 2026

   More actions

   Draft implementation: #13161 (openai-codex, GPT-6.1 Sol and Terra, v2_only, so v1 is unchanged).

   One data point on limits: the 372K/500K values are Codex's client settings (context_window / max_context_window in the Codex model catalog: 500K / 872K for GPT-6.1). The backend itself accepts the API's 922K input on a ChatGPT plan:

   • gpt-6.1-sol: 921,807 accepted, 921,957 rejected (context_too_large);
   • gpt-6.1-terra: 920,870 accepted, 921,875 rejected.

   So the PR keeps the API limits; a working-window default looks like a client setting rather than the model's limit. Happy to change that if you see it differently.
6. ngvoicu

   added 4 commits that reference this issue on Nov 10, 2026

   feat(openai-codex): ChatGPT plan through Codex (proposal for anomalyc…

   ...

   d6d0eab

   feat(openai-codex): ChatGPT plan through Codex (proposal for anomalyc…

   ...

   66464c2

   feat(openai-codex): ChatGPT plan through Codex (proposal for anomalyc…

   ...

   6caaae0

   feat(openai-codex): ChatGPT plan through Codex (proposal for anomalyc…

   ...

   50a6284