This is a nice dive into effort levels. It is specific to Claude Code and Opus 5.5 and Fable 5.1, but it should loosely generalise to other models too.

WHAT IS EFFORT?

At a high level, effort gives the model an approximation of how much compute you want it to spend on the task. It’s somewhat related to your modeling of the difficulty of the task.

Think of it this way, if someone asked you to do something in 12 hours straight, you might assume they just want you to do it and try very hard. If someone asked you to do the same task in 1 hour, you’d try to get them the best version that meets their task and then expect to iterate from there.

Or, you might push back and say the task requires at least 3 hours and then work for 3 hours to deliver it.

You should think of effort in the same way. Claude will always try and do your task reasonably, but higher effort will involve Claude taking more independent action for judgement and verification.

Thariq also dives into several examples, things he built, with visual examples, and also comparing how Claude performed against different tasks in the Terminal-Bench 3.0, a community-sourced benchmark using different effort levels.

Most of this seems intuitive: higher effort levels think more and solve problems better where lower effort offers lower quality output most of the time, more so on more complex tasks. But is context dependent and not always true.

One example stood out to me is that with tasks that are very well specified, performance didn’t differ that much across the different effort levels. Let’s say there is a clear spec for a large feature, if it’s well defined, using a low effort level will run a lot faster and likely still do a really good job compared to higher effort levels as less assumptions need to be made and less edge cases thought of, as the spec should cover these already. So low effort level could be a good workhorse, then use a higher effort level for adversarial and security reviews.

For regular software engineering, particularly new feature work, the effort level depends a lot on how in the loop I want to be. Low effort allows Claude to respond quickly with a starting point, higher effort levels will get more work done but Claude will also make more assumptions on my behalf.

A particularly fruitful loop for feature development I’ve been using is:

• Give Claude a spec and ask it to interview me about any details I’m missing
• Implement it on low effort
• Review to make sure it got the gist of it correct, iterate on low effort as needed
• Verify and test on high effort

Some of this is probably somewhat subjective and will vary wildly depending on context and complexity of tasks. But definitely worth more experimentation with these latest models to get a good feel for how to best utilise effort levels.

I can be a little lazy with this at times, if I have the quota available I tend to just use higher effort levels and the strongest model, usually high or xhigh for most tasks. I say lazy, but really it’s about just wanting the highest quality output first time, especially for high stakes software. I do like the idea of being able to use low effort for a much faster build with a well defined task to speed up build time, and then review and verify with say xhigh.

SemiAnalysis did a test on Anthropic/Claude subscription plans, running long horizon tasks until they maxed out.

The subscriptions are far more generous than API pricing.

When I first started using these tools I went the API route as my personal usage fluctuated a lot. But after a couple of months it was clear this worked out a lot more expensive and so switched to the paid plans even if not using all the quota.

Go with the paid plan.

Anthropic partnering with SpaceX to lease their Colossus 1 data center (over 220,000 NVIDIA GPUs).

While that on it's own is interesting, the astonishing side effect of that is a sharp increase in usage limits in paid Claude plans and their APIs.

The following three changes—all effective today—are aimed at improving the experience of using Claude for our most dedicated customers.

• First, we’re doubling Claude Code’s five-hour rate limits for Pro, Max, Team, and seat-based Enterprise plans.
• Second, we’re removing the peak hours limit reduction on Claude Code for Pro and Max accounts.
• Third, we’re raising our API rate limits considerably for Claude Opus models.

I think people will generally appreciate this too:

Finally, we recently made a commitment to cover any consumer electricity price increases caused by our data centers in the US. As part of our international expansion, we’re exploring ways to extend that commitment to new jurisdictions, as well as partnering with local leaders to invest back into the communities that host our facilities.

The title here, a paraphrased quote from [Gary Marcus], on TNW, today, evaluating a claim from “OpenAI president [who] says AI is now writing 80% of the company’s code”.

Marcus' specific point about coding is structurally important: a model that produces code which compiles and passes the tests it was given is not the same as a model that produces correct, secure, maintainable, well-architected software. The first is verifiable in seconds; the second requires the kind of judgement that has been the historical bottleneck on engineering productivity. Brockman acknowledges the gap, even as he argues it is closing. "The technology we have right now is very jagged," he said in the Big Technology interview. "It is absolutely superhuman at many tasks. When it comes to writing code, those kinds of things, the AI can just do it. But there's some very basic tasks that a human can do that our AI still struggles with."

Realism re AI coding is knowing that next-word prediction gets us a surprisingly long way in writing code, but less far in making sure that code is robust. Coders (especially vibe coders with little experience) beware

As good as these tools are getting — and they are getting really good and helpful — I don't see a non-technical person, say a product manager or marketing person, being able to steer and coerce these LLMs into producing software that any company should be willing to expose to the internet and their user base if they care about robustness, security, reliability and maintainability of the system. Especially if revenue and reputation are on the line.

While all the talk is about Anthropic’s “terrifying” new Mythos model, and it being too dangerous to release to the public, it looks like we may be able to get our hands on an upgraded Opus 4.7 in the meantime, possibly as soon as this week.

While 4.5 and then 4.6 were total game changers, there is still often frustration working with them, as with all other models. If 4.7 is anything like the upgrade from 4.5 to 4.6, then we should see a notable and much-welcomed increase in capability.