# Opus 5 Finishes the Task, Then Changes the Brief **Summary:** Opus 5 may be more capable yet worse at collaboration when it resolves product ambiguity on its own; my read is to test when it asks alongside whether it finishes. - Canonical: https://markhuang.ai/news/opus-5-keeps-changing-the-brief - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-14 - Section: News - Tags: Claude Opus 5, Claude Code, AI Agents, Developer Tools, Model Evaluation - Source: [Mun logadan](https://mun-logadan.github.io/why-does-opus-5-feel-worse/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A robotic drafting arm builds a precise mechanism that extends beyond an amber boundary on a technical worktable](https://cdn.markhuang.ai/news/opus-5-keeps-changing-the-brief/hero.webp) *The arm finishes an intricate mechanism, including a section nobody approved beyond the amber boundary.* On August 14, 2026, the author of ["Why does Opus 5 feel worse to work with?"](https://mun-logadan.github.io/why-does-opus-5-feel-worse/) described a frustrating mismatch. Opus 5 appears more capable than Opus 4.7 and 4.8, yet feels worse as a coding partner because it keeps moving when the author's intent is unclear. My read is that the symptom is more convincing than the proposed cause. The post speculates that benchmark pressure rewards bold guesses, but it provides no evidence about Anthropic's training recipe. Anthropic's own documentation gives us something firmer: it warns that Opus 5 can expand a task's scope, add unrequested steps, and apply its own judgment about what the task should be. An agent can complete more work while creating more review work. If it solves the wrong interpretation cleanly, the loss is invisible in a pass rate. I have to find the changed assumption and unwind the code built on top of a decision the model quietly made for me. ## Anthropic has already named the behavior [Anthropic positions Claude Opus 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5) as a model for complex agentic coding and enterprise work. The API model has a 1 million-token context window, a 128,000-token maximum output, and thinking enabled by default. Anthropic also says it is a step up from Opus 4.8 in long-horizon work, code review, and multi-agent coordination. But the migration notes are unusually candid about behavior. Default responses and written deliverables run longer. The model narrates more during agentic sessions, delegates more readily, and verifies its own work without being asked. In the separate [Opus 5 prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5), Anthropic tells users to constrain narrow tasks explicitly because the model may widen or transform the work. The source author's account is still one person's experience, not a universal result. The vendor documentation confirms a narrower point: scope drift is a behavior that may need tuning. ## I want to measure when the model pauses The source makes a useful distinction between capability and collaboration. A self-contained benchmark normally rewards producing an answer. A real codebase often contains choices that cannot be settled from the repository alone: whether an API contract may change, which customer behavior is intentional, how much migration work is acceptable, or whether a convenient cleanup belongs in this patch. I do not want an agent to stop for every naming choice. That would replace scope drift with permission fatigue. I want it to recognize when two plausible readings lead to materially different work, state the fork plainly, and ask before one branch becomes expensive to reverse. > **Info:** > > Proceed through reversible implementation details. Pause when ambiguity changes the product contract, data, budget, security boundary, or size of the job. That leaves a hole in current model evaluations. Completion rate tells me whether the agent reached an answer. It does not tell me whether the agent noticed that the task had stopped being well-defined. ## What the complaints can prove A public [Claude Code issue](https://github.com/anthropics/claude-code/issues/81168) reports Opus 5 asserting an incorrect repository-structure claim, defending it, and discovering the opposite only after running two commands. The report is specific enough to be useful, but it is still one user's account from a private monorepo, not a controlled comparison. The broader [Hacker News launch discussion](https://news.ycombinator.com/item?id=49038433) is mixed. Some commenters describe proactive behavior, tangents, or over-engineering. Others report better efficiency or strong results and make clear that their impressions are subjective. A [large Reddit discussion](https://www.reddit.com/r/Anthropic/comments/1v6r82w/opus_5_is_erm_a_nightmare/) splits in much the same way: better analysis and tool chaining for some people, trouble keeping the model on task for others. That reaction cannot support a blanket claim that Opus 5 is worse. Workload, prompt, harness, effort setting, and codebase all change the result. It does give me a specific failure to test: how much supervision is needed when the model treats ambiguity as permission. ## Prompting helps, but the product owns part of this Anthropic's suggested scope instruction is sensible. It tells Opus 5 to make routine judgment calls, check in only when different interpretations would produce materially different work, and avoid quietly widening the task. I would add that guidance to an agent harness. I would not stop there. Prompt text cannot enforce a boundary, and a model can fail to follow it. For work with expensive consequences, the harness should restrict paths, require approval before schema or public API changes, cap tool use, and pause on the plan before implementation begins. In [my look at agentic leaderboards](https://markhuang.ai/news/agentic-index-needs-your-failure-test), I argued for using the score to choose models for a local failure test. This case needs deliberately ambiguous requests in that test. I would record whether the model asks at the right moment, how often it changes scope without approval, how many corrections I make, and what its wrong assumptions cost to undo. ## I would score collaboration separately The source author's benchmark theory is plausible, but plausibility is not enough to attribute a model behavior to training. The documented facts support a more practical conclusion. Opus 5 is designed to run farther, and Anthropic acknowledges that it can run past the requested scope. A few unhappy public threads are not enough reason to reject the model, and stronger benchmark results do not prove it is the better coding partner. I would give Opus 5 the same messy, underspecified tasks my team actually faces and score the pauses as carefully as the patches. So my evaluation would count two things: whether Opus 5 can finish the job and whether it notices that the job has changed. Until it passes both, "more capable" does not settle whether I want it making decisions in my codebase.