GPT-5.5 Codex context limit dropped to 400k but uses API context limit (1M) causing "exceeds the context window of this model" errors #24171

TL;DR: Codex dropped the token limit from 1M to 400k with GPT-5.5 but OpenCode still thinks the limit is 1M, causing context window overflow issues.

Description

When OpenCode uses OpenAI OAuth / ChatGPT authentication, openai/gpt-5.5 requests are routed through the Codex backend, but the model metadata used by auto-compaction appears to come from the API model entry.

That creates a context-limit mismatch:

• OpenCode's Models.dev cache reports openai/gpt-5.5 as context: 1,050,000, input: 920,000, output: 130,000.
• OpenAI's GPT-5.5 launch post distinguishes the products:
  • "In Codex, GPT-5.5 is available ... with a 400K context window."
  • "For API developers, gpt-5.5 will soon be available ... with a 1M context window."
  • Source: https://openai.com/index/introducing-gpt-5-5/
• With OpenAI OAuth, CodexAuthPlugin rewrites OpenAI Responses requests to https://chatgpt.com/backend-api/codex/responses.
• session/overflow.ts bases the proactive compaction threshold on model.limit.input - reserved, so it waits for roughly the API-size window rather than the Codex-size window.

Observed result: a long OpenAI OAuth GPT-5.5 session reached roughly 385k reported tokens without proactive compaction, then the Codex backend returned:

{
  "type": "error",
  "sequence_number": 2,
  "error": {
    "type": "invalid_request_error",
    "code": "context_length_exceeded",
    "message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
    "param": "input"
  }
}

OpenCode then handled it reactively as context overflow and inserted overflow compaction, but the expected behavior is for auto-compaction to trigger before the provider rejects the request.

This seems related to, but more specific than:

• Auto-compaction enabled by default, but context_length_exceeded errors still occur in agent workflows #8089, generic context_length_exceeded despite auto-compaction
• [FEATURE]: support codex as a first-class provider (codex subscription rather than OpenAI api provider) #24134, first-class Codex provider support
• Codex: default vs selected variants show different effective context; support per-variant limits #12416, per-variant Codex effective context limits

Plugins

OpenAI OAuth / ChatGPT Pro/Plus auth via built-in CodexAuthPlugin. No third-party plugin is required for the relevant routing behavior.

OpenCode version

Observed on a local build based on current source with an unrelated /vcs/diff mitigation:

0.0.0-jeremy/vcs-diff-disable-flag-202604232219

Relevant source paths inspected:

• packages/opencode/src/plugin/codex.ts
• packages/opencode/src/session/overflow.ts
• packages/opencode/src/provider/models.ts
• packages/opencode/src/provider/provider.ts

Steps to reproduce

1. Authenticate OpenAI using ChatGPT/OAuth rather than an API key.
2. Use openai/gpt-5.5 in a long-running OpenCode session.
3. Let the session grow beyond ~400k effective context without manual compaction.
4. Observe that proactive auto-compaction does not trigger near the Codex limit because the model metadata says input: 920000.
5. The Codex backend can reject the request with context_length_exceeded; only then does OpenCode do reactive overflow compaction.

Expected: when OpenAI auth is OAuth and requests are rewritten to Codex, OpenCode should use the Codex effective context/input limit for overflow checks.

Possible fixes:

• Treat Codex OAuth as a distinct provider/model-limit profile.
• Override OpenAI model limits when openai auth is OAuth and requests are rewritten to the Codex endpoint.
• Or otherwise expose separate Codex model metadata so gpt-5.5 does not use the API 1M metadata while hitting the Codex backend.

Screenshot and/or share link

No share link. The issue was diagnosed from local logs and source inspection.

Operating System

Linux

Terminal

OpenCode TUI / web client