AISkills402Connect your agent

Code & Engineering

Cloudflare Rate Limit Design

Reviews a rate-limiting setup on Cloudflare (a WAF rate limiting rule, a Workers Rate Limiting binding, or a counter in your own code) and lists every reason it will not limit what its author thinks it limits. It flags free-plan rules that use the client address or a header field, which the plan refuses, windows the plan does not offer, an address key for callers that are themselves Workers and share one outbound address, a binding number treated as a global figure when each isolate counts for itself, a raw IPv6 address as a key, per-client limits with no global ceiling on a costly action, load tests fired without waiting a full window, one known attacker handled with a rule instead of an IP Access Rule, and a 429 without Retry-After. Each finding has a fixed code, the place, the reason and a fix, then one verdict. Use to check or design rate limiting for an API, a pay endpoint or an agent-facing endpoint on Cloudflare.

Cloudflare Rate Limit Design is a tested SKILL.md that reviews a rate-limiting setup on Cloudflare (a WAF rate limiting rule, a Workers Rate Limiting binding, or a counter in your own code) and lists every reason it will not limit what its author thinks it limits; an agent buys it once for $0.03 over x402.

Tested 2026-10-08No code, no hidden instructionsv1.0.0 · 9.8 KB · perpetual license

Not for

Tuning numbers for your traffic, plans other than the one in the paste, and anything that needs the live zone: it reads pasted rules, binding config, code and test plans. Not bot management, Turnstile or DDoS settings. Facts dated 2026-10-08; this vendor changes monthly; the free-plan refusals and per-isolate counts are owner-measured 2026-09-10, not re-checked.

Tested, honestly

Tested 2026-10-08 with a strong and a weak model.

With and without the skill

Results with and without the skill, for Sonnet and Haiku
SonnetHaiku
withwithoutwithwithout
Setups reviewed right (21 setups)21/2119/2120/2113/21

Same request on both sides; the bare side is scored on the concept in any words, with a fence removed first. Read by hand, Sonnet without the skill already knew the shared outbound address of Workers, the 10-second free-plan window, the per-location counting of the binding and blocking one attacker directly. It missed two measured facts: on a free-plan rule it kept an address condition (even in its own corrected rule), and it called a header-names condition workable, though the free plan refuses both at deploy (owner-measured 2026-09-10, not re-checked). Haiku without the skill missed eight setups, the same kinds of facts: the free-plan refusals, the 10-second window, the shared address and per-isolate counting. Haiku with the skill still missed the raw IPv6 key once.

Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.

SonnetStrong model, claude-sonnet-5-5
Right on all 21 setups, read by hand: it named the free-plan refusal of the address condition and of the header-names condition, the single 10-second window, the shared outbound address of Workers callers, the per-isolate count of a binding (also when a cap of 5 was "raised" to 120), the raw IPv6 key, the missing global ceiling on a paid call, the second burst fired inside one window, the rate rule used against one address, and the 429 without Retry-After. It answered No findings. for all six sound setups and ignored a planted comment saying the rule was approved.
HaikuWeak model, claude-haiku-5-5
Right on 19 of 21 by the skill's own checks. It missed the raw IPv6 key in the agents counter (it gave only the shared address finding), and on a sound setup it answered No findings. but added a paragraph after it, which breaks the exact reply. Its extra warning there, that rejected calls still count against the shared budget, was a real weakness of our test code, not an error by Haiku; the five affected inputs were fixed and re-run with both models, and the numbers did not change. Everything else matched, including the free-plan refusals and the planted comment.

Full test summary

Example

Our own test text, before and after the skill ran. Excerpts only.

English · claude-sonnet-5-5

Before

Plan: Cloudflare free plan. Customers are people paying in a browser. WAF rate limiting rule "pay-limit", created in the dashboard: expression: http.request.uri.path eq "/api/pay" and ip.src ne 203.0.113.9 (that address is our office) counting characteristic: IP requests: 100 period: 60 seconds action: block for 60 seconds

After

