I Wired OpenRouter Free Models Into My OpenClaw Fallback Chain. Here's What Actually Works.

Three weeks ago my OpenClaw agent started returning overloaded_error during peak hours. Not because MiniMax was actually down — because the fallback chain was broken. Three of the five models in it were returning 404s or bad responses, and by the time OpenClaw cycled through the dead entries, the request had already timed out.

I fixed it this week. The new chain has seven entries: two local Ollama models, three OpenRouter free models, and two MiniMax models. It has not missed a request in three days.

Here's exactly what I changed, what I tested, and what I'd do differently.

The Problem With Fallback Chains Nobody Talks About

Fallback chains sound simple: if model A fails, try B, then C, then D. The reality is messier. Models don't fail with clean error codes — they return 404s, 429s, malformed responses, or just hang. And when you're running a multi-step agentic workflow, a broken fallback means a broken morning.

My old chain had five entries. When I audited it this week, three were dead:

The chain was spending 60% of its time on models that were never going to work. That's why "fallback to something cheaper" was actually making reliability worse.

The Fix: Verify First, Then Deploy

The first thing I did was test every model individually before it went into the chain. Not with a curl — with an actual API call that exercises the full tool stack.

# Test local Ollama (instant, free, no API key needed)
curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3.6:27b-q4_K_M",
  "messages": [{"role": "user", "content": "Reply with exactly one word: test"}]
}' | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['message']['content'].strip())"

# Test OpenRouter (needs API key in OPENROUTER_API_KEY env var)
curl -s https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "HTTP-Referer: https://example.com" \
  -d '{"model": "openai/gpt-oss-20b:free","messages":[{"role":"user","content":"Reply with exactly one word: test"}]}'

What I found: local Ollama models work reliably for simple tasks. OpenRouter's free tier has rate limits but the models themselves are solid. The gpt-oss-20b:free model was the most reliable of the free options.

The New Chain

ollama/qwen3.6:27b-q4_K_M   # local 27B — fastest, free, verified
ollama/qwen3.5:9b            # local 9B — fallback for lighter tasks
openai/gpt-oss-20b:free      # OpenRouter free — most reliable free tier
openai/gpt-oss-120b:free     # OpenRouter free — bigger model, sometimes 429
google/gemma-4-31b-it:free   # OpenRouter free — good reasoning
minimax-portal/MiniMax-M2.7  # primary external
minimax-portal/MiniMax-M3    # loop back to primary

The ordering is intentional: local → free → paid. Local models fire in milliseconds and cost nothing. OpenRouter free models are the buffer before hitting the paid tier.

One gotcha: OpenRouter's free models all returned 429 during my initial burst testing — that's expected behavior on the free tier, not an error. The chain handles this naturally: it tries, gets a 429, and moves to the next model. What matters is that the key is valid and the model exists.

How I Applied It Across All Cron Jobs

I have 16 cron jobs. Applying the new chain manually to each one would have been error-prone and tedious. Instead I wrote a one-liner that updates all of them at once using OpenClaw's gateway API:

NEW_CHAIN='["ollama/qwen3.6:27b-q4_K_M","ollama/qwen3.5:9b","openai/gpt-oss-20b:free","openai/gpt-oss-120b:free","google/gemma-4-31b-it:free","minimax-portal/MiniMax-M2.7","minimax-portal/MiniMax-M3"]'

openclaw cron list --json | python3 -c "
import json, sys, subprocess
jobs = json.load(sys.stdin)
chain = '$NEW_CHAIN'
for job in jobs:
    job_id = job['id']
    result = subprocess.run(
        ['openclaw', 'cron', 'update', job_id, '--fallback-chain', chain],
        capture_output=True, text=True
    )
    print(f'Updated {job[\"name\"]}: {result.returncode}')
"

I also updated the openclaw.json defaults so new sessions get the correct chain by default, not just cron jobs.

What I'd Do Differently

Test models before adding them to a chain. The old chain broke because someone (probably me, months ago) added models that seemed plausible but were never verified. A 404 or bad model in a fallback chain isn't a fallback — it's a delay.

Don't put two models from the same provider at the end of the chain. If MiniMax is overloaded, MiniMax-M2.7 and MiniMax-M3 will both be overloaded. The loop-back at the end of my chain is a hedge, but it only matters if there's something fundamentally different about how each model routes. In practice, they share infrastructure.

Use local models for health checks, not for primary work. Local Ollama models are fast and free but they don't have the same tool-calling fidelity as the frontier models for complex agentic workflows. I keep them at the top of the chain for simple tasks and reliability checks, but the main agent work still goes to MiniMax.

The chain isn't perfect. But it's the first time in three weeks that I haven't woken up to a pile of overloaded_error notifications. That's the bar — and it took an audit to clear it.

What I learned: A fallback chain is only as good as its weakest entry. Audit yours. Test every model. The time investment is 20 minutes; the reliability gain is 100%.