Skip to content

Detached runs

A server job executes inside the threadle process, not the browser tab. Close the tab, quit the browser, walk away — the run continues, logs into the job registry, and persists node statuses and outputs back to the graph under ~/.config/threadle/graphs/.

You already use this path when you press ▶ Run on a graph without interactive gates. is the explicit control (including approve-all for gates). The CLI can start the same jobs against a running server.


Server jobs use the same engine as an in-tab run: prompts, converters, knots, iterators, tripwires, custom nodes, agents, sessions, frames, mute/bypass, retry and continue-on-error.

What changes when no human is present:

ThingIn-tab (gates / partial)Server job
Approval / live handoff / tripwire parkInteractive, with spliceNeeds approve-all; text is forwarded unchanged
Context nodesCan materialize during the runMust already have a payload
Closing the tabEnds an in-tab runNo effect
Reopen the workflowRe-attaches to running jobs; shows finished outputs from disk

A workflow containing gates refuses to start as a server job without approve-all. That’s deliberate: silently skipping a checkpoint you placed would be worse than failing.


  1. Keep threadle (the server) running.
  2. Press (or ).
  3. Close the browser if you like.
  4. Open the workflow again — mid-run statuses sync from the server; when the job finishes, outputs appear on the canvas.
  5. Or watch Runs / Logs without opening the graph.

Keep a server up in one terminal, then fire jobs from another:

Terminal window
# terminal A
threadle --no-open
# terminal B — free ~60s demo (no agents)
threadle run detached-delay --detach
threadle jobs
threadle attach <jobId>
# or several workflows in parallel
threadle run knot-concat --detach
threadle run hello-wire --detach
threadle jobs
threadle stop <jobId>
threadle services
Flag / commandEffect
threadle run … --detachPOST /api/run/workflow on the running server; print jobId and exit
threadle run … (no --detach)Foreground in-process run (streams to stdout; not a long-lived server job unless a server is already up and you use --detach)
threadle jobsList recent jobs (all statuses)
threadle status [--all]List running jobs (--all = same history as jobs)
threadle attach <jobId>Follow a job’s logs until it ends (same as logs -f)
threadle logs [jobId] [-f]Tail one job, or recent lines across jobs
threadle stop <jobId>Cancel a running job
threadle servicesHealth + process + providers (useful before a long unattended run)
--param k=vFill a workflow param (repeatable)
--approve-allAuto-pass gates and parked tripwires
--dir <path>Project directory for agent runs

THREADLE_URL overrides the server base (default http://127.0.0.1:<port>).

See the CLI reference for agents, sessions, graphs, models, nodes, and templates.


Starting several server jobs is how you run workflows in parallel. They share one Node process as async tasks; agent steps already spawn provider CLIs as child processes. Ply only caps concurrency inside one graph.

You do not need a worker-process pool for normal agent-bound or prompt/knot graphs.


  1. Set a model on every agent node — readiness blocks the run otherwise.
  2. Materialize context payloads you depend on, or replace them with library items.
  3. Decide about gates — keep them and pass approve-all / , or replace judgment points with tripwires that abort or skip.
  4. Set a spend ceiling in ≔ params. Unattended plus unbounded is the one combination worth avoiding.
  5. Check Loose ends — dangling branches cost tokens and produce nothing.

WhereWhat
Runs viewLive status, duration, errors, cancel
Run log / Logs viewThe streamed log
The graph (reopened)Node statuses and output contents while the job runs and after it finishes
threadle jobs / attach / logsSame job registry from a terminal