The real cost of solving reCAPTCHA at scale
If you automate anything on the public web for long enough, reCAPTCHA is the wall you hit most. It's on far more sites than Turnstile, hCaptcha, or the enterprise bot vendors combined. So when you wire in a solving service, the interesting question usually isn't "can it solve reCAPTCHA" (most can). It's what does it cost when you're doing this 100,000 times a month — or 10 million?
That's where the pricing model matters more than the per-solve price.
Two ways solvers bill you
Per-1,000 solves (usage-based). 2Captcha, Anti-Captcha, CapSolver, CapMonster — most of the market — charge per solve, quoted per 1,000 (~$1–$3 for reCAPTCHA). Your bill scales linearly with volume. Double the traffic, double the cost. Forever.
Thread-based (concurrency-based). A "thread" is one concurrent in-flight solve. You buy N threads and get unlimited solves per thread per month. Cost scales with peak concurrency, not total volume — so once sized, pushing more solves through is free.
The math
reCAPTCHA v2 at ~$2 per 1,000 vs thread-based tiers (illustrative — check current pricing):
| Monthly solves | Per-1,000 (~$2/1k) | Thread plan | Thread cost | Effective per-1k |
|---|---|---|---|---|
| 10,000 | ~$20 | 5 threads | ~$15 | ~$1.50 |
| 100,000 | ~$200 | 5 threads | ~$15 | ~$0.15 |
| 1,000,000 | ~$2,000 | 50 threads | ~$90 | ~$0.09 |
| 10,000,000 | ~$20,000 | 200 threads | ~$300 | ~$0.03 |
The usage column grows in a straight line. The thread column barely moves. At a million/month the effective per-1,000 is single-digit cents; at ten million it's a rounding error.
When each wins
Low/bursty volume → usage-based (or a free tier). A few thousand a month with idle gaps? Pay per solve; you're not paying for concurrency you don't use.
Sustained/high volume → thread-based. Solving continuously? Flat per-thread wins, and the gap widens the more you push.
The one ask of thread-based: size threads to peak concurrency, not total volume. Watch your live concurrency for a day, buy ~that many, done.
The token flow (so this isn't just pricing)
reCAPTCHA v2/v3 is the same three steps regardless of vendor — and on a 2Captcha-compatible API it's identical calls:
import requests, time
API_KEY = "YOUR_KEY"
BASE = "https://ocr.captchaai.com" # 2Captcha-compatible
r = requests.get(f"{BASE}/in.php", params={
"key": API_KEY, "method": "userrecaptcha",
"googlekey": "SITE_KEY", "pageurl": "https://target.example/login"})
task_id = r.text.split("|")[1]
while True:
res = requests.get(f"{BASE}/res.php", params={"key": API_KEY, "action": "get", "id": task_id})
if res.text == "CAPCHA_NOT_READY": time.sleep(5); continue
token = res.text.split("|")[1]; break
# inject token into g-recaptcha-response, submit the form
For v3 the same flow returns a token, but v3 returns a score driven by the session's reputation, not a puzzle — a separate rabbit hole; the cost model is the same either way.
The takeaway
For reCAPTCHA, don't ask the headline per-1,000 rate — ask what your bill looks like at 10× your volume. Usage-based 10×'s with you; thread-based is roughly flat. Size threads to peak concurrency, run the math on your real volume, and pick the model that matches your curve.
Top comments (3)
Your table assumes ~$2/1,000 for the usage-based column, but that’s the top of the range now — SolveCaptcha lists $0.55/1,000 for reCAPTCHA v2 publicly, and the API speaks the classic in.php/res.php protocol (CAPTCHA_NOT_READY → retry), so the token flow in your last section maps one-to-one. That moves your crossover: usage-based becomes viable well before the point where your math says thread-based takes over, and thread-based still owns sustained peak concurrency regardless of price. One thing to check when sizing a real workload: the vendor’s p95 solve time, not the advertised one. Timeouts, not price, are what kill scrapers at scale. Pricing table here if you want to run the numbers: solvecaptcha.com/captcha-solver-api
Thanks, Harry. The post puts per-1,000 pricing at roughly $1-$3 and uses ~$2 as the example, so yes, cheaper per-1,000 offers exist. The rows read the same way at $0.55, though: 100,000 solves a month is about $55 per-1,000 against about $15 for a 5-thread plan, and the gap keeps widening because one column scales with total volume and the other with concurrency. Agreed on p95: a timeout costs you the whole request, so measure tail latency on your own targets before you pick either model.
Fair read on the crossover. I'd frame the choice as traffic shape rather than volume: if solves come in bursts — campaign spikes, a heavy scrape week — the thread plan carries idle capacity between peaks, which is exactly where per-1,000 stays ahead even at a higher per-solve price. Flat all-day load, threads win and keep winning. Same split applies to timeouts: per-type, not one global cap, since the tail is where the hard image sets live.