Every assumption is visible and replaceable.

1. What ScrapeBudget estimates

The calculator estimates page loads and provider API credits for one recurring monthly workload. It shows base work, retry attempts, request-mode complexity, buffer, daily average, the smallest listed capacity tier that covers the estimate, and utilization of that tier.

2. What it does not estimate

It does not predict target permission, legal compliance, response success, latency, geography, concurrency limits, bandwidth, provider pricing, or whether a proxy type will work against a specific target. A 31-day input models calendar workload even though the currently reviewed rotating plans are valid for 30 days or until credits are used.

3. Formula

base page loads =
pages per site × target sites × checks per day × active days

page loads with retries =
base page loads × (1 + retry overhead / 100)

credits before buffer =
page loads with retries × request-mode multiplier

estimated monthly credits =
ceil(credits before buffer × (1 + safety buffer / 100))

The engine uses exact rational arithmetic and rounds only the final monthly credit estimate upward. This avoids floating-point drift and remains exact at the maximum accepted inputs.

4. Complexity multipliers

These multipliers translate approximate provider guidance into planning assumptions. They are not guaranteed billing values. Browser pages may load scripts, fonts, images, analytics, and API calls separately.

5. Retry overhead

Retry overhead means additional attempts relative to the base page loads. A 10% setting adds 10 attempts per 100 scheduled loads. It is not the probability that a request fails, and it should not be modeled as 1 / (1 − failure rate).

6. Safety buffer

The safety buffer is applied after retries and request complexity. It covers uncertainty such as catalog growth, new browser assets, and incomplete trial data. Keep it separate from retries so both assumptions remain measurable.

7. Tier selection

The engine selects the smallest reviewed capacity greater than or equal to the estimate from 2.5M credits, 5M credits, 10M credits, 50M credits, 100M credits, 200M credits, 400M credits. Utilization at or below 80% is a comfortable fit; higher utilization through 100% is a tight fit. Results above 400M credits require custom capacity.

8. Sticky-session warning

Capacity cannot repair an identity mismatch. When login, navigation, or a multi-step transaction needs the same IP, per-request rotation can break the workflow. The calculator recommends a static dedicated or ISP option and still shows the arithmetic.

9. Worked examples

Raw catalog check

1,000 pages × 2 sites × 2 checks × 30 days = 120,000 base page loads. With 10% retries and 20% buffer at 1×, the final estimate is 158,400 credits.

Browser without JavaScript

5,000 pages × 3 sites × 4 checks × 30 days = 1.8M base loads. Add 10% retries, multiply by 2.5×, then add 20% buffer: 5.94M estimated credits, covered by the 10M tier.

10. How to measure real usage

1. Run a representative sample against the real public pages.
2. Count useful results, attempts, errors, timeouts, and retries.
3. Record provider credits consumed and browser assets loaded.
4. Calculate credits per useful result, not only per request.
5. Replace planning defaults with measured values and recalculate.

11. Data sources and review date

Provider facts were reviewed on 2026-07-26. They are stored once in code and rendered into both the calculator and this page.

• Official rotating proxy product documentation
• Official provider terms

12. Change log

Version 1.0 — July 26, 2026: Initial workload formula, exact arithmetic, reviewed complexity multipliers, capacity tiers, retry model, buffer model, and workflow-fit warnings.