DEV Community: Eliseo Fernandez Suarez

How we run five coding agents side by side in one window

Eliseo Fernandez Suarez — Sun, 23 Aug 2026 23:12:04 +0000

I build NestMux, a desktop app that runs Claude Code, Codex, Gemini CLI, Copilot and OpenCode in a grid of real terminals, each with its own account and its own git worktree. This is how it works inside, including the parts that are heuristics wearing a confident UI and the parts that do not survive a restart.

If you are building something similar, most of this transfers. If you are deciding whether to use it, this is the honest version of what it does.

Thirty-five seconds of it running, so the rest of this has something to attach to:

The unit is a pane, and a pane is smaller than you would think

Every cell in the grid is described by a plain object. Simplified, and this really is most of it:

interface PaneNode {
  id: string
  aiType: 'claude' | 'codex' | 'gemini' | 'copilot' | 'opencode' | 'terminal' | 'custom'
  accountName: string
  accountDir: string        // becomes HOME for this pane's processes
  cmd: string               // '' means a plain shell
  repoPath?: string         // cwd override: the worktree this pane works in
  shellId?: string          // which shell to spawn on Windows
  borderColor: string
}

There is no AI-specific code behind any of it. A pane spawns a shell with node-pty, redirects HOME to accountDir, sets the cwd to repoPath, and types cmd into it. Claude Code is a pane whose cmd is claude. A plain terminal is a pane whose cmd is empty. Adding support for a new agent CLI is a row in a list, which is why custom CLIs are a user-facing feature rather than a release.

The reason it is worth saying out loud: everything below is about the environment around the process, not about the agent. We do not parse the agent's output, we do not wrap its API, and we do not know what it is doing. It is a program in a terminal.

The two things that make it more than five terminals are what accountDir and repoPath are pointed at.

accountDir is an isolated HOME, so two panes can be signed into two different Claude accounts at once, and ~/.claude means something different in each. repoPath is a git worktree, so four agents editing the same repository do not overwrite each other. I wrote up the Windows specifics of both separately, because that part is genuinely fiddly and not interesting here.

Broadcast is four lines and that is the good part

Sending one prompt to every pane sounds like it needs a protocol. It does not. The terminal emulator already hands you every keystroke:

term.onData((data) => {
  const targets = broadcastMode ? panes.map(p => p.id) : [pane.id]
  targets.forEach(id => window.pty.write(id, data))
})

That is the whole feature. Because it operates on raw input rather than on a message, it works with anything that reads a terminal: agents with their own TUI, a REPL, git rebase -i. Nothing had to be taught about it.

The cost of that simplicity is real and worth stating. It broadcasts everything, including Ctrl+C and arrow keys. It does not check whether a pane is ready, so if one agent is still booting it gets your prompt as input to whatever prompt it happens to be showing. There is no "wait for all panes to be idle". That is a design position, not an oversight: the moment you add readiness detection you are parsing agent output, and then every CLI update can break you.

Attribution is the part that is actually hard

Showing CPU, memory and open ports per pane sounds like bookkeeping. It is the hardest thing in the app.

The problem is that the pane's own process is a shell, and nobody cares about the shell. The agent is its child. The dev server the agent started is a grandchild, or worse, has been reparented and is nobody's child at all. If you measure the PID you spawned, every pane reads about 77 MB and looks idle.

So you resolve the whole tree per pane, per polling cycle. On Windows that means one Get-CimInstance Win32_Process snapshot for the entire machine, cached for a second and a half and shared by everything that needs it in that cycle, then walked in memory. (Why not pidtree is its own story.)

And when the parent link is gone, which on Windows it frequently is, the fallback is the filesystem:

const prefix = rootPath.toLowerCase().replace(/\\/g, '/').replace(/\/+$/, '') + '/'
for (const [pid, path] of snap.pathByPid) {
  if (path.toLowerCase().replace(/\\/g, '/').startsWith(prefix)) out.add(pid)
}

If a process's executable path or command line points inside a worktree, that process belongs to that worktree's pane. For processes that do not carry the path either, there is a third pass that reads each process's current directory, which on Windows means going through ntdll because there is no API for it.

Be clear about what this is: a heuristic. It attributes correctly for the common cases and it misses elevated processes and processes from other users, because OpenProcess refuses them. The resource bar is a good signal and it is not accounting.

Reviewing is a git command and a parser

