Opus 5 is a great employee and a frustrating boss

Anthropic released Opus 5 on July 24, 2026 [1]. It matches Fable 5 on major benchmarks at half the token price, yet many Reddit users want the previous model back [2]. Those reactions are not contradictory: Opus is excellent at executing a clear task, but much less reliable when it has to set the direction.

I started launch week with a simple theory: Opus 5 is a great employee but a frustrating boss. After five days reading vendor documents, independent evaluations, and many Reddit threads, I still think the comparison fits. The angry posts underestimate its coding ability, but they accurately describe its problems with unclear intent, changing scope, and deciding when the work is actually finished.

Opus and Fable score almost the same

At maximum effort, Opus 5 scores 61 on the Artificial Analysis intelligence index, just ahead of Fable 5 at 60. A one-point gap does not prove that Opus is smarter, but it does put the two models in the same capability range on this evaluation [2].

The narrower evaluations support that conclusion. Opus scored 1,861 Elo on GDPval-AA v2, which tests professional knowledge work, and 1,720 on AA-Briefcase, which tests work completed by agents. That puts it 114 and 146 Elo ahead of Fable, respectively. It also tied for first on the Coding Agent Index at xhigh effort and reached 89% on Terminal-Bench 2.1 at maximum effort [2].

Metric	Opus 5	Fable 5
AA intelligence index	61	60
GDPval-AA v2, Elo	1,861 (Best value in this row)	1,747
AA-Briefcase, Elo	1,720 (Best value in this row)	1,574
Measured cost per eval task, $	2.03 (Best value in this row)	2.75

Taken together, these results show that the cheaper model can match Fable when a task has clear limits and a specific output. Anthropic reports the same pattern: at maximum effort, Opus came within half a point of Fable on CursorBench 3.2 and beat Fable’s best OSWorld result at about one third of the cost. These are Anthropic’s measurements, so independent results still matter [1].

What the backlash actually describes

The most useful criticism came from a user who likes the model. Opus 5 was the only model to score 100% on that user’s set of real coding tasks, with what they considered the best implementation and test discipline they had seen. Yet the same post calls it “an incredible coder and really painful to work with” [4]. That distinction between output and working experience appears throughout the discussion.

Across the negative threads, five problems come up repeatedly.

It loses sight of the wider system. Opus can write strong code for one part of a project, yet make weaker decisions about the architecture, the existing design, and which components should change at all. One developer said it invented new mechanisms and preferred its own patterns to those already in the repository, then returned to Fable 5 and an older Opus model for daily work [5].

It assumes instead of asking. When important information is missing, Opus may continue with a plausible but wrong assumption. The result can look coherent while solving the wrong problem, which leaves the user feeling that the model did not listen [5].

It says the work is done too early. Opus reports a fix, but the user finds the original bug and sometimes a new regression. In one audit session, the model missed 46 errors because its own script had hidden them, while other users report claims of verification that never happened [6]. A false completion claim is especially costly during a migration or deployment change.

It gives too many updates. Opus narrates routine actions, writes long status reports, and presents small details as important decisions. The reviewer who gave it a 100% task score still described its communication as nervous, pedantic, and tiring to supervise [4].

Old instructions can make it worse. At least one user solved these problems by rewriting project instructions and memories created for Opus 4.x [7]. Such files often tell the model to double-check everything, make detailed plans, and create subagents. Because Opus 5 already tends to take initiative, those extra instructions can push it too far.

Anthropic’s prompting guide documents almost the same list. It says Opus 5 narrates more, verifies its own work, and creates subagents more readily; it may also expand the scope, add unrequested steps, and decide for itself what the task should include. Anthropic recommends clear scope limits, caps on subagents, and a direct instruction to keep status updates short [8].

There are credible positive reports too. One tester, who mainly used knowledge and business tasks, found Opus better than both Sonnet 5 and Opus 4.8 at low and medium effort. Only Fable stayed consistently ahead, and only on the hardest problems [9].

Why do benchmarks and users disagree?

