Harness matters, sometimes: does GPT-5.6 Sol really run better on Anthropic's Claude Code than Codex?

On the morning of 11 July 2026, Theo (t3.gg) posted something that stopped me mid-coffee: "gpt-5.6-sol is meaningfully better in Claude Code than in Codex. I'm going to crash out so badly over this." Same model. OpenAI's own coding CLI on one side, Anthropic's Claude Code on the other. And the model apparently does better work in the competitor's tool than in the one built by the company that made it.

Theo - t3.gg

@theo

gpt-5.6-sol is meaningfully better in Claude Code than in Codex

I'm going to crash out so badly over this

1.8K

11 July 2026

Read that again, because it's a stranger claim than it looks. Nobody's saying GPT-5.6 got worse. They're saying the exact same weights, the exact same model, produce better results depending on which tool is driving them. That's not a vibe. It's a testable question: does the harness around a model change what the model can actually do, holding the model itself constant? I've spent twenty-odd years building on top of whatever the best available tool happens to be, and questions like that are the ones worth an afternoon, because if the answer is yes, it changes how I'd advise a client to pick their stack.

So I set it up on my own machine and checked. Two ways to run it, four tasks, same prompts both ways. What I found wasn't the tidy confirmation I expected, and I think the mess is the honest part.

The corroboration came fast, and it came specific

The thing that made me take Theo seriously wasn't Theo. It's that within the same rough window, other developers independently said the same thing, without hedging, and about a specific, checkable behaviour rather than a general good feeling.

Paul Bettner, who's been shipping software for a long time, posted almost the identical finding right alongside Theo's tweet, close enough in time that I can't say for certain who landed on it first: "trying this myself now too... gpt5.6 performs way better in claude code than codex, actually???" Whether he'd seen an early version of the same thread or arrived at it independently, the two posts sit within minutes of each other, not one reacting to the other days later.

Paul

@paulbettner

trying this myself now too... gpt5.6 performs way better in claude code than codex, actually??? 😅

0

11 July 2026

Then, a couple of hours after both, SeanCasGamer, naming the exact setting: "I'm having the same experience. GPT 5.6-Sol on High is much better running under Claude Code CLI."

SeanCasGamer

@SeanCasGamer

@theo I’m having the same experience.

GPT 5.6-Sol on High is much better running under Claude Code CLI.

1

11 July 2026

And Kisalay, close behind, who framed the interesting part precisely: if the model does better in one environment than another, that tells you something about how the model's strengths line up with the tooling, not just about the model.

⭕Kisalay

@Kisalay_

@theo This is interesting feedback. If GPT-5.6-sol performs significantly better inside Claude Code than in Codex, it suggests the model’s strengths align better with certain coding environments. Many developers will want to test this difference themselves on real projects.

1

11 July 2026

Here's why fast, independent corroboration matters on a claim like this one. If four people all said "GPT-5.6 is amazing", I'd shrug, because "amazing" isn't falsifiable and everyone's amazed at launch. But "the same model is better in tool X than tool Y" is a narrow, specific, awkward claim, awkward because it points the finger at OpenAI's own product, and specific enough that you can actually go and check it. When several people land on an inconvenient specific independently, within hours of each other, that's the kind of signal I don't ignore. It's also worth noting Theo reportedly spent six figures in tokens forming this view, so it wasn't a throwaway.

Worth saying plainly, too: Theo isn't a Claude Code loyalist who'd say this to flatter Anthropic. Elsewhere he's said the opposite-sounding thing, that Codex feels faster, that GPT needs fewer tokens and tool calls to reach an answer, and that GPT-5.5 on Codex has been his own daily driver for a while. That's not actually a contradiction, speed and output quality are different axes, but it matters for how much weight to put on his 11 July post. This isn't someone who'd already decided Claude Code wins everything. It's someone who uses Codex heavily, flagging one specific result as surprising enough to post about. That's a better reason to take it seriously than if it had come from a Claude Code fan.

What "harness" actually means, and why that's the real story

The replies to Theo's post converged on one word, and it's the word that makes this interesting: harness.

A harness, in this context, is everything wrapping the model that isn't the model. How the tool breaks a big task into smaller ones. How it spawns and coordinates subagents. How it manages the context window, decides what to keep and what to drop, and hands work back and forth. One developer put it better than I could: "The harnesses actually make a significant difference. Think about them as the body for the model." Same brain, different body. One body's better at getting useful work out of that brain than the other.

Theo's specific complaint pointed at Codex's subagent implementation. He described it forcing unnecessarily high-effort instances that drain your quota, versus Claude Code's more flexible, file-based workflow primitives that give you more control over how work gets delegated. Another reply just said, flatly: "Harness."

