What is a Run?
A Run is a single task submitted to an agent. Each run:
- Targets a named Profile (the agent’s definition)
- Carries a SubTask (the work to do)
- Produces a stream of RunEvents (progress, tool calls, responses)
- Is assigned a unique
runId and a sessionId
Multiple runs can share a session, but only one run executes per session at a time.
Submitting a Run
Response 202 Accepted:
SubTask Schema
This is the shape of the payload accepted by POST /api/runs. Not every field is client-facing: pool names the workflow a run was launched from, automationId and automationAgentFor are set when a run is started by, or is itself, an automation agent (validated server-side against the caller’s own automations), automationName is a denormalized automation name for display, and contexts names context documents to seed a new session with.
Streaming Events (SSE)
Once you have a runId, open an SSE stream:
The conductor streams RunEvent objects as Server-Sent Events. Events are replayed for late subscribers (the conductor buffers the run’s event log).
RunEvent Types
Every event in the stream is a JSON object with a type field. The types below are the common ones; the list is not exhaustive and may grow.
progress
Lifecycle milestones emitted by the runner and conductor.
session_init
Runtime-native conversation handle emitted once per run when the sidecar reports it.
The conductor preserves it as runtimeSessionId; UIs can ignore this event unless they need to correlate an Orca session with a Claude SDK session_id or Codex thread_id.
assistant
A text response from the LLM.
The agent is invoking a tool.
The result of a tool invocation.
usage
Token usage reported by the LLM provider.
result
The final answer produced by the agent. Signals that the run is complete.
error
An unrecoverable error during the run.
thinking
Provider-exposed reasoning text or summaries, when the underlying model returns any. Providers do not expose private chain of thought; this is only the display-safe content their SDKs return.
capability_span
A bounded, redacted event describing one stage of a capability action, emitted while the agent works through a capability challenge (see POST /api/capabilities/discover and the related capabilities endpoints).
capability_decision
The durable, terminal human decision for one capability challenge and operation.
capability_context_savings
An estimated, non-provider usage comparison for a capability action.
Complete Event Sequence
A typical run produces events in this order:
Consuming Events in TypeScript
Run Persistence
Runs are stored in an append-only JSONL log when AGENT_ORC_RUNS_DIR is set on the conductor:
Each run gets one <runId>.jsonl file containing a header, event lines, and a finish line. Conductor replays these files on restart to reconstruct the in-memory run registry.
Without AGENT_ORC_RUNS_DIR, runs are in-memory only and lost on conductor restart.
Listing & Inspecting Runs
The GET /api/runs/{id} response includes the full event log for completed runs.
Run Status
Stopping a Run
Use DELETE /api/runs/{runId} for normal, cooperative cancellation. It cancels the run context, aborts the runner stream and sidecar turn, and returns 204 No Content.
If the run remains stuck, use POST /api/runs/{runId}/terminate as a last resort. Termination independently attempts to cancel any in-process run, waits up to two seconds for the session’s run claim to drain normally, then steals the claim only if it remains held. It also marks the durable run row as cancelled; a late completion cannot overwrite that status. The response reports which steps succeeded:
Termination is idempotent and still attempts the durable status and session-release steps when the run is no longer in the current conductor’s in-memory registry. claimStolen: true identifies a claim that did not drain and had to be forcibly taken. Any warnings are stable codes rather than internal error details.Last modified on September 6, 2026