Which number explains the work you will actually pay for?
A usage rate measures one meter. A monthly bill also reflects eligible plans, included credits, rounding and additional services. Put the rate beside a fully specified scenario instead of calling it the whole price.
Start with the work that has to finish: executions per month, browser time per execution, concurrent browsers and network traffic. Choose the cheapest eligible plan for that workload. An hourly rate can be lower while the bill is higher because a plan floor, billing minimum or extra service applies.
Notte
The public usage rates are $0.01 per browser-hour, $0.05 per Function-hour and $10 per GB of managed proxy traffic. Paid plans return their price as usage credits. Price the relevant meters and plan eligibility for the workload.
Sources: notte.cc ↗
Browserbase
Compare the public plan's included browser allowance and overage with the workflow's duration. Include proxy traffic and any separately priced services; an Arena browser-hour estimate does not describe the whole Browserbase bill.
Sources: browserbase.com ↗
Kernel
Use the plan and browser configuration in Kernel's pricing documentation. Managed networking, account allowances and app execution make a browser-hour comparison only one part of the decision.
Sources: kernel.sh ↗
Anchor Browser
Compare the selected browser and task offering using Anchor's current commercial terms. Include network usage and the execution path actually used; a batch API's capacity is not a price quote for that batch.
Sources: anchorbrowser.io ↗
Evaluate the operational difference
A useful cost comparison gives both a usage estimate and the eligible monthly plan. Keep an unsupported workload out of the price ranking even if a rate can be multiplied into an attractive number.
For 10,000 runs lasting three minutes, browser time is 500 hours before rounding, setup and retries. At Notte's published $0.01 browser-hour rate, that meter is $5. Paid-plan eligibility and any proxy or Function usage still determine the total bill.
- Count attempted runs as well as successful runs.
- Apply the provider's rounding rule to each session before adding usage.
- Separate browser time, function compute, proxy traffic and identity services.
- Apply included credits once; do not add the same subscription fee again.
- Mark an ineligible plan as a capacity mismatch rather than a cheap option.
Make the acceptance test explicit
Describe the work that must finish, the account it runs under, the state it needs to retain and the expected output. Select eligible product configurations before measuring latency or price.
Run the same workflow with each proposed architecture. Keep startup measurements separate from task execution, and distinguish provider failure from a configuration error or an unsupported website action.
Choose the responsibility you want to own
An external runner keeps deployment and queues in your application. A hosted execution layer moves part of that responsibility to the browser platform. Saved browser state reduces repeated setup, while managed website authentication may add readiness checks. Choose each part deliberately rather than treating a brand as one indivisible feature list.