License and Usage

Open Governance → License for the company license, validity period and human seats, and Usage for inference accounting and limits. This page is for Owners, Admins and License Admins; everyone else should start with Usage.

License

Companies import an offline signed license for one Organization, with a fixed term and human-seat allowance. Every active human member and valid invitation reservation counts. A seven-day grace period follows expiry; then new agent work is blocked while administration, history/export and renewal remain accessible. The license covers My workspace and Team workspaces. See Seats and licensing for what consumes a seat.

Owners, Admins and License Admins import signed replacements in Governance → License. Every active member can view basic license status.

Usage reports are independent of the license. Customer-set token and USD limits, runtime safeguards, manual/security pauses and emergency controls remain authoritative.

Inspect usage

Choose a usage period, custom dates or a recent period. Monthly periods retain the Organization's existing cycle anchor; license renewal does not reset them. Daily token/USD limits reset at midnight in the limit's configured timezone. Filter by Team, owner, agent, configured provider/model or purpose. Requests, input/output, cache and reasoning measurements come from provider counters when available. Known subtotals include missing-measurement counts. Expand a request to inspect model provenance, rate basis, warnings and available run evidence. Agent moves do not reassign historical consumption.

A configured model and a provider-returned model can differ because of deployment aliases or fallbacks. Provider-returned identities are observations, not independent proof of the physical model a gateway executed.

Configure inference rates

Rates exist so your organization can estimate what its own model usage costs. They are for monitoring only. They are not a bill from Decision Terrain, and the company license is separate. Organization Owners, Admins and License Admins can save customer USD rates per million input/output tokens and applicable cache rates in Usage. Staff manage installation overrides. An optional pricing-model mapping resolves deployment aliases. Saving creates a revision for future dispatches; historical estimates preserve their original rates. Blank cache rates leave requests using those buckets unpriced. Explicit zero means a free bucket.

Customer rates take precedence over resolvable default prices. Default public-price estimates may be stale and exclude negotiated terms, capacity commitments and discounts. Provider-reported monetary amounts are separate from customer estimates. Missing rates, missing measurements and unsupported non-token calculators can leave cost unavailable. No estimate reconciles provider invoices.

Usage limits

A usage limit is an optional ceiling, in tokens or in US dollars, for the whole Organization, one Team, or one agent, per day or per month. A separate optional per-cycle ceiling caps the tokens one agent processing cycle may use. When an agent's hard limit is reached it stops starting new model requests and shows Usage limit reached until the window resets or an administrator raises or removes the limit. Requests already running finish, and messages and triggers sent meanwhile are kept and processed when the agent resumes. A limit bounds overshoot to the estimate error plus requests in flight at the boundary; it is not an exact cutoff.

Usage limits must be enabled on your deployment. If they are not, the Usage limits panel says so, nothing is enforced, and you can still raise or remove limits that exist but cannot create or lower one. Your installation operator enables them with USAGE_LIMITS_ENABLED.

Who can see and change limits

Owners, Admins and License Admins can view and change limits. Security Admins and Auditors can view them. Other roles, including Agent Admin, see neither the panel nor the agent Usage limit section; they only see the Usage limit reached status on an agent and when it resets.

Set a limit

1. Open Usage and find Usage limits at the top of the page.
2. Choose Add limit. Pick what it Applies to (Organization, Team or Agent), then the Team or agent, and the Window: Daily, Monthly or Per cycle (see below).
3. Choose what it is Measured in (Tokens or US dollars), then enter the Hard limit. Token limits take plain numbers and suffixes (250000, 250k, 2.5M); dollar limits take amounts such as 250 or 1,250.50. A Team or agent limit cannot exceed the Organization or Team limit above it in the same window; the form shows that cap and the saved message names it if you exceed it.
4. Set the Soft threshold (%). It marks the limit as approaching and emails Owners, Admins and License Admins once per window; work continues.
5. For a daily limit, set the Timezone as an IANA name such as America/Chicago. The day rolls over at midnight in that zone. The default is UTC. Monthly limits follow the Organization's monthly usage cycle and ignore the timezone.
6. Choose Add limit. Use Edit on a limit to change its values and Remove to delete it after confirming.

