Key takeaways
- Kasada splits its token family in two: x-kpsdk-ct is minted once per session, x-kpsdk-cd is single-use and must be regenerated for every single request.
- That asymmetry is the whole story. On Cloudflare you can clear one challenge and reuse the cookie for thousands of requests. On Kasada the per-request half has to come back out of the VM each time.
- The challenge script runs inside its own obfuscated JavaScript virtual machine and computes a proof-of-work whose difficulty Kasada controls — so they can raise your cost per page without changing a single detection rule.
- A protected endpoint typically answers 429 until the script has run. A 429 on Kasada is not rate limiting and retrying with backoff makes it worse.
- We did not include Kasada in our April 2026 benchmark. The reason is in this post, and so is what to measure instead of a pass rate.
Kasada is not harder than Cloudflare because it detects better. It is harder because of how it issues tokens.
Every other major vendor lets you pay for access once and spend it many times. Clear a Cloudflare challenge and the cf_clearance cookie carries that verdict across thousands of cheap requests. Kasada splits the credential in two, and makes one half single-use. That design decision — not the fingerprinting, not the obfuscation — is what sets the cost per page.
Choose Before You Read
| Your situation | Do this |
|---|---|
| You are getting 429 on every request and adding backoff | Stop. 429 does not mean rate limited here |
| You cleared the challenge once and reuse broke anyway | Expected. The ct/cd split |
| You are budgeting a Kasada target | Why fan-out fails — it changes the arithmetic |
| Your patched browser is detected and you cannot see why | CDP and runtime traces |
| You want a pass-rate number to plan against | We do not have one, and here is why |
| You want the rows, not a token pipeline | Skip to the last section |
Confirm It Is Kasada in Thirty Seconds
The signatures are distinctive, and worth checking because the correct response is close to the opposite of the Cloudflare one.
x-kpsdk-ctandx-kpsdk-cdrequest headers — the clearest tell. KPSDK is Kasada's client SDK- A challenge script, usually served as
ips.jsorp.js— heavily obfuscated, and it does not look like ordinary minified JavaScript - HTTP 429 on the protected endpoint before the script has run — this is the one that misleads people
- No interstitial, no checkbox, no visible widget — Kasada generally does not show you anything
That 429 deserves its own warning. In almost every other context 429 means too many requests and the correct response is exponential backoff. Here it means you have not presented a valid token yet. Backing off and retrying the same tokenless request produces the same 429 forever, more slowly, while looking exactly like a rate-limit problem in your logs. Teams lose days to this.
If you see _abck instead, that is Akamai. cf_clearance or a cf-ray header is Cloudflare. __ddg is DataDome. _px is PerimeterX.
The Token Family, and Which One Costs You
Kasada ships a small family of headers. They are not interchangeable and the distinction is the entire engineering problem.
| Header | What it carries | Lifetime |
|---|---|---|
x-kpsdk-ct |
The client token, minted from the device fingerprint and the initial proof-of-work | Reusable for the session — commonly around thirty minutes |
x-kpsdk-cd |
The client data, carrying the proof-of-work answer | Single use, regenerated per request |
x-kpsdk-st |
The server timestamp the client must echo back | Per session |
x-kpsdk-v |
The SDK version pin | Per deployment |
x-kpsdk-h |
Binds ct and cd together |
Per request |
The challenge script fetches, then runs inside its own JavaScript virtual machine — a custom interpreter executing obfuscated bytecode, rather than JavaScript the browser executes directly. Inside that VM it fingerprints the device and computes a proof-of-work: a hashing puzzle whose difficulty Kasada sets server-side.
Two consequences follow from that last clause, and they are the ones that matter commercially.
They can raise your cost without changing anything you can observe. Proof-of-work difficulty is a dial. Turn it up and every scraper's CPU bill rises while every real browser pays an imperceptible few milliseconds. No detection rule changed, no fingerprint got better, nothing in your logs looks different except that pages got slower.
The VM is the product. Reimplementing the token generation means reimplementing the interpreter and keeping up with the obfuscation, which changes. That is why the public solver market for Kasada is a subscription market rather than a library market.
If you want to see the shape of that in one link: the open-source kpsdk-solver repository has an open, unresolved issue reporting that window.KPSDK.configure is no longer a function, and the repository itself was archived read-only in June 2025 with the breakage still there. The SDK moved, the free implementation did not, and that is the normal end state for a library pinned to someone else's obfuscated client.
A walkthrough against a real Kasada-protected target. Watch how much of the work happens before a single page of content is requested — that ratio is the thing to notice.
Why "Solve Once and Fan Out" Fails Here
This is the section worth the read, because it is where Kasada budgets go wrong.
On Cloudflare, the economically correct pattern is: pay for one expensive browser session, take the cf_clearance cookie, and run the remaining thousands of requests through a cheap TLS-impersonating HTTP client such as curl_cffi. One expensive unit amortised across a large crawl. We wrote that pattern up here.
On Kasada, half of that works. x-kpsdk-ct genuinely is reusable for the session — you mint it once. But x-kpsdk-cd carries a fresh proof-of-work answer and is consumed on use. Every request needs a new one, and a new one means the VM runs again.
So the arithmetic inverts:
| Cloudflare | Kasada | |
|---|---|---|
| Expensive step | Once per session | Once per session (ct) plus once per request (cd) |
| Cheap requests after that | Thousands | Zero, unless you can produce cd outside a browser |
| What amortisation buys you | Nearly everything | Only the session setup |
If you cannot generate cd outside the VM, your cost per page is a VM execution per page, and the fleet has to be sized as though every page were a challenge. That is a different capacity model from every other vendor on this list, and it is why a Kasada target that "works in testing" can be unaffordable at catalogue scale. The failure is not technical. It is arithmetic that nobody did at the start.
The honest planning question for a Kasada target is therefore not can we get in. It is what is our cost per thousand pages, and does the data justify it — and that question has an answer before you write any code.
What Gets Caught: CDP, Patched Runtimes, Timing
If you are running a browser at it, the detection surface is specific.
DevTools Protocol traces. Kasada probes for the side effects of a runtime being driven over CDP. This is the same class of leak that Patchright exists to close, and the reason vanilla Playwright and Puppeteer are detected immediately. CDP-Patches and rebrowser-patches address parts of it from different angles.
Patched runtimes, detected as patched. Anything that fixes a property by redefining it after load is visible: a rewritten property descriptor does not look like a native one. This is the structural argument for engine-level patching such as Camoufox, which changes behaviour in the C++ build rather than in page JavaScript.
Timing. The VM observes how long its own execution takes. A headless environment with no GPU, no compositor and no real paint timing produces a profile that a laptop does not. This is the layer where "I fixed the fingerprint and it still fails" usually lives.
TLS, still, underneath all of it. The JA3/JA4 handshake is read before any of the above runs. Getting the token right while presenting a Python TLS fingerprint is a wasted token.
Why Kasada Is Not in Our Benchmark Table
We published measured pass rates for six approaches against Cloudflare, Akamai Bot Manager v4 and PerimeterX, run over 500 requests each in April 2026. Kasada is not in it, and we would rather say why than quietly extend the table.
A pass rate against Kasada is not a stable number the way it is for the others. Proof-of-work difficulty is configurable per deployment and adjustable server-side at any time. Two Kasada-protected sites can present materially different costs with identical tooling, and the same site can change overnight without any observable signal. A single percentage would imply a generality that is not there.
Our six approaches do not span the relevant axis. The question on Kasada is not which stealth browser scores best — it is whether you can produce a valid per-request token at all, and at what CPU cost. Benchmarking stealth libraries against it would measure the wrong variable and report it confidently.
Plenty of guides do publish a Kasada number. Before you plan against one, ask which deployment it was measured on and what the difficulty was set to that day. Usually neither is stated, which tells you what the number is worth.
What to measure instead, on your actual target: cost per thousand delivered pages, wall-clock seconds per page including token generation, and whether the rate holds for a week. Those three are real, they are yours, and they answer the only question that matters.
What This Costs to Keep Alive
Kasada is the most expensive of the major vendors to self-serve against, and the cost is structural rather than incidental. A browser (or a VM runner) per request means the infrastructure line scales with pages, not with sessions. The maintenance line is driven by obfuscation changes you do not control and will not be warned about.
Realistically there are three positions:
- Run a browser per request. Correct, slow, and priced accordingly. Viable for low-volume, high-value targets.
- Buy token generation as a service. Moves the maintenance burden but puts a per-request third-party cost into your critical path, with its own uptime.
- Decide the target is not worth it. A legitimate answer, and more often right than people expect. If the pages behind Kasada are a small share of your catalogue coverage, the honest move is to source that share differently or drop it.
If what you need is competitor prices and stock levels arriving in your systems rather than a token pipeline to keep alive, the Kasada question is the wrong one to be answering. ScrapeWise runs the browsers, the proxies and the anti-bot escalation and delivers structured rows, with each page fetched plain first and escalated only when it is refused. No plan and no compute units: a balance you top up, and a published charge per delivered page — EUR 0.15 per 1,000 for plain requests, EUR 0.75 with rendering, EUR 1.50 through the residential tier and EUR 3.75 for render plus residential. New accounts get 5 free requests and the balance never expires.
You can also call ready-made scraping API endpoints directly, or see how this feeds competitor price tracking.
So What Should You Run?
- An engine-patched browser, one session, token-aware — the only DIY shape that is honest about the per-request cost. Pin the SDK version you have working and watch for
x-kpsdk-vchanging. - A fingerprint check before anything else — TLS and IP tier are read before the VM runs. Fixing them second is wasted work.
- Never exponential backoff on a Kasada 429 — it is not rate limiting, and the retry makes the log harder to read, not the problem smaller.
- A cost-per-thousand-pages estimate before the first line of code — on this vendor specifically, the arithmetic decides the project.
- None of the above — you want delivered rows on a schedule and would rather not run a VM per page to get them.
Kasada sits at one end of a spectrum. For the rest of it, see how to bypass Cloudflare, Akamai and PerimeterX, or see pricing.
Paste any URL — ScrapeWise handles the anti-bot
Managed infrastructure that adapts when sites change. No proxies, no code, no per-request fees.
Not ready to sign up? See 12 real Amazon rows, 972 columns →
97% accuracy on Amazon benchmarks · no credit card · book a 15-min call →