DEV Community: Dron Bhattacharya

Still leaving Claude Code on high effort for everything? It's not doing what you think

Dron Bhattacharya — Sat, 26 Sep 2026 06:40:42 +0000

Most people who use Claude Code a lot pick an effort level once and never change it. Usually it's something high, like one level below the maximum. Ask them why, and the honest answer is often:

"It feels safer. I haven't actually measured it."

I haven't measured mine either. But I recently read Thariq Shihipar's post Using Claude Code: Spending your effort. He ran the same tasks at each of Claude Code's five effort levels (low, medium, high, xhigh and max) and looked at what actually changed.

TL;DR: effort doesn't make Claude smarter. It changes how much Claude checks its own work, and how many decisions it makes without asking you.

That sounds like more effort is always better. It isn't. Extra checking pays off on some tasks and just burns time and tokens on others. And when a task is unclear, more effort can make Claude confidently build the wrong thing.

Here are the four findings that changed how I think about it.

1. Effort buys checking, not brains

The clearest example in the post is an HTML sanitizer: code that strips out every way someone could sneak JavaScript into a page. The model was Fable 5.1, one of Anthropic's newest models, and it tried the task 5 times at each effort level.

At low, each attempt took about two minutes. Claude wrote the filter in roughly one pass, tested it on one hand-written page, and passed 1 time out of 5.

At xhigh, it passed 5 times out of 5. One high-effort run took about 33 minutes. Claude went after its own first draft like an attacker would, read the parser's source code, ran a standard XSS test suite, and then wrote a fuzzer on top of all that.

It didn't get smarter. It got suspicious of itself.

So here's how I think about it now: effort is mostly about how much Claude double-checks itself, and how many calls it makes on its own, before it hands the work back.

Once you see it like that, running at almost-max all the time looks a bit silly. Some tasks need all that double-checking. A lot of them don't.

2. It fixes missed edge cases, not wrong approaches

The post has a chart that sorts every Fable 5.1 attempt by what went wrong. There are 370 attempts at low on the left and 370 at max on the right.

Chart from Thariq Shihipar's post. Each square is one attempt. Green passed, purple missed an edge case, blue made the wrong call.

Most failures are one of two kinds:

Missed an edge case. The approach was right, but Claude didn't test enough. For example, its own tests didn't catch a bug.
Made the wrong call. Claude got the task itself wrong. For example, it misread the requirement.

Going from low to max, missed edge cases dropped by more than half, from 59 to 24. Wrong calls only dropped by about a fifth, from 133 to 107.

That makes sense. More effort means more testing, and testing catches edge cases. But no amount of testing tells Claude it's solving the wrong problem.

The one failure that went up

One kind of wrong call actually went up: Claude picking the wrong meaning of an unclear task. At low it happened 25 times. At max it happened 47 times, almost double.

Thariq hints at why earlier in the post: at higher effort, Claude "will also make more assumptions on my behalf." The longer it works on its own, the more it guesses what you meant, and some of those guesses are wrong. To be fair, it could also be that these mistakes were always there and just got easier to spot once the sloppier ones went away.

Either way, if your task is fuzzy, more effort won't save you. A clearer task will.

3. A good spec shrinks the gap

He also tried some real builds on Opus 5.5. When he gave it a vague prompt to build a personal fitness and workout tracker app, the results were wildly different at each level. low took about 1.5 minutes and gave him a log with a graph. max took 67 minutes and threw in extras like a heat chart.

Then he had Claude interview him first and turned his answers into a detailed spec. This time, every effort level built a fairly similar app. low just got there in 16 minutes, while max took 79. The spec filled in the gaps that extra effort had been filling before.

That's why his go-to loop for new features looks like this:

Start with a rough spec and have Claude interview you to fill it out.
Build on low.
Review it and iterate, still on low.
Verify and test on high, since that's where the missed edge cases from point 2 get caught.

How I actually use it

My own habit is much less scientific than any of this.

I keep effort on the lowest setting when I'm working alongside Claude and just want things done fast. When I hand it a task and walk away for a while, I turn it up.

There's no data behind that. It just felt right: when I'm sitting there, I'm the one checking the output, so I'd rather have quick turns. When I'm gone, nobody is checking, so Claude might as well do it.

Reading the post, I noticed it lines up with something Thariq says: the right level depends on how much you want to stay in the loop. I had the right instinct and no evidence. The post gave me the evidence, and one blind spot I hadn't noticed.

