Version 1.0.1 is a Peak API client, not a local solver
Cloudflare Turnstile Solver 1.0.1 is one Python module with two jobs. It scans HTML for a sitekey and optional action, then posts those values and the page URL to api.peak.fo. The service response supplies the token. An optional proxy and cdata value can travel in the same payload. There is no browser engine, challenge model, or local token-generation implementation in the repository.
That boundary should decide adoption. The package is small because Peak performs the difficult part. You need a Peak API key, network access to its endpoint, and an approved reason for sending it details about the protected page. If a proxy contains a username and password, those credentials also enter the third-party request. Review Peak's terms, data handling, retention, and service reliability before placing this wrapper in a company test pipeline.
What happened when we ran it
Our sandbox installed commit cd81428 in 85 seconds, pulling 36 packages and using 37 MB on disk. The build passed in 10 seconds. Pip-audit reported 0 known vulnerabilities. The container had 3 CPUs, 8 GB of RAM, Python 3.12, no secrets, and no elevated privileges.
No test script or target existed, so the test step was skipped. The checkout contained 11 files, about 288 lines of source, and occupied 0.5 MB. Our scan found no CI workflow, Dockerfile, or tests directory. Those results prove that the package can be installed and built in the lab image. They do not establish that the Peak service returns a token, that a site accepts it, or that retries behave correctly.
The 36 installed packages also need context. pyproject.toml declares zero runtime dependencies, while the lab environment still installed 36 packages during its full setup. The supplied measurement does not divide those into build, packaging, and audit tools. A deployed wheel may be lighter than the measured environment, but the 37 MB figure is the reproducible number from our run.
The documented --url command crashes before any request
The README's first example calls the module with --url. At commit cd81428, main() sends api_url=None into token_for_page(), whose signature does not accept an api_url keyword. We ran that path with a placeholder key and an invalid example domain. Python stopped immediately with TypeError: token_for_page() got an unexpected keyword argument 'api_url', before page fetching or API contact.
Supplying --sitekey selects a different branch that calls create_token() directly, so the signature mismatch is confined to automatic page discovery through the CLI. The Python API does not pass that extra argument when users call token_for_page() themselves. Even so, the broken path is the one featured in the quick start and the default route for anyone following the documentation. A project with no test suite missed its most visible command.
Sitekey discovery is regex-based and intentionally narrow
The module uses 2 regular expressions to find data-sitekey, a sitekey or render assignment, and an optional data-action. That can work for server-rendered markup with recognizable strings. It does not run JavaScript, wait for a widget, or inspect a browser DOM after client-side rendering. Passing HTML directly can avoid a fetch, but the discovery rules remain the same.
The page reader uses Python's standard URL opener with a fixed package user agent and a 30-second timeout. It does not expose request headers, cookies, authentication, or browser state. Teams testing a private staging page will probably supply HTML themselves or use another tool for page access. The project description's phrase “any page” is wider than the implementation supports.
Retry logic covers transport failures, not every bad result
create_token() defaults to 3 attempts and waits longer after each transport exception. A successful HTTP response whose JSON says success is false raises immediately, as does a response missing data.token. The result object retains the raw service response alongside the token and sitekey. That is enough for a thin wrapper, but there are no tests showing malformed JSON, HTTP error bodies, timeouts, or retry limits.
Tokens are short-lived and tied to page context, according to the README. The package does not verify a token with your site's server secret; it only returns what Peak supplies. For a site you control, the meaningful end-to-end test still includes your backend's Turnstile verification, expected action and hostname checks, and the business operation protected by the form.
Zero open items do not replace a release or tests
GitHub showed 313 stars, 0 open issues and pull requests, and a last push on September 15, 2026. The repository has no tagged release even though pyproject.toml declares version 1.0.1. With no issue history in the API response, there is little public evidence of how failures are reported, triaged, or fixed.
The MIT license covers the wrapper, while the operational dependency remains a commercial API advertised throughout the README. That makes this project closer to a vendor client than an independent Turnstile tool. For authorized QA on your own application, begin with Cloudflare's documented test keys and server-side verification. Adopt this package only after fixing the CLI, adding tests around every public function, and deciding that sending page and proxy data to Peak fits your security policy.