Blog

Claude vs Codex: which is the better background agent?

Some of our preferences and stories on Claude and Codex at LangWatch.

Rogerio ChavesRogerio Chaves · July 8, 2026 · Article
Claude vs Codex: which is the better background agent?

We are a lean team at LangWatch, so we automate as much of our own engineering as we can. A fleet of background agents runs a chunk of our internal work now, and it keeps growing. Most of them build on Claude Code. One reviews, and it runs on OpenAI Codex.

The builders each own one chore. One triages our Dependabot alerts, which pile up faster every month now that AI has sped up how much code everyone ships, ours included. One hunts our slowest ClickHouse queries and proposes rewrites, so LangWatch gets a little faster on its own over time. Others draft the weekly changelog, dig through what our customers did that week for the heroes team, chip away at low-priority tech debt, and check that production deploys came up clean.

The reviewer runs on Codex, and it has one job: read a pull request and grade it. None of this is robots left alone, we drive both tools by hand all day too. The division of labor between the two came out of months of real PRs.

After months of running both, our preference has been boringly consistent: Claude Code is better at doing the work, and Codex is the better reviewer of it.

How the builders run

Each builder is the same shape: a skill, which is a markdown playbook checked into the repo, plus a schedule. A systemd timer on a shared box wakes each one on its own cadence with a prompt like "use the optimize-clickhouse-slow-queries skill to do today's run end to end." The agent reads the repo, does the work, and opens a PR.

Every one of those prompts ends the same way: never merge, never approve. A human makes every merge call. That single rule is what lets us leave them running.

The scopes are deliberately small. The ClickHouse skill takes the two slowest production queries from the last 24 hours and opens one advisory PR per query, and it caps the run at two PRs. The tech-debt skill pulls a couple of stale low-priority tickets, re-checks that each one is still worth doing, and the skill caps it at two PRs per run too. A narrow agent that opens one good small PR beats a broad one that hands us a mess to untangle.

Claude Code fits this work well. It holds an hour-long headless session without wandering, skills are a clean way to package a repeatable job, and hooks let us bolt guardrails onto the run. OpenTelemetry export lets us watch the whole fleet from one place when we want to.

The reviewer runs on Codex

The reviewer does not build anything. It reads a diff and grades it, and it runs on Codex.

On our own PRs we drive it on demand. When one of us wants a second read, we ping the reviewer and it posts its findings. We have the wiring to fire it automatically on every internal PR too, a watcher that polls the repos every fifteen minutes. That part is off right now. A full-auto reviewer on every PR burns more than we want to spend before we move to a bigger plan.

What does run on a schedule is the review of pull requests from outside the org. Every weekday morning the agent scans the repos for open PRs from people who are not owners, members, or collaborators, forks included, and reviews the ones it has not seen yet.

A stranger's branch is where you have to be careful, so the agent treats an external PR as untrusted input. It reads the diff statically, leans on the CI results already there, and never runs the PR's code, installs its dependencies, or follows instructions buried in the diff. A reviewer holding our repo and cloud credentials has no business running code an outsider pushed. That is also why the same-repo watcher skips forks, and this morning job is the one path that ever looks at them, under those guardrails.

Two things earned Codex that seat.

First, the model reviewing the code is not the model that wrote it. A model tends to pat itself on the back and wave through its own assumptions. Point a different model at the diff and it has no stake in them. That independence is close to free, and it catches mistakes the author skips right over.

Second, it is just a better reviewer of the stuff that matters. The critical findings, the ones we file as P1 and P2, it surfaces more often than anything else we have run. It has already flagged more than one would-be security hole for us, the access-control kind.

The one that stuck with me: we shipped a personal usage endpoint, and the review caught that one query read the spend ledger with no tenant filter on it. So anyone in more than one org saw their spend from every org summed on their own usage page. One missing predicate, and no test would have caught it.

