Skip to main content
Every list method answers the same envelope, parsed with page(...) from the core schemas:
​
T[]
One page of full objects, newest first.
​
boolean
Whether another page exists after this one.
​
string | null
Opaque cursor for the next page; null on the last page.

​
The ListQuery type

​
number
Page size. Server-side default and cap apply — see Pagination.
​
string
The next_cursor from the previous page. Exclusive.
| undefined is explicit on both so a caller can forward an unset CLI flag without a spread dance.

​
Walking all pages

There is no auto-paging iterator. list returns one page and the cursor; the loop is yours:
That is a decision, not a gap: an auto-pager hides the request count, and the two real consumers (the CLI and the dashboard) both want the page boundary visible.

​
Filters ride the same query

List methods with filters extend ListQuery rather than replacing it, so limit/after always work:
  • sessions.list({ agent_id, status, stop_reason, deployment_id, parent_session_id, limit, after })
  • files.list({ scope, session_id, limit, after })
  • credits.ledger({ type, session_id, agent_id, deployment_id, from, to, limit, after })
  • auditLogs.list({ actor, resource, action, from, to, limit, after })
One exception of note: skills.listVersions pages on the version number, not an id — versions have no id of their own.