Repository navigation
[Bug] Cursor Claude-family models fail via Claude Code path — needs v2.11+ paired trace #1162
Description
Area
Providers / Cursor adapter / Claude Code inbound path
Status
This is a credible provider-compatibility report, but the available reproduction is from OpenCodex 2.10.2.
Cursor transport and model plumbing changed substantially afterward, so the original failure must be reproduced on v2.11.0 or newer before we infer a current adapter defect.
There is not yet enough evidence for a safe model-name, quota, client-identity, or thinking-negotiation patch.
Historical reproduction
On OpenCodex 2.10.2, Cursor-routed Claude-family models failed deterministically through the Claude Code / Anthropic Messages path while non-Claude Cursor models succeeded on the same account.
Reported examples included:
claude-4.6-opus -> FAIL
claude-opus-4-7 -> FAIL
claude-opus-4-8 -> FAIL
claude-opus-5 -> FAIL
claude-fable-5 -> FAIL / occasional partial stream
claude-sonnet-5 -> FAIL
claude-4.6-sonnet -> FAIL
grok-4.5 -> PASS
kimi-k3 -> PASS
composer-2.5 -> PASS
The reporter also verified that the same Cursor account could run the affected Claude models through the native Cursor Agent CLI.
That makes the original family split meaningful and argues against a simple account-quota explanation.
Historical upstream symptom
The failing OpenCodex path reached Cursor successfully and began streaming before Cursor terminated the request:
wireModel: claude-opus-5-high
framesReceived: 14
final code: resource_exhausted
classified: Cursor rate limit exceeded
A small no-tools request reportedly failed the same way, so the previously investigated large tool/catalog budget was not sufficient to explain the failure.
The original report also observed different behavior on the Responses inbound path for some Cursor Claude models, so we should not collapse all Cursor/Claude failures into one assumed cause.
Required current reproduction
Please retest the same affected Claude model on OpenCodex v2.11.0 or newer.
Use the same Cursor account and, as closely as possible, the same time window for:
- native Cursor Agent success; and
- OpenCodex failure.
If the bug persists, provide one redacted paired trace containing:
Native Cursor success
vs.
OpenCodex failure
for the same model.
Capture these boundaries:
- resolved Cursor wire model;
- connect-request capability/client fields;
- the first response frame types/codes up to the failure boundary;
- final upstream status/error metadata.
Do not include:
- OAuth tokens;
- access or refresh credentials;
- prompt/request text;
- other sensitive account data.
The useful next artifact is the first differing admitted field between the native request and OpenCodex request.
Why more evidence is required
resource_exhausted after a stream has already begun does not identify the incompatible handshake field.
The current evidence has already made several simple explanations unlikely:
- the same account accepts the native Cursor request;
- non-Claude Cursor models succeed;
- wire model IDs appeared correct;
- reducing tool/catalog size did not remove the failure.
Guessing at client identity, model aliases, quota policy, or thinking negotiation without a current paired trace risks breaking Cursor models that already work.
Expected behavior
A supported Cursor Claude-family model should complete through the Claude Code / Anthropic Messages path whenever the same account/model is accepted by Cursor and no genuine quota/provider error exists.
Provider errors should retain their real classification rather than being converted into a misleading local diagnosis.
Acceptance criteria
- Failure is reproduced on OpenCodex v2.11.0 or newer.
- Native Cursor succeeds for the same account/model during the comparison.
- A redacted paired native/OpenCodex trace identifies the first material request or response difference.
- Root cause is established before introducing model-family-specific behavior.
- Any fix preserves currently working non-Claude Cursor models.
- Regression coverage reproduces the confirmed failing boundary.
- Accepted correction is merged into
dev.
Related
- 커서 사용 관련 문의 #72 — older intermittent Cursor resource-exhausted report.
- [Bug]: Cursor resource_exhausted with large Codex namespace tool catalog #190 — separate large catalog/tool-budget failure class.
Activity
github-actions commentedon Aug 6, 2026
Automated translation bookkeeping — detected language: English.
github-actions commentedon Aug 6, 2026
Maintainer decision respected
A maintainer has reopened this issue. The automated closure has been deactivated.
test(issue-quality): reproduce #1162 false close
fix(cursor): preserve the Grok wire model prefix on requests (#1159)
fix(cursor): preserve the Grok wire model prefix on requests (lidge-j…
Ingwannu commentedon Aug 8, 2026
The model-family split and the native Cursor control make this a credible compatibility bug, but
resource_exhaustedafter 14 upstream frames does not identify which handshake field differs. There is no safe model-name or quota patch to make from the current evidence: the same account accepts the native Cursor request, and tool/catalog size has already been ruled out.\n\nPlease retest on v2.11.0 first because the Cursor transport/model plumbing changed substantially after 2.10.2. If the failure persists, capture one redacted native-success / OpenCodex-failure pair for the same Claude model at these boundaries: resolved wire model, connect request capability/client fields, first 14 response frame types/codes, and final upstream status metadata. Do not include OAuth tokens or request text. With the first differing admitted field we can patch and regression-test the adapter; until then, guessing at client identity or thinking negotiation risks breaking the non-Claude models that already pass.[-][Bug]: Cursor Claude-family models deterministically fail via Claude Code path (resource_exhausted after stream start) while non-Claude Cursor models pass[/-][+][Bug] Cursor Claude-family models fail via Claude Code path — needs v2.11+ paired trace[/+]Wibias commentedon Aug 11, 2026
Since this is now obsolete, please open a new issue if you still encounter this issue.
test(issue-quality): reproduce lidge-jun#1162 false close
fix(cursor): preserve the Grok wire model prefix on requests (lidge-j…