perplexity-rate-limits
Sets up exponential backoff and request queuing to handle Perplexity API rate limits.
Install
mkdir -p .claude/skills/perplexity-rate-limits && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8280" && unzip -o skill.zip -d .claude/skills/perplexity-rate-limits && rm skill.zipInstalls to .claude/skills/perplexity-rate-limits
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Implement Perplexity rate limiting, backoff, and request queuing.Key capabilities
- →Implement exponential backoff with jitter for API requests
- →Queue Perplexity API requests to manage rate limits
- →Utilize a token bucket algorithm for fine-grained rate control
- →Handle HTTP 429 and 5xx errors with retry logic
- →Space requests 1.2 seconds apart to avoid burst rate limits
How it works
The skill implements exponential backoff with jitter to retry failed requests and uses queue-based or token bucket mechanisms to control request rates.
Inputs & outputs
When to use perplexity-rate-limits
- →Handling 429 errors
- →Implementing retry logic
- →Optimizing request throughput
About this skill
Perplexity Rate Limits
Overview
Handle Perplexity Sonar API rate limits. Perplexity uses a leaky bucket algorithm: burst capacity is available, with tokens refilling continuously at your assigned rate. Rate limits are based on requests per minute (RPM).
Rate Limit Tiers
| Tier | RPM | Notes |
|---|---|---|
| Free / Starter | 50 | Default for new API keys |
| Search API | ~3 req/sec | Per-endpoint limit |
| Higher tiers | Contact sales | Custom limits available |
Rate limits apply per API key, not per model. Using sonar-pro counts against the same RPM as sonar.
Prerequisites
PERPLEXITY_API_KEYset- Understanding of HTTP 429 responses
Instructions
Step 1: Exponential Backoff with Jitter
async function withExponentialBackoff<T>(
operation: () => Promise<T>,
config = { maxRetries: 5, baseDelayMs: 1000, maxDelayMs: 30000, jitterMs: 500 }
): Promise<T> {
for (let attempt = 0; attempt <= config.maxRetries; attempt++) {
try {
return await operation();
} catch (error: any) {
if (attempt === config.maxRetries) throw error;
const status = error.status || error.response?.status;
// Only retry on 429 (rate limit) and 5xx (server errors)
if (status && status !== 429 && status < 500) throw error;
const exponentialDelay = config.baseDelayMs * Math.pow(2, attempt);
const jitter = Math.random() * config.jitterMs;
const delay = Math.min(exponentialDelay + jitter, config.maxDelayMs);
console.warn(`[Perplexity] ${status || "error"} — retry ${attempt + 1}/${config.maxRetries} in ${delay.toFixed(0)}ms`);
await new Promise((r) => setTimeout(r, delay));
}
}
throw new Error("Unreachable");
}
// Usage
const result = await withExponentialBackoff(() =>
perplexity.chat.completions.create({
model: "sonar",
messages: [{ role: "user", content: "test query" }],
})
);
Step 2: Queue-Based Rate Limiting
import PQueue from "p-queue";
// 50 RPM = ~0.83 req/sec. Set intervalCap=1, interval=1200ms for safety.
const perplexityQueue = new PQueue({
concurrency: 3,
interval: 1200,
intervalCap: 1,
});
async function queuedSearch(query: string, model = "sonar") {
return perplexityQueue.add(() =>
withExponentialBackoff(() =>
perplexity.chat.completions.create({
model,
messages: [{ role: "user", content: query }],
})
)
);
}
// Batch queries are automatically rate-limited
const queries = ["query 1", "query 2", "query 3", "query 4", "query 5"];
const results = await Promise.all(queries.map((q) => queuedSearch(q)));
Step 3: Token Bucket Implementation (No Dependencies)
class TokenBucket {
private tokens: number;
private lastRefill: number;
constructor(
private maxTokens: number = 50,
private refillRate: number = 50 / 60 // 50 per minute = 0.83/sec
) {
this.tokens = maxTokens;
this.lastRefill = Date.now();
}
async acquire(): Promise<void> {
this.refill();
if (this.tokens >= 1) {
this.tokens -= 1;
return;
}
// Wait until a token is available
const waitMs = (1 / this.refillRate) * 1000;
await new Promise((r) => setTimeout(r, waitMs));
this.refill();
this.tokens -= 1;
}
private refill() {
const now = Date.now();
const elapsed = (now - this.lastRefill) / 1000;
this.tokens = Math.min(this.maxTokens, this.tokens + elapsed * this.refillRate);
this.lastRefill = now;
}
get available(): number {
this.refill();
return Math.floor(this.tokens);
}
}
const bucket = new TokenBucket(50, 50 / 60);
async function rateLimitedSearch(query: string) {
await bucket.acquire();
return perplexity.chat.completions.create({
model: "sonar",
messages: [{ role: "user", content: query }],
});
}
Step 4: Python Rate Limiting
import time, asyncio
from collections import deque
class RateLimiter:
def __init__(self, rpm: int = 50):
self.rpm = rpm
self.window = deque()
def wait_if_needed(self):
now = time.time()
# Remove timestamps older than 60 seconds
while self.window and self.window[0] < now - 60:
self.window.popleft()
if len(self.window) >= self.rpm:
sleep_time = 60 - (now - self.window[0])
time.sleep(max(0, sleep_time))
self.window.append(time.time())
limiter = RateLimiter(rpm=50)
def rate_limited_search(client, query: str, model: str = "sonar"):
limiter.wait_if_needed()
return client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": query}],
)
Error Handling
| Signal | Meaning | Action |
|---|---|---|
| HTTP 429 | RPM exceeded | Backoff and retry |
Retry-After header | Seconds until reset | Honor this value exactly |
| Repeated 429s | Sustained overload | Reduce concurrency or add queue |
| 429 on burst | Bucket empty | Space requests 1.2s apart |
Output
- Automatic retry with exponential backoff and jitter
- Queue-based rate limiting for batch operations
- Token bucket for fine-grained control
- Python rate limiter for synchronous code
Resources
Next Steps
For security configuration, see perplexity-security-basics.
Prerequisites
Limitations
- →Rate limits apply per API key, not per model
- →Free/Starter tier has a 50 RPM limit
- →Search API has a limit of approximately 3 requests/second
How it compares
This skill automates retry logic and request queuing, unlike manually managing API call timing and error handling.
Compared to similar skills
perplexity-rate-limits side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| perplexity-rate-limits (this skill) | 0 | 27d | No flags | Intermediate |
| exa-performance-tuning | 3 | 27d | Review | Intermediate |
| documenso-performance-tuning | 0 | 27d | Review | Intermediate |
| gamma-performance-tuning | 0 | 27d | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
exa-performance-tuning
jeremylongshore
Optimize Exa API performance with caching, batching, and connection pooling. Use when experiencing slow API responses, implementing caching strategies, or optimizing request throughput for Exa integrations. Trigger with phrases like "exa performance", "optimize exa", "exa latency", "exa caching", "exa slow", "exa batch".
documenso-performance-tuning
jeremylongshore
Optimize Documenso integration performance with caching, batching, and efficient patterns. Use when improving response times, reducing API calls, or optimizing bulk document operations. Trigger with phrases like "documenso performance", "optimize documenso", "documenso caching", "documenso batch operations".
gamma-performance-tuning
jeremylongshore
Optimize Gamma API performance and reduce latency. Use when experiencing slow response times, optimizing throughput, or improving user experience with Gamma integrations. Trigger with phrases like "gamma performance", "gamma slow", "gamma latency", "gamma optimization", "gamma speed".
juicebox-prod-checklist
jeremylongshore
Execute Juicebox production deployment checklist. Use when preparing for production launch, validating deployment readiness, or performing pre-launch reviews. Trigger with phrases like "juicebox production", "deploy juicebox prod", "juicebox launch checklist", "juicebox go-live".
openevidence-performance-tuning
jeremylongshore
Optimize OpenEvidence clinical query performance and response times. Use when improving latency, optimizing query efficiency, or tuning caching for clinical AI applications. Trigger with phrases like "openevidence performance", "openevidence slow", "optimize openevidence", "openevidence latency", "speed up clinical queries".
v3-mcp-optimization
ruvnet
MCP server optimization and transport layer enhancement for claude-flow v3. Implements connection pooling, load balancing, tool registry optimization, and performance monitoring for sub-100ms response times.