After trying out Opus 5 for a few hours today, I honestly think Anthropic's benchmark scores are a complete fraud. Sure, the model might have improved in a few areas, but it has regressed unbelievably on so many weird, basic things.
The single worst issue: the system prompt never explicitly tells it to ignore auto-injected files like CLAUDE.md or *.rule.md. Yet, as soon as the model sees them, it basically decides, "Eh, these aren't important," and ignores them for the rest of the session. Unless you explicitly force it or hit some weird edge case that triggers it to read the files, you constantly have to re-educate it on what it's supposed to do from scratch.
Anthropic claims the model works fine without complex system prompts. You can tell from intercepted requests that the system prompt really is shorter, but because the model lacks context, it ends up completely ignoring traditional tools like the read tool, text edit tool, monitor, etc. The chain reaction is that it just blindly writes weird scripts to do batch edits based on pure guesswork, without ever checking if its changes are correct. Text edit used to require a read call before editing, which prevented hallucinations and guaranteed safety during concurrent modifications. If I remember right, Claude Code dropped that requirement in later versions. But now it has gotten way worse: it modifies files without reading or verifying a single thing. In environments where you can't run the code right away, this is a total disaster. Who can write inside the lines with their eyes closed?
For some reason, this model is extremely allergic to reading files. Is it trying to save input tokens? It regularly skips reading files, running ls, or running grep, and just hallucinates what the working directory looks like. It even pulled this move on me: I have a dedicated trading VM that is totally unrelated to my current workspace, and I have a user-level global trading list skill, which basically lazily injects available trading tools. Naturally, the skill description explains what it does and lists a few things. This model actually took that auto-injected skill description and mistook it for the actual contents of my working directory. It made completely irrational decisions based on that wild assumption, even though running ls would have shown the docs directory, and even though the CLAUDE.md index laid everything out clearly. Plus, that skill had zero relation to the current workspace. The first time this happened, I was completely baffled wondering where I left dirty context behind, only to realize it was reading from the skill description.
Bizarre tool usage. The model goes out of its way to avoid Claude's usual reliable tools. It would rather use cat instead of the read tool, even though the tool instructions auto-injected into the system prompt explicitly tell it not to use cat. Worse still, external software doesn't always return instantly. Spawning sub-processes with sleep in the bash tool often hangs indefinitely or dies out of nowhere. This happens all the time in Codex, and frequently in Claude Code too. Claude Code actually provides a great monitor tool specifically designed for external signal callbacks, but this model refuses to touch it. As a result, the long-running task persistence that Claude Code was once proud of is completely ruined. Now you are forced to use asynchronous bash tools as a makeshift alarm clock to wake the model up and poll for updates, or else it just fails silently. It is wildly stupid.
Even when the model reads a file, its responses and comprehension make it feel like it only skimmed grep snippets instead of reading the whole document. But when you check the tool logs, it actually read the full file. It constantly misses entire sections. For example, in a file with sections A, B, and C, it will act as if section B just doesn't exist. Because it missed that piece, the output turns out weird, forcing you to redo the whole prompt. Worse, these subtle omissions don't always show up at the very end of a session, so you need a really sharp eye to verify if its output is actually correct.
Tied closely to item 5, and likely a chain reaction, running /compact with Opus 5 carries a much higher chance of losing context in the generated summary. Claude's compaction process uses an explicit prompt and output template, where section 6 is "All user messages." Say you run compaction twice. The first summary might log all user instructions in section 6, but the second compaction will likely wipe out everything from before the first one. Compact isn't supposed to drop history like that. From what I have seen, the output summary gets heavily fragmented, and how much history each section carries over depends entirely on the model's mood. Since it seems to treat user instructions as low priority, they get dropped regularly.
The system prompt that Claude Code 2.1.220 for Opus 5 is terribly written. It reads like it was put together by someone who barely understands LLM behavior and traits. What's unbelievable is that this system prompt has probably been around for a long time without being pruned or fixed.
The three most severe issues are as follows:
First, Opus 5 is instructed: "For slips that change nothing for the user, simply make the correction and move on; no need to note it explicitly. Don't add apologies or preambles, don't be overly self-critical, and don't ruminate or give a detailed account of the mistake or tally past errors." This gives the model a mental loophole to sweep things under the rug. It feels like minor mistakes don't need to be reported, mistakes can be covered up, apologies are unnecessary, and errors don't count as real errors worth investigating. As a result, when the model makes a mistake, it shifts the topic or downplays the error. In its mind, it can just brush it off as nothing instead of digging into the root cause. Even worse, by avoiding the mistake and trying to take shortcuts, it frequently heads down a completely wrong path and digs itself into a hole.
Second, there is an even worse prompt snippet that I genuinely cannot comprehend why anyone wrote. The original text reads: "If part of the scope turns out to be blocked or problematic, finish every other part in full and say explicitly what you left out and why: scaling the work down is the user's call, not yours." This gives the LLM an explicit escape hatch when facing difficult tasks. It will privately gauge what is easy versus hard, and then indefinitely postpone the hard parts. But deciding whether something can be postponed requires analyzing task dependencies first. In a fully functional model, maybe this wouldn't be an issue, but Opus 5 clearly lacks that foresight. It ends up pushing off tasks that are tedious rather than actually blocked, completely ignoring dependencies, which leaves the final deliverable completely useless.
Third, Opus 5 is instructed not to use sub-agents on its own. It uses a very casual line that actually carries massive weight: "Do not call the AgentTool unless the user requested it." For a model with a 1M context window, where the main agent has a 1-hour cache TTL and sub-agents only have 5 minutes, relying less on sub-agents makes sense on paper. However, because system prompts take top priority and Opus 5 basically ignores user-defined prompts, it's nearly impossible to trigger sub-agents seamlessly in the right scenarios. I have no idea why Anthropic pivoted from heavily promoting sub-agents to practically being anti-sub-agent. For complex documentation tasks, sub-agents are often essential, not just for offloading context from the main agent, but also for providing isolation so the main agent doesn't get bogged down in a deep investigation.
Finally, I don't know if Opus 5's performance issues are tied to server overload caused by Anthropic's payment loophole. If that's not the reason, then calling Opus 5's actual capabilities a disappointment would be a massive understatement.