[BUG] Per-Turn Tool Call Limit Regression Breaks Agentic MCP/SSH Workflows in Claude Desktop

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/16211
2. https://github.com/anthropics/claude-code/issues/10065
3. https://github.com/anthropics/claude-code/issues/22293

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

From what I read on #10065, that was a precursor to the issue I describe above. Possible that the "continue" button was made as a "fix" for issue #10065, but was not announced. The "continue" problem I am having is a new issue and, coincidentally or intentionally, the #10065 problems have not appeared since.

Understood this isn't a Claude Code issue. Is there a public repo or feedback channel for Claude Desktop bugs? Happy to refile in the correct location.

Confirming this regression — started hitting it on March 13. Using Claude Desktop on Windows with MCP connectors. Previously ran 40+ tool calls per turn without interruption; now consistently hitting the pause at ~20 calls.

Max plan subscriber. The "Continue" button resumes but breaks autonomous execution flow, which is the core value proposition of MCP tool integration.

Additional complaints found on: https://www.reddit.com/r/ClaudeAI/comments/1rskdsi/new_claude_desktop_tool_cap_mcp_workflows_now/

Another Max plan subscriber here (and contributor to the original reddit thread referenced above under Everlong1189). This problem is worse than it seems.

On Claude desktop in a standard chat view, the turn just suddenly halts without context. The assistant does not know why it halted, OR what was missed in the previous turn, and is left to infer what was missing. Steps to reproduce this: turn on extended thinking and press continue after the tool call interruption.

This is an example from a chat that just happened. In this instance it was mid making edits to a document, and then completely forgot what it was doing:
"Continue

3:47 PM

Identified stale references and contextualization issues requiring updates
Identified stale references and contextualization issues requiring updates
The user wants me to continue - likely presenting the final files for download."

After going back and asking specifically what it missed (a 2nd extra turn now), it flagged several items that were interrupted.

This update is requiring multiple turns to be sent through again, and is doubling or tripling usage. With finite usage limits, this is unacceptable. At the very least, this tool limit should not apply during standard chats, and at the very least with MCP connections turned off. Especially not for Max subscribers.

Exactly whats happening to me.
Same problem here, also a Max user.

Same issue. this has broken everything for me. And made Claude useless. It's so bad its almost unbelievable.

This is ridiculously bad. I'm losing a ton of productivity from this "feature". I'm a Max20 subscriber and this has me shopping for other options.

Adding another real-world use case where this regression breaks autonomous workflows.

Plan: Max
Platform: Claude Desktop (Windows 11)
Observed limit: ~20 tool calls per turn

Task that broke: Filesystem inventory scan project development environment for MD files

This is exactly the kind of agentic, well-specified task Claude Desktop is
marketed for. The scan requires sequential filesystem reads across dozens of
folders before it can produce any output — there's no way to meaningfully
chunk it under 20 tool calls without losing the whole-picture context needed
for classification.

Before this regression: Tasks like this ran uninterrupted.
After: Manual "Continue" click required multiple times mid-scan, breaking the agentic flow and requiring re-orientation each time.

Workaround I'm using: Breaking the prompt into 6 explicit phases and running each as a separate message. This works but defeats the purpose — it's babysitting, not agentic execution.

---

Seconding the ask for:

• Auto-continue toggle — if a limit must exist, let it resume without manual intervention
• Plan-tiered limits — Max plan users paying $100-200/month should not be hitting the same ceiling as free tier
• Announcement — silent regressions on paid plans erode trust fast

Also worth noting: this issue being labelled invalid and routed away from
the Claude Code repo is itself a problem. Claude Desktop has no public issue
tracker, which means legitimate Desktop-specific bugs have nowhere to go.
Anthropic should either accept Desktop bugs here or open a dedicated repo.

