v2026.4.3: Qwen3.5 auto-routes to Groq while Neysa is offline

Reliability fix

Both qwen3.5-122b-a10b and qwen3.5-397b-a17b were returning upstream 404 / ERR_NGROK_3200 errors because the self-hosted Neysa backend (model1data.ngrok.app) is offline. The VibeStudio provider mapping pointed to the same backend, so it failed in lockstep.

We've made three changes:

1. Marked the Neysa mapping as unstable on both model IDs, which removes it from automatic routing (same pattern used when Fireworks K2.5 hit capacity issues on 2026-04-19).
2. Removed the redundant VibeStudio mapping — it was pointing to the same offline endpoint.
3. Added Groq (qwen/qwen3-32b) as the working provider on both model IDs. Auto-selected requests now go there directly without waiting for the low-uptime fallback to trigger.

What this means for you

• Default routing now goes to Groq for qwen3.5-* requests. No client changes needed — existing callers keep working.
• Pinning neysa/qwen3.5-* still works if you explicitly request it via the provider field or neysa/model-id syntax, but you'll get a 404 until the ngrok tunnel is back up.
• Pinned vibestudio/qwen3.5-* callers will now receive a "model not found" error. Switch to the unprefixed model ID or groq/qwen3.5-*.

Groq's qwen/qwen3-32b is a smaller checkpoint (32B dense vs. the 122B/397B MoE originals) and does not support vision, so responses may differ slightly while Neysa is down. We'll flip Neysa back to stable once the backend is restored.

Provider mapping