Here are all of my prompts and suggestions for how to best use GPT 5.6. This family of models is quite different from GPT 5.5, so it took some experimentation and getting used to operating with a different mindset. I also share more about how I pair it with Fable 5 inside the workflows that I run.
Pricing and daily model choice
If we look at these numbers, you can start to see the cost per task for GPT 5.6 Sol. If you compare high reasoning with something like GLM 5.2 on high reasoning, GPT 5.6 Sol costs $3.47 per task and GLM 5.2 costs $2.84, but their passing scores are 69% and 36%, respectively, which is incredible. The cost per task for GPT 5.6 Sol on medium reasoning is $1.86. I compare this with GLM 5.2 because it is meant to be a highly capable, cost-effective model.
I look at DeepSWE because the benchmark is closed and uncontaminated, and its tasks read like real engineering work because real engineers wrote them. Its main gap is that bug localization and refactoring are underrepresented, though the team is working on adding more tasks in those areas.
If we also compare GPT 5.6 Sol with Fable 5, we can see that it is much more cost-effective than Fable 5. However, Fable 5 is technically a more intelligent model than GPT 5.6 Sol.
The Codex team recommends using GPT 5.6 Sol medium reasoning as a daily worker agent or driver. For complex work, you can push up to high, xhigh, and max. There is also an “ultra” mode that orchestrates a series of subagents under the hood to solve a problem, but it can skyrocket costs and usage, and personally I haven’t found a direct need for it.
Unlike high, xhigh, and max, ultra is a Codex multi-agent mode rather than a reasoning level, and its subagents can work in parallel on independent workstreams. I prefer to have more control over my workflow orchestration and don’t want to burn my tokens.
How I route work
For my loops or workflows, I use GPT 5.6 Sol medium for worker agents, xhigh for debugging, and max for code review. For codebase research and analysis, I use GPT 5.6 Sol medium. For codebase locators and codebase pattern-finder agents, I leverage GPT 5.6 Terra high. I can fan out a series of these agents in parallel on specific targets, and this model is a more cost-efficient way to extract all the key details. For heavier thought tasks like research and analysis, I use a stronger model.
I mentioned that GPT 5.6 is incredibly efficient and skilled. However, there are still places where it falters, and I substitute Fable 5. Fable 5 is better at prompt refinement to define the work I pass into GPT 5.6 Sol. GPT 5.6 Sol is a very literal model and needs great instructions to work well; otherwise, it is prone to running away with a task. This is why I use Fable 5 to refine the intent.
Additionally, Fable 5 still scores better on design benchmarks, which is another case where I use it. However, if you are an all-GPT shop, you can use OpenAI’s image generation model to iterate on designs and then pass them to GPT 5.6 Sol, and it does great work. I believe this is how Peter Steinberger shared that the OpenAI team does its design work.
Another peculiarity I noticed is that GPT 5.6 Sol goes super in-depth on code review and attempts to find every possible issue to resolve—it is very nitpicky. In contrast, Fable 5 tends to gloss over more and approve changes. Sol tries super hard to optimize your architecture as much as possible, and at least for code reviews, I’d prefer to receive more corrections for now rather than fewer. That is another reason I prefer it to Fable 5.
But you need a good way to define and scope verification; otherwise, GPT 5.6 Sol could run for hours. More on that below.
The table below is my exact configuration for my workflows inside Atomic. This is specifically for the Ralph workflow, which is focused on daily development. I chose to share this one because I think it is the most representative of the daily work we’re doing with coding agents.
Ralph configuration
| Ralph stage / work type | Model | Reasoning level |
|---|---|---|
| Prompt refinement | Fable 5 | High |
| Research | GPT 5.6 Sol | Medium |
| Orchestrator | GPT 5.6 Sol | XHigh |
| Codebase location | GPT 5.6 Terra | High |
| Pattern finding | GPT 5.6 Terra | High |
| Codebase analysis | GPT 5.6 Sol | Medium |
| Implementation worker | GPT 5.6 Sol | Medium |
| Debugging | GPT 5.6 Sol | XHigh |
| Reviewer A | Fable 5 | High |
| Reviewer B | GPT 5.6 Sol | Max |
Keeping long-running work under control
One major consideration is that GPT 5.6, as I mentioned above, tends to run away with work. It can work for hours or days, and this is intended by design as we push toward longer-running tasks. This makes having an effective control plane to monitor, steer, and correct your agents even more important.
My specific working formula has been to define explicit, verifiable outcomes that measure progress as tasks advance. These are specific gates or checks the model must pass as it progresses through the work.
I use Atomic for my workflows. It is a verifiable coding-agent runtime, so it has these verification gates built into loops that I can steer via natural language. However, you can bake in these verification criteria yourself. You can also see how Atomic manages this and incorporate the approach into your own stack.
Another great prompt trick is to ask GPT 5.6 Sol how it would prompt itself to prevent it from being over-eager.
Prompt engineering patterns for GPT 5.6
Treat the request as the literal source of truth. We instruct GPT 5.6 Sol to treat the objective and acceptance criteria as the literal source of truth, rather than silently replacing the requested behavior with external specifications, assumptions, or general best practices.
Create an observable acceptance matrix. We require it to create an observable acceptance matrix that maps every explicit requirement to a concrete test, command, executable scenario, artifact inspection, or state assertion before claiming completion.
Orchestrate focused subagents. We tell it to act as an orchestrator rather than a direct implementer by delegating investigation, code changes, and validation to focused subagents and tracking that work through an explicit todo ledger.
Base decisions on direct and durable evidence. We require completion claims and review decisions to be based on direct repository inspection, independent validation, and durable regression evidence instead of summaries, worker-authored tests alone, or plausible-sounding reasoning.
Define precise convergence rules. We give it precise convergence rules so it continues working while objective-relevant requirements remain unresolved, approves when implementation and validation are genuinely proven, and never invents findings, hides failures, or prolongs the loop over non-blocking issues.
Conclusion
As always, keep experimenting and trying things out to see what works for you. Go at your own pace. We’re all figuring things out as we go. If you found this post helpful, feel free to subscribe to our newsletter. It’s the best way to show your support.
Thanks!
Alex & Norin
Top comments (0)