0fe2ebf02e MUL-8045: feat(runtimes): Qoder Cloud Agent as a managed cloud runtime (#9402)
* feat(runtimes): add Qoder Cloud Agent managed remote execution

* fix(qoder): satisfy migration and localization CI contracts

* fix(qoder): bound execution and scope managed credentials

* fix(qoder): avoid upstream migration number collisions

* fix(qoder): gate issue creation and correlate tool results

* fix(qoder): synchronize guarded issue lifecycle transitions

* test(agent): publish Hermes holder identity atomically

* feat(agents): runtime-first create flow and cloud runtimes section for Qoder Cloud Agent

- Three-step create-agent flow (runtime -> configure -> done) with local,
  remote and cloud sections; Qoder connect form inline in the runtime step
- Runtimes page regrouped into remote and cloud sections with Qoder card
- Generalize Qoder storage to cloud_agent_connection (migrations 586/587)
- Locales for en, zh-Hans, ja, ko, fr; desktop and web routes for done step
- Fix status-picker fixture owner_id and diagnostics route coverage after main merge

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* feat(runtimes): unify runtimes page into machines and cloud services

- One Add menu replaces Add remote runtime, the duplicated Add a computer
  and the web-only Cloud Runtime header button
- Group by machines / cloud services instead of local / remote / cloud, so
  web and desktop share one structure; this device is pinned with a badge
- Cloud services use the machine row anatomy in a single ListGrid table;
  unconnected Qoder is a row with Connect, coming-soon providers are rows
- Empty groups show the next step inline; search and online/offline filter
- Rename computer to machine across runtimes copy in all locales

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* test(runtimes): cover unified runtimes page; pin status and action tracks

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* refactor(runtimes): trim redundant descriptive copy on runtimes page

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(runtimes): keep row actions visible at narrow widths

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* refactor(runtimes): align Qoder add-menu item with other cloud services

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(runtimes): close the Qoder dialog after a first-time connection

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* feat(agents): pick the runtime from one grouped list

The runtime step showed four kinds of cards, a comparison panel and
per-section descriptions. It is now one list in the runtimes-page layout:
machines (this one open, others folded to a row) and cloud services. An
unconnected Qoder opens the runtimes-page connect dialog in place and is
selected once it comes online.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): show owners as 'you' and bare version numbers in the runtime list

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* feat(qoder): disconnect action and dedicated Qoder runtime page

Disconnect removes the encrypted connection and the managed runtime, unbinding
its agents after the admin confirms them. The Qoder row now opens its own page
(status, agents, usage, configuration, pause/resume, disconnect) instead of the
machine layout; generic runtime delete and visibility refuse a managed runtime.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): land on the done page after creating from step 2 on desktop

Desktop's location is the tab URL, which moves to /agents/new/done/<id>
while the configure page is still mounted. Its missing ?runtime= tripped
the skipped-step-1 redirect and replaced the tab back to /agents/new, so
Create looked like it did nothing. Only redirect on the manual route.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): show only settings a Qoder agent can run with

The Qoder bridge fails every task whose agent carries a model, thinking or
speed override, env, custom args, custom skills, MCP config or connected
apps, and it runs issues only. The agent detail page still offered all of
those editors, so one save could break every later run.

For a qoder_cloud agent the page now keeps Instructions under Capabilities,
General / Access / QCA Agent under Settings, drops the model rows and the
header model chip, shows the QCA agent in the summary, and locks the
runtime. Other agents no longer see the Qoder runtime in their picker,
since moving onto it needs a QCA agent the server would otherwise reject.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): hide conversation starters for Qoder agents

Starters only appear in a chat, and the Qoder bridge runs issues only.
The create flow already leaves them out for this runtime.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* feat(runtimes): show the Qoder connection as cards with per-section editing

The Qoder runtime page rendered the whole connection as one always-editable
form. It now summarizes the connection, repositories and limits as read-only
cards; each section opens its own dialog and saves only that section.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(qoder): reuse a follow-up session only with the same repository and credential

Resolve repository credentials before deciding to continue a prior session,
and stamp each session with a fingerprint of its repositories, branches and
tokens. A follow-up continues only when the fingerprint still matches, so a
changed repository, branch or rotated/revoked token never rides into an old
session.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(qoder): keep a paused connection paused when its settings are saved

Saving repositories, limits or the connection no longer re-enables a paused
runtime. Resume goes through a new POST /qoder/resume.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): drop settings a Qoder agent cannot run when creating one

A draft started on another runtime could carry hidden skills, model
overrides and starters into a Qoder agent that then failed every task. The
create request now drops them for Qoder, and the API rejects skills and
execution overrides on Qoder agents at save time.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* chore(db): regenerate sqlc models for cloud_agent_connection

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(runtimes): never list the Qoder runtime under Machines

When the server could not run Qoder (no MULTICA_VCS_SECRET_KEY /
MULTICA_QODER_STATE_DIR), the managed Qoder runtime fell back into the
Machines group as if it were a computer.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* refactor(qoder): drop MULTICA_QODER_STATE_DIR

