On Opus 5.5, medium finished my requests 2.8× faster than max, and needed only 1.3 points more corrections. But in an earlier round there was one kind of work where max clearly won, and the gap between the two almost disappeared once my instructions got longer.
I build apps on my own. So far I have shipped 132 of them to Google Play and the App Store, and most of that work happens with Claude Code. I kept wondering whether leaving the effort level on max actually got me better results, or just made me wait longer. So I counted.
How I measured it
Claude Code keeps its conversation logs on my Mac (~/.claude/projects), and each request records the effort level and model it ran with. I pulled every request I typed myself from July 30 to October 18, 2026: 11,447 in total, with automated runs left out.
For quality I used one signal: was my next message a correction? If a reply was followed by something like “no, that’s not it” or “redo this”, the request didn’t land on the first try. It’s a rough measure, but those do-overs are exactly what eat my time.
Round 1: xhigh vs max, and where max won
From late July to late September I was mostly on Opus 5, switching between xhigh and max. Overall the two were almost tied on corrections (6.6% vs 6.1%), but max took about 1.4 times as long per request.
The type of work made the real difference:
New apps and planning were the clear win for max. Plans I started on xhigh needed me to step in about one time in five; on max that fell to 4.6%. When the job is figuring out what to build, extra thinking pays off. For bug fixes and releases, where the task is already defined, xhigh actually needed fewer corrections.
That was the rule I followed for a while: max for planning, xhigh for the rest. Then I moved to Opus 5.5, and that rule stopped being the obvious choice.
Round 2: dropping to medium on Opus 5.5
From September 30 I mostly worked on Opus 5.5 and set the effort to medium most of the time: 2,457 of the 3,518 requests since then. To keep the model change out of the picture, this comparison uses Opus 5.5 only.
medium finished each request in 0.6 minutes against 1.7 for max, which is 2.8 times faster. Corrections went from 2.5% to 3.8%. Per 100 requests, that’s roughly 110 minutes less waiting in exchange for one or two extra corrections. high landed close to medium on both counts.
The length of my instructions changed the picture more than the effort level did:
On short requests max still had a real edge (3.4% vs 5.7%). On long, specific requests the two were almost even (1.5% vs 2.1%). The more context I gave up front, the less the extra thinking added.
Sonnet: stay on xhigh
On Sonnet, max took 2.4 times as long to start replying and wrote 2.5 times as much output as xhigh, yet corrections went up, from 5.0% to 6.7%. I run Sonnet on xhigh.
The rules I use now
- My default is Opus 5.5 on
medium. Bug fixes, releases, features, questions and chores all start there. - I write longer, more specific instructions instead of turning up the effort.
- I go up to
maxfor work that is expensive to undo, and for anything I can only describe in one short line. - Work where I already know what to change and where (copy, colors, translations, a scripted release) goes to Sonnet on
xhigh. - I pick the model when the session starts. Switching mid-conversation means the new model can’t use the cached context, so the next message re-reads the whole conversation.
In one sentence: a more specific instruction is cheaper than more thinking.
Limits of these numbers
- This was not a randomized experiment. I may have reached for higher effort on harder jobs.
- Of the 473 Opus 5.5 requests on
max, 468 came before September 29, while almost allmediumrequests came after. Same model, different period and mix of work. - I have no Opus 5.5
maxdata for new-app planning, so Round 1’s “plan onmax” result is untested on 5.5. Opus 5.5 onmediumhad a 2.0% correction rate on that kind of work (24 sessions). - “Correction” and “type of work” were classified by keywords, so treat them as rough.
- My first count used each session’s final setting and gave the opposite answer. Counting per request fixed it, and it’s a reminder that what you count with can flip the result.
Raw numbers
Round 1, all models, through September 29:
xhigh | max | |
|---|---|---|
| Sessions / requests | 222 / 1,389 | 350 / 6,198 |
| Time to first reply | 9.7 s | 11.4 s |
| Time to finish a request | 1.6 min | 2.3 min |
| Output tokens | 4,745 | 5,532 |
| Next message was a correction | 6.6% | 6.1% |
Round 1 by type of work (Opus models):
| Type of work | Corrections xhigh / max | Time per request xhigh / max |
|---|---|---|
| New app / planning | 19.6% / 4.6% | 2.4 / 2.6 min |
| Adding a feature | 6.7% / 3.6% | 2.4 / 2.4 min |
| Bug fixes | 4.4% / 6.6% | 1.8 / 2.5 min |
| Releases & deploys | 2.5% / 5.6% | 3.0 / 2.6 min |
| Everything else | 7.8% / 7.1% | 1.7 / 2.4 min |
Round 2, Opus 5.5 only (xhigh had just 8 sessions and is left out):
medium | high | max | |
|---|---|---|---|
| Sessions / requests | 129 / 2,454 | 57 / 818 | 30 / 473 |
| Time to first reply | 4.6 s | 4.4 s | 9.3 s |
| Time to finish a request | 0.6 min | 0.7 min | 1.7 min |
| Output tokens | 2,119 | 2,313 | 6,826 |
| Next message was a correction | 3.8% | 4.2% | 2.5% |