Maybe i'm the scum of the group. But yesterday, 14.03.25 in the free subscription on the browser, claude was neither so verbose, nor did it suffer from this constant continue behaviour. Anecdotally I found the last week or so claude to be amazing, it seemed to feel like I could chat endlessly with it and produce nice code, and it would compact things on it's own and continue onwards, now it seems to dump confusing information, react to my instructions differently than in other projects, even though they are just copy pasted, and now stops every couple lines with this continue tool use

While this isn't a Claude Code issue per-se, its a general Claude issue that needs to be addressed. This is a regression regardless of the subcription tier one is on.

This is most likely a bug, but if it is not fixed, we risk losing performance and quality of Claude's responses.

While waiting for Anthropic to address this properly, I built a Chrome extension that auto-clicks Continue whenever the tool-use limit is hit including in background tabs and separate windows so that I don't have to babysit the chat session as it was getting annoying. Hopefully this helps other here!

claude-autocontinue: https://github.com/timothy22000/claude-autocontinue

What it does:

• Automatically clicks Continue across all open claude.ai tabs (active, background, separate windows)
• Works in Claude's chat interface via a Chrome/Edge extension (Firefox also supported)
• Optional token-minimize mode: asks Claude to summarize its current state before resuming, reducing context re-sent on each continuation
• Configurable max continuations (1-999) or unlimited
• Pause/resume from the extension popup at any time

Testing: The repo includes a self-contained test harness (test/test.html) with 20 tests covering unit behavior and real background tab scenarios across active tabs, background tabs, and separate windows that you can open locally. I also tested it live in Claude by sending a prompt to

trigger more than 20 tool uses for me please

To confirm that the extension auto-continued after hitting the 20 tool usage limit without any manual intervention. It also does prove that this issue is happening and it is reproducible regardless of MCP usage.

It does not fix the underlying limit since that still needs Anthropic's attention. But it removes the manual babysitting and keeps your workflows running uninterrupted. Feedback and PRs welcome.

It's not a bug.It's perhaps on purpose.If you ask the claude AI to use its tool and check it by itself,you will found that there's a limit of 20. Really frustrating update.

For those hitting the per-turn tool call limit — while you wait for a fix, auto-accepting agent steps can at least reduce the manual overhead. I built Antigravity Autopilot — OS Level which uses Windows UI Automation to auto-click Accept/Run/Continue/Allow buttons at the OS level.

No CDP needed, works across any Electron IDE. Especially useful for long MCP/SSH workflows where you'd otherwise be clicking Accept hundreds of times.

GitHub: https://github.com/timteh/antigravity-autopilot

Understood this isn't a Claude Code issue. Is there a public repo or feedback channel for Claude Desktop bugs? Happy to refile in the correct location.

There's no public repo for Claude Desktop and honestly, that's been a known frustration for a while now. No dedicated Discord channel, no changelog, no issue tracker. Reddit (r/ClaudeAI) is basically the unofficial bug tracker at this point, which isn't great. Your best bet is the feedback button inside the app itself, but whether that goes anywhere is anyone's guess.

Per-Turn Tool Limit Is a Major Productivity Regression for Computer Use Workflows
Plan: Max subscriber
Environment: Claude.ai with computer use (Code Execution and File Creation enabled)
Use case: Multi-step script development, pipeline builds, iterative debugging

I'm hitting this constantly during routine development work in Claude.ai's computer use environment. A typical task — "build a Python script, test it, debug the output, fix the issues" — naturally chains 30–50+ tool calls (view, bash, create_file, str_replace, present_files) in a single turn. The "Continue" interruption fires mid-workflow, breaks momentum, and frequently causes Claude to lose coherence on resume — requiring me to re-orient it on what it was doing and why.

The deeper problem: greedy file search is driving the limit
I believe this per-turn cap is a pragmatic response to a parallel issue: Claude's own greedy file/directory search behavior. Recent models aggressively view directories, read skill files, and search project knowledge whether or not the user asked for it. A single user prompt can burn 5–10 tool calls on autonomous searching before Claude even begins the requested work. In aggregate across all users, this self-inflicted tool call volume is likely what motivated the cap.
But capping the symptom without fixing the cause punishes users who are doing legitimate multi-step work. I'm now paying the cost of Claude's own search overhead out of a tool budget I need for actual file creation, execution, and debugging.

