GPT-5.6 Sol was supposed to make Codex competitive with Claude Code on long-running tasks. The model page still says 1,050,000 tokens of context. Paying subscribers get 258,400.

Context window comparison: GPT-5.6 Sol advertised vs actual Codex caps

The gap between what OpenAI advertises and what Codex users actually see has been a quiet frustration for months. But a server-side configuration change on July 13 turned that gap into a canyon. The Codex model catalog for GPT-5.6 Sol now exposes a context window of 272,000 raw tokens. After the standard 5% compaction reserve, the effective runtime window is 258,400 tokens. That is 24.6% of the published 1.05 million specification.

This is not the first cut. When GPT-5.6 Sol launched, Issue #31860 on the OpenAI Codex repository documented that the model was already catalog-capped at 372,000 raw tokens, yielding 353,400 effective. Users who had been hoping for anything close to the advertised 1.05M saw roughly a third of it. Now they see a quarter.

The server-side change

The regression was caught by a Codex user who noticed their session metadata had changed. The previous server-delivered catalog returned context_window: 372000 for GPT-5.6 Sol. After July 13, the same endpoint returned context_window: 272000. No announcement. No changelog entry. No explanation in the client. The effective window dropped from 353,400 to 258,400 — a 26.9% reduction.

The GitHub issue filed on July 13 (opencid #32806) is titled with a siren emoji and the words "SEVERE REGRESSION." The author laid out the math carefully. At the published 1.05M specification with the same 95% effective-window policy, Codex users should see approximately 997,500 usable tokens. Instead they get 258,400. That is 25.9% of the comparable effective capacity of the advertised model.

A response came indirectly. On X, user @kimmonismus posted that "GPT-5.6's context window has been reduced to 272k tokens, subagents are being adjusted, and other changes are being made, so the burn rate should decrease significantly."

OpenAI's official account replied: "Updates for Codex and ChatGPT Work users. No nerfing, only good stuff! We have landed inference optimizations and are passing down savings to all the subscriptions for GPT-5.6 Sol. That should result in around 10% more usage on its own."

The framing is telling. OpenAI describes a 26.9% context reduction as "inference optimizations" and frames the resulting cost savings as benefiting users. But the benefit only materializes if users were saturating their old 353K window. Anyone working on repository-scale code is now hitting the compaction wall 27% sooner, with auto-compaction errors breaking long-running sessions.

The Claude Code comparison

This is where the numbers get uncomfortable for OpenAI. Anthropic's Claude Code ships Claude Opus with a full 1 million token context window included in the subscription. No server-side catalog cap. No silent reduction. When Claude Code users migrated to Codex hoping for similar capacity, they found themselves staring at 258K after expecting 1.05M.

Reddit threads on r/codex tell the story. One user wrote: "I tried using GPT-5.6 Sol today, and it is only giving me a context window of about 270K. With the Claude models I was getting 1M." Another: "I came from Claude Code where you get the 1M model in the subscription. So just making sure how OpenAI does things."

The response from the community: you do not get 1M in Codex. You never did. The model has the capacity, but the product caps it.

The pattern

This is not a one-time event. GPT-5.5 followed the exact same arc. OpenAI's model page advertised 1,050,000 tokens. Inside Codex, the effective window was 258,000 , the same number users see today on GPT-5.6 Sol. At no point did OpenAI document this discrepancy. Users discovered it by watching their session metadata.

The mechanism is straightforward. Codex maintains a server-side model catalog that maps model names to capability parameters including context_window. This catalog is versioned and deployed independently of the model itself. Users querying the GPT-5.6 Sol API directly can access the full 1.05M context. Users inside Codex cannot, because the Codex catalog overrides the model's native capacity.

The question nobody at OpenAI has answered is why. The GitHub issue asks directly: "If the model supports 1.05M, why does Codex cap it at 272K?" The best explanation is cost. Larger context windows consume more KV cache memory and increase inference latency. By capping Codex sessions at 272K raw tokens, OpenAI reduces its compute cost per session. The economics of running a coding agent at scale apparently do not support the advertised context window.

What it means

There is nothing wrong with OpenAI managing its infrastructure costs. What is wrong is advertising a 1.05 million token model and silently delivering 258,000 tokens to the people paying for it. The catalog change on July 13 was not communicated because communication would force a conversation about why the cap exists and whether users should pay less for a quarter of the product.

The broader lesson is straightforward: advertised context windows for coding agents are marketing numbers, not product specs. Until labs ship the full model capacity inside their tools, the number on the model card is aspirational. What you actually get is whatever the server-side catalog says you get.

Sources