Local workers

Task Machine uses Cloud execution by default. A paid workspace can start Task and Chat work there without connecting a computer. The Local workers settings page is only for optional computers that provide files, credentials, software, or accounts already under your control. Workspace-wide Cloud and Run capacity appears on the separate Limits settings page. This chapter explains how local workers report their tools and what makes one ready for an agent's next task.

A machine reports its tools

A machine is a registered computer running Task Machine's local tama program. Once connected, that local process does two jobs on a steady cadence: it tells Task Machine the machine is alive, and it reports which coding tools it found installed there. Each machine carries a name, the CLI version it runs, and a heartbeat — the timestamp of its last check-in — so the workspace can tell a live machine from one that went quiet.

Hanging off each machine are its workers: one record per coding tool Task Machine found there, such as Claude Code or Codex. A worker record holds the tool's name and provider, its installed command path and version, and what the tool reports it can do — the models and reasoning levels available through it, which is what an agent profile chooses from. The local process refreshes this list every time it checks in, so when you install a new tool it appears, and when you remove one its worker drops off the machine. What you see in the workspace is the current state of that computer's toolset, not a snapshot from when you first connected it.

The machine also reports where on disk it runs agent work: its execution root, the directory under which Task Machine creates one folder per workspace and task or chat so each run has an isolated place to read and write files. It defaults to a folder under the home directory of the account running tama and can be pointed elsewhere through the CLI's config file, which getting started covers. Reporting it lets you see from the workspace exactly where a machine will run an agent's work before you trust it with any.

When several Runs are ready on the same connected computer, Task Machine uses that computer's available processors and memory to decide how many can start together. Under elevated processor load, new Runs start one at a time. Sustained pressure pauses new starts until the computer recovers, without interrupting work already running or permanently shrinking the computer's capacity. Starts then resume one at a time while Task Machine rechecks the load. New Runs also wait when there is not enough memory headroom, so connecting multiple workspaces or installing several coding tools cannot make each one independently claim the machine's full resources.

A machine is online only when it is actually checking in

A machine counts as online only when it reports an online status and its last heartbeat is recent. The status alone is not enough, and the reason is simple: if the laptop closed or the local process stopped, that computer cannot reach back to mark itself offline. So Task Machine treats a machine as available only while its heartbeats keep arriving inside a short freshness window, and a machine whose check-ins go stale is treated as offline no matter what its last status said. Workers follow the same rule, because a tool is only runnable while the machine that reports it is live.

This freshness model is what makes the online indicators trustworthy. When an agent's chosen worker goes stale — the machine it lives on went to sleep — the agents that depend on it can no longer run, and Task Machine raises that to the inbox of the people who manage agents rather than letting work silently pile up against a dead machine. Keeping a machine online is therefore mostly about keeping Task Machine running on that computer, which getting started covers.

Task Machine enforces CLI compatibility

Each heartbeat includes the tama version the machine is running. Task Machine advertises the latest published CLI version and can set a minimum supported version. When a machine falls behind, the Local workers page shows an update status and workspace managers receive an Inbox nudge with an Update now action. If the minimum version rises, outdated machines can still check in and report update progress, but they cannot start new agent work until they update.

The update action in machine settings does not connect your browser directly to the local process. For versions that can restart safely, it queues an update request for the machine. The machine receives the request on its next outbound heartbeat, downloads the trusted release, verifies it, installs the new tama binary, and restarts with that release. Older versions instead show manual update guidance and never receive a background update request, because they need you to restart Task Machine directly on the computer after replacing the CLI.

Owners decide which tools agents may use

Detecting a tool is not the same as approving it for agents, and the two are kept separate on purpose. Enabling a worker for agents makes that runtime and its models available when an owner configures an agent. Disabling it removes those choices without uninstalling the tool or stopping the machine from reporting what it detected. An owner can also remove a machine entirely, which clears it and its workers from the workspace.

A separate Pause action on a Local Machine temporarily stops every worker it reports from accepting new runs without hiding those workers or changing any agent that already uses them. Runs already in progress continue until they finish, while queued work waits. Resume returns all workers on the machine to rotation and rechecks work that could not be assigned during the pause. Machine heartbeats keep connectivity and tool details current but never resume the machine on their own.

So a worker is genuinely ready for an agent only when four things hold at once: its machine is online and not paused, the worker itself is freshly reported, and an owner has enabled it for agents. Each condition has one meaning: connectivity says the computer can respond, enablement controls configuration visibility, and the machine pause controls temporary run admission for every installed worker at once.

Cloud execution is available without a machine

Cloud execution is part of every operational Workspace access contract, not a separately purchased worker product. Task Machine provisions managed execution only while work needs it. You do not choose infrastructure sizes or buy individual worker slots.

A Workspace can have at most ten Tasks with active Cloud Runs. Several Cloud Runs for one Task still belong to that Task's one active Task slot, while the separate Cloud Runs limit counts each Run. Chat Runs use their own bounded lane. Local Runs do not claim Cloud Task capacity.

When all ten managed Task slots are active, additional managed Tasks wait visibly until capacity becomes available. A scheduled Task whose start time has passed remains ready and can show that it is late. Task Machine does not interrupt healthy work already running to make room. The Limits page shows this self-service ceiling alongside Cloud, Local, Scheduled, and Chat Run capacity, including the reserved usage currently occupying each limit. Those usage counts update live as work starts, queues, and finishes. Workspace managers may request a higher limit for review, but submitting a request neither changes capacity automatically nor promises approval.

Managed Task and Chat worktrees remain available for 60 days after each managed run so later work can continue from the same files. Running the Task or continuing the Chat extends the date. Retained storage is charged one complete rolling day in advance while those files remain available. At the displayed deadline, Task Machine removes the cloud files while preserving the Task or Chat, transcript, comments, receipts, and separately saved results.

From here, Getting started explains when to use Cloud execution and walks through the optional tama setup for a local machine, while Workspace pricing and access explains access contracts, monthly usage, and managed capacity.