Get session changes
Track progress
Get session changes
Long-poll for real-time session updates.
GET
Get session changes
Returns a stream of changes (events, status transitions, agent actions) that have occurred since your last request. Uses long polling: the server holds the connection open until new changes are available or the timeout expires.
Returns
Long-poll
200 with a TrajectoryChanges object, or 204 No Content if no new events arrive within the wait period.
changes is a delta: each call returns only what’s new since from_index and 204 when nothing new has arrived yet. status can read completed while events (including the answer) are still unread on later pages, so keep advancing from_index until the session is terminal and a poll returns no further events. To skip the loop entirely and just read a finished run’s result, use latest_answer. The SDK helper drains for you.Path parameters
The session ID.
Query parameters
Event index to start from. Use this to resume from where you left off.
Maximum number of events to return.
Whether to include event details in the response.
How long the server should hold the connection waiting for changes. Max: server-configured. Default:
0 (return immediately).Set to 20 to 25 for efficient long polling.Response
| Field | Type | Description |
|---|---|---|
status | string | Current session status. |
started_at | string | null | ISO 8601 timestamp when the agent started executing. |
finished_at | string | null | ISO 8601 timestamp when the session reached a terminal state. |
error | string | null | Error message if the session failed. |
answer | string | object | null | The agent’s final result once produced; null otherwise. A string by default, or an object matching the agent’s answer_format JSON Schema when one was set. It rides the page that delivers the final events, so keep polling until the session is terminal and drained. For a cursor-independent read, the same value is mirrored on the Session object’s latest_answer. |
metrics | object | Usage and cost rolled up to the moment of the response: steps, total_cost, input_cost, output_cost, and cost_per_model[]. |
new_events | array | Events since from_index, each following the event shape (type, data, timestamp). |
Examples
Long-polling pattern
Long polling is more efficient than repeated status checks because the server only responds when something actually changes. The SDK ships a helper that runs the loop for you: it drives termination offstatus (authoritative) while streaming events from changes, resuming from_index and handling the 204 no-change responses automatically.
Comparison: polling vs. long polling
| Approach | Endpoint | Latency | API calls |
|---|---|---|---|
| Status polling | GET /sessions/{id}/status every 3s | Up to 3s delay | ~20/min |
| Long polling | GET /sessions/{id}/changes?wait_for_seconds=25 | Near-instant | 2-3/min |
changes to follow a run: it returns new events and the final answer with near-instant latency and fewer calls. Reach for status only when you want a cheap, one-off liveness check.