Most people I run into seem far less sensitive to the bad writing of Claude than I am (and I assume you share this). For most people, they were satisfied enough with the improvements in Opus 5.5 to finally accept the prose. I still find it wildly unacceptable for models that are so good at writing software. After all, language is a pretty important part of writing software. This writing is very bad. I tolerate reading it for work but I cannot tolerate reading an article written by these models.
Exactly. This year has been a revelation to me. It’s like the blue dress phenomenon: we all look at the same text and some people see perfectly acceptable prose, and others see unreadable slop-drivel.
I did that but I recognize that even though your submission was a few minutes later than that one, you posted the better link, and you're also an established account (the other post was from a new/throwaway account), so I've restored this submission and moved the comments back to it to reward you.
I think this release is really going to give them a hard time selling Fable:
> On our benchmarks, Claude Opus 5.5 leads in agentic coding, computer use, and knowledge work. That said, at these levels of capability we’ve found that benchmark margins have become a less reliable guide to real-world differences. In our own use, the gap between Opus 5.5 and Claude Fable 5.1 is narrower than these scores suggest.
In general, "benchmark margins have become a less reliable guide to real-world differences" sounds like a big problem. It was certainly the biggest problem with the previous generation of Claude models for a different reason, because the non-code output was nonsensical, and that is not being benchmarked at the moment. But I'm not sure what to make of this admission.
"benchmark margins have become a less
reliable guide to real-world differences"
sounds like a big problem.
My guesses:
1. Real-world use cases typically involve big, hairy, crufty, tech debt laden codebases and benchmarks do not.
2. AFAIK "success" in a benchmark essentially boils down to "do the tests pass and do we get the right result?" which is something the LLMs have been achieving with ease for a while, except maybe for uber-challenging coding tasks that would be outliers in just about any workplace. Whereas real-world software engineering is usually just a bunch of CRUD... and "success" involves harder to measure dimensions like "maintainability" and "did you overengineer this?" and "how did you cope with a bunch of vague and maybe contradictory business requirements?"
Having said all of that, I have never ever looked inside any of these benchmarks. I'm putting my guesses out here strictly in the tradition of "the quickest way to learn about something is to be wrong about it on the internet."
Opus 5 fucking sucks. Like it's horrible. I use Fable for coding and anything important and I use Opus 4.8 for things like recursive email categorization, transaction matching, and other stuff where I don't want to burn as much quota.
In my experience Opus 5 is the worst of all possible worlds, it's dumb and headstrong. It just runs away with tasks you didn't ask it to do, is reckless, and basically is unusable in my experience.
Not sure why but my guess is that this will be worse. Happy to be proven wrong.
I believe Opus 5 isn't meant to be spoken to by humans. It's great at executing but I reckon it's intended to be spoken to by other models such as Fable. I use Fable as the orchestrator, only speak with Fable, and all implementation, recon, design etc happens with Opus 5, with Fable reviewing (and translating).
I've really gone in the opposite direction: having a dumber model orchestrate. In my case, it's usually a Luna orchestrator spawning Sol/Astra subagents to do the "big brain" work of planning and reviewing.
Reason I went with "dumb orchestrator" was just to save tokens. Having Opus/Sol (let alone Fable/Astra) orchestrate was burning tokens like crazy for me even when much of the gruntwork was being done by Luna/Sonnet/Haiku subagents. (Luna is also really good, like way better than Sonnet...) Perhaps it was a skill issue on my end though, maybe I wasn't just managing context properly.
Yeah if anything Opus 5 taught me how little benchmarks mean to the actual real world performance of these models.
"Better" in every sense of the benchmarks and absolutely horrible results in my day-to-day work.
The verbosity, goal post moving, tendency to leave work unfinished, over focusing on unrealistic root causes when debugging, etc... etc...
It was the first time I actually pinned my models back because I just could not work with 5 for the price and performance it gave me. Hoping 5.5 is better this time around....
The biggest jump was Opus 4.6. Since then they have gradually gotten better at finding issues in your reasoning, not hallucinating, and being rigorous with the code, but much much worse at explaining things and generally just talking in a way that a human can understand. All the models I've tried seem to be suffering from the same fate so it must be something going on with the training meta right now.
That would actually be a reasonable thing to do with a model that is good at writing though. I'm sure if you used that method on Opus 4.6 you'd get a pretty decent result, because Claude models used to be quite good at that sort of technical synthesis. Asking a model that is bad at technical writing (e.g. Opus/Fable 5) to write your docs is a bad idea.
Ultimately what seems more important that how good the model is at task X vs task Y, seems to be that the human accepting/rejecting/iterating on the text can actually identify "good" from "bad" text, and makes the effort to fix it. Otherwise it doesn't matter much what model you use, it makes boring, bland and bloated prose.
I believe AI technical prose peaked with Opus 4.6. I still use it (mostly for that purpose) and I think it's legitimately great. I'm hoping they are able to reverse the trends that benchmaxxing and RLAIF have wrought on Claude's non-code output with the future models.
Now that the public anger is growing i really hope Anthropics next models seriously address this. Or for that matter, i hope everyone (OpenAI/etc) starts focusing on this too.
Intelligence is important but it feels as if the LLM is only capable of conveying information while drenching it in vomit.
I assure you it won't be as bad as this (answer to FAQ: "Will OpenLogi support Logitech Flow?")
> It's on the roadmap, at the far end: a cross-computer pointer and clipboard bridge is a very large feature. The half that lives in the protocol already ships. OpenLogi drives Easy-Switch host switching over HID++ (0x1814/0x1815), and paired mice follow the keyboard when it switches hosts. If the rest lands, it will be opt-in and local-network only.
A great example of why Claude's writing is terrible is the sentence "The half that lives in the protocol already ships". I cannot imagine any human writing this.
The entire ecosystem of CC is designed to facilitate burning tokens. You have to ask the LLM to write a script for the app to tell you which folder you're working in and which branch you're on. There are commands that just diagnose your Claude Code setup and try to "optimize" it. Adding skills or plugins bloats the context window. Developing plans means that you work through questions before you get to it in the code, but that matters way more for human programmers than LLMs, so it's probably just a waste of tokens.
reply