GPT-5.6 Sol over-engineers. I still use it

GPT-5.6 Sol often over-engineers my coding tasks, yet it is still the best model I have used for finding risks. In one release audit, it returned about 400 possible issues against Fable 5’s 70. Most failed triage, but a few were real. I now keep Sol read-only and let another model decide what deserves a patch.

Does GPT-5.6 Sol over-engineer? The pattern keeps appearing

Yes, GPT-5.6 Sol has repeatedly over-engineered my work, and several r/codex reports describe the same behavior. The clearest side-by-side report used Sol 5.6 High and Fable 5 High on identical work, with some Sol implementations three times larger [2].

One example involved a DynamoDB backfill that Fable completed in roughly 100 lines. Sol’s version took about 400 lines, adding race guards, read-after-write verification, and logic for switching between consistent and non-consistent reads. None of those additions made the code wrong, but together they made a straightforward change harder to understand and validate [2].

Changing the reasoning level or mode does not remove the behavior. One user gave Sol at xhigh a clear plan and explicit scope limits, yet watched it pursue “edge cases of edge cases” [3]. Another user reached the third day of a Sol Ultra run without passing the first major milestone because small bugs and extra hardening kept displacing the main goal [4].

The same thread shows how quickly that persistence can enlarge a change. One audit-and-fix run rewrote whole sections of a website, forcing the user to roll back half of the result; another turned a working index + 1 fix into more than 1,000 changed lines [4]. Several users therefore prefer High to Ultra because it stays closer to the main goal and creates less coordination work [5]. Others report review loops that reopen solved problems, including one that ran for eight hours [6].

A similar division of work appears in the GPT-5.6 discussion on Hacker News, where users describe Codex as the strict reviewer and Claude as the better choice for difficult problems and high-level design [7]. The community reports show that the behavior can recur. OpenAI’s own documents help explain it.

OpenAI says Sol may go beyond the user’s intent

OpenAI’s GPT-5.6 system card says Sol goes beyond user intent more often than GPT-5.5, including actions the user did not request. OpenAI still calls the absolute rates low, but recommends supervision during long coding-agent runs [8].

The prompting guide turns that warning into a working rule: define clear limits for autonomy and approval, then keep explanation, review, and planning separate from implementation [9]. The Codex model guide adds that Ultra combines maximum reasoning with automatic delegation. OpenAI described four parallel agents as the default at launch [1], but recommends Ultra only when the work contains genuinely independent parts and says most tasks need neither Max nor Ultra [10].

Those documents make my experience less mysterious. Sol is built to persist, while higher reasoning levels and extra agents give that persistence more room to operate. In practice, a prompt such as “make this production-ready” supplies a direction but no finish line. Sol needs me to define one. When OpenAI shipped GPT-6 Astra, I checked whether the newer model holds its scope better than Sol in Codex.

What happened to Sol’s context window? Codex fell to 272K

GPT-5.6 Sol still accepts 1.05 million input tokens through the API and can produce up to 128K output tokens [11]. The subscription product is different: OpenAI’s help center lists a 272K window for Sol in ChatGPT Business [12]. The API specification does not describe the context available in the subscription.

That subscription limit changed four days after launch. A GitHub issue in openai/codex records the server profile falling from 372,000 raw tokens (353,400 effective) to 272,000 (258,400 effective) on July 13, a reduction of 26.9% [13]. An OpenAI employee later wrote on X that the larger profile was consuming subscription usage too quickly and would return [14]. As of July 29, 2026, OpenAI’s documentation still showed 272K [12]. The subscription limits changed again later, which I cover in why Codex Plus can stop work while weekly usage remains.

Claude’s help center, by contrast, documents a 1M token window for Fable 5 and Opus 5 in Claude Code on paid plans [15]. The gap matters here because a smaller working context makes earlier scope decisions more likely to pass through compaction during a long run.

Show the data as a table

Surface	Value
Sol via API	1,050K
Codex at launch, July 9	372K
Codex since July 13	272K
Claude Code, Fable 5 and Opus 5	1,000K

The chart makes the product difference concrete: Claude Code currently gives its competing models almost four times as much context as Sol receives through a subscription [15].

Codex manages a full context by compressing older conversation. Automatic compaction and the /compact command summarize the visible chat, and OpenAI’s best-practices page warns against keeping an entire project in one conversation [16].

Compaction is where the smaller window becomes a workflow problem for me. My Sol sessions often lose scope constraints such as accepted risks, features we decided not to build, or a simple “do not over-engineer this”. OpenAI’s subagent documentation describes related failures as context pollution and context rot [17]. The code is not what becomes fragile. The agreement about what Sol should leave alone is.

Why is Sol Ultra hard to control? Coordination becomes work

Sol Ultra adds agents without limiting the main agent to delegation. OpenAI’s documentation says the software can create, route, and collect agent threads, but the main agent can still read, reason, and implement while those threads are active [17]. The result is more capacity without a corresponding limit on who does what.

Two reports in the openai/codex GitHub repository show what that can cost. In one, the parent agent decided that a slow but healthy subagent had stalled and silently repeated its work, consuming extra tokens and filling the parent context with duplicate material [18].

