Skip to main content
Spend caps are org-wide and set in dollars. 0 turns budget protection off.

​
1. Check current usage

The shipped CLI shows:
  • current plan
  • included compute for that plan
  • current period spend
  • current spend cap
In --json mode it also returns max_spend_cap_cents, which is useful for tooling and dashboards.

​
2. Set a spend cap

Set the cap in dollars. Use 0 to turn budget protection off.

​
3. Choose what happens at the cap

Every cap carries a policy. Warning emails go to org admins at 80% under all three; the policy decides what changes at 100%: The CLI has no policy flag: floo billing spend-cap set <amount> keeps the policy already on the org, or selects freeze_new_spend when budget protection was off. To choose a policy, use the dashboard Billing page, which sends policy alongside the amount to POST /v1/billing/spend-cap. Sending a cap with the policy off is rejected with SPEND_CAP_POLICY_REQUIRED. Under freeze_new_spend and hard_stop, a blocked deploy fails with SPEND_CAP_EXCEEDED until the cap is raised or the next billing period begins. Raising the cap above current spend clears the block. After a hard_stop, services stay scaled to zero until the next deploy, restart, or promote recreates them. Choose alerts_only when downtime costs more than overspend, freeze_new_spend when running traffic must stay up but agents must not add capacity, and hard_stop when the bill itself is the hard limit.

​
4. Upgrade the plan

The shipped plan names in the CLI are:
  • paygo
  • team

​
5. Use JSON for automation

​
Dashboard surface

The shipped Billing page adds the visual view:
  • current plan details
  • usage charts and limits
  • spend cap amount and policy
  • upgrade and billing portal flows
The CLI is still the best surface for scripts and agent guardrails.
  1. Inspect usage after the first live deploy.
  2. Set a spend cap that matches the project budget, and pick the policy on the Billing page.
  3. Re-check usage before increasing the cap.
  4. Treat SPEND_CAP_EXCEEDED as an operational signal, not a transient error.