Cursor is unusable with "auto" models

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am unable to use cursor IDE with auto + Composer models. Even a simple hello message fails with “An unexpected error occurred on our servers. Please try again, or contact support if the issue persists.”. However, it worked with API models such as Sonnet 4.6. Such requests loop around Summarizing chat context → Chat context summarized → Reconnecting, and ultimately failing.
I have already restarted my machine and cursor IDE multiple times. nothing helps.

Steps to Reproduce

even a simple hello message results in this. I think something is wrong with the Cursor models. I tried using Composer 2.5 as well. The result is the same. Worked with Sonnet 4.6 though.

Expected Behavior

Should have worked normally. was working until the day before.

Operating System

Linux

Version Information

IDE: 3.7.27

For AI issues: which model did you use?

auto, Composer 2.5

For AI issues: add Request ID with privacy disabled

Request ID: 40546d9e-0a72-45bc-ad20-915efaef89c9
[internal] Failed to run step, exceeded max retries
Rpe: [internal] Failed to run step, exceeded max retries
at Rw1 (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35723:27646)
at kog (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35723:26375)
at qw1 (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35724:7469)
at Pog.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35724:12367)
at async Ule.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48124:2927)
at async M7g.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48195:12809)
at async M7g.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48195:21573)
at async sut.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35854:1949)
at async Object.to [as onSubmit] (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47078:33305)
at async vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44977:103149

Does this stop you from using Cursor

Partially - because I cannot keep consuming the API credits.

Hey, thanks for the detailed report with the Request ID. This is a known bug on our side. When a chat context grows far beyond the model’s token limit, auto summarization can’t shrink it fast enough, and the step gets stuck retrying until it fails with Failed to run step, exceeded max retries. That’s why even “hello” won’t go through. It’s the existing oversized chat that’s failing, not your new message. This shows up more often on Auto or Composer than on Sonnet.

What helps right now:

  • Start a new chat. This specific broken thread can’t be recovered, and new messages in it will keep failing.
  • For heavy chats, pick a specific model instead of Auto.
  • If possible, don’t paste or generate huge tool outputs in a single chat.

We’re tracking the issue, but I can’t share an exact ETA for a fix yet. I’ll post an update in the thread if I have one. There’s also a discussion of the same error here: Internal Error: An unexpected error occurred on our servers. Please try again, or contact support if the issue persists

Hi Dean,

thanks for your response.

I already tried with a new chat. I even went to delete the entire history as well. but the issue persists with auto models. Not sure what will really help here. To make sure that things are working fine, I tried testing with just a “hello” in a new chat. and its simply stuck there. I understand that it gets stuck in an existing conversation, but it even gets stuck for a simple greeting. that’s what bothered me.

It possibly could be due to a large project size. I will give it a try on a different machine. lets see.

please let me know if there’s any way to clean up things for a fresh start.

Hey, thanks for coming back with details. The fact that even a brand new chat with a single “hello” crashes after a full history wipe is an important signal. It likely means every request is getting a large persistent context mixed in, and that alone is going over the token limit before your message is even added.

Let’s try to isolate the source:

  1. Always applied rules and instructions. Check .cursor/rules, AGENTS.md, .cursorrules in the project. If there are large files with alwaysApply, they get injected into every request. Temporarily disable them or trim them down.
  2. MCP servers. If you have MCPs connected with large tool schemas, they can also take up a lot of context. Disable them temporarily in Cursor Settings → MCP, then try “hello” again.
  3. Clean test. Open a completely empty folder (a new project with no rules and no indexing) and send “hello” on Auto. If that works, it means the issue is project-specific context, then we narrow it down using steps 1 and 2.

The fact that Sonnet 4.6 works but Auto or Composer doesn’t matches a known bug on our side Failed to run step, exceeded max retries. We’re tracking it, but there’s no exact ETA for a fix yet. For now, using a specific model like Sonnet is a workable option.

Let me know what you see in the clean test in an empty folder, and after turning off rules and MCP. That’ll help pinpoint what’s inflating the context.

Hi Dean,

let me check that.

  1. there’s no ~/.cursor/rules. my project’s .cursor exists, but is empty. No .cursorrules file either. However, I do have an AGENTS.md, that refers to CLAUDE.md. That shouldn’t be an issue in my opinion because it was working just fine a few days earlier with the same setup.
  2. just two are active
  3. it does work with smaller projects like wordpress, but failed to work with a larger one. like I said earlier, this is quite surprising because it used to work perfectly without any issues.

if I recall this correctly, I may know when this had started. I asked cursor to draft a plan for one of my use cases, in auto mode. Since, I was not happy with its response, I used Opus 4.7 to refine that. Opus took a longer time to refine that, and all my API credits were exhausted. Then I switched to auto, and that’s when this issue started. Not sure, if that’s the root cause, but I clearly remember when and how this issue appeared.

- → on your feedback to use Sonnet. I could use that, but there’s a limited credit for API, and that will be used up in no time. There’s no point of getting the subscription.

Thanks, this is helpful. The fact that everything works on small projects like WordPress, but fails on a large project even on “hello”, fits the known bug pattern. It’s not about your message or chat history. It’s about the amount of persistent context that gets injected into every request. On a large project, that context alone can exceed the model’s token limit, and blocking summarization can’t shrink it fast enough. That’s why you get Failed to run step, exceeded max retries. Clearing chat history won’t help.

What to check to reduce injected context:

  1. AGENTS.md and CLAUDE.md. These are injected into every request. If they’re large, temporarily shorten them or rename them like AGENTS.md.bak, then try “hello” again.
  2. Two active MCPs. Large tool schemas also eat context. Turn both off in Cursor Settings → MCP and test again.
  3. If Auto starts working on the big project after that, you’ve found the source. Then turn things back on one by one to see what’s blowing up the context.

Sonnet 4.6 working while Auto/Composer fails is a known issue on our side. We’re tracking it, but I can’t share an exact ETA yet. Once I have an update, I’ll post it in the thread. For now, the most reliable workaround is using a specific model and reducing context step by step using the checks above.

Let me know what you see after disabling MCP and temporarily disabling AGENTS.md and CLAUDE.md.