Skip to main content
Spend caps are org-wide and set in dollars. Prepaid paygo requires a positive hard usage limit. Subscription billing can use optional budget protection.

​
Prepaid paygo

Run floo billing balance to inspect settled credits, pending funding, the remaining monthly limit, and recorded stop or recovery progress. Use floo billing upgrade to open Billing for the current organization and add funds. Pending payments do not become spendable credits until settlement. New spending requires both a positive balance and room under the monthly hard limit. Raising the limit does not add credits; adding credits does not raise an existing positive limit. The first settled payment sets the limit to its settled amount when the limit is unset, zero, or no higher than the pre-plan $5 ceiling. A higher existing limit is preserved. floo billing spend-cap set 50 sets a $50 monthly hard limit. Prepaid accounts always use hard_stop: set 0 and weaker policies are rejected with PREPAID_HARD_LIMIT_REQUIRED. When funds or limit headroom run out, new spending is refused and floo suspends workloads. Inspect floo billing balance for the limiting condition and recovery progress, then check the app itself. Usage can arrive after work runs, and retained resources can keep accruing charges after workloads stop. The saved card covers unpaid usage; it does not automatically replenish spendable credits or raise the limit. Billing shows payment failures and any required recovery action. The policy choices below apply to subscription billing.

​
1. Check current usage

It shows:
  • current plan
  • floo credits included per month on that plan
  • current period spend
  • current spend cap
--json also returns max_spend_cap_cents, the highest cap the plan allows.

​
2. Set a spend cap

The CLI takes dollars. On subscription billing, 0 turns budget protection off. On prepaid paygo, use a positive amount.

​
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 or send policy alongside spend_cap (in cents) 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

This opens Billing for the CLI’s current organization to choose a plan, add prepaid funds, or inspect recovery. A prepaid organization cannot start a self-serve subscription checkout; contact support if you need to change its billing model. Subscription plans start with no spend cap. A subscription plan change keeps an existing positive cap unless it is below the new plan’s included credits; then floo raises the cap to that allowance and keeps the policy. Prepaid paygo uses the mandatory hard limit described above.

​
5. Use JSON for automation

​
Dashboard surface

The Billing page shows:
  • current plan details
  • usage charts and limits
  • spend cap amount and policy
  • upgrade and billing portal flows
Scripts and agents set guardrails with the CLI or the HTTP API. Read retained billing email history with floo billing notifications. It records earlier observations and submission outcomes, not current workload health.
  1. Inspect usage after the first live deploy.
  2. Set a spend cap that matches the project budget. Prepaid paygo uses hard_stop; subscription accounts can choose a policy on Billing.
  3. Re-check usage before increasing the cap.
  4. Treat SPEND_CAP_EXCEEDED or SPEND_AUTHORITY_EXHAUSTED as an operational signal, not a transient error.