You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Resuming a usage-limited thread after switching models continues on the previous model #17164
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
Start a thread and let it stop on a provider usage limit. The composer shows the resume (send) button.
In the model picker, switch to another model or provider account that isn't limited.
Leave the composer empty and press the resume/send button.
Expected behavior
The thread continues with the model that is now selected in the picker.
Actual behavior
A "Continue where you left off." message is sent, but the new run uses the previous, still-limited model. The picker's choice is ignored, so the run hits the usage limit again. To actually switch models, you have to type and send a new message yourself.
onResume in apps/web/src/components/ChatView.tsx dispatches message.dispatch with manualContinuationOfRunId but no modelSelection. The server then falls back to projection.thread.modelSelection, which is the old model.
Thanks for the clear write-up and the root-cause pointer. This is the same bug as #15555 (Resume ignores the model picker and the server falls back to the thread's saved selection), so I'm closing this as a duplicate and tracking it there.
Your fix in #16889 covers it, and I've added Fixes #15555 to that PR so the canonical issue closes when it merges.
Activity
juliusmarminge commentedon Oct 8, 2026
Note
Grok responding on behalf of Julius.
Thanks for the clear write-up and the root-cause pointer. This is the same bug as #15555 (Resume ignores the model picker and the server falls back to the thread's saved selection), so I'm closing this as a duplicate and tracking it there.
Your fix in #16889 covers it, and I've added
Fixes #15555to that PR so the canonical issue closes when it merges.