Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add j4flmao/agent-skills --skill rate-limitinggit clone --depth 1 https://github.com/j4flmao/agent-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/j4flmao/agent-skills/rate-limiting)<a href="https://agentmods.dev/skills/j4flmao/agent-skills/rate-limiting"><img src="https://agentmods.dev/badge/skills/j4flmao/agent-skills/rate-limiting/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/j4flmao/agent-skills/rate-limiting"><img src="https://agentmods.dev/badge/skills/j4flmao/agent-skills/rate-limiting.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00142 | $0.02593 |
| Opus 5.5 | $0.00057 | $0.01037 |
| Sonnet 5.5 | $0.00028 | $0.00519 |
| Haiku 4.5 | $0.00014 | $0.00259 |
Grade A, and why
rate-limiting scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 198 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Rate Limiting
Purpose
Protect services and enforce fair use by bounding how many requests (or how much cost) a client can consume per unit of time. Correct rate limiting needs the right algorithm, the right key (who is limited), the right enforcement point, and responses that let well-behaved clients back off.
Agent Protocol
Trigger
Exact user phrases: "rate limit", "rate limiting", "throttle requests", "token bucket", "leaky bucket", "sliding window", "429 too many requests", "API quota", "per-user limit", "distributed rate limiter", "Retry-After".
Input Context
- What is being protected (whole API, expensive endpoint, login, outbound calls to a third party).
- Identity available at enforcement time (API key, user ID, tenant, IP).
- Number of instances and shared stores (Redis), gateway in front (Envoy, NGINX, Kong, cloud gateway).
- Desired limits and burst tolerance.
Output Artifact
Limit policy table plus middleware/gateway code or config. No files unless requested.
Response Format
Scope: {endpoint/group} Key: {api_key | user_id | tenant | ip}
Algorithm: {token bucket | sliding window counter | fixed window | GCRA}
Limit: {N} per {window}, burst {B}
Store: {in-memory | Redis (Lua, atomic) | gateway}
On limit: 429 + Retry-After {s} + RateLimit headers
Fail mode if store down: {open | closed}
Algorithms
| Algorithm | Behaviour | Memory/key | Bursts | Notes |
|---|---|---|---|---|
| Fixed window counter | INCR per window, reset at boundary |
1 counter | Up to 2x limit across a boundary | Simplest; fine for coarse quotas (per day) |
| Sliding window log | Store each request timestamp | O(limit) | Exact | Precise but memory-heavy |
| Sliding window counter | Weighted current + previous window counts | 2 counters | Approximate, smooth | Good default for "N per minute" APIs |
| Token bucket | Tokens refill at rate r up to capacity b; request spends tokens | 2 values | Allows bursts up to b | Best when bursts are acceptable; supports variable cost |
| Leaky bucket (queue) | Requests drain at fixed rate | Queue | Smooths output | NGINX limit_req is leaky-bucket based |
| GCRA | Token-bucket-equivalent using one timestamp (theoretical arrival time) | 1 value | Configurable | Used by redis-cell and several gateways |
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- references/algorithms.md 5.6 KB
- references/backpressure.md 6.0 KB
- references/distributed-rate-limiting.md 4.6 KB
- references/implementation-patterns.md 4.7 KB
- references/rate-limiting-api-gateway.md 3.2 KB
- references/rate-limiting-implementations.md 5.9 KB
- references/rate-limiting-monitoring.md 3.4 KB
- references/rate-limiting-queuing.md 4.3 KB
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday Changed · +75 lines · +121 tokens per session b440bbe37167
- 1mo ago First seen · 123 lines · 21 tokens per session scan A 563026c2c961
rate-limiting is a skill published in the GitHub repository j4flmao/agent-skills (35 stars, last pushed yesterday), licensed MIT. It adds 142 tokens to every session and 2,593 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
implementing-api-rate-limiting-and-throttling
Implements API rate limiting and throttling controls using token bucket, sliding window, and fixed window algorithms to protect against brute force attacks, credential stuffing, resource exhaustion, and API abuse. The engineer configures per-user, per-IP, and per-endpoint rate limits using Redis-backed counters, API…
api-rate-limiting-throttling-expert
Token bucket, sliding window, and Redis-based rate limiting for API protection. Activate on: rate limiting, throttling, token bucket, sliding window, API abuse, DDoS protection, quota management. NOT for: API gateway setup (use api-gateway-reverse-proxy-expert), caching (use cache-strategy-invalidation-expert).
implementing-api-rate-limiting-and-throttling
Implements API rate limiting and throttling controls using token bucket, sliding window, and fixed window algorithms to protect against brute force attacks, credential stuffing, resource exhaustion, and API abuse. The engineer configures per-user, per-IP, and per-endpoint rate limits using Redis-backed counters, API…
implementing-api-rate-limiting-and-throttling
Implements API rate limiting and throttling controls using token bucket, sliding window, and fixed window algorithms to protect against brute force attacks, credential stuffing, resource exhaustion, and API abuse. The engineer configures per-user, per-IP, and per-endpoint rate limits using Redis-backed counters, API…
API Rate Limiting Testing
Testing API rate limiting implementations including throttling behavior, burst handling, rate limit headers, and distributed rate limiting patterns.
api-rate-limit-handler
Implement bounded, idempotency-aware API throttling, backoff, and retry handling for 429 and transient 5xx responses.