FactorAI

Billing controls

What happens when FTAI runs out and which limits change it.

Included, daily, and purchased FTAI is always spent first. Billing controls decide whether usage continues after that FTAI is exhausted, and how far it may go.

Fallback order

FTAI is used first. Auto-reload is tried before on-demand billing. On-demand is used only when FTAI and auto-reload cannot cover a charge.

Auto-reloadOn-demandOutcome
OffOffUsage stops when FTAI runs out.
OnOffFTAI reloads; usage stops if the reload cannot complete.
OffOnUsage continues on-demand after FTAI is exhausted.
OnOnFTAI reloads first; on-demand covers what remains.

Postpaid overage

Postpaid overage lets usage continue after available FTAI is exhausted, up to an invoice limit that you set. Usage is added to the next invoice rather than drawn from FTAI.

Overage is available to any account with an attached payment method, not only to Pro, so a limit saved on Pro keeps applying after a plan change. On Pro the limit defaults to the included monthly FTAI for the team's seats.

The control shows one of these states:

StateMeaning
AvailableOverage is enabled and under the limit.
Approaching limitUsage has reached 80% of the invoice limit.
Limit reachedUsage has reached the invoice limit.
Payment failedThe last overage charge could not be collected.

Turning postpaid overage off stops usage with a billing error once available FTAI is exhausted. The product API reports this as 402 with insufficient_ftai; see usage lifecycle.

Self-serve Pro teams manage auto-reload and postpaid overage in team billing settings. Enterprise limits are set in the contract instead.

Auto-reload

Auto-reload buys prepaid FTAI when the remaining balance falls to or below a threshold. The current defaults are a $5 threshold and a $25 top-up; both values are editable.

A reload that fails does not silently continue usage: with on-demand off, usage stops; with on-demand on, it falls back to on-demand billing. One-time top-ups default to $20 with a $5 minimum.

Spend limits

A spend limit caps usage for one feature over a period. Set it through the Developer API:

  • POST /v1/billing/spend-limits creates or updates a limit and accepts featureId, limitMicroUsd, and an optional period.
  • GET /v1/billing/spend-limits lists limits.
  • DELETE /v1/billing/spend-limits/{id} removes one.

The period defaults to the subscription billing period (billing_period) and also accepts day, month, and lifetime. Usage is measured inside the active period. When measured usage reaches the limit, evaluation reports that usage is no longer allowed and records a balances.limit_reached event. The team overview warns at 80% of a configured limit and marks it reached at 100%.

Managing these limits is self-serve on Pro. Enterprise limits are contract-managed.

Usage alerts

A usage alert is a per-feature threshold that fires when usage reaches it. Alerts do not stop usage.

Set and list alerts through the Developer API:

  • POST /v1/billing/alerts creates or updates an alert with featureId and thresholdMicroUsd.
  • GET /v1/billing/alerts lists alerts.
  • DELETE /v1/billing/alerts/{id} removes one.

Each evaluation compares current usage with the threshold. When usage is at or above it, the alert records the trigger time and emits a balances.usage_alert_triggered event, which the team's usage and spend notifications can deliver.

See also