Problem
The GET /messages endpoint currently returns all messages in the conversation history with no pagination support. For clients that need to poll for updates periodically (e.g. the VS Code extension fetching logs), this means pulling the entire message history on every request, which becomes increasingly expensive as conversations grow.
The same applies to the GET /events SSE endpoint, which replays all current state (all messages, status, and screen) on each new subscription.
Current behavior
GET /messages returns a MessagesResponseBody containing the full messages array with no filtering or pagination parameters.
- Each
Message has a sequential id field (integer) that represents the order in the conversation history.
GET /events replays all messages as message_update events on subscription, followed by current status and screen state.
Desired behavior
Support for fetching only new or updated messages since a given point, so that clients polling periodically don't need to re-fetch the entire history each time.
Some possible approaches (not exhaustive):
- Query parameter on
GET /messages to filter by message id (e.g. ?after=<id> to get messages after a given ID)
- Cursor-based pagination
- Limit/offset pagination
Use case
The VS Code extension will be fetching conversation logs periodically. Without pagination, every poll retrieves the full message history, which is wasteful in terms of bandwidth and processing — especially for long-running agent sessions with many messages.
Created on behalf of @mafredri