AQ vs Multica: the board that dispatches agents, or the room where they run

Published September 17, 2026 · by the AQ team

How is AQ different from Multica? Multica (multica.ai, github.com/multica-ai/multica) is an open-source, self-hostable platform that sits above the agent CLIs you already have installed: you assign an issue to an agent the way you would assign it to a colleague, a daemon on your own machine or cloud box executes the work, the agent comments as it goes, and the result lands back on the board for review. AQ is the workspace under the run itself: agents execute as real CLIs on an always-on machine in your own cloud, and the whole team opens the same live terminal, editor, and app preview in the browser, watching and steering the work while it happens. Multica manages agents from above, through issues and review gates. AQ puts the team inside the session.

Multica moves fast (three releases in the week before this writing), so every Multica claim here is as of September 2026, verified against the multica-ai/multica GitHub repository, its LICENSE, and its self-hosting documentation. One disambiguation up front: Multica here means the coding-agent platform at multica.ai whose README tagline is "Agents that show up on the board", not the unrelated automation service at multica.uk.

AQ vs Multica at a glance

What is Multica?

Multica is one of the fastest-growing projects in the coding-agent space: roughly 50,000 GitHub stars as of September 2026, releasing multiple versions per week. Its pitch is that agents should show up on the board like anyone else. You give each agent a name, a provider, and a runtime, then assign it an issue the way you would pick a colleague as assignee. The agent picks the task up, runs it, comments when it needs clarification or hits a wall, and moves the issue to review when done. Work lands in review, not in main; a human decides what ships.

The execution layer is deliberately yours. Self-hosting runs a Go backend and web frontend against PostgreSQL (Docker Compose for most teams, a Helm chart for Kubernetes), and the agent work happens through a daemon on your own laptop or cloud machine. The daemon detects the agent CLIs you already have installed (Multica lists 26, from Claude Code and Codex to Cursor Agent, GitHub Copilot CLI, OpenCode, Kimi, and Grok), registers them with the server, and executes assigned tasks locally, so your code stays on machines you control. A hosted Multica Cloud exists as the no-ops alternative.

Around the core loop, Multica has built real team machinery: squads that put agents and people on one team with a leader routing the work, skills that turn a solved problem into a playbook other agents reuse, autopilots that run standups, audits, and reports on a schedule, and workspaces with owner, admin, and member roles. Every run leaves a timestamped execution log you can replay, tool call by tool call, with cost tracked per agent and per issue. It works with GitHub, GitLab, Gitea, and Forgejo, including self-hosted instances, on web, desktop (macOS, Windows, Linux), and iPhone, plus a CLI and API. One thing to read before betting on it: the license is not plain Apache 2.0. The Multica License is the Apache 2.0 text plus additional conditions covering hosted services, commercial embedding, and branding; self-hosting and modification are permitted, but offering Multica as a hosted or embedded service requires a commercial license.

What is AQ?

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud.

On AQ the agents are the real CLIs your engineers already use (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells), running in persistent tmux sessions on the team's VM and streamed live to the browser. Each engineer signs in with their own Claude or OpenAI account, and AQ never marks up usage on your own subscriptions. Every workspace gets one isolated git worktree (branch ai/{id}-{slug}, automatic dependency install, one-click rebase onto main), so parallel sessions never collide. Sessions survive a closed laptop and resume from any device, including a phone. Teammates open the same workspace and watch the same live session; typing into someone else's terminal is delegated by its owner approving a control request in one click, and the owner keeps their own input. Each workspace runs a live dev-server preview with shareable links that work without an account for viewing, and comments pinned on the preview can be sent to the agent as prompts. Label a Linear issue ai-task and a workspace appears, with status syncing both ways; humans start agents, never auto-launched. There is no shared multi-tenant execution tier.

Where Multica stands out

