Multica turns agent runs into assigned work
Multica starts where a pile of agent terminals becomes hard to supervise. An issue gets an agent assignee, the selected CLI runs on a registered machine, and its progress, tool calls, errors, cost, and final diff remain attached to that issue. A person can steer a supported run while it is active, then decide whether the work moves past review. That is more useful than a chat transcript when several people share responsibility for what agents change.
The project supports 26 agent CLIs in its current README, including Claude Code, Codex, Cursor Agent, Copilot CLI, OpenCode, and Kimi. Multica supplies coordination rather than model access. Each runtime machine still needs at least one supported CLI installed and signed in. That separation lets a team mix providers, but it also leaves subscription terms, credentials, and provider failures outside Multica's control.
The board earns its keep when several agents share a queue
The strongest parts are ordinary management controls applied to automated work. Agents and people appear on the same workspace, projects attach repositories and documents, and squads can route assignments. Autopilots schedule audits or reports, while inbox notifications surface decisions instead of every command. Review gates keep finished work out of the main branch until a person accepts it. The execution log makes a failed run inspectable instead of reducing it to a red status dot.
This breadth has a cost. The checkout at commit 2ea01ae contained 6,429 files, about 1,298,019 lines of source, and occupied 63.4 MB before installation. Web, desktop, mobile, backend, documentation, and shared packages live in one workspace. A developer changing the platform is entering a large product codebase, not adding a thin wrapper around codex or claude.
What happened when we ran it
Our sandbox installed commit 2ea01ae in 162 seconds. Pnpm added 2,024 packages, and the resulting environment used 2,429 MB on disk. We ran it in an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. The repository had 6 CI workflow files, a Dockerfile, a Compose file, and monorepo workspaces.
The build failed after 14 seconds. Its final lines identify @multica/desktop#build as the failed task and show lifecycle failures for desktop, docs, UI lab, and web. Only 2 of 6 tasks completed successfully. The log tail does not provide the underlying compiler or system error, so it does not support blaming a missing package, memory limit, or application defect. It supports one narrower finding: the measured commit did not build cleanly in our fresh Debian container.
Vitest told a very different story. The test command ran for 720 seconds and reported 5,961 passed with 0 failed. Those results cover the supplied test command, not a successful distributable build. The combination matters: tests exercised a lot of code successfully, yet a contributor still could not finish the top-level build in the same clean environment.
Self-hosting needs a server plus daemons on worker machines
The packaged self-host route uses Docker Compose for a Go backend, a Next.js frontend, and PostgreSQL 17. Each person who runs agents locally also installs the Multica CLI and starts its daemon beside the working copy. Email login can use Resend; without it, a one-off deployment can retrieve generated codes from backend logs. Kubernetes users get a Helm chart, separate web and API ingress hosts, persistent volumes, and a Secret they must create themselves.
The README's quick path is short, but production ownership is wider than 2 shell commands. You still manage TLS, backups, database upgrades, daemon reachability, agent credentials, and whichever Git or chat integrations you enable. The server also sends one anonymous deployment snapshot each day by default. The self-hosting guide documents its fields and says DO_NOT_TRACK=1 disables collection and delivery.
The license blocks an ordinary hosted fork
GitHub reports no standard SPDX license because Multica combines the Apache 2.0 text with extra conditions. Internal commercial use is allowed, but operating a hosted service for third parties or embedding Multica in a commercially distributed product requires a commercial license. Its interface branding also stays unless the producer grants a separate waiver. Anyone choosing Multica because it appears to be an Apache project should read the complete license before building around it.
That condition changes who should invest in the platform. An internal engineering group can self-host and modify it under the stated terms. A vendor planning a managed agent board cannot assume the rights attached to plain Apache 2.0 software. Multica's own README accurately calls it source-available, which is the safer description.
October activity is high, and the issue queue is busy
GitHub showed 51,861 stars, 1,756 combined issues and pull requests, and a last push on October 2, 2026. Release v0.6.1 arrived on October 1. Its notes include daemon path handling, provider quota classification, chat fixes, issue controls, and query work. The dates show active maintenance, while the combined queue warns that activity and unresolved work are both substantial.
Recent reports reach into the workflow Multica is meant to protect. Issue 9024 says host sleep can be counted as agent silence and kill active runs after wake. Issue 9017 reports a wakeup retry that can remain unclaimed after its rule changes. These are current user reports, not findings from our sandbox, but they concern unattended execution rather than cosmetic edges. Trial scheduled work on disposable branches before trusting it with overnight changes.
Multica makes the most sense after agent coordination has already become a team problem. Its board, audit trail, runtime control, and review state address that problem directly. The measured build failure means source contributors should reproduce the full build before committing to the stack, even with 5,961 green tests behind it.