Opus 5 retired on Sume: why requests and threads show Opus 5.5

If a request names Claude Opus 5 on Sume, it now runs on Claude Opus 5.5. Opus 5 is retired in Sume's model registry with an unconditional successor, while Anthropic still lists Opus 5 as a legacy model that remains available. Unlike the Sonnet rows, Opus 5.5 is not behind a catalog flag: Sume lists it on every catalog.

What does Anthropic say about Opus 5.5?

Anthropic's models overview tells readers to start with Opus 5.5 for most workloads and describes it as built for long-running agentic coding and knowledge work. Its table gives the numbers that matter when you pick an orchestrator for a tool-calling agent:

• The same page lists Claude Opus 5 among legacy models that are still available, so the retirement here is Sume's catalog decision.
• Anthropic's migration link for Opus 5 users points to a guide for moving to Opus 5.5; read it before you rely on identical behavior.

What exactly does Sume change?

Three things, all in the registry that the picker, the API and usage reporting read.

First, a new request naming Opus 5 resolves to Opus 5.5 before anything is reserved or billed. Second, Opus 5 is no longer listed in the picker, so nobody can choose it fresh. Third, old rows keep their exact id: a thread or usage line written while Opus 5 was live still reads as Opus 5, with its original billing card, instead of being rewritten.

The Sume catalog id for the new model is openrouter/anthropic-claude-opus-5-5. Anthropic's own id, claude-opus-5-5, is a different string and belongs in Anthropic's API, not in a Sume field.

How do I check which Opus a run used?

On a Format run, read the model field on the receipt; Runs and results defines it as the catalog id the orchestrator ran on. If you stored the string you sent, compare the two. A sent openrouter/anthropic-claude-opus-5 that comes back as openrouter/anthropic-claude-opus-5-5 is the remap working as designed.

In a thread, the model line in the Usage view follows the same rule: new turns show Opus 5.5, old turns keep what ran then. That makes a before-and-after cost comparison honest, because each side is labelled with its own model.

Is Opus 5.5 worth the price over Sonnet 5.5 for an agent?

Only your own runs can say, but Anthropic's table frames the trade. Opus 5.5 lists $4 input and $20 output per million tokens against $2 and $10 for Sonnet 5.5, a comparative latency of moderate against fast, and default effort of medium against high. Both show a 1M-token window and 128K max output.

For an agent whose main job is calling video and image tools, the orchestrator's cost is usually small next to the generation spend, and the generation spend cap is what bounds the run. That is a reason to try the cheaper row first and move up only when a plan goes wrong, for example a storyboard that misses a reference or a retry loop. The Sonnet versus Opus comparison covers that decision in more detail.

What can still go wrong?

The remap does not save you from an id Sume has never heard of. An id outside the catalog is 400 invalid_request, per the errors page, and a typo never lands on another Claude. It also does not carry settings across: effort and Fast are per-model choices in the picker, so re-check them after the move.

Cost is the other change. Anthropic lists Opus 5.5 at $4 input and $20 output per million tokens, and Sume's own rate for the run is on the receipt's usage object. For a first week on the new model, set a modest generation_spend_cap_usd and read usage before you widen it. The dry-run and spend-cap post walks through that loop for MCP callers.