[MODEL] Opus 4.6 continuously stuck in explore and thinking loops (Claude Code)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23688
2. https://github.com/anthropics/claude-code/issues/24104
3. https://github.com/anthropics/claude-code/issues/24215

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirming - Opus 4.6 loops are a serious production issue

I'm experiencing the exact same problem daily. I run Claude Code with Opus 4.6 on a Max subscription ($200/mo) for managing a small company's IT infrastructure (Odoo ERP, AI agents, network devices, NAS).

What I see consistently:

• Claude gets stuck in explore/thinking loops for 5-15 minutes, reading files it already read, searching for things it already found
• When I interrupt, it acknowledges the work was useless
• On tasks that Opus 4.5 would handle in 2-3 turns, Opus 4.6 takes 8-10+ turns going in circles
• The model repeatedly "re-discovers" information it had 3 turns ago

My environment: Windows 11, VSCode extension + CLI, MCP servers (Odoo, Playwright), heavy use of CLAUDE.md project files and memory system.

Impact: I depend on Claude Code for real business operations - deploying code, managing servers, processing orders. These loops waste significant time and burn through the usage limits much faster. What used to be a 5-minute task now takes 20+ minutes of babysitting.

This is not a subjective "feels dumber" complaint - the behavioral change from Opus 4.5 to 4.6 is stark and measurable in my daily workflow.

I'm finding the same with Sonnet 4.6 compared to Sonnet 4.5. Gets stuck in speculative loops and then doesn't actually take any action or reach conclusion, just goes back around the same loop as before. Requests to ask it to change approach often fall on deaf ears - it'll simply acknowledge the user is frustrated then dive back into the loop.

It's as if its been given imposter syndrome - it's often reaching reasonable conclusions and then self-doubting and looping, instead of giving them a go or prompting the user for input.

I'm no way near the usage some of you have but I'm having the same issue, where it just keeps going in circles and doesn't find the answer. I just spent 50% of my session trying to add an "auto IP finder" for a file he created, which was working before mind you, and now it can't figure out how to get it working as it was before.

I'm running Opus 4.6 and does anyone have any good suggestions on how to get it to stop? Should I use another LLM to find the answer?

Edit, I just had Chatgpt pro go over everything that Opus did and it found the problem, in less than 15 minutes. I'm a big fan of Claude, but chatgpt saved the day today.

A circuit-breaker hook can stop infinite exploration loops:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
STATE="/tmp/cc-explore-loop"
READONLY_TOOLS='Read|Grep|Glob|Agent'
if echo "$TOOL" | grep -qE "$READONLY_TOOLS"; then
    COUNT=$(cat "$STATE" 2>/dev/null || echo 0)
    COUNT=$((COUNT + 1))
    echo "$COUNT" > "$STATE"
    if [ $COUNT -ge 15 ]; then
        echo "⚠️ LOOP DETECTED: $COUNT consecutive read/explore calls without action." >&2
        echo "Stop exploring and start implementing." >&2
        rm -f "$STATE"
        exit 2  # Block to force a different action
    elif [ $COUNT -ge 10 ]; then
        echo "⚠️ $COUNT consecutive reads — consider taking action instead of exploring further." >&2
    fi
else
    rm -f "$STATE"
fi
exit 0

For a softer approach that nudges rather than blocks:

STATE="/tmp/cc-explore-count"
COUNT=$(cat "$STATE" 2>/dev/null || echo 0)
if [ $COUNT -ge 8 ]; then
    jq -n '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"IMPORTANT: You have been reading/exploring for many turns without making changes. Stop exploring and start implementing. If you are stuck, state what you are stuck on rather than reading more files."}}'
    echo 0 > "$STATE"
fi
exit 0

These hooks detect the "explore loop" pattern (read → read → read → ...) and either block after N iterations or inject a nudge to break the cycle.

Can confirm I am encountering that issue as well, very annoying to burn through your entire plan usage for nothing of value to be done.

● Searched for 1 pattern, read 2 files (ctrl+o to expand)
  ⎿  Interrupted · What should Claude do instead?

❯ are you stuck or why is it taking so long

● Sorry, was over-planning. Let me just do it.

Still happening in April 2026. Not fixed. Financial impact confirmed. Issue #52362 is mine — same behavior, different task type (web search + structured response, not code editing). This is not a niche edge case.

Try adjusting the thinking effort in the /model configuration.

This failure mode appears across many long-running multi-agent traces.

The visible symptoms are usually:

• retries continue
• tool intent is restated
• execution still appears active
• token usage keeps growing
• no material state transition occurs

The difficult part is that workflows can remain locally coherent long after execution has effectively stopped progressing.

In replayed traces, this often appears as:

• repeated intent reformulation
• coordination continuity without execution advancement
• expanding context consumption after structural contribution has already peaked

Traditional controls like recursion ceilings eventually terminate execution, but they do not explain where execution stopped materially evolving.

We’ve been analyzing this class of behavior through deterministic replay and execution-trajectory analysis in X-Ray:

https://github.com/veloryn-intel/veloryn-xray

Replay analysis helps make these transition boundaries visible after execution completes.

The operational distinction becomes:

• execution that is still active

vs

• execution that is still progressing