That complaint checks out, and this is the part I didn't expect to find. There's a real, open GitHub issue, openai/codex#31814, filed 9 July 2026, 111 reactions and still unresolved as I write this. GPT-5.6 Sol defaults into a subagent mode that hides the exact fields (agent_type, model, reasoning_effort, service_tier) it would need to route work to cheaper Terra or Luna subagents. The practical effect, spelled out plainly in the issue by the developer who filed it: "Sol's most important use case is as a subagent orchestrator. This setting makes it impossible to use Terra/Luna subagents." Every subagent Sol spawns inherits Sol's own full, expensive configuration, whether the task needs it or not. That's not a vibe about a harness feeling different, it's a specific, acknowledged bug with a documented workaround, and it's the closest thing to a hard technical explanation for the exact behaviour Theo described.

Theo's own fuller view, from later conversations rather than the single viral tweet, is more nuanced too: Sol is genuinely good at grinding through long, determined tasks and subagent orchestration once it's actually allowed to orchestrate properly, Fable's edge is discernment, taste and strategic thinking, fewer rabbit holes. And independent evaluator Artificial Analysis, who run their own Coding Agent Index across labs, found GPT-5.6 Sol running inside Codex topped that index, with Claude Fable 5 running inside Claude Code close behind. Worth being precise about what that does and doesn't prove: it's each lab's best model on its own harness, not the same model held constant across two harnesses, so it doesn't settle the specific claim either. But it's real, independent, third-party evidence that model and harness are tangled together in exactly the way this whole story is about, not just one viral thread's word for it.

I want to be clear about why this is a better story than "GPT-5.6 is bad" or "Claude Code wins". It isn't about which model or which tool is best. It's a claim about architecture: that the scaffolding around a model can materially change what you actually get out of it, not just how fast or how comfortably. The GitHub issue is the clearest evidence I found that this isn't hand-waving, a specific configuration default measurably changes what Sol can do inside Codex, filed, documented, and still open. That's the bit that keeps nagging at me, honestly. We talk about models like they're the whole story. They might be half of it.

Two ways to actually run this, and the trade-off between them

Here's the immediate problem: there's no official way to point Claude Code at a non-Anthropic model. Claude Code expects to talk to Claude. So to run GPT-5.6 Sol inside it, you need a proxy sitting in the middle, translating Claude Code's Anthropic-format requests into OpenAI API calls. There are two genuinely different ways to do that, and the difference matters.

Path A is the clean one. You take a billed OpenAI API key and run it through a proxy like 1rgs/claude-code-proxy or musistudio/claude-code-router. These tools exist precisely for this: they convert Anthropic Messages requests into standard OpenAI API calls. No subscription trickery, no OAuth, no grey area. You're paying OpenAI directly for API usage the way you're meant to. GPT-5.6 Sol is on the standard billed API at $5 per million input tokens and $30 per million output, the same rate I covered in the Sol/Terra/Luna buyer's guide. So for a few dollars of API spend, Path A lets you run this comparison without touching anyone's terms of service.

Related Article11 min read

GPT-5.6 is out of the sandbox: when to actually use Sol, Terra, or Luna

OpenAI's gated GPT-5.6 preview went generally available on 9 July 2026, three tiers, three prices, and a lot of confused buyers. Here's the practical...

Read full article

Path B is the grey one, and it's the one most of the viral thread was actually using. A tool called CLIProxyAPI does an OAuth login against OpenAI's own Codex backend using a ChatGPT Plus or Pro subscription, the same OAuth flow the official Codex CLI uses, then re-exposes those model calls as a generic endpoint that Claude Code can talk to. The appeal is obvious: no separate API bill, you're using the subscription you already pay for. The catch is real. The OAuth login itself is fine, that's how Codex is meant to work. Feeding it into a different, non-OpenAI frontend through an unofficial proxy is not something OpenAI has blessed. Their terms say ChatGPT Plus doesn't include API or programmatic access, and they generally prohibit circumventing the service's technical limits. There's no explicit ruling on this exact pattern, so it's a genuine grey area rather than a clearly stated breach. The practical risk isn't legal, it's your account: whichever ChatGPT account you use could get suspended. This isn't fringe, either. Several other tools (vibeproxy, Quotio, CCS) are built on the same mechanism, all marketed as "no API keys needed."

I want to be plain about what Path B is here. I'm reporting what the community's doing and what I chose to do myself. I'm not writing you a how-to for breaching a terms of service. If you want to run this test, Path A avoids the entire question for the price of a coffee, and it's what I'd point most people at.

I ran Path B, with eyes open. I used a secondary ChatGPT Plus account, not my main dev account, because I wanted to test the exact setup the thread was using, and I genuinely don't mind if that particular account gets suspended for it. That's an informed choice for a specific reason, not a recommendation that you make the same one. A standing advisor I ran this past told me flatly not to risk a primary account on Path B, and that's advice I'd pass straight on to you.

