Conversation
|
@kanri-san review |
SummaryAdds support for Grok 4.5 and its six named variants (base, fast, low-effort, low-fast, high-effort, high-fast) across the local-agent bridge and worker model catalog. The bridge normalizes public ids (including legacy Changes
Walkthrough by kanri |
![kanri-san[bot]](https://avatars.githubusercontent.com/in/4254147?s=60&v=4){kind=small}
There was a problem hiding this comment.
Issues
1. worker/cursor.ts resolveCursorModel normalizes Composer hyphenated aliases (e...
Location: worker/cursor.ts:64
Severity: warning
worker/cursor.ts resolveCursorModel normalizes Composer hyphenated aliases (e.g., composer-2-5-fast → composer-2.5-fast) but has no equivalent Grok 4.5 alias handling. A request with model=grok-4-5-fast falls through to return { id: model.trim() }, so the chat route sends the raw hyphenated id to the Cursor API and the cost path computes cost from the raw hyphenated string, omitting the cost field. Add Grok 4.5 alias normalization to resolveCursorModel and ensure cost/pricing lookups handle the aliases.
Verdict
Status: APPROVED
No critical defects found. The bridge and model list are consistent, but worker/cursor.ts needs the same Grok 4.5 alias normalization to avoid sending raw hyphenated ids to the Cursor API and omitting cost on SDK responses. The model-list test should also verify per-variant costs.
2 findings below min severity (warning) were omitted from posting.
The effective status was recalculated from current findings and prior Kanri threads: APPROVED.
Inline comments: 1
Reviewed by kanri | 1 new inline comments
| expect.objectContaining({ id: "gpt-5.3-codex" }), | ||
| expect.objectContaining({ id: "gemini-3.1-pro" }), | ||
| expect.objectContaining({ id: "default" }), | ||
| expect.objectContaining({ id: "grok-4.5" }), |
There was a problem hiding this comment.
WARNING
The new /v1/models test only asserts that each Grok 4.5 variant id is present; it does not verify the per-variant cost field (e.g., grok-4.5 at 2/6 vs grok-4.5-fast at 4/18). A pricing regression such as copying the fast price to all variants would pass. Add cost assertions for each Grok 4.5 variant and include cost in the body type annotation.
Fix with AI
Verify the issue still exists before applying this fix.
The new /v1/models test only asserts that each Grok 4.5 variant id is present; it does not verify the per-variant cost field (e.g., grok-4.5 at 2/6 vs grok-4.5-fast at 4/18). A pricing regression such as copying the fast price to all variants would pass. Add cost assertions for each Grok 4.5 variant and include cost in the body type annotation.
In worker/__tests__/index.test.ts, inside the 'requires a bearer token for /v1/models' it block, after the existing arrayContaining assertion, add explicit per-id cost assertions: expect(body.data.find((m) => m.id === 'grok-4.5')?.cost).toEqual({ input: 2, output: 6 }); expect(body.data.find((m) => m.id === 'grok-4.5-fast')?.cost).toEqual({ input: 4, output: 18 }); expect(body.data.find((m) => m.id === 'grok-4.5-low')?.cost).toEqual({ input: 2, output: 6 }); expect(body.data.find((m) => m.id === 'grok-4.5-high')?.cost).toEqual({ input: 2, output: 6 }); expect(body.data.find((m) => m.id === 'grok-4.5-low-fast')?.cost).toEqual({ input: 4, output: 18 }); expect(body.data.find((m) => m.id === 'grok-4.5-high-fast')?.cost).toEqual({ input: 4, output: 18 }). Extend the body type annotation to include cost?: { input: number; output: number }.
Resolve legacy grok-4-5 ids in resolveCursorModel and pricing lookups, and assert per-variant Grok 4.5 costs in the model list test.
|
Status: COMMENTED The unresolved finding C2 has been fixed; no new issues remain in the recent changes. The effective status was recalculated from current findings and prior Kanri threads: COMMENTED. No inline comments on the diff. Walkthrough summary/changes preserved from an earlier completed run and may not reflect the latest push. Verdict by kanri |
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
1 participant
What this PR does
Adds support for Grok 4.5 and its six named variants (base, fast, low-effort, low-fast, high-effort, high-fast) across the local-agent bridge and worker model catalog. The bridge normalizes public ids (including legacy
grok-4-5andcursorapi/…prefixes) and maps each variant to an SDKmodelselection withfastand optionaleffortparameters. The worker exposes the new variants in its model list and registers pricing entries sourced from the Cursor Grok 4.5 pricing page.