Budgets & limits

How budgets are structured

A selected budget package defines its own scopes and enforcement. The canonical software-company package demonstrates:

• A top-level company budget — An optional envelope for the whole exocorp, often summarized from narrower package-owned scopes.
• Per-team budgets — The reference package may assign a budget scope to each of its teams and surface a package-owned approval when a limit is reached.
• Per-component or per-integration budgets — A budget package may define scopes for paid providers or external integrations when the consuming component exposes the usage data it needs. This is not automatic for every installed package.
• Custom scopes — A package can define budgets on other scopes — a specific bet, a particular customer engagement, a campaign — if you want hard limits on something that doesn’t map cleanly to a team.

Setting and changing budgets

Budget semantics and controls belong to the package that defines the scope. Use its API or optional settings surface. A budget package may let you set:

• The limit — Total dollars (or other unit) over a period. Usually a monthly cap.
• Advisory threshold — The level at which the company should start watching. Usually 60-70%. Crossing it triggers a soft signal in the package’s summary and alert records.
• Soft limit — The point at which the company stops admitting new non-essential work in this scope. Usually 85-90%. Existing work continues; new initiatives wait. The package emits an alert.
• Hard stop — The level at which the scope refuses to admit any new work, including continuing in-flight efforts that require new spend. The scope is effectively paused. An urgent package-owned alert is emitted.

You can change limits at any time. Lowering a limit below current spend immediately moves the scope into the appropriate alert state.

Watching spending

A budget package may expose pressure through several records or optional views:

• Summary — Top-level pressure bar plus the three most-stressed sub-budgets in a package-owned dashboard. Daily glance.
• Scoped detail — Per-team budget detail: used, limit, burn rate per day, projected month-end. With overrun callout if the projection puts the team past its limit.
• Alerts — Active budget alerts — advisory, soft limit, hard stop — exposed through the package’s API, notifications, or optional UI.
• All scopes — A consolidated package view is useful for spotting structural issues (one team way under, one way over) and rebalancing.

Handling alerts

When the budget owner emits an alert, your options include:

• Raise the limit — If the spend is justified, increase the budget. The alert clears, the scope continues operating.
• Look at what's spending — Inspect the package’s scoped records to see which work items, which agents, which categories are consuming. Sometimes one specific thing is the cost.
• Pause the scope — If the work isn’t justified, pause the team or scope. Existing in-flight work may complete; new work stops admitting.
• Reshape — If a team keeps blowing through budget, the underlying issue is usually structural. The mandate may be too broad. Tools may be too expensive. The team may need different capabilities. See Working with teams.

What drives the spend

The dominant cost components in most exocorps:

• Provider tokens — Each model invocation costs. High-capability agents running on premium models will dominate spend. Use the owning package’s usage and audit records to inspect this.
• External service costs — Component packages may call paid third-party APIs (CRM, email sending, SMS, search). Those vendors bill under their own terms; a consuming component may expose usage through its API or optional settings interface.
• Runtime cost — The compute the exocorp itself runs on. Smaller and more predictable than the above, but real.