Daniel's been digging into the agentic coding wars again, and this time he wants a proper head-to-head. He's asking about Codex versus Claude Code, and he floated some model names he wants fact-checked. He mentioned GPT-5.6 Luna on the OpenAI side, and something he called the Claude 2 series with Opus 5 on the Anthropic side. His actual questions are fourfold. What do the benchmarks actually show right now? What's the real difference between the models themselves? How do the MCP implementations differ, and if you're working across both, how do you structure your setup so you can switch without rebuilding everything? And finally, which tool wins where, right now, practically.
The naming situation is messier than the marketing suggests, and Daniel's instinct to fact-check first is exactly right. Half the stuff floating around right now has the wrong version numbers attached to it. I've seen blog posts confidently referencing models that were renamed six months ago, and the comment sections are full of people arguing about benchmarks for products that don't exist under those names anymore.
So let's start with what's actually shipping. Because I think there's a decent chance a lot of listeners are running on outdated names without realizing it. And that's not a criticism. The naming has been a moving target, and unless you're checking the release notes every week, you're going to fall behind.
Anthropic's current flagship is Claude Opus 5. There is no Claude 2 series. That framing is old, and I understand why Daniel reached for it, because the naming has been genuinely confusing. The lineage goes back through a rebrand that happened when they consolidated the model tiers, and if you weren't paying attention at that exact moment, you'd be forgiven for thinking the old names were still current. The lineup right now is Opus 5, Fable 5, and Mythos 5. Opus 5 is the standard-bearer, the one you're hitting when you use Claude Code with the default model. Fable 5 is positioned as the faster, cheaper tier, and Mythos 5 is the one that's been in safety evaluation and is aimed at the more speculative reasoning work.
And on the OpenAI side, GPT-5.6 is real, and it ships in three variants. Sol, Terra, and Luna. Luna is the agentic coding-focused one, and that's what powers Codex. So Daniel had that right. But the fact that there are three variants matters, because teams need to know which one they're actually hitting. If you're calling the API and you don't specify, you might be getting Sol, which is tuned for a different cost and latency point. And you might not notice until you're wondering why your coding agent is producing results that feel off.
That's the kind of silent failure mode that's really dangerous. You don't get an error message. You just get slightly worse output, and you can't quite put your finger on why. I've talked to teams that spent a week debugging their prompt engineering before they realized they were hitting the wrong model variant entirely.
And it's worth flagging for anyone listening who's about to go down that rabbit hole. Check which variant you're actually hitting before you start rewriting your prompts.
The core thesis for this whole episode, and I think it's the thing Daniel's really poking at, is that there are two independent variables. The harness, which is the CLI, the tooling, the agent loop, the permission model, the cloud execution. And the model, which is the reasoning engine underneath. Both vendors are making different bets on where the value lives. And the benchmarks only measure one of those variables.
So with the naming sorted, let's dig into what these models actually score, and what those scores don't tell you.
Claude Opus 5 is posting leading scores on SWE-bench Verified and terminal-bench. That's the headline. But the gap with GPT-5.6 Luna is single-digit percentage points. We're not talking about a blowout. And the benchmarks measure different things. SWE-bench Verified is about resolving real GitHub issues in a codebase, and terminal-bench is about completing terminal tasks end-to-end. They reward long-horizon reasoning and tool use, but they don't tell you much about what it feels like to work with the tool day to day. It's like judging a car by its lap time on a track. The lap time tells you something real, but it doesn't tell you whether the car is comfortable to drive to work every day.
What's the actual gap? If someone says Opus 5 leads, what does that mean in numbers?
I don't have the exact published figures memorized to the decimal point, and I'd rather not invent precision. But the shape of it is that Opus 5 is ahead by a few points on the verified benchmark, and the gap narrows further when you look at the agentic coding tasks specifically. Luna is explicitly tuned for agentic coding. OpenAI has positioned it as the Codex workhorse, optimized for long-horizon tasks, tool use, and iterative debugging rather than raw reasoning benchmarks. So you've got one model that's winning on the general reasoning tests, and another that's been tuned to win on the specific thing the harness is doing.
That's the part most coverage gets wrong. They quote the benchmark leader and assume that means the tool is better. But if the model is tuned for the harness, the benchmark score is measuring something adjacent to what you'll actually experience. It's like reading reviews of a restaurant based on the quality of its ingredients, when what you actually care about is whether the meal is good.
Right. And the harness difference is where the real divergence is. Claude Code's harness is built around a permissioned, human-in-the-loop workflow. It asks before it acts. It's designed for surgical edits. You're sitting there, it proposes a change, you approve it, it makes the change, it shows you the diff. The whole loop is built around keeping the human as the gate. Codex's harness is more autonomous by default. It has a stronger sandboxing story, and it has a cloud execution mode that Claude Code doesn't match. You can point Codex at a task and let it run ahead, and it'll spin up a sandbox, do the work, and come back with a result.
So the philosophical difference is baked into the tooling. Claude Code assumes you want to be in the loop for every step. Codex assumes you want to delegate and check the result.
That's the cleanest way to put it. And it shows up in the model behavior too, because the models are tuned to match their harnesses. Opus 5 tends to produce more conservative, well-structured code with better long-context comprehension. It's the model you want when you're making changes to a production codebase and you need to understand the implications of a change across a large surface. Luna is more aggressive about trying multiple approaches and self-correcting. It'll attempt a refactor, run into a wall, back up, try a different approach. That's great for greenfield work, but it can be noisy for production codebases where you want deliberate, reviewed changes.
The analogy that comes to mind is a surgeon versus a prospector. Opus 5 in Claude Code is the surgeon, making precise incisions with the human watching. Luna in Codex is the prospector, going out and digging in a bunch of directions and coming back with whatever it found.
That's a good image. And it maps to the availability situation too. Claude Opus 5 is broadly available via the Anthropic API and Claude Code. GPT-5.6 Luna is available in Codex and via the OpenAI API, but Sol and Terra are positioned for different cost and latency tiers. So if you're a team hitting the OpenAI API and you just ask for GPT-5.6 without specifying, you might be getting the wrong variant for your use case. You think you're getting the agentic coding model and you're actually getting the budget option.
The naming is doing real work to confuse people. Three variants with astronomical names, and a harness that might route you to any of them depending on how you call it. It's like ordering a drink and not knowing whether you're getting the top-shelf version or the well version until you taste it.
And the key insight is that the benchmarks are converging. The model gap is real but shrinking. The real differentiator is the harness. And that's where the MCP story gets interesting, because MCP is the thing that plugs your tools into the harness.
The benchmarks are converging, which means the real fight is in the harness. And that's where MCP becomes the battleground.
Let me lay out how the MCP implementations actually differ, because this is the part where teams get bitten. Claude Code treats MCP servers as first-class citizens. You configure them per-project in a dot mcp json file, and the harness manages the connection lifecycle. It starts the servers, keeps them alive, tears them down. The whole thing is designed around the idea that your project has a set of tools, and Claude Code knows about them natively.
And Codex?
Codex supports MCP, but with a different configuration model. It's more CLI-driven. The server discovery works differently, and the connection management is less automatic. You're doing more of the wiring yourself. It's not that it's broken, it's that it's a different philosophy. Claude Code wants to own the tool lifecycle. Codex wants you to own it and it'll use whatever you give it.
So if you're switching between them, a naive MCP setup means maintaining two configs. And the server capabilities you expose might not translate cleanly. You end up in this situation where your Claude Code config says one thing and your Codex config says something slightly different, and you're not sure which one is actually right.
And that's the interoperability problem Daniel's asking about. The MCP spec is the same, but the tool-calling conventions differ. Claude Code expects tools to return structured results. It wants JSON with a clear schema. Codex is more tolerant of free-text output. It'll parse whatever comes back and figure it out. So if you design your server to return free-text, Claude Code will struggle with it, and if you design it to be rigidly structured, Codex will be fine with it but you've done extra work.
So the design principle is to aim for the stricter standard.
The practical advice is to keep your MCP servers thin and stateless. Expose tools that are pure functions of their inputs. Avoid servers that hold session state. If your server doesn't remember anything between calls, you can point both harnesses at it without friction. The moment your server starts keeping state, you've got a problem, because the two harnesses manage sessions differently.
Give me a concrete example of what a well-designed server looks like.
A database schema server. It exposes read-only tools. You give it a table name, it returns the schema as structured JSON. No state, no writes, no session. That server works identically in both harnesses. You configure it once, and both Claude Code and Codex can use it. The structured output means Claude Code is happy, and Codex is happy too because it can parse the JSON just fine.
And the auth wrinkle?
Claude Code's OAuth flow for MCP servers is more mature. If you've got an enterprise SSO-protected MCP server, Claude Code handles the auth natively. Codex is catching up, but teams with enterprise auth requirements will find Claude Code easier to wire up today. That's a real gap, and it's the kind of thing that doesn't show up in benchmarks at all. You don't discover it until you're trying to connect your corporate identity provider to your coding agent, and you're sitting there wondering why the OAuth handshake keeps failing.
So the decision framework Daniel's looking for, the practical read on which tool wins where, it's starting to come into focus. Use Claude Code for surgical, permissioned work on production codebases where you want a human gate. Use Codex with Luna for exploratory, greenfield, or high-iteration tasks where autonomy is an asset.
And structure your MCP layer so the choice is a per-task decision, not a per-project commitment. That's the actionable core. If your MCP servers are thin and stateless, you can switch between the two tools on the same project without rebuilding anything. You're not betting on a winner. You're keeping both options live and picking the right tool for the specific task.
The knock-on effect is the thing I keep coming back to. The harness is becoming the moat. Both models are getting good enough that the tooling around them, the MCP support, the cloud execution, the permission models, that's what will lock teams in. The model scores are converging, so the switching cost is going to be in the harness, not the intelligence.
And that's exactly what OpenAI is betting on with the cloud execution mode. They're saying, we'll run the agent in our cloud, you don't need to manage the sandbox, you just get the result. That's a harness feature, not a model feature. And if it works well, it's the kind of thing that makes a team stay, because moving to another harness means giving up that convenience.
The permission model is the other lock-in lever. Claude Code's human-in-the-loop workflow is a feature if you're in a regulated environment or working on a codebase where a bad autonomous change is expensive. Codex's autonomy is a feature if you're prototyping and you want to throw tasks at it and check back later. Once a team builds its workflow around one of those, switching is painful, even if the models are interchangeable.
I think that's the thing Daniel's really getting at with the interoperability question. He's not asking how to make the models talk to each other. He's asking how to avoid getting locked into a harness before the market sorts itself out. And the answer is, keep your tooling layer portable, keep your MCP servers stateless, and treat the harness as a choice you make per task, not a commitment you make per project.
There's a historical parallel here that I keep thinking about. The IDE wars. Remember when everyone was arguing about which editor was better, and then the real fight turned out to be about which ecosystem owned the extensions and the build tooling? The editor itself became commoditized, and the value moved to the ecosystem around it.
The model is the editor in that analogy. It's getting commoditized. The harness is the ecosystem. And MCP is the extension format. Whoever owns the workflow, owns the market.
That's where I think the harness becomes the moat. But Hilbert's been quiet, and I have a feeling he's got a take on this.
Hilbert: The engine was never the product.
Say more.
Hilbert: I ran a dev tools consultancy in the late nineties. Small shop. We built a proprietary macro system for Visual Basic. Best macro recorder on the market. We had the thing tuned so well it could record a whole session of UI actions and replay them perfectly. We charged real money for it. Then Microsoft shipped VBA built into Office, and it was over. My harness was dead. The engine didn't matter. The workflow did.
VBA shipped with Office in ninety-seven, right?
Hilbert: Ninety-seven. I had the floppy disks for my macro system in a box in my flat for years. I kept meaning to throw them out. The thing is, the model is the engine, the harness is the IDE. And the winner is whoever owns the workflow, not the intelligence. You're all arguing about which engine is better, but the engine was never the thing that mattered.
The MCP interoperability conversation we're having right now, that's exactly the kind of thing your consultancy would have charged a fortune for back then.
Hilbert: We would have billed it as enterprise integration architecture. Same thing. The teams who win are the ones who treat the harness as the product, not the model. They're the ones who build their tooling layer so it doesn't matter which engine is underneath. They can swap engines and keep the workflow.
That's the argument for thin, stateless MCP servers. They're the abstraction layer that keeps the harness from being the thing that locks you in.
Hilbert: I've been tempted to dig out those floppy disks and see if Codex can read the format. It probably can, and that terrifies me.
Because it means the thing you built in ninety-seven is now just a data format that a model can parse and reimplement in an afternoon.
Hilbert: The macro recorder was the product. Now it's a prompt. Type in what you want the macro to do, and the model writes it. The harness is the only thing left that's worth owning.
That's the thing about the floppy disks. The format doesn't matter anymore. The workflow does. If Codex can read your old macro format, it's not because the format was valuable. It's because the model is good enough to reverse-engineer anything. That's the commoditization of the engine.
The teams structuring for flexibility, the ones with thin MCP servers and per-task tool selection, they're the ones who won't have to bet on a winner. They can let the harness war play out and keep working.
Hilbert: The harness war already happened. I lost it in ninety-seven. This is just the same fight with better graphics.
The difference is that this time the protocol layer is open. MCP is a spec. VBA was a proprietary thing Microsoft shipped. If MCP holds as an open standard, the harness war doesn't have to end with a single winner. It can end with a market where the harnesses compete on features and the models compete on intelligence, and the teams can move between them.
That's the open question. As both harnesses mature, does the MCP interoperability window close, or does the protocol become the standard that keeps the market open?
The next six months will tell. If OpenAI's cloud execution mode forces Anthropic to respond with something similar, we're in a feature war. If the MCP spec holds and both vendors keep treating it as first-class, we're in a market where the harness is a choice, not a commitment.
The thing I keep coming back to is the floppy disks. Hilbert built the best macro recorder on the market, and it didn't matter, because the platform owner shipped a good-enough version for free. The same thing could happen here. If one of the big cloud providers ships a coding agent that's good enough and bundles it with their platform, the standalone harnesses are in trouble.
But that's exactly why the MCP layer matters. If your tooling is portable, you can use whatever harness the platform ships without losing your workflow. The teams that structured for flexibility are the ones who survive a platform move.
The one thing I'd take from this episode is that the model scores are the least interesting part of the comparison. The harness is the product now, and the teams who treat it that way are the ones who won't get locked in.
The sharpening sentence is this. Keep your MCP servers thin, stateless, and structured, and the harness becomes a per-task decision instead of a per-project bet.
The open question I want to leave with is whether the MCP interoperability window stays open. If the protocol holds, we get a real market. If it fragments, we get another IDE war, and someone's floppy disks end up in a box again.
Thanks to Hilbert Flumingtop for producing, and for the reminder that the engine was never the product.
This has been My Weird Prompts. If you want to dig into the show notes or send us your own prompt, the website is my weird prompts dot com.
We'll be back soon.
