Choose Sonnet or Opus by the cost of a checked coding result

Define what the task asks the model to do

Luke’s short comparison asks when a cheaper coding model is sufficient and when a more expensive model is worth using. It includes examples from a live SaaS codebase and a Sonnet-versus-Opus test. The description supplies a framework, not exact model versions, a complete score table or current prices.

1. Write a bounded task with the files, expected behaviour and completion check. Distinguish a straightforward change with clear instructions from work that needs diagnosis, architectural judgement or several uncertain decisions.
2. Record the starting revision and inputs before trying a model. Decide which mistakes would be easy to correct and which could make the result unusable, so price is weighed against the actual job.

Compare usable output rather than the first response

The video discusses cost at 0:28, cheaper models at 1:00 and expensive models at 2:05, then shows the coding comparison at 3:35. Those sections help organise an experiment: an inexpensive first answer may still require substantial review, while a costly answer is not automatically correct.

1. Run the task with the selected model and inspect the saved changes. Repeat the relevant behaviour or test, noting missing requirements and any correction you had to request.
2. If comparing both models, use the same initial code and acceptance criteria. Keep the original outputs and follow-up instructions so you can distinguish first-pass quality from the final repaired result.

Make a reusable choice from the evidence

The useful decision is whether a route completes this type of task at an acceptable total cost. That includes usage, checking, waiting and rework. The recorded advice does not establish that every simple task belongs to one model or every difficult task to another.

1. Record the checked outcome, model route, usage and revision effort together. Verify current pricing for your own access method before converting usage into money.
2. Use the results to choose a default for similar small tasks, then revisit that choice when task difficulty or model availability changes. Keep examples where the default failed rather than averaging away the extra work.

The takeaway

Optimise for a correct, reviewable result. Compare the whole task and its revision effort, not just the price or length of one answer.