Troubleshooting
Model ID Invalid or “Agent Failed Before Reply”?
A clean recovery flow for broken model settings, invalid fallback IDs, and “all models failed” errors.
If your agent suddenly stops responding after model changes, you’re usually dealing with config validation — not a broken account.
Common trigger: changing the primary model and fallback models at the same time, then one ID is typed wrong or no longer available.
What this error usually means
- “Model ID is not valid”: the model string does not match a currently supported ID in your provider route.
- “Agent failed before reply”: preflight validation failed before the model even generated output.
- “All models failed”: primary + all fallbacks failed (invalid IDs, disabled key, or exhausted key limits).
5-minute recovery workflow
1) Revert to one known-good model (no fallbacks)
Temporarily remove every fallback model. Keep only one model that previously worked in your setup.
2) Run a tiny canary test
Send a minimal prompt like “Reply with OK.” If this fails, the issue is still base config/provider, not prompt quality.
3) Validate fallback IDs one-by-one
Add one fallback, test. Add the next, test. Do not add 3+ at once or you won’t know which one broke it.
4) Check provider/key limits
If you see 403 key limit errors, the model ID may be fine — the key quota is not. Fix quota/key first.
5) Keep a rollback block
Save your last known-good model config in a note so you can restore fast after experiments.
Good vs risky model-change pattern
Risky (hard to debug)
Change primary model + add 3 new fallbacks + switch provider key in one edit.
Safe (debuggable)
Step 1: Change primary model only → test
Step 2: Add fallback #1 → test
Step 3: Add fallback #2 → test
Important: if a model worked last week but fails now, the model may have been renamed, deprecated, or your key scope changed.
High-friction edge cases (that look random but aren’t)
- Provider namespace mismatch: model ID format may require a provider prefix/syntax change (for example, switching providers but keeping old-style IDs).
- Fallback masks root cause: runtime may report generic “all models failed” while the first real failure is auth/quota on primary.
- Stale runtime after config edit: dashboard shows new model list, but active runtime is still using old values until a fresh session/restart.
- Mixed key + model family: key is valid, but not authorized for that model family/tier.
- Model is invalid at startup and UI settings appear stuck: some users report they can’t change settings while every prompt instantly errors. Open settings in a fresh browser tab/session, remove fallbacks first, save one known-good model, then start a brand-new chat.
- Support channel access confusion during onboarding: if you can’t see a support channel yet, use the web support form first so your issue is in queue while Discord permissions refresh.
Loop-break sequence
1) Set ONE known-good model (no fallbacks)
2) Start a fresh session (or restart runtime if required)
3) Run canary: "Reply with OK"
4) Re-add exactly one fallback
5) Re-test before adding another
Copy/paste prompt to self-heal config
Diagnose my model config without guessing.
1) Tell me the exact primary model currently set.
2) List all fallback model IDs exactly as configured.
3) Flag any invalid or suspicious IDs.
4) Propose the smallest safe rollback to one known-good model.
5) After rollback, run a tiny canary prompt: "Reply with OK" and report result.
When to escalate to support
- You reverted to a previously working model and canary still fails.
- You keep seeing 401/403 errors after key reset.
- Dashboard shows one model, runtime reports another.
- Behavior differs across Discord vs dashboard with same agent config.
- You cannot access the Discord support channel yet (permission/visibility delay) and need immediate help.
Support packet (fast)
- Exact error text (full line, no paraphrase)
- Primary model ID + fallback IDs
- Whether error is 401, 403, invalid ID, or “all models failed”
- Result of tiny canary prompt
- Whether you tested with one-model/no-fallback mode in a fresh session
- What changed right before it broke
- Whether support-channel access is blocked (and confirmation you also filed at heyron.ai/support)
Bottom line: model failures are usually config drift, not agent failure. Roll back to one known-good model, test small, then reintroduce fallbacks one at a time.