groq-rate-limits
Tools and patterns for managing Groq API 429 rate limit errors and optimizing request throughput.
Install
mkdir -p .claude/skills/groq-rate-limits && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7261" && unzip -o skill.zip -d .claude/skills/groq-rate-limits && rm skill.zipInstalls to .claude/skills/groq-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 Groq rate limit handling with backoff, queuing, and headerKey capabilities
- →Parse x-ratelimit headers into typed information
- →Gate requests using concurrency control queues
- →Monitor remaining capacity proactively
- →Execute model-aware fallback strategies
How it works
The skill implements a client wrapper that combines request queuing, proactive monitoring of rate limit headers, and exponential backoff logic.
Inputs & outputs
When to use groq-rate-limits
- →Implementing exponential backoff for 429 errors
- →Setting up request concurrency queues
- →Parsing Groq rate limit headers
- →Building model fallback strategies
- →Monitoring API capacity
About this skill
Groq Rate Limits
Overview
Handle Groq rate limits using the retry-after header, exponential backoff, and request queuing. Groq enforces limits at the organization level with both RPM (requests/minute) and TPM (tokens/minute) constraints -- hitting either one triggers a 429.
The workflow builds up in five composable layers: parse the rate-limit headers, wrap calls in retry-with-backoff, gate concurrency through a queue, monitor remaining capacity proactively, and fall back across models when one pool is exhausted. Read SKILL.md for the high-level flow, then drill into the full implementation for every code block and the reference tables + worked examples for header definitions and composed clients.
Prerequisites
- A Groq API key (
GROQ_API_KEY) — get one at console.groq.com. groq-sdkinstalled:npm install groq-sdk.- For queuing (Step 3):
p-queueinstalled:npm install p-queue. - Node.js 18+ (for native
fetchand the SDK). - Know your plan's limits — check console.groq.com/settings/limits.
Rate Limits at a Glance
Groq applies RPM, RPD, TPM, and TPD limits simultaneously — you must stay under every one, and either RPM or TPM can trip a 429. Every response (even a success) carries x-ratelimit-* headers describing remaining capacity and reset timing; 429 responses add a retry-after header. Full header and constraint tables: reference.md.
Instructions
Compose these five steps into one client wrapper (queue → monitor → retry). Each step's complete, copy-pasteable code is in implementation.md.
Step 1: Parse Rate Limit Headers
Read the x-ratelimit-* headers off every response into a typed RateLimitInfo so downstream logic can reason about remaining capacity. Groq reports reset times as strings like "1.2s" or "120ms" — normalize them to milliseconds.
Step 2: Exponential Backoff with Retry-After
Wrap each API call in a retry loop. Prefer Groq's retry-after header when present; otherwise back off exponentially with jitter, capped at maxDelayMs. Retry only 429 and 5xx — other 4xx errors are not retryable.
Step 3: Request Queue with Concurrency Control
Gate all requests through a p-queue sized to your plan's RPM (intervalCap over a 60s interval) so bursts never exceed the limit in the first place.
Step 4: Proactive Rate Limit Monitor
Track remaining requests/tokens from response headers and pause before hitting zero (shouldThrottle() → waitIfNeeded()), instead of reacting to 429s after the fact.
Step 5: Model-Aware Rate Limit Strategy
Different models draw from different limit pools. When the preferred model is throttled, fall back to another model to keep making progress without waiting for a reset.
Output
Applying this skill produces:
- A
withRateLimitRetry()wrapper that transparently retries429/5xxwithretry-after-aware backoff. - A
RateLimitMonitorthat surfaces live status (getStatus()→"Requests: N remaining | Tokens: M remaining") and throttles proactively. - A
p-queue-backed client that caps throughput to your RPM so 100 fan-out calls complete without tripping the limit. - Console diagnostics on every backoff/throttle event (e.g.
Rate limited (attempt 2/5). Waiting 1.4s...).
The observable end state: sustained request volume that stays under RPM/TPM with zero unhandled 429s.
Error Handling
| Scenario | Symptom | Solution |
|---|---|---|
| Burst of requests | Many 429s in quick succession | Use queue with p-queue interval limiting (Step 3) |
| Large prompts burn TPM | 429 on tokens, not requests | Reduce max_tokens, compress prompts |
| Free tier too restrictive | Constant 429s | Upgrade to Developer plan at console.groq.com |
| Multiple services sharing key | Cascading 429s | Use separate API keys per service |
retry-after absent on 429 | Retries hammer too fast | Fall back to exponential backoff + jitter (Step 2) |
Examples
Start from this minimal 429 handler, then graduate to the composed client (queue + monitor + retry) in reference.md:
try {
await groq.chat.completions.create({ model, messages });
} catch (err) {
if (err instanceof Groq.APIError && err.status === 429) {
const retryAfter = parseInt(err.headers?.["retry-after"] || "0");
console.log(`Rate limited. retry-after says wait ${retryAfter}s.`);
// -> feed retryAfter into withRateLimitRetry (Step 2)
}
}
- Full five-step implementation (every code block, verbatim): implementation.md
- Composed client + header/limit tables + a 100-request fan-out: reference.md
Resources
- Groq Rate Limits Documentation
- Groq Pricing / Plans
- p-queue on npm
- Full implementation: references/implementation.md
- Reference tables & worked examples: references/reference.md
Next Steps
For security configuration, see the groq-security-basics skill in this pack, which covers API key storage, rotation, and request signing to complement the throughput handling above.
When not to use it
- →When handling non-retryable 4xx errors
- →When ignoring organization-level RPM or TPM constraints
Prerequisites
Limitations
- →Requires p-queue for concurrency control
- →Requires knowledge of specific plan limits
How it compares
This approach proactively manages throughput using queues and header parsing rather than reacting only after receiving 429 errors.
Compared to similar skills
groq-rate-limits side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| groq-rate-limits (this skill) | 1 | 24d | No flags | Intermediate |
| chrome-devtools | 41 | 7mo | Review | Intermediate |
| python-performance-optimization | 27 | 2mo | No flags | Intermediate |
| analyzing-logs | 14 | 25d | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
chrome-devtools
mrgoonie
Browser automation, debugging, and performance analysis using Puppeteer CLI scripts. Use for automating browsers, taking screenshots, analyzing performance, monitoring network traffic, web scraping, form automation, and JavaScript debugging.
python-performance-optimization
wshobson
Profile and optimize Python code using cProfile, memory profilers, and performance best practices. Use when debugging slow Python code, optimizing bottlenecks, or improving application performance.
analyzing-logs
jeremylongshore
Analyze application logs to detect performance issues, identify error patterns, and improve stability by extracting key insights.
n8n-expression-syntax
czlonkowski
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.
redis-inspect
civitai
Inspect Redis cache keys, values, and TTLs for debugging. Supports both main cache and system cache. Use for debugging cache issues, checking cached values, and monitoring cache state. Read-only by default.
obsidian-performance-tuning
jeremylongshore
Optimize Obsidian plugin performance for smooth operation. Use when experiencing lag, memory issues, or slow startup, or when optimizing plugin code for large vaults. Trigger with phrases like "obsidian performance", "obsidian slow", "optimize obsidian plugin", "obsidian memory usage".