FinOps & fleet governance
Setting a per-project cost cap
An agent fleet spends money the moment it plans. A recursive planning loop or a misconfigured retry can burn a month's allocation before anyone reads a billing alert, so XOOZLY treats the project's cap as a precondition of starting a run rather than a figure to reconcile afterwards.
Open Set a cost cap in the consoleWhy the cap is a precondition, not a budget alert
- Stored as
- cost_caps.centsInteger cents, never a float
- Checked
- Pre-flightBefore StartAgentRun, not after
- On breach
- Auto-pauseThe project pauses, not just the run
A billing alert tells you what you already spent. For a fleet issuing planning calls and tool calls continuously, that is the wrong instrument: by the time an org-level alert fires, the spend it describes is finished. The cap is therefore evaluated as a precondition — a run that would exceed it does not start.
A budget alert
Spend is measured after the fact and compared against a budget on a schedule. Anything between two checks is unbounded, so a retry loop is only visible once it has finished being expensive.
A hard cap
The project's remaining allowance is read before the run is accepted. A run that does not fit is refused at that point, and a breach discovered mid-cycle pauses the project rather than letting the next step proceed.
Setting one
- Open the project you want to limitCaps are per project, so pick the project whose fleet you are limiting. A cap on one project does not constrain another.
- Set the cap amountThe figure is money, held as integer cents. A cap of zero is valid and meaningful: it blocks all spend rather than meaning “unlimited”.
- Agree who can resume after a breachA breach pauses the project. Resuming is deliberately a restricted action rather than something any member can clear, so decide who holds that role before you need it.
What a breach actually does
- The project pausesThe run stops at its next step boundary rather than mid-write, and the project is marked paused. Work already recorded stays recorded — the pause is a refusal to continue, not a rollback.
- A person decides what happens nextRaising the cap, or the period rolling over, is what lets work proceed again. Resuming is restricted to the roles your organization assigned that capability.
Who can lift a pause
Resuming a paused project is deliberately not something every member can do. A pause means the project has already spent its allowance, so clearing it is a spending decision, and the roles your organization assigned that capability are the ones that can make it.
What the cap does not cover
The cap governs what the fleet spends on your project. It is not a per-agent budget, not a rate limit, and not a quota on how many runs you may queue — a run that fits inside the remaining allowance starts regardless of how many ran before it.
- It is per project. One project's cap does not constrain another's.
- It gates the run at the point of starting, so a long run that was within budget when it began is not killed mid-flight by a later check — it stops at its next step boundary instead.
- Request-rate limits are a separate concern with their own configuration; do not expect the cap to stand in for one.
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.