Multica: issue-driven control plane for coding agents
Evaluation metadata
| Field | Value |
|---|---|
| Resource | multica-ai/multica |
| Evidence snapshot | Commit 7a438bd |
| Current metadata check | 2026-09-09: 49,348 stars, 6,375 forks, release v0.4.41 published 2026-09-07 |
| Resource type | Source-available multi-agent control plane |
| Decision | Integrate |
| Score | 3/5, moderate value |
Verdict
Multica fills a real documentation gap between terminal multiplexers and coding-agent runtimes. It gives people and agents a shared issue, chat, schedule, and run-management layer while connected computers execute existing coding-agent CLIs. It belongs in the guide as an adjacent control plane, not as a runtime harness that owns the model-tool loop.
The integration should remain evidence-bounded. The source review confirms the architecture and important permission boundaries, but this evaluation did not run the application or complete a real agent task. GitHub popularity shows reach, not reliability or output quality.
Observed architecture
Web, desktop, or mobile client
|
v
Multica server + PostgreSQL
issues, chat, agents, schedules, run records
|
WebSocket queue
|
v
Daemon on a connected computer
|
worktree or working directory
|
v
Claude Code, Codex, Cursor, OpenCode, or another agent CLIThe server coordinates work and persists product state. The daemon discovers installed runtimes, receives queued work, prepares a repository directory or worktree, invokes the selected external CLI, and reports logs, progress, cost, and results. The audited source advertises 25 runtime protocol families plus the OMP identity, for 26 integrations. See the pinned architecture guide and runtime reference.
Claim and evidence ledger
| Claim | Evidence | Assessment |
|---|---|---|
| Coordination can use a hosted or self-hosted server | Pinned README and deployment files | Confirmed structurally |
| Agent execution happens through a daemon on a connected computer | How Multica works and daemon source | Confirmed structurally |
| Offline work queues and daemon reconnection support recovery | Server queue and daemon reconnection paths in the pinned source | Confirmed structurally, not exercised |
| The audited commit passed upstream CI | GitHub Actions run 33954745978 | Confirmed for upstream checks, not an end-to-end product test |
| Multica improves coding-agent output quality or team throughput | No independent comparative benchmark found in the reviewed scope | Unknown |
Data, permissions, and Git boundaries
Local repositories and local credential files are not automatically uploaded wholesale by the architecture reviewed. That does not make the coordination tier data-free: issues, comments, agent configuration, schedules, run context, records, logs, costs, and results can be stored server-side. Custom environment and MCP configuration can also become server-managed data. Teams should classify that content before choosing the hosted topology.
The daemon runs with the permissions of its operating-system account. The audited Claude path uses bypassPermissions, and the Codex path uses danger-full-access except for a documented Windows native-sandbox option. Multica does not add a general filesystem sandbox around those CLIs. Its security model should therefore be read as an execution-account boundary, not as proof of repository isolation.
The product's in_review state is workflow metadata. It does not configure Git-host branch protection, mandatory review, or merge policy. An agent can use Git credentials available to the daemon account. Repository-side rules remain the enforcement point.