The bugs that matter are rarely the ones with a clean stack trace. They are intermittent, they involve two modules that were written by different people two years apart, and the obvious fix makes them disappear without explaining anything. Claude Opus 5's advantage here is that it will keep pulling the thread instead of declaring victory after one green run.
This page is written for developers stuck on a bug that won't reproduce. If you want the model overview first, start with the complete Claude Opus 5 guide.
| Best effort level | xhigh |
| Context available | 1M tokens — enough for real working material, not just snippets |
| Cost | $5 per million input tokens, $25 per million output |
Why Claude Opus 5 suits debugging
- It correctly identifies intermittent failures as flakes rather than announcing a fix after a single passing run.
- It can hold the failing test, the implementation, and the surrounding call graph in one context.
- It reasons about causes rather than pattern-matching symptoms to a known fix.
- It explains the mechanism clearly enough that you learn something from the answer.
A workflow that works
- Give it the evidence, not your theory. Logs, the failing test, the stack trace, and what you have already ruled out.
- Say how often it fails. "Fails about one run in twenty" points it at a different class of cause than "fails every time."
- Let it run the tests if your setup allows — repeated execution is how flakes get characterised.
- Ask for the mechanism before the patch. A fix you can't explain is a fix that comes back.
- Push back if the explanation is thin. It responds well to a specific challenge and will not simply agree with you.
Settings to start from
Set the effort level to xhigh. Debugging is intelligence-sensitive and usually worth the extra tokens. If you need a fast triage pass instead, medium still performs well.
Leave adaptive thinking on — it is the default on Claude Opus 5, and turning it off introduces failure modes that are not worth the saving. See effort levels explained if you want to tune this properly.
What to watch out for
- Before it reports a state-changing action — restarting a service, deleting a cache — check the evidence actually supports that specific action.
- Its narration is long. Ask for the outcome first if you are reading between tool calls.
- It may propose the broader fix, not the smallest one. Say which you want.
The verdict
The best use of Opus 5 in debugging is the mechanism, not the patch. Get the explanation; write the fix yourself if it is small.
If cost is the constraint, read how to cut Claude Opus 5 costs before downgrading — routing and caching usually beat switching models.
More on Claude Opus 5
Start with the complete Claude Opus 5 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Claude Opus 5 guideFrequently Asked Questions
Can Claude Opus 5 debug a problem it cannot reproduce?
It can reason from evidence — logs, traces, the failing test, and the code path — to a ranked set of candidate causes, which is often what unblocks a stuck investigation. It is markedly better than earlier models at recognising an intermittent failure as intermittent rather than treating one clean run as proof of a fix.
Should I paste logs or give it repository access?
Repository access, wherever possible. Opus 5's strength is holding the failing test, the implementation, and the call graph together in one 1M-token context. Pasted snippets throw away the advantage you are paying for.
Does Claude Opus 5 just agree with whatever theory I suggest?
No — it is more willing to push back than earlier Claude models, and it responds well to a specific challenge to its own reasoning. Giving it your theory as a hypothesis to test, rather than as a conclusion, generally produces a better answer than leading it.