You can also set one agent's daily, monthly and per-cycle limits, in tokens or dollars, from the agent's settings, under Usage limit, with the same rules. The section is read-only for roles that can view but not change limits.

Dollar limits and fallback rates

A dollar limit counts each request at the cost the request ledger priced it from your customer rates or the default public pricing. A route with no resolvable rate (a private endpoint, an alias, tiered pricing) is counted at the Organization fallback rates instead: US dollars per million input and output tokens that an Owner, Admin or License Admin sets under Fallback rates for dollar limits. Those amounts are labeled estimates: the request ledger keeps showing the request as unpriced, and nothing here is an invoice or a provider amount.

You cannot create a dollar limit while an active endpoint has no resolvable rate and no fallback rate is set. The error lists the endpoints. Rates you remove later cannot leave a dollar limit unable to price its routes: removal is refused while one depends on them. If a route becomes unpriceable after a limit exists, its requests still run and are shown as not counted; set a fallback rate to count them.

Each dollar limit shows what is counted toward the limit, the part of it priced at the fallback rate, the part kept as an estimate for requests with unknown token counts, the requests not counted, and separately what the providers themselves reported for the window. Provider-reported amounts are never counted toward the limit. Embeddings, dedicated image and avatar calls count toward a dollar limit only when the ledger priced them, after they have run; they cannot be refused, and unpriced ones are not counted. A per-cycle ceiling is always in tokens.

Email alerts

When a limit reaches its soft threshold, and again when it reaches its hard limit, the platform emails every active Owner, Admin and License Admin who has a verified address. Each threshold is sent once per window. The message is deliberately generic: it says a limit was reached and links to Usage, and it names no agent, Team or figure. Each limit shows the delivery state of its alerts: waiting to send, sent to a number of recipients, not confirmed by the mail provider (it is not resent, so a message may or may not have arrived), or failed with the reason, such as no recipient with a verified address. A limit that is raised after its threshold was reached does not send that threshold again in the same window.

Per-cycle ceiling

A Per cycle limit caps the model tokens one agent may use in a single processing cycle. When a cycle reaches the ceiling the agent ends it before its next model request and continues in a new cycle shortly after. A request already running finishes, so a cycle can pass the ceiling by one step, and a response that reports no token counts is not counted. The ceiling does not park the agent, does not send an alert, and applies from the next cycle after you set or change it. It can be set at the same scopes and cannot exceed the ceiling above it. It is off unless you set one. To bound total spend, use the daily and monthly limits as well.

Each limit shows the tokens counted toward it, the share used, the soft threshold, the headroom held for requests still running, the Next reset in your own timezone, and its state: Within limit, Soft threshold reached or Hard limit reached. "Counted toward the limit" is settled usage plus the estimate held for running requests, so it can differ from the request totals lower on the page. Requests whose token counts were unavailable or interrupted are counted at an estimate and labeled as estimated, never as zero. Requests recorded before the limit was set whose counts were unknown are not part of the count, and the limit says how many there were. If the headroom left is smaller than the request an agent was refused, the limit says so: the hard limit is smaller than one request and must be raised.

Resume a parked agent

Agents parked by a limit are listed under Usage limit reached with the limit that parked them and when it resets. Use Raise limit to resume to open that limit for editing, or Remove limit to resume to delete it. An agent resumes once its next request fits under the new value. Raising a limit to a value still at or below the counted usage leaves the agents parked, and the form says so. A security hold or emergency stop always takes precedence: a held agent shows Security hold and never shows Usage limit reached, and releasing the hold does not bypass the limit.

What a limit does not cover

The panel lists the purposes outside a token limit: embeddings, dedicated image generation and avatar generation (a dollar limit counts these only when priced, after the fact). It also does not see retries inside a remote gateway, evaluation traffic, or security-evaluator checks. A dollar limit is an estimate and a bounded-overshoot control, not an exact cutoff or a bill.