Skip to main content
Announcements

Cloud Agents SSE Initial Connection Behavior Change

The initial connection behavior of Cloud Agents SSE endpoints changes on August 24, 2026.

  • Announcement date: August 10, 2026
  • Effective time: August 24, 2026 at 00:00 (UTC+8)
  • Scope: Cloud Agents
Cloud Agents will change how SSE endpoints deliver events when a client establishes an initial connection.

What is changing

After the change takes effect, if a client establishes an SSE connection without a Last-Event-ID request header, the server starts at the tail of the event stream at connection time. It delivers only events created after the connection is established and no longer replays existing events from the Session or Thread. This change does not affect event data or event formats. Historical events remain available through the paginated List Events endpoints. Reconnection with Last-Event-ID is unchanged.

Why this is changing

Currently, a new connection without Last-Event-ID first receives a replay of all historical events and then receives new events. When a Session contains many events, each new connection repeatedly transfers data that the client may already have processed. Clients must parse and deduplicate that data and cannot easily distinguish replayed events from real-time events. After the change, each access pattern has a clearer responsibility: SSE delivers real-time events, List Events retrieves historical events, and Last-Event-ID locates the reconnection point. This eliminates redundant transfers.

Affected endpoints

Endpoint or capabilityChangedDetails
GET /api/v1/cloud/sessions/{session_id}/events/streamYesWithout Last-Event-ID, starts at the tail of the Session event stream at connection time and delivers only subsequent events
GET /api/v1/cloud/sessions/{session_id}/threads/{thread_id}/streamYesWithout Last-Event-ID, starts at the tail of the specified Thread event stream at connection time and delivers only subsequent events for that Thread
GET /api/v1/cloud/sessions/{session_id}/events and GET /api/v1/cloud/sessions/{session_id}/threads/{thread_id}/events with Accept: text/event-streamYesWhen used as SSE endpoints, behavior matches the corresponding stream endpoint
Reconnection with Last-Event-IDNoWith a valid Last-Event-ID, delivery continues after that event, as before
JSON queries to the two List Events endpoints aboveNoSaved public events remain available through pagination
POST /api/v1/cloud/sessions/{session_id}/eventsNoThe request and response contract is unchanged

Behavior example

Suppose a Session has four events before the connection is established and creates four more events afterward. Event IDs are shortened below. 
Events that exist before connection:
evt_00l82zhn…ls0e   session.status_running
evt_00l82zhmp…c9t4  user.message
evt_00l82zhoi…pskrt agent.message
evt_00l830291…ct2zo session.status_idle

Events created after connection:
evt_00l830465…7yh4u session.status_running
evt_00l83045n…jlw6i user.message
evt_00l83046h…r1c3b agent.message
evt_00l830yjc…k2tb  session.status_idle
Before the change, a connection without Last-Event-ID receives all eight events. After the change, it receives only the four events created after connection. The server does not replay any historical event, including the most recent one. When reconnecting with a valid Last-Event-ID, delivery still continues after that event. Existing connections are not affected. The new behavior applies only to connections established or re-established after the effective time.

Migration guidance

Update your client before the effective time if it does any of the following:
  • Opens a new SSE connection to retrieve historical events.
  • Sends a message or starts Agent execution before opening an SSE connection without a cursor, relying on history replay to receive those events.
  • Reconnects after an interruption without Last-Event-ID, relying on history replay to recover events created while disconnected.
Use the following integration pattern:
  1. Retrieve historical events through paginated List Events requests.
  2. Receive real-time events through SSE and record the latest event ID after processing succeeds.
  3. If the connection is interrupted, reconnect with that ID in the Last-Event-ID header and make event processing idempotent by event ID.
  4. To receive every real-time event produced by an operation, confirm that the SSE connection is established before starting the operation.
Clients that use SSE only for real-time events and do not rely on history replay require no changes.

Effective date

This change takes effect on August 24, 2026 at 00:00 (UTC+8) for Cloud Agents. Existing behavior remains unchanged until then. To assess the impact or request integration support, contact us at contact@qoder.com.
First steps
Define your agent
Configure agent environment
Delegate work to your agent
Agent integrations
Manage agent context
Account
Best Practices
Announcements
API reference
Cloud Agents SSE Initial Connection Behavior Change - Qoder