Why Does GPT-5.6 Perform Better in Claude Code Than in Codex? A Deep Dive

Tech blogger Theo (t3.gg) recently released a fairly controversial hands-on video, arriving at a conclusion that surprised even himself: OpenAI's GPT-5.6 model actually performs better running inside Anthropic's Claude Code than in OpenAI's own Codex. This seemingly absurd combination reveals deep-seated differences in the design of AI coding tools (harnesses). Based on the video's content, this article takes a deep dive into the key differences between Codex and Claude Code across core mechanisms like system prompts and subagent orchestration.

A Counterintuitive Experiment: Putting GPT-5.6 Inside Claude Code

Theo admits that if someone had told him a few months ago that he'd be making a video like this, he'd have thought they were strange. But as his frustration with Codex as a CLI tool grew, he decided to seriously try running the GPT-5.6 model inside Claude Code—and to be clear, this doesn't mean having Claude Code call the Codex CLI, but rather using GPT-5.6 directly as the core model working inside Claude Code.

The result completely changed his mind. He emphasizes that the advantage isn't just that Claude Code has a better terminal UI (though it does)—the real gains come from Claude Code's different design at the underlying level: from its approach to subagents, to its system prompts, to its various integration capabilities.

As a side note, Theo specifically clarified that this isn't an attack on other tools like Pi or OpenCode. He focused on Codex and Claude Code because this new generation of models brings entirely new capabilities, and understanding what these tools get right and wrong is crucial for getting the most out of the models.

Key Difference #1: Subagent Orchestration Mechanisms Compared

Codex's Messy Subagent System

Theo's biggest gripe with Codex is its subagent mechanism. Currently, Codex has two versions:

• V1: Stable and simple, allowing the top-level agent to spawn a batch of subagents that are only one level deep, assign them specific tasks, and return the results upon completion.
• V2: A new, unfinished version that must be manually enabled. It copies the entire context window by default (which is annoying) and allows subagents to spawn their own named subagents downward, forming a hierarchy with message passing. This turns what was a simple hierarchy into something extremely complex, adding a large number of tools needed for communication. The result is quite messy and clearly still being tuned—which is why it's off by default.

Claude Code's Workflows

By contrast, Theo praises Claude Code's Workflows feature. Instead of having subagents spawn randomly, the model defines a programmatic workflow in advance: different stages, different prompts, different subagents configured for each stage—all written in a single JavaScript file that executes top to bottom.

Because workflows are essentially code, they actually terminate. This proved to be a huge advantage when using GPT-5.6—models in the GPT-5.6 series tend to "dive in headfirst" and not stop, whereas executing via a workflow means that even for the same task where Ultra mode might run indefinitely, the workflow will terminate. Theo observed that the output quality was the same or even better, but token consumption was only a quarter of the original, a huge efficiency gain.

The key difference is this: OpenAI hardcodes the logic directly into Codex, and the model must call it correctly; whereas Claude Code lets the model write the code for the workflows and subagents itself. Theo believes this approach is overall far better.

Key Difference #2: A World of Difference in System Prompt Quality

Claude Code's System Prompt: Less Is More

Theo ran an interesting experiment: he had GPT-5.6 generate web designs in both environments, and found that the pages generated in Claude Code were noticeably higher quality—they even "looked like Claude made them itself."

He initially assumed Claude Code's system prompt must contain a ton of front-end design guidance. So he read through the entire Claude Code system prompt—and found that the word "front-end" appeared only three times, none of which was substantive design guidance. It simply told the model to start the dev server and verify its work in the browser. There was almost nothing about design in the system prompt.

Codex's System Prompt: An Overly Prescriptive Design Disaster

So where was the problem coming from? Theo then examined Codex's official system prompt, and promptly "broke down."

He found that Codex's system prompt was crammed with extremely specific, rigid front-end design rules, such as:

• Mandating that tools like SaaS and CRMs "must look quiet, utilitarian, and work-focused"—which directly causes every SaaS page Codex generates to look identical.
• Specifying that card border radii must be 8 pixels or smaller.
• Requiring the use of the Lucide icon library.
• Mentioning "card" six times (the word appears 12 times), and even "goblins" appearing twice—more than the number of times Claude Code mentions front-end UI at all.

Worse still, this prompt mandates "no visible instructional copy allowed" and "empty states are not allowed to be used"—which explains why Codex could never do empty states well. And the rule to "provide user updates every 30 seconds" explains why Codex always obsessively sets a 30-second timer.

Theo pointedly noted that this system prompt has been burning through users' millions upon millions of tokens, degrading output quality, and wasting time—and it took a YouTuber to expose these problems. He said he's hand-writing a brand-new Codex system prompt from scratch, and plans to open-source and share it once it succeeds.

Cross-Model Verification

For objectivity, Theo had GPT-5.6 (Claude Code version), Fable 5 (Claude Code version), and GPT-5.6 (Codex version) each evaluate this Codex system prompt. GPT-5.6 in Claude Code gave it a score of 7 as a tightly-coupled Codex runtime prompt, only 4 as a general-purpose coding agent prompt, and just 3 as a portable prompt aimed at modern models. Even GPT-5.6 running inside the Codex environment only gave the prompt a 4. The model noted that the front-end section was "overly prescriptive," amounting to a standalone "front-end design constitution," taking up roughly a quarter of the length even when the task was a CLI, database, or backend library.

Minor Flaws in Testing

Theo also candidly pointed out some issues he encountered running GPT-5.6 in Claude Code—though fewer than expected:

• Occasionally losing track of the task: This might relate to how context is managed, but he believes it's most likely a minor issue in the system prompt.
• Formatting issues: GPT-5.6 wasn't very skilled at handling Claude Code's Markdown formatting (like numbered lists and link formats), producing minor errors such as repeated numbering.
• Token usage not real-time: GPT-5.6 series models don't report token usage until the work is complete, whereas Fable updates in real time.

To get Claude Code to use workflows correctly and understand model codenames like "soul" and "terror," you need to configure the system prompt or the global agents.md accordingly.

Why Not Use Pi, OpenCode, or Other Tools?

Anticipating potential objections, Theo responded in advance: while these tools may have system prompts that aren't as bad as Codex's, they don't solve the subagent orchestration problem he cares most about. OpenCode has a batch of hardcoded subagents built in, and their quality isn't great; Pi is excellent, but requires users to build all their own workflows and orchestration tools.

His conclusion is clear: for real day-to-day work, Claude Code's workflows are the best implementation of subagent orchestration he's seen—enabling an agent to break down complex work among other agents running different models, executing them in stages and turns, launching important tasks while ignoring irrelevant ones, and having a real endpoint.

Conclusion: Tool Design Matters As Much As the Model Itself

Theo repeatedly stressed that he doesn't think everyone should switch to using their Codex subscription through Claude Code. This was just an interesting experiment with results far beyond his expectations. But the core insight this experiment reveals is worth deep reflection for all AI coding users: in the era of a new generation of models, the design of the tool (harness)—especially the quality of the system prompt and the mechanism of subagent orchestration—may have as much impact on the final outcome as the model itself. The same model, placed in different tools, can produce vastly different output quality and token efficiency. This reminds us that when evaluating AI coding capabilities, we can't just look at the model—we must also scrutinize the entire engineering framework that carries it.