[BUG] Cowork: "Reached maximum number of turns (100)" breaks long-running browser automation projects

I also encountered this problem on a large scale today. Many automated processes that were working perfectly suddenly started showing this error, and all conversations ended up displaying:

`
Something went wrong
Try sending your message again. If it keeps happening, share feedback so we can investigate.

Reached maximum number of turns (100)
You can restart the conversation from an earlier message.
`

This means I have to click "Try again" for each message to continue running.

The following are images:
<img width="875" height="776" alt="Image" src="https://github.com/user-attachments/assets/f6f5e127-3a82-4f74-892b-0f1d8fdbe688" />

<img width="497" height="725" alt="Image" src="https://github.com/user-attachments/assets/72c51ccf-866d-435c-9fda-c6f421cd99bb" />

Having the same problem across multiple scheduled tasks in cowork

Has this been solved yet??

No it hasn't

same issue

ANY NEWS??????? FUCK THIS IS HURTING MY BUSINESS!

+1 — confirming this regression is hitting my business automations hard.

Use case: I run a Tunisia-based tour operator (Simba Fun Travel Services).
I have ~6 production Claude Cowork prompt families running daily browser
automations on WhatsApp Web for review requests, driver dispatch, tour
info messaging, and OTA review monitoring. Stack has been live and
hardened over months.

Impact since the v1.8.x update:

• Every prompt family is now hitting the 100-turn ceiling mid-run
• Workflows that previously completed in 60-80 turns are dying at 100
• Forces constant manual "Try again" babysitting throughout each run
• Some workflows can no longer complete a single daily batch
• I am a paying Claude Max subscriber ($100/month) specifically for

Cowork reliability

What I need: rollback of whatever changed in turn-cost accounting, or
raise the cap, or fix whatever in the v1.8.x update is burning turns
faster than before.

This is a production blocker for me. Happy to provide logs or test patches.

Quick question to others affected by this: @pyrocat101 @jeveloff @xiaoxiang-7 @territestgogo @ktwordpressdev-glitch

What are you doing as a workaround while waiting for the fix?

I've tried ChatGPT Agent Mode (too confirmation-prone, stops mid-run)
and looked at Perplexity Comet (architecture not suited for autonomous
send workflows). Nothing I've tested comes close to Cowork's autonomy
for production browser automations.

Has anyone found a viable bridge solution? Or are most people just
babysitting "Try again" until Anthropic ships a patch?

Also curious if anyone has heard back from Anthropic support with an ETA.

Email : b4rr@live.Fr | Whatsapp +216 23 23 25 20

Confirming this on a second, independent workflow — and confirming it's a regression
Adding a second data point to this issue. I'm hitting the identical "Reached maximum number of turns (100)" error on a different workflow than the original report.
The key fact: this ran reliably for weeks and broke suddenly with no changes on my end. My workflow completed cleanly in single runs from roughly late April until this week. Then it began hitting the 100-turn ceiling mid-run. I rolled back to a version of my task instructions from last week to test whether my own edits were responsible — the error still hit at the same point, which rules out my instructions as the cause.
Setup:

