Troubleshooting
Agent Failed Before Reply: “All Models Failed (403 Key Limit Exceeded)”
Your agent is online. Your provider key hit a usage cap. Here’s the fastest way to recover in under 5 minutes.
This error keeps showing up in #help, usually after switching models or running a lot of requests quickly. Typical message:
⚠️ Agent failed before reply: All models failed (...)
openrouter/...: 403 Key limit exceeded (total limit)
What it means: the model provider accepted your key, but refused new requests because your key or account budget has been exhausted.
Fast recovery checklist
- Open your provider dashboard (often OpenRouter) and check key limits / account balance.
- Increase the key limit or add credits.
- Verify your configured model IDs are valid and spelled exactly.
- Set one stable primary model + one valid fallback model.
- Send a short test prompt: "reply with: model check passed".
Where people get stuck
- Invalid model IDs: after experimentation, old IDs remain in config and every request fails.
- Fallback also broken: fallback model has no quota or invalid ID, so there is no rescue path.
- Assuming heyron outage: this is usually a provider-key issue, not a platform outage.
Important: don’t keep retrying the same failing prompt 20 times. It won’t clear key caps and just burns time. Fix provider limits first, then retest once.
Known-good model reset prompt
You are failing with provider/model config errors.
Do this exactly:
1) Show me the active primary model and fallback model IDs.
2) Verify both IDs are currently valid with the provider.
3) If either is invalid, replace with valid IDs.
4) Keep one primary + one fallback only.
5) Run a tiny test prompt and report exact result.
6) If it still fails, output the full provider error text only (no summary).
If you use OpenRouter
- Check credit balance.
- Check per-key limit caps (not just account balance).
- Rotate to a fresh key if needed, then update config cleanly.
High-friction edge cases (quick checks)
- Wrong key in the wrong place: you updated one surface (dashboard or local config), but the active runtime is still using an old key somewhere else.
- Fresh key, same error: old key is still selected/loaded; force a clean restart, then run one tiny test prompt.
- Fallback hides the real issue: primary fails with 403, fallback fails with a different error (or another 403), making it look random.
- Burst testing triggers caps: repeated retries can quickly hit per-minute/per-day limits even with non-zero account balance.
Loop-break rule: after two failed retests, stop. Capture exact primary + fallback IDs and full provider error text, then escalate once with complete evidence.
When it might be a platform-wide incident
- Signal: several users report
403 Key limit exceeded at the same time across channels.
- What this usually means: shared provider allocation/key pool limits are being hit, not just your individual prompt.
- What to do: open one support ticket with evidence instead of repeatedly retrying and burning more requests.
Fast differentiator: if your exact same short canary prompt fails in a fresh session and other users are reporting the same 403 window, treat it as service allocation pressure and escalate once with timestamps.
Escalation packet for #help
Provider/model failure report
Primary model ID:
Fallback model ID:
Exact error text:
Provider (OpenRouter/OpenAI/etc):
Did you confirm key balance/limit? (yes/no):
Did you test with one simple prompt? (yes/no):
What happened on test:
Did you rotate/replace key in all active surfaces? (yes/no):
Did you restart runtime/session after key change? (yes/no):
Bottom line: this error is usually fixable in minutes. Treat it as a provider quota/config issue: validate key limits, clean model IDs, then run one tiny smoke test.