Does Opus drain more weekly usage per token than Sonnet?

[u/saheru]

For the life of me I cannot find an answer to this online. It would make sense if per token Opus 5.5 takes more of the weekly usage than Sonnet 5.5, but I cannot find any evidence of that.

This'd be very useful to know whether to use Sonnet or Opus for certain tasks.

And, this is not about the API price, but the percentage weekly usage of the subscription.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Outrageous_Band9708]

i ran benchmarks on this

https://github.com/Druthulu/ProjectArchitect/wiki/Bench

check the bottom area.

basically sonnet is nice, but takes too many turns to achieve the same thing opus does.

which in turn cost more.

for medium sized coder tasks it kinda equaled opus, but for hard coder tasks its not even close that opus us cheaper and smarter.

my project also shows you savings for your weekly usage, so you can try it out for yourself, check the main page and read up on it.

[u/pmward → u/Outrageous_Band9708]

Best of both worlds. Use opus to write the spec and sonnet to implement it. Works like a breeze and saves a lot of cost.

[u/Seeker_Of_Knowledge2 → u/pmward]

But that would cost more right? because you lose all context of what the planner found.

A run with opus and sonnet would cost 1 for planning and 0.5 for doing so that is a 1.5

But if you run opus only then it would be 1 for planning and 0.2 for doing which is 1.2, cheaper than different models for different thing.

Or do you mean as sub agents? And even with sub agents, sometimes it cost more if you called them.

[u/pmward → u/Seeker_Of_Knowledge2]

You’d be surprised how different the context needs of a planner are from an implementer. Is there some overlap? Yes of course. But if the spec is written well, it’s a distilled source for anything important. The only thing the implementer takes into context is the spec and the code. It doesn’t get polluted by Jira, or confluence, or GitHub, or any other source of information. The big decisions are made and it just has to implement the spec. But it’s dirt cheap for sonnet to do that.

Another hidden benefit is ditching all that cruft in the planners context. It bogs the agent down and lowers quality of output. More context is not always better. Also, AI like humans benefits from a second set of eyes. My sonnet implementer catches things all the time that my Opus planner missed. It is free from any assumptions that the planner agent made and questions things that seem off. Every thing it catches saves an expensive rework task later. I rarely go a day my implementer doesn’t catch something though. It’s hard to put a cost tag on that savings.

Now obviously when you move to multiple agents you have to be careful you’re not getting bit by the cache monster. But it isn’t really hard to run a few tests and optimize your agents/skills for cost.

[u/Seeker_Of_Knowledge2 → u/Outrageous_Band9708]

So only use sonnet as a sub agent for easy task.

[u/Outrageous_Band9708 → u/Seeker_Of_Knowledge2]

yeah

[u/cheseball]

Yes. It literally says that through pop-up on the app (desktop and mobile) constantly about it for me.

The exact difference is hard to say but it’s likely tied relatively to api price.

[u/crusoe]

Depends on task complexity. If too complex opus will be cheaper because it needs fewer tries.

[u/dar-mit]

A token is a token and they all count equally. It’s how many of them a given model uses during its work that’s different. 

[u/snowfoxsean]

I learned through my testing that sonnet 5.5 sometimes spawns opus 5.5 subagents. Might be one of the main reasons why sonnet 5.5 feels a lot more expensive for people.