← Back to Blog

Cloudflare Precursor: Bot Detection Now Monitors Entire Sessions

On July 13, 2026, Cloudflare began rolling out Precursor: instead of a one-time check at the entrance β€” continuous behavior analysis throughout the entire session. Let's analyze what signals it collects, why refreshing the page no longer resets the signature, and what this changes for scraping, multi-accounting, and AI agents.

πŸ“…July 27, 2026
Cloudflare Precursor: Bot Detection Now Monitors Entire Sessions

On July 13, 2026, Cloudflare began rolling out to all clients Precursor β€” a client engine that evaluates not individual requests or captcha passes, but behavior throughout the entire session. The wording from Cloudflare's CTO, Dane Knecht, is short and precise: "Instead of just checking an ID at the gate, we are looking at behavior over the entire visit."

For those automating browsers β€” scrapers, multi-accounting, SMM automation, AI agents β€” this marks a shift in the unit of risk measurement. Previously, the unit was a request: pass the challenge, receive cf_clearance, and you’re good to go. Now, the unit is a session, which lives on, accumulates evaluation, and can "degrade" at any moment after you have already passed the verification.

What exactly did Cloudflare launch

Precursor is a script that Cloudflare embeds into pages through its network. It can be toggled on in the panel (Security β†’ Settings β†’ Precursor), requires no changes to the site’s code, and works across the entire zone at once; specific behaviors can be adjusted through Precursor Rules. It is positioned not as a replacement for Turnstile, but as a complement to it: Turnstile is a one-time check, while Precursor is continuous.

What the script collects, according to Cloudflare's own description:

  • mouse movement β€” trajectories, speed, arc characteristics;
  • scrolling rhythm;
  • typing cadence β€” timings and rhythm, but not the actual keystrokes;
  • clipboard activity;
  • focus shifts of elements and visibility of the page/tab.

Then things get interesting. Cloudflare explicitly states that it is looking for not a "fingerprint," but the physics and physiology of a human: arcs of mouse movement, constrained by wrist rotation, instead of linear movements typical of automation; measurable cognitive delays between the appearance of a stimulus on the screen and the reaction; micro-tremors of the hand as natural noise in the trajectory.

The second layer β€” cross-checks for internal contradictions. Is the pointer moving while the page is hidden? Are keyboard events coming in, but no text field is in focus? Each signal individually looks normal, but together they do not form a coherent picture of a living person β€” and this is caught more cheaply than any analysis of a single click.

The third and most unpleasant aspect for automation: the evaluation accumulates over the session and is not reset by a page reload. The classic tactic of "got blocked β€” F5 / new tab" ceases to reset the state. The results of continuous verification update that same cf_clearance, and Cloudflare explicitly states that an already issued clearance confirmation can be reduced or revoked right in the middle of a session, as well as trigger an additional challenge.

Two modes β€” and why it’s important to know in advance

  1. Minimize Friction (default) β€” background checking without interstitials. The user sees nothing, but the guarantee of "session validity" is weaker.
  2. Maximize Security (recommended by Cloudflare) β€” a light interstitial challenge that establishes a valid session, with a conscious degradation of UX.

The practical takeaway: the protection behavior on a specific site now depends on the settings that you cannot see from the outside. The same script, the same proxy, and the same site may behave differently before and after the owner switches the mode. Triggers are visible to the site owner in Security β†’ Analytics β†’ Traffic β†’ Bot analysis β€” alongside bot score distribution and WAF matches.

Scale: why this is not "just another anti-bot"

The context that makes this news more significant than a typical release. Cloudflare processes over 1 trillion requests per day, and Turnstile operates nearly 3 billion times a day. According to the company’s estimates, automated traffic has for the first time surpassed human traffic and accounts for about 57% of all web requests. Enabling a behavioral layer with a single toggle on such a base means that the share of the internet where session behavioral detection operates could increase dramatically β€” without a single commit on the site’s side.

And the stated goal is precisely what is being utilized today: "advanced automation that executes JavaScript, operates in a real browser environment, and passes individual captchas without raising suspicion." In other words, Playwright/Puppeteer with stealth patches, anti-detect browsers, and agent browsers β€” exactly the target that Precursor describes openly.

