Agentic coding: Claude Opus 5 is strongest on difficult coding tasks: multi-file features, larger refactors, and end-to-end feature work. It completes full tasks rather than leaving stubs or placeholders, and it performs best when given the complete task specification up front and left to run. It also performs well on easier tasks like single-turn edits, where the difference from prior models is smaller.
Code review and bug-finding: Claude Opus 5 reviews code with high precision and recall: it finds real bugs at a high rate per pass, and its additional findings are mostly real issues rather than false positives. Accuracy holds at lower effort settings, which supports a fast pass at review time and a more thorough pass later. If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.
Efficiency at lower effort: low and medium effort produce strong quality at a fraction of the tokens and latency of higher settings, and they perform above the same settings on prior Opus models. Use them liberally as your primary control for token cost and response time wherever your evals show quality holds; for coding and agentic work, xhigh remains the recommended starting point. If you carried effort defaults over from a prior model, re-run an effort sweep on your own evals. See Effort for the full recommendations.
Vision: Claude Opus 5 is strong on chart, document, and diagram understanding, and on UI and frontend visual replication. Re-validate any prompt-side vision workarounds you tuned for prior models; they may no longer be needed. Vision performance is strongest when the model has tools to iteratively analyze, crop, and visually verify its work, and tool use is a more cost-effective lever than thinking alone.
Long-context work: Claude Opus 5 has a 1M token context window as both the default and the maximum, and its instruction following, tool calling, and reasoning stay consistent throughout the window.
Office and document tasks: Claude Opus 5 generates and works with complex, multi-sheet spreadsheets with non-trivial formulas, and it produces well-structured slide decks. Prompt it with any specific styles or templates it needs to follow.
Multi-agent coordination: Claude Opus 5 coordinates teams of subagents well, with effective writer-verifier patterns and few cases of agents overwriting each other's work. For cost-sensitive workloads, cap delegation; see Controlling subagent spawning.
Report
@chrismessina That bit about lower/medium efforts producing strong quality at a fraction of the cost is super helpful. Managing token costs while maintaining output quality has always been a tightrope definitely eager to run some sweeps on this.
alright - Opus 5 is a banger. Fable 5-level reasoning at half the price, @Claude by Anthropic is killing it. it's already running on @Kilo Code, and early traction shows similar performance to GPT-5.6.
the real question now isn't whether AI can write good code, it's which model fits the task and at what cost. LFG
Report
Very nice. Here's a comment generated by Opus 5 posted on a launch page for Opus 5.
Report
Been running it in Claude Code. Not sure yet if it's better or worse than Fable 5 for what I do, but the token efficiency alone is a big win.
Report
The claim I want to poke at is the 1M context holding up consistently, since that is usually where things quietly degrade. Multi-file refactors landing end to end instead of stopping halfway matters more to me day to day than benchmark numbers. How does the subagent management differ from before, is the parent model deciding when to spawn them now or is that still on the developer?
Report
Claude has been huge for me. I understand tech well but I'm not a developer, and it's helped me take ideas that used to just live in my head and turn them into real working software I can put in front of test users. It walked me through publishing a live website and even setting up a proper dev environment with GitHub, stuff I never would have figured out on my own. Excited to use opus 5 and see how it compares to fable 5.
Report
Adding a production note from the boring end of the stack, since most of this thread is about coding and long-running agents.
We run Claude in an AI phone assistant — it answers calls people can't take and places calls on their behalf. Two things we learned the hard way that are not in any prompting guide, and both are about the interaction between reasoning and structured output rather than raw capability.
First: turning extended thinking ON made our planner worse, not better. The planner emits a structured plan that other code consumes. With thinking enabled, reasoning prose started leaking into the structured fields — not malformed exactly, just contaminated in ways a schema won't catch. We now run that leg with thinking off by default and keep it for the legs where a human reads the output. The lesson we took: thinking helps where the consumer is a person, and can actively hurt where the consumer is a parser.
Second, and more relevant to Chris's note about "be conservative" prompts under-reporting: we found the same effect inverts dangerously on refusal calibration. We had a cheaper model in the planner seat and considered letting it judge whether a request was in scope and answer directly if not. We didn't ship it, because in testing it started refusing things it genuinely supported. The failure was not that it answered wrong; it was that the confidence to decline generalised past the cases we wanted declined. So we kept the judgement in the expensive leg and let the cheap one only plan.
The general shape both times: the model was not the bottleneck, the seat we put it in was. Cost per token got a lot of our attention and explained almost none of our incidents.
Genuinely curious whether anyone here has measured the thinking-versus-structured-output interaction properly, because our evidence is a handful of production regressions rather than a clean benchmark, and I'd rather be corrected than keep generalising from it.
Report
I've been testing it fully now for the last two days and it does pretty well, much better than Opus 4.8 and not as great as Fable, but pretty close to it.
Report
That's nice. How does it handle long-context reasoning compared to Fable 5?
Report
Half the price for close to the same quality is the kind of update that actually shows up on the bill. Most of what I throw at it is long messy work that runs for an hour, so the end to end feature work angle is what I care about. Does the lower pricing hold across the whole 1M context window, or does the cost step up once you go past a certain point?
Replies
Osaurus
To get the most out of this model, here's the new prompting guide:
Agentic coding: Claude Opus 5 is strongest on difficult coding tasks: multi-file features, larger refactors, and end-to-end feature work. It completes full tasks rather than leaving stubs or placeholders, and it performs best when given the complete task specification up front and left to run. It also performs well on easier tasks like single-turn edits, where the difference from prior models is smaller.
Code review and bug-finding: Claude Opus 5 reviews code with high precision and recall: it finds real bugs at a high rate per pass, and its additional findings are mostly real issues rather than false positives. Accuracy holds at lower effort settings, which supports a fast pass at review time and a more thorough pass later. If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.
Efficiency at lower effort: low and medium effort produce strong quality at a fraction of the tokens and latency of higher settings, and they perform above the same settings on prior Opus models. Use them liberally as your primary control for token cost and response time wherever your evals show quality holds; for coding and agentic work, xhigh remains the recommended starting point. If you carried effort defaults over from a prior model, re-run an effort sweep on your own evals. See Effort for the full recommendations.
Vision: Claude Opus 5 is strong on chart, document, and diagram understanding, and on UI and frontend visual replication. Re-validate any prompt-side vision workarounds you tuned for prior models; they may no longer be needed. Vision performance is strongest when the model has tools to iteratively analyze, crop, and visually verify its work, and tool use is a more cost-effective lever than thinking alone.
Long-context work: Claude Opus 5 has a 1M token context window as both the default and the maximum, and its instruction following, tool calling, and reasoning stay consistent throughout the window.
Office and document tasks: Claude Opus 5 generates and works with complex, multi-sheet spreadsheets with non-trivial formulas, and it produces well-structured slide decks. Prompt it with any specific styles or templates it needs to follow.
Multi-agent coordination: Claude Opus 5 coordinates teams of subagents well, with effective writer-verifier patterns and few cases of agents overwriting each other's work. For cost-sensitive workloads, cap delegation; see Controlling subagent spawning.
Kilo Code
alright - Opus 5 is a banger. Fable 5-level reasoning at half the price, @Claude by Anthropic is killing it. it's already running on @Kilo Code, and early traction shows similar performance to GPT-5.6.
the real question now isn't whether AI can write good code, it's which model fits the task and at what cost. LFG
Very nice. Here's a comment generated by Opus 5 posted on a launch page for Opus 5.
Been running it in Claude Code. Not sure yet if it's better or worse than Fable 5 for what I do, but the token efficiency alone is a big win.
The claim I want to poke at is the 1M context holding up consistently, since that is usually where things quietly degrade. Multi-file refactors landing end to end instead of stopping halfway matters more to me day to day than benchmark numbers. How does the subagent management differ from before, is the parent model deciding when to spawn them now or is that still on the developer?
Claude has been huge for me. I understand tech well but I'm not a developer, and it's helped me take ideas that used to just live in my head and turn them into real working software I can put in front of test users. It walked me through publishing a live website and even setting up a proper dev environment with GitHub, stuff I never would have figured out on my own. Excited to use opus 5 and see how it compares to fable 5.
Adding a production note from the boring end of the stack, since most of this thread is about coding and long-running agents.
We run Claude in an AI phone assistant — it answers calls people can't take and places calls on their behalf. Two things we learned the hard way that are not in any prompting guide, and both are about the interaction between reasoning and structured output rather than raw capability.
First: turning extended thinking ON made our planner worse, not better. The planner emits a structured plan that other code consumes. With thinking enabled, reasoning prose started leaking into the structured fields — not malformed exactly, just contaminated in ways a schema won't catch. We now run that leg with thinking off by default and keep it for the legs where a human reads the output. The lesson we took: thinking helps where the consumer is a person, and can actively hurt where the consumer is a parser.
Second, and more relevant to Chris's note about "be conservative" prompts under-reporting: we found the same effect inverts dangerously on refusal calibration. We had a cheaper model in the planner seat and considered letting it judge whether a request was in scope and answer directly if not. We didn't ship it, because in testing it started refusing things it genuinely supported. The failure was not that it answered wrong; it was that the confidence to decline generalised past the cases we wanted declined. So we kept the judgement in the expensive leg and let the cheap one only plan.
The general shape both times: the model was not the bottleneck, the seat we put it in was. Cost per token got a lot of our attention and explained almost none of our incidents.
Genuinely curious whether anyone here has measured the thinking-versus-structured-output interaction properly, because our evidence is a handful of production regressions rather than a clean benchmark, and I'd rather be corrected than keep generalising from it.
I've been testing it fully now for the last two days and it does pretty well, much better than Opus 4.8 and not as great as Fable, but pretty close to it.
That's nice. How does it handle long-context reasoning compared to Fable 5?
Half the price for close to the same quality is the kind of update that actually shows up on the bill. Most of what I throw at it is long messy work that runs for an hour, so the end to end feature work angle is what I care about. Does the lower pricing hold across the whole 1M context window, or does the cost step up once you go past a certain point?