We run the reviewer as a skill. It is a company skill on our box; I also keep a copy on my personal skills repo if you want to see the shape of it. It grades each finding by severity, posts them as proper inline GitHub review comments instead of one top-level blob, and never approves or merges.

We kept CodeRabbit too

We kept CodeRabbit when the Codex reviewer got good. They do different jobs.

CodeRabbit is fast and it comments on everything: style, naming, the line-level bug a careful pass catches. Codex is slower and pickier. It goes after the design and correctness bugs, the ones you only see with the whole change in your head.

So we run both. Two reviewers is cheap next to one bad merge.

Codex lets you swap the harness

There is one real difference under the hood, and it barely touches us.

Codex lets you bring your own harness. The CLI is open-source Rust, so you can drive the Codex models from something else: opencode, pi-mono, or a harness you write yourself. Claude Code keeps you on its own CLI.

On paper that is a win for Codex on lock-in. In practice we run both in tmux panes on the same box. Two panes doing work. The harness underneath does not change how we start, watch, or stop them.

We like having the option. We have not needed it yet.

How we settle Codex vs Claude Code

No agent merges its own work, so a human reads every agent PR. That read is where quality shows, not a benchmark. We watch how often we rewrite the diff, how often a review comment misses, how often a run burns twenty minutes and hands us nothing.

When that is not enough to settle it, we look at the traces. Both tools export OpenTelemetry, so the tokens, cost, and tool calls from both land in one place and the argument gets numbers. We compare on cost per merged PR. That is the number that survives a price change, not cost per token.

Tracking Claude Code usage this way, across a whole fleet of agents, is its own hard problem. It is the Agent Governance side of what we build.

We also quit reading Codex vs Claude Code benchmarks to decide this. Your own repo, skills, and CI settle it better than any leaderboard. Want a real answer? Run both on two weeks of your own tickets.

Nobody sat down and assigned Claude the building and Codex the reviewing. It is just where each one landed once we had run them long enough to stop guessing. A strong model release on either side will probably move a job from one to the other, and the transcripts we kept are what make moving one cheap.

Get started

Put this into production with LangWatch.

Trace your agents, run evaluations, and turn failures into repeatable tests.

Frequently asked questions

Is Claude Code or Codex the better background agent?
For us it splits by job. Claude Code is the better builder and runs most of our background agents, the ones that open PRs. Codex is the better reviewer and runs the one that reads a diff and grades it: on demand when we want a second opinion on our own PR, and on a weekday-morning schedule that reviews pull requests from outside the org. The ranking moves with every model release, so the honest answer is to run both on two weeks of your own tickets rather than trust a leaderboard.
Can you use Codex and Claude Code together?
Yes, and we do daily. Both read plain markdown instruction files (CLAUDE.md and AGENTS.md), we run both inside tmux, and our Codex agent reviews the pull requests our Claude Code agents open when we ask it to. It also runs a scheduled weekday-morning scan that reviews pull requests from outside the org, forks included, treating that code as untrusted. Having the reviewer be a different model from the author is close to free and catches mistakes a model tends to wave through in its own work.
Is Codex a better code reviewer than CodeRabbit?
They do different jobs, so we keep both. CodeRabbit is fast and thorough on the nitpicky layer and hidden line-level bugs. Codex goes after the critical design and correctness issues, what we track as P1 and P2. Paying for two reviewers is cheap next to one bad merge.
Can you run Codex with a different harness?
Yes. The Codex CLI is open-source Rust and you can drive the models from another harness like opencode, pi-mono, or one you build yourself. Claude Code keeps you on its own CLI. We run both inside tmux, so from where we sit the harness underneath does not change how we start, watch, or stop them.
How do you measure which coding agent is better?
Because no agent can merge its own work, quality shows up as review friction: how often we rewrite the diff, how often a review comment misses, how often a run produces nothing worth merging. When that is not enough we trace sessions over OpenTelemetry, which both tools export, and compare on cost per merged PR, the one metric that survives pricing changes.