Troubleshooting

Model Randomly Changed?

A fast recovery guide for when your agent suddenly feels "different" and you suspect the model changed mid-project.

If your outputs suddenly get shorter, more robotic, or just "not like yesterday," don't panic. In most cases this is one of three things:

you switched surfaces/sessions and landed in a different context,
the active model changed, or
you’re in a stale thread with old behavior instructions.

Common symptom

"Yesterday it wrote amazing responses, today it broke my project." This is usually configuration/context drift, not your project being cursed.

2-Minute Recovery Checklist

Ask for current runtime details in your current chat:
Show my active model name and reasoning mode right now.
Start a fresh test session (don’t reuse a long, noisy thread).
Run the same prompt twice using a tiny deterministic test prompt.
If model is wrong, set the model explicitly in dashboard/settings and retest.
If still unstable, restart gateway/session and retry once.

Known-Good Verification Prompt

Paste this exactly:

Before answering, print:
1) active model id/name
2) reasoning mode status
3) current timezone
Then write a 5-bullet summary of this sentence in a friendly tone:
"We are launching a beta feature next week for early users."
Finally, rate output confidence from 1-10.

Save the output. If it changes dramatically between runs without your input changing, you likely have a model/config/session mismatch.

High-Friction Gotchas

1) Dashboard chat vs Discord chat

Same agent identity, different conversation surfaces. You can feel like "the model changed" when you actually changed context.

2) Long-thread quality collapse

Very long chats can degrade quality and imitate a model change. Test in a clean thread before assuming your model swapped.

3) Quiet fallback to a default model

If your chosen model is temporarily unavailable, rate-limited, or access-restricted, output may look like a "different brain." Re-run the runtime check immediately before and after your test prompt to confirm what actually executed.

4) Shared workspace or team config edits

If multiple people can change settings, model changes may be real. Lock a known-good model during critical work windows and document who can edit model config.

5) Old screenshots or stale instructions

UI and model lists change quickly. Verify against current settings and current runtime output, not yesterday's screenshot.

6) “Model change failed” (500 tool invoke error)

If changing models throws a 500-style gateway/tool error, this is usually runtime state drift (not your prompt). Use this sequence:

Capture the exact error text (don’t paraphrase).
Try one nearby model in the same family as a canary.
Start a fresh session and re-run the model-change attempt once.
If still failing, restart runtime/gateway once and retry.
If available, run environment updates (for example Nerve/runtime update), then retry model switch.

If one model family works and another consistently fails, treat this as a provider/runtime compatibility issue and escalate with evidence.

Best practice

For important projects, start each session with a one-line runtime check: confirm active model + reasoning mode. It prevents silent drift.

Escalation Packet (if still broken)

Share this in #help to get fast support:

Where it fails (Dashboard / Discord DM / server channel)
Expected vs actual behavior
Current model shown by runtime check (before and after test prompt)
Exact verification prompt used
Whether fresh-session retest changed results
Approximate timestamp + timezone of the mismatch
Whether anyone else changed workspace/model settings recently

Don’t do this

Don’t keep debugging inside the same giant thread for 50 messages. You’ll mix signal and noise and make diagnosis slower.