On different hosts (me and most of my colleagues in the team) we have very different results when we execute an agent request (the same request) through SDK.
The question is exactly the same, but:
On some machine the answer is returned with a single turn.
On some machine we get a lot of chunk and finally an invalid answer.
This does not happen usually with expensive models, but with basic ones.
Here attached a log using gpt 5.6 Luna.
Model makes many multiple turns, then it finish with status error.
Steps to Reproduce
Open a clean agent with Cursor SDK then send it an heavy question.
Typically > 20K
Expected Behavior
model makes one only turn, then the stream finish correctly.
This isn’t the model or the request. The same run works on one machine and fails on another because the failing host’s network path drops the long-lived streaming connection mid-run, and your SDK version then keeps retrying until it errors out. Two things to try:
1. Upgrade cursor-sdk. You’re on 1.0.31; latest is 1.2.0 (pip install -U cursor-sdk on every host). 1.0.34+ handles dropped connections much better (bounds the retries instead of churning), and 1.0.39+ surfaces a real error reason instead of a bare error status. See the SDK release notes.
2. Check the network path on the hosts that fail. Since only some machines fail on an identical request, the difference is each host’s route to our API. Corporate TLS-inspection or an idle timeout on long-lived connections will cut the stream partway through a long run - worth comparing a working host vs a failing one with your network team, and making sure connections to the Cursor API aren’t being deep-inspected or idle-cut.
If it still happens after upgrading, reply with a fresh run ID and the UTC time from a failing host and I’ll trace it.
Hi @mohitjain
I have done the upgrade on two hosts. One that fails, one that was ok.
We upgraded today, the log at the end.
As visible in installation log, in machine was working, we moved from 0.1.5 to 1.3.1.
Errored machine was upgraded from 1.0.31 to 1.3.1
Instead to solve something, now previously correct machine is failing too.
This gpt-5.6-luna is stucked after a long time:
agent: run started agent_id=agent-ec6c146f-2ae5-43e4-a958-3ce672177eac run_id=run-45aa8377-4fea-4a1d-a41d-155e621bbbd3
This claude-opus-5.5 finishes with error:
run started agent_id=agent-7c45b307-e391-4a90-8c14-2d097d0cdc49 run_id=run-8603eb9b-87d6-45e3-98ca-1edb7ba63dd9
pip install -U cursor-sdk log: C:\Users\fcalcabr.cursor\plugins\local\se-team-skills-rules>pip install -U cursor-sdk
Requirement already satisfied: cursor-sdk in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (0.1.5)
Collecting cursor-sdk
Downloading cursor_sdk-1.3.1-py3-none-win_amd64.whl.metadata (2.5 kB)
Requirement already satisfied: httpx<1,>=0.27 in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from cursor-sdk) (0.28.1)
Requirement already satisfied: anyio in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from httpx<1,>=0.27->cursor-sdk) (4.13.0)
Requirement already satisfied: certifi in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from httpx<1,>=0.27->cursor-sdk) (2026.5.20)
Requirement already satisfied: httpcore==1.* in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from httpx<1,>=0.27->cursor-sdk) (1.0.9)
Requirement already satisfied: idna in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from httpx<1,>=0.27->cursor-sdk) (3.16)
Requirement already satisfied: h11>=0.16 in C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages (from httpcore==1.*->httpx<1,>=0.27->cursor-sdk) (0.16.0)
Downloading cursor_sdk-1.3.1-py3-none-win_amd64.whl (47.9 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 47.9/47.9 MB 4.9 MB/s 0:00:10
Installing collected packages: cursor-sdk
Attempting uninstall: cursor-sdk
Found existing installation: cursor-sdk 0.1.5
Uninstalling cursor-sdk-0.1.5:
Successfully uninstalled cursor-sdk-0.1.5
WARNING: The script cursor-sdk-bridge.exe is installed in ‘C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Scripts’ which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
WARNING: Failed to remove contents in a temporary directory ‘C:\Users\fcalcabr\AppData\Local\Python\pythoncore-3.14-64\Lib\site-packages~ursor_sdk’.
You can safely remove it manually.
Successfully installed cursor-sdk-1.3.1
On both runs our side finished the answer each time (the luna run 10 times, the opus run 7 times), but the SDK never registered that the turn had ended. It treated each one as a lost connection, sent the whole question again from the start, and gave up with an error after 10 attempts. That’s the “many turns, then an error” you’re seeing, and why the long luna run looked stuck. Your colleague’s original failing run on 1.0.31 shows the same pattern.
So it isn’t the question, the model or the host’s network settings, and you don’t need to keep digging into the network side. This is an issue the team is aware of, and I’ve passed your runs along with these details.
Hi @Colin
Thanks for the analysis.
Now, after upgraded to 1.3.1, the entire team is stuck.
Do you have some workaround?
Is it a regression? Can we solve something downgrading some library?