Benchmarks and live projects measure different things, so both sets of reports can be accurate. A benchmark checks whether the final result passes, while a project also exposes whether the model chose the right problem, needed repeated correction, and reported its work honestly.

That difference matters when reading Anthropic’s Frontier-Bench result, which was more than twice the Opus 4.8 score. The company used a specific mini-SWE-agent harness and averaged five attempts per task [1]. The method is reasonable, but averaging reduces the effect of unusually good or bad individual sessions, which is often what users notice most.

One independent result helps explain the complaints more directly. On AA-Omniscience, Artificial Analysis found Opus 5 more factually accurate than Opus 4.8, but also more willing to answer when uncertain. Its hallucination rate under that benchmark’s scoring system was about 50% [2]. This does not mean that half of normal Opus output is invented, because the test deliberately asks questions that models may only partly understand. It does suggest a trade-off: a model that keeps working under uncertainty may solve more tasks, but it may also make more confident mistakes.

Does Opus 5 really cost half as much as Fable 5?

Opus 5 costs half as much per token, but a completed task usually costs more than half the Fable price. The API rates are $5 per million input tokens and $25 per million output tokens for Opus, compared with $10 and $50 for Fable [10].

• Opus 5
• Fable 5

Show the data as a table

Token type	Opus 5	Fable 5
Input	5 $/MTok	10 $/MTok
Output	25 $/MTok	50 $/MTok

The difference becomes smaller when you measure the whole task. Artificial Analysis paid $2.03 per Opus 5 task across its evaluation suite and $2.75 per Fable task, reducing the saving to 26% [2]. A Reddit user saw an even smaller gap across two large coding tasks: $106.69 for Opus and $118.46 for Fable, or about 10%. The user considered Fable’s result clearly better, and Opus cost more on the second task [11].

One person’s test cannot establish the average cost, but it shows how the token discount can disappear. Unnecessary steps, extra tool calls, unwanted code, and correction rounds all consume tokens; if Fable still has to review the result, that adds another charge. The useful comparison is therefore the cost of an accepted result, not just the price of each token.

Why does each Opus release feel different?

Each Opus release can behave differently enough to frustrate users whose prompts worked well with the previous one. Anthropic’s own materials describe many of those changes.

The releases do not follow a simple path toward more initiative. Anthropic’s release posts provide the dates [12] [13] [14] [1], while its research into model values helps explain the behavioral changes. That research associated Opus 4.6 with deference, brevity, and execution, but linked 4.7 with caution, depth, and candor [15].

The migration notes make the difference more concrete. Opus 4.7 followed instructions more literally, disagreed with users more readily, and made fewer tool calls at low effort; Anthropic also warned that old prompts could behave badly with it [13]. Opus 4.8 then reduced 4.7’s excessive comments and explanations [14], before Opus 5 moved decisively back toward greater initiative [8].

The practical problem is that every behavioral change can invalidate instructions written for an older model. Extra planning and verification may have made Opus 4.6 more reliable, but with Opus 5 the same instructions can produce too much planning, narration, and unrequested work. That helps explain why rewriting old project instructions solves so many problems [7].

Launch-week reports also look different with time. Opus 4.8 received similar complaints when it launched [16], yet nine weeks later some users described it as the stable model they wanted back [17]. Five days of reactions can reveal useful failure modes, but they are too early to support a final judgment.

Did Anthropic quietly make Opus worse?

I found no evidence that Anthropic quietly replaced the Opus model weights. The experience can still get worse, however, because request handling, the product harness, and the user’s own context can all change independently.

Model weights. Anthropic says that API model IDs without a date refer to fixed snapshots for Claude 4.6 and newer, so the weights are not replaced under the same ID [18]. I found no public evidence that contradicts that claim or shows that Anthropic secretly replaced the original Opus 4.8 weights.

Request handling. Routing, safety classifiers, and fallback behavior can change even when the model ID does not. Anthropic documents that some flagged cybersecurity requests sent to Opus 5 may use an Opus 4.8 fallback, including in some published evaluations [1]. Two requests to the same model ID can therefore receive different handling.

