Paying for CAPTCHA Solvers vs Buying Better Proxies

Measure your challenge rate over 10,000 requests on the target you care about, then apply this:

• Under 5%. Keep the solver. At that rate the spend is small, the engineering time to chase the cause costs more than the solver does, and the challenge is probably triggered by something you cannot control anyway.
• 5% to 20%. Route retries through a cleaner exit instead of solving them. This is the band where the arithmetic in the retry economics section actually flips, and it usually flips toward the cleaner address.
• Over 20%. Stop solving. A one in five challenge rate means the target has classified your traffic, and every solve you buy is a payment to keep a broken configuration running. Fix the address type, the pace or the fingerprint.
• Any rate, on a target that challenges a logged-in session. A solver is the right answer and no proxy change helps, because the challenge is attached to the account rather than to the network.

The rest of this post is the arithmetic behind those four lines, with every figure traceable to either a vendor's own published page or a stated assumption.

These are not two ways to do the same thing, which is why "which is better" produces such bad answers.

A solver is recovery. A challenge has already fired, your request has already failed, and you are buying the token that lets you retry. It works on any target, including ones where the trigger has nothing to do with your network, and its cost is strictly proportional to how often you fail.

Cleaner exits are prevention. You are buying a lower probability that the challenge fires at all. The cost is paid on every request whether or not it would have been challenged, and it only helps when the trigger is actually the address.

That asymmetry is the whole decision. Prevention is a fixed tax on all traffic, recovery is a variable tax on failures. Fixed beats variable once the failure rate is high enough, and the crossover point is computable rather than a matter of opinion.

One more thing follows from it. Buying both is normal and often correct: prevention on the bulk of requests, recovery on the residue that still gets challenged. The mistake is buying recovery and then never revisiting the rate, because a solver bill scales linearly with a number that tends to drift upward.

Every figure in this section was read on the vendor's own pricing page on 23 September 2026. Solver rates change, volume discounts apply on both services, and reCAPTCHA v3 pricing on both is explicitly tied to the score you need, so treat this as a dated snapshot and check the current page before you budget.

Source: 2captcha.com/pricing and anti-captcha.com, both read 23 September 2026. Our ranking of the services themselves, on solve rate as well as price, is in best CAPTCHA solving services.

Two features of that table matter more than any single number. The published ranges are wide, so the rate you actually pay depends on the exact variant and the score threshold you need, and the hardest challenge types carry the widest spread. Arkose Labs runs from $1.45 to $50.00 per 1,000 on one of the two pages, which is not a pricing error, it reflects how much harder some deployments are than others. If your target uses one of the expensive families, the arithmetic below tilts hard toward prevention.

Solver spend is trivially computable: challenge rate multiplied by the rate per 1,000 solves. The table below does it for the range of published rates above, expressed per 1,000 requests sent. Multiply any cell by 1,000 for the monthly cost at a million requests.

Worked through at a million requests a month with an 8% challenge rate:

• reCAPTCHA v2 at $2.00 per 1,000 gives 80,000 solves, which is 80 thousand-blocks at $2.00, so $160 a month.
• The same volume at Anti-Captcha's published $0.95 floor for reCAPTCHA v2 is $76 a month.
• reCAPTCHA v3 at 2captcha's published $2.99 for a score above 0.3 is $239.20 a month.
• reCAPTCHA Enterprise at Anti-Captcha's published $5.00 is $400 a month.

That last line is the one worth sitting with. At an 8% challenge rate on an Enterprise deployment, the solver bill alone exceeds SparkProxy's largest publicly priced proxy plan, which is Plus at $440 a month for 1,000 concurrent threads with unlimited bandwidth. You are not comparing a small add-on to your infrastructure cost, you are comparing two infrastructure costs.

A solve is not instant. A human-backed solve on a visual challenge takes tens of seconds, and during that time the request is still occupying a worker, a connection and a thread on your proxy plan. Nobody puts this in a pricing calculator, and on a concurrency-priced plan it converts directly into money.

Take a base request that completes in 2 seconds, an 8% challenge rate, and a 20 second average solve turnaround. Mean service time becomes:

• 0.92 times 2 seconds, which is 1.84 seconds for the requests that sail through, plus
• 0.08 times 22 seconds, which is 1.76 seconds for the ones that stall on a solve.
• Total mean: 3.60 seconds, against a clean baseline of 2.00 seconds.

Throughput per thread is the reciprocal of that, so you have lost 2.00 divided by 3.60, which is 44% of the work each thread can do. Solving 8% of your requests costs you nearly half your effective concurrency.

Whether that costs money depends on how close you run to your thread ceiling. At a million requests a month compressed into a two hour nightly window, you are sending 33,333 requests a night, which is 4.63 a second, needing about 10 threads clean and 17 with solving. Both fit inside a 100 thread Starter plan at $75 a month, so the occupancy tax is free at that scale.

Push the same window to 6 million requests a month and it stops being free. That is 200,000 requests a night, 27.8 a second, which needs 56 threads clean and 100 threads with solving. A hundred threads is exactly Starter's ceiling, so the solver has pushed you onto Core at $140 a month. The $65 delta is small next to the solver bill at that volume, which at 8% and $2.00 per 1,000 is 480,000 solves for $960 a month, but it is real and nobody budgets for it. Our note on concurrent connections in proxies covers why threads rather than bandwidth set your ceiling.

