Test results

Cloudflare Rate Limit Design: test results

Tested 2026-10-08, skill version 1.0.0 at the time of loading this page. We run every skill on a strong and a weak model before it is listed, and publish both verdicts, including where the weak one fails.

Verdicts

Date
2026-10-08
Strong · claude-sonnet-5-5 (Claude Code alias "sonnet")
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.
Weak · claude-haiku-5-5 (Claude Code alias "haiku")
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.

With and without the skill

Tested 2026-10-08.

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.

Note

Twenty-one rate-limiting setups written by us (15 with a planted fault, 6 sound): free-plan rules, a Workers binding, own counters in D1, a test plan, and a rule against one attacker. Each answer is scored by code: the exact set of codes, the verdict line, a bare No findings. for sound setups, no fence. Facts re-checked in the vendor documentation on 2026-10-08: the free plan has one address-only rule with a 10-second window; the binding takes a period of 10 or 60, counts per location and is eventually consistent. Owner-measured on 2026-09-10 and NOT re-checked: the refusal of the address, network-number and header-names fields, the shared outbound address of Workers, and the per-isolate counts. The no-skill checks were widened after the run to accept every phrasing of the same point (a shared pool of addresses, blocking the address directly, a field the plan refuses). One run per model and setup.

What was not measured

  • Models other than the two named above were not run.
  • Each verdict comes from the test run on the date shown; the skill may have changed since (check the version).
  • Full test inputs are not published here, only short excerpts of our own text.
  • Results on your own texts, languages and domains can differ.

Back to Cloudflare Rate Limit Design · Card (JSON)