Credits, reservations, and billing
Understand what a browser costs and why available balance differs from the account balance.
Coming soon
Production checkout is planned for the 1.0 release and is not available yet. The credit ledger and payment-provider test flow are implemented. Confirm test access and funding with your instance operator.
Current pricing rules
The current base rate is 100 credits per browser-hour; USD 1 purchases 1,000 credits. The implemented checkout minimum is USD 10 before tax. Confirm the instance's displayed price before purchase.
Each normally billable session rounds up to whole credits, with a minimum of one credit: one credit per started 36 seconds at the base rate. A 10-second session costs one credit; a 37-second session costs two. Purchased credits do not expire under the current product policy.
Reservations are a budget
Creation reserves enough credits for the requested maximum lifetime, rounded up. Those credits are temporarily unavailable to other new sessions.
For example, a 900-second browser reserves 25 credits at the base rate. If it normally stops after 37 seconds, its charge is two credits and the unused 23-credit reservation is released.
Account balance, available credits, reserved credits, and final consumption therefore describe different values. Projects and keys share the account balance.
When time counts
Billable time starts when the browser becomes ready and ends when its resources actually stop. Starting does not count. Waiting for a model, website, or person while the browser remains running still counts.
Disconnecting CDP or closing a viewer does not stop billing. Explicitly close the session when finished. Cleanup after confirmed stop does not add browser usage time.
Failures and release
Startup failure or a platform fault that interrupts use makes that session free under the current policy. Your task failing or a target website refusing access is not itself proof of a platform fault.
An ordinary completed session remains billable if later cleanup fails. Usage settlement and resource release are separate: a credit reservation can be released while concurrency still awaits confirmed resource cleanup.
Normal settlement stays within the approved session budget; delayed stopping costs beyond that budget are borne by the platform.
Funding and account restrictions
Successful payment must be verified before credits become spendable. Taxes do not change the credited amount. A payment dispute can freeze new sessions despite a positive balance.
Unused reservation release is not a cash refund. Payment reversals and refunds have their own reconciliation process; this product does not currently offer a self-service refund request workflow.