Four agents produce four diffs, and the first version of this app made you read them with git diff in a fifth pane. The diff viewer is deliberately thin:

execFile('git', ['-C', worktreePath, 'diff', '--no-color', '--unified=3', base])

Then parse the unified diff into files and hunks in about a hundred lines. No library, no server, no LSP.

Two decisions in there that matter more than the parsing. Files over 10,000 lines get marked oversized and are not rendered, because one regenerated lockfile will otherwise freeze the renderer while it builds a hundred thousand DOM rows. And base defaults to HEAD, which means what you see is uncommitted work. That is the right default for reviewing an agent that just finished, and it is the wrong one if the agent committed as it went, which several of them now do by default. You can pass another base. Most people do not know that, which is a UI failure rather than an engine one.

What survives a restart, and what does not

session.json holds the pane descriptors. Types, account names, colors, repo paths, layout, tab structure. It is written atomically, serialize first, write to a temp sibling, rename over the real file, because a crash mid-write used to leave truncated JSON that failed to parse and took the whole workspace with it.

What it does not hold is any terminal state. Scrollback lives in memory in the main process and dies with the PTY. Reopening the app respawns the panes and re-runs the CLIs. Your grid comes back, your agents restart, and the conversation on screen is gone.

In practice that hurts less than it should, because the agents keep their own histories and most of them can resume a session. But it is a real limit and the app does not pretend otherwise: the panes are containers for processes, not a saved document.

What I would fix first

The thing the app is worst at is the thing this whole design makes hardest. Every pane is an opaque process, which is why adding a new agent is trivial. It is also why there is no unified log: no single timeline with timestamps and exit codes across panes, telling you which agent touched which file and in what order. There is a per-pane transcript you can export and that is all.

That gap is the price of not parsing agent output, and I have not found a way to close it that does not involve becoming a wrapper around each CLI. Filesystem watching per worktree is the obvious idea and it tells you what changed without telling you who did it. If you have a better one, that is the comment I want.

NestMux runs on Windows 10 and up, macOS 13 and up, and Linux, same build on all three, local-first with no telemetry. It is at nestmux.com, free during launch.

wmic is gone and your Node process tree is silently wrong on Windows 11

Eliseo Fernandez Suarez — Sun, 23 Aug 2026 22:59:00 +0000

The last post I wrote here ended on a line I had to go and check: killing a shell does not kill what the shell started. This is what I found underneath it, and one of the things is a dependency a lot of people have without knowing.

Numbers below come from Windows 11 Home, build 26200, in August 2026. Run the commands yourself, they take a minute. I work on NestMux, which is where I hit this, but nothing here is specific to it.

The symptom

A terminal pane running a coding agent reported 77 MB of memory. That is roughly the PowerShell host and nothing else. The agent inside it, and the dev server the agent had started, were not being counted.

So the process tree was empty. Every pane looked like an idle shell.

wmic does not exist any more

Get-Command wmic

Get-Command : The term 'wmic' is not recognized as the name of a cmdlet...

Microsoft deprecated WMIC in Windows 10 21H1 and started removing it from the image in Windows 11 22H2. On a current install it is simply not there. This is documented and it was announced, and it is still going to break things for years, because wmic is buried inside libraries rather than in the code people wrote.

Which brings us to pidtree

pidtree is the standard way to get a process tree from Node. It backs pkill-style behavior in a lot of tooling and it has millions of downloads a week. On Windows, version 0.6.0 shells out to wmic.

npm i pidtree@0.6.0
node -e "require('pidtree')(process.pid,{root:true}).then(console.log).catch(e=>console.log('FAIL:',e.message))"

FAIL: spawn wmic ENOENT

Version 1.0.0 fixed it. It still tries wmic first, and falls back to PowerShell Get-CimInstance when that fails:

npm i pidtree@1.0.0
node -e "const m=require('pidtree');(m.default||m)(process.pid,{root:true}).then(console.log)"

OK [ 30520, 36000, 29244 ]

So check what you actually resolve, not what your package.json says. A caret range of ^0.6.0 will never reach 1.0.0. That was our case: the range said ^0.6.0, the lockfile said 0.6.0, and every call on Windows was throwing ENOENT into a Promise.allSettled that treated the rejection as "no children" and moved on. It was not an error anyone saw. It was a tree of size one.

That is the part worth repeating. This failure does not look like a failure. It looks like a process with no children.

Rolling your own: take one snapshot, not N queries

