Usage and spend

Every model call goes through the tenant’s LLM gateway, which meters it against the run that made it. Usage therefore rolls up from runs to sessions, agents, and the principals who started them, and a session can carry a budget that bounds it.

Availability: Metering and budgets are enabled per tenant; a session shows usage as not measured where they are off. See What is available where.

At a glance

• Usage is recorded per run: input tokens, output tokens, and the model.
• The Console’s session view shows usage by run and, where a budget governs the session, the cap, what is reserved, what has settled, and what remains.
• A run that would exceed the session’s budget is refused before it starts, not cut off midway.

Read usage

Open a session in the Console and choose the tokens panel. It shows totals for the session and a breakdown by run, split into input and output. The same numbers are attributed in the execution trace’s model-call spans, so an evaluation experiment can report cost beside quality.

Budgets

Where a session budget is set, the panel shows:

Figure	Meaning
Cap	The session’s budget
Reserved	Usage held for a run that is still executing
Settled	Usage recorded for completed runs
Available	Cap minus reserved minus settled

A run is admitted only if its reservation fits. “No budget governs this session” means the session has no cap, and usage is metered but unbounded.

Where spend is decided

Spend is a consequence of three declarations you already control: the models in permitted_models, the tools the agent may call, and how long sessions live. A cheaper model in the allowlist that your application selects for routine requests is the largest lever. See Choose models.

Where to go next

• Sessions and runs
• Evaluate a version: cost beside quality for a candidate.