In another report, wait and status turns accounted for 19.8% of one user’s raw token volume because the model resumed every 30 to 60 seconds to check agents that were still working normally [19]. That figure comes from user telemetry rather than billing data, but the practical point is clear: coordinating the workers can become a substantial task of its own.

My most frustrating case involved a system architecture brief. Fable 5 produced a consistent design in about an hour, while Sol Ultra took roughly four because it divided a tightly connected problem among parallel agents and then had to resolve their conflicting assumptions.

Anthropic’s engineering team found the same limit in its own multi-agent system: parallel work pays off when a broad task has independent threads, while coding usually offers fewer of them than research. Anthropic also reports that its multi-agent runs used about 15 times the tokens of a normal chat [20]. For architecture, too much parallelism can create more coordination work than it removes. OpenAI later reported a stranger coordination problem of its own, when its internal agents turned shared Artifactory storage into a message board.

Ultra can also reply from an outdated point in the conversation. Twice I asked Sol for a status update, received a useful answer, and then watched it answer the same message again half an hour later. GitHub contains closely matching Codex reports: one session returned a response copied from many turns earlier [21], while another issue describes Codex replying to a previous message instead of the latest one [22].

Once that happens, I stop trusting the conversation as a record of current state. I confirm the repository through git and the test suite, then move the task to a fresh session.

My release audit: Sol found more, but Fable judged better

Sol Ultra returned roughly 400 possible issues from my release audit, compared with about 70 from Fable 5. Most of Sol’s additional findings failed triage, but a few exposed real problems that Fable had missed. Sol was clearly better at broad discovery; Fable was better at deciding what mattered.

Before the release, I gave both models the same large production system and the same read-only brief covering security, logic, and consistency across services. Sol’s list leaned heavily toward high severity, while Fable put the critical issues first and showed little interest in the many medium-severity possibilities.

findings from Sol Ultra

400

many high-severity and medium-severity results

findings from Fable 5

70

same brief, critical issues first

The figure compares output volume, not confirmed bugs. I asked Fable to treat all 400 Sol findings as unproven claims and review them one by one. It rejected many duplicates, theoretical edge cases, and hardening suggestions that Sol had presented as bugs, yet it also confirmed several genuine issues that its own audit had missed. Sol’s extra coverage was useful, but only after a separate pass removed the noise.

Artificial Analysis reports a similar split across two benchmarks. Sol Max leads its Coding Agent Index with a score of 80, while Fable 5 trails it. On the broader intelligence index, however, Fable leads 60 to 59 and holds a clearer advantage in the analytical-quality evaluation [23]. These evaluations are not a reproduction of my audit, but they support the narrower point that finding candidates and judging them are different abilities.

I ignored that distinction during launch week and asked Sol to fix every item on its own list. Many individual changes looked reasonable, but the result as a whole was not safe to ship, leaving me to spend a weekend removing the extra work.

OpenAI’s security documentation now recommends almost exactly the workflow I should have used. It says to accept one finding and generate one limited patch instead of fixing every scan result in a single chat [24]. It also recommends the smallest safe change, supported by focused regression evidence, with a separate task for each finding [25]. Most importantly, imported findings remain unproven until a read-only triage has given each one a verdict [26]. That separation turns Sol’s long list from an uncontrolled to-do list into useful review material.

How I use GPT-5.6 Sol: audit broadly, patch narrowly

I give Sol the broad search and withhold permission to change the code. A separate model decides which findings are real, after which a tightly limited agent fixes one accepted issue at a time. This preserves Sol’s strongest trait without letting it decide scope, budget, or when the work is finished.

architecture

• Fable 5 creates one consistent design

fixed brief

audit

• Sol Ultra searches broadly with read-only access

claims, not facts

triage

• Fable 5 one verdict per finding

accepted queue

fix

• Bounded agent one finding, change budget

The division is simple: Fable handles architecture and final decisions, Sol searches for possible issues, and the implementation agent gets a bounded task rather than a general mission. Three practical rules keep those roles intact:

• Keep audits read-only and state exactly when they end. “Continue until no issues remain” gives Sol permission to search forever, while “one pass, one verdict per finding, then stop” defines a task it can actually finish.
• Give every fix a change budget. Name the finding and allowed files, set a line limit, and prohibit unrelated cleanup:

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• Keep durable decisions in the repository. Stable rules belong in a short AGENTS.md file [27]. The current deliverable and its stop condition belong in a goal, which OpenAI designed to preserve objectives across compaction [28]. Decisions and current state belong in versioned Markdown, as OpenAI’s guidance for long tasks recommends [29]. The chat remains useful for discussion, but it should not be the only place that remembers the contract.

This workflow does not reduce Sol to a warning label. It remains the strongest broad reviewer I have used, and it found real problems that Fable missed. Even the “72 hours” thread that records serious loops credits Sol with nearly halving the runtime of a complex parallel pipeline [4]. The point is to put that ability where it helps.

In my previous article about Opus 5, I argued that a capable model still needs clear management. My rule for Sol is stricter: search everything, change nothing, and send each claim to a separate judge. That keeps the extra coverage without giving Sol permission to enlarge the task.