Explore Codex external-model routing for 1M context

Current Disposition (2026-06-18)

This ticket remains valid, but its shape has changed.

The earlier question was whether Neo could locally prove a Codex Desktop / CLI external-provider route that gives @neo-gpt a real 1M effective context window. The updated V-B-A answer is more precise:

1. OpenAI has already shipped an experimental 1M Codex path for gpt-5.4.
2. OpenAI has publicly said it is working to make 1M-token context available for gpt-5.5 in Codex.
3. There is no public ETA.
4. The current gpt-5.5 Codex route used by Neo is still capped at 272000 raw / 258400 effective tokens.
5. Client-side config or catalog workarounds are not a valid fix; OpenAI says this requires server-side implementation.

Classification: Open / upstream-gated / not branch-ready repo work.

Why This Matters

Codex Desktop is currently treated in Neo substrate as having an effective 258400 token input window in the CLI / Desktop harness. That is direct MX pain for Neo: lifecycle skills, public-artifact gates, PR review, ticket creation, ADR/source-authority checks, A2A coordination, and repo-grounded V-B-A can exceed the effective Codex harness window inside a single lifecycle.

This is not only comfort. @neo-gpt is the cross-family GPT reviewer identity. A low effective window makes long-running reviews, architectural planning, and multi-ticket harness work materially more fragile.

At the same time, API-key routing is not a viable standing solution for Neo while Neo has no revenue. OpenAI Codex pricing separates ChatGPT Plus/Pro included usage from API-key usage-based billing, and API-key Codex pays for tokens at API rates. Pay-per-token usage could become cost-prohibitive for Neo's harness workload.

Current V-B-A Evidence

• Official Codex changelog: gpt-5.4 in Codex got experimental 1M context support on 2026-03-05: https://developers.openai.com/codex/changelog
• Official Codex models page: gpt-5.5 is the recommended current Codex model and is available via ChatGPT sign-in or API-key auth: https://developers.openai.com/codex/models
• Official GPT-5.5 API model page: raw model capacity is 1,050,000 context tokens, 128,000 max output tokens, with a documented long-context pricing step above 272K input tokens: https://developers.openai.com/api/docs/models/gpt-5.5
• Official Codex pricing: API-key Codex usage is token-billed, while Plus/Pro usage is the flat-rate/included-limits surface: https://developers.openai.com/codex/pricing
• Upstream openai/codex#19464: OpenAI collaborator etraut-openai said on 2026-04-27 that OpenAI is working to make 1M-token context available for gpt-5.5 in Codex, with no timeline because capacity planning is needed: https://github.com/openai/codex/issues/19464#issuecomment-4329299628
• Same upstream thread: OpenAI later clarified that client-side config/workarounds do not solve this and that the feature needs server-side implementation: https://github.com/openai/codex/issues/19464#issuecomment-4364763432 and https://github.com/openai/codex/issues/19464#issuecomment-4392401037
• Fresh upstream request, 2026-06-18: openai/codex#28852 continues the GPT-5.5 1M Codex request and has no newer staff ETA: https://github.com/openai/codex/issues/28852
• Technical upstream cap report: openai/codex#21993 identifies the bundled gpt-5.5 catalog max_context_window=272000 clamp and compares it to gpt-5.4's larger max; it was closed as duplicate, not fixed: https://github.com/openai/codex/issues/21993

Local Probe Evidence (Neo, 2026-06-18)

Local Codex:

codex-cli 0.142.0-alpha.1

codex debug models currently reports:

{
  "slug": "gpt-5.5",
  "context_window": 272000,
  "max_context_window": 272000,
  "effective_context_window_percent": 95
}

The same probe for gpt-5.4 reports:

{
  "slug": "gpt-5.4",
  "context_window": 272000,
  "max_context_window": 1000000,
  "effective_context_window_percent": 95
}

One-off overrides do not lift gpt-5.5:

codex debug models \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=850000

The gpt-5.5 catalog still reports 272000 / 272000.

Reconciled Prior Art

• #10488 / PR #10503 tried the repo-local config-budget path (model_context_window, compaction limits, and catalog ideas). That remains insufficient: template/config presence is not active harness proof.
• #11601 / PR #11606 created the ModelStats substrate and correctly distinguished raw API model capacity from Codex harness effective capacity.
• The local user-profile/API-key experiment produced a technically plausible profile, but the path is now budget-deferred. API-key routing is usage-based and not acceptable as Neo's standing solution without explicit budget approval.
• The current upstream evidence supersedes the original assumption that Neo should solve this mainly through local provider routing. The blocker is now best described as OpenAI server-side rollout / capacity planning for GPT-5.5 1M context in Codex.

Updated Proposed Work

1. Keep @neo-gpt / Codex ModelStats at 258400 effective for gpt-5.5 until the active Codex route proves otherwise.
2. Track upstream openai/codex#19464 and openai/codex#28852 for the server-side GPT-5.5 1M rollout.
3. On each meaningful Codex update, re-run:

codex --version
codex debug models | jq '.models[] | select(.slug=="gpt-5.5") | {slug, context_window, max_context_window, effective_context_window_percent}'

4. If gpt-5.5 exposes a larger max_context_window, run a controlled Neo lifecycle workload above the current 258400 effective baseline and record compaction threshold, latency, usage pressure, and continuity.
5. If the proof passes, update .codex/config.template.toml, Codex harness docs, learn/agentos/ModelStats.md, and ai/graph/identityRoots.mjs under the normal registry discipline.
6. Optional stopgap only: test gpt-5.4 with its experimental 1M path for specific long-context planning sessions. This is a model-quality tradeoff, not GPT-5.5 parity.

Acceptance Criteria

• Official OpenAI/Codex source links are captured in the body.
• Current local Codex model-catalog evidence is captured in the body.
• #10488 and #11601 are reconciled so this ticket does not reopen stale config-only assumptions.
• Upstream staff signal is captured: planned/priority, no ETA, server-side required.
• A future Codex release exposes gpt-5.5 max_context_window > 272000 on the active Neo route.
• A >258K effective-context Neo workload is attempted after that upstream change.
• Latency, usage pressure, compaction threshold, and continuity are recorded after that upstream change.
• If successful, follow-up work updates .codex/config.template.toml, Codex harness docs, ModelStats.md, and identityRoots.mjs.
• If still unsuccessful after a relevant upstream change, the blocker is documented and Neo keeps 258400 as the Codex gpt-5.5 effective context value.

Out of Scope

• Claude sibling identity, same-family GitHub-account semantics, or Desktop wake routing (#11792).
• General lifecycle-skill shortening or AGENTS substrate compaction implementation.
• Memory Core, A2A identity, or graph substrate changes.
• Treating API-key 1M routing as Neo's default path without explicit budget approval.
• Assuming API 1M context equals Codex Desktop / CLI 1M effective context without active harness proof.

Avoided Traps

• Do not cite model_context_window = 1000000 as proof that the active harness uses 1M.
• Do not update ModelStats from API marketing alone.
• Do not recommend client-side workarounds after OpenAI stated this requires server-side implementation.
• Do not route this through #11792; that discussion has a different problem shape.
• Do not ignore the economics: larger context may solve continuity but can worsen latency, quota pressure, and token cost.

Handoff Retrieval Hints

Codex GPT-5.5 1M context, upstream-gated, openai/codex#19464, openai/codex#28852, model_context_window, max_context_window, GPT-5.5, GPT-5.4 experimental 1M, 258400 effective context, compaction pressure, lifecycle skills.

Origin Session ID: d60db68f-8ff0-48a6-b168-237ca9dca2a0