Where Caudra is headed: one cockpit for a swarm of agents
So I've been thinking a lot lately about where caudra should be headed. There's so much happening in this AI harness space right now!
To catch you up: Caudra is already a fully working TUI coding agent with many, many capabilities and enhancements. Just to name a few: autopilot, decision system for screening and reranking, built-in token savings, background subagents/shell calls, learner + memory system, nudges that keep models on track (small and flagship alike), code mode, and everything else a modern coding agent should have, all designed together in one native binary. You can see some (probably by now outdated) examples in the gallery. It's moving so fast that I have trouble myself communicating what caudra is or what it makes better, but I'm trying my best.
Status Quo
It was originally bootstrapped with OpenCode, but I fully switched to Caudra about two months ago, around the time session persistence was working with a sqlite DB (and have since just migrated forward without issues). It all started from a simple motivation: I wanted a coding agent that works flawlessly with smaller models like Qwen-3.8-27b, which are great but need a little more hand-holding than I wanted to do myself. So I started rolling my own 1 and implemented native nudges where they make sense, like when the model just stops with an intent and hands control back to the user. That quickly led to many more features, like a proper goal mode (similar to the one in Claude Code), and eventually a complete autopilot that can take over (like answering permission prompts, making sure the model works toward the goal, and so on). Then JEV happened, and I quickly saw how to integrate it into Caudra. Integrating this into a coding agent feels unreal, it's like the agent got superpowers. This decision engine can screen, rank, guide, advise, and judge, with pretty low latency (most of the time it just happens instantly).
OK, all of these are nice features, but what next?
Vision
I hope I've at least caught you up in the slightest and still got your attention, because now it's going to get really interesting!
I mentioned at the beginning that there's a lot happening in this space: countless coding agents (some from model providers themselves, some closed source, some open source): Claude Code, Codex, Grok Build, etc., and some that are also provider agnostic and very extensible, like OpenCode and Pi. They are all great and very inspiring!
Then there are coding agent runtimes:
There are also always-on agents surfacing (again, some closed source and locked to a model provider, some open source and provider agnostic):
(I'm sure I missed many more great projects.)
Most of them orchestrate the underlying harnesses themselves, though (like via ACP or by driving the CLI directly). For Caudra I'm envisioning something that pays attention to the complete stack to give us the best user experience: namely, the optimized, provider agnostic harness runtime that can also connect to other Caudra processes to form something greater. Think: multiple (isolated), persistent agents, each with its own tools, skills, memories, etc. You can talk to any of these agents directly, but more importantly, they communicate and collaborate with each other to work toward broader goals or handle continuous tasks. Since each has its own memories, they will (hopefully) get better over time, since they are remembering and learning. Permissions are strictly defined for each agent, only for what it really needs. And when anything changes, an agent is always in the loop: it gets assigned a task by other agents, instead of other agents doing the work behind its back (which sometimes woulnd't even be possible, because of permission scopes).
flowchart LR
subgraph Agent["One Caudra agent"]
direction TB
Core["Provider-agnostic harness"]
Tools["Own tools and skills"]
Mem["Own memory and learner"]
Perm["Strict permission scope"]
Feat["Autopilot · decision engine ·<br/>nudges · code mode · token savings"]
Core --- Tools & Mem & Perm & Feat
end
Models[("Any model:<br/>Qwen, Claude, GPT, …")] <--> Core
Agent <-- "link: ACP + _caudra extensions" --> Hub["Hub"]I know this is still very vague, since real-world tests have yet to be conducted, but I'm trying to build this foundation with caudra.
So how will this look like?!
The Swarm
Caudra (the single binary) can be deployed anywhere: remote machines, VMs, containers, isolated namespaces. Each instance is then linked to one (or even multiple) hub(s), where they start to see each other and form a swarm. They can create and join channels (or topics) and exchange messages there (like pub/sub). You, the human operator, get a nice GUI that surfaces only the relevant info at hand: status updates, findings, gotchas, permission requests, etc. You always have the capability to drill down very deeply to understand every detail an agent is (or was) doing, for troubleshooting and transparency, if you must. Even so far as to open up the raw underlying full TUI over the wire, embedded in the GUI.
flowchart TB
Human(["👤 Operator"])
subgraph Cockpit["Cockpit: web UI"]
Feed["Status, findings, gotchas,<br/>permission requests"]
Drill["Drill-down: chat, browser,<br/>terminal, embedded TUI"]
end
subgraph Hub["Your hub"]
subgraph Channels["Channels / topics: pub/sub"]
C1["#backend"]
C2["#release"]
Cn["#topic n"]
end
end
subgraph Nodes["Caudra nodes: one native binary, deployed anywhere"]
N1["Agent 1<br/>remote machine"]
N2["Agent 2<br/>VM"]
N3["Agent 3<br/>container"]
N4["Agent 4<br/>isolated namespace"]
Nn["Agent n"]
end
Human <--> Cockpit
Cockpit <--> Hub
N1 -- "dials in" --> Hub
N2 -- "dials in" --> Hub
N3 -- "dials in" --> Hub
N4 -- "dials in" --> Hub
Nn -- "dials in" --> Hub
N1 -. "assigns task" .-> N2
N2 -. "assigns task" .-> N4
HubB["Another user's hub<br/>(future: multi-user)"]
N3 -. "also linked" .-> HubB
classDef future fill:#eee,stroke:#999,stroke-dasharray: 5 5,color:#666;
class HubB future;This is all possible because we own the complete harness stack and don't need to attach to very heterogenous harnesses/coding agents that are complex to set up in these various environments, and where either dedicated solutions must be developed or a common denominator must be found (translated: less capabilities). Plus, we can do it all natively and very efficiently, in terms of CPU, RAM, disk, resources, and, more importantly, token usage.
Rough Roadmap
flowchart LR
A["✅ Usable TUI<br/>coding agent"] --> B["🚧 Client/server:<br/>link nodes to a hub"]
B --> C["🚧 Cockpit ADE:<br/>web chat, browser,<br/>remote terminal"]
C --> D["⬜ Swarm:<br/>agents collaborate<br/>via channels"]
D --> E["⬜ Desktop and<br/>mobile apps"]
E -.-> F["🔭 Multi-user:<br/>multiple hubs"]
classDef done fill:#d4f7d4,stroke:#2e7d32;
classDef wip fill:#fff4c2,stroke:#b58900;
classDef todo fill:#eee,stroke:#888;
classDef future fill:#fafafa,stroke:#bbb,stroke-dasharray: 5 5,color:#777;
class A done;
class B,C wip;
class D,E todo;
class F future;Questions to You
- Should agents collaborate mainly through channels/topics (pub/sub) or through direct task assignment?
- What would you need to see before you let an agent on a remote machine act with its own permission scope?
- Would you run your own hub, or is that too much setup for you? (In a nutshell, it's just going to be a
caudra servecommand ) - If you use ACP today, which extensions would you need?
Ideas and questions are welcome below, or open a thread in Ideas :)
Cheers, Thorsten
P.S.: I know some of these aspects are still very abstract and not very concrete, but over time I will shed more light on each of these components. In the meantime, you can keep an eye out for new commits (once pushed) or for more (pre-)releases.