[{"data":1,"prerenderedAt":99},["ShallowReactive",2],{"$flfOflGPahPaPlmTgeymyR1f2k2TxbaeP0_-nVYJ7lcs":3},{"title":4,"date":5,"dateModified":6,"datePublished":7,"dateModifiedISO":7,"image":8,"content":9,"faq":10,"metaTitle":39,"metaDescription":40,"author":41,"authorBio":6,"authorLinkedin":6,"authorTitle":6,"authorPhoto":42,"lastReviewed":6,"noindex":43,"researchBasis":6,"category":44,"readingTime":45,"related":46,"prev":63,"next":66,"toc":67,"takeaways":93},"Bypassing Kasada in 2026: The Token Economics Nobody Prices In","20 Oct 2026",null,"2026-10-20","/img/news/bypass-kasada-bot-protection-2026.png","\u003Cp>\u003Cstrong>Kasada is not harder than Cloudflare because it detects better. It is harder because of how it issues tokens.\u003C/strong>\u003C/p>\n\u003Cp>Every other major vendor lets you pay for access once and spend it many times. Clear a Cloudflare challenge and the \u003Ccode>cf_clearance\u003C/code> 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.\u003C/p>\n\u003Ch2 id=\"choose-before-you-read\">Choose Before You Read\u003C/h2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Your situation\u003C/th>\n\u003Cth>Do this\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>You are getting 429 on every request and adding backoff\u003C/td>\n\u003Ctd>Stop. \u003Ca href=\"#confirm-it-is-kasada-in-thirty-seconds\">429 does not mean rate limited here\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>You cleared the challenge once and reuse broke anyway\u003C/td>\n\u003Ctd>Expected. \u003Ca href=\"#the-token-family-and-which-one-costs-you\">The ct/cd split\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>You are budgeting a Kasada target\u003C/td>\n\u003Ctd>\u003Ca href=\"#why-solve-once-and-fan-out-fails-here\">Why fan-out fails\u003C/a> — it changes the arithmetic\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Your patched browser is detected and you cannot see why\u003C/td>\n\u003Ctd>\u003Ca href=\"#what-gets-caught-cdp-patched-runtimes-timing\">CDP and runtime traces\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>You want a pass-rate number to plan against\u003C/td>\n\u003Ctd>\u003Ca href=\"#why-kasada-is-not-in-our-benchmark-table\">We do not have one, and here is why\u003C/a>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>You want the rows, not a token pipeline\u003C/td>\n\u003Ctd>\u003Ca href=\"#what-this-costs-to-keep-alive\">Skip to the last section\u003C/a>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Caside class=\"article__usecase-card\">\u003Cdiv class=\"article__usecase-label\">Related use case\u003C/div>\u003Ch3 class=\"article__usecase-title\">Any-site data scraper\u003C/h3>\u003Cp class=\"article__usecase-blurb\">No-code extraction from any website. Managed infrastructure, no anti-bot headaches.\u003C/p>\u003Ca class=\"article__usecase-link\" href=\"/use-cases/data-scraper\">See how it works →\u003C/a>\u003C/aside>\u003Ch2 id=\"confirm-it-is-kasada-in-thirty-seconds\">Confirm It Is Kasada in Thirty Seconds\u003C/h2>\n\u003Cp>The signatures are distinctive, and worth checking because the correct response is close to the opposite of the Cloudflare one.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ccode>x-kpsdk-ct\u003C/code> and \u003Ccode>x-kpsdk-cd\u003C/code> request headers\u003C/strong> — the clearest tell. KPSDK is Kasada's client SDK\u003C/li>\n\u003Cli>\u003Cstrong>A challenge script, usually served as \u003Ccode>ips.js\u003C/code> or \u003Ccode>p.js\u003C/code>\u003C/strong> — heavily obfuscated, and it does not look like ordinary minified JavaScript\u003C/li>\n\u003Cli>\u003Cstrong>HTTP 429 on the protected endpoint before the script has run\u003C/strong> — this is the one that misleads people\u003C/li>\n\u003Cli>\u003Cstrong>No interstitial, no checkbox, no visible widget\u003C/strong> — Kasada generally does not show you anything\u003C/li>\n\u003C/ul>\n\u003Cp>That 429 deserves its own warning. In almost every other context \u003Ca href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429\">429 means too many requests\u003C/a> and the correct response is exponential backoff. Here it means \u003Cem>you have not presented a valid token yet\u003C/em>. 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.\u003C/p>\n\u003Cp>If you see \u003Ccode>_abck\u003C/code> instead, that is \u003Ca href=\"/blogs/bypass-akamai-bot-manager-web-scraping-2026\">Akamai\u003C/a>. \u003Ccode>cf_clearance\u003C/code> or a \u003Ccode>cf-ray\u003C/code> header is \u003Ca href=\"/blogs/bypass-cloudflare-turnstile-web-scraping-2026\">Cloudflare\u003C/a>. \u003Ccode>__ddg\u003C/code> is \u003Ca href=\"/blogs/bypass-datadome-web-scraping-2026\">DataDome\u003C/a>. \u003Ccode>_px\u003C/code> is \u003Ca href=\"/blogs/bypass-perimeterx-human-web-scraping-2026\">PerimeterX\u003C/a>.\u003C/p>\n\u003Ch2 id=\"the-token-family-and-which-one-costs-you\">The Token Family, and Which One Costs You\u003C/h2>\n\u003Cp>\u003Ca href=\"https://www.kasada.io/\">Kasada\u003C/a> ships a small family of headers. They are not interchangeable and the distinction is the entire engineering problem.\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Header\u003C/th>\n\u003Cth>What it carries\u003C/th>\n\u003Cth>Lifetime\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Ccode>x-kpsdk-ct\u003C/code>\u003C/td>\n\u003Ctd>The client token, minted from the device fingerprint and the initial proof-of-work\u003C/td>\n\u003Ctd>Reusable for the session — commonly around thirty minutes\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>x-kpsdk-cd\u003C/code>\u003C/td>\n\u003Ctd>The client data, carrying the proof-of-work answer\u003C/td>\n\u003Ctd>\u003Cstrong>Single use, regenerated per request\u003C/strong>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>x-kpsdk-st\u003C/code>\u003C/td>\n\u003Ctd>The server timestamp the client must echo back\u003C/td>\n\u003Ctd>Per session\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>x-kpsdk-v\u003C/code>\u003C/td>\n\u003Ctd>The SDK version pin\u003C/td>\n\u003Ctd>Per deployment\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>x-kpsdk-h\u003C/code>\u003C/td>\n\u003Ctd>Binds \u003Ccode>ct\u003C/code> and \u003Ccode>cd\u003C/code> together\u003C/td>\n\u003Ctd>Per request\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>The challenge script fetches, then runs inside its \u003Cstrong>own JavaScript virtual machine\u003C/strong> — 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.\u003C/p>\n\u003Cp>Two consequences follow from that last clause, and they are the ones that matter commercially.\u003C/p>\n\u003Cp>\u003Cstrong>They can raise your cost without changing anything you can observe.\u003C/strong> 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.\u003C/p>\n\u003Cp>\u003Cstrong>The VM is the product.\u003C/strong> 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.\u003C/p>\n\u003Cp>If you want to see the shape of that in one link: the open-source \u003Ccode>kpsdk-solver\u003C/code> repository has an \u003Ca href=\"https://github.com/0x6a69616e/kpsdk-solver/issues/20\">open, unresolved issue reporting that \u003Ccode>window.KPSDK.configure\u003C/code> is no longer a function\u003C/a>, 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.\u003C/p>\n\u003Cdiv class=\"video-embed\">\u003Ciframe src=\"https://www.youtube-nocookie.com/embed/M66XyjY51Cs\" title=\"How To Bypass Kasada in 2025 And Scrape WizzAir\" loading=\"lazy\" allowfullscreen>\u003C/iframe>\u003C/div>\n\n\u003Cp>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.\u003C/p>\n\u003Caside class=\"article__inline-cta\">\u003Cp class=\"article__inline-cta-text\">Try ScrapeWise on your own URL. \u003Cstrong>Your first 5 requests are free.\u003C/strong>\u003C/p>\u003Ca class=\"article__inline-cta-btn\" href=\"https://portal.scrapewise.ai/register\" target=\"_blank\" rel=\"noopener\">Start Free →\u003C/a>\u003C/aside>\u003Ch2 id=\"why-quotsolve-once-and-fan-outquot-fails-here\">Why "Solve Once and Fan Out" Fails Here\u003C/h2>\n\u003Cp>This is the section worth the read, because it is where Kasada budgets go wrong.\u003C/p>\n\u003Cp>On Cloudflare, the economically correct pattern is: pay for one expensive browser session, take the \u003Ccode>cf_clearance\u003C/code> cookie, and run the remaining thousands of requests through a cheap TLS-impersonating HTTP client such as \u003Ca href=\"https://pypi.org/project/curl-cffi/\">curl_cffi\u003C/a>. One expensive unit amortised across a large crawl. We \u003Ca href=\"/blogs/bypass-cloudflare-turnstile-web-scraping-2026\">wrote that pattern up here\u003C/a>.\u003C/p>\n\u003Cp>On Kasada, half of that works. \u003Ccode>x-kpsdk-ct\u003C/code> genuinely is reusable for the session — you mint it once. But \u003Ccode>x-kpsdk-cd\u003C/code> 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.\u003C/p>\n\u003Cp>So the arithmetic inverts:\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C/th>\n\u003Cth>Cloudflare\u003C/th>\n\u003Cth>Kasada\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Expensive step\u003C/td>\n\u003Ctd>Once per session\u003C/td>\n\u003Ctd>Once per session (\u003Ccode>ct\u003C/code>) \u003Cstrong>plus once per request\u003C/strong> (\u003Ccode>cd\u003C/code>)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Cheap requests after that\u003C/td>\n\u003Ctd>Thousands\u003C/td>\n\u003Ctd>Zero, unless you can produce \u003Ccode>cd\u003C/code> outside a browser\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>What amortisation buys you\u003C/td>\n\u003Ctd>Nearly everything\u003C/td>\n\u003Ctd>Only the session setup\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>If you cannot generate \u003Ccode>cd\u003C/code> 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.\u003C/p>\n\u003Cp>The honest planning question for a Kasada target is therefore not \u003Cem>can we get in\u003C/em>. It is \u003Cstrong>what is our cost per thousand pages, and does the data justify it\u003C/strong> — and that question has an answer before you write any code.\u003C/p>\n\u003Ch2 id=\"what-gets-caught-cdp-patched-runtimes-timing\">What Gets Caught: CDP, Patched Runtimes, Timing\u003C/h2>\n\u003Cp>If you are running a browser at it, the detection surface is specific.\u003C/p>\n\u003Cp>\u003Cstrong>DevTools Protocol traces.\u003C/strong> Kasada probes for the side effects of a runtime being driven over CDP. This is the same class of leak that \u003Ca href=\"/blogs/what-is-patchright-guide-2026\">Patchright\u003C/a> exists to close, and the reason vanilla Playwright and Puppeteer are detected immediately. \u003Ca href=\"https://github.com/Kaliiiiiiiiii-Vinyzu/CDP-Patches\">CDP-Patches\u003C/a> and \u003Ca href=\"https://github.com/rebrowser/rebrowser-patches\">rebrowser-patches\u003C/a> address parts of it from different angles.\u003C/p>\n\u003Cp>\u003Cstrong>Patched runtimes, detected as patched.\u003C/strong> 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 \u003Ca href=\"/blogs/camoufox-vs-patchright-2026\">Camoufox\u003C/a>, which changes behaviour in the C++ build rather than in page JavaScript.\u003C/p>\n\u003Cp>\u003Cstrong>Timing.\u003C/strong> 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.\u003C/p>\n\u003Cp>\u003Cstrong>TLS, still, underneath all of it.\u003C/strong> The \u003Ca href=\"https://github.com/FoxIO-LLC/ja4\">JA3/JA4\u003C/a> handshake is read before any of the above runs. Getting the token right while presenting a Python TLS fingerprint is a wasted token.\u003C/p>\n\u003Ch2 id=\"why-kasada-is-not-in-our-benchmark-table\">Why Kasada Is Not in Our Benchmark Table\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>\u003Cstrong>A pass rate against Kasada is not a stable number the way it is for the others.\u003C/strong> 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.\u003C/p>\n\u003Cp>\u003Cstrong>Our six approaches do not span the relevant axis.\u003C/strong> 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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>What to measure instead, on your actual target: \u003Cstrong>cost per thousand delivered pages\u003C/strong>, 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.\u003C/p>\n\u003Ch2 id=\"what-this-costs-to-keep-alive\">What This Costs to Keep Alive\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>Realistically there are three positions:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Run a browser per request.\u003C/strong> Correct, slow, and priced accordingly. Viable for low-volume, high-value targets.\u003C/li>\n\u003Cli>\u003Cstrong>Buy token generation as a service.\u003C/strong> Moves the maintenance burden but puts a per-request third-party cost into your critical path, with its own uptime.\u003C/li>\n\u003Cli>\u003Cstrong>Decide the target is not worth it.\u003C/strong> 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.\u003C/li>\n\u003C/ul>\n\u003Cp>If what you need is \u003Cstrong>competitor prices and stock levels arriving in your systems\u003C/strong> rather than a token pipeline to keep alive, the Kasada question is the wrong one to be answering. \u003Ca href=\"/\">ScrapeWise\u003C/a> 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.\u003C/p>\n\u003Cp>You can also call \u003Ca href=\"/scrapers\">ready-made scraping API endpoints\u003C/a> directly, or see how this feeds \u003Ca href=\"/use-cases/competitor-price-tracking\">competitor price tracking\u003C/a>.\u003C/p>\n\u003Ch2 id=\"so-what-should-you-run\">So What Should You Run?\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>An engine-patched browser, one session, token-aware\u003C/strong> — the only DIY shape that is honest about the per-request cost. Pin the SDK version you have working and watch for \u003Ccode>x-kpsdk-v\u003C/code> changing.\u003C/li>\n\u003Cli>\u003Cstrong>A fingerprint check before anything else\u003C/strong> — TLS and IP tier are read before the VM runs. Fixing them second is wasted work.\u003C/li>\n\u003Cli>\u003Cstrong>Never exponential backoff on a Kasada 429\u003C/strong> — it is not rate limiting, and the retry makes the log harder to read, not the problem smaller.\u003C/li>\n\u003Cli>\u003Cstrong>A cost-per-thousand-pages estimate before the first line of code\u003C/strong> — on this vendor specifically, the arithmetic decides the project.\u003C/li>\n\u003Cli>\u003Cstrong>None of the above\u003C/strong> — you want delivered rows on a schedule and would rather not run a VM per page to get them.\u003C/li>\n\u003C/ul>\n\u003Cp>Kasada sits at one end of a spectrum. For the rest of it, see \u003Ca href=\"/blogs/bypass-cloudflare-akamai-perimeterx-web-scraping-2026\">how to bypass Cloudflare, Akamai and PerimeterX\u003C/a>, or \u003Ca href=\"/pricing\">see pricing\u003C/a>.\u003C/p>\n",{"title":11,"description":12,"badge":13,"benefits":14},"Frequently asked questions","How Kasada's x-kpsdk token family works, why the per-request half changes the cost model, and what to measure instead of a pass rate","FAQ",[15,18,21,24,27,30,33,36],{"title":16,"description":17},"How do you know a site is protected by Kasada?","The clearest signal is x-kpsdk-ct and x-kpsdk-cd request headers, since KPSDK is Kasada's client SDK. You will also see a heavily obfuscated challenge script, usually served as ips.js or p.js, which does not look like ordinary minified JavaScript. The protected endpoint typically returns HTTP 429 before that script has run. There is generally no interstitial page, no checkbox and no visible widget, which is part of why Kasada is often misidentified. By contrast, _abck means Akamai, cf_clearance or a cf-ray header means Cloudflare, __ddg means DataDome and _px means PerimeterX.",{"title":19,"description":20},"Why does Kasada return HTTP 429 and should I back off?","No, and this is the single most expensive misreading of Kasada. In almost every other context a 429 means too many requests and the correct response is exponential backoff. On Kasada it means you have not presented a valid token yet. Backing off and retrying the same tokenless request produces the same 429 forever, just more slowly, while looking exactly like a rate-limit problem in your logs and in your monitoring. Teams routinely lose days to this before realising the status code is being used to mean something else entirely.",{"title":22,"description":23},"What is the difference between x-kpsdk-ct and x-kpsdk-cd?","This distinction is the entire engineering problem. x-kpsdk-ct is the client token, minted once from the device fingerprint and the initial proof-of-work, and it is reusable for the life of the session, commonly around thirty minutes. x-kpsdk-cd is the client data, carrying the proof-of-work answer, and it is single-use and must be regenerated for every single request. The supporting headers are x-kpsdk-st for the server timestamp the client echoes back, x-kpsdk-v for the SDK version pin, and x-kpsdk-h which binds ct and cd together.",{"title":25,"description":26},"Why does solve-once-and-reuse not work on Kasada?","Because only half the credential is reusable. On Cloudflare the economically correct pattern is to pay for one expensive browser session, take the cf_clearance cookie, and run thousands of cheap requests through a TLS-impersonating HTTP client, amortising one expensive unit across a whole crawl. On Kasada, x-kpsdk-ct genuinely amortises that way, 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 virtual machine runs again. The practical result is that your cost per page is a VM execution per page, so the fleet must be sized as though every page were a challenge.",{"title":28,"description":29},"What is the Kasada proof-of-work and why does it matter commercially?","The challenge script runs inside its own JavaScript virtual machine, a custom interpreter executing obfuscated bytecode rather than JavaScript the browser runs directly. Inside that VM it fingerprints the device and computes a proof-of-work: a hashing puzzle whose difficulty Kasada sets server-side. That last part is the commercially important one. Difficulty is a dial they can turn, so they can raise your CPU cost per page without changing any detection rule and without anything in your logs looking different, while a real browser pays an imperceptible few milliseconds.",{"title":31,"description":32},"What does Kasada detect in a patched browser?","Four layers, and they are checked in a specific order. The TLS handshake, read as a JA3 or JA4 fingerprint before any script runs, so a correct token presented over a Python TLS fingerprint is a wasted token. DevTools Protocol traces, the same class of leak that Patchright, CDP-Patches and rebrowser-patches exist to close, which is why vanilla Playwright and Puppeteer are caught immediately. Patched runtimes detected as patched, because a property redefined after load does not look native. And execution timing, since a headless environment with no GPU, no compositor and no real paint timing produces a profile a laptop does not.",{"title":34,"description":35},"What is the measured pass rate against Kasada?","We do not publish one, and we would rather explain that than quietly extend our benchmark table. A pass rate against Kasada is not a stable number the way it is for Cloudflare or Akamai, because 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 with no observable signal. Plenty of guides do publish a figure; before planning against one, ask which deployment it was measured on and what the difficulty was that day. Usually neither is stated.",{"title":37,"description":38},"What should you measure on a Kasada target instead?","Three things, all of which are specific to your own target and none of which depend on anyone else's benchmark. Cost per thousand delivered pages, including the CPU time spent generating tokens. Wall-clock seconds per page end to end, again including token generation rather than just the content fetch. And whether that rate holds for a full week rather than for one afternoon of testing. On this vendor specifically the arithmetic decides the project, so the estimate belongs before the first line of code rather than after the first invoice.","Bypass Kasada 2026: The x-kpsdk Token Problem","Kasada mints x-kpsdk-ct once per session, but x-kpsdk-cd is single-use, per request. That asymmetry is why solve-once-and-fan-out fails here.","Siim Brazier","/img/team/siim.jpg",false,"Scraping",9,[47,52,58],{"slug":48,"title":49,"image":50,"date":5,"category":44,"excerpt":51},"bypass-cloudflare-turnstile-web-scraping-2026","Cloudflare Turnstile and Web Scraping: What Actually Clears It (2026)","/img/news/bypass-cloudflare-turnstile-web-scraping-2026.png","Turnstile is a score you earn before the widget renders, not a puzzle. Measured pass rates, the 42-second cost, and why cookie reuse beats a solver.",{"slug":53,"title":54,"image":55,"date":56,"category":44,"excerpt":57},"curl-cffi-tls-fingerprint-web-scraping-2026","curl_cffi and TLS Fingerprint Impersonation for Web Scraping (2026)","/img/news/curl-cffi-tls-fingerprint-web-scraping-2026.png","13 Oct 2026","Your requests call is blocked before any JavaScript runs, because its TLS handshake is not a browser's. What JA3/JA4 is, how curl_cffi fixes it, measured pass rates, and the four cases where it cannot help.",{"slug":59,"title":60,"image":61,"date":56,"category":44,"excerpt":62},"playwright-akamai-bot-manager-2026","Playwright vs Akamai Bot Manager: Why the Browser Is the Wrong Layer (2026)","/img/news/playwright-akamai-bot-manager-2026.png","Vanilla Playwright does not clear Akamai Bot Manager v4. Patched Playwright reaches 74% on residential proxies. A plain HTTP client reaches 87% for a quarter of the compute. The measurements and the reason.",{"slug":64,"title":65},"camoufox-alternatives-2026","Camoufox Alternatives in 2026: 5 Options and the Licence Nobody Checks",{"slug":48,"title":49},[68,72,75,78,81,84,87,90],{"level":69,"text":70,"id":71},2,"Choose Before You Read","choose-before-you-read",{"level":69,"text":73,"id":74},"Confirm It Is Kasada in Thirty Seconds","confirm-it-is-kasada-in-thirty-seconds",{"level":69,"text":76,"id":77},"The Token Family, and Which One Costs You","the-token-family-and-which-one-costs-you",{"level":69,"text":79,"id":80},"Why "Solve Once and Fan Out" Fails Here","why-quotsolve-once-and-fan-outquot-fails-here",{"level":69,"text":82,"id":83},"What Gets Caught: CDP, Patched Runtimes, Timing","what-gets-caught-cdp-patched-runtimes-timing",{"level":69,"text":85,"id":86},"Why Kasada Is Not in Our Benchmark Table","why-kasada-is-not-in-our-benchmark-table",{"level":69,"text":88,"id":89},"What This Costs to Keep Alive","what-this-costs-to-keep-alive",{"level":69,"text":91,"id":92},"So What Should You Run?","so-what-should-you-run",[94,95,96,97,98],"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.",1792524068773]