A migration too big for one context, cut into pieces that fit.
One agent doing a whole migration fills its context halfway through and starts losing what it decided in the first module. Here the coordinator writes the rules down once, gives each module to its own helper in its own worktree, merges the branches back, and hands the result to a reviewer that touched none of it.
Free and open sourceRuns on Mac and LinuxYour own Claude and Codex logins
Recorded on a demo machine: helpers report back to the coordinator, which then sums up.
Halfway through a migration, one agent forgets how it started
The first modules get careful work. By the later ones the context is full of diffs, the early decisions have been compacted away, and the same pattern gets done three different ways across the repo.
One agent on its own
One context holding every module
Early decisions lost by the end
Each module done a little differently
One huge diff to review at the end
Agents side by side in Overvibe
One helper per module, with a short brief
The rules written once, read by every helper
A branch per module, merged one at a time
A reviewer reading the merged result fresh
Split, mergeand review at the end
You type
❯Migrate src from the old db client to the new one, one helper per module in its own worktree, then have Codex review the merged result.
1The coordinator maps it out
It lists the modules and writes the rules every helper follows into MIGRATION.md.
2One helper per module
Each in its own worktree under the coordinator, briefed with MIGRATION.md and its folder.
3Branches come back
When a helper stops, its branch and the merge command arrive in the coordinator.
4Merge and test
One branch at a time, with your test suite between merges.
5A fresh review
Codex reads the merged diff against MIGRATION.md and reports anything that drifted.
Behind it, a helper and the reviewer. The coordinator runs the first command once per module. By default a session can run 8 children at a time; Settings > Spawn limits changes that. Read the CLI reference
$ overvibe new --attach --worktree --cwd . --name "db: billing" \
--prompt "Migrate src/billing to the new db client, following MIGRATION.md, and commit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<summary>\""
$ overvibe new --attach --tool codex --cwd . --name "db: review" \
--prompt "Review git diff main against MIGRATION.md. Report drift and bugs. Do not edit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<review>\""
Keep it to one agent if
the change fits in one sitting: a rename across a handful of files, one module's internals, a dependency bump. Splitting has its own cost. Every helper needs a brief, and branches that touch shared code can conflict when you merge them.
Questions
What about code every module shares?
Change it first, in the coordinator or one helper, and merge it before the others start. Otherwise every branch changes it a little and the merges fight.
Can helpers be different tools?
Yes. Mix Claude Code and Codex helpers with --tool; they all read the same MIGRATION.md.
What if a helper gets stuck?
When it's waiting on you, its row turns amber. The coordinator can see its screen with overvibe peek and give it the next step with overvibe send.
