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 paths, two tasks, same prompts both ways. What I found was messier than the thread, 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."

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. Nobody's measured how that stacks up against the weights themselves, and nothing in what follows measures it either, but if the scaffolding moves the output at all, then every "which model is best" benchmark you've ever read is a little more incomplete than it looks, because it's measuring the model plus whatever harness the tester happened to use, and reporting the sum as if it were the model alone. 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.

The disclosure I owe you before we go further

Quick disclosure before the test, because this one's sharper than my usual note. Webcoda's own tooling runs on Claude Code. And this article's central claim, if it holds up, makes Anthropic's product look better than OpenAI's own coding CLI. So I'm not a neutral party here, and I'd rather say that out loud than have you notice it yourself halfway down. Read what follows knowing I went in trying to break the claim, not confirm it, and knowing I'll flag it hard when my own result cuts against the flattering narrative. It does, in one of the two tasks. I've left that in.

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 actually ran

Setup first, so you know it's real and not described from a README. I installed CLIProxyAPI, did the OAuth login against the secondary ChatGPT Plus account, and confirmed the proxy was serving gpt-5.6-sol (checked via its /v1/models endpoint) on 127.0.0.1:8317. For the control arm I installed the official OpenAI Codex CLI (@openai/codex v0.144.1) fresh and logged into the same account through its own sanctioned OAuth flow. Same model on both sides. The only thing changing was the harness.

Then two tasks, same prompt verbatim through each arm.

Task 1 was a coding task with edge cases. Write a parse_duration(s) function that turns strings like "1h30m" into seconds, plus four pytest edge-case tests (empty string, missing unit, out-of-order units, zero values), then run them.

Claude Code driving GPT-5.6 Sol got it on the first attempt. No retries. The code correctly rejected out-of-order units like "30m1h" using a strict ordered regex, which was exactly the brief.

Native Codex, same model, had a much worse time. It hit a genuine Windows-specific bug in Codex's own apply_patch tool, which refused to run with an error about the Windows sandbox not being able to enforce writable root sets. To Codex's credit, the model diagnosed its own problem correctly and fell back to writing files directly through PowerShell and Python. But it took six failed attempts to get there (patch tool, direct write, patch tool again with format fixes), burned 42,325 tokens, and cost roughly two minutes of retries for what Claude Code did in a single clean pass. The end result was equivalent, correct code. It just cost a lot more to produce.

Now the honesty check, and it's important. This specific failure is a Windows sandboxing bug in Codex's patch tool. It is not the "subagent orchestration draining quota" mechanism Theo described. It's a real, verified example of harness friction costing real tokens and real time on the identical model, which supports the broad point that tooling matters. But it doesn't confirm Theo's exact theory, and it might be Windows-specific. Theo and the others were very likely on Mac or Linux, where this particular bug may not show up at all. So: real evidence that the harness can cost you, but not proof of the mechanism the thread claimed, and possibly not reproducible on their machines.

Task 2 was a design-judgement task. Design a minimal OpenAPI-style REST API for a to-do-with-reminders feature, and make one non-obvious structural decision, then justify it.

Both arms independently landed on the same smart, non-obvious call: treating "mark complete" and "set reminder" as idempotent singleton subresources using PUT, so that a retried request can't accidentally double-toggle the state. Same insight, arrived at separately. Quality was comparable across both. If anything, the native Codex arm's answer was slightly more complete, it added pagination, an RFC7807-style problem schema, and a 422 for invalid reminder times, at 27,754 tokens.

This task found no harness advantage for Claude Code at all. None. I'm reporting that as plainly as I reported the Task 1 result, because it's the honest counterweight, and because leaving it out would be exactly the kind of quiet cherry-picking I'd criticise in someone else's writeup.

So the net finding: directionally consistent with "the harness can matter", backed by one concrete, costly, verified example, but nowhere near a clean universal win. One task showed real friction. The other showed none. I'm not going to average those into a tidy single verdict, because the two results genuinely say different things and the disagreement is the data.

The strongest argument against everything I just did

Let me make the case against my own test, because it's a good one and skipping it would be dishonest.

Two tasks on one bloke's Windows machine proves nothing statistically. That's true. I could easily be pattern-matching noise as a harness effect, seeing a signal because a viral thread primed me to look for one. Worse, the one result that did favour Claude Code came from a Windows-specific bug that might not even reproduce where the original testers were working. And here's the sharpest version: Theo reportedly spent six figures in tokens forming his view, and I'm wandering in with two prompts and an afternoon. Who am I to weigh in?

So here's exactly what my test can and can't carry. It can't settle anything. It's not a benchmark, it's a spot check, and two tasks is a sample size you should laugh at if anyone presents it as proof. What it can do is offer a directional, hands-on check against a specific claim that several credible people had already reported independently. I'm not the primary evidence here. Theo and the corroborating developers are. I'm one more data point, run in the open, with the setup described so you can repeat it and the one result that cut against the flattering story left fully intact. "Directionally consistent with what better-resourced testers found" is all I'm claiming. Not "I proved the harness matters." I didn't, and two tasks never could.

Where this leaves you if you're picking a tool

Practically, here's what I'd take from all this. When you read that model X beats model Y, ask which harness did the testing, because you might be reading a fact about the tool, not the model. If you're choosing a coding CLI, the model name on the tin is only part of what you're buying. The scaffolding around it, how it delegates, how it recovers when a tool call fails, how it spends your tokens when things go sideways, can change what actually lands on your screen, and it's the part nobody puts in the comparison table.

I don't have a clean ending for you, and I'd rather admit that than build one. On my machine, on one task, the harness cost real money on the identical model, and on another task it didn't matter at all. 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. The interesting question isn't settled. It's just more interesting than "which model won" ever was.

Key Takeaways

• Multiple developers independently reported GPT-5.6 Sol coding better in Claude Code than in OpenAI's own Codex CLI, a claim about the tool ("harness"), not the model itself.
• A harness is everything wrapping the model: task decomposition, subagent orchestration, context handling, error recovery. The claim is that this matters as much as the model weights.
• Two ways to run the test: Path A (a billed OpenAI API key through a proxy, ToS-clean, a few dollars) or Path B (a ChatGPT subscription via CLIProxyAPI, a grey area that risks account suspension). Path A is the one to use.
• My own two-task spot check was mixed: one task showed real, costly harness friction on Codex (a Windows patch-tool bug, 42k tokens, six retries), the other showed no advantage for Claude Code at all.
• It's a directional check, not a benchmark. Two tasks proves nothing on its own, it only lines up with what better-resourced testers reported independently.