Daemons and runtime

This structure brings about the biggest difference between Multica and Linear/Jira: Your API key, tool chain, and code directory are all kept locally, and the Multica server cannot see any of them. "My agent is not working" problems are almost always local problems - the daemon process is not started, a certain AI tool is not installed, the key has expired - please check locally first; for location guidance, see Troubleshooting.

multica daemon start

After starting it will do four things:

1. Read the credentials you saved when logging in
2. Detect AI programming tools installed on the local PATH (built-in support for 12 models: Antigravity, Claude Code,Codex,Cursor,Copilot,Gemini,Hermes,Kimi,Kiro CLI, OpenCode, OpenClaw, Pi)
3. Register yourself with the server and the runtime corresponding to each detected tool
4. Continuously poll every 3 seconds to see if there are any task essentials, send a heartbeat every 15 seconds

Commonly used commands:

Command	Function
multica daemon start	Start (default background, add --foreground to run in the foreground)
multica daemon stop	stop
multica daemon restart	Restart
multica daemon status	View status
multica daemon logs	View logs (follow with -f)

For a complete CLI reference, see CLI Command Quick Reference.

**The desktop application comes with its own daemon. **With Desktop Application, you don’t have to manually multica daemon start - it will automatically start the daemon process when it starts. Which method is more suitable for your workflow? See the Desktop App page for details.

graph TD
    D["Your daemon<br/>MacBook"]
    D --> R1["Runtime<br/>Workspace A × Claude Code"]
    D --> R2["Runtime<br/>Workspace A × Codex"]
    D --> R3["Runtime<br/>Workspace B × Claude Code"]
    D --> R4["Runtime<br/>Workspace B × Codex"]

Key points:

• One daemon can correspond to multiple runtimes - multiple tools are installed and multiple workspaces are added, one for each combination
• There will only be one runtime for the same daemon process on the same tool in the same workspace - restarting the daemon process will not generate duplicate records
• The Runtimes page of the Multica interface lists these lines

multica runtime profile list
multica runtime profile create --display-name "Composer" --protocol-family codex --command-name agent
multica runtime profile update <profile-id> --command-name agent
multica runtime profile delete <profile-id>

What is filled in here is the argv style command, not the shell string. Multica stores the executable file name and fixed parameters, and the daemon process will be started directly using exec.Command(command_name, fixed_args...). Supports normal parameters, quotes and backslash escaping; does not support pipes, redirections, &&, ;, backticks, $VAR / $(...) expansion. When shell behavior is required, wrap it with a wrapper script. Currently, the entry for parsing commands and parameters is in the Runtimes UI; the profile command of the CLI is responsible for managing profile records and local path coverage.

If the daemon process launched by the desktop application cannot find the command you can run in the terminal, you can fix the absolute path on this machine:

multica runtime profile set-path <profile-id> --path /abs/path/to/agent
multica runtime profile unset-path <profile-id>

After modifying the command or parameters of the profile, the started tasks will still use the parameters at startup; only after the daemon is re-registered, the newly received tasks will use the new configuration. When deploying mixed versions, it is recommended to upgrade the server first, and then gradually upgrade the daemon: fixed_args is entered in the Runtimes UI on the server side, and the failed_profiles registration report is also displayed by the server. Old components may ignore fields they don't recognize instead of explicitly reporting errors; upgrading the server first can make the rollout more observable.

Cloud runtime will be available soon, currently on the waiting list. Once online, you can execute agent tasks directly on Multica Cloud without running a daemon locally. Register your email address on Download Page to get notifications.

Event	Threshold
Daemon heartbeat frequency	every 15 seconds
Mark as lost	No heartbeat for more than 45 seconds (missed 3 times)
Automatic deletion	Lost contact and no associated agent for more than 7 days

The loss of connection is not permanent - the daemon comes back online as soon as it sends a heartbeat again, and runtime records are retained. Restarting the daemon does not lose runtime.

Execution tasks running on the lost runtime will be marked as failed (failure reason runtime_offline). For retryable sources (issue, chat), Multica will automatically requeue; tasks triggered by Autopilots will not be automatically retried. For details, see [Execute tasks → Which failures will be automatically retried] (/tasks# Which failures will be automatically retried and which will not).

• Daemon layer: Default 20 concurrent execution tasks (environment variable MULTICA_DAEMON_MAX_CONCURRENT_TASKS is adjustable)
• Agent layer: Each agent has 6 concurrent task executions by default (changed in the agent configuration)

The tighter of the two layers takes effect. If your daemon is already running 20 tasks, new tasks will have to wait even if there is room for an agent.

If you see that the execution task is stuck in the queued state but not dispatched, it usually means that one of the two layers is full.

Even if this step is not completed due to network problems, there is still a server-side scan every 30 seconds as a backup: runs without heartbeats for more than 45 seconds will be marked as disconnected, and the above tasks will also be recycled.

1. Run multica daemon status to confirm that the daemon process is running and online
2. Run multica daemon logs -f to see if there are any errors
3. Go to the Runtimes page of the Multica interface and confirm that your runtime displays "Online"

See Troubleshooting for more scenarios.

• Execute tasks - After the daemon process receives the task, its complete life cycle
• Providers Matrix - Comparison of the capabilities of 12 AI programming tools