Managing Multiple AI Coding Assistants in Practice: The Open-Source Worktree Control Tool
Running multiple AI coding assistants in parallel requires centralized scheduling and shared context; Worktree Control offers a solution.
The article describes the resource conflicts, context loss, and verification confusion a developer faced after subscribing to multiple AI coding assistants. He built the open-source tool Worktree Control, which centralizes dev server and test concurrency scheduling via project claims, port reservations, and queues; records Git observations to distinguish command success from verified current revisions; and adds a knowledge base module for shared to-dos and project memory across sessions. The tool is open-sourced and still pre-1.0, with delegation boundaries and verification distribution under ongoing exploration.
When developers subscribe to multiple AI coding assistants (such as Codex and Claude Code) and try to run several agents in parallel, problems like resource conflicts, context loss, and verification confusion quickly surface. In this article, the author builds an open-source tool called Worktree Control, evolving an initial goal of "maximizing subscriptions" into a multi-agent scheduling system. Drawing on his experience, the following breaks down the core challenges and solutions of multi-agent collaboration.
From Simple Tasks to the Multi-Agent Dilemma
At first, the author used Codex only for isolated small tasks: writing functions, adding tests, fixing bugs. As model capabilities improved, he began delegating larger chunks of work, but session limits made him wonder: could agents keep working while he slept? Could they automatically pick up tasks from a to-do list? This illusion of "team collaboration" soon brought a management burden—he became, in his own words, a "micromanager."
Chaos after adding a second subscription
After a friend recommended Claude, the author ran multiple coding clients in parallel. He used T3 Code to manage sessions across clients, but the shared to-do list was still maintained through JSON and Markdown files in a Git repository. Branches and worktrees meant each agent had its own version of the to-do list, making synchronization tricky: decisions made in one conversation were hard to reuse directly by another agent. Switching models was easy; keeping project context consistent was much harder.
Git worktree is a Git mechanism that allows multiple branches to be checked out simultaneously into different directories on the same repository, without cloning multiple copies of the repo. Each worktree has its own working area and index but shares the same .git object database. In a multi-agent scenario, this means each agent can have its own branch and working directory, modifying code in parallel without interference. However, if the shared to-do list exists as ordinary files in the repository, it will produce multiple copies as worktrees are checked out, and each agent's changes cannot be merged automatically, causing decisions and state to become scattered. Understanding this explains why the author needed independent scheduling and knowledge management modules rather than relying solely on in-repo file synchronization.
Hardware Resources and the Challenge of Concurrency Control
The author runs five threads, four dev servers, and two end-to-end tests simultaneously on a 6-core, 18GiB Linux dev machine. Every agent has a reason to start its own process, but machine resources are limited. Memory limits can constrain usage, but they cannot decide which dev server should run and which test should wait. Recalling the concept of semaphores from his student days, the author decided to build Worktree Control to centralize scheduling.
Ports, Reservations, and Queue Mechanisms
The core design of Worktree Control is simple: limit the number of managed dev servers running at once, assign each project a stable port, and let agents switch between worktrees. Agents must "claim" a project before use and release it when done. The author, as the "most important agent," can lock a project via the dashboard to prevent other agents from taking it over. Releasing a claim does not stop the server, so an idle reservation is not the same as an idle slot.
Builds and tests go through separate queues that limit concurrent runs, with at most one active check per worktree. Submitting a test does not switch the dev server; tests that need a browser still require claiming a server. If another agent holds the claim, the test must wait; starting a stopped server is also subject to the server count limit. This distinction is critical in projects with shared test fixtures—resetting the database must happen inside a queue task, otherwise it would interfere with running tests.
The controller also shows resource usage and worktree disk consumption, and can clean up Next.js caches for stopped, unlocked worktrees. But the rules only take effect when agents use the controller; nothing prevents an unrelated terminal from starting extra servers, so the workflow is also written into the project's agent instructions.
Semaphore is a synchronization primitive in concurrent programming used to control access to a limited number of resources. It maintains a counter; threads perform a P (wait) operation to decrement the count before acquiring a resource, and a V (signal) operation to increment it upon release. When the count reaches zero, subsequent acquirers are blocked until a resource is released. Worktree Control extends this idea from within a process to the scheduling level across multiple agents and processes: dev server slots and test queue concurrency are resources protected by semaphores, and agents must explicitly claim and release them, turning "who goes first, who waits" from implicit contention into an auditable, explicit protocol.
Verification Evidence: What Did the Tests Actually Run?
"Tests passed" sounds reassuring, but the author wants to know: which worktree? What command? Did the code change after the test was queued? Do the results still apply to the current code?
Worktree Control records Git observations before and after a run, keeping command results separate from source evidence. A successful command does not automatically mean the current revision has been verified. Results record the commit hash, whether the worktree is dirty, a summary of changed paths via Git status, and are flagged if HEAD changes before and after the run. The limitation is that local checks use worktree files (including uncommitted changes), not an immutable snapshot, and Git observations cannot capture all environment dependencies. But it is far more auditable than a verbal assurance in chat.
Git observation refers to a snapshot of repository state captured before and after a command runs, typically including the current HEAD commit hash, whether the worktree contains uncommitted changes, and a summary of changed file paths and statuses. Its purpose is to bind a test result to the code state that produced it. If HEAD changes before and after the run, the code was modified during testing and the result's credibility decreases. It is important to distinguish that local worktree checks use file contents including uncommitted changes, not an immutable snapshot, so observations can only provide auditable correlating evidence and cannot replace deterministic verification on a clean snapshot.
Knowledge Base: Context Continuity Across Sessions
With servers and test queues under control, the work itself still needs a place to live. The author added a Knowledge module to Worktree Control to store to-dos, discussions, and project memory. Tasks can link to source discussions, decisions retain sources and revision history, and saving a memory entry and approving it are separate operations.
The author can read and write records via the dashboard, and agents access them through MCP or the CLI. Different sessions thus have a common lookup point, even when switching coding clients. During handoff, a task's "next session context" collects related memories and source revisions; the next agent still needs to read and understand them, but the information has a home.
MCP (Model Context Protocol) is an open protocol that lets AI applications connect to external tools and data sources in a standardized way. It defines the communication interface between clients and servers, enabling models to discover and invoke tools and read resources without writing separate integration code for each client. In this article's scenario, Worktree Control exposes the knowledge base's read and write capabilities via MCP, so different coding clients (Codex, Claude Code, OpenCode, etc.) that support MCP can access shared to-dos, discussions, and project memory in a consistent way, reducing context loss when switching between clients.
Current Configuration and Open Questions
The author currently runs one Linux dev machine, using Codex, Claude Code, and OpenCode, with T3 Code for remote access, n8n for PR review automation, and Worktree Control to manage dev servers, check queues, and shared context. The controller is a single Node.js process using SQLite and a browser dashboard; the Next.js UI is exported as static files, requiring no extra resident server. The project is still pre-1.0, and distributing verification to independent worker nodes is still under development.
The author is still figuring out the boundaries of delegation. Keeping every agent busy can easily be mistaken for progress; what he would rather see when reviewing tasks is: what changed, what was checked, and what still needs attention. Worktree Control is open-sourced on GitHub, and the author is curious how other multi-agent users handle context storage and dev server access.
- Project website: https://pioootrek.github.io/worktree-control/
- Source code: https://github.com/pioootrek/worktree-control
Related articles
Random Pruning of the DPO Computation Graph: 1.4x Training Speedup and Lower Peak Memory
DPO training too slow and memory-hungry? This paper proposes a random pruning framework for the DPO computation graph, sampling independently across position, sequence, and branch dimensions; branch pruning achieves a 1.426x step-time speedup and cuts training time by about 30%, with in-depth attribution of memory and time gains.
Why Does JEPA Underperform MLM in Longitudinal EHR Representation Learning?
New study compares JEPA and MLM for longitudinal EHR representation learning on MIMIC-IV: three JEPA variants train stably without collapse but underperform MLM; target size, not heterogeneity, drives prediction error.
Transfer Learning + Visible Light Communication: A New Approach to Energy-Efficient Indoor Positioning
A study proposes a transfer learning-based visible light communication indoor positioning method, achieving 47% accuracy improvement on the BOSCH factory dataset, 67.5% model efficiency under high noise, and introducing the ME composite metric for energy-efficient positioning in energy-constrained industrial IoT scenarios.