Batch results leave out the identity you need to reuse them
Call Solver.batch() and you get a token for each successful URL. You don't get its cookies, headers, or browser fingerprint. That matters because captcha-api's own README says a follow-up request needs the identity that earned the token. The individual challenge() and turnstile() methods return that information. The batch shortcut discards it. For an integration built around Cloudflare clearance, this is the difference between collecting results and being able to use them.
The project is small enough to inspect: our checkout contained 16 files and about 1,187 source lines, occupying 0.3 MB. Its main module wraps Clearance's hosted API with a Python interface and command-line tool. The MIT license covers that client code. It doesn't give you a local captcha-solving service. You'll still need a Clearance account, an API credential, and an integration that handles the returned identity correctly.
What happened when we ran it
Our sandbox installed commit b817110 in 34 seconds, adding 36 packages and occupying 38 MB. The build succeeded in 4 seconds. Pytest finished in 6 seconds with 36 passed and 0 failed. Pip-audit reported 0 known vulnerabilities. Our measurement setup was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets, on October 14, 2026.
Those results establish that the measured checkout installs, builds, and passes its available checks in that environment. They don't establish Clearance's live solve speed or whether a token clears a particular website. The repository describes its suite as offline and replaces network transport with fakes. The README's advertised solve times therefore remain vendor claims. We wouldn't use them to size a production job or promise a customer a response deadline.
The Python install leaves the hosted service outside your control
The 38 MB environment we measured is a modest local commitment. Configuration is also short: Solver.from_env() reads CLEARANCE_API_KEY, and the CLI accepts an explicit credential. A Challenge request needs a page URL. Turnstile needs a sitekey too, which the individual helper can attempt to extract from page HTML. That extraction uses patterns in fetched text, so don't expect it to execute a page's JavaScript.
The README's response and identity section makes the expensive integration step clear. Receiving a cookie is only part of the job. Your subsequent HTTP client must reproduce the supplied headers and browser identity, including TLS and HTTP/2 settings. The example leaves that transport configuration to you. If your application uses an ordinary HTTP client without fingerprint controls, budget engineering work beyond the quick-start call.
Cost estimates are local arithmetic, not a spending limit
Our 36 passing tests don't turn estimate_cost() into a billing control. The function multiplies a requested count by a price constant in the module. CostTracker accumulates local successes and failures, while _result() leaves the result's cost at its dataclass default instead of reading a charged amount from the service response. These are useful estimates if the assumptions hold. They aren't an account ledger reconciled against actual charges.
There's another accounting wrinkle in the source at the measured commit. Batch failures call the tracker's failure recorder, but a failed individual solve() raises before recording that failure. An operator expecting the summary to represent every attempted request would miss those individual errors. Keep your own attempt log and spending controls if money reporting is the reason you're choosing this wrapper.
Batch convenience requires a narrower use case
The 0.3 MB checkout includes a thread-pool batch helper that catches API errors per URL and returns results in input order. That's handy when a batch contains an occasional bad target: the other results can still come back. However, its result dictionary keeps only the URL, success flag, token, and elapsed value. It drops the richer Result object. The README's promise about replaying an identity and its batch example deserve to be read together.
I'd use the individual methods when the downstream request needs cookies or fingerprint data. I'd also pass known sitekeys explicitly for mixed workflows: the batch function calls solve() directly, bypassing the individual Turnstile helper's HTML discovery. This is manageable code to adapt, but it makes the batch interface a poor default for someone expecting a complete fetch-and-clear pipeline. The wrapper submits work and polls results. It doesn't perform the final application request.
September activity offers little evidence of outside use
The last push was September 25, 2026. GitHub showed 261 stars and 0 open issues and PRs, and the recent all-state issue listing was empty. The latest-release endpoint returned no release. A changelog describes versions, but that's different from a published GitHub release. Recent source activity argues against calling the project abandoned. The empty discussion record also gives us little evidence about independent deployment experience.
Our scan found 0 CI workflow files and no Dockerfile, although a tests directory exists. Choose captcha-api for a readable Clearance integration you can own and adjust. Choose 2Captcha's Python client or Anti-Captcha's official library when you need those providers or their broader captcha coverage. If you adopt this one for batches, preserve the full result before relying on the token: the information you need is already present in the individual response.