# Sonnet 5.5 split the middle-tier question between office work and code

Why Sonnet 5.5's everyday-work positioning needs separate acceptance evidence for repository changes, spreadsheets and presentations.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-28
Original announcement: https://www.anthropic.com/claude-sonnet-5-5
Canonical URL: https://retrivium.ai/retrospectives/sonnet55-middle-tier-office-code/

## One tier covered different kinds of deliverable

The [Fable and Mythos release on September 1, 2026](https://www.anthropic.com/claude-fable-and-mythos-5-1) preceded [Opus 5.5 on September 22](https://www.anthropic.com/claude-opus-5-5). [Sonnet 5.5 followed on September 28](https://www.anthropic.com/claude-sonnet-5-5), positioned for everyday coding and office artifacts. That common positioning is useful for selection, but it does not create one universal acceptance test. A repository patch and an operating-review presentation can both look polished while failing in fundamentally different ways. Choosing a middle tier therefore leaves the definition of a successful deliverable unresolved.

## Code exposes executable obligations

An illustrative bug fix must preserve behavior outside its intended change. A plausible explanation and a clean diff are insufficient if the altered path fails at runtime. The acceptance packet should connect the reported defect, changed code and relevant validation. Review also needs to notice an unnecessary rewrite that expands the task. This does not imply that every low-impact edit requires a new test suite. It means that the evidence should address the actual behavior at risk, rather than rely on how confidently the model describes its patch.

## Office artifacts expose interpretive obligations

An illustrative operating review can open correctly and still misstate a comparison, hide a qualification or make a chart unreadable. Its acceptance therefore includes source fidelity, meaningful labels and a rendered view of the artifact. Those checks differ from executing a repository's tests. They also distinguish design polish from supported analysis. A slide with attractive typography cannot establish that its conclusion follows from the underlying records, just as a correct spreadsheet formula cannot guarantee that the chosen business comparison answers the assigned question.

## A split fixture avoids a misleading average

A practical evaluation can retain a bounded coding task and a bounded document task as separate cohorts. Each cohort has its own acceptance evidence and revision history. Combining them only after that review prevents easy document formatting from concealing a weak patch result, or a strong coding result from masking inaccurate reports. No comparative score is proposed here. The fixture demonstrates why a broad product category should be decomposed before an evaluator concludes that one default is suitable across the organization's routine work.

## The shared model does not erase task differences

The September release can motivate testing a more economical or responsive option for everyday assignments. It cannot remove the obligations carried by the artifact itself. The useful retrospective lesson is that model-tier selection and acceptance design operate at different levels. A team may eventually use the same model for code and documents, but that should follow evidence from both workflows. Keeping the checks distinct makes a mixed result actionable: improve the failing workflow or route it differently, rather than declaring the whole tier uniformly good or bad.

## Related reading

- [Keeping task cohorts separate](/journal/inference-benchmark-method/)
- [Preserving application behavior](/journal/provider-api-contract-deprecation-migration/)