Appearance
Usage & Data Governance
Agentfleet lets a tenant control how much its agents spend on models, how long conversation data is kept, and which data each model may receive. Spend, budgets and chat retention are managed on the Usage page (/usage). Sensitivity labels and purpose requirements are set through the API.
Usage limits
A usage limit caps model usage at one of five scopes:
| Scope | Governs | Target |
|---|---|---|
Tenant | Every model call the tenant makes. | None |
Workflow | Calls made by runs of one workflow. | The workflow |
Model | Calls to one provider and model, from anywhere. | Provider and model |
User | Calls one user makes, in runs and chats. | The user |
AssistantProfile | Calls made by the chats on one assistant profile. | The profile |
A tenant has at most one limit per target. A limit sets any of these:
- Requests per minute and tokens per minute. These pace calls: a call waits for capacity and is never refused because of rate. Tokens are estimated before the call, so the token rate is approximate. Pacing is per API instance, so with N instances the effective rate can be up to N times the limit.
- Monthly budget (an amount and an ISO currency, default
USD). This is a hard stop that resets at the start of each calendar month (UTC).- Notify at % (1–99, default 80) raises a soft alert the first time spend reaches that share of the budget in a month.
- When spent, new runs are either refused (
Refuse: the run fails with the budget as its reason) or deferred (Defer: the run stays queued and is checked again hourly, or at the start of next month if that comes sooner).
Every limit a call falls under applies, so the strictest one wins. A call in a run of workflow W by user U to model M is checked against the tenant limit and the limits for W, U and M. A call in a chat on profile P is checked against the tenant limit and the limits for P, U and M. A workflow limit never applies to a chat, and a profile limit never applies to a run.
Where budgets are checked
| When | Budgets checked | When spent |
|---|---|---|
| A run starts | Tenant, the run's workflow, the user who launched it | Refuse fails the run; Defer keeps it queued |
| A chat message is sent, or a paused chat tool call is approved or rejected | Tenant, the sender, the thread's profile | 403 UsageLimit.BudgetExhausted, whatever the over-budget action |
| Every model call | Tenant, the model, the current user, the run's workflow or the chat's profile | The call fails with UsageLimit.BudgetExhausted, which fails the step or the turn |
A chat message cannot wait, so Defer never applies to it. When a refused message is answered, no turn is stored, no model is called, and a streamed request gets the problem response instead of a stream. The problem title names the budget that is spent. Model budgets are not checked when a run starts, because a run may call several models. They are checked when the run calls a model.
Spend is cached for about 30 seconds, so a budget can be overshot by that much traffic plus calls already in flight.
Budget alerts
A background sweep (every UsageGovernance:BudgetAlertIntervalMinutes, default 5) records a Budget alert activity the first time in a month that a limit crosses its soft threshold, and again when the budget is spent. Set UsageGovernance:BudgetAlertsEnabled to false to turn the sweep off.
Provider back-off
Apart from tenant limits, every model call respects the rate-limit headers the provider sends back (Retry-After, and OpenAI- and Anthropic-style remaining/reset headers). When a provider signals a limit, calls to it from that instance back off, for at most two minutes.
How spend is measured
Spend is the sum of the estimated cost of this month's model calls, taken from each call's pricing snapshot. Only calls priced in the limit's currency count. Calls on unpriced models cost nothing and are shown as unpriced calls.
A user's spend includes their runs and their chats. A profile's spend is the calls of its chats. A run that a chat launched keeps its own cost: that cost counts for the run's workflow and user, never for the profile.
The Usage page
- Limits lists each limit with its target and rates, and this month's spend against its budget, with a Within budget, Near limit or Spent badge and what happens when it is spent. Managers can add, change and remove limits.
- Chat retention shows the tenant's retention settings and lets managers change them (see below).
- History shows the tenant, or one workflow, over the last 24 hours (by hour) or the last 7, 30 or 90 days (by day). It has totals, a bar chart (or table) of cost, tokens or calls per period, and a per-model breakdown.
| Endpoint | Permission |
|---|---|
GET /api/usage/limits | view-usage |
POST / PUT /api/usage/limits, DELETE /api/usage/limits/{id} | manage-usage-limits |
GET /api/usage/history?from&to&granularity=Hour|Day&workflowId | view-usage |
GET /api/usage/thread-retention | view-usage |
PUT /api/usage/thread-retention | manage-usage-limits |
History covers at most 14 days by hour or 400 days by day. view-usage is in viewer, and manage-usage-limits is in identity-admin, model-provider-admin and admin.
Chat retention and purge
Deleting a chat is a soft delete: it disappears for its owner at once. Each tenant sets two periods, each 1–3650 days:
| Setting | Default | Effect |
|---|---|---|
retentionDays | 90 (Threads:DefaultRetentionDays) | After this many days, a deleted chat is permanently removed with its turns, model and tool calls, confirmations and search data. Runs it launched are not touched. |
idlePurgeDays | 30 (Threads:DefaultIdlePurgeDays) | The search data (result embeddings) of a chat with no activity for this long is cleared. The chat itself stays. |
Archiving or deleting a chat clears its search data immediately. A background sweep applies both periods every Threads:RetentionSweepIntervalMinutes (60), in batches of Threads:RetentionSweepBatchSize (100). Set Threads:RetentionSweepEnabled to false to turn it off. Activity feed entries are kept.
LLM data governance
Sensitivity labels and model allowlists. A resource can carry sensitivity labels describing what its tools return, such as pii or eu-only (up to 20 lowercase labels). Each model of a provider has an allowlist of the labels it may receive. The allowlist is empty by default, which admits only unlabelled data. A model may be offered a tool only when its allowlist covers every label on the tool's resource. If the model or provider cannot be found, the check fails closed.
The rule is checked when a step's model override is saved, when a run is launched (including scheduled runs), and again before every model call, in runs and in chat turns alike. A violation fails with SensitivityLabel.ModelNotAllowed, naming the model and the missing labels. Changing a label does not re-check saved configuration; it takes effect the next time a run launches or a model is called.
| Endpoint | Permission |
|---|---|
PUT /api/resources/sensitivity-labels { resourceId, labels } | update-resource |
PUT /api/model-providers/model-sensitivity-allowlist { modelProviderId, model, allowedLabels } | update-model-provider |
Purpose. A workflow can require every launch to state a purpose (PUT /api/workflows/purpose-requirement, update-workflow). An assistant profile can require the same of every chat. The purpose (up to 500 characters) is the purpose run input. It is sent in every delegated token exchange and is stored on the run or the thread.
Delegation chain. Every token exchange a step makes is recorded with its subject, actor, audience, scopes, purpose and the identity provider's token id. The run's page shows these in the Purpose & delegation card. A chat turn records its exchanges in the same way.
Agentfleet does not redact or classify prompt content. Data governance controls which models may receive labelled data, and records who acted for whom and why.
Related
- Model Providers: pricing and cost estimation.
- Conversations: chats, assistant profiles and their cost.
- Identity & Security: delegated tokens and the purpose claim.
- Operator runbooks: usage governance, LLM data governance and threads.