If you cannot upgrade, the replacement is Get-CimInstance Win32_Process. The instinct is to query per PID with a filter. Do not:

# one snapshot of everything
Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId
# 396 processes in 200 ms

# five filtered queries
1..5 | ForEach-Object { Get-CimInstance Win32_Process -Filter "ParentProcessId=$PID" }
# 517 ms

One full snapshot of 396 processes costs less than five filtered queries. The cost is in starting the CIM call, not in the rows. Take one snapshot per polling cycle, build a parent -> children[] map from it, and walk the map in memory for every PID you care about. If you are polling several panes every few seconds, this is the difference between a background cost you can ignore and one you cannot.

Killing the tree

Now the part from the previous post, with the actual output.

Start a grandchild. Root cmd spawns a cmd, which spawns timeout:

$g = Start-Process cmd -PassThru -WindowStyle Hidden -ArgumentList '/c','cmd /c timeout /t 90 /nobreak'
@(Get-CimInstance Win32_Process -Filter "Name='timeout.exe'").Count
# 1

Kill the root and only the root:

Stop-Process -Id $g.Id -Force
@(Get-CimInstance Win32_Process -Filter "Name='timeout.exe'").Count
# 1

Still alive. Windows has no process groups in the POSIX sense and no automatic reparenting cleanup. Stop-Process, and process.kill(pid) from Node, both terminate exactly one process. The descendants keep running, holding their file handles and their ports, with a parent PID that now points at a dead process.

taskkill /F /T walks it properly:

taskkill /F /T /PID $g.Id

SUCCESS: the process with PID 29828 (child process of PID 34112) has been terminated.
SUCCESS: the process with PID 39928 (child process of PID 37072) has been terminated.
SUCCESS: the process with PID 34112 (child process of PID 37072) has been terminated.
SUCCESS: the process with PID 37072 (child process of PID 39620) has been terminated.

Deepest first, then up. That ordering is the whole point: it resolves the tree while the links are still intact.

Which gives you the trap. If you kill the root first and then go looking for the descendants, the links you needed are gone. The orphans are still there, they are still holding whatever they were holding, and nothing connects them to the thing you were trying to clean up. Resolve the tree first, or hand the root to taskkill /F /T and let it do both.

One hazard while you are in here: Windows reuses PIDs, and aggressively. A PID you cached thirty seconds ago and are about to force-kill may now be something else. If you keep a PID map across polling cycles, validate it against a fresh snapshot before you kill anything.

When there is no parent link at all

The uncomfortable case. A coding agent starts a dev server in the background. On Windows that server frequently ends up with no usable ancestry back to the pane: the intermediate process has exited, the parent PID is stale or recycled, and the binary path is just node.exe. The command line does not carry the worktree it belongs to either.

What is left is the process's current directory. If the server's cwd is inside a given worktree, it belongs to that worktree.

There is no Node API for reading another process's cwd on Windows. On Linux it is /proc/<pid>/cwd, on macOS it is lsof, and on Windows you go through the kernel:

const koffi = require('koffi')
const ntdll = koffi.load('ntdll.dll')
const NtQueryInformationProcess = ntdll.func(
  'long __stdcall NtQueryInformationProcess(void*, int, _Out_ uint8_t*, uint32_t, _Out_ uint32_t*)'
)
// OpenProcess with PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
// then NtQueryInformationProcess to get PROCESS_BASIC_INFORMATION,
// then ReadProcessMemory to walk:
//   PEB + 0x20 -> ProcessParameters -> CurrentDirectory (UNICODE_STRING)

The offsets are x64 Windows 10 and 11. They are not a public contract, which is the honest caveat here: this is a documented-enough structure that tooling has relied on it for twenty years, and it is still something Microsoft can move.

Two things you will hit immediately. Elevated processes and processes from another user reject OpenProcess with access denied, and you get nothing back for them, so whatever feature you built on this silently does not apply to Docker Desktop and to services. Log those once per PID rather than per poll, otherwise a five second polling loop buries the console.

The short version

Check whether you resolve pidtree below 1.0.0. If you do, your Windows process trees are size one and nothing told you.
One CIM snapshot per cycle beats per-PID queries, by a lot.
process.kill and Stop-Process are not tree kills. taskkill /F /T is.
Resolve the tree before you kill the root, not after.
If you need attribution when the parent link is gone, cwd is the last reliable signal, and getting it on Windows means going through ntdll.

