The Document Assistant stops responding after reading 2-3 document files consecutively. No error messages, timeout warnings, or status indicators are displayed. The assistant simply becomes unresponsive without any explanation.
Steps to Reproduce
1.Open the Document Assistant feature
2.Sequentially read multiple document files (3+ files)
3.Attempt to read the 3rd-4th document file
4.The assistant stops responding and provides no feedback
Expected Behavior
The Document Assistant should continue responding to requests regardless of how many documents have been read
If a limit is reached, a clear error message should be displayed
If a timeout occurs, a notification should inform the user
The assistant should gracefully handle consecutive requests
Like I mentioned there, this widget is meant for quick docs questions and navigation. It’s not designed to process lots of documents in a row or handle heavy tasks.
For full work with files and documents, it’s better to use Cursor IDE. It has Agent mode, longer context, and it doesn’t have these streaming limits.
Thank you for the previous response. I need to add an important clarification: I was not processing large documents or executing heavy tasks when I encountered this problem.
In my actual use case:
I simply sent error codes to the Document Assistant when encountering errors
I asked the assistant to help explain or diagnose the errors
This is a relatively simple, lightweight operation
Problem Manifestation: Even within this normal, reasonable usage scope, the Document Assistant stops responding after 2-3 reads and triggers the streaming limit.
Core Issue:
The official response mentions the widget is “designed for quick document queries and navigation,” suggesting to use Cursor IDE only for large-scale tasks. However, I experienced timeouts even during quick queries.
This indicates:
The limit may be overly restrictive for normal use cases
The widget should not timeout when handling simple error code explanation requests
The problem is not user “abuse” of the widget, but rather poor limit design
Suggestions:
Evaluate whether the limit is appropriate for normal, lightweight use cases
If the limit cannot be adjusted, at least provide clear error messaging indicating the time limit has been reached
Documentation should clearly specify what types of queries trigger timeouts (rather than just saying “don’t process large tasks”)
Your point about error messaging is fair. If the widget hits a limit, it should say so instead of silently stopping. I’ll pass this feedback to the team.
But the limits on the docs widget on Cursor Docs are expected behavior, even for simple requests. The widget is meant for short sessions, like a couple of questions about the docs, not ongoing work with multiple requests in a row.