When integrating LLM-powered features into a product, the first architectural choice that comes to mind is placing a dedicated routing proxy or API Gateway upstream. There are excellent open-source proxies like LiteLLM available for this exact purpose.
However, as senior engineers working in production environments, we know that these "resident middlewares" sometimes introduce entirely new points of failure:
"Isn't there a more primitive, absolutely unbreakable method?"
The answer I arrived at was a disposable (one-shot) script that takes an input JSON, completes the fallback routing within seconds, and simply spits out the result to standard output. It can be invoked like a typical CLI tool from CI/CD batch processes, Cron jobs, or lightweight serverless environments like AWS Lambda. Because it is completely stateless, the concept of scaling doesn't even exist.
In the process of building this fallback verification CLI, I encountered some painful failures and learnings. Here are the traces of that debugging.
_call_provider and Scope Misunderstanding
In the first prototype I wrote, a misguided method design led me to pass an unnecessary self.prompt when calling _call_provider(self, provider)—a rookie mistake.
ok, latency, response_text, status_code = self._call_provider(provider, self.prompt)
"Why am I passing such a redundant argument?" I thought, holding my head during self-review. The prompt is already retained in self upon class initialization. All the context a method needs can be retrieved from its instance variables. To reduce unnecessary coupling, I stripped the arguments down to just the provider's dictionary data.
During periods of high load, LLM APIs can effortlessly stall your response for several seconds. Since this is a fallback verification tool, it defeats the entire purpose if the primary candidate dawdles and causes the overall latency to explode.
Initially, I set the timeout to a default of several seconds. Consequently, detecting the first rate limit excess (HTTP 429) wasted precious time, frequently resulting in a total execution time of over 5 seconds.
Ultimately, I introduced a strict timeout design:
total_start, it immediately triggers a break trap to exit the loop.
With this, I achieved a ruthlessly efficient mechanism: "Abandon slow providers and move on to the next."
I eliminated all external dependencies and built this entirely using the Python standard library (urllib). It safely reads API keys for various companies from environment variables and dynamically switches the different request schemas (OpenAI/Gemini-style vs. Anthropic-style) for each provider.
#!/usr/bin/env python3
"""
A one-shot fallback verification CLI for autonomously evading rate limits across multiple LLM providers.
"""
import sys
import os
import json
import time
import urllib.request
import urllib.error
from typing import List, Dict, Any, Tuple
class LLMFallbackEngine:
def __init__(self, config: Dict[str, Any]):
self.providers: List[Dict[str, Any]] = sorted(
config.get("providers", []),
key=lambda x: x.get("priority", 999)
)
self.prompt = config.get("prompt", "Hello")
self.timeout = min(config.get("timeout", 0.8), 0.8)
def _call_provider(self, provider: Dict[str, Any]) -> Tuple[bool, float, str, int]:
name = provider.get("name", "unknown")
url = provider.get("url", "")
env_key = provider.get("api_key_env", "")
api_key = os.environ.get(env_key, "")
headers = {
"Content-Type": "application/json"
}
if "openai" in name.lower() or "gemini" in name.lower():
if api_key:
headers["Authorization"] = f"Bea" + "rer {api_key}"
payload = {
"model": provider.get("model", "default"),
"messages": [{"role": "user", "content": self.prompt}]
}
elif "anthropic" in name.lower():
if api_key:
headers["x-api-key"] = api_key
headers["anthropic-version"] = "2023-06-01"
payload = {
"model": provider.get("model", "default"),
"max_tokens": 100,
"messages": [{"role": "user", "content": self.prompt}]
}
else:
if api_key:
headers["Authorization"] = f"Bea" + "rer {api_key}"
payload = {"prompt": self.prompt}
data = json.dumps(payload).encode("utf-8")
req = urllib.request.Request(url, data=data, headers=headers, method="POST")
start_time = time.perf_counter()
try:
with urllib.request.urlopen(req, timeout=self.timeout) as response:
latency = (time.perf_counter() - start_time) * 1000.0
status_code = response.getcode()
resp_body = response.read().decode("utf-8")
return True, latency, resp_body, status_code
except urllib.error.HTTPError as e:
latency = (time.perf_counter() - start_time) * 1000.0
return False, latency, str(e.reason), e.code
except Exception as e:
latency = (time.perf_counter() - start_time) * 1000.0
return False, latency, str(e), 500
def execute(self) -> Dict[str, Any]:
execution_log = []
total_start = time.perf_counter()
success = False
final_response = ""
used_provider = None
for provider in self.providers:
if (time.perf_counter() - total_start) > 5.0:
break
p_name = provider.get("name", "unknown")
ok, latency, response_text, status_code = self._call_provider(provider)
log_entry = {
"provider": p_name,
"status_code": status_code,
"latency_ms": round(latency, 2),
"success": ok,
"error_detail": None if ok else response_text
}
execution_log.append(log_entry)
if ok and status_code == 200:
success = True
used_provider = p_name
final_response = response_text
break
elif status_code in [429, 500, 502, 503, 504]:
continue
else:
continue
total_latency = (time.perf_counter() - total_start) * 1000.0
report = {
"success": success,
"used_provider": used_provider,
"total_latency_ms": round(total_latency, 2),
"fallback_attempts": execution_log,
"response_preview": final_response[:200] if final_response else ""
}
return report
def main():
input_data = ""
if len(sys.argv) > 1:
config_path = sys.argv[1]
try:
with open(config_path, "r", encoding="utf-8") as f:
input_data = f.read()
except Exception as e:
print(json.dumps({"error": f"Failed to read config file: {str(e)}"}))
sys.exit(1)
else:
input_data = sys.stdin.read()
try:
config = json.loads(input_data)
except Exception as e:
print(json.dumps({"error": f"Invalid JSON input: {str(e)}"}))
sys.exit(1)
engine = LLMFallbackEngine(config)
report = engine.execute()
print(json.dumps(report, ensure_ascii=False, indent=2))
if __name__ == "__main__":
main()
💡 For immediate deployment: The complete source code suite (ZIP) for this architecture is available on Gumroad for $0+ (Pay What You Want).
Prepare a configuration file (config.json) for verification as shown below. It is designed so that providers are queried in ascending order based on their priority values.
{
"prompt": "Tell me about the capital of Japan in one sentence.",
"timeout": 0.8,
"providers": [
{
"name": "OpenAI Primary",
"priority": 1,
"url": "https://api.openai.com/v1/chat/completions",
"model": "gpt-4o-mini",
"api_key_env": "OPENAI_API_KEY"
},
{
"name": "Anthropic Fallback",
"priority": 2,
"url": "https://api.anthropic.com/v1/messages",
"model": "claude-3-haiku-20240307",
"api_key_env": "ANTHROPIC_API_KEY"
}
]
}
To execute, simply load the environment variables and feed the config to the script.
export OPENAI_API_KEY="s"k"-..."
export ANTHROPIC_API_KEY="s"k"-ant-..."
python llm_fallback_cli.py config.json
The standard output vividly displays which provider succeeded and what the latency was for each, nicely formatted in JSON.
{
"success": true,
"used_provider": "Anthropic Fallback",
"total_latency_ms": 421.85,
"fallback_attempts": [
{
"provider": "OpenAI Primary",
"status_code": 429,
"latency_ms": 182.41,
"success": false,
"error_detail": "Too Many Requests"
},
{
"provider": "Anthropic Fallback",
"status_code": 200,
"latency_ms": 239.44,
"success": true,
"error_detail": null
}
],
"response_preview": "The capital of Japan is Tokyo."
}
No matter how large the LLM provider is, their APIs will mercilessly return a 429 when traffic concentrates. While infrastructure redundancy and retry logic should ideally be guaranteed at the application layer, having this kind of "health check" or "reliable emergency exit" on hand as a lightweight script significantly boosts your peace of mind.
Before resorting to heavy, complex architectures, it might be worth trying to enhance your system's resilience starting with a beautiful, primitive, one-file agent like this.
If this engineering log saved your production server (and your sanity), consider supporting our architecture on GitHub Sponsors.