OpenAI Just Silently Cut Codex Context by 27% — And Nobody Noticed

On 13 July, a Codex user noticed something had gone wrong with their long-running session. Their multi-file refactoring task, the kind of thing GPT-5.6 Sol was supposed to handle, had started failing with context-overflow errors where it hadn't before.

They dug into the server-delivered model catalog. What they found was not a bug.

OpenAI had reduced the raw context window from 372,000 tokens to 272,000 tokens. No announcement. No changelog entry. No documentation update. The effective usable context, after the standard 95% allocation policy, dropped from 353,400 to 258,400 tokens. That's a 26.9% cut, overnight.

The discovery landed as GitHub issue #32806 on the openai/codex repository. It collected 36 thumbs-up reactions before being marked "resolved", not because OpenAI reversed the change, but because a bot auto-closed it as a duplicate.

Four days later, on 17 July, OpenAI slipped a single line into the Codex release notes tracked by releasebot.io: "corrected their context windows to 272,000 tokens." The word they chose was "corrected." As though the previous 372K had been a mistake. As though a capacity cut of more than a quarter needs no explanation beyond a typo fix.

The mathematics of erosion

The raw numbers are bad enough. But the gap between what OpenAI advertises and what Codex actually delivers is worse.

The official GPT-5.6 Sol model page still lists a 1,050,000-token context window. At the same 95% effective rate, that should deliver roughly 997,500 usable tokens. Codex now exposes 258,400. That's 25.9% of the advertised capacity.

There's a pricing detail that makes this feel less like capacity management and more like revenue engineering. OpenAI's API pricing page states that requests above 272,000 input tokens are billed at 2× input and 1.5× output, for the entire request. Codex now caps the raw window at exactly 272,000 tokens. Users cannot access the published long-context tier through Codex even if they wanted to pay for it.

The cap sits precisely at the threshold where billing doubles. Draw your own conclusions.

"I'm spending all my tokens on resets because OpenAI won't give us a bigger window," wrote one user on the GitHub thread. "It's a waste across the board."

Is this a one-off or a playbook?

If this were isolated, it might be frustrating but forgettable. It is not isolated.

In June, Google killed Gemini CLI for consumer and individual developer accounts. Users had until 18 June to migrate or lose access entirely. The enterprise version survived; hobbyists and indie builders got cut loose.

Anthropic's Claude Code shipped an AFK auto-approve misfeature that accepted changes while developers were away from their machines. It was framed as "auto mode" but treated by many users as an unbidden security surface. The implementation was so broken it was sending the unsupported `afk-mode-2026-01-31` beta header and causing API 400 errors. When you leave your desk and your AI keeps approving pull requests, the word "feature" is doing a lot of heavy lifting.

And earlier in July, Codex itself had to ship a bundled instruction bug fix that had been silently corrupting GPT-5.6 prompts. Another change users discovered through broken behaviour rather than a changelog.

Codex-resets.com, a community tracker that monitors OpenAI's opaque usage-limit resets, has catalogued 35 resets since launch with an average interval of 8.9 days and a longest drought of 67.7 days. The site exists because there is no official schedule. There is no changelog. There is only the feed.

The pattern is hard to miss. AI providers are quietly reducing capacity while publicly marketing ever-larger numbers. The 1.05M context window exists. It's just not anywhere you can actually use it without paying API prices. Consumer and prosumer tools get the compressed version. Enterprise contracts get the real thing.

What does this actually break?

For someone writing a Python script in a weekend, 258K tokens is still a lot. That's not who this hurts.

The people getting burned are the ones using Codex for repository-scale work: multi-file refactors, large codebase migrations, long-running implementation sessions where the model needs to hold an entire architecture in its attention window. These builders start with a 353K session, plan around that capacity, and then, mid-task, the floor drops to 258K. Context compactions become frequent. The model loses track of decisions made earlier in the session. You burn tokens re-anchoring what it already understood.

Imagine you've been guiding Codex through a database migration across 40 files for two hours. The model has internalised your schema, your naming conventions, and three specific edge cases you called out at the start. Then the context fills, it compacts, and suddenly it's suggesting column names from a framework you're not even using. That's not a hallucination. That's a compaction artefact.

The compaction tax is real. Every time the context window fills, Codex has to summarise and discard earlier conversation, and every compaction introduces small losses of specificity, small distortions of intent. At 258K, you compact more often. The cumulative effect on a long session is a model that gradually forgets what you asked it to build.

Why platform-managed AI is starting to look less like a luxury and more like a hedge

Here's the thing about coding directly against an AI provider's API or desktop client: you are in a direct relationship with a company that can, and does, change the terms of that relationship without telling you.

No-code platforms that manage model selection on your behalf operate differently. When a platform negotiates context windows, model routing, and fallback behaviour, the platform shoulders the degradation risk. Not the individual builder. If Codex cuts the context window again next month, the platform's infrastructure team deals with it. The builder's app doesn't break mid-session.

This is not theoretical. Governed platforms that abstract model selection exist precisely because model behaviour is unreliable. The platform becomes the shock absorber between volatile provider APIs and the applications that depend on them.

The alternative, building directly on provider APIs and desktop clients, means you are the shock absorber. You monitor the changelogs. You read the GitHub issues. You discover the degradation when your task fails, not when someone tells you about it.

The takeaway

OpenAI cut Codex's context window by 27% and called it a "correction." The fact that builders had to discover this through server-side metadata inspection, not a changelog, not an email, not a blog post, tells you everything about who bears the risk in the current AI tooling landscape.

If you're building anything that matters, you need an intermediary between your work and the provider's whims. Whether that's a platform, an abstraction layer, or a multi-provider routing setup, the days of trusting any single AI provider's desktop client are numbered.

And if you're currently mid-session on Codex? Check your context percentage.