Since today, OpenAI / ChatGPT models used through BYOK in Cursor start replying briefly and then abort. The reply begins normally, but after a short partial answer the generation stops / aborts. This happens consistently and makes the model unusable in Cursor.
The same BYOK setup was working before. My proxy/API connection itself appears to be reachable, and the provider requests do not look like a normal authentication failure.
The model should stream the full response normally and complete the message.
Actual Behavior
The response starts, then aborts after a brief partial reply.
Additional Information
This started today. It may be related to existing BYOK/custom OpenAI endpoint issues where Cursor mixes Responses API-style payloads with /chat/completions, or where custom base URL routing behaves inconsistently.
Please let me know which logs would be most useful.
Steps to Reproduce
Steps to Reproduce
Open Cursor.
Enable OpenAI API Key / BYOK.
Use a custom OpenAI-compatible endpoint / proxy.
Select an OpenAI / ChatGPT model.
Send a normal prompt in Agent or Chat.
Observe that the model starts answering briefly, then the response aborts.
Expected Behavior
Expected Behavior
Cursor should give a normal response, working on a task until its finished.
Thanks a lot for the fast reply; I usually use Privacy Mode. I changed to âShare Dataâ and ran the âContinueâ prompt on the existing chat where the error occurred.
I hope you can access it.
Request ID: de0c4704-03c1-462d-a299-2e875ace1625
Yeah, please do! We pushed some changes last night in this area (BYOK OpenAI) and so I was not at all surprised to hear that something might have regressed.
It explicitly aborts when I ask it to make changes to documents or write things. Reading and grepping work.
Additional update: Using GPT-5.5 and BYOK, Cursor in Agent Mode doesnât write.MD files (or any other files; for example, for planning). If I switch it to Plan Mode and ask it to write an .MD file, it does so.
Havenât used Cursor or my BYOK setting yesterday. I assume its the same error.
An additional Request ID:
7110c29a-47b5-4639-9a75-a4ed2b39359d
In that chat, the Agent was able to write files using GPT-5.5. However, after the first run, when trying to continue, I got the following error:
Provider returned error: { âerrorâ: { âmessageâ: âInvalid âinput[142].call_idâ: string too long. Expected a string with maximum length 64, but got a string with length 83 instead.â, âtypeâ: âinvalid_request_errorâ, âparamâ: âinput[142].call_idâ, âcodeâ: âstring_above_max_lengthâ } }
Sub-agents work in a different workspace and repo, using a new chat and the classic IDE. No idea whether a difference between classic IDE and Agent Window can have an impact. I dont think so. The related Request ID:
c1446868-d80f-40e0-be17-758bece6daf1
The âstarts normally, then abortsâ part is the useful signal here.
That usually points to a streaming or payload-shape mismatch more than a plain auth problem. If the same endpoint works outside Cursor, the best evidence would be the final chunk or error returned by the proxy right when Cursor stops reading.
