Plans & credits
Every org is on a plan. The plan grants a monthly credit allotment and sets the org’s limits, and it clamps every request before it’s matched.
The catalog
Section titled “The catalog”| Basic | Pro | Enterprise | |
|---|---|---|---|
| Monthly credits | 5,000 | 100,000 | By agreement |
| Max concurrency | 10 | 200 | 2,000 |
Plans are a fixed catalog (basic, pro, enterprise); the dashboard’s plan
page is generated from it. Enterprise has no automatic monthly allotment; its
credits are arranged by agreement, and it still needs a positive balance to send
traffic.
How credits are spent
Section titled “How credits are spent”Billing is per operation, in whole credits. There’s no per-GB math, just a flat surcharge for very large bodies:
| Operation | Credits |
|---|---|
| Any proxied request, and each crawled page | 1 |
| + JavaScript render (headless browser) | +5 |
| + Structured extraction | +1 |
| + Full-page screenshot (crawls, in place of the render charge) | +5 |
| + Each whole 5 MiB of response body (proxied requests) | +1 |
So a plain fetch costs 1 credit; a crawled page rendered with JavaScript costs
6. Render, extract and screenshots are opt-in, so a standard proxy request
costs 1 credit plus the size surcharge. A request is charged once the target’s
response starts arriving, whatever its status; requests that fail before that
(no edge, a timeout, 597, or our own 429/402) are free.
Getting credits
Section titled “Getting credits”-
Monthly allotment: your plan’s monthly credits are granted automatically at the start of each calendar month (UTC). The grant runs hourly, so a new org gets its first allotment within an hour. Unused credits carry over.
-
Credit packs: top up with a prepaid pack, bought through the API (
bt billing checkout <pack>opens a Stripe checkout); the dashboard doesn’t sell packs. Packs never expire:Pack Credits Price 5k 5,000 $16 100k 100,000 $83 500k 500,000 $333
When your balance hits zero, requests are refused until you top up or your next allotment lands.
What a plan clamps
Section titled “What a plan clamps”- Credit balance: every request that gets a response debits credits; an
empty balance stops traffic (
402) until it’s refilled. - Allowed regions: the catalog plans allow every region, but an org can
carry a region allow-list (see below); a request that names a region outside it
is rejected with
403. A request that names no region isn’t checked against it. - Max concurrency: the number of simultaneous in-flight requests. Exceeding
it returns
429. (A per-second burst guard sits well above this to catch runaway clients; concurrency is the real throughput knob.) - Default strategy: the routing strategy used when a
request doesn’t specify one. The catalog plans leave it unset, so requests fall
back to the fleet default,
goodput_per_second.
Per-org overrides
Section titled “Per-org overrides”An org can carry overrides set by bytetourist (a default strategy, a region allow-list, a concurrency cap, or a stealth profile) without changing plans. Each one replaces the plan’s value rather than being bounded by it, and there’s no dashboard or API control for them. The effective config enforced on the request path is the plan merged with these overrides.
Concurrency
Section titled “Concurrency”In-flight requests are counted per org atomically, so the concurrency cap is
enforced consistently across every proxy instance. When you’re at the cap, new
requests get 429 until in-flight work drains.