Claude Code can write your edge WAF rules. It cannot pick the thresholds.

Partly. Claude Code is excellent at writing the rule expressions in Cloudflare wirefilter, the Fastly VCL clauses, and the Worker code that wraps a managed ruleset. It is also genuinely useful for generating test traffic, validating that a rule fires, and producing a Terraform or wrangler config you can review. What it cannot do for you is pick the thresholds. A per-IP rate limit on /api/cart, a JS challenge cutoff for high-risk countries, and the bot-score line below which to outright block versus challenge are decisions that need real traffic from your site. The agent does not have your last 30 days of access logs and should not guess. The right division of labor is: agent writes the expression, human picks the number, agent writes the test that proves the number does what you intended.

On Free you get unlimited Layer 3 and Layer 4 DDoS mitigation, Bot Fight Mode (the simple version), 5 custom WAF rules, basic rate limiting at modest thresholds, and access to the Free managed ruleset. On Pro ($25/mo per zone as of 2026-05-07) you get the Cloudflare Managed Ruleset, more custom rules, Super Bot Fight Mode with stronger bot scoring, page rules, and image optimization. On Business and Enterprise you unlock the OWASP managed ruleset, custom certificates, Argo, and the higher rate-limit ceilings. For most c0nsl SMB clients the right starting point is Pro plus 6 to 10 carefully scoped custom rules, which lands well inside the published $500 to $2,000 small-integration tier on this site.

Wirefilter is Cloudflare's expression language for matching HTTP requests. An expression like (http.request.uri.path matches "^/api/" and ip.src.country in {"CN" "RU" "KP"} and cf.bot_management.score lt 30) is the kind of clause Claude Code will produce in seconds, with the right operators and the right field names from the official docs. The reason it is safe to delegate is that wirefilter is a closed, documented language with no arbitrary code execution. A wrong expression either fails validation in the Cloudflare UI or matches the wrong traffic. It cannot escape the rule engine. The bigger risk is not the language, it is the threshold inside the expression: cf.bot_management.score lt 30 versus lt 10 is the difference between blocking some bots and blocking your own marketing analytics tag.

First, the per-IP rate limit on hot endpoints. /api/cart, /api/login, /search, and /webhook each have a different normal request rate, and the wrong limit either lets a credential-stuffing attack through or breaks a legitimate user who clicks fast. Second, the country-level challenge cutoff. Issuing a JS challenge to traffic from a long tail of countries you do not serve is almost free; issuing a managed challenge to traffic from your second-biggest customer market is a conversion incident. Third, the bot-score block-versus-challenge line. Cloudflare's bot management score runs 1 to 99. A site that depends on aggregator scrapers (price comparison, search engines that respect robots.txt, partner integrations) wants to challenge below 30 and only block below 5. A site that has zero legitimate bot traffic can block aggressively under 30. None of these three numbers comes out of a documentation page.

It depends on what you write. Anthropic has published the user-agent strings and IP ranges its crawlers use; ClaudeBot identifies itself in user-agent and respects robots.txt. If you write a custom rule that matches user-agents containing 'bot' or that blocks all traffic with a low Cloudflare bot score, you can absolutely catch ClaudeBot in the net along with everything else. The right pattern, if you want AI assistants to be able to read your public pages, is to allowlist named user-agents (ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot, etc.) before any general bot rule, then block or challenge below the bot-score line. If you do not want them, you also have to write that rule explicitly; the default Cloudflare ruleset does not block named AI crawlers for you.

On a real engagement it goes like this. Pull the last 30 days of access logs from Cloudflare or whatever edge sits in front of your origin. Have Claude Code parse the log shape, surface the top URIs by request count, the top source countries, and the bot-score distribution. Ask it to draft 6 to 10 wirefilter rules from a written specification you give it (the human-picked thresholds), each in a single comment-annotated block. Run them in log mode for 24 hours. Read the action log. Promote the rules that fire on real attack traffic to challenge or block, lower the threshold on the ones that fire too often, drop the ones that produce false positives. Claude Code is in the loop for the first and third step; the human picks the numbers in step two and reads the result in step four.

Vercel's firewall is a thin layer over the Next.js platform with built-in DDoS mitigation included on Pro and Enterprise. It is the right choice if your origin is Vercel and your team would not configure Cloudflare correctly anyway. Fastly's Next-Gen WAF (formerly Signal Sciences) is a different shape: it observes traffic at the edge and feeds a request-scoring model that can run in front of Vercel, Cloudflare, or your own VCL service. It is the right choice for higher-traffic SaaS where you also want signal back into a SOC. For a 5 to 15 person SMB without a security team, Cloudflare's free or Pro tier covers the realistic threat model and is what fits the small-integration retainer band. The decision is mostly about where your origin already is and how much custom telemetry you want, not about WAF features in the abstract.

If you are starting from a Cloudflare zone with no custom rules, a documented goal (block credential stuffing on /api/login, mitigate scraping on /search, allow AI assistants on public pages, challenge anomalous traffic from countries outside your customer base), and 30 days of logs to look at, the work fits the published $500 to $2,000 small-integration tier on c0nsl.com. The deliverable is a written ruleset, the wrangler or Terraform config that deploys it, a 24-hour log-mode run with the rules disabled, a reading of the action log, and a final promote-or-tune session. If your stack also requires custom Workers code, multi-zone alignment, a Fastly VCL component, or a SOC-style alerting wire-up, that is a different shape and lands closer to the $2,000 to $10,000+ custom system tier. The rate is on the page, no rate-card games.

Three failure modes show up on every engagement. First, it overfits to recent log lines and writes a rule that protects against last week's specific attack but not against the obvious next variant. The fix is to keep the rule expressions general (path prefix plus risk signal, not a literal CVE-style regex). Second, it under-allows known-good bots. If you do not give it an explicit allowlist of user-agents you want indexing your site, it will treat all bots the same and your search-engine traffic suffers a week later. Third, it picks round-number thresholds (60 requests per minute, score lt 30) that look reasonable but are not anchored in your real traffic. The fix is to feed it the actual percentiles from your logs and have it write the rule from those numbers, not from priors.

Mostly yes. If your site is static, has no auth, no /api endpoints behind it, and no inventory of real value (a directory, a price feed, an email list), Cloudflare's Free tier with Bot Fight Mode on is a fine answer and you should not pay anyone to write 10 wirefilter rules for you. The work in this guide is for sites where there is something to protect: a login, a cart, a tenant-request form, a booking endpoint, a search index that costs money to serve, or an API that competitors would scrape. If you are unsure which side of the line you are on, the $75 consult on the homepage is the cheapest way to find out without a months-long discovery.