Points 2 and 3 are changing one thing for me: before I walk away, I'm going to let Claude ask its questions first. Otherwise I'm leaving it alone on a long run, and going by that data, that's exactly when it's more likely to guess wrong about what I meant.

Conclusion

Effort isn't a quality dial you set once and forget. It decides how much Claude checks its own work, and how many calls it makes without you.

So match it to the task:

More effort helps most when a task is full of hidden edge cases, like security or hardware work.
It helps least when the task itself is unclear. A better spec does more there than a higher effort setting.

You can switch levels mid-conversation with /effort, and it doesn't break the prompt cache. So there's no real reason to leave it on one setting.

If you use Claude a lot, the original post is worth reading. It has animated versions of the charts I talked about here.

If you've ever compared two effort levels on the same task, share your findings in the comments.

R2-Score Explained

Dron Bhattacharya — Fri, 13 Feb 2026 04:14:43 +0000

Learning Outcomes

Define the R2-score and its role in regression analysis
Interpret numerical R2 values to assess model fit
Identify specific scenarios where R2 is helpful or misleading.

Why do we need R2-score?

Imagine we are asked to guess the CO2 emissions of a car we have never seen. Without any data (eg. engine size, fuel consumption), our safest bet is to guess the average of all known cars. Which means, for all cars we always predict the mean CO2 emission.

But can prediction be better than the mean? Yes

We can build a linear regression model which uses fuel consumption as a feature to predict the CO2 emissions. Now our predictions are much closer to the actual values than just guessing the mean!

But how can we quantify how much it has improved with respect to the mean? This is exactly what the R2-score tells us.

A score of 1.0 indicates a perfect fit, where every data point sits exactly on the regression line. Conversely, a score of 0.0 suggests that the model is no better at predicting the outcome than simply guessing the average value every single time. And if the model is somehow worse than guessing the average, R2-score becomes negative.

Formula

R² = 1 - (Variance remaining with model / Total variance)

Components:

Total Variance = How spread out the actual values are from their mean
- Squared differences: (actual - mean)²
Variance Remaining with Model = How spread out the prediction errors are
- Squared errors: (actual - predicted)²

How to interpret R2-score?

To truly grasp the R2-score, we must understand Variance. Variance measures how far the data points are "spread out" from the mean.

Let's assume that we got R2-score=0.73 using Engine-size as a feature to predict CO2.

What does this mean?

It means, that the model was able to capture 73% of the influence of all the features that makes the target variable change. The other 27% of the uncaptured influence can be other features like fuel consumption, number of cylinders or fuel type. So if there is a change in the target variable caused by this 27% of left out influence, our model will not be able to predict that.
From that statement we can also infer that the feature Engine-size has 73% influence on the target variable CO2 emission

When to use R2-score and what are its limitations?

The R2 score is a fantastic tool for comparing different models on the same dataset. We can quickly see if "Fuel Consumption" is a stronger predictor than "Engine Size". If Model A has an R2 of 0.92 and Model B has 0.75, Model A is the clear winner.

But note that R2 is not suitable for comparing models across different datasets.

Can we use R2 score for Non-Linear models? While R2 can be technically calculated for non-linear regression, it is fundamentally designed for linear models and may not accurately reflect the fit of non-linear models, making other metrics more appropriate.

Another very important thing to remember is that a high R2 does not guarantee that the model is accurate enough for real-world use. It is a relative measure, not an absolute one. The model might explain 99% of the variance, but if the remaining 1% results in an RSME of ±500 tons of CO2, the model might still be useless.

While R2 tells us how well the model fits the trend, RMSE tells us how big the actual error is, in actual units.

Summary

The R2 score measures how much better a model is compared to a "dumb" baseline that just guesses the average. A score of 0 means no value is added; a negative score means things got worse and a score between 0 and 1 means the model accounts for variance better than the average.
Think of R2 as a percentage of the data's "wiggle" that a model understands. If R2 is 0.80, the model captures 80% of the reasons why the target variable changes.
Never rely on R2 alone. It tells about correlation and fit, but not about prediction precision. Always validate high scores with error metrics like RMSE to ensure the model is practical.
High R2 on training data doesn't guarantee good predictions outside the data range.
R2-Score works best for linear models.

Review Questions

If a model has an R2 score of -0.5, what does that imply about its predictive power compared to a simple mean?
Why is an R2 of 1.0 often a red flag for "overfitting" in real-world data?
Why might a model with a high R2 still be dangerous to deploy in a high-stakes environment (like healthcare)?