A background run is long work that DataMind Oda starts and leaves running while the chat carries on. Several kinds of work can register as a job: a workflow fanning out across many subagents, a command in a shell, a send to a terminal session, or a one-shot subagent. This page covers how to follow a job, read it and stop it. Which session a job belongs to, how much output it keeps and the limits on how many can run are on Background jobs: limits and lifecycle.
workflow "<name>" started in the background as job <jobId>.Every kind registers as a job that belongs to the session that started it, and every kind is read, listed and stopped through the same three job tools: job_list, job_output and job_kill.
The job list sits in the session header and shows the session's jobs, one row each. While a run works, its row and its output view carry live lines:
▸: ▸ Scan.agent #1 <label> started as one starts, and a matching line with its outcome as it ends.The lines narrate the run for watching; they are not part of the job's output. A row updates when the job's state changes: when it starts, when its progress changes, when a stop is requested, and when it settles. The current phase also shows on the row as its progress line.
The output view follows what the job writes and keeps a bounded tail of the newest text. Where earlier bytes were dropped or are no longer kept, it marks the gap at that point, and a retained tail always ends on a whole character.
job_list lists the session's jobs.job_output reads one job's output, continuing from where the last read stopped. It opens with the job as it stands, follows the output as it arrives, and closes with the final status once the job settles.cancelled by the user.job_kill, which takes a short reason. With no reason given, a background workflow run records background workflow job killed.A background run does not watch the step that started it, so ending that step, or stopping the turn it belonged to, leaves the job running. Stop the job itself, from its row in the job list or with job_kill.
A Ralph loop folds into a single row in the Activity monitor, with each round of the loop as a member of that row. The loop's records are observational and never reach a model request. The tool is described in The Ralph tool; the panel that gathers running work is Activity.
started in the background as job <id> mean?Oda has accepted the work as a background job, and the chat is free again. The run keeps going while you carry on: Oda checks it with job_output and stops it with job_kill, and a workflow run's return value arrives when it finishes.
In the job list, which sits in the session header and lists the session's jobs. A running job's row carries the run's live lines, and its output view follows the output as it is written.
▸ <phase> marks a phase of the run starting. A plain line is a log message the run wrote. agent #1 <label> started and the matching line with its outcome track each helper the run starts and ends.
Use the stop control on the job's row in the job list, or ask Oda to stop it, which uses job_kill. A stop from the list records the reason cancelled by the user; a workflow run stopped without a reason records background workflow job killed.
No. A background workflow run reports no intermediate value: until it settles, a check reports its status only. The return value comes back with the completion notice when the run finishes.
The view keeps only a bounded tail of the newest text. Where earlier bytes were dropped or are no longer kept, it marks the gap at that point; output after the mark continues as normal. How much output a job keeps is on Background jobs: limits and lifecycle.
No. A background run does not watch the step that started it: once the work is a job, stopping the turn it came from leaves the job running. Stop the job itself, from its row in the job list or with job_kill.
As one row, with each round of the loop as a member of that row. The loop's records never reach a model request.