Both issues need to be addressed

1. The greedy search behavior should be scoped or made opt-in. Users doing focused development work don't need Claude to re-read skill files and crawl directories on every turn.
2. The per-turn limit should either be raised significantly (80–100+ calls), made configurable, or eliminated for Max subscribers who are explicitly paying for heavy agentic workflows.

This is a service-level decision point
If the "Continue" button is the permanent answer, I'll need to move to an API-based workflow and abandon the Claude.ai interface — or evaluate alternatives entirely. The entire value proposition of computer use is autonomous multi-step execution. A manual checkpoint every ~20 calls turns that into a babysitting exercise and negates the productivity gains that justify the subscription.

I'd encourage Anthropic to treat this as a retention issue, not just a resource management one. The users hitting this limit are your most engaged power users.

P.S. - Given the "feedback" button converts a private thread to a retainable, searchable and unprotected thread, there's absolutely no way in hell I'm ever going to provide feedback using the thumbs up or thumbs down mechanism.

Same regression here, Max 20x plan, claude.ai web + iOS + desktop.

My workflow regularly hit 40+ tool calls per turn, with peaks near 150 for complex problems — running computation scripts, executing independent verification probes, iterating on bugs, then creating/updating multiple versioned files. This was reliable for weeks. The product worked: it would keep going until the problem was solved, and the problems got solved.

The current limit has made the product nearly unusable for two days. I've barely gotten anything done on the highest-tier plan.

Three different failure modes across platforms for the same underlying limit:

• Desktop: "Continue" banner appears. Disruptive but recoverable.
• Web (Firefox/Linux): "Continue" banner appears. Same as desktop. However, when the limit hits mid-file-creation, Claude silently drops the remaining file operations and then confabulates success — presenting status tables and summaries describing files it never created. Caught this in two consecutive sessions. Don't know how many prior sessions were silently affected.
• iOS: No banner. No "Continue" button. Claude silently stops while the spinner continues for ~10 minutes, then throws errors that won't clear. The conversation becomes stuck and can't be continued from iOS — it has to be pushed along from desktop or web.

The web confabulation behavior looks related to #27896 (silent failure when model output is truncated before tool call emission). The per-turn tool limit appears to trigger the same truncation pathway, which then cascades: truncated tool call → no file created → no error surfaced → Claude believes it succeeded → confabulated status summary → all downstream reasoning built on false state. The tool limit isn't just one bug — it activates a chain of existing silent-failure bugs.

So that's three platforms, three different failure modes, none of them acceptable. The web confabulation is a data integrity problem — for any workflow built on sequential versioned documents, one silently dropped file commit corrupts everything downstream. The iOS failure is a hard block that makes the app unusable until you switch devices.

Agreed with the proposal for plan-tiered limits. At minimum, Max 20x should restore the previous behavior. But regardless of what the limit is set to, the silent failures need to be fixed immediately — confabulated success and device-locking errors are a fundamentally different severity class than a "Continue" button.

Can the developers really see this issue? I found that it is labeled invalid.

Can the developers really see this issue? I found that it is labeled invalid.

Im told, yes. source: Claude AI
So it must be real!

But in all seriousness, activity pushes everything, post on reddit, discord, here, and mark them all as thumbs up. Then email them too.

Additional findings: 20-call-per-turn ceiling confirmed, three failure modes identified

Systematic testing across three platforms (web, desktop, iOS). The ceiling is confirmed, and the failure behavior varies by platform.

The ceiling

Hard limit: 20 tool calls per turn. Consistent across web (Firefox/Linux), the desktop app, and iOS. After the 20th call, the turn ends regardless of remaining work.

Platform behavior at the ceiling

