Skip to content

providerContextCaps.openai is ignored for native GPT-5.6 catalog rows #1430

Description

@mkarolczyk

Client or integration

Codex App

Area

Catalog / models

Summary

The supported per-provider context cap is persisted and reported as active for openai, but native GPT-5.6 catalog rows ignore it.

On OpenCodex 2.12.0, both contextCapValue and providerContextCaps.openai are set to 272000. After restarting the managed proxy and running a full opencodex sync, GPT-5.6 Sol, Terra, and Luna are still generated with a 372,000-token context window and a 334,800-token auto-compaction threshold.

I expected the enabled OpenAI provider cap to constrain native GPT-5.6 models to 272,000 tokens, with auto-compaction at 244,800.

This is intentionally narrower than #1051: regardless of whether 372k is the desired default, the documented/configurable provider cap currently has no effect on the native GPT-5.6 overrides.

Reproduction

  1. Install or update to OpenCodex 2.12.0.
  2. Configure the global and OpenAI provider caps:
{
  "contextCapValue": 272000,
  "providerContextCaps": {
    "openai": 272000
  }
}

The same result occurs when the OpenAI cap is enabled through the management API. Readback confirms providerContextCaps.openai = 272000 and the API reports the cap without degraded mode.

  1. Restart the managed OpenCodex service so the installed version is active.
  2. Run a full sync:
opencodex sync
  1. Verify the persisted configuration:
jq '{contextCapValue, providerContextCaps: {openai: .providerContextCaps.openai}}' \
  ~/.opencodex/config.json

Result:

{
  "contextCapValue": 272000,
  "providerContextCaps": {
    "openai": 272000
  }
}
  1. Inspect the generated catalog or runtime model metadata:
codex debug models | jq -r '
  .models[]
  | select(.slug | test("^gpt-5\\.6-(sol|terra|luna)$"))
  | [.slug, .context_window, .max_context_window, .auto_compact_token_limit]
  | @tsv
'

Actual result:

gpt-5.6-sol    372000    372000    334800
gpt-5.6-terra  372000    372000    334800
gpt-5.6-luna   372000    372000    334800

Expected result while the OpenAI provider cap is enabled:

gpt-5.6-sol    272000    272000    244800
gpt-5.6-terra  272000    272000    244800
gpt-5.6-luna   272000    272000    244800

The proxy is healthy and opencodex doctor confirms that the Codex app-server catalog is current with the on-disk catalog, which rules out a stale proxy or stale model cache.

Suspected cause

The native GPT-5.6 rows appear to bypass the configured provider cap because two source-level overrides remain fixed at 372,000:

src/codex/catalog/metadata.ts
NATIVE_GPT56_CONTEXT_WINDOW = 372_000

src/providers/registry.ts
OPENAI_CODEX_GPT56_CONTEXT_WINDOW = 372_000

Changing only those two values to 272_000, restarting the managed service, and running opencodex sync immediately produces the expected 272000 / 272000 / 244800 values for Sol, Terra, and Luna. Spark remains unchanged at 100000 / 100000 / 90000, confirming that the failure is scoped to the native GPT-5.6 override path.

Suggested behavior

When providerContextCaps.openai is enabled, apply it as a ceiling to native OpenAI catalog rows as well as routed/provider-discovered models. The 372k native value can remain the default when no custom cap is enabled.

Related reports:

Version

2.12.0

Operating system

macOS 27.0 (26A5388g), arm64

Provider and model

OpenAI (Codex login) / gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna

Logs or error output

gpt-5.6-sol    372000    372000    334800
gpt-5.6-terra  372000    372000    334800
gpt-5.6-luna   372000    372000    334800

Screenshots and supporting files

Redacted configuration

{
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "codexAccountMode": "pool",
      "authMode": "forward"
    }
  },
  "contextCapValue": 272000,
  "providerContextCaps": {
    "openai": 272000
  }
}

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcatalogModel catalog, slugs, visibility, routed entriesproxyHTTP proxy, routing, reverse-proxy / management auth

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions