Skip to content

Understand Usage and Limits

Purpose

Understand why a key or deployment is admitted or denied and how its usage is counted.

Prerequisites

Use usage.read for Team financial summaries and budgets.read for budget details. Key managers can inspect/edit supported key-local caps without receiving ancestor budget details.

Procedure

  1. Open the selected Team's Usage, follow Recorded spend from Overview, or open a virtual key's detail to inspect known/estimated/unknown spending and reservations. Overview links retain the exact Team scope and half-open [from, to) UTC epoch-millisecond bounds. Recorded spend uses non-cancelled physical attempts by creation time and payer Team; unknown-cost attempts make it incomplete.
  2. Open Manage → Budgets if permitted. Distinguish an allocated ceiling from an operating cap. Every applicable Organization, Team, owner, key and customer limit must allow work.
  3. For generation under finite spending caps, set an explicit supported output bound, such as max_completion_tokens: 128 in Chat Completions. Unknown or unbounded priced liability can fail before provider I/O.
  4. Reduce request output/concurrency or ask the appropriate administrator to change a cap. Retry only after reconciling any uncertain earlier work.

Expected result

Each physical attempt is settled once. Shared governing meters do not multiply the invoice amount. A wrapper adds no duplicate spend. Active work renews an existing lease without another request count or spend admission. Unknown termination keeps its debit and capacity until confirmation or lease recovery.

Historical reporting and current constraints have different windows. Overview's budget attention shows finite caps that are blocked or at least 80% used within each cap's own current window. Constraint balances use current constraint windows even when you select a 24-hour, 7-day or 30-day report. With Organization-scoped budgets.read, applicable Organization constraints remain visible when a Team is selected. A missing budgets.read permission does not block an independently authorized usage.read panel. No matching attempts is an empty state, and an unknown amount is never treated as zero.

Verification

Compare an allowed bounded request with one that exceeds a key-local cap. The latter fails safely without disclosing a hidden parent ceiling. Rotation leaves usage intact; changing a cap does not erase already recorded facts.

Failure recovery

Zero is a hard stop; null removes that one cap while parent limits still apply. A Session label is grouping, not a new budget pool. Do not create a fresh key to evade a Team or owner ceiling. Reconcile unknown work before repeating a paid operation.