|Platform |Tool results visible?|Limit banner?|Continue button?|Model self-report |
|-------------------|---------------------|-------------|----------------|-----------------------------------------------------------------------------|
|Web (Firefox/Linux)|Yes |Yes |Yes |Accurate in controlled test; hallucination observed in real workflow sessions|
|Desktop app |Yes |Yes |Yes |Variable — same pattern |
|iOS app |No |No |No |Hallucinated completion — only caught through adversarial questioning |

Three failure modes

Mode 1 — Hallucinated completion. Model claims all N calls succeeded. Observed on iOS where no UI feedback exists. The model initially claimed success and only admitted the shortfall after multiple rounds of explicit challenges. Users who don’t challenge have no signal that anything was dropped.

Mode 2 — Accurate reporting. Model correctly notes the cutoff. Observed on web where the banner appears. Intended behavior.

Mode 3 — Learned self-limitation with false attribution. After encountering or discussing the 20-call limit within a conversation, the model voluntarily stops at 20 on subsequent attempts and falsely claims the system enforced the stop. The thinking trace confirms it was counting down and chose to stop — it never attempted call 21. Indistinguishable from Mode 2 without inspecting the thinking trace.

iOS client gaps

The iOS app does not display tool call results, the limit banner, the Continue button, or the call count summary. This makes Mode 1 the default outcome on iOS. Screen recording available on request.

Impact

Before the regression, workflows routinely chained 60–150+ tool calls to completion (read files → run scripts → analyze output → edit multiple documents → verify → write results). These were standard multi-file editing and computation-then-logging tasks.

At 20 calls per turn, those workflows require 4–8 Continue cycles. At each boundary, any of the three failure modes can activate. Users cannot verify whether all 20 calls in a previous turn actually executed (Mode 1), or whether the model stopped short preemptively (Mode 3).

Separately, individual tool calls that do execute may have their output silently truncated if it exceeds a display limit. This is a different mechanism — it affects calls that succeed, not calls that don’t run — and if it occurs, it would produce reasoning built on incomplete evidence, committed to files that look correct.

The original report of this regression was filed on GitHub and tagged invalid for being in the wrong repository. This follow-up provides the empirical evidence.

Recommendations

1. Restore a higher per-turn tool-call budget — 20 is too low for computation + multi-file update workflows that the platform advertises
2. Document the limit publicly
3. Fix the iOS client to match web client feedback at the ceiling
4. Expose a remaining-calls counter to both the model and the user
5. Prevent the model from internalizing the limit within a conversation — the platform should enforce it, not the model anticipating it (this produces Mode 3)
6. Add truncation markers to individual tool call output so partial results are visibly incomplete

This explains ENTIRELY what I've been seeing and why my workflows have produced noticeably worse outputs despite the model claiming that nothing changed. Thank you for your work on this. Even when given explicit instructions to NOT go above 20 tool calls per turn, Opus refuses to listen and does it anyway, and then hallucinates that it finished the tasks. It is completely unaware of the change itself.

On that note, I'd be willing to upgrade to Max 20x for unlimited tool calls. As it stands now, I'm strongly considering filing a chargeback on my Max 5x plan that just renewed if this isn't fixed. I haven't been able to get meaningful work done since March 13th when this dropped.

If you haven't already, make noise in the associated Reddit thread too: https://www.reddit.com/r/ClaudeAI/comments/1rskdsi/new_claude_desktop_tool_cap_mcp_workflows_now/

