Generation finishes with recommendations to complete

Describe the Bug

On multiple occasions using Agent mode after generating and fixing for few minutes sometimes longer, Cursor will finish generating even though it hasn’t finished the task it was asked to do and simply share “Recommendations to complete this” list and with a question “would you like me to try the recommendations”.
While this is great as it gave some instructions or ideas how to solve an issue, this also now means if I am to ask it to continue, I will have used another “request” that’s included in my plan.

Here is an example of the prompts:
Create unit tests for file xxx.tsx following @unit-test.mdc rules

Rules even have a specific rule to say “Do not stop generating until you have all test cases working/passed when running tests”

Once it gets to a point where it somewhat struggles to figure out how to solve it, it goes in the loop and then just decides to stop generating.
Interestingly enough in most cases it will generate e.g. 10 tests, 6 of them will work and 4 won’t and then while it tries to fix these 4 it will break other 6.
This is mostly when it just decides to give up.

On top of this, asking it to keep going pretty much always leads to it fixing the issues in next couple of tries.

Steps to Reproduce

It’s a bit difficult to explain how to exactly trigger this but I am sure if there was a bit more complicated “react hook” and you asked it to generate unit tests without mocking absolutely everything(which is what it natively tries to do) you will get the same issue.

Expected Behavior

Expected behavior would be for it to keep going until it’s finished and have all test cases working.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.2.4 (user setup)
VSCode Version: 1.99.3
Commit: a8e95743c5268be73767c46944a71f4465d05c90
Date: 2025-07-10T17:09:01.383Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

Thanks for raising this @tom.svecak I’ve noticed this issue with some models as well. This is more model dependent than Cursor as far as I understand. Which model were you using here? Or was it auto mode?

I’ve noticed Gemini 2.5 Pro do this a lot more as compared to Claude Sonnet 4 or o3

1 Like

I only use Claude Sonnet 4 and have seen it happen quite often.
I am not sure if this is related to internal usage of tokens or something else so it decides to stop generating but it’s quite a bit frustrating not knowing why it decided to break and just offer possible solutions without it trying the solution?
Why not ask “would you like to continue by using additional requests” if that is the case?

hi @tom.svecak and welcome to Cursor Forum.

As sanjeed5 mentions the responses depend on AI models and the context sent to the model. Its not token counting related.

The AI model tries to be helpful but if it gets confused by too much context from long chat, lots of files read/attached or conflicting information, then it may happen to not do the task.

If a task needs many steps, you can ask the AI to prepare a todo list before implementing changes. That would keep it better on track.

It also depends on the request itself, perhaps you can share here more of how you approach this.

What works well:

Implement feature xyz…
Fix the broken component…

Requests that usually lead to AI answering but not performing the task

Why is the component broken?
Can you tell me what went wrong?

Thanks condor! :slight_smile:
Just to be very honest, I am having a lot of fun with Cursor and it has been very helpful in many ways with our unit tests but this same issue keeps coming back for some reason.

Use case is pretty simple tbf.
prompt is “add unit tests following @unit-tests.mdc” which has about 90 lines of instructions e.g. do not mock localization, do not mock theme.
a quick snipper of some of the rules.

# Test Quality Requirements
- Tests must verify **WHAT** the component does, not just **THAT** it renders
- Test the **behavior** triggered by user actions (onClick, onSubmit, onChange, etc.)
- Test **business logic** - how props affect component behavior 
- Test **error scenarios** - how component handles invalid/missing data
- Test **state transitions** - how component responds to prop/state changes
- Test **accessibility** - keyboard navigation, ARIA attributes, screen reader support
- Test component rendering
- Test user interactions using `fireEvent`
- when testing defaultValues and values on components make sure to test that these values are present in the output of the component
- when testing onChange make sure to verify that data returned by onChange is in the correct and expected type/format
- Include accessibility tests (ARIA attributes, keyboard navigation, screen reader compatibility)
- Use meaningful test descriptions

However at times it seems to start working following these rules, gets to a point where it makes previously working tests fail(even tho one of the rules says don’t remove or edit existing test cases if user didn’t explicitly ask for it) and then decides to ditch the rules, tries to fix the tests and then just decides to give up with couple of suggestions on what to do next.

This does not happen all the time but I have now repeatedly experienced this and it’s a bit annoying but also could turn out costly as me requesting to continue with the above triggers another request which feels a bit unfair considering it had an idea already how to fix it but decided not to try it but instead just give up :thinking:

From my experience, the AI does not do well handling multiple assignments at once. This varies depending on the tasks and the model, but I find it to be especially bad when it comes to fixing tests.

If I have a test file with 10 tests and two of them are failing:

  • If I give the AI one test at a time to fix (in separate requests), then it generally nails it and fixes each one on the first try
  • If I give the AI both tests and their failure outputs in the same request, telling it to fix both, then more likely than not it will totally hose it up, get stuck in a weird loop, and break half the other tests in the file as well :sweat_smile:

What I’ll usually do is break it into multiple steps:

  1. Have the model generate the entire test file first, but tell it not to try running them
  2. Run them myself. If any failures, have the model fix them one at a time

Sounds like you’re still on the old request-based billing structure. Enjoy it while it lasts :zany_face: the new structure (that most of us are on) is token-based billing. Because of that I appreciate if the AI cuts itself off instead of looping uselessly.

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.