Skip to main content
Every model call a session makes is recorded in a cost ledger with its exact cost in US dollars. Use these reads to see what one session cost, how cost splits across its subagents, and what a batch of sessions cost, and to tell a final figure from one that is still settling. The TypeScript samples assume the rl client from Client setup.

Before you begin

  • Any organization role that can read sessions can read their cost: user, developer, or admin. The billing role cannot see sessions. See Organizations and roles and API keys.
  • These figures report what model and tool use cost, for tracking and comparison. Credits are bought separately on the Billing screen; see Billing.

Choose a read

What the cost covers

Model cost covers:
  • Model calls: every inference call made by the agent, its subagents and teammates, and grading passes.
  • Provider-side tools: metered tools that run with the model call, such as a provider’s web search.
Sandbox compute is not part of these reads.

How cost rolls up

Sessions form a tree. A root session can delegate to subagents, run teammates, and start grading passes, and each of those is a child session with its own cost. Every cost read lets you pick a scope. For a root session, subtree and tree are the same, and that total is what the whole run cost.

Read one session’s cost

getSessionModelCosts returns a summary for the scope you ask for, the self, subtree, and tree summaries side by side, and the individual calls (attempts) in that scope, oldest first.
  1. On the Sessions tab, open the session.
  2. Click Model cost in the session header.
  3. Pick a scope: This session, Session and descendants, or Whole session tree.
  4. Read the total, then the Model cost by session and Model cost attempts sections for the breakdown.
Some fields are omitted from this response.
Each attempt is one call. session_path places it in the tree (/ is the root). state is prepared or dispatched while the call is in flight, charged once its cost is recorded, not_charged when the call produced no charge, and indeterminate when it may have incurred a cost but no usable receipt came back. Each attempt shows its cost amounts; token counts and prices are withheld.

Page through a consistent snapshot

The first page returns a model_cost_snapshot_token and a read_timestamp. Every later page read with its next_page_token sees the ledger exactly as it was at that moment, so pages never skip or repeat attempts while the session keeps running and the totals match the attempts you paged through.
  • Page tokens only work with the same session, scope, limit, and snapshot that produced them.
  • A snapshot token only works with the same session and scope.
  • Snapshots are kept for 24 hours. After that, start again without a token.

Find which session spent the most

listSessionModelCostNodes returns one entry per session in the scope, ordered by session_path, each with its self, subtree, and tree totals. Send scope=tree to list every session in the tree; the default, self, returns only the session you name. It takes the same limit, page_token, and model_cost_snapshot_token parameters. Pass the snapshot token from a getSessionModelCosts response to read both at the same moment.

Compare many sessions

Both batch reads take session_ids, a comma-separated list of up to 1000 ids.
  • listSessionModelCosts returns session_model_costs: one entry per id, in request order, repeated if an id is repeated, each with self, subtree, and tree totals. If any id is unknown or outside your access, the whole request returns 404.
  • listSessionUsage returns session_usage: event count, token counts, and cost_micros (cost in millionths of a US dollar) for each session’s own events. Children are not included. Unknown ids and sessions with no events are left out, so compare the number of rows with the number of ids you sent.
Use listSessionModelCosts for amounts you reconcile, because it covers child sessions and reports completeness. Use listSessionUsage for token counts.

Know when a figure is final

Every summary and attempt has a completeness. A summary reports the weakest state in its scope, so it never claims more certainty than its least certain call. A total can change in three ways:
  1. The session is still running. New calls add to the total. Once the session has stopped, no new calls arrive unless you resume it.
  2. Calls are still settling. pending becomes charged or not_charged.
  3. A charge is corrected. Charges are never edited. A correction is added as an adjustment, so model_cost_usd is the current amount and original_model_cost_usd is the amount first recorded. adjustment_count tells you whether any correction applies in scope.
Treat a figure as settled when the session has stopped and completeness is complete, and record the read_timestamp next to it.

Amount format

  • All amounts are in US dollars. No other currency is used.
  • model_cost_usd and every other _usd field is an exact decimal string with up to nine decimal places and no trailing zeros, such as "0.18472". A zero amount is "0".
  • attempt_count, charge_count, and adjustment_count are integer strings.
  • cost_micros in usage rows and grading passes is an integer in millionths of a dollar.
Add amounts with a decimal type, such as Decimal in Python or a decimal library in TypeScript. Floating-point sums drift.

Organization analytics

To see cost, tokens, and tool calls across your whole organization over time, broken down by agent, model, and tool, use Analytics. To total a specific set of sessions, use the batch reads in Compare many sessions.

What can go wrong

The full list of codes is in Errors.

Limits

Every other limit is on Limits.

Next steps

Teams

See why a team costs more than one agent.

Outcomes

Read what each grading pass cost.

Multi-agent

Understand the session trees behind cost rollups.

Limits

Check quotas and request limits.