I run Claude Code and Codex every day, sometimes on the same repository. The question is whether the second agent saves more time than it creates in coordination.
So I pulled my session logs to check the first part. The working tree answered the second.
How I split the work
Claude Code is still my first choice for coding. I have not found anything better for complex development work, especially when the logic gets difficult. It handles most feature work, refactors, reviews, and content tooling. I also use it for longer conversations where a lot of project context stays active.
I prefer Codex for content, marketing, and analysis. On those tasks, I think it can be as good as Claude Code and sometimes better. It also takes whatever independent task Claude Code is not holding. Its input turned out lopsided in a way I would not have guessed before counting: on the laptop two thirds went to a single site build, and on the desktop two projects took over three quarters, neither of them this site. It contributes here too, so both agents sometimes leave changes in the same working tree.
That overlap needs rules. I treat unfamiliar uncommitted changes as someone else's active work, not mine to clean up. Each agent stages only its own files, never reverts what it did not create, and reports the rest of the dirty tree.
I also keep one source of truth for project guidance. Claude Code reads CLAUDE.md; Codex reads a short AGENTS.md that points to the Claude files. Duplicating the rules would guarantee drift. In my setup, that lets me carry the same approach across machines, fresh sessions, and repositories: the durable part is checked into the project, not trapped in one chat. The exact rules differ by repository, but the pattern stays the same.
That does not give the agents shared memory or a live view of each other's work. It gives them the same operating rules. Both can inspect the working tree, Git history, and handover files, so an agent can see that a change exists and, when the handover records it, who owns it. The rule is still simple: treat an unfamiliar uncommitted change as active work, not something to clean up. Handover notes carry the state a new session or the other agent cannot see for itself.
What the logs showed
Both agents write their own session logs, so the counting is local and I can redo it whenever I want. Neither tool syncs those logs between machines, so each one has to be counted where it sits. This covers both of mine: nine projects for Claude Code and eight for Codex on the desktop, seven and six on the laptop, with the two lists overlapping.
The windows are not the same length, and the second machine made that worse rather than better. Codex logs on the desktop reach back to early June and cover 28 active days, against two weeks and 8 days on the laptop where it is newly installed. Claude Code covers 15 desktop days and 16 laptop days. The active days overlap, so they do not add up to a clean total, and the totals below cover a longer stretch for Codex than for Claude Code. Read the table as a shape, not a benchmark.
| Claude Code | Codex | |
|---|---|---|
| Active days | 15 desktop, 16 laptop | 28 desktop, 8 laptop |
| Projects | 9 desktop, 7 laptop | 8 desktop, 6 laptop |
| Input tokens | 8.98 billion | 5.82 billion |
| Output tokens | 21.8 million | 19.9 million |
| Input to output | 412:1 | 292:1 |
| Cached input | 97% | 95% |
One figure is near enough identical for both. Roughly 96% of everything either agent read came from cache. The volume is not the same: Claude Code carried about 410 input tokens for every token it wrote, Codex about 290.
Adding the desktop narrowed that gap. On the laptop alone the two read 524:1 and 332:1, which looked like a real difference in how the tools work. Across both machines it is 412:1 and 292:1. Same direction, smaller gap, and a reminder that one machine is a small sample of your own habits.
I would not read the remaining gap as one tool being wasteful either. The windows are different lengths, the work is different, and long sessions with a lot of live project context are exactly what I point Claude Code at. The visible output is the small part. Most of the traffic is context.
That is a token-traffic pattern, not a cash bill. OpenAI's current Codex pricing documentation says usage depends on the model, task size, context, reasoning, and tools. It also prices cached input differently from new input and output. What I can conclude is simpler: project context dominates the token count in my sessions.
Counting this is easy to get wrong
My first pass at these numbers was wrong twice over, and both mistakes are easy to repeat.
Claude Code writes one transcript record per content block. A reply that says something and then calls a tool logs its usage block twice, sometimes more. Sum the file without deduplicating on request ID and you roughly double both totals. Of 122,447 usage records across the two machines, only 56,178 were distinct calls, and the ratio held at about 2.2 on each one separately.
Codex logs a running session total on every turn rather than a per-turn delta. Add the totals up and you get a triangular number. My first pass on the laptop produced 1.25 trillion input tokens, about 740 times the real figure. The per-turn field is the one to sum.
If you run this on your own logs, check the result two ways before you believe it. I trusted the first number. It was wrong.
Context needs a budget too
I used to focus mostly on the visible output: generated code and diffs. The logs changed that. A long conversation can keep sending project rules, file contents, chat history, and tool results even when the final change is small.
That changed three things in how I work:
- Start a fresh session when old context no longer helps the task.
- Keep project instructions short and load detailed rules only where they apply.
- Scope the request and source files before asking the agent to work.
Caching makes this much cheaper than resending everything as new input, but cached context is not free. Smaller context costs less and gives the agent less irrelevant material to trip over.
Rate limits are part of planning
The Codex logs also stored my position in a rolling seven-day limit, and this is the one place where the second machine changed the answer instead of enlarging it.
Counting the laptop alone, one day crossed 80% and peaked at 94%, and every other day topped out at 45% or lower. That reads as a single bad day. Both machines together show six days over 80%: five consecutive ones on the desktop running 83 to 93%, then the laptop's 94% two days after the last of them. It is one account and one rolling window, read from two places, and neither machine on its own saw the whole week.
So the conclusion I would have drawn from one machine was wrong in a specific way. One spike is something to plan around. A week spent near the ceiling is a working pattern, and the fix for it is different.
That is my usage for that period, not a published allowance for every plan. Codex limits vary by model, task, context, and plan. Current Codex documentation points users to the usage dashboard and /status.
My rule is simple: check the remaining allowance before starting work that is hard to hand over. Discovering the limit halfway through a migration is poor planning (and an avoidable handover).
Claude Code left no matching historical limit series in the transcripts on either machine, so I cannot compare the curves honestly. I did not hit its limit during that window, but one person's usage does not prove its limits are higher.
Where Cursor fits
It does not, for me. I have never used it and it is not installed on my machines.
Cursor now has a terminal agent as well as the editor, so working in a terminal no longer rules it out. I already use two agents and have not tested a third. Someone who has can make the comparison I cannot.
Is the second agent worth it?
For me, yes. Waiting for one agent sometimes stopped work I could give to the other. The second agent keeps an independent task moving and gives me another path when one service reaches a limit.
The cost is coordination. That gets sharper when running a pile of agents: one rule source, disciplined commits, tolerance for a dirty working tree, and a handover when work changes tools or machines. The exact pair is not the point. More agents do not fix coordination. They make shared rules and deliberate handovers more important.
If you work on one project at a time and rarely wait for the agent, that cost may buy nothing. Add a second agent when blocked work is expensive enough to justify the extra state.
What this comparison does not prove
These numbers come from my projects and my way of working. Both machines are in now, which removes one caveat and sharpens another: the Codex window is much longer than the Claude Code one, so the totals are still unsuitable for a direct tool comparison. They do not measure output quality either.
The logs made both costs visible: context, and coordination between two agents. I can manage both once I can see them.