rate-limit-fallback

Implements LLM provider fallback chains with per-minute and per-day rate limit handling.

Updated May 19, 2026
One-click install
npx skills add https://github.com/Jessitoii/career-os --skill rate-limit-fallback-jessitoii
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rate-limit-fallback
Source: https://github.com/Jessitoii/career-os/tree/main/.agents/skills/rate-limit-fallback
Command: npx skills add https://github.com/Jessitoii/career-os --skill rate-limit-fallback-jessitoii

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? LLM API calls fail unpredictably due to rate limits, quota exhaustion, and malformed JSON responses, breaking automated pipelines. This Skill provides a structured fallback chain that distinguishes per-minute from per-day limits and routes requests across Groq, Cerebras, Ollama, Anthropic, OpenAI, and Google providers. ## Core Features & Use Cases - Rate Limit Classification: Parses 429 error responses to distinguish per-minute limits (wait and retry) from per-day quota exhaustion (skip to next provider). - Multi-Provider Fallback Chains: Defines per-task model chains (relevance scoring, CV tailoring, rejection categorization, interview prep, DOM vision) with a local Ollama model as the final fallback. - Invalid JSON Recovery: Automatically retries with the next model in the chain when a provider returns malformed JSON. - Use Case: When a Groq model returns a 429 daily quota error during relevance scoring, the dispatcher immediately routes the request to Cerebras, then to a local Ollama model if needed, and sends a Telegram alert if all models are exhausted. ## Quick Start Use the rate-limit-fallback skill to debug why my call_with_fallback function raises AllModelsExhaustedError on the relevance_scoring task.

Frequently Asked Questions about rate-limit-fallback

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle LLM API rate limits with automatic fallback?

Parse the 429 error response to determine the limit type, then either wait and retry the same model for per-minute limits or skip to the next provider for per-day limits. Define an ordered model chain per task and iterate through it until a call succeeds.

How to distinguish per-minute vs per-day rate limits in Groq API errors?

Check the error message body for keywords like daily, per day, quota, or 24-hour to identify daily limits, and read the retry-after or x-ratelimit-reset-requests headers for wait times. Per-minute limits warrant a retry after the specified delay; daily limits require switching providers.

What is a good fallback order for LLM providers?

A typical chain starts with fast hosted providers like Groq across several models, falls back to Cerebras, and ends with a local Ollama model as the last resort. The local model guarantees availability even when all cloud quotas are exhausted.

Why does my LLM fallback chain fail with invalid JSON responses?

Some models return malformed JSON that fails parsing even when the API call succeeds. Catch the JSON parsing error separately and continue to the next model in the chain rather than retrying the same model.

When should I not use an LLM fallback chain?

Do not use this approach for platform-level rate limiting in browser automation, which requires session lifecycle management instead. It is designed for LLM API calls, not web scraping or browser request throttling.