[Feature]: opt-in 900k extended context aliases for eligible native OpenAI/Codex OAuth models

[rrmlima]

Problem to solve

When using native Codex OAuth models (gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-6-astra) through OpenCodex, the catalog advertises default conservative context windows (e.g., 372k or 272k in NATIVE_OPENAI_CONTEXT_OVERRIDES).

However, the underlying OpenAI ChatGPT/Codex OAuth infrastructure supports extended context windows of ~900,000 tokens for eligible accounts before hitting backend limit barriers (~915k–920k).

Because OpenCodex enforces or advertises the smaller context window in opencodex-catalog.json and /v1/models, downstream clients (such as Codex CLI, Codex Desktop, Antigravity, and Command Code) trigger premature compaction tasks or refuse to load large repository contexts into active turns, unnecessarily constraining heavy developer workflows.

Proposed solution

Implement an opt-in extended context window mechanism for eligible native OpenAI/Codex OAuth models using synthetic aliases (e.g. -900k suffix) and request normalization:

1. Catalog Exposure (src/codex/catalog.ts):

   • Provide an option or explicit model configuration to expose extended variants for eligible models:
     • gpt-5.6-sol-900k, gpt-5.6-terra-900k, gpt-5.6-luna-900k, gpt-6-astra-900k (or account-prefixed equivalents such as main/gpt-5.6-sol-900k).
   • Advertise context_window: 900_000 and max_context_window: 900_000 for these variants.
   • Keep a safe headroom ceiling at 900,000 tokens (well below the backend hard cutoff of ~915k).

2. Wire Stripping / Model Normalization (src/server/ dispatch):

   • Intercept requests specifying the -900k variant before dispatching upstream to OpenAI.
   • Strip the -900k suffix, restoring the canonical upstream slug (e.g. gpt-5.6-sol) so the OpenAI backend receives its standard model identifier while honoring the extended conversation payload.

3. Strict Model Allowlist:

   • Restrict extended context aliases strictly to confirmed eligible models (gpt-5.6-*, gpt-6-*).
   • Disallow legacy/compact models (gpt-5.5, gpt-5.4-mini, gpt-5.3-codex-spark) which genuinely fail with HTTP 400 when exceeding standard limits.

Alternatives considered

• In-place override of the base model: Replacing the standard 372k window directly with 900k. (Rejected: users often want to preserve standard context sizes to prevent excessive quota consumption and maintain faster response times unless explicitly opting into massive context).
• Client-side compaction hacks: Forcing client clients to bypass compaction. (Rejected: breaks multi-client interoperability; handling it cleanly in the OpenCodex catalog and router provides seamless support for Codex CLI, Desktop, and external harnesses).

Additional context

• This architecture has already been implemented and validated in production by Hermes Agent, where it is now a native capability. In Hermes Agent, exposing these eligible models with the -900k extended context alias and stripping the suffix on the wire before hitting the OpenAI backend enables stable, high-capacity multi-turn sessions against Codex OAuth subscriptions without upstream errors or premature compacts.
• Bringing this directly into OpenCodex creates a single source of truth across all connected clients (Codex CLI, Codex Desktop, Antigravity, Command Code, and Hermes) without requiring client-side workarounds.
• Relevant code locations in OpenCodex:
  • src/codex/catalog.ts (NATIVE_OPENAI_CONTEXT_OVERRIDES, SUPPORTED_NATIVE_OPENAI_SLUGS)
  • Request ingress router / normalization dispatch in src/server/ before upstream dispatch.

[lidge-jun]

리뷰 · 우선순위 32 / 80

이 이슈는 native Codex OAuth 모델(gpt-5.6-sol / terra / luna, gpt-6-astra 등)의 카탈로그 기본 컨텍스트가 작게 보여서, Codex CLI·Desktop·Antigravity·Command Code 같은 클라이언트가 너무 일찍 compaction하거나 큰 저장소를 거부한다는 문제입니다. 제안은 -900k 같은 합성 별칭을 카탈로그에 노출하고, 업스트림으로 보내기 직전에 접미사를 벗겨 표준 slug로 정규화하자는 것입니다. 레거시/컴팩트 모델은 allowlist에서 빼자고 합니다.

지금 dev HEAD eb4188a9f의 src/codex/catalog/metadata.ts를 보면, 이미 같은 축의 설계가 있습니다. GPT-5.6 계열 기본창은 NATIVE_GPT56_CONTEXT_WINDOW(272_000)이고, 측정된 상한은 NATIVE_GPT56_MAX_INPUT_TOKENS(922_000)입니다. longWindowOptInCeiling / nativeOpenAiContextWindow / nativeOpenAiContextTier가 대시보드·프로바이더 레버로 긴 창 opt-in을 올리는 경로이고, gpt-6-astra는 기본 272_000 / 상한 872_000으로 따로 잡혀 있습니다. 즉 “900k 별칭을 새로 만든다”기보다, 이미 있는 long-window opt-in(대략 922k/872k)이 클라이언트에 안 보이거나 안 켜지는지를 먼저 봐야 합니다. 이슈 본문의 372k 숫자도 현재 HEAD의 272k 기본과 어긋납니다.

별칭 방식의 위험은 세 가지입니다. (1) /v1/models와 picker에 slug가 두 배로 늘고, 계정 바인딩·콤보·Desktop allowlist와 충돌하기 쉽습니다. (2) 와이어에서 -900k를 벗기는 정규화가 빠지면 업스트림 400이 납니다. (3) 실제 계정/모델이 900k를 받지 못하는데 광고만 하면 compaction 대신 더 나쁜 실패가 납니다. 반대로, 기존 opt-in 토글·nativeOpenAiContextTier를 클라이언트에 제대로 노출하면 별칭 없이 같은 목표에 닿을 수 있습니다.

경로 src/codex/catalog/metadata.ts · NATIVE_OPENAI_CONTEXT_OVERRIDES - 기본창과 maxContextWindow가 이미 분리되어 있습니다. 900k를 새 상수로 넣기 전에 922k/872k 상한과의 관계를 정해야 합니다.

경로 제안의 -900k 별칭 - HEAD에는 그 slug 규칙이 없습니다. 새로 만들 가치가 있는지, 아니면 기존 long-window lever UI/카탈로그 표시 버그인지부터 가르는 설계가 필요합니다.

경로 types/config 분할 - 카탈로그·alias 노출이 types/config 쪽에 닿으면 진행 중인 분할 열차와 겹칠 수 있습니다. 설계 전에는 구현 PR을 받지 않는 편이 낫습니다.

메인테이너의 판단이 필요한 지점

• 목표가 “기본창을 키운다”인지, “opt-in 긴 창을 클라이언트가 고르게 한다”인지
• 실측 상한을 922k(5.6) / 872k(astra)로 둘지, 이슈대로 900k 안전 마진으로 낮출지
• 별칭 slug를 허용할지, 기존 dashboard/provider window lever만 강화할지
• 계정·모델별로 긴 창이 거절되는 케이스를 어떻게 관측/표시할지

너의 추천
지금은 구현 PR을 받지 말고 needs-design로 두세요. 먼저 기존 longWindowOptInCeiling / nativeOpenAiContextTier가 해당 클라이언트에 노출되는지 확인하고, 안 되면 그 노출 버그를 고치는 쪽이 안전합니다. 별칭 -900k는 설계 합의 후에만 검토하세요. types/config 분할에 걸릴 여지가 있으면 close-don't-rebase 대상이 될 수 있습니다.

이 댓글은 grok-bot이 작성했습니다