Tasks

A task is the unit of every agent run — assigning an issue to an agent, @-mentioning an agent in a comment, sending a message in chat, or an Autopilot firing on schedule all produce a task. Multica puts it in a queue; a daemon picks it up and hands it off to the corresponding AI coding tool, then writes the result back to the server when it finishes.

Tasks and issues are two different objects. A single issue can be assigned, @-mentioned, and manually rerun many times — each produces a new task.

The states a task goes through

• Queued — the task was just created and is waiting for a daemon to pick it up
• Dispatched — a daemon has claimed it and is starting the AI coding tool
• Running — the AI coding tool is actually doing the work
• Completed — finished successfully; the output (comments, code commits, status changes) is written back to the server
• Failed — aborted with an error or timeout; if the failure reason is retryable, the task automatically returns to queued for another attempt
• Cancelled — the user cancelled it

What happens when a task times out

The Multica server scans every 30 seconds. Two kinds of timeout trigger a failure:

Both timeouts use failure reason timeout and retry automatically (next section). For the related runtime-missing check, see Daemon and runtimes → When a runtime is marked offline.

Which failures retry automatically, which don't

Failures fall into two categories: retryable and non-retryable.

Retryable (Multica automatically requeues):

• runtime_offline — the daemon went missing after the task was dispatched
• runtime_recovery — the daemon crashed and restarted, reclaiming tasks it didn't finish
• timeout — runtime or dispatch timeout

Non-retryable (the task stays in failed):

• agent_error — the AI coding tool itself reported an error (API error, quota exceeded, internal bug). Underlying problems aren't retried — that would loop forever.

Automatic retry also has two extra conditions:

1. At most 2 attempts — 1 original + 1 retry. If the retry also fails, no further retries, even if the reason is retryable.
2. Only for issue- and chat-triggered tasks — Autopilot-triggered tasks do not retry automatically.

Manual rerun vs. automatic retry

A manual rerun is one you trigger from the CLI or the API (POST /api/issues/{id}/rerun):

multica issue rerun <issue-id>

Behavior:

• By default, targets the issue's current agent assignee — useful when you want the rerun to follow the current assignment regardless of who ran the prior task.
• The execution-log retry button on a specific row sends that row's task ID alongside, so the rerun targets the agent that ran that exact task — not the current assignee. This makes per-row retry meaningful for squad workers, parallel @-mention agents, or rows whose agent has since been displaced by a reassignment.
• Cancels the target agent's queued or running task on this issue (if any). Tasks owned by other agents on the same issue (e.g. parallel @-mention runs) are left alone.
• Creates a brand-new task — attempt count resets to 1, even if the original task hit the attempt ceiling.
• Reuses the workdir; the session is resumed conditionally — and this depends on how you triggered the rerun:
  • Execution-log per-row retry (carries a task ID): reuses that exact run's working directory, so files already written to disk are preserved. It resumes that run's agent session too — unless the failure poisoned the conversation (context overflow, iteration limit, invalid request, Codex semantic inactivity, agent fallback), in which case it starts a fresh session on top of the reused workdir. If the original directory is gone (garbage-collected, on a different runtime, or never recorded before the failure), it falls back to a fresh workdir. So a transient failure — a network blip, a provider 5xx / rate-limit, a runtime that briefly went offline, or an auth/quota/config error you've since fixed — continues from where it left off instead of starting over.
  • CLI / API rerun without a task ID: there is no specific run to continue, so it starts a fresh agent session in a fresh workdir.

Comparison:

How a failed task affects issue status

If an issue-triggered task fails (and no automatic retry succeeds) because the issue was assigned to an agent, the issue's status automatically rolls back from in_progress to todo — so when you open the board you immediately see "this one needs another look." See Issues and projects.

Can a task continue from the previous context

Yes — as long as the AI coding tool supports session resumption.

Multica pins the session ID twice during a task: once at the start (when the AI tool returns its first system message), and once at the end (on completion or failure). The first lets the daemon recover if it crashes mid-run; the second is passed back to the next automatic retry and to an execution-log per-row retry, so the agent picks up the previous conversation and file state — unless the failure poisoned the conversation, in which case only the workdir is reused and a fresh session starts. A CLI / API rerun without a task ID starts a fresh session in a fresh workdir — see Manual rerun vs. automatic retry.

But which AI coding tools actually support this varies a lot:

• ✅ Real support — Antigravity, Claude Code, Codex, Copilot, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
• ❌ No support — Gemini

See Providers Matrix → Session resumption.

Next

• Providers Matrix — capability differences across the 16 AI coding tools (including the exact session-resumption status)
• Assigning issues to agents / @-mentioning agents in comments / Chat / Autopilots — the four ways to trigger a task