Cursor BYOK with "Override OpenAI Base URL" hangs on "Planning next moves" (`No first token received`) while the same endpoint works in curl: Cursor's servers can't reach the endpoint

Context

Source(s): https://forum.cursor.com/t/openai-byok-custom-base-url-hangs-on-windows-3-22-12-endpoint-works-in-other-clients/173471 Signal: 84 views; staff answer accepted, and the original poster confirmed the fix the next day (October 2026). Status: reported working by source, not reproduced by us.

Problem

With "Use OpenAI API Key" and "Override OpenAI Base URL" turned on, every OpenAI-routed model (a custom model, a server-side alias, and built-in GPT-5.5) hangs at "Planning Next Moves" or "Taking longer than expected". After a long wait Cursor sometimes shows a user-provided-key / rate-limit style error (the original poster did not capture its exact wording). The endpoint's reverse-proxy access log shows no request from Cursor. The same endpoint works from curl and another desktop client (GET /v1/models, POST /v1/responses with streaming, POST /v1/chat/completions), and built-in Claude models in Cursor answer normally.

Error (redacted / normalized)

[composer] No first token received within 2s / 4s / 6s / …

Applies when

Cursor 3.22.12 (Windows x64, stable, user setup); a self-hosted OpenAI-compatible proxy behind an HTTPS Nginx reverse proxy on a non-standard port.

Confirm it is this problem

1. Send a minimal prompt in a new Agent chat with the custom model selected, and watch your reverse proxy's access log. → expect: no request from Cursor arrives, even though Cursor keeps waiting.
2. Open the Cursor developer console. → expect: repeated [composer] No first token received within … warnings.

Not this when / boundary

The endpoint answers from a cloud-hosted server and Cursor's requests do show up in your access log; then the hang has another cause (our inference).

Root cause

Per Cursor staff: Cursor did use the override base URL and port, but the requests are sent from Cursor's servers, not from your machine, and those servers could not open a connection to the endpoint. That is why curl works locally but nothing reaches Nginx; the final rate-limit style error is misleading. The original poster then found their firewall (QuFirewall) was dropping incoming TCP connections on that port from cloud-hosted sources.

Fix

1. Test the endpoint from a cloud-hosted server outside your own network, for example curl -sS https://<your-host>:<port>/v1/models -H "Authorization: Bearer <KEY>" (staff said to test with curl from a cloud-hosted server; the exact command is our inference). → expect: if it times out or is refused there, Cursor's servers can't reach it either.
2. Allow inbound HTTPS from cloud networks to the endpoint: check port forwarding, the firewall, and any geo-IP or IP allowlist rules (staff). → expect: the original poster fixed the firewall rule and Cursor then worked with the existing key and base URL; no change to the API key, certificate or model alias was needed.
3. Optional, to use the built-in OpenAI models normally in the meantime: switch off "Use OpenAI API Key" in Cursor Settings > Models (staff: the key plus the override sends all OpenAI models to your endpoint; the key and base URL stay saved). → expect: built-in GPT models answer again (workaround only).

How to verify

The request now appears in the reverse-proxy access log, and the Cursor chat streams a reply instead of hanging.

What did not work

none reported.

Risks

Opening a self-hosted endpoint to inbound internet traffic exposes it: keep key authentication and HTTPS on, open only the API port, and don't expose admin ports (our inference). Don't post your real hostname or key in public threads; the original poster redacted the hostname and offered it to staff privately.

Verified scope

Cursor 3.22.12 on Windows with a self-hosted OpenAI-compatible endpoint, October 2026. Staff described the server-side request path as general BYOK behaviour, so other versions are likely affected the same way (our inference).

Becomes obsolete when

Cursor sends BYOK override requests from the user's machine, or shows a clear "endpoint unreachable" error instead of hanging.