Skip to main content
The agent-worker API is internal — runners call it, not user applications. The endpoints below apply to inbound server mode. In outbound client mode, the worker binds no port and calls the runner instead.

Transport Modes

Inbound server mode remains the default. When both ORCA_RUNNER_URL and ORCA_WORKER_TOKEN are set, the same process switches to a session-scoped outbound client. ORCA_SESSION_ID is then required. The outbound client uses three runner endpoints, all authenticated with Authorization: Bearer <ORCA_WORKER_TOKEN>: The worker sends X-Orca-Worker-Protocol: 1 when polling. It writes state to ORCA_STATE_DIR after each run and on export_state, uploads a durable copy to the runner, and restores the disk copy before its first poll. These state operations are best-effort so a corrupt or unavailable bundle does not prevent the worker from calling home.

Base URL

In inbound server mode, sidecars run on configurable ports (default 7070). In a typical setup:

Health Check

GET /health

Returns sidecar health, the active runtime mode, and the identity and self-reported footprint of this worker process. /healthz returns the same body.
The response also includes the X-Orca-Worker-Instance header. The ID is generated once per process and changes when the process restarts. POST /run responses include the same X-Orca-Worker-Instance header and an X-Orca-Worker-Inflight header containing the process’s in-flight run count at the start of the response. The runner uses the identity header for passive instance observation, while it obtains memory and CPU details from /health probes.

Run Execution

POST /run

Executes a task against the configured LLM provider. Returns a streaming NDJSON response of RunEvent objects. Request body:
Request fields: Response: application/x-ndjson (streaming) If run dispatch fails after the streaming response has started, the sidecar writes a terminal error event and closes the stream; the process remains available for subsequent runs. Each line is a RunEvent JSON object:

RunEvent Schema


Session State

GET /state/:sessionId

Exports an opaque state bundle for one sidecar session. Runners use this internal route when they need to persist runtime-local conversation state outside the sidecar process.
When MODE=all, pass the runtime explicitly:
Response headers: Returns 400 for malformed percent-encoding in sessionId or, in MODE=all, a missing or unknown runtime query parameter. Returns 404 when the sidecar has no exportable state for the session. Codex exports include only rollout files whose filename contains the exact requested thread ID at ID-token boundaries; a thread ID like thread-1 does not also export thread-12.

POST /state/:sessionId

Hydrates a sidecar session from a previously exported state bundle. The request body is treated as the exported body for that runtime: JSON for general, gzip state bundles for claude and codex.
When MODE=all, pass the runtime query parameter. On success, the sidecar returns 204 No Content; the next POST /run for that session can resume from the hydrated state. Client-caused import failures, such as invalid JSON or corrupt gzip/tar data, return 400 and do not seed X-Runtime-Session-Id for the session. Unexpected dispatcher failures return 500; the sidecar contains the error and continues serving subsequent requests.

Mode Configuration

The sidecar’s behavior is controlled by the MODE environment variable:
Uses @anthropic-ai/claude-agent-sdk.
Model format: claude-sonnet-4-6, claude-haiku-4-5Host-executing Claude built-ins are disabled by default. Use runner MCP tools for filesystem, sandbox, and skill-script execution.

Environment Variables


MCP Bridge (general mode)

In general mode, the sidecar connects an MCP client to the runner’s session MCP endpoint: The sidecar also opens any external MCP servers from the profile and merges them with the runner platform tools. External tool names are prefixed separately from runner tool names. When a connected MCP catalog is large enough for deferred loading, general mode exposes search_tools and call_tool meta-tools instead of sending every underlying tool schema to the model on each turn. The deferred catalog stores plain JSON schemas only; Vercel AI SDK schema wrappers are unwrapped before search results are returned, and degenerate wrappers with no usable JSON schema fall back to {} so replayed history does not contain Symbol-keyed or function-valued schema metadata. The general mode sidecar keeps bounded in-memory session history for replay. If the upstream model stream errors after a turn has started, the sidecar commits the user prompt and any accumulated assistant/tool context once before emitting the terminal error event, so the next turn can replay the prior context. Replay also repairs malformed or partial tool-result history before handing messages back to the AI SDK, including defensive JSON sanitization that drops function-valued properties and replaces circular references with "[circular]".

Custom Sidecar

You can implement a custom sidecar that conforms to this API. Requirements:
  1. GET /health{ ok: true, runtime: string }
  2. POST /run → accepts the run envelope body, responds with NDJSON RunEvent stream
  3. Must stream events as newline-delimited JSON
  4. Must emit a result or error event to signal completion
  5. For resumable sessions, implement GET /state/:sessionId and POST /state/:sessionId with opaque state-bundle bytes
This lets you integrate any LLM provider or custom inference engine with Orca’s orchestration layer.