Show HN: A local merge queue for parallel Claude Code agents

funador 26 points 8 comments July 30, 2026
github.com · View on Hacker News

I have been pushing up to 90 commits a day on a MacBook Air via 4-5 parallel agents. As you can imagine when all the agents try to build, test and run dev servers on an 8GB machine it is the fast lane to a force quit and restart. I also did not want to pay the CI minutes on 90 pushes a day. So I designed a local merge queue to have all commits land one at a time and fully tested. Hopefully this helps other folks with more modest machines. Appreciate any feedback.

Discussion Highlights (3 comments)

orsorna

I have CI set up so that I can just let that handle builds and exclusive locks for me, but there are particular limitations (network connectivity is mandatory). I did this because I wanted to avoid something like you built, which theoretically can't scale as well as a dev box (much easier to extend deploy environments versus my local machine). I can see that you are working within resource constraints though which is admirable :)

barrkel

A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj? I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees. It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.

ElijahLynn

Definitely going to look into this! I just built something pretty much in the same vein of this with Claude over the past 2 months. It's a custom deployment system that uses work trees and each work tree has to to run end-to-end tests (Playright, Supabase, Astro) and other tests and create a stamp based on the contents of the entire tree. And then if another work tree has the same digest that matches the stamp then it can bypass the tests. So nothing can land on main without tests passing. Which is all in in enforced with a pre-push hook that checks the digest. Then once it's on main it is deployed to Dev and then from there it can be promoted to prod. I like the idea of just having one branch and the work trees funnel into it. But definitely going to have my setup analyze this and see what can be improved with it or if I should just throw out mine and use that one.

Semantic search powered by Rivestack pgvector
15,380 stories · 143,452 chunks indexed