You typed one sentence. "Add a function that sorts this list by date." Claude Code answered in a few seconds, the diff looked exactly right, and then you glanced at the usage bar in the corner and it had jumped from 59% to 100%. Not over the session. In one reply.
If you searched for that, you already know you're not alone. "Claude Code users hitting usage limits way faster than expected" is its own genre of forum post right now. People are watching one clean, boring exchange eat the rest of their five-hour window, and the explanations on offer are either "AI is expensive, deal with it" or nothing at all. There is a specific, fixable reason this is happening to Pro and Max subscribers this week, and it has a name: effort.
Here's the fix, before the mechanism: open '/effort' in Claude Code, and if it reads high, drop it to medium. That's the move — everything below is why it works.
The setting that's driving your meter
On 24 July, Anthropic shipped Claude Opus 5 with a control called effort. Five levels: low, medium, high, xhigh, max — though xhigh and max exist for the rare job that dwarfs the rubric below; this piece lives on the three rungs you'll actually reach for. Effort governs how much the model thinks before it answers — more effort means more internal reasoning tokens, the units your usage meter actually counts in, spent working the problem before you see a single word of output.
Here's the part that explains your jump from 59 to 100: the default is high. Not medium. High. Every request you send, including "sort this list," starts by assuming it might need the model's fuller reasoning pass unless you tell it otherwise.
In Claude Code, the setting lives behind the '/effort' command — type it and you get the same five rungs, applied to everything you send in that session. If you're calling the API directly, it's 'output_config.effort', nested inside 'output_config' rather than sitting at the top level of the request, set to one of 'low', 'medium', 'high', 'xhigh', or 'max'.
Why does that burn your usage window specifically? Pro and Max plans meter you against a rolling token budget, not a dollar figure — you don't see a price, you see a percentage. Thinking tokens count against that budget the same as output tokens do. Effort=high means the model does substantially more of that invisible reasoning work per request. On a genuinely hard problem, that's the point — you're buying depth. On "sort this list by date," you paid for depth nobody asked for, and the meter doesn't know the difference between a request that needed it and one that didn't. It just adds up tokens.
This is also why Claude Opus 5 can feel slow on simple asks: it isn't slow, it's thinking harder than the task called for, by default, and you're waiting for reasoning you didn't need.
The rubric, not the vibe
The fix isn't "always turn it down" any more than the problem was "always leave it on high." Both are the same mistake — picking a setting on reflex instead of by looking at the task in front of you. What you actually need is a rule you can apply in the two seconds before you hit enter.
Stay at medium (or drop to low) for:
- CSV or list sorting, filtering, reshaping — anything where the transformation is mechanical and the output shape is obvious before you start
- Boilerplate scaffolding — a new component, a standard CRUD endpoint, a config file that follows a pattern you've used ten times
- Known-shape answers — "what does this error mean," "write the regex for a US phone number," anything with one clearly correct form
Reach for high only for:
- Multi-file refactors, where the model has to hold several files' worth of context and reason about how a change in one ripples into the others
- Auth or money logic — anything where a subtly wrong answer costs more than a retry: permission checks, payment flows, anything touching who-can-do-what
- First-time architecture calls — the decision you're making once for a whole project, where getting it wrong means unwinding real work later
That's three or four items on each side, not "use your judgment" dressed up as advice. If the task you're about to send fits the left column, it doesn't need high effort, full stop — you're not sacrificing quality, you're stopping the model from doing work you didn't ask for and won't use.
This lines up with what people running their own comparisons are already finding and posting: "at medium effort it drops to almost half the cost, and is probably sufficient for 95% of coding tasks." That's not a marketing claim, that's someone timing the same prompt at two settings and reporting what they saw — which is exactly the kind of check you should run once on your own workload before you trust any rubric, mine included.
Setting it once versus setting it every time
'/effort' in Claude Code applies to the session you set it in — you're not retyping it before every message, you're picking a baseline and overriding it when a specific request clearly needs more. That's the actual workflow: set medium as where you live, and reach for '/effort high' the way you'd reach for a bigger wrench — when the bolt in front of you actually needs it, not as a standing precaution.
If you're building against the API directly rather than through Claude Code, the same idea applies per request:
import anthropic client = anthropic.Anthropic() response = client.messages.create( model="claude-opus-5", max_tokens=1024, output_config={"effort": "medium"}, # low | medium | high | xhigh | max messages=[{"role": "user", "content": "Sort this list of dicts by the 'date' key."}], ) print(response.content[0].text)
Swap 'output_config={"effort": "medium"}' for '"high"' on the calls where the task actually earns it — a migration script touching a dozen files, a permissions check, the first pass at a system you haven't designed before. Everything else, leave it where it is.
Why this matters
The instinct to leave everything on the highest setting is the same instinct that leads a beginner to over-engineer a first project — more must be better, so why would you ever turn it down? But "more thinking" isn't free intelligence sitting there for the taking. It's tokens, and on a Pro or Max plan those tokens are the thing standing between you and a five-hour wait. Somebody in the threads already found the compressed version of this: "it overthinks quite a bit above medium effort, try using that." That's not a complaint about the model being bad. It's a correct diagnosis of a setting left in the wrong place.
The people writing the "here's the rubric" posts elsewhere online mostly got the shape of it right — low for boilerplate, high for hard problems — but they're writing for someone tuning API costs in a spreadsheet, not for someone who just watched their whole afternoon evaporate on one function. The rubric only actually helps once you know why the meter moved, and most of what's out there skips straight to the table. You now have both halves: the mechanism, and the rule.
One more thing worth naming plainly: this is effort, not a different, more capable model hiding behind a toggle. Same Claude Opus 5, same weights, same everything — what effort mostly changes is how long it's allowed to think before it commits to an answer. Turning it down doesn't make the model dumber for the task at hand; it just stops it from spending your budget on reasoning depth that particular task never needed.
Final thought
You already made that switch at the top. The one thing left to remember: the next time you're about to send a multi-file refactor, something touching auth or payments, or a first-time architecture decision, bump it back up for that one request — then drop it down again when you're done.