• The assignment model is genuinely clean. If your team already thinks in issues and assignees, giving an agent a name and a spot on the board is the shortest possible path from backlog to delegated work. This is agent orchestration in its most literal form.
• Open source you can run entirely yourself. Backend, frontend, database, and runtime all on your own infrastructure via Docker Compose or Helm, against any of four git hosts including self-hosted GitLab, Gitea, and Forgejo. Teams that cannot adopt a SaaS have a real path here (with the license caveat above).
• Breadth of CLI support. 26 agent CLIs as of September 2026 is the widest catalog we have seen a platform list, and the daemon model means a new CLI is usable wherever it installs.
• Accounting built in. Per-agent, per-issue cost tracking and a replayable execution log answer questions most teams only ask after the first surprising bill or diff.
• Chat-native triggers. Agent work starts and reports from Slack, Lark, DingTalk, WeCom, or Telegram, where teams already coordinate.

Where AQ wins

• You are in the session, not above it. Multica's visibility is the issue thread and the execution log: honest artifacts, but records of the run. On AQ teammates watch the same terminal live and steer mid-run: catch the wrong assumption at minute two instead of reading about it in review.
• The whole workbench is shared, not just the status. A workspace is a terminal, a code editor, and a running dev-server preview with shareable links; a PM or designer can pin a comment on the preview and send it to the agent as a prompt. A board can say a task is in review; it cannot show a stakeholder the running app.
• The machine outlives the laptop. Multica's daemon runs where you put it, and on the default laptop runtime the run's lifetime is the laptop's. AQ sessions run in persistent tmux sessions on an always-on VM, survive the lid closing, and resume from any device.
• Isolation by construction. Every AQ workspace is its own git worktree on its own branch, so parallel agents never collide and every run reviews as ordinary git history.
• Nothing to operate. Multica self-hosted means running a backend, a database, and a daemon fleet, and keeping pace with weekly releases. AQ is a product: connect VMs from your own cloud or use a dedicated AQ-managed VM, with runner health visible in-product, installer preflight, and an aq-runner doctor command.
• Issue intake without a second board. AQ's Linear intake keeps your tracker as the source of truth: label an issue ai-task, a workspace appears, status syncs both ways, ownership follows the assignee.

The deeper difference: dispatching work vs sharing it

Multica and AQ are both reactions to the same fact: agent-assisted development is single-player by default. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans.

Multica's answer is management structure: make agents legible to the team by giving them issues, statuses, review gates, and cost lines, exactly like human teammates. That framing is powerful for delegation at volume, and it is where the board pattern (Multica today, vibe-kanban before it) genuinely shines: ten well-specified tasks, ten agents, one review queue. Its blind spot is the middle of the run. Between "assigned" and "in review" the work is a log to read, not a place to be, and course corrections happen by commenting on an issue rather than by taking the keyboard. AQ's answer is shared presence: the run itself is the thing teammates open, watch, and steer, with control handed over only when the session owner approves it. Boards summarize; rooms show. Most teams eventually want both layers, which is why AQ syncs status out to the tracker you already have instead of becoming one.

Pricing compared

Multica, as of September 2026: self-hosting is free under the Multica License (you pay for your own infrastructure, and hosted or embedded resale requires a commercial license). A hosted Multica Cloud exists; we could not verify published pricing for it as of September 2026. Model usage rides the CLI subscriptions and API keys the agents run on.

AQ has two plans. Free is a personal sandbox for one person: AQ creates a private machine in an isolated network, nothing to install, no time limit. Team is $50 per user per month early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with your rate locked for your first 12 months. Inviting a teammate costs nothing until the person accepts and joins. Model usage stays on each engineer's own Claude or OpenAI account: AQ never marks up usage.

Bottom line

Multica is the strongest open-source statement of the agents-as-teammates thesis: a board where agents take issues, report progress, and hand work back through review, on runtimes you control, with squads, skills, and real cost accounting around it. If your problem is dispatching and tracking many well-specified tasks across many agents, and you are willing to operate the stack, it earns its stars. AQ's bet is one layer closer to the work: before you manage the run from above, be able to stand inside it. Agents on an always-on machine in your own cloud, sessions any teammate can open, watch, and steer live from a browser, one worktree per workspace so parallel runs never collide, and your existing tracker kept in sync instead of replaced. If the question is "who is doing what," a board answers it. If the question is "what is the agent doing right now, and can we fix it together," that takes a room.