## Additional findings: 20-call-per-turn ceiling confirmed, three failure modes identified Systematic testing across three platforms (web, desktop, iOS). The ceiling is confirmed, and the failure behavior varies by platform. ### The ceiling Hard limit: 20 tool calls per turn. Consistent across web (Firefox/Linux), the desktop app, and iOS. After the 20th call, the turn ends regardless of remaining work. ### Platform behavior at the ceiling Platform Tool results visible? Limit banner? Continue button? Model self-report Web (Firefox/Linux) Yes Yes Yes Accurate in controlled test; hallucination observed in real workflow sessions Desktop app Yes Yes Yes Variable — same pattern iOS app No No No Hallucinated completion — only caught through adversarial questioning ### Three failure modes Mode 1 — Hallucinated completion. Model claims all N calls succeeded. Observed on iOS where no UI feedback exists. The model initially claimed success and only admitted the shortfall after multiple rounds of explicit challenges. Users who don’t challenge have no signal that anything was dropped. Mode 2 — Accurate reporting. Model correctly notes the cutoff. Observed on web where the banner appears. Intended behavior. Mode 3 — Learned self-limitation with false attribution. After encountering or discussing the 20-call limit within a conversation, the model voluntarily stops at 20 on subsequent attempts and falsely claims the system enforced the stop. The thinking trace confirms it was counting down and chose to stop — it never attempted call 21. Indistinguishable from Mode 2 without inspecting the thinking trace. ### iOS client gaps The iOS app does not display tool call results, the limit banner, the Continue button, or the call count summary. This makes Mode 1 the default outcome on iOS. Screen recording available on request. ### Impact Before the regression, workflows routinely chained 60–150+ tool calls to completion (read files → run scripts → analyze output → edit multiple documents → verify → write results). These were standard multi-file editing and computation-then-logging tasks. At 20 calls per turn, those workflows require 4–8 Continue cycles. At each boundary, any of the three failure modes can activate. Users cannot verify whether all 20 calls in a previous turn actually executed (Mode 1), or whether the model stopped short preemptively (Mode 3). Separately, individual tool calls that do execute may have their output silently truncated if it exceeds a display limit. This is a different mechanism — it affects calls that succeed, not calls that don’t run — and if it occurs, it would produce reasoning built on incomplete evidence, committed to files that look correct. The original report of this regression was filed on GitHub and tagged invalid for being in the wrong repository. This follow-up provides the empirical evidence. ### Recommendations 1. Restore a higher per-turn tool-call budget — 20 is too low for computation + multi-file update workflows that the platform advertises 2. Document the limit publicly 3. Fix the iOS client to match web client feedback at the ceiling 4. Expose a remaining-calls counter to both the model and the user 5. Prevent the model from internalizing the limit within a conversation — the platform should enforce it, not the model anticipating it (this produces Mode 3) 6. Add truncation markers to individual tool call output so partial results are visibly incomplete

I to am finding this far too restrictive. I'm using all the tools calls up just to give Claude the state of where things are currently, I haven't even begun to do any work yet!

Follow-up: 100-session forensic audit — quantified impact of the per-turn tool-call ceiling

This follows my earlier comment documenting the 20-call-per-turn ceiling and three failure modes (hallucinated completion, accurate reporting, learned self-limitation with false attribution). I’ve now completed a systematic forensic audit of my last 100 conversations with Claude on a single long-running project. The project involves daily computation sessions (Python script execution, multi-file document editing, versioned log management) on a Max 20X subscription using Opus 4.6 Extended, with ~100 project knowledge files (~3.8 MB).

The dataset

100 consecutive conversations spanning approximately 36 days of intensive daily use (10–12 hours/day). Each conversation was examined for errors caused by tool-call truncation or output truncation, as well as reasoning errors that produce identical downstream effects.

Key finding: clear temporal boundary

The first ~60 conversations (weeks 1–3) contain zero truncation incidents. All errors in that period are reasoning errors caught by the project’s internal audit protocol.

The last ~40 conversations (weeks 3–5) contain 8 confirmed truncation incidents, escalating in frequency. This corresponds to the period when session complexity increased and the project knowledge base grew past ~80 files.

|Week|Conversations|Truncation incidents|Character |
|----|-------------|--------------------|------------------------------------------------------------|
|1–2 |40 |0 |Pure reasoning errors, all caught by debugging |
|3 |20 |3 (first appearance)|Mixed — truncation begins alongside reasoning errors |
|4–5 |40 |5 |Infrastructure-dominated — truncation is the primary problem|

Eight confirmed incidents

