Daemon and runtimes

In Multica, agents do not run on our servers — they run on your own machines, driven by a small program called the daemon that invokes the AI coding tools installed locally. The Multica server only coordinates: it stores issues, queues tasks, and dispatches them to the right runtime (runtime = daemon × one AI coding tool).

This structure is the biggest difference between Multica and Linear / Jira: your API keys, toolchain, and code directories stay on your machine — the Multica server never sees any of them. That means "my agent isn't working" is almost always a local problem — the daemon isn't running, an AI tool isn't installed, a key has expired. Check locally first; see Troubleshooting for a guide.

Starting the daemon

The daemon is part of the Multica CLI. Once you've installed the Multica CLI, run on your own machine:

multica daemon start

On startup it does four things:

Reads the credentials saved when you logged in
Detects AI coding tools installed on your PATH (10 built-in: Claude Code, Codex, Cursor, Copilot, Gemini, Hermes, Kimi, OpenCode, OpenClaw, Pi)
Registers itself with the server, along with a runtime for each detected tool
Keeps polling every 3 seconds for tasks to pick up, and sends a heartbeat every 15 seconds

Common commands:

Command	Purpose
`multica daemon start`	Start (background by default; add `--foreground` to run in the foreground)
`multica daemon stop`	Stop
`multica daemon restart`	Restart
`multica daemon status`	Show status
`multica daemon logs`	Show logs (add `-f` to follow)

Full CLI reference in CLI commands.

The desktop app ships with a daemon. If you use the desktop app, you don't need to run multica daemon start manually — it launches the daemon automatically on startup.

Why one machine has multiple runtimes

A runtime is not a server and not a container — it's the combination of "daemon × one AI coding tool". For example: you start the daemon on a MacBook with both Claude Code and Codex installed, and you're a member of two workspaces. Multica then registers 4 runtimes:

Rendering diagram…

Key points:

One daemon can map to multiple runtimes — one per combination of installed tool and workspace you belong to
The same daemon, workspace, and tool produces exactly one runtime — restarting the daemon never creates duplicate records
The Runtimes page in the Multica UI lists these rows

Cloud runtimes are coming, currently in a waitlist phase. Once available, you'll be able to execute agent tasks directly on Multica Cloud without running a local daemon. Sign up with your email on the download page to get notified.

When a runtime is marked offline

Multica uses heartbeats to decide whether a runtime is online. Three key numbers:

Event	Threshold
Daemon heartbeat frequency	Every 15 seconds
Marked as missing	No heartbeat for 45 seconds (3 missed beats)
Auto-deleted	Missing with no associated agents for over 7 days

Missing is not permanent — as soon as the daemon sends another heartbeat it returns to online, and the runtime record is preserved. Restarting the daemon does not lose runtimes.

Tasks running on a missing runtime are marked as failed (failure reason runtime_offline). For retryable sources (issues, chat), Multica automatically requeues them; Autopilot-triggered tasks are not retried automatically. See Tasks → Which failures retry automatically.

How many tasks can run in parallel

Multica enforces concurrency limits at two layers:

Daemon layer: 20 concurrent tasks by default (tunable via env var MULTICA_DAEMON_MAX_CONCURRENT_TASKS)
Agent layer: 6 concurrent tasks per agent by default (configured per-agent)

The tighter of the two wins. If your daemon is already running 20 tasks, new tasks wait even if an agent still has headroom.

If you see tasks stuck in queued without moving to dispatched, one of these two limits is usually saturated.

What happens to in-flight tasks after a daemon crash

When the daemon crashes or is force-killed, the tasks it had picked up are left in dispatched or running. On the next start, the daemon tells the server: "these tasks are no longer mine, please mark them failed." The server flips them to failed with reason runtime_recovery — for retryable sources, the tasks are automatically requeued.

Even if this step fails due to a network issue, there's a server-side scan every 30 seconds as a backstop: any runtime without a heartbeat for over 45 seconds is marked missing, and its tasks are reclaimed along with it.

Troubleshooting agents that aren't working

When you hit a "my agent isn't working" problem, run this three-step checklist first:

Run multica daemon status — confirm the daemon is running and online
Run multica daemon logs -f — check for errors
Open the Runtimes page in the Multica UI — confirm your runtime shows "online"

More scenarios in Troubleshooting.

Tasks — the full lifecycle of a task once the daemon picks it up
Providers Matrix — capability differences across the 10 AI coding tools