multica-ai/multica

The core problem Multica solves is coordination debt. When you run multiple agent CLIs — Claude Code, Codex, Cursor, whatever — each one lives in its own terminal, forgets everything when the session ends, and forces you to re-explain context every time. The more agents you add, the more your day becomes agent-wrangling rather than actual work. Multica's answer is to treat agents as assignable teammates on a shared board, not as isolated processes you babysit.

The architecture is worth understanding because it explains what Multica actually controls. A local daemon runs on your machine — or any machine you designate as a runtime — and communicates with a Go backend over WebSocket. That daemon spawns whichever of the 23 supported agent CLIs you've pointed at a given task. Multica doesn't ship a model or a runtime of its own; it drives the CLIs you already have installed and authenticated. Switching providers is a dropdown change, not a migration. The full stack is Next.js frontend, Go backend with Chi and gorilla/websocket, and PostgreSQL 17.

What makes this more than a fancy task runner is the execution log. Every tool call, command, and error is timestamped and replayable. Token usage is tracked per agent per issue. Work lands in a review state, not directly in main — a human has to approve before anything ships. The inbox surfaces only the moments when an agent is genuinely blocked and needs a decision, not a notification for every intermediate step. That distinction matters: the design explicitly tries to reduce the interruption surface rather than expand it.

The "Skills" concept is interesting and underexplained in the README. The idea is that a solved problem becomes a reusable playbook any agent can follow — essentially codified institutional memory that survives session boundaries. Whether that holds up in practice depends entirely on how well the playbook abstraction handles novel situations, and the README doesn't go there.

The name traces to Multics, the 1960s time-sharing OS that let multiple users share one machine as if each had it to themselves. The analogy is deliberate: agents make time-sharing relevant again, but now the users multiplexing the system include both humans and machines. It's a cleaner framing than most agent-orchestration projects manage.

Self-hosting is a first-class path — Docker Compose or Helm, any Git host including self-hosted GitLab and Gitea, and a license that is Apache 2.0 with additional conditions around hosted services and commercial embedding. The iOS client exists but is not yet on the App Store; it builds from source today. The project releases most weekdays, which means main moves fast and pulling often is genuinely advised, not boilerplate.