A plausible token still needs acceptance by Cloudflare
Run turnstile-token verify and a plausible result means the string passed local formatting checks. The command doesn't ask Cloudflare whether the value is valid. That's a sensible tool for catching damaged shell output, but a dangerous name to read too quickly. The README explains the distinction. Anyone choosing this client should carry it into their application: successful polling, a plausible string, and an accepted form submission are separate outcomes.
Our checkout occupied 0.3 MB across 18 files and about 1,362 source lines. Most of the interesting work lives in a readable Python module: find a widget sitekey, submit a task to Clearance, poll for the result, and return the token alongside browser identity data. The MIT-licensed client is unofficial. Clearance provides the remote solving service, and installing this repository doesn't make that service local or independent of its operator.
What happened when we ran it
Our run installed commit 2e41b5d in 20 seconds, adding 36 packages and occupying 38 MB. The build passed in 3 seconds. Pytest passed in 3 seconds with 49 passed and 0 failed, and pip-audit reported 0 known vulnerabilities. The measurement setup was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets, on October 14, 2026.
The repository's test module says it replaces network calls with fakes. That makes the passing result useful for checking client behavior without buying solves or supplying a credential. It leaves live acceptance and provider availability outside this evidence. The README advertises service speed, but our sandbox didn't measure that speed. I'd judge a proposed deployment using representative permitted targets before treating the advertised turnaround as an application deadline.
Sitekey discovery reads HTML without running a browser
The measured 38 MB environment gets you the client, while useful solving needs a Clearance account and CLEARANCE_API_KEY. Supply a page URL and an explicit sitekey, or let solve() fetch the page and search its text. SitekeyScanner ranks attribute matches ahead of JavaScript-shaped and query-string matches. It also retains context snippets, which help you inspect a page containing multiple possible widgets instead of accepting an unexplained first match.
The scanner uses regular expressions on fetched HTML. It doesn't run JavaScript or inspect a live browser session. A widget configured only after scripts execute may therefore require a sitekey supplied by your application. The confidence values are fixed weights associated with match types, not measured probabilities that the selected widget is correct. Use the discovery command to inspect candidates, then pin the relevant key when your integration already knows it.
ReplayBundle helps package data but leaves transport configuration to you
Our 49 passing tests support the wrapper's local behavior, including its response handling. A successful library call returns ReplayBundle, which carries the token, headers, cookies, and an emulation block. replay_headers() supplies the returned User-Agent, and form_fields() packages the token under common form names. Those helpers save repetitive mapping code. They don't send the final request or configure an HTTP client's TLS settings.
The README's replay example leaves a comment where the TLS and HTTP/2 configuration should go. That's a consequential omission for anyone expecting a complete integration. The project supplies identity data and tells you to reproduce it, but the consuming transport remains your choice and responsibility. Keep that work in the adoption estimate rather than assuming that calling form_fields() finishes the browser-identity requirement described by the author.
The batch CLI discards the richer library result
The 18-file repository includes a file-based batch command, but its loop processes targets sequentially. Each successful output entry contains the URL, token, and success flag. It omits the headers, cookies, and emulation data held by the individual bundle. Even verbose output doesn't change that branch. If your downstream request needs those fields, the CLI's convenient JSON output is insufficient without modifying the code or calling the library yourself.
There's a proxy detail worth inspecting in the measured source. The constructor stores a proxy used by task-creation transport, while solve() puts its own method argument into the task payload. It doesn't fall back to the constructor value for that field. The README describes a constructor-level proxy as selecting the solving exit. If that exit matters, review the payload path and don't assume a global CLI proxy setting supplies it.
Recent source changes come with little public feedback
The last push was September 30, 2026. GitHub showed 175 stars and 0 open issues and PRs, with an empty recent all-state issue listing. The latest-release endpoint returned no release, although the changelog documents changes. This is recent source activity with little public deployment feedback to inspect. Neither the empty queue nor the lack of a GitHub release establishes that the code is dependable or abandoned.
Our scan found 0 CI workflow files and no Dockerfile, alongside a tests directory. I'd choose turnstile-token for a small Clearance-specific library integration where someone owns the final HTTP request and can inspect proxy handling. 2Captcha's Python client and Anti-Captcha's official library are alternatives when those services fit your requirements. Keep Cloudflare acceptance as an application outcome you observe separately: a locally plausible token is only permission to attempt the submission.