If you maintain something that manages child processes on Windows and you have a cleaner answer than the PEB walk, I would like to hear it. That is the part of this I am least happy with.

Isolation, file ownership and cleanup: the boring half of running coding agents in parallel on Windows

Eliseo Fernandez Suarez — Sun, 23 Aug 2026 22:50:34 +0000

Someone left a comment on my last post that was a better outline than the post was:

Parallel agents are only practical when the workspace boundaries are boring and explicit. On Windows especially, I would care less about the launch trick and more about isolation, logs, file ownership, and cleanup after failed runs.

That is Alex Shev, and he is right. Four agents in a pane grid is the screenshot. The four things he listed are what decide whether you are still using the setup in a month.

I work on NestMux, so I have a stake in this. Most of what is below is plain Windows and plain git, and the commands run the same whether or not you use it. Where I describe a decision we made, I say so, and I say where it still falls short.

Isolation is not one HOME variable

Two agents running under the same Windows account share ~/.claude, ~/.codex, ~/.gemini. Same config, and more importantly the same authenticated session. If you want two Claude accounts side by side, they need separate home directories.

On Windows, HOME is not the variable that gets you there. It is a POSIX convention that some tools honor and Windows itself does not. Set only HOME and you get a half-redirected agent: the CLI writes its config to the new location while git writes .gitconfig to the old one, and you will not notice until two panes start sharing a git identity. What you actually need per process:

HOME       = <accountDir>
USERPROFILE= <accountDir>
HOMEDRIVE  = C:
HOMEPATH   = \path\to\accountDir

Gemini CLI wants GEMINI_CLI_HOME pointing at its own subdirectory on top of that.

One trap if you are building the launcher rather than using one: Node's os.homedir() does not reliably reflect a USERPROFILE you injected at spawn time on Windows. If your app reads homedir() to decide where its own storage lives, and it also redirects USERPROFILE for child processes, those two will disagree. We ended up with a dedicated env var for storage and a separate function for "where a new shell should start", because collapsing them meant every new terminal opened inside the agent's config directory.

The config you do want shared

Full isolation is not what anyone wants. Your CLAUDE.md, your settings.json and your skills should be the same in every pane. So they get linked back to the global copy instead of duplicated.

On Windows that link is more annoying than it sounds. mklink for a file symlink needs elevation or Developer Mode. Junctions do not, so directories are fine. For files the fallback is a hardlink.

That fallback has a sting. A hardlink is not a symlink, so lstat().isSymbolicLink() returns false for it. If you later offer a "detach this account from the shared config" button and implement it as "replace symlinks with real copies", the hardlinked files are skipped, and the account goes on silently editing your global config while the UI says it is detached. Detecting them means comparing the file id:

const a = lstatSync(src,  { bigint: true })
const b = lstatSync(dest, { bigint: true })
const sameFile = a.dev === b.dev && a.ino === b.ino && a.ino !== 0n

bigint: true matters. The regular ino comes back as 0 on some Windows configurations, which makes every pair of files look identical.

File ownership on Windows means open handles

This is the one that generates support questions, and the error message actively points the wrong way.

Set up a repo with a worktree, then put a process inside it with a real working directory:

git -C C:\dev\repo worktree add C:\dev\feat -b feat
Start-Process cmd -WorkingDirectory C:\dev\feat -ArgumentList '/c','timeout /t 60'
git -C C:\dev\repo worktree remove C:\dev\feat --force

error: failed to delete 'C:/dev/feat': Permission denied

Permissions have nothing to do with it. Windows will not delete a directory that is some process's current directory, and git reports the refusal as a permissions error. On Linux the same removal succeeds, which is why this tends to reach Windows users first as a bug report nobody can reproduce.

Two things I only found by trying to write a reliable teardown:

PowerShell's Set-Location does not reproduce it. The PowerShell location is a provider concept layered on top of the process. The underlying working directory stays where the process started. So a Start-Process powershell -Command "Set-Location C:\dev\feat; ..." will let the delete go through, and you will conclude the problem is not real. Use -WorkingDirectory, or cmd, or anything that sets the actual cwd.

Killing the shell is not enough. In the run above I killed the cmd.exe and the delete still failed. The holder was timeout.exe, a child that inherited the working directory and outlived its parent. You need the process tree, not the process.

