-
Notifications
You must be signed in to change notification settings - Fork 106
Description
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 /messagesreturns aMessagesResponseBodycontaining the fullmessagesarray with no filtering or pagination parameters.- Each
Messagehas a sequentialidfield (integer) that represents the order in the conversation history. GET /eventsreplays all messages asmessage_updateevents 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 /messagesto filter by messageid(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