The managed bridge keeps its run journal encrypted in cloud_agent_connection
and a database advisory lock already elects one supervisor, so the state
directory only held a redundant file lock and acted as a feature switch.
Qoder is now available whenever MULTICA_VCS_SECRET_KEY is set. The
standalone qoder-runtime command still uses its on-disk state_dir.

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(qoder): keep the branch in the session fingerprint after a journal restore

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

* fix(agents): validate Qoder agents' effective settings on every write

Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>

---------

Co-authored-by: 安辰 <[email protected]>
Co-authored-by: Cursor <[email protected]>
Co-authored-by: multica-agent <[email protected]>
2026-10-22 01:33:38 +08:00

Multica

Multica

Agents that show up on the board.

Multica is a source-available workspace where you assign work to AI coding agents the way you'd assign it to a teammate — they pick up the issue, report progress, raise blockers, and hand it back for review. Self-hostable, works with the agent CLIs you already use, no lock-in.

CI Release GitHub stars Discord

Star History Rank GitHub Trending Repository of the Day

Website · Docs · Quickstart · Download · Vision · Self-Hosting · Discord · X

English | 简体中文

A Multica board where agents and their human teammates are moving work across columns

Your next 10 hires won't be human.


What is Multica?

You already run Claude Code, Codex, and three other agents. Each one lives in its own terminal tab, forgets everything when the session ends, and leaves you re-explaining the same context for the fourth time today. The more agents you add, the more of your day goes to babysitting them.

Multica puts those agents and your teammates in one workspace. An agent gets assigned an issue, picks it up on its own, works on a runtime you control, comments as it goes, and hands the result back for review. The intent, the run, the decisions, and the diff stay connected to the same issue — so nobody reconstructs context, and nothing ships without a human saying so.


Build the team.

Claude Code, Codex, Cursor, Kimi — you don't pick one. You hire them all.

  • The agent CLIs you already use → Claude Code, Codex, Cursor, Copilot, Kimi, OpenCode, and more.
  • Agents as teammates → Give each one a name, a provider, and a runtime — they show up on the board like anyone else.
  • Squads → Put agents and people on one team; the leader routes the work.
  • Skills → Turn a solved problem into a playbook every agent reuses.
  • Your own runtime → Their desk is your machine — a daemon on your laptop or cloud box. Code never leaves it.

Hand off the work.

It starts as three rough sentences in an issue. It ends as a pull request.

  • Assign an issue → Pick an agent as assignee the way you'd pick a colleague — it takes the work from there.
  • Autopilots → Run standups, audits, and reports on a cron — nobody to remind.
  • Chat → Ask your workspace a question, or start work without filing anything.
  • Projects → Group work and attach the repos and docs agents need as context.

Stay in the loop.

Which agent touched this? What did it run? What did it cost? Open the run.

  • Execution log → Replay every tool call, command, and error, timestamped.
  • Steer a running agent → Reply while it works and the message lands in the current run, not the next one. Claude Code, Codex, Grok, and Kiro today.
  • Usage analytics → See what each run cost, per agent and per issue.
  • Review gates → Work lands in review, not in main. You decide what ships.
  • Inbox → Get pinged when an agent needs a call, not for every step.
  • Retries and timeouts → Failed runs retry on their own, or stop and tell you why.

Make it yours.

Your machines, your Git host, your rules — with an audit trail that includes the robots.

  • Self-host everything → Docker Compose or Helm, on your own infrastructure.
  • Your Git host → GitHub, GitLab, Gitea, or Forgejo — self-hosted included.
  • Workspaces → Separate agents, issues, and settings per team.
  • Roles and access scopes → owner, admin, and member — and exactly which agents each member can run.
  • Security model → What an agent can reach, and what it can't.
  • Slack, Feishu/Lark, DingTalk, WeCom, and Telegram → Trigger and follow agent work where your team already talks. New Feishu/Lark connections are open to mainland-China Feishu only for now; DingTalk, WeCom, and Telegram are community-maintained.
  • Web, desktop, and mobile → The same workspace on macOS, Windows, Linux, iPhone, and iPad — the iOS app builds from source today, not yet on the App Store.
  • CLI and API → Every surface is scriptable. Agents drive Multica through the same CLI you do.

Get started

  • Cloud — sign up at multica.ai. No terminal required.
  • Desktop — download Multica Desktop for macOS, Windows, or Linux. It connects the computer it runs on as a runtime automatically.
  • Self-host — run the whole stack on your own infrastructure; see below.

The one prerequisite: the machine that will run agents needs at least one supported agent CLI installed and signed in — Claude Code, Codex, Cursor, and friends. Multica drives them; it doesn't ship them.

Self-hosting the whole thing
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host

On Windows, set $env:MULTICA_MODE="with-server", then run the PowerShell installer: irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex.

This pulls the official images from GHCR and requires Docker. See the Self-Hosting Guide; if the selected GHCR tag has not been published yet, fall back to make selfhost-build from a checkout.

A self-hosted server sends one anonymous, deployment-level snapshot a day: the release version plus bucketed counts, with no names, content, or IDs. Set DO_NOT_TRACK=1 on the API server to turn it off — what's collected.

Your first agent in five minutes

