Claude Code vs Codex vs Hermes: Choosing the Right AI Agent Harness
Why the harness around an AI model matters more than the model itself, and how to choose between Claude Code, Codex, Hermes, and similar agent tools.
What is an AI agent harness, and why does it matter more than the model?
A harness is the software layer wrapped around a language model that gives it the ability to read files, write and edit code, run commands on your computer, and act on the results of those actions. The model itself is just a “brain in a jar”: it can generate text, reason about a problem, and produce output, but it has no hands. Ask a raw local model to build a website and host it locally, and it can write the HTML, but it cannot spin up a server, move files, or touch your file system. It doesn’t have the limbs for that.
Tools like Claude Code and Codex bundle a model with exactly those limbs: file read/write access, edit capabilities, and “bash” access that lets the model control folders, processes, and servers on your machine. That bundle is the harness. When people argue about whether Claude is smarter than Codex or Gemini, they’re usually arguing about the brain, when the thing actually determining whether a task gets done is the surrounding factory of tools, permissions, and feedback loops.
TL;DR
- A harness is the tooling layer (file access, bash, editing) wrapped around a model that lets it actually act on a computer instead of just producing text.
- Claude on the web and Claude Code use the same underlying model, but Claude Code adds the harness that lets it touch local files and execute commands, which is why it can finish tasks the chat version can only describe.
- The agentic loop (act, observe result, adjust, repeat) is what lets an agent recover from errors and keep working toward a goal, and a model’s skill at using that loop matters as much as its raw intelligence.
- Local, open-source models running through tools like LM Studio can already handle a large share of day-to-day coding work, with heavier “genius-level” tasks routed to frontier models.
- Builders should stay loyal to their harness and their own skills/assets, not to one model provider, since the brain underneath can and should be swapped depending on the task.
- Claude Code and Codex have noticeably different personalities in practice: one leans toward ideation and planning, the other toward literal, obedient execution.
- Skills and custom agent configurations decay quickly as models and tools evolve, which is why some practitioners recommend periodically deleting and rebuilding them rather than letting them go stale.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
How is Claude Code different from Claude on the web?
Claude on the web (the standard chat interface) and Claude Code run on similar underlying models, but they behave very differently because of what surrounds them. In the web version, Claude can research a topic and draft something like a PDF, but any step that requires touching local files, calling outside platforms, or moving data around your computer has to be assumed or simulated rather than actually executed. It’s working blind to your actual environment.
Claude Code, by contrast, is a harness: it can read and write files on your machine, run bash commands, and interact with both your local system and the cloud. That means it can go from “here’s what we could do” to an actual finished artifact sitting on your disk. The gap between the two isn’t a smarter model, it’s the tool access wrapped around it. Some practitioners expect this distinction to fade over time, with lightweight harness versions eventually becoming the default way anyone interacts with these models at all, rather than a separate “chat” product existing alongside a separate “code” product.
What is the agentic loop, and why does it decide how well an agent performs?
The agentic loop is the repeating cycle an agent runs through: take an action, observe what happened (success, failure, or an error message), feed that result back in as new information, and decide the next action. This loop is what lets an agent recover from a broken command, retry a failed edit, or adjust a plan mid-task instead of stopping the moment something doesn’t work.
How well a model uses that loop depends on the sophistication of its harness and its own trained ability to pick the right tool at the right moment. A more capable model will recognize, for example, that a task needs a bash command paired with a file write, rather than just one or the other. The comparison that captures this well: two people can both be handed the same toolbox, but someone who has used those tools for years and has scar tissue from past mistakes will get dramatically more out of them than someone holding the tools for the first time. Model intelligence matters, but tacit knowledge of when and how to use the available tools matters just as much.
How do Claude Code and Codex actually differ in practice?
Both are harnesses built around frontier models, but they behave with different “personalities” once they’re actually working on a task. Claude Code tends to act like a visionary: strong at ideation and planning, willing to go back and forth, sometimes pushing back on instructions rather than executing them exactly as given. Codex tends to behave more like a surgeon, or a Rottweiler that takes a command and just keeps executing until it’s done, following instructions literally rather than improvising around them.
In practice, this difference is useful rather than a drawback. One workflow described in the source material involves using Codex to review and stress-test a plan that Claude Code produced, running the two back and forth across multiple rounds until Codex has surfaced every gap or missing consideration Claude Code’s plan didn’t anticipate. Neither model is strictly “better” here. They’re complementary, and the choice of which one leads depends on whether the task at hand needs broad planning or precise, obedient execution.
Is running a local model enough, or do you still need frontier models?
Increasingly, no single model needs to handle everything. Local, open-weight models run through tools like LM Studio can already carry a large share of day-to-day coding and writing work, assuming you have the hardware to run them. The catch is that a local model on its own, without a harness, is exactly the “brain in a jar” problem: it can write code but can’t execute it, host it, or interact with your file system unless something is built around it to provide that access.
The practical pattern emerging is a mixed one: run the bulk of routine work locally, and route the harder, “genius-level” tasks, like architectural planning or gnarly debugging, to frontier models like Claude or GPT-class systems accessed through a full harness. This keeps costs down and keeps work moving even without constant API access, while still tapping bigger models when a task actually demands it.
Should you build loyalty to a model, or to your own harness and skills?
The more durable strategy is to stay attached to your own harness, skills, and context files rather than to any single model provider. Skills, custom prompts, and plugins can be written so they work across multiple harnesses and multiple models, which means the investment you put into building them doesn’t evaporate if you switch from Claude Code to Codex, Hermes, Open Claw, or whatever tool replaces them next year. One practical technique is converting a skill built for one harness so it also works cleanly in another, keeping a single set of core assets usable everywhere rather than maintaining separate versions per tool.
This matters because skills and agent configurations decay fast. As models update and harnesses change how they call tools, instructions that worked well six months ago can quietly stop working as intended. That’s the reasoning behind advice, attributed in AI circles to Anthropic’s Boris Cherny, to periodically delete all your skills and rebuild them rather than let outdated ones accumulate. The underlying principle: you can outsource the thinking to a model, but you can’t outsource the understanding of what your systems actually do and why.
Frequently Asked Questions
What’s the difference between a model and a harness?
The model is the reasoning engine that takes input and produces output, text, code, or a plan. The harness is the surrounding software that gives the model tools: reading and writing files, running commands, executing code, and observing the results. A model without a harness can describe a solution but can’t execute it.
Is Claude Code better than Codex?
Neither is strictly better. They tend to specialize differently in practice: Claude Code leans toward planning and ideation and will sometimes push back on instructions, while Codex tends to execute instructions literally and persistently. Many workflows use both, having one check the other’s work.
Can local models replace tools like Claude Code or Codex?
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Local models run through interfaces like LM Studio can handle a large portion of routine coding tasks, but they need a harness of their own to interact with your file system or run commands. Without one, a local model faces the same “brain in a jar” limitation as any other model on its own.
Why would someone delete all their AI skills every six months?
Skills and agent configurations are built around specific model behaviors and tool-calling patterns. As models and harnesses update, those configurations can quietly become mismatched or outdated. Rebuilding periodically keeps your setup aligned with how the current tools actually behave, rather than optimizing for a version that no longer exists.
What should I actually build loyalty to when using AI coding tools?
Your own skills, context files, and workflows, not a single provider’s model. Building assets that work across multiple harnesses and models means you can switch the “brain” being used without losing the accumulated work you’ve put into how your system operates.
