Skip to content

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

Closed

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

  1. added
    bugSomething isn't working
    catalogModel catalog, slugs, visibility, routed entries
    proxyHTTP proxy, routing, reverse-proxy / management auth
    on Aug 10, 2026
  2. added a commit that references this issue on Aug 11, 2026
    16e6342
  3. Ingwannu commented on Aug 11, 2026

    @Ingwannu
    Owner

    Confirmed against current dev: the report is valid, and the fixed 372k constants are defaults rather than the real configuration contract. providerContextCaps.openai should act as a ceiling across every native OpenAI catalog surface.

    PR #1435 is close and now handles synchronized/preserved rows and routing evidence correctly, but its current head still omits the cap on the live Codex discovery route at src/server/index.ts:914 (GET /v1/models?client_version=...). I requested that final endpoint fix plus an endpoint-level regression and a refresh onto current dev before merge.

    Keeping this issue open until the corrected exact head passes CI and is integrated into dev.

  4. added 2 commits that reference this issue on Aug 11, 2026
    73bd6d0
    7a5fafd
  5. Wibias commented on Aug 11, 2026

    @Wibias
    Contributor

    Closed by #1435

  6. added a commit that references this issue on Aug 11, 2026
    cf44362
  7. added a commit that references this issue on Sep 17, 2026
    14ec9b8
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