Opus 5 is a great employee but a frustrating boss

Anthropic released Opus 5 on July 24, 2026, and my launch-week verdict is simple: it is a great employee but a frustrating boss [1]. After five days of research, I found a model that matches Fable 5 on major benchmarks at half the token price, but becomes less reliable when it has to set the direction [2].

Is Opus 5 as capable as Fable 5? On benchmarks, almost

On published benchmarks, Opus 5 and Fable 5 sit in the same capability range. At maximum effort, Artificial Analysis scores Opus at 61 on its intelligence index, just ahead of Fable at 60; that one-point gap is too small to call Opus the smarter model [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

The narrower Artificial Analysis 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].

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. Those last measurements come from Anthropic, so the independent results above carry more weight [1].

What is the Opus 5 backlash about? Supervision

The backlash is mostly about the cost of supervising Opus, not the quality of its code.

The clearest example comes from a user who scored it at 100% on a set of real coding tasks and considered its implementation and test discipline the best they had seen, yet still called it “an incredible coder and really painful to work with” [4].

That split between output and working experience appears throughout the negative threads, where 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? They measure different work

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. Anthropic 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? Only per token

Opus 5 costs half as much per token, but a completed task usually costs more than half the Fable price. Claude Platform Docs list API rates of $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].

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

Why does each Opus release feel different? Its behavior changes

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

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]. That documented versioning points away from a silent weight swap.

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. OpenAI ran into its own version of the cyber risk question, which I cover in what OpenAI confirmed about Astra and why it slowed the work down.

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]. Usage limits belong in the same group: the smaller weekly allowance in Claude Code after a promotion ended is a plan change, not a model change.

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 uses the same split: Opus executes, Fable advises

Anthropic uses the same basic division of work as my employee-and-boss comparison. Its Advisor tool pairs a cheaper executor with a stronger model that can provide direction, and the 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. I have since run this split on large multi-agent features and set the result against Codex in my comparison of Claude and Codex on large features.

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]. When Anthropic later shipped the next Fable, I compared Fable 5.1 with Opus 5 on long agent tasks and price.

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: bound the task and verify the result

I would give Opus bounded implementation work and keep Fable responsible for unclear direction, architecture, and high-risk review.

Based on the available results and user reports, this is how I would choose between them today. I may change the table after more direct use. That direct use is now written up in whether Opus 5 is really as bad as people say.

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.