For the sake of honesty: Cloudflare has not published quantitative data β€” neither accuracy, nor the rate of false positives, nor the overhead from continuous monitoring in the browser. For now, these are stated capabilities, not independently measured. There has also been no public wave of complaints about mass false blocks in the two weeks since the rollout.

What this means in practice

1. IP quality is no longer a "sufficient condition" β€” but remains necessary

The tempting conclusion that "since detection is behavioral, proxies no longer matter" is incorrect. Precursor works on top of the previous layers: IP reputation, TLS/HTTP fingerprinting, bot score. A data center IP from a flagged subnet receives a high bot score and strict challenge mode even before mouse analysis comes into play. Behavior is an additional exam, not a replacement for the entry filter: clean residential proxies or mobile proxies with a live ASN simply provide a chance to reach the second exam.

2. Session is the new hygiene object

Previously, the typical error sounded like "too many requests from one IP." Now it is joined by "too much non-human-like activity within a single session." Hence the practice:

  • Do not reuse one browser context for hundreds of tasks. A long session is a long behavior log, where any anomaly can accumulate. A shorter session means less material for scoring.
  • Keep the "session ↔ IP" pair stable. Changing the outgoing IP mid-session is a noticeable contradiction; for login scenarios, sticky sessions with a lifespan tailored to the task are needed, rather than aggressive rotation for every request.
  • Do not mix profiles. One account β€” one stable set: browser profile, IP, timezone, language, behavioral pattern.

3. Synthetic behavior will need to be more honest β€” or not done at all

Naive "human" emulations (linear movement to the center of the button, even pauses of 100 ms, instant clicks after loading) work against you under cross-checks: they add signal rather than remove it. If the scenario does not require human imitation β€” it is more reliable to not generate behavior at all than to generate poor behavior. We discussed this layer in detail in the article about behavioral biometrics and proxies.

4. API endpoints and non-browser clients β€” a separate story

Precursor requires JavaScript execution. Clients without a browser β€” curl, mobile backends β€” and XHR/fetch requests to protected endpoints must correctly carry session credentials, namely cf_clearance. Practically, this means: first, the browser establishes a valid session, and then "quick" requests go with its cookies and in the same network context (same IP, agreed TLS profile). A mismatch between the browser session and the HTTP client is the very internal contradiction they are looking for.

5. Data capture points are shifting

Where the site enables Maximize Security, cheap headless scraping will become noticeably more expensive. A reasonable response is not to escalate to "smart emulation" at any cost, but to reconsider the source: the official site API, partner feeds, mobile endpoints, public datasets. The fully browser-based route makes sense to keep where data cannot be obtained otherwise.

Where this is headed

Precursor logically fits into Cloudflare's trajectory over the past year: blocking AI crawlers by default, AI Crawl Control with granular rules, Pay Per Crawl as an attempt to monetize access to content, and starting September 15, 2026 β€” blocking mixed-use AI crawlers on pages with ads by default. The overall vector: the site wants to know not "are you a human at the moment of entry," but "who you are throughout the visit and why you came."

For the automation market, this means a slow but one-way shift: the cost of one "human-like" session is rising, and the cost of one request is no longer the primary metric. Those who collect less but more accurately will win: careful sessions, clean IPs tailored to the task, consistent fingerprints β€” and a sober assessment of what data is worth the browser path.

In short

  • As of July 13, 2026, Cloudflare is rolling out Precursor β€” a session behavioral detection that can be enabled with a single toggle without code changes on the site side.
  • Signals: pointer movement, scrolling, typing rhythm (without content), clipboard activity, focus, and visibility; plus cross-checks for contradictions.
  • Evaluation accumulates over the session; reloading the page does not reset the signature, and clearance can be revoked mid-visit.
  • Proxies have not "become irrelevant": the IP layer remains the entry filter, while behavior is a second exam.
  • Cloudflare has not yet published quantitative data on accuracy and false positives β€” it is too early to draw conclusions about the actual strictness.