Sonnet 5 retired on Sume: requests move to Sonnet 5.5, ids explained

Sume retired its Claude Sonnet 5 pick at the end of September: a request that names Sonnet 5 now runs on Claude Sonnet 5.5, while Anthropic itself still lists Sonnet 5 as a legacy model that remains available. So "retired" means the Sume picker and API remap it, not that Anthropic switched it off.

The remap is unconditional in the registry. Sonnet 5 has no gate of its own to bypass: it points at the Sonnet 5.5 row, and Sonnet 5.5 is admitted wherever the Anthropic catalog is open.

What replaced Sonnet 5 in the Sume Agents catalog?

Sonnet 5.5 is the replacement, added in the same change that retired Sonnet 5. It is described in the picker as Anthropic's best combination of speed and intelligence, which matches the line on Anthropic's overview page for the model.

Anthropic's table gives Sonnet 5.5 a 1M-token context window, 128K max output, $2 per million input tokens and $10 per million output tokens, adaptive thinking with default effort high, and a retirement of not sooner than September 28, 2027. The page's own legacy list names Sonnet 5 as still available.

Which id spelling should I send?

Four strings show up around this model in different places. Only the second is the Sume catalog id, and the fourth is the retired one:

• The registry resolves short picker names, native and dashed spellings and retired ones to the catalog row.
• A two-slash spelling such as openrouter/anthropic/claude-sonnet-5 names nothing and is refused.
• Anthropic's own id does not appear in that list of Sume spellings, so do not paste claude-sonnet-5-5 from Anthropic's docs into a Sume field and expect it to resolve; copy the id the picker shows.

What stays on Sonnet 5?

Old records. A stored thread, a saved setting or a usage row that was written while Sonnet 5 was live keeps the exact id and its original billing card, so history still reads as Sonnet 5. Only new requests move.

If you compared two runs and one of them used Sonnet 5, the receipt's model field is how you tell them apart afterwards. For a Format run that field is documented in Runs and results as the catalog id the orchestrator ran on.

Should I move to Sonnet 5.5 myself or let the remap do it?

Do it yourself, in your own config, and keep the receipt as evidence. A remap is correct for old clients, but it hides the change from your logs: your code still says Sonnet 5 while the work ran on 5.5, and a regression you chase later will point at the wrong model.

A practical order is to change the string in staging, run one real job that calls a media tool, compare the receipt's model, usage and output against a run from before the change, then update production. Because Sonnet 5.5 and Sonnet 5 both list large context windows on Anthropic's pages, the change is rarely about fitting a prompt; it is about cost and behavior, which only your own run shows.

Should I move to Sonnet 5.5 myself or let the remap do it?

Do it yourself, in your own config, and keep the receipt as evidence. A remap is correct for old clients, but it hides the change from your logs: your code still says Sonnet 5 while the work ran on 5.5, and a regression you chase later will point at the wrong model.

A practical order is to change the string in staging, run one real job that calls a media tool, compare the receipt's model, usage and output against a run from before the change, then update production. Anthropic's page gives Sonnet 5.5 a 1M-token window, so the change is rarely about fitting a prompt; it is about cost and behavior, which only your own run shows.

Will my request be refused instead?

Only when the catalog is closed in your environment. Sume's Anthropic rows other than Opus 5.5 are behind an OpenRouter catalog gate, an environment flag. If the gate is closed, a request naming Sonnet 5.5, or Sonnet 5 on its way there, gets an error and not a silent downgrade onto another model. On a Format run that error is 400 invalid_request, listed on the errors page.

Check the model picker in your workspace before you change a stored payload, and keep the old string in your config for a day so you can roll back. The mid-session switch post shows that Sume jobs keep running while the model underneath changes.