freedzhost.cloud

Stacking free tiers: the quota warden

A frontier subscription (Kimi, Claude…) drains in cycles: a few hours of intense work, then a wall until the reset. Meanwhile, eight free providers (Groq, Cerebras, Gemini, Cloudflare, OpenRouter, Cohere, NVIDIA NIM, Mistral) each offer a few hundred or thousand requests a day. None replaces a subscription. But added up, they comfortably cover routing, validation, small tasks and part of the coding — given three ingredients: a bit of automation, thread teleportation, and provider handoff.

1. The sum nobody does by hand

Switching providers by hand means copying context, finding the right key, praying the quota holds. Nobody does that ten times a day. Our answer is three pieces:

2. Routes: cascading escalation

Models are arranged into named routes that cascade on their own:

When Groq answers 429, the cascade tries Cerebras, then Gemini, then Mistral… The request lands somewhere, and the warden learned something. Next time, the exhausted model is not even tried: it stays greyed out until its reset.

3. What it actually changes

Before: empty frontier quota = no work until the next cycle. After: the background work (routing, review, small tasks, writing) keeps going on the stacked free tiers, and frontier quota is reserved for what truly justifies it — heavy code, final review, hard decisions. The subscription does not change; what we ask of it does. A frontier quota cycle no longer bounds the day, only the peak tasks.

House rules

Traps we paid for

Free tiers promise nothing: variable latency, weaker models on complex code, quotas that change without notice. Treat them as a bonus, never as a foundation.

A supervision callback must be invisible when it works and silent when it breaks. Our first version failed the user's request when the warden was unreachable — exactly the opposite of the goal. Everything sits in absolute try/except, and async hooks are mandatory: the proxy never calls the synchronous ones.

On the proxy, the model name in the logs is the upstream id (openai/gpt-oss-20b), not your deployment name. The warden must read model_group, or it greys a name your UI does not know.

Found this useful? Tell us what to measure next.