The practical consequence for anything that manages worktrees: before you touch the filesystem, you have to know which panes are sitting inside the directory. That means recording each pane's cwd at spawn time and killing by path prefix, normalized, because on Windows the same worktree shows up as both C:\dev\feat and C:/dev/feat depending on who wrote the path.

Cleanup after a failed run is where the state gets weird

Here is the part I did not expect. A failed git worktree remove is not a no-op. Continuing from the failure above:

> git -C C:\dev\repo worktree list
C:/dev/repo  39ca293 [master]

> dir C:\dev\feat
(empty)

> git -C C:\dev\repo worktree remove C:\dev\feat --force
fatal: 'C:\dev\feat' is not a working tree

> git -C C:\dev\repo worktree prune -v
(nothing)

Git deleted the worktree contents, deleted the administrative directory under .git/worktrees, and dropped the entry from git worktree list. Then it hit the locked top-level directory and stopped. What survives is an empty folder that git no longer recognizes, will not remove, and does not consider dangling. The branch is still there. prune has nothing to prune because the metadata is already gone.

So the recovery is manual and the order matters:

Kill whatever holds the handle, process tree included.
Delete the directory yourself.
git worktree prune afterwards, for the case where git did not get as far as clearing its own metadata.

Prune first and you can be pruning metadata that still references the directory you are about to delete.

The rule we ended up with in the app, which cost us a bug to learn: if either of those steps fails, keep the entry and report the failure. The tempting version is to drop your own record and call it removed, since the user asked for it to be gone. Then the next refresh reads git worktree list, or the leftover directory, and the worktree reappears looking healthy. Now it cannot be removed through the UI at all, because the code path for removing it assumes the state it just lost. A partial delete reported as success is worse than an error message.

Two smaller things in the same area:

Reconcile on read. People delete worktrees outside your app, with rm -rf or plain git. If your list comes from your own store, entries go stale. Compare against git worktree list on every listing, mark what git no longer knows about, and drop entries whose directory is gone from disk.

Never create a worktree inside .git. An early version of ours put some under .git/worktrees, which is git's own metadata folder. Git will create it, then refuse to treat it as a working tree, so git worktree remove fails permanently and the only exit is manual deletion. If you build paths from a repo path plus a branch name, check where you are about to land.

The setup commands that run before the agent does

Most parallel-agent setups run something after creating a worktree: npm install, a .env copy, a build. That is a place where failures get swallowed.

Three things worth having, none of them clever:

A per-command timeout. The command that errors is fine, you see it. The one that costs you is the command that prints nothing and never exits. Waiting for a prompt on stdin will do it. Ten minutes per command and then kill it.
Cancel on teardown. If the setup is still running when someone removes the worktree, cancel it first. Otherwise you are deleting a directory that a live npm install is writing into, which puts you right back in the previous section.
Redaction. Setup logs catch TOKEN=... lines from an env dump or a verbose install. If you persist those logs, strip them on the way in, not on the way out.

Logs: the part I do not have an answer for

This is where the comment landed hardest and where I have the least to show.

What exists in NestMux today is a per-pane transcript you can save and export as markdown, and a setup log per worktree capped at 200 lines with secrets redacted. What does not exist is anything unified: one timeline across panes, with timestamps, exit codes, and which worktree each line belonged to.

That is exactly the artifact you need in the case the comment described. A run failed overnight, four agents were working, and the question is which one touched what, and in what order. A transcript per pane makes you reconstruct that by hand from four scrollbacks.

I do not have a shipping date for it. I am writing it down as a gap rather than a plan, because the honest state is that pane-level transcripts were easy and a cross-pane log with correct attribution is not, particularly when panes come and go.

What this adds up to

The launch trick genuinely is the easy part. Everything expensive is in teardown: who holds the handle, what state a failed delete leaves behind, and whether your own record of the world still matches the disk afterward. On Windows that is a different set of failures than on Linux, and the error messages are worse.

If you run agents in parallel and you have a teardown that survives a failed run, or a logging setup that actually answers "which agent did this", I would like to see it. Especially if it argues that the whole thing should be a script rather than an application.

Running several coding agents in parallel on Windows, without WSL or tmux

Eliseo Fernandez Suarez — Fri, 21 Aug 2026 01:50:06 +0000

I work on NestMux, so read this the way you would read anything written by someone with a stake in it. Everything I claim about other tools comes from the documentation each vendor publishes, and I link it so you can check instead of trusting me.

The setup

Running one coding agent is easy. Running four is where it gets interesting, and where it breaks.

