Get session changes
Lifecycle
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
Use status polling for simplicity. Use long polling when you need real-time updates or want to minimize API calls.
200 with a TrajectoryChanges object, or 204 No Content if no new events arrive within the wait period.
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–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 request’s answer_format JSON Schema when one was set. This is the canonical place to read the output; it is not returned on the Session object. |
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 |