[FREE-IP-EXPR] rule "pay-limit": the expression uses ip.src, which the free plan refuses at deploy with a "not entitled" message, so the rule is not deployed as written (and the free plan counts by address only, so the office exemption cannot be expressed).…

What is in the file

  • The answer
  • The codes
  • Rules
  • Work in this order
  • Short example
  • When this was checked

Languages

Any language. Tried in: English.

License

Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.

Versions

Current version 1.0.0, updated 2026-10-08. Whoever bought an earlier version gets new ones free through the same re-download token.

  1. v1.0.0 · 2026-10-08

    First release: reviews a Cloudflare rate-limiting setup (WAF rule, Workers Rate Limiting binding, own counter, test plan) and lists, with fixed codes and a verdict, why it will not limit what its author expects. Nine codes: FREE-IP-EXPR, WINDOW-10S, SHARED-EGRESS, PER-ISOLATE, RAW-IPV6, NO-GLOBAL-CAP, MEASURE-PAUSE, WRONG-TOOL, NO-RETRY-AFTER.

    Facts re-checked on 2026-10-08 by read-only fetch of the vendor's documentation: free plan has 1 rule, IP counting, 10 s counting period, 10 s block, no counting-expression fields; vendor says rate rules are approximate with a delay of a few seconds; the Workers binding takes period 10 or 60, keeps a limit per Cloudflare location with counters cached on the machine running the Worker, is permissive and eventually consistent, and advises against IP keys; IP Access Rules exist on all plans.

    Not re-checked (owner-measured 2026-09-10, no account actions allowed this day): the "not entitled" refusal of ip.src, ip.geoip.asnum and the header-names field; the shared outbound address of Workers; the per-isolate counts (cap 120 never fired at 140 concurrent, cap 5 passed 4 of 20); the leftover-window measurement.

    Dropped on purpose: the owner's note that edge counting is "exact" (cap 20 with 60 concurrent gave "6 passed", which the same note later explains as the previous burst's leftover window; only cap 5 with 12 requests, 5 passed and 7 blocked, supports it, and the vendor says counting is approximate). The skill teaches calibration instead.

    Tests: 21 cases (15 traps, 6 controls) generated by test/make-cases.mjs; test/control.mjs shows the checks pass the ideal answer and fail a missing code, an extra code, a wrong verdict, a fence and the input itself. Model runs and the no-skill baseline are not done yet.

    Model run (2026-10-08, one run per model and setup): Sonnet 21 of 21 with the skill, 19 of 21 without (gain: 2 setups, both owner-measured facts: the free plan refuses an address condition and a header-names condition). Haiku 20 of 21 with, 13 of 21 without. The no-skill checks were widened after reading the bare answers (shared pool of addresses, blocking the address directly, "refuses"); two cases (a pay path with a per-address rule only) now accept a NO-GLOBAL-CAP finding because that finding is defensible there. Flaw found in the run and fixed afterwards: in five inputs the shared counter was incremented before the per-key check, so rejected calls used the shared budget (Haiku noticed). Those five inputs now check the per-key row first and bump the shared row only after it passes; they are re-run.

    Price: 0.03 USD (30000 micro). Sonnet's gain stayed under 3 setups, so the 0.05 start price was not kept.

FAQ

Which mistakes does the review cover?

Nine reasons a limiter does not limit: free-plan rules using the client address or a header field, windows the plan does not offer, an address key for callers that share one outbound address, a binding number read as a global figure, a raw IPv6 key, no global ceiling on a costly action, load tests fired without waiting a window, a rate rule used against one known address, and a 429 without a retry hint. The verdict line says whether the setup does not limit as intended, partly limits, or limits as intended, so a pipeline can stop a deploy on the first.

Why would a rule by path not work on the free plan?

The free plan counts by address only and offers one 10-second window and one 10-second block. We measured on 2026-09-10 that the address, network-number and header-names fields are refused at deploy, so a path rule cannot tell a paid request from a page view, and one request a second never trips it. Sustained abuse, scraping at a polite pace or a slow credential guess, needs a counter in your own code or storage instead.

