Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →chunkydotdev/rate-limiting
Implement email rate limiting and volume controls that protect sender reputation.
Passed 19 of 23 test cases with the skill, and 15 of 23 without it.
and 1 more in the full report
4 fixed15 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
When designing an email sending rate limiter, we are debating whether to use a single daily limit or add an hourly limit. What failure mode does an hourly limit specifically guard against?
| Checked | Without skill | With skill |
|---|---|---|
| Identifies hourly limits as a defense against infinite loops or runaway software bugs | Missed | Passed |
The instructions your model reads when the skill loads.
Volume controls that protect your sender reputation from runaway sends, ISP throttling, and agent-driven spikes.
bounce-handling - processing the soft bounces that result from ISP throttlingemail-warmup - ramping volume on new domains/IPs (rate limiting during warmup is critical)sender-reputation - understanding the reputation signals that rate limiting protectssender-monitoring - dashboards and alerts for catching rate limit issues earlysuppression-lists - managing bounces and complaints that compound rate limit problemsSender reputation does not degrade linearly. It cliff-drops. A sudden spike in outbound volume - whether from a bug, a batch job, or an AI agent stuck in a retry loop - triggers automated defenses at mailbox providers that can take weeks to recover from. During that recovery window, even your legitimate human-sent email lands in spam.
Gmail, Microsoft, and Yahoo track engagement per sender domain across rolling time windows. A sudden volume spike with no corresponding engagement history reads as a spam blast, regardless of your intent. The sequence is predictable: soft filtering first (messages land in spam), then hard reputation damage (messages get rejected), then potential blocklisting.
Rate limiting is the infrastructure that prevents this. It converts an unbounded sending surface into a predictable, reputation-safe operating envelope.
Effective email rate limiting requires enforcement across multiple time horizons. A single "messages per hour" limit is not enough because different time windows protect against different failure modes.
test cases passed, vs 15 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.