Product: Claude Cowork (desktop app) + Claude in Chrome extension
Plan: Max
Trigger: manual, not scheduled (so this isn't limited to scheduled projects)
Workflow: daily job-board search — navigates a sequence of job sites, extracts listings via JS, dedupes against a Google Sheet, logs matches back

The regression:
This workflow ran reliably for several weeks. It started failing this week with no meaningful changes on my end. I rolled back to a prior version of my task instructions from last week to test whether my own edits caused it — the error still hit at the same point. That rules out my instructions as the cause.
Failure detail that may help diagnosis:
My workflow processes the search in "query sets." Each query set runs the same search across ~8 ATS sites, paginating through results, then verifies candidates. In a run I captured, Claude executed everything correctly — connected Chrome, loaded ~1,000 dedup pairs from the sheet, completed the full search across all 8 sites for the first query set, ran dedup checks, and began verifying candidates — then hit the 100-turn ceiling. It died on query set 1 of 7. Each individual browser action (navigate / extract / paginate) appears to consume one turn, so a single query set alone exhausts the budget.
Things I ruled out, in case useful:

Not model-specific: switching models via /model did not change the behavior.
Not my task edits: rolling back to last week's instructions still failed at the same point.
Not scheduled-only: this is a manually triggered run, so the ceiling applies to manual sessions too (the original report was a scheduled project).

Re: the original report's questions — I have the same three, especially whether the ceiling is configurable per-project the way the SDK exposes --max-turns. For browser-automation workflows where each record/site requires multiple sequential navigations, 100 turns is exhausted almost immediately, and there's currently no recovery path — when the ceiling hits mid-run, the in-memory work since the last write is lost, and "restart from an earlier message" doesn't preserve it.

The retards didnt fix it yet...

Quick question to others affected by this: @pyrocat101 @jeveloff @xiaoxiang-7 @territestgogo @ktwordpressdev-glitch What are you doing as a workaround while waiting for the fix? I've tried ChatGPT Agent Mode (too confirmation-prone, stops mid-run) and looked at Perplexity Comet (architecture not suited for autonomous send workflows). Nothing I've tested comes close to Cowork's autonomy for production browser automations. Has anyone found a viable bridge solution? Or are most people just babysitting "Try again" until Anthropic ships a patch? Also curious if anyone has heard back from Anthropic support with an ETA. Email : [b4rr@live.Fr](mailto:b4rr@live.Fr) | Whatsapp +216 23 23 25 20

this has forced me to evaluate my tasks and make them more efficient. but it has hurt my business, a couple of my task i really can't get them done in under 100 turns.

I got my co-works running well around a week ago. Now none work because of this issue.

Same issue here, starting 3 days ago, my scheduled work has never been completed and has wasted many tokens

IS THIS INTENTIONAL by Anthropic? If yes, that would at least give us understanding on what to do next with the prompts....

Or is this identified as a BUG by anthropic?

Just throwing my voice into the pot. All of my scheduled task have become useless. Which is unfortunate. If Anthropic doesn't have a solution to this, then I will need to move on. Unfortunately in its current state there is no benefit to continuing.

Same problem here. I updated last Sunday the desktop app and now i encounter the same limit. Max plan . Mac mini. Are we going to get this fixed anytime.soon ????

Anyone tried to rollback the previous claude.app version over the latest ? To me the problem started after I updated this sunday

Any workarounds or other solutions anyone has found or implemented for this?

my read: the 100-turn ceiling isn't really the bug, it's the turn cost of the screenshot-then-navigate-then-read loop. every record you describe burns 15-25 turns because each field read is a fresh screenshot + scroll + OCR pass, so 86 records was never going to fit under any cap. i keep seeing this same pattern with screenshot-driven browser agents: they pay a turn for every glance, then wall out after 4-5 records and need a human to restart. reading off the accessibility tree instead collapses a record to a couple of reads, no screenshots, and you stay well under the ceiling. the turn limit and the babysitting are both downstream of how the page is being observed.

It worked previously for 2 month.. so this 100 limit is a bug or a new limit. .. anyone found a workaround yet ? I will try to rollback to previous version tonight. Would appreciate any feedback if anyone tried this already. For me it started just after applying the update last Friday 22

Sorry folks, I added this recently as a failsafe after a recent bug (has since been fixed) that caused a runaway message loop for some users. I just bumped max turns to 10K for scheduled tasks and will take a closer look tomorrow.

@dreamofabear sir i don't understand? are you a part of claude's team ???

IF_PATCHED_PROMPTS_FAIL_TOO_WHATS_NEXT.txt
TURN_BUDGET_85_PATCH_INSTRUCTIONS.md

depending on @m13v 's message, i updated my prompts with the following instructions in the files. you can update your prompts with them if you want

Yes he is https://www.linkedin.com/in/williamchou/

@legrooter-create thanks for confirming
@dreamofabear sir is this already resolved then ? without waiting for a claude's update ?

@dreamofabear Thank you. Can you confirm whether this fix is live across all accounts immediately or rolling out? Also: is the 100-turn cap removed entirely for scheduled tasks, or just bumped to 10K? Some of us would still appreciate --max-turns being exposed in the Cowork project UI so we can self-tune. And could the issue be either closed with a clear "fixed in [server version]" or kept open until the tooling-level fix lands? Thanks for the quick response.

The change should be effective immediately for all accounts. You might need to restart the app to pick up the dynamic value.

So nice to see dev is reactive . Ok good. I will try it tomorrow runs. Anyone can confirm it works now ?

The change should be effective immediately for all accounts. You might need to restart the app to pick up the dynamic value.

This is awesome service. Thanks William!

All good. Back to normal ;) thanks 😊 🙏

Mine startet 3 days ago with this and is still failing.