Billing & credits

BizOS bills on credits (1 credit = 1 task run or 1 creative) and a prepaid wallet for ad spend. Only two CLI commands spend credits, both gated by --yes. Out-of-credits returns HTTP 402; top up at app.bizos.lol/billing. Payments always stay on the web.

Credits

A credit is the unit of paid work:

1 credit = 1 task run, or 1 creative generated.

You can read your balance any time (free):

bizos billing --json

{ "plan": "pro", "credits": 42, "tiers": [ ... ], "packs": [ ... ] }

What spends credits

Only two actions cost a credit. Both require an explicit --yes:

Everything else — listing, reading, creating documents, reading leads, reading wallet/billing, notifications — is free.

Reserve-and-refund

Credit-spending is enforced server-side, reusing the same billing library as the web app:

1. The route reserves a credit before doing the work (reserveCredit / reserveCreative).
2. It runs the task or generates the creative.
3. On failure, the credit is refunded automatically.

The CLI cannot bypass this. There is no client-side credit logic to tamper with.

The wallet (ad spend)

Separately from credits, BizOS uses a prepaid wallet for ad spend (Model B, 85/15). The CLI is read-only here — payments and auto-recharge are configured on the web.

bizos wallet --json

{
  "balance": 18.50,
  "funding": "card",
  "autoRecharge": { "enabled": true, "threshold": 5 }
}

When auto-recharge is enabled, the wallet tops itself up off-session once the balance crosses the threshold.

Handling 402 (out of credits)

When you have no credits left, a credit-spending route returns HTTP 402 with this shape:

{ "error": "out_of_credits", "message": "Out of credits — top up at app.bizos.lol/billing." }

What to do:

• Humans: open app.bizos.lol/billing and buy a credit pack or upgrade your plan.
• Agents: stop — do not retry. Surface the message to the user and wait. Retrying will keep returning 402.

Check before you spend:

# read balance first (free), then spend only if > 0
bizos billing --json
bizos tasks run tsk_456 --yes --json

Why payments stay on the web

Buying credits and managing cards happen in the dashboard, never in the CLI. This keeps payment flows in a browser context (where 3-D Secure and card entry belong) and keeps the CLI a safe, read-and-spend-only client. See the API reference for the full endpoint list.