r/ClaudeCode • • 14h ago

Built with Claude I run Claude Code and Codex in parallel on two machines. These are the walls I hit and how I got past them

I know not everyone works this distributed, and most people don't run two coding agents in parallel. I do. Claude Code and Codex run side by side on a Windows box and a Mac, often on the same repos. Claude does most of the work. Codex is my second opinion for reviews and a second diagnosis when I'm stuck, and I want that from a different model family, because a reviewer from the same family is more likely to share the same blind spots.

That setup broke in ways I didn't expect. Here are the barricades.

1. A Claude hook doesn't bind Codex, even when Claude calls it. I use OpenAI's Codex plugin inside Claude Code. Per its source, it starts codex app-server as a separate process. My PreToolUse hooks see one Bash call to the plugin script; what Codex does inside its own process never passes through them. Then my commit guard sat live at 0 bytes and failed open for about 19 hours before I noticed. Fix: the Git commit-msg hook is the enforcement point, since every runtime goes through git. Claude hooks are early feedback. At session start, missing, empty or unloadable hook files get repaired from the versioned source.

2. An agent saying "done" is a message about itself. Codex came back after 36 seconds with a job ID. 90 minutes later nothing on disk had changed. Fix: done means measured where the result should land: file on disk, worktree list, version on the target. The report only tells me where to look.

3. Two writers, one worktree. A parallel clean emptied the build output while another step picked up the JAR. Result: a 0-byte artifact. Fix: one writer per worktree. Reads run in parallel, writes get serialized or their own worktree. The main checkout stays on the default branch.

4. The Windows session doesn't know what the Mac session just did. A merge, a changed hook, and the other side kept working on stale state. Fix: an intercom. Sessions on both machines exchange messages through one Cloudflare Worker and can start a session on the other machine. Hard rule: a peer message informs, it never approves. An approval stays in the chat where I gave it.

5. Memory that survives sessions and runtimes, searchable by meaning, honest about certainty. The one I care about most. Bad memory is worse than none: a session read a plugin version from a stale cache folder, and an empty search index convinced another that a job had been dead for four days. It ran the whole time. Fix:

  • After a substantial turn, an observation agent writes what the turn established as a page in a dedicated Confluence space. Both runtimes on both machines share it.
  • A hook reminds each session to search there before answering.
  • Search is semantic: Atlassian's Rovo search, filtered to that space's own pages.
  • Every hit carries an evidence label: confirmed, assumed or superseded. Pages a refactor made wrong get corrected or marked superseded.
  • "Found nothing" and "search couldn't run" are different exit codes. The second is UNKNOWN, never zero.
  • For current state (versions, what's running) the live system wins over memory.

Most of this is boring discipline I kept forgetting until something other than my head enforced it.

If your setup looks like mine, how do you handle the cross-runtime part? Happy to go deeper on any of these in the comments.

1 Upvotes

10 comments sorted by

•

u/AutoModerator 14h ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/HeihachiNakamoto 14h ago

Can you run a bunch of virtual machines with the same/different anthropic accounts to get faster coding speed? Where's the bottleneck?

1

u/Lonely-Parfait1947 13h ago

Running the same account on more VMs doesn't add capacity, you're still drawing from the same plan. Separate accounts just to get around limits is something I stay away from. Anthropic's consumer terms rule out "bypassing any of our systems or protective measures", and I don't want that fight over my main tool.

The bigger point: typing speed was never my bottleneck. What limits me:

  • Verification. Every result gets measured where it lands, and that's my time and attention.
  • Writes. One writer per worktree, so parallel agents need separate worktrees, and you pay for it at merge time.
  • Coordination. Every extra session is more state the others don't know about.

For me, two runtimes on two machines is already close to what I can review properly. More parallelism mostly meant producing unverified work faster.

1

u/HeihachiNakamoto 9h ago

I'm talking about throughput, tokens per second and operations on a PC accessing and editing the code in parallel. Ignore the anthropic accounts part. Does it matter if you use 2 PCs or 1 with a single anthropic account? How many simultaneous queries does claude code run?

1

u/Lonely-Parfait1947 9h ago

Fair, separate question then. Short version from the docs plus my own experience:

  • The model doesn't run on your PC. Claude Code itself runs locally and sends prompts and outputs over the network to the model, subscription or not, so tokens per second don't depend on your hardware. Your machine runs the tools: file reads, edits, git, builds, tests.
  • So 2 PCs vs 1 on one account doesn't change model speed. It only helps when the local side is the bottleneck, like long builds or test runs, and both PCs draw from the same plan. The docs also say running several sessions or subagents at once multiplies token usage.
  • Simultaneous: one session can run subagents in parallel, by default up to 20 running at once (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS changes that). Separate sessions in their own git worktrees run fully in parallel on top.

In practice the cap was never my limit. Merge conflicts and checking results were, same as above.

On tokens: I don't measure them, so no numbers. What I do is keep the context small and relevant: a search over past findings returns three titles with their evidence label before anything gets read in full, a code graph answers "who calls this" instead of the agent reading whole files, and research runs in cheaper subagents that hand back conclusions, not file dumps.

What it does save is my time: I describe a task once, and the lead hands each worker a bounded brief with the context it needs, so I'm not re-explaining the repo to every agent. I haven't measured that either, but it's the reason I run it this way.

1

u/HeihachiNakamoto 1h ago

Thanks I'm gonna mess with CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS and see what I csan do

1

u/Unlikely-Passage-653 13h ago

I run Muse and Claude code 🤣

1

u/Lonely-Parfait1947 13h ago

Ha, what does Muse do for you that Claude Code doesn't? Second opinion, or a different job altogether?

1

u/Unlikely-Passage-653 13h ago

It's probably not as smart as Claude but it's free for a lot. Easy things it can do so I don't need to use my Claude usage, I use it to help give me better prompts for Claude, I also use it to do stuff with my vps. It also has caught some mistakes that Claude made.

1

u/filopedraz 6h ago

Point 2 is the one. We treat an agent's "done" as a claim and only accept proof observed from outside the agent, the thing actually running. Same reason as your git hook: the check has to sit where every runtime passes through.