Four agents on the same repository will overwrite each other's files. They will fight over the same working tree, the same branch, and, if you use more than one provider, the same credentials directory. The usual answer is one git worktree per agent, one terminal pane per worktree, and some way to see all of it at once.

That last part is where Windows falls out.

tmux is the quiet dependency

Claude Code has an agent teams feature that puts each agent in its own split pane. The backend for those splits is tmux, with iTerm2 as the alternative. Anthropic's own documentation says split-pane mode is not supported in Windows Terminal.

tmux does not run natively on Windows. It runs under WSL, which means your agents run in a Linux filesystem, talking to a Windows checkout across a boundary that is slow for file watching and awkward for anything with a native toolchain. If you build with MSBuild, Unity, or Unreal, that boundary is not a detail you can ignore.

So the feature exists. It just does not exist for you.

The tools built to solve this are Mac-first

This is the part I expected to be wrong when I started checking, and it was not. As of August 2026:

Conductor: macOS only, Apple Silicon.
cmux: macOS, Linux in beta, Windows on a waitlist.
Superset: macOS, with Windows and Linux listed as coming soon.
Sculptor: macOS and Linux. Windows through WSL.

Every one of these shipped in the last year, and every one of them treats Windows as a later problem. I do not think this is contempt. Mac is what the people building developer tools use, and you build for the machine on your desk.

But the people who need this are not all on that machine. Game studios run Unity and Unreal on Windows. .NET shops run Windows. Regulated fintech and hospital IT run Windows because that is what their compliance posture was built around. Those are large teams with real budgets, and right now the answer they get is a waitlist.

What it actually takes

Nothing here requires a terminal multiplexer. It requires four things:

One worktree per agent. git worktree add ../feature-x feature-x gives each agent its own checkout of the same repository sharing one object store. They can edit at the same time without touching each other's files, and you merge normally afterward.

An isolated HOME per agent. This is the one people miss. Claude Code reads ~/.claude, Codex reads ~/.codex, Gemini CLI reads ~/.gemini. Two agents under the same user account share the same config and, more to the point, the same authenticated session. If you want two Claude accounts running side by side, they need separate home directories. On Windows that means pointing USERPROFILE and HOME somewhere different per process, not just setting an env var and hoping.

A pane grid that is not a multiplexer. tmux exists because terminals could not split themselves in 1980. A desktop application can just draw four terminals. Once you stop treating the multiplexer as a requirement, the Windows problem stops being a problem.

A way to review the output. Four agents produce four diffs. Reading them one git diff at a time is where the time savings go to die.

How NestMux does it

Here is the part where I am selling something, clearly marked.

NestMux is a desktop application that runs Claude Code, Codex, Gemini CLI, Copilot and OpenCode side by side in a resizable pane grid. Each pane gets its own account, its own isolated HOME, and its own git worktree. There is a diff viewer for reviewing what the agents did, MCP server management, a broadcast mode to send one prompt to every pane, and voice input through a local Whisper model.

It runs on Windows 10 and up, macOS 13 and up, and Linux. Same build, same features on all three. It is local-first with no telemetry: the code and the keys stay on the machine.

Thirty-five seconds of it running:

If you do not want to use it

You should not need a product for this, and depending on your setup you might not.

Do it by hand. Windows Terminal has panes. wt.exe split-pane will give you a grid, and you can drive each pane into a different worktree with a different HOME. It is fiddly to set up and you rebuild it every session, but it is free and it works today.

Use WSL and accept the boundary. If your project is Node or Python and does not care where the filesystem lives, WSL plus tmux is a completely reasonable answer, and every Mac-first tool above becomes available to you through Sculptor.

Wait. cmux has a Windows waitlist and Superset says it is coming. If you are not in a hurry, the market will probably solve this in a year.

Use one agent well. A lot of the parallel-agents enthusiasm is people discovering that four mediocre agents produce four mediocre pull requests. One agent with good context often beats four without it.

The honest limitation

Parallel agents multiply output, and output is not the bottleneck for most teams. Review is. If you are already behind on reviewing what one agent writes, four will make that worse, not better. The setup pays off when the work is genuinely parallel: separate features, separate bugs, a migration split across independent files. It does not pay off when four agents are all guessing at the same underspecified ticket.

If you run agents in parallel and you have found a different way through the Windows problem, I want to hear it, especially if it makes the case that this does not need a product at all.