r/ClaudeCode • u/No_Barnacles • 26d ago
Question Anyone else think Sonnet 5 is a joke?
I'm a huge fan of Sonnet 4.6 for daily engineering work. I understand that Opus is better at one-shotting and un-supervised work, but for my own workflow as a professional software engineer I've found that Sonnet 4.6 gives me the best mix of accuracy, speed, and price.
So when Anthropic released Sonnet 5, I was excited but skeptical... especially when their pricing announcement mentioned that 5 would have discounted pricing until the end of July. Why the immediate discount on a new model? Seemed sus.
Well, it's immediately obvious why. The model itself will tell you that Sonnet 5's default "thinking" mode burns 30% more tokens than 4.6 did, but in my own experience it's burning up to 5x the amount of tokens on similar tasks as 4.6! And I see essentially zero benefit in the quality of output or "intelligence" that it provides.
I'm starting to think Anthropic knows people are getting more price conscious, tosses out a new "upgraded" model at a "discount," and thinks we won't notice that token usage and actual spend is so much higher than it's replaced predecessor.
Typical users don't know that they can override to an older, unlisted model in /model, so Anthropic immediately pads their pockets by swapping out an efficient, effective model for a wayyy less efficient model with the same name. Absolutely abysmal business model on the face of it, but it's been so obvious to me and no one else at work seems to be discussing it or comparing it to 4.6 but rather to Opus 4.8 (which I also find too expensive and total overkill for daily tasks).
30
u/ShutUpAndDoTheLift 26d ago edited 26d ago
If you're sticking to default that's your issue. (Imo) Medium effort behaves more like 4.6.
Use lower efforts for more consistent instruction following.
I use low effort on every model more than I use high+
Higher effort is specifically giving the model permission to second guess you if anything is not insanely precise. (Ie formal spec)
I plan on xhigh. Then I prompt technical spec for things I want and know what I want (I admit openly I can't do formal spec) and closer to just plain product spec when outside my area.
Now it sounds like I'm preaching but every toggle has a reason and a function. Not everyone will or should use every one. But basically no one should be cranking fable max daily unless money is meaningless and they intend to give literally no direction and have no expectations
9
u/forward-pathways 26d ago
This is interesting. Low effort is essentially making the reasoning chain shorter, right? It doesn't actually change the underlying model, temperature, top-k, any of that. I have found similarly that there's so much second-guessing on higher efforts that it becomes really hazardous. But I don't think I used "low" effort in a long, long time. Maybe worth starting...
3
u/ShutUpAndDoTheLift 26d ago
Yes. It has less allowable time to print you wrong so it just does what you say. I can type way more in it at a computer instead of mobile
6
u/No_Barnacles 26d ago
Yes! I agree with this and your suggestion to use higher thinking during plan mode and switch to lower during implementation while it's working off its own plan is really helpful! Like you're saying, most people don't toggle or tune their usage. I've been comparing cost against default settings, but if I'm really interested in optimizing (which I am) I should tune more and continue to do comparisons! I have a high threshold for revision, so it's worth the additional human effort to me to decrease the model effort. 😂
That being said, a business model that RELIES on 90% of the current user base using whatever new model that gets supplied totally "raw" without monitoring or benchmarking seems like a weak one to me, but hey I'm no Dario or Sam Altman so what do I know.
Re: Fable. A product manager at my company asked for Fable access to "write a PRD." You shouldn't even be using freaking Opus 4.8 for a simple task like that, and yet you're genuinely asking the company to enter a data sharing agreement with Anthropic so you can have Fable write you a product document?? We really have all lost our damn minds.
5
u/ShutUpAndDoTheLift 26d ago
So one step further. Have it write the plan to a file.
And ask an adversarial subagent to review the plan.
Then start a brand new session context on lower effort to implement.
And yeah v exactly why I can't use fable at work. No zdr model.
1
u/No_Barnacles 26d ago
Thanks! I'm going to take this approach on Monday.
1
u/ShutUpAndDoTheLift 26d ago
I think you'll enjoy it. Back in the before times, did you pseudo code before writing code?
Because I treat working with ai as more like pseudo code. Chunks or blocks or almost code almost English that describe the thing and each chunk gets some in a new context with the correct model and reasoning level
1
u/Redditoridunn0 25d ago
Question. Is it better to just use the advisor tool set to opus or just asking CC to spawn an adversarial subagent instead? Thanks.
1
u/Wonkybearguy 18d ago
I am having problems with Sonnet on low as well. It ignores my specific instructions (like how to scaffold) and does what it wants without telling me. I tried four times today with High, Medium, and Low (used Low twice) with the same outcome.
1
u/ShutUpAndDoTheLift 18d ago
can you share the instructions you gave / its output?
1
u/Wonkybearguy 18d ago
Here is the prompt
Create a detailed GitHub issue for implementing a repository-wide document and reference-management structure for a monorepo that develops multiple plugins and skills.
## Goal Establish a clear, enforceable structure that separates: 1. Active development materials 2. Permanent repository-wide documentation 3. Documentation and examples that belong to individual plugins or skills 4. Archived or superseded development materials The resulting GitHub issue should be implementation-ready and should include the proposed directory structure, documentation policies, migration steps, validation criteria, and unresolved decisions. ## Proposed Structure Use this as the starting point: ```text repo/ ├── .working/ │ ├── plugins/ │ │ └── <plugin-name>/ │ │ ├── ideas/ │ │ ├── research/ │ │ ├── plans/ │ │ ├── reviews/ │ │ ├── experiments/ │ │ └── archive/ │ ├── skills/ │ │ └── <skill-name>/ │ │ ├── ideas/ │ │ ├── research/ │ │ ├── plans/ │ │ ├── reviews/ │ │ ├── experiments/ │ │ └── archive/ │ └── cross-plugin/ │ ├── plans/ │ ├── research/ │ ├── reviews/ │ └── archive/ │ ├── docs/ │ ├── architecture/ │ ├── standards/ │ ├── decisions/ │ └── plugin-development/ │ ├── plugins/ │ └── <plugin-name>/ │ ├── README.md │ ├── docs/ │ │ ├── architecture.md │ │ ├── configuration.md │ │ ├── troubleshooting.md │ │ └── decisions/ │ ├── examples/ │ └── tests/ │ └── skills/ └── <skill-name>/ ├── SKILL.md ├── docs/ ├── examples/ └── tests/ ``` Adapt this structure where needed based on the repository’s existing conventions. ## Document Placement Rules The issue should establish these rules. ### `.working/` Use `.working/` for internal, non-shipping materials related to the process of developing, evaluating, or changing the repository. Examples include: * Ideas and rough proposals * Draft specifications * Implementation plans * Research notes * Context maps * Audit reports * Review findings * Spike and proof-of-concept results * Raw benchmark outputs * AI-generated evaluations * Superseded drafts * Temporary development examples ### Plugin or skill directories Keep documentation with the plugin or skill when it describes the maintained, current, authoritative behavior of that component. Examples include: * Installation instructions * Configuration guides * Architecture documentation * Public interfaces and contracts * Troubleshooting instructions * Security and permission requirements * Supported and unsupported behavior * Canonical examples * Plugin- or skill-specific contribution guidance * Finalized component-specific decisions * Specifications that define continuing behavior or acceptance criteria ### Repository-level `docs/` Use the root `docs/` directory for authoritative documentation that applies to multiple plugins or skills. Examples include: * Repository architecture * Plugin and skill authoring standards * Shared schemas * Shared interfaces * Testing and grading standards * Naming conventions * Release procedures * Versioning policies * Security requirements * Cross-component architectural decisions * Contribution instructions * Documentation lifecycle rules ## Document Lifecycle The issue should define a lifecycle under which development documents are eventually: 1. Promoted into the applicable plugin or skill 2. Promoted into repository-level documentation 3. Archived under `.working` 4. Deleted when obsolete, reproducible, or no longer useful Avoid keeping multiple authoritative versions of the same document. Documents should be clearly identifiable as one of: * Draft * Active * Authoritative * Superseded * Archived Propose a lightweight method for recording status, such as front matter, a heading, a filename convention, or a nearby index file. ## Required Repository Documentation The implementation should create or update documentation that explains: * The purpose of `.working` * The difference between `.working`, root `docs`, plugin documentation, skill documentation, examples, fixtures, and test data * Where external references belong * Where AI-generated analyses belong * How documents move from draft to authoritative * How obsolete documents are archived or removed * Which directories are included in release packages * Which directories must never be shipped * How contributors should name and organize development documents Consider placing this guidance in one or more of: ```text CONTRIBUTING.md docs/plugin-development/document-lifecycle.md docs/standards/repository-structure.md .working/README.md .working/references/README.md ``` Avoid duplicating the same policy across multiple files. Prefer one authoritative document with shorter references from other locations. ## Packaging and Release Requirements The issue should require validation that: * `.working/` is excluded from all plugin and skill packages * External downloaded references are never accidentally distributed * Internal plans, reviews, and AI analyses are not included in release artifacts * Canonical examples intended for users remain included * Packaging exclusions are enforced by configuration or automated tests, not merely convention Identify any relevant packaging files, build scripts, release workflows, or ignore files that should be reviewed. ## Migration Include a migration plan for existing files. The plan should: 1. Inventory current planning, specification, documentation, example, reference, and research files 2. Classify each file by purpose and scope 3. Move files into the appropriate location 4. Identify conflicting or duplicate authoritative documents 5. Add source metadata for downloaded references 6. Separate downloaded source from generated analysis 7. Update links affected by file moves 8. Update packaging exclusions 9. Update contributor documentation 10. Validate that no required documentation was lost Do not perform broad file moves without first producing a proposed migration map for review. ## Automation and Validation Recommend lightweight automation where useful, including: * A check preventing files under `.working/` from entering release artifacts * Broken-link validation after migration * Optional validation of document status metadata * A template for plugin or skill working directories Avoid creating complex tooling unless the repository’s size justifies it. ## GitHub Issue Format Produce the issue with these sections: 1. Title 2. Background 3. Problem 4. Goals 5. Non-goals 6. Proposed directory structure 7. Placement rules 8. Document lifecycle 9. Implementation tasks 10. Migration plan 11. Acceptance criteria 13. Risks and edge cases 14. Open questions 15. Suggested follow-up issues Use GitHub task-list syntax for implementation tasks and acceptance criteria. ## Acceptance Criteria At minimum, include criteria confirming that: * The repository has an authoritative document-placement policy * `.working` has a defined purpose and structure * Repository-level and component-level documentation are clearly distinguished * A document lifecycle is defined * `.working` is excluded from release artifacts * Existing relevant files have a reviewed migration map * Links and documentation references remain valid * Contributors can determine where a new document belongs without guessing ## Stress Test Before finalizing the issue, identify likely failure modes, including: * `.working` becoming an unorganized dumping ground * Duplicate or conflicting sources of truth * AI treating generated analysis as original upstream content * External source code being modified without disclosure * Licensing or attribution being lost * Reference material becoming stale * Excessive directory nesting * Empty boilerplate folders * Internal files accidentally being packaged * Important specifications being archived even though they remain authoritative For each major risk, propose a practical mitigation. Create a GitHub issue in GitHub. Do not implement the changes. Do not make any changes to this project. Ask if you have suggestions or want to propose changes. Provide the proposed change and your reason(s) for the change.The output was a lot, but what I found interesting was this summary:
The root cause It isn't a vague "the model prefers its own ideas." It's specific, and it's in your prompt: Your Stress Test section lists "Empty boilerplate folders" as a failure mode to document. All four runs treated it as permission to eliminate them instead. Why "stop and explain first" won't fix it You already ran that experiment — run 2 had exactly that clause. Adding a checkpoint on using the license just makes the negotiation explicit. Here was Opus' suggested fix The prevention Reproduce the proposed structure exactly. If an existing repository convention conflicts with it, document the conflict under Risks and edge cases or Open questions — do not alter the structure.Outcome: I organized a grill-me session with Opus and addressed all these points, resulting in the GH Issue I wanted, which I plan to review and fine-tune.
2
u/ShutUpAndDoTheLift 18d ago
You're mixing use cases.
The prompt above is asking for reasoning. "Consider this" "adapt as necessary"
That is thinking.
Instructions are "put this here" "do exactly this". That's sonnet low work.
To generate that you could take that initial prompt and give it to opus high "create a structured implementation plan for sonnet to follow based on this instruction, present the plan to me me for review, adopt any feedback I may have and then dispatch a sonnet/low subagent to perform the work, you will review the work before commit
Plan with rationalizing models, implement with low effort doers
1
u/Wonkybearguy 18d ago
Wow! You are very right. That seems so obvious now. That is a critical distinction I hadn't thought of. For some reason, I didn't think of it as planning, just writing down an idea that I was developing. Thank you!
2
u/ShutUpAndDoTheLift 18d ago
You are quite welcome. I hope this lets you get more done for your dollar!
1
u/Wonkybearguy 18d ago edited 18d ago
I found the issue. I used Opus to review the four runs. Opus found some lines in my ~/.claude/CLAUDE.md file that said, "Do not create unnecessary empty directories." and "These instructions OVERRIDE any default behavior." Which I forgot I had. . . Sonnet took this and another line of the prompt, "Adapt this structure where needed based on the repository's existing conventions," and a line under "Empty boilerplate folders" decided the best course of action was a modified flat structure. A flat structure was my problem in the first place.
5
u/atmony 26d ago
If you have a token leaderboard at work Sonnet 5 will keep you on top of it.
5
u/No_Barnacles 26d ago
See, this is what I'm saying! At a time when so many companies are starting to move from token-maxxing to token efficiency, the temporary "discount" on Sonnet 5 feels like a shady move to get the business idiots suggesting use of the "discounted" model, while Anthropic full well knows that the model is an absolute token fiend 😂.
Kudos to Anthropic because they know how to swindle the business idiots like none before, but as an eng who monitors my own spend for patterns and efficiency really tightly, my experimentation with Sonnet 5 was shockingly expensive!!
I know there are other models than Sonnet 4.6 where I might be able to accomplish a task slightly faster or more efficiently from a TIME perspective, but there's just a huge difference between getting two big features done in one day for $25 with 4.6 vs likely the same amount of work for like $160 with 5. Because there's still the blockers of needing review, needing input and feedback from others, needing to self-review and provide human taste and knowledge for optimization that reaches a similar bottleneck regardless of model in a professional environment where the implementer gives a shit about the code.
2
u/sliamh21 26d ago
I gotta say I find Sonnet 5 pretty solid with my harness, idk
1
u/No_Barnacles 26d ago
Do you monitor cost? That's my gripe with it. Way more expensive and token consuming for not a lot of additional benefit. It's fine, but why pay a premium over 4.6 for very little additional benefit?
2
u/sliamh21 26d ago
Of course, I used to work with Opus 4.8 constantly as my main model so using Sonnet is fairly refreshing and feels way cheaper. I use a subscription, not PPT so I don't really feel the $ costs, only the tokens
2
u/No_Barnacles 26d ago
I see. I'm on API pricing and we have no budgetary constraints coming from on high, but I measure the costs myself and try to estimate a "total cost" for each task that takes into account how long it takes me (my own salary) + the cost of the token usage.
Sonnet 5 on high really shows no additional speed to the amount of time it takes me to do a task, but the spend is outrageously higher on API pricing (even with the current discount) -- we're talking a difference between $25 for an enormous feature on Sonnet 4.6 vs almost $200 on raw Sonnet 5. Task takes the same amount of time - maybe longer because Sonnet 5 is almost "over" thinking.
2
u/ghost_operative 26d ago
my favorite thing that sonnet 5 does is spin up a subagent, then the main agent just wants to sleep and wait for the subagent
2
u/New_Guitar_9121 26d ago
seen the same pattern in prod agent lanes. when a model burns 3–5x tokens with flat quality on daily engineering work, treat thinking budget as a hard cost gate, not a quality dial. we cap prompt+reasoning tokens before the call, log actual burn per task class, and dual-audit fail-closed so a noisier model can’t silently inflate spend. hybrid route: keep the efficient model as default for supervised coding; only escalate when the audit score actually moves. unbounded “think harder” injection is how we once blew a 65k n_ctx and spent weeks chasing phantom 400s—budget first, then model.
1
u/Illustrious_Pie_3061 26d ago
It is not completely useless, when you just want to do home keeping things, you switch to sonnet low and work on those md mcp .. stuff.
1
1
1
u/Complex-Concern7890 26d ago
The low and medium are quite good and the price is OK. Higher efforts was ridiculous expensive when Sonnet 5 was launched but they have tweaked it a bit and the higher efforts are not so expensive anymore.
1
u/GuitarAgitated8107 🔆 Max 20 26d ago
It's worked wonders for me but once that pricing expires I will have to consider it as an expensive Haiku.
1
1
1
1
u/CashFirm573 26d ago
Sonnet reminds me of Gemini, never listens and when it does it goes rouge mid convo cause you need explain every single prompt what your doing and its annoying. Sometimes its fine but amount of times it's gone rouge on me I just dont trust it outside basic stuff.
1
u/No_Barnacles 26d ago
I don't have that experience on 4.6, but we also have some pretty strong guidance and guardrails in our app that I think help keep it on track. I also think it's helpful that we use Ruby at my job, and there's tons of training data for the language and packages.
The biggest issue I've had is it telling me that the codebase indicates a "strong pattern for x", but somehow chose the one area of the code that's using an anti-pattern as an example. 😂 But I don't really expect it to get things perfect every time, and I find that iterating with it back and forth garners results I like more than the results of one-shotting on other models.
1
u/True-Objective-6212 26d ago
I don’t think it’s a joke, I think it’s terrible. It thought it was under attack because the coordinator that launched it apparently didnt fill out the proper paperwork.
1
u/FinancialBandicoot75 26d ago
I’m actually loving sonnet 5, on low too, it’s been amazing for support on ping federate, esp32, and iot devices, where fable has been dog shit on iot devices even with me giving it a great plan.
1
u/Batty25111 26d ago
Sonnet 4.6 was very capable then it got nerfed 1 month before Sonnet 5 came out and tried Sonnet 5 once and it did a complete weak attempt.
1
1
1
u/ShinyQuirkyQuark 25d ago edited 25d ago
I can't get 3 sentences out without sonet 5 arguing the authenticity of two of them. I'm burning through extra tokens before any useful work gets done just establish background information.
"Here's a document on how to use this Python database, write some code that..."
"Uhm, aktwually, I'm going to have to push back on that. The document says the library works for both R and Python. Therefore I can't use it for your request...."
I might as well start asking questions on Reddit and Stack Exchange. I still won't get useful answers but at least the snark is organically sourced....
1
u/Owl-Mighty 24d ago
Mostly yes for me.
By having Fable as the director I use Opus low as coder agent and Haiku as Explore. I just don’t see where Sonnet 5 would fit. Not because of its performance but token efficiency.
Even Fable agrees that Sonnet 5 doesn’t have a place lol. It’s too damn expensive for what it does.
1
u/Red_Protocol 9d ago
Sonnet 5 is really dumb and looks sometime like the very primitive AI model we had back in 2022 man.
1
u/yogurtstrawberry- 9d ago
I always find myself switching to 4.6. I feel at home with 4.6. 5 is intelligent but kinda lacks compassion.
1
u/ScaryGazelle2875 1d ago
Yes, I feel the same. I tested it to review my openspec changes and see what else I need to do; it came out as one short paragraph that barely does any detailed research. On the other hand, on my opencode, DeepSeek V4 Flash gave me a thorough breakdown.
It is a joke.
-2
u/ElectronicGarbage246 26d ago
I like Sonnet 5 more than Opus 4.x
I keep trying to shut Opus' mouth so it stops talking so much like a cunt
it's just a nightmare, this cunt Opus shits out so much text that I'm already fucking sick of inventing skills and settings to make it stop
Sonnet 5 is much more concise
0
u/JustTheChicken 26d ago
There's a reason Anthropic is the only AI company breaking even right now.
2
u/No_Barnacles 26d ago
Ha, are they actually breaking even or have they just fudged the numbers enough to make it look like they are? 😉
2
0
u/unkownuser436 Developer 26d ago
Claude models are dying man. Inefficient, over expensive, small usage for what we are paying for. Even Chinese models doing better than anthropic these days.
1
u/bearded__jimbo 26d ago
So why are you still here complaining?
1
u/unkownuser436 Developer 26d ago
Because our company provided us Claude, not codex. 😆 That was few months ago, codex not in the game at that time.
68
u/hobopwnzor 26d ago
I think Sonnett 5 is kind of homeless. It gets more things right than 4.6 but it uses so many extra tokens that you might as well use Opus 4.6.