Session spend

GET /v1/orgs/{orgId}/usage/sessions lists a Tenant's sessions with what each one spent on AI calls in a date range, so you can charge your customer per session or see which sessions cost the most. It sits next to Organisation usage and takes the same credentials: an owner's or admin's session, or an Organisation Key of this Organisation. A Tenant of another Organisation is 404 not_found.

The figures are what the Organisation is charged for these calls, not an estimate. They are not the Tenant's whole bill: see What is counted.

List a Tenant's session spend

curl -s "$SAI_API_URL/v1/orgs/$ORG_ID/usage/sessions?tenantId=$TENANT_ID&from=2026-10-01&to=2026-10-31&limit=50" \
  -H "Authorization: Bearer $SAI_ORG_KEY"

{
  "sessions": [
    {
      "sessionId": "cs_01HZY",
      "title": "Reconcile the October invoices",
      "costUsd": 0.4172,
      "modelCalls": 23,
      "firstDay": "2026-10-03",
      "lastDay": "2026-10-04"
    }
  ],
  "nextCursor": null,
  "dataThrough": "2026-10-28T09:45:00Z"
}

Sessions come in order of firstDay, oldest first. A session that spent nothing in the range is left out. Paging never returns a session twice. But a session that starts or resumes spending while you page may be missed by that pass and show up only when you page again. For a range wholly in the past, older than the lag, the results don't change.

A page can hold fewer sessions than limit, or none at all, and still have a nextCursor. Keep paging until nextCursor is null; an empty page is not the end.

Each Tenant can be read at most 1200 pages an hour, counted from its first page in the hour. Pages read with a member's session for the same Tenant count too. Past that, requests get 429 rate_limited until the hour is up.

{ "error": "invalid_request", "message": "from and to are at most 93 days apart, inclusive" }

What is counted

A session's spend is its AI calls: the model calls Sai makes to do the task, choosing a model when the session uses auto, locating elements on the screen, and the calls Sai makes after a task finishes, to fill in output_schema and check success_criteria.

• Only AI calls. Computer time, residential proxy traffic and storage are not split by session. Read them per Tenant from Organisation usage.
• The sessions don't add up to the Tenant's bill. Adding up every session's costUsd can come to less than what the Tenant cost. Besides computer time, proxy traffic and storage, it leaves out AI calls that don't belong to a chat session, such as writing or repairing learned code, and the spend of sessions that were deleted. For the Tenant's own spend, see its entry under byTenant in Organisation usage.
• Spend from before this endpoint shipped is not counted. Sessions that ran before then read low or are missing.
• Locating elements on the screen is counted once the machine's Sai runtime is updated, where that work runs on the machine. Until then, those calls are missing from the sessions that ran on it.

When the figures are final

• Days are UTC. A session that runs across the edge of your range counts only the days inside it.
• The figures lag, usually by 15 to 20 minutes, and longer when a backlog builds. The most recent day reads low until they catch up; dataThrough says how far they go.
• A running session's figures change each time you ask.
• The calls after a task finishes are charged a little after the task ends, so a session can still go up for a few minutes after it goes idle.

Compared with sessionUsage on /events

sessionUsage on GET /v1/agents/events is a live count while you watch a task. It covers only the model calls Sai makes to do the task, not choosing a model, locating elements or the calls Sai makes after a task finishes, to fill in output_schema and check success_criteria. Its costUsd is also rounded to cents and this endpoint's is not, so the two won't match exactly. Use this endpoint for what a session cost.