Switch Opus 5.5 and Sonnet 5.5 mid-session: Sume jobs keep running
Claude Code 2.1.287 fixed /model and opusplan switches rewriting earlier MCP tool announcements. Sume jobs live on the server, so a new model can pick them up.

You can switch between Opus 5.5 and Sonnet 5.5 in the middle of a Claude Code session that is waiting on Sume jobs, because a Sume job belongs to your workspace on Sume's side, not to the model that submitted it. Claude Code 2.1.287 also fixed a bug where switching with /model or opusplan rewrote earlier MCP tool announcements, which could drop earlier extended thinking.
The fix is in the Claude Code changelog entry for October 1, 2026; the model ids and prices are from Anthropic's models overview. Both were read 2026-10-01.
What exactly did 2.1.287 fix?
The changelog line: switching between Opus 5.5 and Sonnet 5.5 with /model or opusplan rewrote earlier MCP tool announcements, which could drop earlier extended thinking. So before the update a switch could change how earlier MCP tools were presented to the model. After it, the earlier announcements are left alone.
Which two models are involved?
Anthropic's overview lists both with a 1M-token context window and 128K max output. The Claude Code changelog adds that Sonnet 5.5 became the default Sonnet on September 28.
| Claude Opus 5.5 | Claude Sonnet 5.5 | |
|---|---|---|
| API id | claude-opus-5-5 | claude-sonnet-5-5 |
| Input / output per MTok | $4 / $20 | $2 / $10 |
| Default effort | medium | high |
| Context window | 1M tokens | 1M tokens |
Where does a Sume job live while I switch?
Sume's jobs page says generation endpoints create durable jobs and to store the job id so work can be recovered after process restarts. A job in queued or processing keeps going whichever model is in the chat, and it keeps billing. A model switch changes who reads the result, not whether the job runs.
How does the new model pick up an in-flight job?
Paste or restate the job ids, or let the new model call jobs_list, which is a read tool. Then jobs_wait with those ids; on remote MCP a wait slice is capped at 55 seconds, and the docs say to retry the wait with the same ids rather than resubmit the paid create. jobs_result returns the outputs once a job is completed. The tools and gates page lists all three.
Should I switch before or after a paid submit?
Switching between submit and wait is safe for the job. What the switch cannot do is un-send a call, so if you want the cheaper model to do the polling, submit with the stronger one, note the ids, then switch. Keep idempotency_key stable for any retry.
Sources
Related posts
More in Integrations
- Claude Managed Agents vault static_bearer for Sume tools
For Sume's hosted MCP in a Claude Managed Agents vault, use a static_bearer credential keyed to https://mcp.sume.com/mcp; OAuth tokens last an hour.
- Sonnet 5.5 and a 10-minute render: about 12 jobs_wait calls
A Sume job that takes ten minutes needs roughly 11 to 12 jobs_wait calls at the 55 and 50 second slices. How to keep a Sonnet 5.5 tool loop that short.
- Code by Zapier 225 requests per 10 seconds and Sume 429s
Zapier lists 225 requests per 10 seconds for Code by Zapier on Pro and Team. Sume has its own 429 rate_limited: honor retry-after and send an Idempotency-Key.
- Code by Zapier 10-minute runtime vs Sume's 30-second sync wait
Code by Zapier can run 10 minutes on action steps, but Sume's sync wait caps at 30 seconds. Submit async, keep the job id, and poll instead of holding the step.
Written by Sume