Why Theo Runs GPT-5.6 Sol in Claude Code

I have been using GPT-5.6 Sol a lot, but often inside Claude Code rather than Codex. That surprised me too. The reason is not just the terminal interface: the harness, system prompt, sub-agent orchestration and integrations can all shape what the same underlying model does.

These are my impressions from hands-on work, not a controlled head-to-head evaluation. I still think the Codex desktop app is a good starting point for many people, but I have become frustrated with aspects of its CLI and especially the way its sub-agents are orchestrated.

In the version I was testing, Codex had a simple sub-agent implementation where a parent delegates tasks one level down, and an experimental version with nested named agents, inherited context and messages. I found the latter powerful but complicated and difficult to predict.

The Claude Code workflow feature I used takes a different approach. The model writes code that defines phases, prompts, sub-agents and control flow, then a runtime executes it. I like being able to see an explicit structure for the work instead of relying only on ad hoc delegation.

In my own trials, these workflows tended to finish more predictably and use much less of my allowance than the Ultra runs I compared them with. I estimate roughly a quarter of the token use in some cases with comparable output, but that is an anecdote, not a measured general rule.

That led me to try Sol as the model doing the work within Claude Code itself. I was not merely asking a Claude model to invoke Codex as a separate tool. The combination let me explore whether a different harness could change the experience of a model I already used.

I show two generated pages, one produced with Sol in Claude Code and another with Sol in Codex. I prefer the first design, though I do not think either is perfect. The example made me investigate what instructions each environment gives the model; it does not isolate the cause by itself.

In the Claude Code prompt I examined, the main frontend instruction I found was to run the application and use it in a browser before declaring the work complete. That is a verification instruction rather than a detailed visual style guide.

I then examined a cached Codex prompt. I was particularly concerned about a long frontend section that prescribed decisions for different kinds of interfaces. I say in the video that the guidance had recently changed for 5.6; the prompt being criticized is a historical version, not a statement of what every current installation uses.

Some advice, such as respecting an existing design system, sounds sensible. My objection is the accumulation of highly specific defaults: for example, directing business software toward a quiet utilitarian style and constraining how common controls and cards should look.

The displayed text specified an eight-pixel maximum card radius unless the existing system required otherwise and encouraged icon buttons. My concern is that broad rules like these can turn a style preference into a universal constraint, even when the product or user needs something else.

The prompt also discouraged visible explanatory text and landing pages in many circumstances, while prescribing parts of a hero layout. Those constraints could interfere with onboarding, empty states or accessibility. The right choice depends on the application, not one fixed template.

I argue that a powerful model will follow the rules it is given, and that the rules themselves deserve review when output looks repetitive. I plan to write a replacement prompt and evaluate it; the design comparison is my hypothesis about the cause, not proof that the prompt alone caused the difference.

I also noticed frequent 30-second waits or updates during long tasks and found an instruction calling for frequent updates in the version I examined. I suspect the instruction influenced the behavior, but the video does not establish that it was the sole cause.

To get another perspective, I asked several models to review the prompt. One Sol response rated it differently as a runtime-specific prompt, a general coding prompt and a portable prompt. These are model-generated opinions, not independent measurements of prompt quality.

The review objected to repeated runtime details and a large, prescriptive frontend section applied even to unrelated work. It also questioned icon-only controls and a broad restriction on explanatory text, since touch interfaces, onboarding and error recovery may need visible guidance.

I connect other behavior, such as continuing too long or implementing while a user wants to explore, to instructions about persistence and action. That is my interpretation of the prompt and my experience; determining causation would require a more careful comparison.

The prompt and product can change by model and version. I mention being told that an older model's prompt was tied to its training, while newer guidance had changed. The lesson I draw is to inspect the actual configuration being used instead of treating a prompt as timeless.

By contrast, the Claude Code prompt I read gives more general guidance about software tasks. I like its distinction between exploratory questions and requests to implement, its preference for meaningful comments, and its emphasis on testing UI changes in a browser.

I also value its emphasis on reversibility and the scope of an action: local edits and tests are different from destructive or externally visible operations. These are principles I find useful, not proof that any agent is incapable of making a damaging mistake.

My proposed remedy for the Codex prompt is to rewrite and evaluate it more carefully, including reviewing actual interaction histories. I prefer human-authored global guidance, but whatever the drafting method, the important test is how it behaves across representative tasks.

Sol in Claude Code has drawbacks too. In one example I thought it had failed to publish a generated HTML report after a file-name collision. On closer inspection it had published the report; I had missed the link because the formatting looked unfamiliar.

There were still formatting problems, including a numbered list with repeated numbers. The correction matters: I should not attribute a missed step to the model when the step actually happened, but the presentation can still make the result harder to understand.

For orchestration, I give an example prompt asking a workflow to analyze a codebase with Sol, Terra and Fable sub-agents. The model needs enough information about the available names and tools to coordinate the work. Explicitly asking for a workflow helps convey the desired structure.

Another small difference is reporting: in my setup, 5.6 did not show sub-agent token usage until a task finished, whereas Fable provided live updates. These details affect observability even when the underlying work is similar.

Why not Pi or OpenCode? My reason is specific: I was looking for a built-in way to orchestrate staged sub-agent workflows. I like aspects of Pi but would have to build more of that orchestration myself; I had not evaluated the newer OpenCode version at the time.

For my day-to-day work, I find workflows useful because they can express phases, dependencies, model choices and an ending. I do not think this is impossible for other tools to implement; it is simply the best implementation I had personally found for that need at the time.

I mention a CLI proxy that can route different providers and subscriptions into the tools I use. The video does not provide a complete setup walkthrough, and provider support, terms and pricing may change. Check the current documentation and authorized access conditions before attempting any integration.

I am not saying everyone should route a Codex subscription through Claude Code. This was an experiment that worked better than I expected and showed how much the harness around a model can matter. Test the combination against your own tasks and judge the results yourself.