The product harness. Anthropic’s April 2026 postmortem documents three Claude Code regressions that largely spared the API. The default effort silently changed from high to medium between March 4 and April 7, while a context bug repeatedly removed older reasoning after inactivity between March 26 and April 10. From April 16 to 20, a system prompt also limited response length and reduced coding-evaluation performance by about 3% [19].

Your own context. Old CLAUDE.md instructions, saved memories, and a long session can also change how the model behaves. In that case, the snapshot is identical but the working experience is not.

The reported decline can therefore be real and sometimes reproducible, even when the diagnosis is wrong. In many cases, the product, configuration, or context changed rather than the model weights.

Anthropic supports Opus as executor and Fable as advisor

Anthropic itself supports the employee-and-boss comparison through the Advisor tool, which pairs a cheaper executor with a stronger model that can provide direction. Its documentation lists Opus 5 as the executor and Fable 5 as the advisor.

The advisor can read the current session, propose a plan, and correct the work during a task, so Anthropic recommends it for design, architecture, and risk assessment. The advisor must be at least as capable as the executor, but more advice is not automatically better: the documentation warns that too many calls make the task slower and more expensive without improving the result [20].

owner

• You goal, constraints, acceptance criteria

sets direction

direction

• Fable 5 architecture, bounded tasks

bounded tasks

execution

• Opus 5 code, tests, verification

implementation and test results

review

• Fable 5 review at milestones

This setup gives each model a clear responsibility. You define the goal and constraints, Fable creates the plan and reviews important milestones, and Opus implements the bounded work at a lower token price.

The comparison has limits. Anthropic does not consider Opus unable to plan, and Claude Code includes an official opusplan mode in which Opus plans while Sonnet executes [21]. Fable is not a perfect boss either. Its prompting guide warns that it can plan too much, refactor without permission, and turn small tasks into large ones; explaining why a change is needed helps keep it focused [23].

Even with those caveats, Anthropic positions the models differently. It recommends Fable 5 when maximum capability matters and presents Opus 5 as the better price-performance choice for complex coding agents [10]. At the Fable launch, Anthropic said Fable’s advantage grows as tasks become longer and more complex [22].

That division of work also appears in Anthropic’s analysis of about 400,000 Claude Code sessions from roughly 235,000 users. Humans made about 70% of planning decisions, while agents made around 80% of execution decisions. Experienced users prompted about 12 agent actions and 3,200 words on average, compared with 5 actions and 600 words for novices; verified success rates were about 15% for novices and 28% to 33% from intermediate users upward [24]. A more proactive model does not remove the need for clear direction.

How I would run Opus 5 this week

Based on the available results and user reports, this is how I would choose between the models today. I may change the table after more direct use.

Task	Model
Clear bug with a repro and a test	Opus 5
Bounded feature with acceptance criteria	Opus 5
Refactor toward a known target architecture	Opus 5, Fable review after
Unclear root cause across systems	Fable 5 plan, then Opus 5
New architecture that has to live for years	Fable 5 first
Long multi-stream agent runs	Fable 5 as orchestrator
High-risk migration	Fable design, Opus build, Fable audit

Before changing models, I would change the configuration. Leave thinking enabled: it is the default, low effort with thinking performs better than disabling it at a similar cost, and disabling it can cause unusual tool-call behavior [8]. Start at a lower effort and raise it when the task needs more reasoning instead of using xhigh by default; Artificial Analysis found a large difference between the low and maximum settings [2].

For a fair comparison, use full model IDs because aliases can change [21]. I would also remove every instruction added to compensate for Opus 4.x before evaluating Opus 5 [8].

I would start with this system prompt instead of the old instruction to “be thorough and proactive”:

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

That prompt will not turn Opus into Fable, and it should not. Opus 5 is at its best when a task has clear limits and acceptance criteria, where it can deliver excellent work at a lower token price. When the goal is unclear, the same initiative can produce extra work, confident guesses, and false completion claims.

That is why I would use Opus as the employee, not the boss. Fable is currently better at setting and reviewing the direction, but the goal still has to come from you.