Add burst and fast to paid hCaptcha task requests
Choose extra weighted concurrency, higher queue priority, or both, and account for their distinct prices and limits.
Choose the control for the problem
Burst and fast solve different scheduling problems. Burst allows paid work above the account’s normal weighted concurrency limit within the documented burst ceiling. Fast increases queue priority. A high-priority task can still wait, and fast does not expand the concurrency allowance.
Set either boolean on task creation. Omitting a field has the same effect as false. Do not enable both by default unless you intend to pay for both on every affected request.
{
"type": "hcaptcha_token",
"sitekey": "YOUR_SITEKEY",
"url": "https://your-site.example/login",
"burst": true,
"fast": false
}
This request chooses the concurrency mode without the priority mode. It still requires the normal customer credential and task lifecycle handling.
Account for weighted admission
Recognition uses one concurrency unit and token work uses ten. The account limit spans its API keys. Burst’s documented ceiling is five times the normal limit, and standard requests still use the standard limit even when burst jobs are active.
For a 20-unit account, a burst ceiling of 100 units is not 100 simultaneous token jobs. Local scheduling should reflect weights, and a definitive 429 still needs recovery according to the response.
Estimate prices using the selected modes
The standard multipliers are 1.5× for burst and 1.2× for fast. Both apply when both are selected. For recognition, group count also changes the base charge. Custom account rates can differ, so use the current rates contract for accounting.
A task marked burst uses that price even when it happens to fit below normal capacity. Enabling fast does not promise an immediate worker or extend a task timeout. Make these tradeoffs explicit in any user-facing mode selector.
Evaluate before making a mode permanent
Measure queue wait, terminal completion, observed acceptance, and billed cost on comparable work. A faster client polling interval is not evidence that fast improved queue processing. Preserve task IDs and distinguish unknown outcomes.
The burst-versus-fast comparison summarizes the decision. A bounded queue can often smooth bursts before you decide to buy extra capacity, and budget handling keeps microcent calculations precise.