Repository navigation
[Bug][Cursor] grok-4.5-fast dropped: live wire ids use trailing -fast after effort #731
Closed as not planned
Description
Activity
Issue closed: use an issue template
Thanks for taking the time to submit this issue. It was closed automatically because it was not opened with a recognized issue template (Bug report, Feature request, Documentation, or Provider compatibility). Freeform and API-opened issues cannot skip this check.
- This looks like a bug report but it does not use the Bug report template headings (for example Description/Log entry instead of Summary).
Please edit the issue to add:
- Use the Bug report template, or edit this issue to include: Client or integration, Summary, Reproduction, Version, and Operating system.
- Retitling with
[Bug]:and applying thebuglabel alone is not enough without those section headings filled in.
See the Contributing guide for details.
Once the report passes the automated checks, it will be reopened automatically unless a maintainer has changed its state.
Automated translation bookkeeping — detected language: English.
Summary
Cursor
GetUsableModelscurrently returns Grok Fast as:cursor-grok-4.5-low-fastcursor-grok-4.5-medium-fastcursor-grok-4.5-high-fastOpenCodex still assumes the older shape
grok-4.5-fast-{medium,high,xhigh}(and builds wire ids that way). As a result:grok-4.5-fastunavailable even when Fast is on the account.cursor/grok-4.5-fastwould sendgrok-4.5-fast-high, which Cursor rejects (not_found).Reproduction
GetUsableModels).ocx login cursor+ocx sync.ocx models selected cursor/ catalog: onlygrok-4.5, notgrok-4.5-fast.Evidence (redacted)
Raw usable Grok ids from
GetUsableModels:isCursorModelAvailableForAccount("grok-4.5-fast", liveIds)→falseon current main.After matching trailing
-fast, →true.Expected
cursor/grok-4.5-fastwhen Fast wire ids are present.grok-4.5-{effort}-fast.grok-4.5-fast-{effort}live ids still count as available for compatibility.Area
Provider adapter (Cursor)
Related
PR: #730
Checks
cursor-prefix, not trailing-fast).