Inspiration
I use multiple coding agents, but they still behave like isolated tools.
Claude can hit a usage limit halfway through a task while Codex or Grok sits completely unused. Moving the work manually means reconstructing the task, explaining what changed, pointing the next agent at the right files, and hoping it understands where the previous one stopped.
Most of the time, I just wait for the reset.
Then I saw people independently asking for the same thing: a meta harness that could coordinate coding agents across providers, track what each one was doing, and hand work between them cleanly when one hit its limits.
Around the same time, another discussion asked why AI agents should behave like developers on isolated machines who only coordinate through pull requests. If we are going to run several agents in parallel, there should be something acting like the factory floor.
That became LegCli.
What it does
Instead of running:
claude
you run:
leg claude
or:
leg codex
leg agy
leg grok
You still get the real interactive coding agent with your own configuration.
LegCli runs beside it and coordinates everything around the session.
The core idea is simple:
When one agent hits its usage limit, LegCli hands the same work to the next available agent in the same terminal with the context already loaded.
One board for every agent
Every LegCli session appears on a local board showing the agent, account, repository, branch, current task, files being touched, usage state, and what has already landed on trunk.
If two agents start editing the same file, both sessions get warned.
If another session starts inside a repository that already has an active LegCli session, LegCli can isolate it into a Git worktree instead of letting two agents overwrite the same checkout.
Finished work can then move through the Land flow instead of being manually copied around.
It understands agent limits
Every coding agent exposes usage and limit information differently.
LegCli normalizes those signals across providers.
Claude Code usage comes from its usage endpoint and limit hooks.
Codex usage comes from its read only app server rate limit interface.
Antigravity is monitored through its logs.
Grok usage comes from the billing proxy used by its CLI.
The board can therefore show which agents and accounts still have capacity instead of treating every provider like a black box.
It keeps the handoff ready before you need it
While an agent works, LegCli continuously maintains a context handoff containing the task, recent conversation context, changed files, Git state, recent commits, and the reason the previous agent stopped.
The handoff is not created after something fails.
It is kept ready the whole time.
When one agent runs out, another gets the leg
Near a usage limit, LegCli warns you.
When the limit is reached, it saves the latest handoff state, stops the exhausted agent, selects the next available agent or account, and starts it in the same terminal with instructions to load the context and continue.
Claude can become Codex.
Codex can become Grok.
Another Claude account can take over before switching providers.
The handoff order is configurable.
Nothing has to be retyped.
If every configured option is exhausted, LegCli shows which one resets first, counts down to that reset, and can resume from the saved context when capacity returns.
That is where the name comes from.
Each agent runs one leg of the job.
How I built it
LegCli is built on Node.js 22 and has zero runtime npm dependencies.
Rather than recreating Claude Code, Codex, Antigravity, or Grok, LegCli launches the real installed CLI and adds coordination around it.
Each provider adapter normalizes three questions:
- What is this agent doing?
- How much capacity does this account have left?
- How do we know when it has actually hit a limit?
Those signals feed a single local session ledger.
The browser board receives updates through server sent events, giving every active terminal one consistent view of the system.
Git worktrees isolate simultaneous sessions.
A merge and landing workflow handles completed work.
Context moves between agents using context-handoff-bundle, a Python package I had previously built for saving and resuming coding agent sessions.
Everything runs locally.
LegCli also strips API key and custom base URL environment variables before launching supported agents. The goal is specifically to coordinate subscription based coding agents without silently falling back to metered API usage.
Challenges
Every agent exposes limits differently
There is no standard API for asking:
How much coding agent usage do I have left?
Claude, Codex, Antigravity, and Grok all expose different information through different mechanisms.
A large part of LegCli became an adapter problem: turning several unrelated systems into the same concepts of utilization, availability, reset time, and limit reached.
Testing an event you cannot easily trigger
Usage exhaustion is difficult to test because normally you have to actually consume the subscription.
I built simulated limit events and fixtures based on real limit responses so the complete handoff path could be tested repeatedly without burning through an account every time.
That let me test the important sequence end to end:
agent hits wall
→ state saved
→ process stops
→ next agent launches
→ context resumes
Parallel agents create real Git problems
Multiple autonomous coding sessions inside one checkout are a conflict generator.
At first, I thought the coordination layer should prevent overlap entirely.
That turned out to be the wrong abstraction.
LegCli instead makes overlap visible, isolates concurrent sessions with worktrees where appropriate, and provides a controlled path for landing completed work.
The system coordinates agents without pretending conflicts cannot happen.
What I learned
The hardest part of multi agent development is not the agents.
It is coordination.
The models are already capable. The missing layer is the system that knows what each agent is doing, what capacity it has left, what files it touched, what landed, and how another agent can continue without starting over.
I also learned that orchestration should expose state rather than hide it.
If two agents are touching the same file, I want to know.
If Claude is about to stop, I want to know exactly what Codex will inherit.
If something lands on main, I want to know how it got there.
The orchestration layer should reduce uncertainty, not create another opaque system.
What's next
Today LegCli is primarily a local control plane for one developer running multiple coding agents.
Next is multiplayer: shared project state, per human identity, agent ownership, collision detection, and handoffs between both agents and people.
The goal is for Claude, Codex, Grok, and whatever comes next to stop feeling like unrelated terminals.
They should feel like a workforce.
Log in or sign up for Devpost to join the conversation.