Skip to main content
skill CX Codex

rate-limiting-implementation — Claude Code skill: API limits

A skill that walks your agent through adding rate limiting, quotas and backpressure to a service. Useful when an API is public or traffic keeps growing.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add aj-geddes/useful-ai-prompts --skill rate-limiting-implementation -a claude-code
Open on GitHub

What rate-limiting-implementation does

The skill tells the agent how to wire rate limiting and overload protection into a project. It ships worked examples: a token bucket in TypeScript, a Redis-based distributed limiter, Express middleware, a sliding window in Python, plus tiered and adaptive rate limiting. Each one lives in its own file under references/.

It also sets behaviour rules for the agent: return 429, send a Retry-After header, log violations, and stack several limit tiers — per second, minute and hour. For multi-server deployments it advises keeping counters in Redis rather than process memory, because otherwise each instance counts on its own and the shared limit never holds.

There is a list of things to avoid too: don't block a whole IP over one bad actor, don't set limits so tight that normal clients hit them, and don't deny every request when the limiter itself fails. That last point matters — if the store goes down, the service should still answer.

What it helps with

  • shield a public API from scraping and floods
  • apply per-plan quotas to different clients
  • share counters across several servers via Redis
  • drop Express middleware with a request cap into an existing app
  • absorb traffic spikes without taking the service down

Example prompts for the agent

  • add rate limiting to our Express API, per IP and per API key
  • build a Redis-backed limiter that works across instances
  • set up tiered limits for second, minute and hour windows

How to install rate-limiting-implementation

1Skills CLI (Vercel)

npx skills add aj-geddes/useful-ai-prompts --skill rate-limiting-implementation -a claude-code

2Manually: put the files in place

~/.claude/skills/rate-limiting-implementation/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/rate-limiting-implementation/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about rate-limiting-implementation

How do I install rate-limiting-implementation in Claude?

Run npx skills add aj-geddes/useful-ai-prompts --skill rate-limiting-implementation -a claude-code. The skill lands at ~/.claude/skills/rate-limiting-implementation/SKILL.md.

What does rate-limiting-implementation do?

It gives the agent instructions and code samples for request throttling, quotas and backpressure. That covers token bucket, sliding window, a Redis limiter and Express middleware.

Do I need Redis for this skill?

For a distributed limiter across several servers, yes — counters live there. On a single instance the local-state examples are enough.

Source text

SKILL.md · MIT
---
name: rate-limiting-implementation
description: >
  Implement rate limiting, throttling, API quotas, and backpressure mechanisms
  to protect services from abuse and ensure fair resource usage. Use when
  building APIs, preventing DOS attacks, or managing system load.
---

# Rate Limiting Implementation

## Table of Contents

- [Overview](#overview)
- [When to Use](#when-to-use)
- [Quick Start](#quick-start)
- [Reference Guides](#reference-guides)
- [Best Practices](#best-practices)

## Overview

Implement rate limiting and throttling mechanisms to protect your services from abuse, ensure fair resource allocation, and maintain system stability under load.

## When to Use

- Protecting public APIs from abuse
- Preventing DOS/DDOS attacks
- Ensuring fair resource usage across users
- Implementing API quotas and billing tiers
- Managing system load and backpressure
- Enforcing SLA limits
- Controlling third-party API usage
- Database connection management

## Quick Start

Minimal working example:

```typescript
interface TokenBucketConfig {
  capacity: number;
  refillRate: number; // tokens per second
  refillInterval: number; // milliseconds
}

class TokenBucket {
  private tokens: number;
  private lastRefill: number;
  private readonly capacity: number;
  private readonly refillRate: number;
  private readonly refillInterval: number;
  private refillTimer?: NodeJS.Timeout;

  constructor(config: TokenBucketConfig) {
    this.capacity = config.capacity;
    this.tokens = config.capacity;
    this.refillRate = config.refillRate;
    this.refillInterval = config.refillInterval;
    this.lastRefill = Date.now();

    this.startRefill();
  }

  private startRefill(): void {
// ... (see reference guides for full implementation)
```

## Reference Guides

Detailed implementations in the `references/` directory:

| Guide | Contents |
|---|---|
| [Token Bucket Algorithm (TypeScript)](references/token-bucket-algorithm-typescript.md) | Token Bucket Algorithm (TypeScript) |
| [Redis-Based Distributed Rate Limiter](references/redis-based-distributed-rate-limiter.md) | Redis-Based Distributed Rate Limiter |
| [Express Middleware](references/express-middleware.md) | Express Middleware |
| [Sliding Window Algorithm (Python)](references/sliding-window-algorithm-python.md) | Sliding Window Algorithm (Python) |
| [Tiered Rate Limiting](references/tiered-rate-limiting.md) | Tiered Rate Limiting |
| [Adaptive Rate Limiting](references/adaptive-rate-limiting.md) | Adaptive Rate Limiting |

## Best Practices

### ✅ DO

- Use distributed rate limiting for multi-server deployments
- Implement multiple rate limit tiers (per second, minute, hour, day)
- Return proper HTTP status codes (429 Too Many Requests)
- Include Retry-After header in responses
- Log rate limit violations for monitoring
- Implement graceful degradation
- Use Redis or similar for persistence
- Consider cost-based rate limiting (expensive operations cost more)
- Implement burst allowances for legitimate traffic spikes
- Provide clear API documentation about limits

### ❌ DON'T

- Store rate limit data in application memory for distributed systems
- Use fixed window counters without considering edge cases
- Forget to clean up expired data
- Block all requests from an IP due to one bad actor
- Set limits too restrictive for legitimate use
- Ignore the impact of rate limiting on user experience
- Fail closed (deny all) when rate limiter fails

© aj-geddes · MIT · aj-geddes/useful-ai-prompts

Similar skills

Everything for Backend and APIs →

From the same set118

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor