Cloudflare's new bot engine withholds the clean yes-or-no that automated probes feed on

Determinism is the property this post attacks, and it pays to be precise about what the word is doing. Cloudflare defines it as the same input always producing the same output ^[3]. That is also the property that makes a WAF operable: you replay the request, you get the same verdict, you know what changed. The company's complaint is that automated probes get that same clean yes or no, and over enough attempts the answers map the edges of the system ^[4].

Both readings are true at once, and that is the interesting part. The feedback channel Cloudflare wants to close is the one your on-call engineer uses at two in the morning when a customer's checkout is failing. If a detection engine keeps changing, a request scored as a bot at 03:00 may not score that way when you curl it at 09:00. That is by design.

So the acceptance test for this class of product is not accuracy in the abstract. Ask what artifact replaces the release note. Rule-based detection hands the attacker a stationary target, which is Cloudflare's objection to it ^[14], but a rule you can name is also a rule you can cite in a postmortem and diff before it lands. Cloudflare's own description of the alternative is a model that waits months while attackers iterate in days ^[18]. Continuous adaptation removes the wait and the diff together.

The scale claim is load-bearing in the argument. More than a trillion requests a day ^[5] is about 11.6 million per second, dividing by 86,400 ^[15], and that aggregate is the observation surface. For that visibility to transfer to your property, your traffic has to resemble the attacks it was learned on: low-rate requests spread across a large residential proxy network, each with a fresh address or fingerprint so no single source crosses a rate limit ^[6], moving through login and account-recovery flows ^[13]. If your bot problem is one scraper on one network hitting a price endpoint, the aggregate buys you less.

Then there are the two conditions Cloudflare says must hold at the same time ^[2]. The second, starving attackers of the feedback they use to adapt, is at least observable from outside; you can measure how much a probe learns. The first, that reacting costs the defender less than working around it costs the attacker, is a statement about Cloudflare's internal cost of adaptation, and no customer can audit it. What you can measure is your own false positive rate and how often you open a ticket to get a legitimate client unblocked. Cloudflare adds that it believes no other bot detection works this way ^[19], which is the kind of claim that ages at the speed of a competitor's blog post.

Credit where it is due: the post stops promising the wall holds. Its framing is that a determined attacker gets through, and the question is what happens then ^[8]. That is a more honest statement of the problem than most bot vendors publish. It also moves the thing you negotiate. The question becomes whether the vendor can tell you, after the fact, why a request scored the way it did, without handing that same answer to whoever sent it.