OpenAI made the GPT-5.6 family generally available on July 9, following a limited preview announced on June 26. Sol is the flagship tier; Terra is the less expensive general-purpose option; and Luna is the low-cost, high-speed tier. OpenAI’s own positioning is unusually explicit: Sol is intended for long-running coding, research, cybersecurity, computer-use, and scientific tasks where additional reasoning time can pay off.
For developers using ChatGPT or Codex, though, the headline model choice is only part of the story. OpenAI’s current product documentation makes access dependent on plan, product, and reasoning setting. Sol is available through Medium, High, and Extra High settings on eligible paid ChatGPT plans; its more intensive options are exposed more broadly in Codex and ChatGPT Work. The company also says the rollout remains gradual for eligible ChatGPT accounts, so “available globally” does not mean every paid account sees the same controls at the same moment.
The reports are promising, but they are not a benchmark
Twilligear’s experience, as reported by The New Stack, is compelling precisely because it reflects a real workload rather than an artificial leaderboard prompt. He says Sol found substantive mistakes in a nationwide database that had been generated with Claude Opus 5; when he reversed the workflow and asked Claude to audit Sol’s output, he says it found only minor issues.
That is a useful account of model behavior, but it is not an independent accuracy test. The outputs were compared largely through another model’s review, rather than against a complete externally verified dataset. A model that misses a defect may have been poorly prompted for auditing, may lack the required domain knowledge, or may simply have failed to inspect that particular field. Conversely, a model that flags a difference has not necessarily identified an actual error.
Joshua Estrin, an AI-governance researcher interviewed by The New Stack, made the central point: model-versus-model review measures a narrower property than correctness. To establish which database is better, both outputs need comparison with ground truth—source records, validation rules, and a documented error taxonomy—not merely with one another.
That does not make Twilligear’s experience meaningless. It identifies a workflow worth testing: use Sol as an independent validator for structured data produced by another system, then require deterministic validation before accepting its proposed correction. For IT teams, that means schema checks, referential-integrity checks, duplicate detection, source-of-record reconciliation, and sampled human review. The model can expand the set of likely defects; it cannot be the final authority on whether a record is right.
OpenAI’s public performance claims support the general direction, but not Twilligear’s specific conclusion. The company says Sol leads its previous models in agentic coding and professional-work evaluations and improves work-per-token efficiency. Those are vendor-published results, not a substitute for a reproducible evaluation on an organization’s own codebase, data model, security policy, and deployment environment.
“Ultra” is a workflow setting, not a free intelligence upgrade
The most consequential technical detail in the GPT-5.6 launch is OpenAI’s
ultramode. OpenAI describes it as a highest-capability setting that coordinates multiple agents working across parallel workstreams, intended to accelerate demanding work. That is materially different from simply giving one model a longer hidden reasoning budget.
For developers, this changes the trade-off. A conventional chat exchange is suitable for a targeted bug fix, a short script, a design review, or an explanation of an unfamiliar Windows API. An ultra or long-running Codex task is better aligned with work that can be divided, revisited, tested, and synthesized: a repository-wide migration, a large refactor, a multi-stage investigation of an intermittent failure, or research that depends on local files and tool execution.
It also means that Sol’s best results may be inseparable from the surrounding agentic workflow. Shouqiao Wang, a Columbia Business School PhD candidate, wrote on X that he used GPT-5.6 Sol with ultra reasoning through Codex to solve six open Erdős problems in five days. He described pasting a goal into Codex and allowing it to retain research context, use local files, and continue exploring without ongoing prompts.
The claim has drawn attention, but it needs to be read accurately. Wang has published proof materials, prompts, and supporting files, and he said two of the six results have Lean formalizations while work on the others continues. That is more evidence than a bare social-media claim. It is still not the same as independent mathematical acceptance. Formalization can validate a precisely expressed proof, but only after researchers have confirmed that the theorem statement, assumptions, definitions, and translation into the proof assistant correctly capture the original problem.
There is additional context that makes the “five days” framing less clean than it first sounds. Wang has said he experimented with prompts and workflows for two months, selected 13 candidate problems, and received funding for the long compute runs. His work also follows earlier collaboration: a May arXiv preprint credits Wang and Davide Crapis with a solution to Erdős Problem 690. None of that diminishes a potentially important result. It does show that the result came from a researched, curated, compute-intensive process—not an untrained user pressing a button and receiving six verified proofs.
For enterprise teams, this is the more transferable takeaway. Long-horizon agents can produce useful work when supplied with a bounded objective, files, tools, time, and a way to check their output. The required human labor moves upstream into task selection and downstream into verification.
Sol’s overengineering problem is a cost and maintenance problem
Bustinza’s criticism is the one Windows developers and sysadmins should take most seriously. He told The New Stack that Sol sometimes has “a tendency to overengineer things,” and that he still turns to Claude or Gemini for smaller frontend problems.
Overengineering by a coding model is not merely an aesthetic problem. An assistant that turns a small UI adjustment into new abstractions, extra services, additional configuration layers, or broad rewrites creates review overhead and increases the chance of regression. In a Windows application, that can mean a simple WinUI, WPF, PowerShell, or installer task suddenly touches packaging, deployment configuration, telemetry, dependency versions, and compatibility logic that did not need to change.
Sol’s high-capability modes may therefore be a poor default for narrowly scoped work. The model may have enough capacity to discover adjacent concerns, but identifying concerns is not the same as having permission to redesign the system around them.
Teams should write constraints into their prompts and automation instructions:
- Specify the exact files, functions, components, or deployment artifacts that may change.
- Require the smallest viable patch and prohibit unrelated refactors unless an identified defect makes them necessary.
- Require the agent to state assumptions before changing public interfaces, schemas, permissions, installers, or infrastructure definitions.
- Run unit tests, linters, build validation, and security checks after every generated patch rather than accepting a confident explanation as proof.
- Ask for a short change summary that distinguishes required modifications from optional cleanup the model chose not to perform.
Those controls also improve comparison testing. If one team asks Sol to “improve the application” and another asks Terra or a competing model to “fix this method without changing any public APIs,” the apparent quality difference could be caused by the task definition, not the model.
Availability and pricing put Sol in a different operating tier
OpenAI prices GPT-5.6 Sol at $5 per million input tokens and $30 per million output tokens through the API, versus $2.50 and $15 for Terra, and $1 and $6 for Luna. Sol also supports a much larger context window than older GPT-family models, with OpenAI’s API documentation listing 1.05 million tokens of context and 128,000 maximum output tokens.
The important qualification sits in the price details: prompts exceeding 272,000 input tokens carry a higher price multiplier for the full request. Large-context work is possible, but it is not economically neutral. A repository-wide analysis, document corpus review, or autonomous multi-agent run can consume budget quickly, particularly when it produces extensive output or repeats tool calls.
The practical model-selection rule is straightforward. Use Sol when the work requires deep planning, cross-file reasoning, complex tool use, or a verification loop whose value exceeds the extra latency and cost. Use Terra or Luna—or a competing model—when the task is bounded, repetitive, UI-specific, or cheap to retry. The best model is the one that produces an acceptable patch with the least total cost of tokens, execution time, review time, and production risk.
OpenAI’s launch materials argue that GPT-5.6 improves performance per dollar. The developer accounts collected by The New Stack suggest that claim is credible for certain long-horizon workflows. They do not establish that Sol wins every head-to-head comparison, and the strongest anecdotes still lack controlled, ground-truth evaluation.
For now, GPT-5.6 Sol looks less like a single “best model” and more like a high-end engineering instrument: powerful when the task is substantial, expensive when used carelessly, and dependent on verification when the output affects real systems.