Most software buyers have two pricing models in their heads. Per seat: you count people. Per unit: you count contacts, records, minutes, or API calls. Both are quotas — you buy an amount, you consume it, you top up.
Then you open a price page that says "5 threads — unlimited usage" and the mental math stops working. Unlimited usage sounds like the best deal you have ever seen, right up until you realize you have no idea whether five threads is generous or crippling for your workload.
Concurrency pricing — threads, workers, lanes, parallel jobs, concurrent sessions — sells you a rate ceiling, not a quota. You are not buying how much you can do in a month. You are buying how much you can do at the same instant. Size it on peak, not on total, and the model becomes easy to reason about. Size it on total and you will either overpay by an order of magnitude or hit a wall on your busiest day.
Where you'll meet this model
Concurrency pricing shows up wherever a vendor's real cost is capacity held open rather than work performed:
- Contact-centre and live-chat platforms priced by concurrent agent sessions.
- CI/CD services priced by parallel jobs or runners.
- Media and rendering pipelines priced by simultaneous encodes.
- Automation and data APIs priced by concurrent tasks, usually called "threads."
The wider comparison of SaaS pricing models covers the per-seat and per-unit shapes; this piece is about the third one, because it is the one buyers consistently mis-size.
The only formula you need
Peak concurrency is arrival rate multiplied by how long each job occupies a lane:
concurrent jobs needed = jobs arriving per second × average seconds per job
That is Little's Law with the jargon removed. Work it in the units you actually have. If your busiest hour runs 1,800 jobs and each takes an average of 8 seconds:
1,800 jobs / 3,600 seconds = 0.5 jobs per second
0.5 × 8 seconds = 4 concurrent jobs
Four. Not 1,800. That gap — between monthly volume and concurrent demand — is where nearly all the mis-sizing lives.
Two corrections before you commit to the number:
- Peak, not average. Traffic is lumpy. If your busiest ten minutes carry three times the hourly average, size on the ten minutes. A plan that queues during your daily spike is a plan that fails when it matters.
- Headroom for latency drift. If job duration doubles because an upstream service slowed down, your concurrency requirement doubles with it. Buy one tier of slack, or confirm the vendor lets you upgrade mid-cycle without a sales call.
Reading a thread-based price page
CAPTCHA-solving APIs are a clean worked example of this model, because their price pages publish both the thread counts and the per-job latency ceilings you need to convert threads into throughput.
CaptchaAI states thread-based plans with unlimited solves per thread: BASIC at $15/month for 5 threads, ADVANCE at $90/month for 50 threads, and ENTERPRISE at $300/month for 200 threads. It also publishes solve-time ceilings by challenge type — under 0.5 seconds for image OCR, under 4 seconds for reCAPTCHA v3, under 10 seconds for Cloudflare Turnstile, under 60 seconds for reCAPTCHA v2 — plus a stated success rate above 99% and a 99.9% uptime SLA.
Those two facts together are what let you price the thing properly:
throughput ceiling = threads × (3,600 ÷ worst-case seconds per job)
At the stated 10-second Turnstile ceiling, 5 threads gives a defensible worst-case floor of 5 × 360 = 1,800 solves an hour. At the sub-0.5-second image ceiling, the same 5 threads is arithmetically enormous. Same plan, same price, wildly different capacity — because in a concurrency model the job duration is half the product.
This is why "unlimited" is not marketing fluff in a thread-based plan, and also not the bargain it first appears. It is unlimited in the dimension the vendor doesn't pay for (total volume) and strictly limited in the dimension they do (simultaneous work). Model the limited dimension; ignore the unlimited one.
The eight questions to ask before you buy
Concurrency plans differ in ways price pages rarely spell out. Get answers in writing:
- What exactly occupies a thread? Submission only, or submission through result retrieval? The second is longer and it is the one that matters.
- What happens at the ceiling — queue or reject? Queuing degrades gracefully; a hard rejection means your code needs a retry path on day one.
- How long is the queue allowed to get? An unbounded queue is a latency problem disguised as a capacity feature.
- Do retries occupy a thread? If a failed job re-enters the pool, your effective concurrency is lower than the number on the invoice.
- Is there a burst allowance? Some vendors permit short overshoot. That can be worth a whole tier.
- How granular is the upgrade path? Jumping 5 → 50 threads because there is nothing in between is a real cost, not a rounding error.
- Is latency covered by an SLA, or only uptime? In a concurrency model, latency is capacity. An uptime SLA alone doesn't protect the thing you bought.
- Can you observe utilization? If the dashboard doesn't show threads in use over time, you cannot right-size at renewal.
Where teams get it wrong
Over-buying on volume. "We do two million jobs a month, so we need the biggest plan." Run the formula: two million monthly jobs at two seconds each is roughly 1.5 concurrent jobs. The entry tier is likely correct and the difference is a few hundred dollars a month for nothing.
Under-buying on average. The mirror image. Average demand fits in three threads, so three threads it is — and every Monday morning batch run silently queues for twenty minutes. Nobody files a ticket because nothing errors; the work just arrives late, which is harder to diagnose than a failure.
Ignoring job duration. Two vendors quote the same thread count at the same price, but one's worst-case job takes six times longer. You are not buying threads, you are buying threads × speed. A vendor that publishes per-type ceilings, as CaptchaAI does, is giving you the second half of the equation; one that publishes only "fast" is asking you to guess.
Forgetting the trial is not the peak. Free trials are run at leisure by one engineer. Reproduce your actual peak during evaluation — replay a busy hour of real job arrivals — or the plan you pick will be sized for the calmest workload you will ever run. The general trial discipline in how to choose business software applies here with one addition: for concurrency pricing, the trial must include a load spike or it has proved nothing.
FAQ
Is "unlimited per thread" ever a trick? Not usually a trick, but it is a redirection. The vendor caps you on simultaneity instead of volume. Read the concurrency number and the per-job latency; those two set your real ceiling, and "unlimited" describes the dimension that was never going to bind you.
How do I estimate peak if I haven't launched yet? Take your best guess at monthly volume, assume the busiest hour carries 5–10% of a day's traffic, and apply the formula to that hour. Then buy the smallest plan that covers it and confirm the upgrade path is self-service. Over-buying pre-launch is the most avoidable software waste there is.
Should I model cost per job to compare against a per-call vendor? Yes — divide the monthly plan price by the jobs you realistically expect, and compare that against the metered vendor's per-call rate at the same volume. Concurrency pricing usually wins as volume grows and loses badly at low, spiky volume where you pay for idle lanes.
Is a low entry price a quality signal, one way or the other? No. In a concurrency model a low entry tier mostly tells you the vendor wants small workloads on the platform. Judge quality on published SLAs, documented latency ceilings, observable utilization, and whether support answers a technical question properly — not on the shape of the price ladder.
Next step
Do the arithmetic before you open a price page: busiest-hour jobs, average duration, resulting concurrency, plus one tier of headroom. Then hold vendor plans against that single number. If a CAPTCHA-solving API is the concurrency-priced tool in front of you, check CaptchaAI's published tiers and solve-time ceilings against your peak figure and start on the smallest plan that clears it — a thread-based model is one of the few where starting small and measuring costs you nothing but a plan change.
