A control plane for coding agents
Multica starts from an increasingly familiar problem: one developer has Claude Code in one terminal, Codex in another, Cursor somewhere else, and no durable record connecting each run to the request that caused it. Multica replaces that collection of private sessions with a shared issue board. Assign an issue to an agent, let a daemon invoke the selected command-line tool, watch progress and tool calls, then review the result before deciding that the issue is done.
The distinction is important. Multica does not provide a model and it is not another coding agent. It coordinates 20 existing agent CLIs, including Claude Code, Codex, Cursor Agent, Copilot, OpenCode, Kimi, Hermes, and Qwen Code. Each tool remains installed and authenticated on a machine you control. The server stores issues, comments, agent configuration, run records, and returned context, while the local daemon operates beside the code.
That makes Multica most valuable after agent use becomes a team workflow. A single developer with one terminal does not need this much machinery. A team running concurrent agents on recurring tasks can benefit from ownership, history, costs, retries, permissions, and one review queue.
The issue model is thoughtfully designed
An issue records the ongoing goal, discussion, assignee, and status. A task records one execution attempt. Reassigning an issue or retrying after failure creates another task without erasing previous runs. The execution log shows messages, tool calls, errors, timing, and the agent responsible. Completion of a run does not automatically declare the work correct, which preserves the human review boundary.
Multica handles operational details that ad hoc terminal sessions leave to the user. Runtimes send heartbeats, queued work waits for an offline machine, transient failures can retry, and local directory locks stop two runs from editing the same checkout simultaneously. Tasks receive separate working directories and agent state. Autopilots schedule audits or reports, while Slack, Lark, DingTalk, and WeCom can trigger and follow work outside the board.
Support for GitHub, GitLab, Gitea, and Forgejo makes the product useful beyond one hosted forge. Custom runtime profiles can wrap internal tools as long as they follow a supported protocol family. A current issue shows the cost of that abstraction, however: model discovery for a custom Hermes-compatible profile fails because the daemon looks only among built-in providers. The custom runtime can execute while its model dropdown remains empty.
Security requires an external boundary
The project's security documentation is unusually direct and should be read before installation. By default, an agent process has the full permissions of the operating-system user running the daemon. It can read and modify that user's files, use reachable credentials, and access the network. Multica makes no general filesystem sandbox promise. It runs Codex with danger-full-access and Claude Code with permission prompts bypassed for unattended operation.
Per-task directories, scoped Multica tokens, and separate agent state reduce accidental collisions, but they are not containment. The recommended boundary is a dedicated Unix user, container, or virtual machine with only the repositories and credentials needed for assigned work. Running the daemon under a personal account exposes SSH keys, cloud CLI credentials, shell configuration, and documents to every task. This is the largest reason a competent team should pause. The product makes autonomous execution convenient, so operators must make least-privilege execution equally routine.
Local execution does not mean every secret stays local either. Custom environment variables and MCP configuration are stored on the Multica server and delivered to the runtime. Scope tokens per purpose and decide whether the hosted service or your own server is the appropriate trust boundary.
Self-hosting is credible, not tiny
The quick installer provisions Docker Compose, the CLI, and local configuration. Underneath it are a Next.js frontend, Go API and WebSocket backend, PostgreSQL 17 with pgvector, and a daemon on every machine that executes agents. Each daemon also needs at least one supported agent CLI installed and signed in. Desktop simplifies registration, but does not remove the underlying provider account.
For production authentication, the guide recommends configuring Resend to email login codes. Without it, a generated code appears in backend logs. A fixed development code is available for private testing, with an explicit warning never to expose that setup publicly. Kubernetes users get a Helm chart, readiness checks, storage, ingress, and upgrade guidance, but must manage DNS, secrets, persistent volumes, and database migrations. This is a real self-hosted application, not one static binary.
The license also needs attention. It incorporates Apache 2.0 but adds conditions. Internal organizational use and self-hosting are allowed, while providing a hosted service to third parties or embedding Multica in a commercial offering requires a commercial license. Interface branding cannot be removed without a waiver, and backend-only products retain attribution requirements. This is source-available with meaningful commercial restrictions, not ordinary Apache 2.0.
Extraordinary activity, early-stage stability
The repository was pushed and released on August 11, 2026, with v0.4.23. The project says it releases most weekdays, and that release alone contains fixes across daemons, issues, channels, attachments, workspace deletion, skills, and several agent adapters. Fresh work and issue discussion arrive throughout the day.
The queue is enormous: GitHub search reports 761 open issues and 529 open pull requests, rather than 1,290 confirmed bugs. Much of the traffic is active contribution work, but the volume makes triage difficult and signals a rapidly moving surface. A current self-hosted report says setting MULTICA_DAEMON_PORT breaks CLI login in v0.4.22 and v0.4.23, despite working in v0.4.21. Another report covers intermittent Hermes authentication. Daily releases deliver fixes quickly, but they also justify pinning versions and testing upgrades on a staging workspace.
Multica is impressive because it treats agents as accountable workers rather than chat windows. Teams prepared to isolate runtimes and operate the control plane should trial it on low-risk repositories. Everyone else should start with a lighter local session manager until the coordination pain genuinely exceeds the security and administration cost.