Claude Sonnet 5 and client web work: what to test first

A developer is halfway through a website for a physiotherapy clinic. The pages are drafted, the booking link works, and the owner wants to see a first version on Friday. Then, on Tuesday morning, the news arrives: Anthropic has released Claude Sonnet 5. Every thread says it's better at coding. Should she switch now, halfway through the job?

Not for this client, and not this week. Claude Sonnet 5 came out on 30 June 2026, and Anthropic describes it as its most capable Sonnet model so far for coding and for work where the model uses tools. Whether it's better for your client websites is something you find out on your own work, not from a chart. Finish the current job on the model you started with. Then give the new one a fair test: rebuild one small past project from the same brief, check it the way you'd check anything before a client sees it, and compare.

This article covers what changed and a test you can run on a past project.

What changed with Claude Sonnet 5?

Here is what Anthropic's announcement says, in plain words:

• It does more of a job before stopping. Anthropic calls it its most agentic Sonnet yet: it can make a plan, and use tools such as a web browser and the terminal (the text window where commands run) to carry it out.
• It gets closer to the larger model. The announcement says its results are close to Opus 4.8, Anthropic's larger model, at a lower cost, and a clear step up from Sonnet 4.6 on reasoning, tool use and coding.
• Fewer made-up answers, by Anthropic's own tests. Its safety testing found lower rates of hallucination (stating things that aren't true) and of simply agreeing with the user than Sonnet 4.6. It also resisted more attempts to hijack it with instructions hidden in web pages or files.
• You choose how hard it thinks. Sonnet 5 can run at different effort levels, trading cost against quality, and Anthropic raised usage limits in Claude Code to allow for the higher levels.
• It's the default on Claude's free and entry paid plans, and available on the larger ones.

None of that is a test of your work. Benchmarks measure coding tasks in general. Your clients care whether their opening hours are right and the booking button works on a phone.

Is Claude Sonnet 5 good for building websites?

It may well be. Some of the early testers quoted by Anthropic say it finishes long tasks that earlier Sonnet models left half done, and checks its own output without being asked. Those are exactly the habits that matter on a website build. They are also claims made in a launch post, about other people's code.

So treat the release like a new freelancer offering to help. You wouldn't hand them a live client on day one. You'd give them a job you've already done, compare the result with yours, and decide from there.

If you're new to building with an agent, start with how to use Claude Code to build a website for a client, then come back to the test below.

What should you test first?

Pick a finished project that was small and typical: a five-page site for a bakery, say, with a menu, opening hours, a map and a contact form. Use the brief you worked from, not your memory of it. Work on a copy in its own folder, so nothing touches the live site.

Then run these tests, one at a time, in a fresh session:

Test	What you give it	What a pass looks like
Build from the brief	The original brief and your design notes	Every fact matches the brief: name, hours, prices, phone number
Missing information	The brief with the prices removed	It asks, or leaves a clear gap, instead of inventing prices
One small change	"Add a gluten-free section to the menu page"	Only the menu page changes; the rest stays as it was
A fix with a reason	"The contact form doesn't send on phones" (plant a real fault first)	It finds the cause and tells you what it changed and why
Checking its own work	Ask it to review the finished pages against the brief	It finds its own mistakes, and doesn't mark everything as fine

The second test matters most for client work. A made-up price or an award the bakery never won is worse than a slow build, because a client may not spot it until a customer does.

If you've written Claude Code skills (saved instructions your agent loads when a task needs them) for your usual builds, include them. A new model can read the same instructions differently. Claude Code skills and plugins explains what they are and how to keep them tidy.

How do you switch models in Claude Code?

In a Claude Code session, run /model and pick Sonnet from the list, or type /model sonnet. Claude Code's documentation says the sonnet alias points to the latest Sonnet model, and that aliases move to new versions over time. To keep one project on a fixed version, set the full model name instead of the alias.

Two habits make the comparison fair:

1. One model per client job. Finish a project on the model you started it with. If you switch halfway, you can't tell whether a problem came from the model, the brief or the switch.
2. Same brief, same instructions, fresh session. Give both models exactly what the client gave you, and nothing extra.

What should you compare?

Speed is tempting to measure and tells you little. A model that finishes in half the time but needs an hour of fixes has cost you more. Compare these instead:

• Your fixing time. How long you spent correcting the result before you'd show it to the bakery.
• Invented facts. Count them. One is too many for a client site.
• Changes you didn't ask for. Anything outside the pages named in the request, from a tidied footer to a new colour.
• What it told you. Did it explain what it changed, and was the explanation true when you checked?
• Usage. How much of your plan's limit the job took, at the effort level you used.

Write the results in a short note with the date and the model name. When the next release arrives, you run the same test and compare against the note, not against a feeling.

Then do the checks you'd do on your agent's work before a client sees it. A simple routine is in how to review an AI built website before a client sees it, and it applies whatever model produced the pages.

What stays the same, whichever model you use?

The model is one part of the work. The rest of the job doesn't change with a release:

• Your agent still needs the client's facts. It can only get the hours right if it can read them. What MCP means explains the standard way to connect an agent to your notes instead of pasting them into every chat.
• You still decide what reaches the client. A better model makes fewer mistakes, not none. Approving what your agent sends before it goes anywhere is the habit that protects the client relationship.
• Your checks still come before the client's. A named version, checked on a computer and a phone, then shown to the client.

If you're a developer building client sites with an agent, Volant for developers describes the business side around that work.

If you run a one-person AI agency, test Sonnet 5 on a project you've already finished. If it passes your five tests, use it for the next new client job from the start, and keep the old note for the next release.