> ## Documentation Index > Fetch the complete documentation index at: https://mint.skeptrune.com/llms.txt > Use this file to discover all available pages before exploring further. # Parallelize Coding Agents with Git Worktrees and Tmux > Run multiple AI coding agents in parallel with isolated git worktrees. Includes the probability math, a tmux workflow, and the uzi CLI built to automate it. If you're underwhelmed with AI coding agents or simply want to get more out of them, give parallelization a try. After seeing the results firsthand, the throughput improvements are incredible — and the key insight is that you don't lose control of the codebase when you do it right. The effectiveness of using Git worktrees for simultaneous agent execution is gaining broader recognition. It's mentioned in [Claude Code's docs](https://docs.anthropic.com/en/docs/claude-code/tutorials#run-parallel-claude-code-sessions-with-git-worktrees), discussed on [Hacker News](https://news.ycombinator.com/item?id=44043717), implemented in projects like [Claude Squad](https://github.com/smtg-ai/claude-squad), and actively discussed on [X](https://x.com/search?q=git%20worktree\&src=typed_query\&f=live). ## Why parallelization works The core insight is probabilistic. A single LLM has some probability — say 25% — of producing a useful solution to a given UI or feature task on the first try. If you run four agents independently with the same prompt, the probability that at least one succeeds is: ``` 1 - 0.75^4 ≈ 0.68 (68%) ``` Four agents gives you a 68% chance of getting a workable result. Running one gives you 25%. That's the math that justifies parallelization. With LLMs being so affordable, there's virtually no downside. The cost difference between using one agent ($0.10) versus four ($0.40) is negligible compared to the 20 minutes of development time saved. The financial risk is minimal, so you can afford to be aggressive. ## Example: Adding a UI component Here's a concrete example. When building [astrobits](https://astrobits.dev), a component library, the task was to add a `Toggle` component. To tackle it, two [Claude Code](https://www.anthropic.com/claude-code) agents and two [Codex](https://openai.com/index/introducing-codex/) agents were deployed — all with the same prompt, running in parallel within their own [git worktrees](https://git-scm.com/docs/git-worktrees). Worktrees are essential because they provide each agent with an isolated directory, allowing them to execute simultaneously without overwriting each other's changes. The results: | Agent | Result | | ---------- | ----------------------------------------------------------------------------- | | `claude-1` | Mostly correct, workable, but pixelated border-image and shadow needed fixing | | `claude-2` | Completely broken — sliding circle too small, wrong color | | `codex-1` | Very wrong — shadow on top, active state on wrong side | | `codex-2` | Unusable — circle color wrong, active side incorrect | Only one of four produced something that saved time. That validates the math: four agents at \~25% each gives roughly a 68% chance of getting at least one workable result. The number of agents you deploy should scale with task complexity. Simple tasks might need only two. Novel or ambiguous tasks might warrant six or more. You'll develop intuition for this over time. ## The current manual workflow Right now, the parallel workflow goes like this: 1. Manually create git worktrees with `git worktree add -b newbranch ../path` 2. Start a `tmux` session for each worktree 3. Run Claude Code in the first pane, paste the prompt 4. Open a new pane with `leader+c`, run `yarn dev` to get a preview 5. Switch to the browser to review results 6. Repeat for agents that didn't succeed 7. Commit, push, and create a PR for the successful output This works, but it's cumbersome. The top pain points: * **Branch tracking confusion.** You can't tell which branch a worktree was most recently rebased onto. If `agent-1` was rebased onto `feature-x` but `agent-2` onto `main`, you lose track without manual notes. * **No broadcast prompting.** If all agents are stuck on the same misunderstanding, you have to copy-paste the clarification into each session individually. * **Opening your IDE is clunky.** To open VS Code for a given worktree, you have to `tmux a`, `leader + c`, then `code .`. A keyboard shortcut for this would help enormously. * **Port management for previews.** Running `yarn dev` in each worktree means mentally tracking which port each worktree is on. * **Committing and PRs are manual.** After finding a solution in `agent-3`, you manually attach to that tmux session, then `commit`, `push`, and `gh pr`. ## Proposed solution: uzi To address these challenges, the ideal developer experience would involve a lightweight CLI that wraps tmux and automates the orchestration. Nick and his co-founder Denzell are building exactly this: [uzi](https://github.com/devflowinc/uzi). The core idea is to abstract away the manual, repetitive tasks while staying close to existing mechanics. The goal is to feel at home using `uzi` alongside standard Unix tools like `xargs`, `grep`, and `awk`. Here are some of the planned commands: ```bash theme={null} uzi start --agents claude:3,codex:2 --prompt "Implement feature X" ``` Initializes three Claude instances and two Codex instances, each in its own worktree, each with the prompt already running. ```bash theme={null} uzi ls ``` Displays all active agents, their target branches, and current statuses. Solves the branch-tracking problem at a glance. ```bash theme={null} uzi exec --all -- yarn dev ``` Runs `yarn dev` across all agent worktrees simultaneously. No more mental port mapping. ```bash theme={null} uzi broadcast -- "Refine the previous response by focusing on Y" ``` Sends a follow-up prompt to all active agents at once. Solves the copy-paste problem immediately. ```bash theme={null} uzi checkpoint --agent claude-1 --message "Implemented initial draft" ``` Rebases the specified agent's worktree and commits the changes. ```bash theme={null} uzi kill --agent codex-2 ``` Cleans up a specific agent's tmux session and optionally its worktree. These commands operate via `tmux send-keys` instructions to the appropriate sessions — no wheel reinvention, just polish on the existing process. ## The future is parallel: beyond code The parallel agent pattern isn't limited to software. The principle — run multiple agents independently, review outputs, select and merge the best — applies universally. Consider transactional law. A company like [versionstory](https://www.versionstory.com/), which is pioneering version control for legal documents, could let attorneys run multiple agent instances to redline a contract. After reviewing outputs, they select and merge the best components. The final review is based on multiple independent analyses rather than a single agent's judgment. Or consider marketing analytics. A team could prompt multiple AI instances to analyze ad performance data, then select the most insightful analyses to inform strategy. More coverage of the solution space leads to better decision-making. Expect existing software products to gain more powerful version control and parallel execution capabilities in the coming years — emulating what git worktrees enable for software development, but across every knowledge-work domain. The parallel paradigm is a glimpse into a more efficient, robust future for AI-assisted productivity. For now, the workflow is a bit manual — but it's already dramatically effective, and tools like `uzi` are making it smoother.