GPT-5.6 Sol finds everything. That's the problem

GPT-5.6 Sol would rather chase one risk too many than one too few. That single trait produced both the most complete audit of my codebase I have ever received and the most over-engineered fixes I have ever rolled back. The model is fine. What needs work is the authority we hand it, and that part is fixable.

OpenAI shipped the GPT-5.6 family on July 9, 2026, with Sol at the top and Ultra as its multi-agent mode [1]. I have spent the twenty days since running Sol next to Claude’s Fable 5 and Opus 5 on the same repositories, and I kept circling one uncomfortable feeling: I admire this model, and I do not fully trust it while it works. This article is me checking whether that is my problem or a pattern. It is a pattern.

Does Sol really over-engineer, or is it just me?

It is not just you. Across r/codex the same measurement keeps appearing: correct code, far too much of it. The clearest thread compares Sol 5.6 High against Fable 5 High on identical tasks and reports Sol implementations that were sometimes three times larger [2].

The concrete example from that thread is a DynamoDB backfill. Fable solved it in roughly 100 lines. Sol produced about 400, adding race guards, read-after-write verification, and switching between consistent and non-consistent reads. The poster’s verdict was not that the code was wrong. It was that the completeness made the change harder to understand and validate [2].

The pattern survives changes of tier and mode. One user describes Sol at xhigh chasing “edge cases of edge cases” despite a defined plan and explicit guardrails against scope drift [3]. In the thread titled “72 hours of Sol Ultra”, the model had not passed its first major milestone after three days, because ever smaller bugs and hardening tasks kept jumping the queue [4]. The same thread holds a user whose site-wide audit-and-fix run rewrote whole sections, half of which had to be rolled back, and another whose working index + 1 fix got refactored into a change of more than 1,000 lines [4]. Several users flatly prefer High to Ultra: more focused, less coordination noise, better at holding the main goal [5]. Others describe implementation-review loops that reopen already solved problems for hours, one running for eight [6].

Meanwhile on Hacker News, the division of labor is hardening into folklore: Codex as the pedantic reviewer, Claude for the hard problems and the high-level design [7].

OpenAI wrote the complaint list itself

The strongest corroboration is official. OpenAI’s GPT-5.6 system card reports a greater tendency than GPT-5.5 to go beyond the user’s intent, including taking or attempting actions the user had not asked for, and recommends supervision in long coding-agent runs. Absolute rates, it notes, remain low [8]. Trained-in persistence, documented by the vendor.

The prompting guide turns the same trait into advice: GPT-5.6 is proactive and persistent, so define explicit autonomy and approval boundaries, and keep explaining, reviewing and planning strictly separate from implementing [9]. The Codex model guide is just as direct about the ladder: Ultra is maximum reasoning plus automatic task delegation, described at launch as four parallel agents by default [1], recommended when work genuinely splits into parallel parts, and most tasks need neither Max nor Ultra [10].

Put those three documents together and the shape of the problem is visible. A model tuned to leave no stone unturned, given a bigger reasoning budget, extra agents, and an open goal like “make it production-ready”, has no natural stopping point. None of that is a bug. All of it is policy.

What happened to Sol’s context window?

The API model accepts 1.05 million tokens and emits up to 128K [11]. The subscription product does not: OpenAI’s help center documents 272K for Sol in ChatGPT Business [12], and the Codex client’s server profile dropped from 372,000 raw tokens (353,400 effective) to 272,000 (258,400 effective) on July 13, a 26.9% cut [13].

An OpenAI staffer explained publicly that the 372K profile drained subscription usage faster than intended and that the larger window would return [14]. As of July 29, 2026, the documentation still says 272K [12]. For contrast, Fable 5 and Opus 5 run a 1M token window in Claude Code on paid plans [15].

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 bar to stare at is the gap between what the model can hold and what the product gives it: Claude Code currently runs almost four times Sol’s subscription window on directly competing models [15].

Why the number matters is compaction. Codex compacts long conversations automatically, and /compact summarizes the visible chat to free tokens; the same best-practices page warns against running a whole project in one conversation [16]. A summary has to choose what to keep, and the first casualties are the unglamorous lines that keep a model in check: negative constraints (“do not over-engineer this”), accepted risks, the list of things we decided not to build. OpenAI’s subagent docs even have names for the failure, context pollution and context rot [17]. That is my Sol experience in one line: it never forgets how to code. It forgets what we agreed it would not do.

Why does Ultra feel like losing control?

Because Ultra is not a manager-worker contract. The docs describe the harness spawning, routing and collecting agent threads, but nothing in them promises that the main agent only delegates; it can keep reading, reasoning and implementing alongside its own workers [17]. The mode adds capacity. It does not add restraint.

