Big coding session. 60 messages. I fired /effort max three times, and three times I killed it. Result: "partially_achieved." Three rounds of 25 minutes watching Claude spin in circles while my actual task sat there, untouched.
Here's the thing. I did what you're supposed to do. Claude Code suggests /effort medium at install, I don't even think about it, I switch to high right away. Because I can't burn through all my tokens anyway, and because Boris Cherny (the guy who created Claude Code) said to always use the most capable setup.
That didn't fix anything. Because the problem was never the effort level. It was what I was putting in front of it. And nobody talks about that part. The influencers would rather congratulate each other for finding the right slider position.
TLDR: /effort max doesn't compensate for bad context. My data from 25 effort commands confirms it. The sessions that one-shot complex tasks all share the same opening pattern: a structured plan before the first keystroke. Change your default from medium to high, yes. But if that's all you change, you'll spend more tokens looping through the same mistakes. The real sequence: structured plan first, then max effort. In that order.
What Boris Cherny understood before the rest of us, and what my own session data confirmed after a week of tracking, is that the slider is the last thing you should touch. Not the first.
The Session That Made Me Question the Slider
Session 271c43dd. I remember it because /insights flagged it later as one of my longest.
60 messages. Three times I escalated to /effort max during the same session, hoping to brute-force my way through a cover image bug that should have been straightforward. Claude went deep on iCloud sync issues. Then pivoted to fnm path conflicts. Then dove into node_modules resolution. Twelve hours of context, and the model was thinking harder and harder about the wrong things.
The covers never got fixed.
It's like fighting a boss in an RPG where you keep using the same maxed-out spell, over and over, and the boss just heals. At some point you have to stop and read the actual bestiary entry. The spell was never the problem. You were hitting the wrong weakness.
I didn't have the wrong setting. I had the wrong corridor.
That realization sits weird, because it means the thing everybody is busy optimizing (the slider) is the last variable that matters, not the first.
Max effort in the wrong corridor is just paddling faster.
Before figuring out what actually fixes this, you need to understand what the slider is supposed to do, and why even its creator doesn't stop there.
The Creator of Claude Code Runs Max. But That's Not His Real Move.
Boris Cherny is something of a demigod to me. Half human, half daemon process that never stops shipping.
The man ships 20 to 30 pull requests every day. Not a single line edited by hand since November. Opus 4.6, extended thinking, maximum effort, always on. Before Anthropic, he spent 7 years at Meta leading code quality across Facebook, Instagram, WhatsApp, and Messenger. He created Claude Code alone in September 2024, starting with a terminal chatbot that could tell him what music he was listening to. The whole thing was, by his own words, accidental.
His reasoning for always running the most expensive model is counterintuitive: it's actually cheaper. Sonnet needs three iterations to land on the right result. Opus needs one. The total token cost for Opus ends up lower despite the higher per-token price, because you stop paying for correction loops. Most people look at the price tag per token and pick the cheaper model. Boris looks at the total cost per completed task and picks the smarter one.
But that's the part everyone already quotes from his interviews. The part they skip is what happens before any of that matters.
Boris starts roughly 80% of his sessions in plan mode. And plan mode is not some sophisticated orchestration system. He described it himself: all it does is inject one sentence into the prompt that says "please don't write any code yet." That's the whole thing. He coded the feature in 30 minutes on a Sunday night after reading GitHub issues where users were already doing this naturally in their prompts. Shipped it Monday morning.
The principle underneath: once the plan is good, the code is good. His words, not mine. And it's probably the single most important thing he's said about Claude Code that nobody seems to actually internalize. The model, the effort level, the extended thinking, all of that comes after the plan. Always after.
He even said plan mode probably has a limited lifespan. Maybe a month. Because eventually the model will just figure out on its own when to plan. But right now, in this window, the human's job is to get the plan right. The prep work before you start cooking. Everything else follows from there.
(Worth noting: Boris works at Anthropic with privileged access to the model. He ships at a velocity most of us won't match, and his workflow is optimized for high-velocity delivery of 20-30 PRs a day. The pattern transfers to your projects. The exact numbers probably don't.)
Boris does max effort. But he does plan mode first.
21 Out of 25: What My Effort Commands Actually Show
The raw numbers first.
/insights audited my last 25 effort commands since March 16th. 21 times I used /effort max. Once /effort medium. Once /effort high. Two checks. I'm not someone who starts low and escalates gradually. I go straight to max on anything that looks even slightly non-trivial.
And right now, this is happening everywhere. Anthropic just officially switched Opus 4.6 to "medium effort" as the default for Max and Team subscribers. The changelog post collected over a thousand likes. Devs across the board are discovering this setting exists and rushing to crank it up. As Todd Saunders put it: most people using Claude Code are getting maybe 40% of what the model can do with the defaults.
So yes. Change the default. That part is settled.
Now the number that actually matters: my worst sessions, the 60-message marathons ending in "partially_achieved," those ran /effort max too. Same slider position as my best sessions. Same model. Same extended thinking. The difference in outcome was not the effort level.
It's like having two kitchens with the exact same professional oven. One chef did the prep work upfront with structured prompt contracts. The other just cranked the temperature and hoped for the best. Same oven. Very different dinners.
(The /insights data doesn't log which effort level is active per conversation turn, only when you type the slash command. So this analysis is based on observed patterns, not direct effort-to-outcome correlation per message. The pattern is still hard to ignore.)
21 times max effort. My worst sessions too.
What separates the sessions that one-shot from the sessions that spiral? The answer showed up in the 2-message sessions.
The Real Variable: What Happens Before You Type the Task
Here's what my actual session history reveals when you sort by efficiency.
Sessions where /effort max changed the outcome: complex refactoring with non-regression tests (session 8fd1e558). Writing the skeleton for my book on prompt contracts (session ae7d6686). Architectural bugs where Claude needed to reason across multiple files at once. Tasks with genuine ambiguity where the model's deeper reasoning actually had something useful to chew on.
Sessions where /effort max changed nothing: wrong repo context ("no, the Astro blog, not this one"), scope drift where Claude started modifying files I never mentioned ("why did you touch ollama, I didn't ask for that"), ambiguous opening prompts where I described my frustration instead of describing the task.
And the sessions that one-shot? The 2 to 4 message sessions that resolved complex tasks on the first try?
They all open the same way.
"Implement the following plan:" followed by a structured context block.
Four of my ten most efficient sessions use this exact prefix. A 2-message session with a structured plan consistently outperforms a 60-message session with /effort max and no upfront context. Every single time in my data. It's not even close. The 2-message sessions feel almost boring, like watching someone follow a recipe. The 60-message sessions feel like a raid with no tank and no healer. Everyone's DPS is maxed out but the party wipes anyway.
The breakdown that came out of this is not complicated:
/effort max matters when the task has genuine architectural ambiguity. Multiple files, non-obvious dependencies, reasoning that requires holding several constraints in parallel. For those tasks, max effort is worth the extra response time.
A structured plan upfront matters on everything else. Routine features, bug fixes, migrations, anything where you know what the outcome should look like but the model doesn't have enough context to go in the right direction.
For critical tasks, you want both. Plan first, max effort second. That combination is what one-shots.
(One caveat that matters: "Implement the following plan:" works when the plan is actually structured. A vague plan plus max effort gives you the same result as a vague prompt plus max effort. The quality of the plan is the variable, not its formal presence.)
"Implement the following plan:" beats /effort max without context. Every time.
What Boris calls plan mode, what my data calls "Implement the following plan:", it's the same principle. And it's missing from 90% of Claude Code workflows I see online.
Change the Default. Then Change What You Put In Front of It.
The medium default is a decision Anthropic made for cost management at scale. Not a recommendation for your workflow. The changelog confirms it. If you're on a Max or Team plan and you're still running medium, you are leaving capability on the table. Switch to high as your baseline. Reserve /effort max for tasks with real architectural complexity, the kind where Claude needs to reason across multiple files and hold several constraints in its head. On mechanical work (deploys, pushes, repetitive migrations), high is enough and noticeably faster.
But if changing the slider is the only thing you change, you will spend more tokens arriving at the same wrong answer with more confidence.
Garry Tan optimized the review layer, catching mistakes after Claude writes code. Most devs optimize the slider, the model's raw power. Neither one addresses the actual bottleneck: what Claude understands before it starts working. The input layer. The one that determines whether all that processing power goes in the right direction or into a wall.
Three things to remember.
One: change the default from medium to high at install. It's an Anthropic decision to manage infrastructure costs, not a recommendation for your workflow. The changelog confirms it, it's done, next.
Two: /effort max doesn't compensate for bad starting context. My 25 commands show it. Boris Cherny knew this from the start. That's why he coded plan mode on a Sunday night before ever talking about which model to use.
Three: the sequence that works is depressingly banal. A structured plan. "Implement the following plan:". /effort max. In that order. It's not glamorous. But it's what my 2-message sessions that one-shot have in common, and what my 60-message sessions don't have.
The /effort slider is the last thing to touch, not the first.
Sources & links
Boris Cherny on Claude Code workflows, plan mode, and the Opus cost paradox: YC Light Cone podcast, Pragmatic Engineer podcast, Lenny's Podcast (2025-2026).
Anthropic changelog on Opus 4.6 medium effort default for Max/Team subscribers: @ClaudeCodeLog.
(*) The cover is AI-generated. Boris's plan mode was also generated in 30 minutes, so at least the cover is in good company.
Top comments (0)