Managed Agents API requests require the
managed-agents-2026-04-01 beta header, except memory store endpoints, which use agent-memory-2026-07-22 instead. The SDK sets the correct beta header automatically. See Beta headers.Session statuses
Sessions progress through these statuses. See Start a session for the session lifecycle.Updating the agent configuration
You can update a session’sagent.tools and agent.mcp_servers, including permission policies, mid-session without creating a new agent version. Updates are session-local and do not propagate back to the underlying agent.
Only the agent’s tools and mcp_servers can change after a session is created. To run a session with model, system, or skills values other than the agent’s, use agent configuration overrides when you create the session. The agent’s model configuration, including its inference_geo pin, also can’t change mid-session: set the pin when you save the agent, or set or clear it for a single session with a model override when you create it. The agent’s configured system field is fixed for the session’s lifetime. On models that support it, you can still append system-level guidance mid-session by sending a system.message event.
The semantics of a tools or mcp_servers update are full replacement: the provided array is the new value. To preserve existing entries, GET the session, modify the array, and POST it back.
The session must be idle to update the agent. Interrupt the session if you need to update the agent while it’s running.
Updating the session budget
A session created with a budget accepts two kinds of budget update: replacing the cap with a newmax_list_cost, and removing it by setting budget to null. Both automatically resume work that paused when the session reached its cap. A replacement cap can be higher or lower than the current one, but it must be strictly greater than the session’s consumed list cost, and removal is one-way: a non-null budget is accepted only on a session that currently has one, so you can’t re-add a removed budget or add one to a session created without it. See Session budgets for request examples, the error behaviors, and what counts toward list cost.
Retrieving a session
Listing sessions
Results fromGET /v1/sessions are paginated. Use the limit query parameter to control the page size. Each response includes a next_page cursor; pass it as the page parameter on the next request to fetch the following page. next_page is null when there are no more results.
To go back a page, pass prev_page as the page parameter. prev_page is null when you’re on the first page.
A page cursor is opaque and encodes the order of the request that produced it. The order query parameter sets the sort direction of the results, asc or desc by creation time; the default is desc (newest first). Reusing a cursor with a different order returns a 400 error, as does changing a created_at filter so that it excludes the cursor’s position. Other query parameters, including the remaining filters and limit, can change between paginated requests. For the pagination fields shared across list endpoints, see Pagination.
Archiving a session
Archive a session to prevent new events from being sent while preserving its history. Arunning session cannot be archived; send an interrupt event if you need to archive it immediately.
Deleting a session
Delete a session to permanently remove its record, events, and associated sandbox. Arunning session cannot be deleted; send an interrupt event if you need to delete it immediately.
Memory stores, vaults, skills, environments, and agents are independent resources and are not affected by session deletion. Files you uploaded through the Files API are also unaffected, but files the session itself produced are scoped to it and are permanently deleted along with its filesystem. Download anything you need to keep before deleting the session.