Credits & Pricing

Rove uses a credit-based billing system. 1 credit = 1 API action.

Free Tier

Every new account gets 100 free credits. No credit card required. Test keys (rvp_test_) never consume credits.

Credit Packs

Buy credits anytime from the dashboard billing page. One-time purchase through Stripe Checkout; credits never expire.

The same prices are served by GET /v1/billing/catalogue (public, no key).

What Costs Credits

What Doesn't Cost Credits

• Test keys (rvp_test_) — authenticate normally but never deduct credits. Use for development and CI.
• Read-only endpoints — usage stats, artifact retrieval, key listing.
• Wait actions — wait_for is free because it doesn't generate new browser state.

Typical Costs

Credit Expiry

Purchased credits never expire. They're valid for the lifetime of the current API version (v1).

Exact Credits

Balances are kept in millicredits: 1 credit = 1,000 millicredits. Browser actions cost whole credits; supervised time is charged by the minute in millicredits, so a balance can hold a fraction of a credit.

• credits_remaining is the whole credits left, rounded down; credits_remaining_millicredits is the exact balance. A balance of 250 millicredits shows credits_remaining: 0.
• The supervised rate a session started now would use is supervised_millicredits_per_minute in GET /v1/account/balance. The base rate, the minimum minutes and the rounding are in GET /v1/billing/catalogue under supervised; Builder and Scale subscriptions have lower rates (catalogue tiers, and the pricing page). A session keeps the rate it started with.
• The SDKs format millicredits exactly with formatCredits (Node) and format_credits (Python): 1750 becomes "1.75".

Monitoring Usage

Check your balance anytime:

curl https://api.roveapi.com/v1/account/balance \
  -H "Authorization: Bearer rvp_live_YOUR_KEY"

GET /v1/account/usage adds usage counts for the key. Or visit the dashboard to see usage charts and credit burn rate.

How Agents Buy

An agent can buy credits with its own API key when the account owner allows it:

1. The owner turns on Agent purchasing at Billing, sets a per-purchase and a per-period limit, and allows the key under API keys. Optionally the owner saves a card and lets agents charge it.
2. The agent reads GET /v1/account/balance (purchasing.allowed, purchasing.packs_within_limits) and calls POST /v1/billing/purchases with a pack item_id and an Idempotency-Key.
3. With an allowed saved card, the purchase is charged at once. Otherwise the agent gets a payment link to give to a person, who pays in their own browser.

Limits are checked before any money moves, and the owner is emailed about payment links and paid purchases. The same flow is in the Node and Python SDKs (purchaseCredits, purchase_credits) and the MCP buy_credits tool. Everything, including retries and test keys, is in the Billing API guide.

What Happens at Zero

When the balance is too low for an operation, the API answers 402 insufficient-credits; a supervised session that runs out ends with 410 session-expired and reason: "credit_exhausted" (the browser profile is kept). Both say what to do next: next_step is buy_credits when this key may buy a pack within its limits (packs_within_limits), otherwise ask_owner with the owner's owner_action_url. See Out of credits for both bodies.

No surprise charges. No silent degradation. Buy more credits or switch to a test key.