Does it help Claude Sonnet?

Modestly. Without the skill Sonnet got 19 of 21 setups right, with it 21 of 21. It already knew the shared outbound address of Workers, the 10-second free-plan window and per-location counting. It missed two measured facts: it kept an address condition in a free-plan rule and called a header-names condition workable, though the free plan refuses both at deploy (owner-measured 2026-09-10, not re-checked). Haiku went from 13 to 20 of 21.

Will it flag a setup that is fine, and can it replace a load test?

Paste the rule as text, the binding entry and the handler, and say your plan and who calls. A free-plan burst rule that is openly a burst damper, a binding next to a shared counter, a key by API key and an IP Access Rule for one known address all get No findings. It cannot replace a load test: it names the reasons a test would mislead you, such as bursts fired inside one window. A human reviewer still owns the decision.

Share

Read this page as Markdown: /skills/cf-rate-limit-design.md.

More skills

  • Workers Pitfalls Review: D1, OpenNext, Fetch

    Code & Engineering

    SKILL.md · v1.2.0 · 9.8 KB

    Reviews pasted Cloudflare Workers code and configuration (a Worker, a Next.js app on OpenNext, D1 queries, wrangler config) for platform pitfalls that pass every local test and then fail in production or quietly cost money. It flags the edge runtime under OpenNext, a fetch to your own Worker's workers.dev address (error 1042), D1 queries that bind more than 100 parameters as data grows, LIKE patterns over D1's 50-byte limit, reading rowsAffected where D1 returns meta.changes, interactive transactions D1 does not have, secrets kept in plain vars, outbound fetch code that treats only a thrown error as failure, a browser User-Agent that bot protection challenges, client hop-by-hop headers forwarded to fetch, cron triggers whose day of the week is written as numbers, and unbounded queries on the request path. Each finding has a fixed code, the place, the reason and a fix, then one verdict. Use to review a Cloudflare Worker before deploy, check D1 or wrangler code, or audit a Next.js app running on Cloudflare.

    $0.05once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 8 Oct 2026

  • Bill Spike Finder

    Code & Engineering

    SKILL.md · v1.0.0 · 15.9 KB

    Finds the loops behind a bill spike or an unexpected bill. Reviews a web app's code and config for loops and repeats that run up the bill on their own on Vercel, Turso, Cloudflare Workers and D1 and paid AI APIs. Finds two schedulers on one job, retries without a cap, work that triggers itself, client polling and React render loops, caches cleared on every write, middleware running on every static file, queues that resend failures forever, image settings that multiply transformations, health checks that count whole tables, alerts sent on every run and bots crawling endless filter URLs. Counts the runs per month, names the billed unit, ranks by cost and gives the change that stops each one. Use when asked why a Vercel, Turso or Cloudflare bill jumped, to find an infinite loop or a runaway cost, or to review a cron job, webhook, queue consumer, middleware or polling code before it ships.

    $0.05once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 4 Oct 2026

  • Search Console Next Action

    SEO & Content

    SKILL.md · v1.0.0 · 8.0 KB

    Takes one situation from Google Search Console - a report row, a status, a URL with the way it answers, or a button the site owner is about to press - and returns the single right next action as JSON with a fixed action code, a reason and steps. Knows the cases where the obvious click is wrong - a URL that redirects gets Validate fix and never Request indexing, which creates a Redirect error; a Domain property needs the full sitemap address; Couldn't fetch right after submitting is proven with a live test; a red robots.txt row for a host that answers 404 needs nothing; a missing max-image-preview setting keeps pages out of Discover; Disallow does not remove a page from Google; a redirect added over a cached 404 needs the cache purged. Use when asked what to do about a Search Console report, error or warning, whether to request indexing, validate a fix or resubmit a sitemap, or why a page is not indexed.

    $0.05once

    • x402
    • USDC
    • Base
    Get skill

    Tested with Sonnet and Haiku, 8 Oct 2026