Cursor BYOK omits selected reasoning effort for custom OpenAI Base URLs

[masterkain]

Summary

Cursor BYOK with Override OpenAI Base URL can omit the reasoning level selected in Cursor's model picker.

Codex Pooler receives and processes the request normally, but cannot infer the missing UI choice safely. This is tracked as a client interoperability limitation, not a Pooler defect.

Verified behavior

A real Cursor desktop Agent run used:

• an explicit gpt-5.6-luna selection
• Cursor Pro
• OpenAI API key with Override OpenAI Base URL
• a public HTTPS endpoint routed through a metadata-only local diagnostic proxy to Codex Pooler

Across 83 observed Cursor requests, the top-level request shape contained fields such as model, messages, stream, tools, user, and stream_options, but never reasoning or reasoning_effort. This remained true while the Cursor picker displayed a Medium reasoning level.

The same Pooler deployment accepts an explicit Chat Completions reasoning_effort: "high" request and:

• forwards reasoning.effort: "high" upstream
• persists requested, effective, and applied effort as high
• returns a successful completion

This rules out Pooler normalization, dispatch, and accounting as the point where the selected Cursor effort disappears.

Why this is wontfix here

The selected effort is not present in the client request. Guessing it from a displayed model, API key, prompt, or prior turn would create misleading accounting and make policy enforcement non-deterministic.

Pooler will continue to:

• honor an explicit client reasoning_effort
• enforce configured Pool API-key reasoning policies
• allow operators to require a fixed effort through policy when that is appropriate

It will not synthesize an omitted Cursor UI setting.

External sources

Cursor staff has confirmed that custom Override OpenAI Base URL requests omit selected reasoning effort on the Chat Completions path:

• Cursor forum: BYOK does not send the reasoning_effort parameter for GPT-5.6 models
• Cursor staff clarification that the issue applies whenever a custom base URL is enabled
• Cursor staff confirmation that the issue still affected Luna in August 2026

Cursor also documents its server-side BYOK architecture in this forum response:

• Cursor forum: custom endpoints must be public because requests pass through Cursor servers

Related

This limitation was found during the broader Cursor compatibility work.

Users who need a chosen effort with Cursor BYOK should configure the desired Pool API-key reasoning policy rather than relying on Cursor's picker to transmit it.

[bshx2024]

Very thorough breakdown, @masterkain. We observed the exact same payload behavior when benchmarking Cursor's BYOK path against OpenAI-compatible gateways.

A few corroborating observations from our tests:

1. Parameter Stripping: Cursor's desktop client indeed strips non-standard top-level parameters (and specific reasoning_effort flags) on the /v1/chat/completions route when Override Base URL is active. The client UI selection doesn't reliably serialize into the wire protocol.
2. Server-Side Middleman: Because Cursor routes BYOK requests through their relay cluster before hitting the custom endpoint, standard local localhost endpoints fail unless exposed via public tunnels or dedicated proxies.
3. Recommended Gateway Workaround: Injecting the policy at the gateway level (e.g. mapping virtual model aliases like model-name-high or enforcing API-key level defaults in the pooler) is indeed the only deterministic fix until the Cursor team standardizes reasoning parameter serialization across BYOK channels.

We documented similar client-side quirks and the exact token billing / rate-limit trade-offs when stress-testing Cursor BYOK against different proxy backends here for anyone diving into Cursor gateway interoperability:
👉 Cursor Pro vs. Custom API Key (BYOK) Cost & Limits Guide

Thanks for documenting the trace logs on this!