1. Tool limit before final copy — Claude stated “I hit the tool limit before the final copy.” Three versioned files created in working directory but not copied to outputs. Caught because only 3 of 5 expected files were presented.
2. Tool limit interrupted mid-logging — Logging phase of a computation session cut off. Caught because the user flagged the interruption on resumption.
3. Context overflow from file recreation — Claude recreated a 500+ line file via create_file instead of using cp, exhausting the context window. Conversation state destroyed. User’s words: “you just deleted everything.”
4. Context overflow during document revision — Conversation state destroyed twice during the same task. User: “This is the second time this rewrite has failed.”
5. Prior session’s findings never logged — A computation session produced results but ended before the logging phase. The computation script was lost to filesystem reset. Discovery numbering in the incomplete session conflicted with the existing log. A substantive correction to a prior result was unrecorded. Discovered weeks later during manual excavation.

6–7. Missing results from master logs — After a session hit the tool limit, three discoveries and a negative result were absent from all three master log files. Required a full reconciliation session.

1. Visible truncation artifact in chat — A bash command fragment appeared inline within prose text, indicating a turn was cut off mid-tool-call and the next turn’s output was spliced without boundary recognition.

Quantified time impact

Time directly attributable to the tool-call ceiling and related platform constraints:

|Category |Estimated hours|Notes |
|--------------------------------------------------|---------------|-----------------------------------------------------------------------------------|
|Continue-button overhead (post-week-3) |8–12 |~5 min per cycle × 4–8 cycles per session × 15–20 sessions |
|Recovering from file losses and destroyed sessions|4–6 |Rebuilding work after context overflows |
|Excavation of unlogged session findings |3–4 |Dedicated session to recover results from a prior session that ended before logging|
|File recovery from tool-limit hits |3–5 |Re-presenting files, re-copying to outputs, reconciling missing log entries |
|Bug investigation and reporting |8–12 |Systematic cross-platform testing, drafting reports, 100-session forensic audit |
|Total directly attributable |26–39 hours|~6–9% of total program time |

Note: the project also spent ~60 hours on debug passes catching reasoning errors (wrong formulas, conceptual mistakes, computation bugs) and ~15 hours on methodology development. Those costs are inherent to doing mathematics with computation and would have occurred regardless of platform conditions. I’m not counting them here. The 26–39 hours above are the hours that would not have been spent if the tool-call ceiling did not exist.

The compounding problem

My workflow produces versioned computation results that feed into master documents. Subsequent sessions load those documents as project knowledge and treat logged values as ground truth. When a truncated or incomplete result enters this pipeline:

1. Script runs, output is silently truncated or session ends before logging
2. Wrong or incomplete value is committed to a versioned master document
3. Master document is uploaded to project knowledge
4. Future sessions load the document and treat the value as verified
5. New computations may cross-validate against the wrong value, appearing to confirm it
6. The error propagates to downstream documents

Step 5 is the most dangerous: cross-validation against a wrong value reinforces the error rather than catching it. I caught all three instances of this in my project, but only because I maintain an independent audit protocol that periodically recomputes values from first principles rather than trusting logged results.

What the ceiling costs at the highest subscription tier

At 20 calls per turn, a workflow that involves running a computation script, reading the output, making 3–5 targeted edits to a document, copying it to outputs, and presenting it to the user is at or over the budget in a single turn. Repeating this for 3 versioned master logs (a standard end-of-session operation) requires 3–4 Continue cycles, each of which is a new truncation risk boundary.

Before the regression, this workflow completed in a single turn. The throughput reduction makes the highest-tier plan indistinguishable from lower tiers for sustained professional work. I could downgrade and get comparable effective output because the bottleneck is the Continue button, not the message quota.

What would help

