Claude Sonnet 5.5: should my business switch?
Test Claude Sonnet 5.5 on one recurring task before changing a working process. Give it the same inputs as your current setup, check the result yourself and record the time spent correcting it. Switch where the whole task improves, not simply where the first response arrives faster.
What changed on 28 September?
Anthropic released Sonnet 5.5 on 28 September 2026. It reports faster output and lower task costs than Sonnet 5, positioning it for well-defined everyday work. These are vendor findings, not measured savings for your business. The announcement keeps Opus 5.5 as its stronger option for complex, open-ended work. Read the announcement.
This article was researched on 29 September. The news is yesterday’s release, not a launch today. We have not run an independent Sonnet 5.5 benchmark; the pilot below is a suggested way to make your own decision.
Can my team use it now?
Anthropic lists Sonnet 5.5 on Claude.ai and its mobile apps, plus the Claude Platform and major cloud platforms. Availability in a product is not the same as unlimited use or permission to upload company data. Official availability.
In Claude, the model menu is next to the send button. Choose the model there and check the effort setting. On Enterprise, an administrator can restrict available models or effort levels. Current model controls.
Before testing, record your plan, the selected model, available usage and any workspace restrictions. Confirm approval to use the data involved. Do not purchase a new plan or move customer files merely because a release announcement says the model is available.
Which of these three routes fits my business?
1. I use Claude directly for everyday work
Start with a task someone can verify quickly: turning approved meeting notes into a handover checklist, rewriting a page against a clear brief, or producing a first draft from an existing template.
- Choose one finished example with a known acceptable result.
- Remove unnecessary personal or confidential information.
- Open a fresh conversation, select Sonnet 5.5 if available and keep the input and instructions fixed.
- Run the same task in your existing setup, also in a fresh conversation. If that model is no longer available, compare with saved, reviewed outputs and label this limitation.
- Compare accuracy, missing details, editing time and usability. Hide model labels from the reviewer where practical.
Keep the tools and supplied context comparable. If one run has web access, files or memory the other lacks, you are comparing two workflows, not isolating a model difference. That can still be useful, provided you record it honestly.
2. My team builds with Claude Code
Use a separate branch and one bounded task with an existing test, such as a small validation fix. Ask for no unrelated refactoring. A cleaner explanation does not prove the code works: inspect the diff and run the relevant tests and interface checks.
Claude Code’s /effort control changes reasoning effort; /effort auto restores the model default. Anthropic advises starting at the default and adjusting against the task. Record the setting rather than assuming that the same label means identical work across models. Official effort guide.
For your pilot, compare elapsed time, review effort and whether the change actually passes acceptance. Do not give a trial session production credentials or deployment authority just to make it more autonomous.
3. Sonnet already powers an automation or customer-facing app
Treat this as a migration, not a dropdown change. The official guide identifies breaking changes: Sonnet 5.5 rejects forced tool_choice values any and tool; the old thinking: disabled setting also needs adjustment. The guide describes between_tools for disabling up-front thinking, subject to its documented constraints. Migration checklist.
Ask the developer to test the actual request/response contract, tool calls, output validation and failure handling on a staging copy. Keep the production model unchanged until that passes. A connector or MCP supplies access; it does not establish a scheduler, approval policy or recovery procedure.
For a scheduled bot, also test a missed run, unavailable source and failed action. A successful answer in a chat window is not an end-to-end automation test.
What should a useful comparison measure?
An acceptance test is a task with explicit conditions for a usable result. It is more useful here than asking which response sounds cleverer.
As a small screening exercise, select five representative tasks: three routine ones, one with missing information and one with conflicting information. Five is a suggested starting point, not a statistically reliable benchmark or production certification. Repeat variable or high-impact tasks and expand the test set before rollout.
| Check | What to record |
|---|---|
| Accuracy | Are statements supported by the supplied material? |
| Completeness | Are all required fields and deliverables present? |
| Uncertainty | Does it ask instead of inventing missing details? |
| Human effort | How long does review and correction take? |
| Reliability | Does it finish, obey the scope and handle exceptions? |
For API workflows, add actual usage, retries and tool costs. For a subscription, record usage limits and people time; do not turn a vendor’s task-cost claim into a promised reduction in your subscription bill.
Decide the pass conditions before seeing the outputs. For a handover checklist, for example: no invented owner, no invented deadline, every action linked to a source note, and unresolved dependencies clearly marked. A fast answer that invents a commitment fails.
What prompt can I use for the first trial?
The following is an original, fictional exercise. Paste it unchanged into each setup you are comparing. It needs no customer data or connected tools.
Turn these fictional project notes into a handover table. Columns: action, owner, deadline, source note, open question. Use only the notes. Write “not specified” when a fact is absent. Distinguish an action from a target or dependency. Do not send messages, create tasks or use external tools.
N1: Operations will send the product list on Friday. No calendar date was recorded.
N2: The launch target depends on approval of the final content. Nobody was assigned to obtain that approval.
N3: Support asked for a training session. No owner or date was agreed.
After the table, list the questions that must be answered before anyone can commit to a launch date. Do not invent answers or describe the launch target as confirmed.
Check the output manually: “Friday” must remain an unresolved calendar date, the approval owner is unknown, and the training request has no agreed owner or deadline. These are the expected checks, not results observed from Sonnet 5.5. Passing this tiny exercise is only a first filter.
How do I move from a trial to daily use?
Keep one owner responsible for the pilot and one known-good setup available for rollback. Start with low-impact work and require a person to approve external messages or consequential changes. Grant only the access needed for that task; a prompt saying “do not send” is not a substitute for restricting permissions.
Also record which model actually answered. Anthropic documents automatic fallback for some flagged requests in Claude apps, while API fallback requires configuration. A fallback can change what your comparison measures. Fallback behaviour.
Use a simple decision rule:
- Adopt for this task if acceptance holds and the complete workflow improves.
- Keep testing if the results vary or one important exception remains unresolved.
- Keep the current setup if review effort rises, an integration breaks or the improvement is immaterial.
You do not have to choose one model for everything. A task that needs a quick, reviewable draft is different from an ambiguous decision with expensive consequences.
Want AI upgrades to improve the work, not add another experiment?
If your team only needs a better drafting assistant, a controlled trial in the existing product may be enough. If model choices affect connected systems, approvals, recurring costs and customer experience, the useful next step is to design the process and acceptance checks together.
Explore Ergonya AI transformation or tell us which workflow you want to improve. We can help identify where ready-made tools suffice and where a custom implementation is justified. For a concrete reporting workflow to test next, see the weekly AI sales report guide.
Sources and controls checked on 29 September 2026. Product access and behaviour can change. The exercises and images are illustrative; no customer results or independent model benchmark are claimed.