One more thing worth a paragraph, because it's the question I actually asked before touching any of this: does swapping the model break my normal Claude Code setup? No, if you do it right. Claude Code reads two environment variables at startup, ANTHROPIC_BASE_URL and an auth token. Set them inline in a single terminal session only, don't use setx (that's permanent for your whole Windows profile) and don't edit ~/.claude/settings.json (that's shared config), and only that one window's claude runs are affected. Every other session, including ones already open, keeps talking to real Claude. I confirmed this directly in the test: the variables reached exactly one subprocess and nothing else.

What I ran myself, and why I'm not leaning on it

I did set this up on my own machine and run a small test, because I wanted at least one hands-on data point of my own before writing about someone else's. I won't spend long on it, though, and here's why plainly: four tasks on one Windows box, using GPT-5.6 Sol on both harnesses, is a spot check, not evidence, and it shouldn't carry more weight in this article than the real research above. In short, three coding tasks (a duration parser, a CSV parser, an interval merger) came back correct and working on both Claude Code and native Codex CLI, no difference I could measure. (I also asked all five models how many times the letter r appears in strawberry, purely out of curiosity. Five for five got it right, three. Whatever tokenization quirk made that question famous, it's clearly saturated the training data by now.) A fourth task, a real design brief, is worth a bit more space, because it produced something concrete rather than a null result either way.

For that fourth task I handed both arms a genuine brief: redesign our own AI Checker analysis report (the one at ai-checker.webcoda.com.au), using the real scan data from an actual completed analysis, to serve both a time-poor business owner and an advanced user without compromising either.

Zoom

Image could not be loaded: /images/articles/gpt-5-6-sol-claude-code-harness-test-2026/report-redesign-claude-code.png

GPT-5.6 Sol's report redesign via Claude Code

Claude Code's result: a "Business summary / Technical detail" toggle, the single highest-priority fix surfaced above everything else, backed by the actual measured numbers.

Zoom

Image could not be loaded: /images/articles/gpt-5-6-sol-claude-code-harness-test-2026/report-redesign-codex-cli.png

GPT-5.6 Sol's report redesign via native Codex CLI

Native Codex CLI's result on the identical brief and data: near-identical structure, the same priority fix identified first.

The two are barely distinguishable in substance, both split the report into a business view and a technical view behind a toggle, both led with the same fix. I ran the same brief through three more models for good measure (GPT-5.6 Terra, Claude Fable, and Claude Opus, all on Claude Code), and every one landed on that same structural decision independently, worth noting as a real finding about the problem, not about which harness is smarter. All five are live and unedited if you want to look yourself: GPT-5.6 Sol via Claude Code, GPT-5.6 Sol via Codex CLI, GPT-5.6 Terra via Claude Code, Claude Fable via Claude Code, and Claude Opus via Claude Code, or all five side by side.

Since design quality is subjective, here's my own read, for what it's worth, not a scored verdict. Fable's is the one I'd actually ship, hands down, its two-column "working in your favour" versus "costing you visibility" contrast is the sharpest piece of writing in the batch.

Zoom

Image could not be loaded: /images/articles/gpt-5-6-sol-claude-code-harness-test-2026/report-redesign-fable.png

GPT-5.6 Sol via Claude Code, my personal favourite among the five for its editorial contrast

I'd also take GPT-5.6 Terra on Claude Code over GPT-5.6 Sol on Codex, and Sol on Claude Code over Sol on Codex too, though not by leaps and bounds. Opus's is a different case entirely: it's the one I, as a developer, would have built myself if you'd handed me the brief, plain-language questions per pillar and a visible line showing the raw scan field behind every recommendation. Not my favourite to look at, but the one that thinks the way I do. None of that ranking is about the harness question this article is actually asking, GPT-5.6 Sol produced code I couldn't tell apart between Claude Code and Codex on this task. It's just an honest personal note on a genuinely different question, which design would I ship.

Where this leaves you if you're picking a tool

The real evidence here isn't my own small test, it's the community's. Several developers, working independently, on their own machines, on real tasks, reported the same specific, checkable thing. A filed, still-open GitHub issue gives a genuine technical mechanism for at least part of it. An independent benchmarking outfit's numbers are consistent with model and harness being tangled together, even if they don't isolate the variable cleanly. My own spot check didn't surface the same gap on the tasks I happened to pick, and I'd rather tell you that honestly than pretend a four-task test settles anything either way.

If you want to know for your own work, the honest answer is to run your own tasks through both, using Path A so you're not gambling an account on it, and watch what actually happens with your code, not mine.

Key Takeaways

• Multiple developers, including Theo (t3.gg), independently reported GPT-5.6 Sol coding better in Claude Code than in OpenAI's own Codex CLI, a claim about the tool, not the model.
• A real, still-open GitHub issue (openai/codex#31814) gives a genuine technical mechanism for part of Theo's complaint: GPT-5.6 Sol's subagent mode defaults to hiding the fields needed to route work to cheaper subagents.
• Independent evaluator Artificial Analysis found GPT-5.6 Sol topping their Coding Agent Index inside Codex, with Claude Fable close behind inside Claude Code, real evidence model and harness are entangled, though not a clean same-model comparison.
• My own small test (four tasks, one machine) didn't confirm the harness advantage on coding tasks, but did produce a genuinely useful real-world design comparison, with all five results published for you to judge yourself.
• Design quality is subjective. My own pick was Claude Fable's redesign, by a clear margin.