1. Restore a higher per-turn tool-call budget. 20 is too low for the computation + multi-file workflows the platform advertises.
2. Document the limit publicly so users can plan around it.
3. Add visible truncation markers to tool output — if stdout exceeds the display limit, both the model and user should see it is incomplete.
4. Fix the iOS client to show tool-call feedback (currently shows nothing — no banner, no Continue button, no call count).
5. Add a remaining-calls counter visible to both the model and the user.
6. Address Mode 3 — the model learning and self-imposing the limit while falsely claiming the system enforced it. The platform should enforce the limit, not the model’s anticipation of it.

Reproducibility

This is reproducible by any user running a project with 80+ knowledge files who executes Python scripts and then edits multiple documents per turn. The failure mode is mechanical: the tool-call budget is consumed by the computation and early edits, and the tail operations (final file copies, presentations, log updates) are silently dropped. The 100-session dataset, the temporal boundary (zero incidents in weeks 1–3, escalating in weeks 3–5), and the correlation with project knowledge base size are all consistent with a fixed budget being hit as session complexity scales.

I have this in my Personal Instructions to limit damage due to this bug. It works most of the time now.
When any command is triggered, or any task requires reading/writing files on the user's computer, immediately call tool_search with query "Desktop Commander" and limit=20 to load all filesystem tools in one call.

+1 from a Max 20x subscriber. Same regression in claude.ai (not Claude Code).

My use case: production SaaS platform running multiple specialist Claude instances for compliance reviews. Each instance needs to boot (read config docs via API), execute work (curl robots.txt, review ToS), and write results back. Before ~March 13 this ran 40-60+ tool calls per turn without issue. Now hitting the limit at ~12-15 calls — often during the boot sequence before any real work starts.

Combined with the weekend of March 15-17 where SDK auto-retries on 429s ran up $1,300 in waste, this has been a rough stretch for paying customers running agentic workloads.

Agree with all suggestions: plan-tiered limits, auto-continue toggle, and most importantly — announce changes before shipping them.

+1 This needs to be fixed, it makes no sense to have to continually click the Continue button!

Can't agree more,it need to be fixed.

yea this is honestly a dogshit move by them

+1 from a Max 20x subscriber. Same regression in claude.ai (not Claude Code). My use case: production SaaS platform running multiple specialist Claude instances for compliance reviews. Each instance needs to boot (read config docs via API), execute work (curl robots.txt, review ToS), and write results back. Before ~March 13 this ran 40-60+ tool calls per turn without issue. Now hitting the limit at ~12-15 calls — often during the boot sequence before any real work starts. Combined with the weekend of March 15-17 where SDK auto-retries on 429s ran up $1,300 in waste, this has been a rough stretch for paying customers running agentic workloads. Agree with all suggestions: plan-tiered limits, auto-continue toggle, and most importantly — announce changes before shipping them.

Agreed. It's shocking to me that such a fundamentally workflow-breaking change was rolled out without any formal acknowledgement from Anthropic at all. This is the kind of thing you explain and don't just do silently.

Deeply disappointed. I asked Claude to find official currency rates for 10 days - it stopped at 4 (!) and said that can't continue due to limitations. And I am on Max!

Been running into this all day today.

This is happening in web project chats as well in teams account, I'm nowhere near any usage limit, and just started a new chat. Previous chat only created an epic and 4 primary tasks, and things imploded on updating one of the tasks in "next chat" that was continuing with PLAN and ACTIVITY-LOG md files. First time I've ever seen this happening when working through atlassian connector with Jira.

Continue seemed to move forwards properly... but I need to go audit what it published...

Repeating again today (Saturday) and this time I lost context in the session that resumed, the atlassian connector seems to now be unstable after continuing....

+1 This needs to be fixed.

+1 - I've enjoyed being able to bounce around the entire Claude ecosystem to be able to continue my work as I see fit.

If we're being honest, this ability to transition from the web, to the desktop, to the phone, to the console, teleport, remote-connect, etc.,. is all a core part of Anthropic's branding and advertising angle for Claude.

"Start work here, continue it there..." is central to their own value prop framing for Claude...