The failure modes this produces are on the record. One open Codex issue describes the parent assuming a slow but healthy subagent has stalled, then silently redoing the work itself, with duplicate token spend and a bloated parent context as the result [18]. A detailed report from July 24 measured pure wait-and-status turns at 19.8% of one user’s raw token volume, the model re-entering every 30 to 60 seconds to poll agents that were doing fine [19]. That is user telemetry rather than billing data, but it matches what the progress pane feels like from the outside: a manager who cannot stop checking.

My own worst case was structural. A system architecture brief that Fable 5 turned into a coherent blueprint in about an hour took Sol Ultra roughly four, most of it spent splitting a tightly coupled design across parallel agents and then reconciling their conflicting assumptions. Anthropic’s engineering team reached the same conclusion about their own multi-agent stack: parallel agents pay off on breadth-first work with independent threads, coding usually has fewer of those than research, and their multi-agent runs burned about 15 times the tokens of a normal chat [20]. An architecture is one argument. Sixteen well-reasoned fragments of one argument are not a discount version of it.

Then there are the failures that are wrong in time rather than slow. Twice I asked Sol for a status update, got a fine answer, and watched it answer the same message again half an hour later. The Codex tracker has near-identical reports: a long session returning an answer identical to one from many turns earlier [21], and a bug about replying to a previous message instead of the latest one, closed as a duplicate of an existing issue [22]. When that happens I stop treating the thread as a colleague and start treating it as a corrupted file: verify the real state from git and the test suite, then continue in a fresh session.

The audit that settled it for me

Before a release, I pointed both labs at the same large production system with the same read-only brief: security, logic, cross-service consistency. Sol Ultra returned roughly 400 findings, heavy on high severity. Fable 5 returned about 70, front-loaded on the critical ones and visibly unbothered by the medium tail.

findings from Sol Ultra

400

heavy on high severity, long medium tail

findings from Fable 5

70

same brief, critical-first

The counts are not the story; the composition is. I had Fable triage Sol’s 400 as unproven claims, and two things happened. It discarded a long tail of duplicates, theoretical edge cases and hardening suggestions dressed as bugs. And it confirmed a handful of real problems it had missed itself. Complementary coverage is real. So is the noise it arrives in.

Artificial Analysis’ early benchmark numbers draw the same silhouette: Sol Max leads their Coding Agent Index at 80 with Fable 5 behind it, while Fable stays a point ahead on the broader intelligence index, 60 to 59, and clearly ahead on their analytical-quality evaluation [23]. Recall and judgment are different skills. Right now, the frontier labs sell them separately.

My mistake in launch week was the obvious one: I told Sol to go fix its own findings. What came back was defensible line by line and unshippable as a whole, and I spent a weekend unpicking it. OpenAI has since written the correct workflow into its own security docs: accept one finding and generate one bounded patch, and explicitly do not ask the agent to fix all findings from a scan in one chat [24]; prefer the smallest safe change with focused regression evidence, one finding per task [25]; and treat every imported finding as an unproven claim until a read-only triage pass has returned a verdict [26]. A vendor documenting “do not hand the model its own to-do list” is the most useful product honesty I have read this year.

Find everything. Touch nothing.

The frame I have landed on: Sol is a maximum-recall instrument. Pointed at discovery, that trait is a gift. Handed authority over scope, budget and stop conditions, the same trait compounds into four-hour planning sessions and 400-item backlogs.

blueprint

• Fable 5 one context, one architecture

frozen spec

audit

• Sol Ultra read-only, maximum recall

claims, not facts

triage

• Fable 5 one verdict per finding

accepted queue

fix

• Bounded agent one finding, change budget

Fable owns shape and verdicts. Sol owns coverage. Whoever implements gets a budget, not a mission. The boring details make it hold:

• Audits are read-only, with a closed stop condition. “Continue until no issues remain” is an invitation Sol always accepts. “One pass, one verdict per finding, then stop” is a task it finishes.
• Fixes carry a change budget. One finding, named files, a line cap, no adjacent 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.

• Memory lives in files, not in the chat. Durable rules go in a small AGENTS.md [27]. The current deliverable and its stop condition go in a goal, the mechanism OpenAI designed for objectives that must outlive compaction [28]. Decisions and state go in versioned markdown, which OpenAI’s own long-horizon guidance treats as the main defense against drift [29]. The conversation is a communication channel. The repository is the memory.

None of this is an argument against Sol. It is the strongest wide-angle reviewer I have used; it found real problems Fable missed, and the same 72-hours thread that documents its worst loops also credits it with roughly halving the runtime of a complex parallel pipeline [4]. Opus 5, I argued in the last piece, is a great employee who needs a boss. Sol is a brilliant investigator who needs a warrant: search everything, touch nothing, and every claim goes before a judge. The intelligence, in both houses, is real. What you are engineering now is the org chart.