Sonnet 4.6 versus Opus 4.6: compare task outcomes before averaging the verdict

Define the work and the evidence for success

The 18 February 2026 description reports a roughly 15-minute comparison of Sonnet 4.6 and Opus 4.6 on production code. The chapter list names a SaaS and flight simulator. A working game, a useful landing page and a cheaper run are different outcomes, so keep separate notes for each rather than reducing the test to one score.

1. Start with the price discussion at 0:00 and task overview at 0:40, recording the source’s claims before accepting them.
2. Keep the same starting files and intended outcome identifiable for both model attempts.
3. Define what you will actually test in each output, including the core interaction and the visitor’s main task.

Preserve the failure alongside the redesign result

The coding comparison begins at 2:46. The chapter at 5:40 explicitly says Opus works and Sonnet fails, while the later redesign reveal at 9:46 and winner chapter at 13:12 favour Sonnet overall. These statements can coexist because different tasks reveal different strengths. Do not erase the failed attempt when evaluating the later visual result.

1. Watch the actual failure and note what action or state prevented completion, without assuming a later page redesign fixed it.
2. Compare the landing-page versions at 11:00, checking information hierarchy and the real visitor journey as well as appearance.
3. Record follow-up work and unresolved defects beside each model’s accepted output.

Interpret the token and price figures as a dated example

The description claims one model produced the better redesign using 30% fewer tokens while being 50% cheaper. Cost and token analysis appears at 14:01, followed by closing thoughts at 15:10. The source does not provide the complete usage ledger in its description, and this companion does not independently reproduce the percentages.

1. Review the recorded analysis for which task and usage measures the figures describe.
2. Separate token count, billed cost and elapsed time when comparing your own runs.
3. Include retries and checks needed to reach a usable result, and verify present model pricing separately before planning a budget.

The takeaway

A model can win a redesign and lose another task. Retain that detail when choosing the next model, rather than treating a cheaper historical run as universal superiority.