Cursor BYOK is very slow

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m using Cursor with BYOK mode enabled (Custom OpenAI Base URL). However, Cursor frequently gets stuck at the “planning next moves” step for a very long time and it shows after every request.

I’ve ruled out a slow endpoint because everything works fine when I try to access it directly with other software (Claude Code, Open Code).

It’s worth noting that some requests are very fast at times, but most are very slow.

Does Cursor have a “slow pool” for BYOK requests? Or is it because I’m still using the old pricing plan (500 requests) and haven’t opted in the new pricing plan?

Steps to Reproduce

Turn on BYOK and do any task. Requests will not error. However, it will be very slow during “planning next moves”.

Expected Behavior

speedup

Operating System

MacOS

Version Information

Version: 3.12.10
VS Code Extension API: 1.128.0
Commit: 24a12dbd9cabf48956ce5bb3dbd234e41385b3d0
Date: 2026-07-16T03:15:48.538Z
Layout: IDE
Build Type: Stable
Release Track: Nightly
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Claude Opus 4.8 x-high

For AI issues: add Request ID with privacy disabled

e4d8a471-13e4-4347-942e-6bb98930bc36

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report and the Request ID.

Short answer to your question: no, there’s no slow pool for BYOK. The slow pool wait time only applies when you’re using Cursor’s own API key, not your own. The old plan limit (500 requests) also doesn’t affect BYOK, it doesn’t apply to requests made with your key.

What’s actually happening: most of the time is spent on your endpoint. That’s the model’s reasoning time (Opus 4.8 x-high can take a few seconds per step) plus the context size. The Cursor agent sends noticeably more context on each step than a lighter direct call from Claude Code or Open Code, so Cursor can feel slower even if the endpoint itself is fast.

There’s also a known bug on our side: when using a custom OpenAI Base URL, Cursor currently doesn’t render the model’s streaming reasoning. Because of that, the whole reasoning phase on each step just shows as Planning next moves. It looks stuck, but the model is actively thinking during that time. We’re tracking it, but I can’t share an ETA for a fix yet.

So the speed is limited by reasoning and context on your endpoint, not any throttling from Cursor. If there’s an update on showing reasoning for custom base URL, I’ll post it in the thread.