Cursor 429 response

[QD-Y]

On Windows, claude-code-proxy 0.1.23 loads the Cursor provider and accepts Cursor model IDs, but all Cursor-backed requests return:

Connect error 429: Error (resource_exhausted)

Tested models:

• cursor
• cursor-plan
• cursor-ask
• composer-2.5
• composer-2.5-fast
• cursor-composer-fast

Environment:

• Windows 11
• claude-code-proxy 0.1.23
• Cursor app version 3.12.30
• CCP_CURSOR_CLIENT_VERSION unset
• claude-code-proxy cursor auth status shows valid auth.json and unexpired access token
• no HTTP_PROXY/HTTPS_PROXY env vars
• WinHTTP proxy = direct
• Internet Settings proxy disabled
• Test-NetConnection api2.cursor.sh -Port 443 succeeds
• curl.exe https://api2.cursor.sh/ returns normal "Welcome to Cursor" response

Claude harness is correctly pointed at the proxy and requests appear in proxy.log, but all Cursor upstream requests return 429 resource_exhausted.

Official Cursor app/CLI usage works on the same account.

[ruredi]

Same symptom on macOS (0.1.23 and 0.1.24), and I think I can narrow down the root cause: it's the x-cursor-client-version header, not the account.

Repro/diagnosis (macOS 15, proxy 0.1.23 → upgraded to 0.1.24, cursor auth status valid, ~15% of plan usage consumed, same account works fine in the official Cursor app):

• Default config (no CCP_CURSOR_CLIENT_VERSION): every Cursor-backed model (cursor, composer-2.5, cursor:grok-4.5, …) returns Connect error 429: Error (resource_exhausted) on the first request — so it's not a real quota condition.
• The proxy's built-in default is 0.48.5 (cursor_client_version() in src/config.rs). Cursor's backend appears to reject requests carrying that ancient version outright, and the rejection surfaces as resource_exhausted.
• CCP_CURSOR_CLIENT_VERSION=3.12.17 (the currently installed Cursor app version): the 429 disappears — the request is accepted upstream — but the response then fails to decode:
  Response decoding error: Connect error 502: parse binary: premature EOF (internal)
  i.e. the wire format the server speaks to a 3.12.x client differs from what the proxy's Connect client parses.
• Other version strings tried (1.0.0, 0.50.5, 1.7.52, a date-form 2026.07.10-…): all 429 resource_exhausted.

So it looks like two layered issues: (1) the default client version is now blocked server-side (reads as resource_exhausted, which is confusing), and (2) bumping the version unlocks the request but requires supporting the newer binary response framing. Happy to test a build if you want a guinea pig on macOS.