How coders work

A coder is one Docker container running an AI agent that's been wired up with a model, a set of tools (file edit, shell, git, MCP), and — for each task it picks up — a clone of your workspace. Coders aren't spawned one per task: they're pooled queue consumers, and ARDS grows and shrinks the pool with demand.

The container lifecycle

Tasks queue up per coding tool and variant (standard, browser, android). ARDS regularly compares each queue's depth with the number of coder containers consuming it, and acts:

  1. Cold start — tasks are waiting and no container is running for that queue → ARDS starts one. This is why the first task after a quiet stretch takes a little longer to leave Pending.
  2. Scale up — the backlog grows past a threshold → another container joins, up to a cap.
  3. Work — a container picks up a task (the task shows InProgress), clones your workspace from the review mirror, and gets going: reads files, runs commands, edits, tests, iterates. Everything happens inside the container — your host filesystem and origin repo never see any of it. Credentials the coder needs (API keys, git tokens) are injected as environment variables when the container starts.
  4. Task end — success, failure, or cancel: the coder commits to a branch on the mirror and pushes. Anything that wasn't committed is lost — by design.
  5. Reuse — the container doesn't die with the task; it goes back to its queue and consumes the next one.
  6. Scale to zero — once a queue has sat empty for a stretch of idle minutes, its containers are removed. A container that exits or turns unhealthy is replaced automatically while work is still queued.

So a container may live through one task or many — but a task's work products live exactly as long as they're committed to the mirror. That point matters for what coders can and can't do, see below.

Inside a workflow, a coder's success, failure, or refusal routes down the workflow's outcome arms — see Anatomy of a workflow.

Coder capabilities

Every task runs on the standard coder image (backend, frontend, MCP tool development — .NET 10 SDK, Node.js, npm, common test frameworks). What varies per task is which extra capabilities are attached to it, drawn from shared capability pools:

  • Browser — a real Chrome for visual testing, browser automation, or E2E flows that need a real DOM.
  • Emulator — an Android emulator for mobile work.
  • Windows tooling — a Windows environment for tasks that need one.

You don't pick these yourself — they're attached when the task calls for them, and most tasks need none of them. If you're curious how a task ran, the task page's details include the provider that served it, the branch it worked on, how many turns it took, and what it cost.

What coders can do

  • Read, edit, and create files in the cloned workspace.
  • Run any command available in the image — dotnet, npm, pytest, etc.
  • Hit the internet for documentation and package downloads.
  • Use MCP tools (the ARDS bridge) to look up project state, validate work, etc.
  • Commit + push to the mirror.

What coders can't do (or won't)

  • Push to your origin repo. Only the approval flow pushes through to origin.
  • Persist work anywhere but the mirror. Only what's committed and pushed survives a task; the container's scratch state is disposable, and idle containers are routinely scaled away.
  • See other tenants' data. The coder pool is per-tenant; one tenant's containers never serve another tenant's tasks.
  • Hold a conversation directly with you. If a coder needs input, it raises an attention request that surfaces in the dashboard — it doesn't pop up a chat window.
  • Edit code outside the workspace. Coders are scoped to one workspace at a time.

Where to read coder logs

On any task page, the Coder session link at the top opens the live session view for that task — everything the coder said and did: the tool calls, the model output, the commands it ran. If a task failed, this is where the cause usually lives. The same data feeds the Costs page (token-level accounting per task — see Tracking costs).

For workflow runs, the run viewer goes further: the node sheet and the Coder session panel show the effective prompt exactly as dispatched, the files touched, a diff on demand, and per-file or zip downloads. See Watching a run.

How long a task takes

Highly variable. Small refactors finish in a couple of minutes; a "write a new module with tests" task might take 10–20 minutes; an "implement feature X end to end" task can run an hour or more. Token usage scales roughly with wall-clock time when the same model is in use.