Verdict
GPT-5.5 and GPT-5.6 look broadly comparable in core capability. The most repeatable differences were about posture: GPT-5.5 more often behaved like a collaborative design partner, while GPT-5.6 more often behaved like a decisive operator.
Those tendencies were visible enough to influence task routing, but not strong enough to justify moving all work to either model.
The models were used at different times, on different projects, with evolving system prompts, skills, and tools. This is a natural-use audit, not a randomized trial.
Behavioral differences
| Dimension | GPT-5.5 | GPT-5.6 |
|---|---|---|
| Default posture | Collaborative and architecture-first | Decisive and execution-first |
| Best observed work | Ambiguous product shaping and evolving system design | Bounded audits, operations, and runtime recovery |
| Communication | More conversational; explicitly states process limits | More structured; cleaner findings and status summaries |
| Typical risk | Longer ceremony and repair loops | Over-completing before proving the exact result |
| Confidence | Tentative. The apparent differences may partly reflect task and tooling era. | |
The numbers
The sample was balanced on coarse task categories and contained 108 GPT-5.5 turns and 109 GPT-5.6 turns. Multiple internal GPT-5.6 variants were represented without being analyzed as separate products.
| Metric | GPT-5.5 | GPT-5.6 |
|---|---|---|
| Duration | 26.7 min | 27.9 min |
| Turns | 4.0 | 6.5 |
| Tool calls | 95.5 | 108 |
| Tools per turn | 25.1 | 25.7 |
| Tokens per turn, including cache | 1.60M | 1.84M |
None of these differences was statistically persuasive. Aggregate and median error rates even pointed in opposite directions because a handful of very large sessions dominated the totals.
How the reviewers split
| Lens | Verdict |
|---|---|
| Qualitative behavior | Slight GPT-5.5 edge Collaboration and adaptation |
| Instruction adherence | Slight GPT-5.5 edge Literal and process adherence |
| Outcomes and failures | Modest GPT-5.6 edge Systemic risk detection and operations |
| Efficiency and recovery | Mixed GPT-5.6 on complex recovery; GPT-5.5 on a typical session |
| Devil's advocate | No winner Apparent advantages collapsed under confounds |
| Methodology and statistics | No winner Useful for hypotheses, not ranking |
The shared failure mode matters more than the model gap
Both models were strongest when they inspected live state: actual database plans, browser output, runtime streams, remote processes, or external-service readback. Both were least trustworthy when a static check was treated as proof that a visual interaction worked.
Require a task-specific acceptance check before “done”: exact visible state for UI, readback for operations, and focused runtime behavior plus checks for code.
How I would route work today
- Prefer GPT-5.5 for ambiguous architecture, product shaping, and discussions where the design should evolve through repeated judgment.
- Prefer GPT-5.6 for bounded audits, remote-system work, operations, and recovery-heavy debugging.
- Use either model for implementation, but define the acceptance check in the prompt and insist that the final answer distinguish static validation from live verification.
- Do not make variant-level decisions yet. The internal GPT-5.6 subgroups were too small and task-segregated.
Method and limits
The workflow read complete JSONL snapshots, linked calls to their preceding model context, removed duplicate active/archive copies and repeated prompts, excluded mixed-model and incomplete sessions, separated direct from orchestrated work, and built equal task-category samples. Reviewers received a packet without model names, dates, aliases, or source paths.
The study remains observational. Project mix was not truly matched, long sessions contained multiple tasks and idle time, the available tools changed over time, and model selection was not random. Automated “correction” counts were discarded after injected skill and instruction text produced false matches.
A stronger follow-up would run 30–50 representative tasks on both models from identical clean snapshots, randomize model order, keep the tool surface fixed, manually classify corrections and failures, and score objective verified outcomes.