This package delegates the challenge to Peak
The name sounds like a local Cloudflare exploit. The code is much simpler: it extracts a public Turnstile sitekey, builds a JSON request, and sends that request to Peak's solver API. A successful response contains a cf-turnstile-response token. The package returns that token through Python or prints it from a command line interface.
That distinction matters for both reliability and permission. Your program does not solve the challenge by itself, and this repository does not contain Peak's solver. A real run depends on the vendor accepting the task, returning a token before it expires, and producing a result that the target accepts. The README describes CI and QA use, but the same mechanism can defeat a site's anti-bot control. Use it only on workflows you own or have permission to test.
A 336-line client keeps the local side small
The repository is 14 files, roughly 336 lines of source, and 0.5 MB checked out. Its main module uses Python's standard library for HTTP, JSON, argument parsing, retries, and regular expressions. The package metadata declares no runtime dependencies and supports Python 3.8 through 3.13. That is attractive compared with carrying a browser and matching driver into a CI image.
Small does not mean self-contained. bypass_turnstile posts the sitekey and target URL to https://api.peak.fo/solve; optional proxy, action, and cdata values go into the same payload. The API key is sent in an X-API-Key header. Teams should treat those fields as third-party disclosures, read Peak's current terms, and avoid placing unrelated secrets in target URLs or proxy strings.
What happened when we ran it
Our unprivileged Python 3.12 sandbox installed commit 42adace in 19 seconds. The environment pulled 36 packages and occupied 37 MB, then the package built successfully in 4 seconds. Pytest finished in 7 seconds with 11 passed and 0 failed. Pip-audit reported 0 known vulnerabilities.
Those 11 tests cover sitekey extraction, action extraction, payload construction, missing credentials, successful and failed API responses, one-call token creation, version output, and the default CLI discovery path. The remote calls are mocked in the test file. Since our sandbox had no secrets, it did not ask Peak for a token or submit one to Cloudflare. No conclusion about solve rate, latency, token acceptance, or billing follows from this run.
The distinction is easy to miss because every measured step is green. We verified that the local wrapper installs, builds, and behaves as its unit tests expect. The service behind the wrapper remains an external dependency. Before relying on it, run an authorized staging case, record error behavior, set a spending limit, and decide what your test should do when the solver is unavailable.
Static HTML discovery misses browser-only widgets
find_sitekey looks for data-sitekey, sitekey=, or render= patterns in supplied HTML. If no HTML is supplied, read_page fetches the URL with urllib and decodes the response. There is no JavaScript runtime. A site that constructs its widget only after scripts execute may therefore leave nothing for this client to match, despite the README saying bundle-source patterns are supported.
The regex also returns the first matching candidate. That is adequate for a simple page with one widget. A page with several keys, conditional scripts, or unrelated text containing the same pattern needs extra selection logic. The library exposes find_action, but its one-call path only forwards the first discovered action and does not verify that the sitekey and action came from the same widget.
One code path deserves another test. When the file runs through python -m with --sitekey, main calls the create_token alias before the file assigns that alias below its if __name__ == "__main__" block. The installed console entry point imports the module first and avoids that ordering problem, but direct module execution can hit it. The 11-test suite covers the discovery CLI path, not this branch.
Cloudflare test keys are better for first-party QA
Cloudflare publishes test sitekeys and secret keys that return defined outcomes on any domain. Its visible widget key ending in AA always passes, while the key ending in BB always blocks. Dummy tokens also let server-side Siteverify tests cover success and failure without a solver account. For most teams testing their own form, those fixtures are the clean answer.
A solver becomes relevant only when an authorized test must exercise behavior closer to a production challenge. Even then, keep it in a separate staging job, never a general crawler. Store the Peak key in a secret manager, restrict target hosts in your wrapper, and log task IDs rather than response tokens. This package has no built-in allowlist or spend control, so those guardrails belong to the caller.
The repository is active but too young for star-based trust
The project was created on September 8, 2026 and pushed on September 30. GitHub showed 624 stars, 41 forks, and 0 open issues or pull requests on October 1. There was no GitHub release, Dockerfile, or CI workflow. The pyproject and changelog identify version 1.0.1, which fixes argument forwarding in the default CLI discovery path.
A clean issue queue in a three-week-old project says little about field use. The README's advertisement offering paid placement in GitHub's top search results also weakens stars as a buying signal, though it does not prove how this repository gained them. Judge the 336 lines yourself, test the Peak dependency on an authorized staging target, and prefer Cloudflare's own fixtures whenever they cover the case.