When using Bring Your Own Key (custom OpenAI Base URL + API key) with GPT-5.6 models, Cursor does not send the reasoning_effort parameter in the request payload to the custom endpoint, even when Max/High reasoning effort is selected.
The priority parameter is sent, but the reasoning effort setting is ignored. This was confirmed by capturing traffic through a simple proxy that forwards requests to OpenAI.
As a result, the reasoning effort selector has no effect when using custom OpenAI-compatible endpoints with GPT-5.6 models.
Steps to Reproduce
Go to Settings → Models and enable Override Base URL + enter your OpenAI API key.
Select a GPT-5.6 model (e.g. GPT-5.6 Sol or Terra) and set reasoning effort to Max (or High).
Open a new chat or Composer.
Use any proxy to inspect the outgoing request to your custom base URL.
Check the request body: priority is present, but reasoning_effort (or equivalent reasoning parameter) is missing.
Expected Behavior
Cursor should include the selected reasoning effort level (e.g. reasoning_effort: “max” or “high”) in the payload sent to custom OpenAI-compatible endpoints, the same way it does with the official OpenAI endpoint.
Hey, thanks for the detailed report, especially the proxy capture. It helped a lot.
Confirmed, this is a bug on our side. When using a custom Override OpenAI Base URL, GPT-5 family requests (including GPT-5.6) get sent to /chat/completions, and on that path the selected reasoning effort is not added to the payload as reasoning_effort. It gets silently dropped. This doesn’t happen on the official OpenAI endpoint managed path, where the effort is applied correctly.
I’ve reported this internally to the team. I can’t share an ETA yet, but I’ll post an update in this thread when I have one.
Good question, let me clarify, the wording was a bit ambiguous.
By managed path, I meant the built-in official OpenAI connection with no Override Base URL, where requests go through our standard integration with api.openai.com. In that case, effort is applied.
As soon as Override OpenAI Base URL is enabled, Cursor classifies the endpoint as Chat Completions no matter whether your URL points to /chat/completions or /responses. So with a custom base URL, reasoning effort gets dropped in both cases, which is exactly what you’re seeing. So your observation is correct, and I fully agree this matches a bug.
To make the bug report as complete as possible, can you share a proxy capture from the responses endpoint test, meaning the outgoing request body? I want to document both cases.
I’m not sure how to capture any more helpful debugging details here but I am having the same issue as I am testing switching from OpenClaw harness to Cursor harness but not being able to pick my effort level is going to be a big issue for me. Let me know what I can provide to help out fixing this. Thank you.
Hey, thanks for reaching out. This is the same issue we’re already tracking: when you use a custom Override OpenAI Base URL, the selected reasoning effort doesn’t make it into the request payload on the /chat/completions path, and based on the report above, it also affects /responses. On the official managed connection to api.openai.com, the effect is applied correctly. I can’t share a timeline yet, but I’ll post in the thread when there’s an update.
If you want to help with debugging, it’d be useful to have:
A proxy capture of the outgoing request body (like the thread author did), so we can see exactly what’s being sent to your endpoint
Your Cursor version, which exact GPT-5.6 model (Sol or Terra), and which effort level (High or Max) you selected
Whether your endpoint is /chat/completions or /responses
This isn’t something in your setup, it’s on our side, so you don’t need to change anything.
Thanks, that’s enough. A proxy capture isn’t required here. The details you shared (Cursor 3.14.7, GPT-5.6 Luna, effort Max, endpoint /chat/completions) are actually useful because they confirm the issue still happens on the latest version and affects Luna, not just Sol and Terra.
This is the same issue we’re already tracking. When custom Override OpenAI Base URL is enabled, the selected reasoning effort doesn’t make it into the request payload. On the official managed connection to api.openai.com, the setting applies correctly. This isn’t anything you misconfigured, so you don’t need to change anything on your side.