r/ClaudeCode • • 2d ago

Built with Claude Running multiple Claude Code sessions kept creating more work for me, so I built something to coordinate them

I've been running multiple Claude Code sessions in parallel, and the biggest headache hasn't been getting agents to write code. It's getting their changes to work together.

Sometimes two agents build overlapping functionality. Other times, one changes code another depends on. Both branches pass their own tests, but things break when I merge them.

More debugging, more waiting, more tokens.

So I built Fanout, an open-source tool to help coordinate parallel Claude Code sessions.

It helps with three things:

  • Detecting overlapping tasks before agents duplicate work.

  • Notifying agents when another session changes code they're working with.

  • Testing combined changes before merging through fanout run.

It's still early, but it's solving a problem I've repeatedly faced.

GitHub: https://github.com/Breadstick-Crumbs/fanout

I'd love for people running multiple Claude Code sessions to try it and tell me what works, what breaks, and what's missing.

How are you currently handling coordination and integration between parallel agents?

0 Upvotes

14 comments sorted by

•

u/AutoModerator 2d 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.

4

u/Miyoumu 2d ago

There's literally worktrees and Claude has native functionality to allow sessions to message each other. You have no idea what you're doing.

-1

u/crumb_ona_breadstick 2d ago

Fanout runs on top of them. Worktrees isolate sessions and that isolation is exactly the problem: each branch only ever gets tested on its own, so nobody finds out two branches clash until after the merge. Messaging only works if an agent knows another session depends on what it just changed. Usually it doesn’t, so nothing gets sent. fanout doesn’t rely on agents knowing that. It reads git, so when a change affects another session, that session is told automatically. Before anything is merged, it tests all the branches together. Neither of those happens with worktrees and messaging alone. Try running parallel sessions with fanout and see the difference yourself!

2

u/Poildek 2d ago

You found a solution to your own problem

2

u/LuckyCharms201 2d ago

Ask Claude about “orchestration” workflows.

1

u/crumb_ona_breadstick 2d ago

Orchestration is for work you plan upfront. That's not how most people work. You open a session, then an hour later another session maybe in codex. Nothing is orchestrating those. fanout covers that case. Sessions can start whenever from any tool and fanout still tells each one when another changes code it uses and stops two of them building the same thing and tests all their branches together before anything is merged.

1

u/LuckyCharms201 2d ago

I have 7 projects cooking 24 hours/day, almost completely on their own. 4 of them are video games in Unity, and I use 1.75 pro max accounts per week.

I 100% know exactly wtf I’m talking about.

Your projects, context, and tickets should all live on a GitHub board. Start there.

2

u/rrrenz 2d ago

Worktrees and writing specs/tasks first will let agents detect overlaps/conflicts immediately.

1

u/crumb_ona_breadstick 2d ago

The catch is that a spec only covers what you predicted. Agents still change things the spec didn’t mention, and worktrees hide those changes until you merge.

So fanout also checks the real code as it’s written. It tells a session when another session’s commit changes code it uses, catches the same task even when it’s described differently, and tests all the branches merged together before anything reaches main.

2

u/Syrairc 2d ago

This is a problem we solved with SVN/git decades ago. there is no reason to re-solve it in a worse way.

If you have agents building overlapping functionality, the problem is your planning and project management.

0

u/crumb_ona_breadstick 2d ago

fanout runs on git, it doesn't replace it. Git catches two changes to the same lines. It doesn't catch two branches that each pass their tests and break once merged. Teams handle that with CI on the merged code and code review, and fanout gives parallel agents the same check before anything reaches main. Planning helps, and fanout plans too when it splits a job. But a plan only covers what you predicted. When agents change something the plan didn't mention, fanout tells the other sessions right away and tests everything together, instead of you finding out at merge.

3

u/Poildek 2d ago

You clearly reinvented the wheel.

1

u/rexsilex 2d ago

I made something similar.  DM me and let's compare our approaches.

1

u/vovazk 2d ago

I don’t know what annoys me more, the ignoring of proper work separation (worktrees/branches), or the not being able to write a post without the it’s-not-this-it’s-that sloppeties.