soupz-stall: Soupz: The Remote Control Layer for Local AI Coding Agents
A local-first daemon that turns Claude Code, Gemini CLI, and Copilot into swappable backends, then exposes the whole workflow through a phone-friendly web interface.
- Soupz is less an AI assistant than a control plane for assistants, wrapping multiple coding CLIs behind one local orchestration layer.
- Its real product value is mobility without relocation, because the code stays on the developer's machine while the interface moves to phone or browser.
- The daemon matters because it treats agent failure as a routing problem, with fallback logic that can pivot work between backends instead of stopping at the first error.
- The repo points toward a different dev workflow: local execution, remote supervision, and swappable agent backends as a single system.
The Missing Layer in AI Coding
Most AI coding tools are built for one person at one keyboard, staring at one terminal. Soupz breaks that assumption. It turns a local dev box into something you can supervise from a phone, tablet, or browser, while the code stays put.
That is the real move here. Soupz is not trying to be a better model or a prettier chat UI. It is the layer that sits between you and the agents you already use.
The repo’s core idea is simple to say and surprisingly rare in practice: treat Claude Code, Gemini CLI, and Copilot as swappable workers behind a single order system. The surprise is not that it runs AI. The surprise is that it makes AI tooling feel like a remotely operated machine.
Orders, Chefs, and the Stall
The culinary metaphor is not decorative. It is the operating model. Orders are tasks, chefs are agent backends, the stall is the daemon, and the kitchen floor is the live workspace where output lands.
Once you see it this way, the rest of the system reads clearly. The daemon is not just hosting a web page. It is coordinating task assignment, terminal streaming, and live state sync across devices.
How the Daemon Stays Local but Feels Remote
The technical backbone is a Node.js backend built around the local machine. In the research, the key pieces are pairing, WebSockets, `node-pty`, file watching, and Supabase relay support. That combination is what lets a local terminal feel like a remote product.
Pairing starts the connection. Soupz generates a human-readable one-time code, checks local IPs and tunnel URLs, and establishes a path from the device in your hand to the machine doing the work. The result is a remote control flow without a cloud IDE in the middle.
The live loop matters just as much. `node-pty` gives Soupz a real pseudo-terminal, so this is not a fake command runner. It can handle interactive commands, stream stdout in real time, and keep the browser synchronized with filesystem changes.
| Tool type | Where code lives | How you interact | Mobile friendliness | Fallback / orchestration | Privacy posture | Setup friction |
|---|---|---|---|---|---|---|
| Soupz | Local machine | Browser or phone over a paired session | High | Built in, across agent backends | Strong, because code stays local | Moderate |
| Cloud IDE | Cloud workspace | Browser in a hosted environment | High | Limited to the platform | Depends on vendor | Low to moderate |
| Plain terminal agent | Local machine | Directly in the terminal | Low | Manual switching | Strong | Low |
| Remote desktop / SSH | Local or remote machine | General-purpose remote access | Medium | None | Varies by setup | Medium |
That table is the category break. Cloud IDEs solve access by moving the environment. Plain agents solve generation by staying in the terminal. Soupz solves supervision and continuity while keeping execution local.
Why the Fallback Logic Matters
Fallback is the feature that turns the system from a wrapper into an orchestrator. If one CLI fails because of a rate limit, trust issue, or missing backend, Soupz can route the order somewhere else. That is workflow protection, not just convenience.
if (looksLikeRateLimitFailure(err) || looksLikeTrustFailure(err)) {
return routeOrderToFallbackAgent(order, backends)
}
return startSingleAgentOrder(order, preferredBackend)That small idea has a big product effect. It means the user is not forced to understand which agent is available at the moment. They make the request once, and the system absorbs backend volatility.
Soupz vs Cloud IDEs and Plain Terminals
Compared with Codespaces-style tools, Soupz keeps the compute and the source tree on the developer's machine. Compared with a direct CLI session, it gives you a supervisory layer, live remote access, and swappable backends. Compared with ad hoc SSH, it has a product shape instead of a bag of shell tricks.
That distinction matters because it changes the unit of design. The unit is no longer the editor, and it is not the model either. The unit is the order, plus the routing around it.
What This Project Suggests About the Next Dev Workflow
Soupz points toward a plausible next step in agentic development: local-first execution, multi-backend orchestration, and lightweight supervision surfaces. That is a different category from cloud-first AI tools and a more resilient one than a single chat loop.
The long-term value is not the kitchen metaphor. It is the abstraction underneath it. Once AI tools become interchangeable workers, the important software is the layer that routes, monitors, and recovers when one worker stalls.