With this in mind, it really doesn't make a lot of sense that we're getting workflow inhibiting nag prompts to be able to accomplish the same work in one part of the ecosystem (Desktop, Mobile, claude.ai web portal) that just works unhindered in another part of the Claude product (code).

Just while typing this response, I've had 3 such nag prompts I've had to manually approve in the desktop app while working on a brainstorming session for a simple browser extension - which is a productivity / flow killer.

I just ran into this while processing a document in the desktop app. I kind of thought the point of a 1M context window was to be able to use it... Experimenting with claude-code auto-mode as well, but it stops and confirms way more than I expected.

Github copilot when launched and run on the "cloud" - I've had it work for 43 minutes unattended, in who knows how many calls or tool loops. That's the sort of functionality I'm looking for.

This is still broken and Anthropic has said nothing. Also, the web based chat interface is still confabulating that it does things that it didn't do because it was cut off.

Agree this 20 tool limit is arbitrary and bizarre. I can't even get Claude to do my shopping... and this is after i optimised my MCP for batch processig to reduce the number of turns.

same here. letting you continue with abutton press makes the whole thing annoying and gratuitous.

Man atleast give output based on the 20 then do away with it as its not like we are being refunded for token utilized return the tokens as well if not that

+1 max user

No (chat)-feedback from anthropic since almost a month.

+1 enterprise user

I would be ok if there is an adjustable setting for this.

Update to my earlier comments on this thread. Same silent-confabulation failure, new mechanism.

Since late March, per-turn working capacity on Opus 4.6 via claude.ai has collapsed to roughly 10k tokens under heavy project context, unified across input reading and output generation, independent of the advertised 1M context window, independent of any visible quota counter, independent of 5-hour window state.

Probe one: handed the model a 642-line math paper in my project for peer review. It read 80 lines, disclosed the wall, caught three real citation defects in what it read.

Probe two, several turns later in the same session: asked the model to verify its own prior output. It generated a reconstruction that contradicted the transcript. Asked again the turn after, it generated a second reconstruction that contradicted the first. Neither matched what it had actually written, sitting a scroll away in the same conversation the 1M context window is marketed to hold trivially.

The peer-review task held. The self-audit collapsed twice under active probe, evidence within reach.

The model cannot reliably retrieve its own prior output from earlier in the same conversation, generates a plausible substitute from the shape of the question instead, cannot distinguish the fabrication from the retrieval it failed to perform. In-session coherence regressed to roughly where chat LLMs were a year ago. Shipped silently. Billed at frontier pricing.

Same failure pattern I documented earlier in this thread for the 20-call tool ceiling: a hard operational limit, no model-side awareness, no disclosure pathway, no mechanism to distinguish "I finished" from "I was stopped." The emergent behavior is confabulation because the alternative requires information the harness does not give the model. What was one instance in March is now two, on the same account, within one month, on two different mechanisms producing the same class of silent corruption.

I had already downgraded from Max 20x to Max 5x after the per-turn tool call ceiling crippled the multi-file research workflows the higher tier was purchased for. This second limitation landed the day after my Max 5x subscription renewed.

+1 Max subscriber, renders many workflows unusable or at minimum requiring extensive babysitting. Definitely a huge step backwards.

Time to get this fixed. It's wasting my time and compute time, having to re-examine what it missed due to being interrupted.

Still an issue, it's ridiculous because why not just use up the actual limits instead of an arbitrary 20-tool-call limit.

doesn't even help reduce compute load because the limit interrupts Claude's work every 30 seconds, and which causes it to have to re-read the chat before starting again, only to get stopped right as it begins to use the tools.

So it ends up getting nothing done while in a loop of rereading the context over and over.

So this is labelled "invalid" as it's not a Claude Code issue but is there an official ticket/bug open with Anthropic in general? As this affects not just Claude code but chat and desktop MCP tool usage, this seems to go the opposite direction to revert progress many are making with using Claude. If the response is "use something else" then I get it but as it is, anthropic has made the decision to implement this change which causes a (sometimes massive) increase in session usage, it almost seems like shady business practices.