The general form: at challenge rate c and solve latency L on a base request time T, your throughput per thread falls by a factor of T divided by (T + cL). Plug your own numbers in before you decide that solving is cheap.

Here is the comparison almost nobody publishes, because it requires the credit costs of a managed API rather than a per-gigabyte proxy price. SparkProxy's Scraping API prices a plain fetch at 1 credit and a fetch through a residential exit, set with premium_proxy=true, at 10 credits without JavaScript rendering. So the question becomes concrete: for one challenged request, is it cheaper to buy a solve or to buy a residential retry?

Credit value differs by plan, so the answer differs by plan. Dividing each published plan price by its credit allowance:

The break-even column subtracts the 1 credit you would spend re-fetching the page after a solve, since that cost applies to the solver path and not to the retry path. On Growth, a residential retry costs $0.99 per 1,000, and the solver path costs the solve plus $0.099 of re-fetch credits, so a solver has to charge under about $0.89 per 1,000 to win.

Set that against the published rates from earlier. Nothing in the reCAPTCHA, Turnstile, GeeTest, Arkose or Amazon WAF rows on either vendor page is under $0.89 per 1,000, so on Growth or larger the residential retry is the cheaper recovery for every one of those families. Simple image captchas are the exception: both vendors publish a $0.50 floor there, which comfortably beats a retry on any plan.

Three caveats, because this is the section people will quote out of context.

1. The retry only works if the challenge was address-driven. If the trigger was your TLS fingerprint, a residential exit changes nothing and you have paid 10 credits for the same failure. Measure before you build a retry path.
2. A retry is not free of latency either. It is usually faster than a human solve, but it is a second round trip.
3. These are list rates. Both solver vendors publish volume discounts, and the break-even moves if you negotiate. The method survives; the specific dollar figures do not.

Our breakdown of how scraping API credit pricing works has the full credit table, including the additions for country_code, stealth and rendered formats, which change the arithmetic if your job needs them.

This is the mistake the solver vendors are quietly right about. A team facing a 15% challenge rate upgrades its proxy plan, gets nothing, and concludes that proxies do not help and only solvers do.

The upgrade did nothing because on most concurrency-priced plans the tiers differ in threads, speed ceiling and whitelist slots rather than in address quality. SparkProxy's ladder runs Starter at 100 threads, Core at 250, Boost at 500 and Plus at 1,000, and every one of them draws from the same pool of 1M+ datacenter addresses across 80+ countries. Buying more threads buys more parallelism against exactly the same exits. If the target is challenging you because it recognises hosting networks, four times the threads is four times the challenges.

What actually changes the challenge rate is one of three things:

• A different address type. Moving the challenged traffic to residential exits changes what the target sees at the network layer. That is the premium_proxy=true path priced above, and our comparison of residential vs datacenter proxies covers when the difference is real.
• A different pace. Per-address request tolerance is the most common hidden trigger, and it costs nothing to fix beyond wall-clock time.
• A different fingerprint. TLS and HTTP/2 characteristics get you classified before your address is even scored. Free to fix, not free to discover. Start with TLS fingerprinting.

None of those three is a plan upgrade. Two of them are free. That is why the diagnostic below comes before any purchase.

Four tests, one afternoon, and they tell you which of the three levers is yours to pull. Run each over at least 1,000 requests, because challenge rates are noisy at smaller samples.

Test 1: same request, two networks. Send identical requests, identical headers, identical TLS settings, through a datacenter exit and a residential exit. If the challenge rate drops sharply on the residential exit, the trigger is address-driven and the retry arithmetic applies. If it barely moves, stop shopping for addresses.

Test 2: same network, two clients. Send from the same exit using a plain HTTP client and a real browser stack. A large gap points at your fingerprint rather than your address, and no proxy purchase fixes it.

Test 3: halve the rate. Cut your requests per address per minute by half and re-measure. If the challenge rate falls roughly in proportion, you have a pacing problem, which is the cheapest of the three to fix and the one most often mistaken for an address problem.

Test 4: does it survive a session? Check whether the challenge fires on first contact or only after a logged-in session is established. Account-triggered challenges do not respond to any network change, and that is the one case where a solver is unambiguously correct.

Log the challenge rate as a first-class metric while you do this, not just the error count. Our guide to detecting when your scraper is blocked covers the soft-block cases that never surface as a non-200 status, which is where most unmeasured challenge rates hide, and how to avoid CAPTCHAs when web scraping covers the prevention side in detail.

Write your challenge rate, your solve price and your retry price on one line, and the answer falls out.

Buy solves when the challenge rate is under 5%, the challenge is account-triggered, the type is a cheap image captcha, or you are still proving the target is worth collecting at all. Below 5% the total spend is small enough that engineering attention is the more expensive resource.

Buy prevention when the challenge rate is above 20%, the challenge family is one of the expensive ones, or the rate has moved upward twice in a quarter. A rising challenge rate is the target adapting to you, and a solver subscription does not stop that process, it just makes it affordable for a while longer.

Buy both, split by outcome, when you are in the middle band. First attempt cheap, retry expensive, and keep the solver for the residue that still fails after the retry. On a credit-priced API that looks like a plain fetch at 1 credit, a premium_proxy=true retry at 10, and a solver call only on the second failure.

Re-measure quarterly, in all cases. The single most expensive pattern in this whole area is a solver integration that was correct when it was built two years ago, on a challenge rate nobody has looked at since. The number moves. The bill moves with it.