Three channels
All three use the same authentication flow: mint a short-lived token via REST, then pass it as a query parameter when opening the WebSocket.
Token exchange
WebSockets cannot send custom HTTP headers in the browser, so Runtime uses a token exchange pattern:- Call
POST /api/sessions/{id}/ws-tokenwith your API key and the capability you need - Receive a short-lived, single-purpose token
- Open the WebSocket with
?token=...immediately - If the token expires before you connect, mint a new one
Terminal WebSocket
The terminal channel gives you an interactive shell inside a running session. It is the same PTY the dashboard renders. Protocol:- Binary frames carry raw stdin (client to server) and stdout/stderr (server to client)
- JSON text frames carry control messages:
resize(update terminal dimensions),ping/pong(keepalive),settings(terminal configuration)
Prompt WebSocket
The prompt channel lets you send a prompt and receive structured agent events as the agent works. Each WebSocket connection handles exactly one prompt. Client sends:accepted- prompt was received and the agent is starting- Agent events - tool calls, file edits, terminal commands, thinking
done- agent finished, with a summary of changeserror- something went wrong
Collaboration WebSocket
The collaboration channel is read-only. It streams events about what is happening in a session:presence- who is currently viewing the sessionprompt_started/prompt_completed- a user started or finished a promptvisibility_changed- the session’s visibility was updated
sessions:read scope, making it safe for monitoring dashboards.
See Collaboration WebSocket for the event reference.
When to use REST vs WebSocket
The REST prompt endpoint is simpler but blocks until the agent is done. The WebSocket prompt endpoint gives you streaming events and is better for interactive UIs.
Related guides
Stream prompts over WebSockets
Token exchange, event types, and reconnection patterns.
Handle long-running prompts
REST vs WebSocket, cancel, rewind, and history replay.