dvcrn/openclaw-skills-marketplace/rate-limiting
- community
Checking that the SKILL.md file is still in the repository.
Rate limiting algorithms, implementation strategies, HTTP conventions, tiered limits, distributed patterns, and client-side handling. Use when protecting APIs from abuse, implementing usage tiers, or configuring gateway-level throttling.
Install
npx vskill@latest install dvcrn/openclaw-skills-marketplace/rate-limitingSKILL.md
Rate Limiting Patterns
Algorithms
| Algorithm | Accuracy | Burst Handling | Best For | |
|---|---|---|---|---|
| Token Bucket | High | Allows controlled bursts | API rate limiting, traffic shaping | |
| Leaky Bucket | High | Smooths bursts entirely | Steady-rate processing, queues | |
| Fixed Window | Low | Allows edge bursts (2x) | Simple use cases, prototyping | |
| Sliding Window Log | Very High | Precise control | Strict compliance, billing-critical | |
| Sliding Window Counter | High | Good approximation | Production APIs — best tradeoff |
Fixed window problem: A user sends the full limit at 11:59 and again at 12:01, doubling the effective rate. Sliding window fixes this.
Token Bucket
Bucket holds tokens up to capacity. Tokens refill at a fixed rate. Each request consumes one.
Sliding Window Counter
Hybrid of fixed window and sliding window log — weights the previous window's count by overlap percentage:
Implementation Options
| Approach | Scope | Best For | |
|---|---|---|---|
| In-memory | Single server | Zero latency, no dependencies | |
Redis (INCR + EXPIRE) | Distributed | Multi-instance deployments | |
| API Gateway | Edge | No code, built-in dashboards | |
| Middleware | Per-service | Fine-grained per-user/endpoint control |
Use gateway-level limiting as outer defense + application-level for fine-grained control.
HTTP Headers
Always return rate limit info, even on successful requests:
| Header | When to Include | |
|---|---|---|
RateLimit-Limit | Every response | |
RateLimit-Remaining | Every response | |
RateLimit-Reset | Every response | |
Retry-After | 429 responses only |
429 Response Body
Never return 500 or 503 for rate limiting — 429 is the correct status code.
Rate Limit Tiers
Apply limits at multiple granularities:
| Scope | Key | Example Limit | Purpose | |
|---|---|---|---|---|
| Per-IP | Client IP | 100 req/min | Abuse prevention | |
| Per-User | User ID | 1000 req/hr | Fair usage | |
| Per-API-Key | API key | 5000 req/hr | Service-to-service | |
| Per-Endpoint | Route + key | 60 req/min on /search | Protect expensive ops |
Tiered pricing:
| Tier | Rate Limit | Burst | Cost | |
|---|---|---|---|---|
| Free | 100 req/hr | 10 | $0 | |
| Pro | 5,000 req/hr | 100 | $49/mo | |
| Enterprise | 100,000 req/hr | 2,000 | Custom |
Evaluate from most specific to least specific: per-endpoint > per-user > per-IP.
Distributed Rate Limiting
Redis-based pattern for consistent limiting across instances:
Atomic Lua script (prevents race conditions):
Never do separate GET then SET — the gap allows overcount.
API Gateway Configuration
NGINX:
Kong:
Client-Side Handling
Clients must handle 429 gracefully:
- Always respect
Retry-Afterwhen present - Use exponential backoff with jitter when absent
- Implement request queuing for batch operations
Monitoring
Track these metrics:
- Rate limit hit rate — % of requests returning 429 (alert if >5% sustained)
- Near-limit warnings — requests where remaining < 10% of limit
- Top offenders — keys/IPs hitting limits most frequently
- Limit headroom — how close normal traffic is to the ceiling
- False positives — legitimate users being rate limited
Anti-Patterns
| Anti-Pattern | Fix | |
|---|---|---|
| Application-only limiting | Always combine with infrastructure-level limits | |
| No retry guidance | Always include Retry-After header on 429 | |
| Inconsistent limits | Same endpoint, same limits across services | |
| No burst allowance | Allow controlled bursts for legitimate traffic | |
| Silent dropping | Always return 429 so clients can distinguish from errors | |
| Global single counter | Per-endpoint counters to protect expensive operations | |
| Hard-coded limits | Use configuration, not code constants |
NEVER Do
- NEVER rate limit health check endpoints — monitoring systems will false-alarm
- NEVER use client-supplied identifiers as sole rate limit key — trivially spoofed
- NEVER return `200 OK` when rate limiting — clients must know they were throttled
- NEVER set limits without measuring actual traffic first — you'll block legitimate users or set limits too high to matter
- NEVER share counters across unrelated tenants — noisy neighbor problem
- NEVER skip rate limiting on internal APIs — misbehaving internal services can take down shared infrastructure
- NEVER implement rate limiting without logging — you need visibility to tune limits and detect abuse
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingplugins/wpank--api-rate-limiting/skills/rate-limiting/SKILL.md
Popularity
- Repository stars
- 27
- Repository forks
- 10
- 7-day trend score
- 17
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/dvcrn/openclaw-skills-marketplace/rate-limiting)