1. Connect a computer. A runtime is any machine agents can work on — your laptop, or a cloud box. Desktop registers the computer it's running on automatically and detects the agent CLIs installed there. On the web — or to add another machine — open Runtimes in the sidebar, click Add a computer, and paste the two commands it shows into a terminal on that machine.

2. Create an agent. Open Agents in the sidebar and click New agent. Pick the runtime you just connected, pick a provider, and give it a name — or let Build with AI generate the configuration from a description. That name is how it shows up on the board and in comments.

3. Assign it something. File an issue and set the agent as assignee. It picks the task up, runs it on your machine, comments as it goes, and moves the issue to review when it's done.

Full walkthrough: Quickstart · Tutorial


Runtimes

Multica does not ship a model. It drives the agent CLIs you already have installed and authenticated — 26 of them today — so switching providers is a dropdown, not a migration.

Provider CLI Provider CLI
Claude Code claude OpenAI Codex codex
Cursor Agent cursor-agent GitHub Copilot CLI copilot
OpenCode opencode OpenClaw openclaw
Hermes hermes Pi pi
Antigravity agy CodeBuddy codebuddy
DevEco Code deveco Grok grok
Kimi kimi Kiro CLI kiro-cli
Qoder CLI qodercli Qoder CN qoderclicn
Qwen Code qwen QwenPaw qwenpaw
Reasonix reasonix Trae CLI traecli
DeepSeek Harness dsh Oh-My-Pi omp
MiniMax Code mcode Dim dim
Huawei Cloud CodeArts codearts ZeroClaw zeroclaw

Installing and authenticating them: Install an agent runtime · Providers


Documentation

I want to… Start here
Get an agent doing something today Quickstart · Tutorial
Understand how the pieces fit Core concepts · How Multica works
Create and configure agents Agents · Create an agent · Skills
Get work to an agent Triggering agents · Assigning issues · Mentions
Connect my machines Daemon and runtimes · Install an agent runtime
Connect Git and chat tools GitHub · Self-hosted Git · Channels
Run it on my own infrastructure Self-hosting · Security model · Environment variables
Script it CLI reference · CLI and daemon guide · Auth tokens
Drive Multica from Codex, Claude Code, or Cursor Multica CLI skill
Work out why an agent is stuck Runs · Troubleshooting

The docs are also available in 简体中文, 日本語, 한국어, and Français.


Architecture

   Web (browser)        Desktop (Electron)        iPhone · iPad (Expo)
         │                      │                          │
         ▼                      │                          │
  ┌──────────────┐              │                          │
  │   Next.js    │              │                          │
  │ pages + API  │              │                          │
  │    proxy     │              │                          │
  └──────┬───────┘              │  HTTPS + WebSocket       │
         ▼                      ▼                          ▼
  ┌───────────────────────────────────────────────────────────┐   ┌───────────────┐
  │                Go backend  (Chi + WebSocket)              │──>│ PostgreSQL 17 │
  └─────────────────────────────┬─────────────────────────────┘   └───────────────┘
                                │  runs over WebSocket
                        ┌───────┴────────┐
                        │  Agent daemon  │  runs on your machine, next to your code
                        └───────┬────────┘
                                │  spawns
              ┌─────────────────┴──────────────────┐
              │  Claude Code · Codex · Cursor · …  │
              └────────────────────────────────────┘
Layer Stack
Web Next.js 16 (App Router)
Desktop Electron, sharing the web UI packages
Mobile Expo / React Native (iPhone and iPad)
Backend Go (Chi router, sqlc, gorilla/websocket)
Database PostgreSQL 17 (pgcrypto + pg_trgm)
Agent runtime Local daemon executing any supported agent CLI

Development

Contributors: start with the Contributing Guide.

Prerequisites: Node.js 22, pnpm 10.28.2, Go 1.26.9, Docker

make dev

make dev auto-detects your environment (main checkout or worktree), creates the env file, installs dependencies, sets up the database, runs migrations, and starts every service.

See CONTRIBUTING.md for the full workflow, worktree support, testing, and troubleshooting. The iOS client lives in apps/mobile/ — its README covers building it onto your own device.

We release most weekdays, so main moves quickly — pull often.


Why "Multica"?

Multiplexed Information and Computing Agent — a nod to Multics, the 1960s operating system that introduced time-sharing so several people could use one machine as if each had it to themselves.

Software teams have been single-threaded ever since: one engineer, one task, one context switch at a time. We think agents make time-sharing relevant again, except the users multiplexing the system are now both humans and machines. A small team shouldn't feel small.

The longer argument, and where we think this goes: VISION.md.


License

Multica License — the complete Apache License 2.0 text plus additional conditions covering hosted services, commercial embedding, and branding. Self-host it, modify it, build on it; the exact terms are in the LICENSE, attribution notices in NOTICE.

S
Description
Make humans and AI agents work as one team — open-source and self-hostable. — mirror of https://github.com/klinsmaya/multica
https://multica.ai
go
Readme Apache-2.0
179 MiB
Languages
Go 55.2%
TypeScript 38.3%
MDX 5%
PLpgSQL 0.4%
JavaScript 0.4%
Other 0.6%