chore(cursor-review): bump panel pins to claude-opus-5-thinking-max and kimi-k3-max (BE-4818) - #86
chore(cursor-review): bump panel pins to claude-opus-5-thinking-max and kimi-k3-max (BE-4818)#86mattmillerai wants to merge 2 commits into
Conversation
…nd kimi-k3-max (BE-4818) Refresh the review panel per the 2026-07-27 catalog re-audit. Anthropic slot moves Opus 4.8 -> Opus 5 thinking (max tier, ZDR-eligible, identical per-token pricing) and the judge default follows it; Moonshot moves K2.7 Code -> Kimi K3 (max tier). OpenAI (gpt-5.6-sol-max) and Google (gemini-3.1-pro) are unchanged. README model/inputs tables and the judge prompt's attribution example are kept in sync.
mattmillerai
added
cursor-review
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 29 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: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔍 Cursor Review — Consolidated panel
Triggered by @mattmillerai.
Found 2 finding(s).
| Severity | Count |
|---|---|
| 🟠 High | 2 |
Panel: 8/8 reviewers contributed findings.
… (BE-4818) main independently bumped the Anthropic pin to claude-opus-5-thinking-max with an unconfirmed-ZDR caveat; this branch's own comment already covers that same bump plus the Kimi K3 bump, backed by a live-catalog check (no NO-ZDR marker on either id, see PR body). Kept this branch's comment.
2 participants
ELI-5
The PR reviewer here is a panel of four AI models, one per lab. Two of them just got newer, smarter siblings, so this swaps in the new names: Anthropic's Opus 4.8 becomes Opus 5, and Moonshot's Kimi K2.7 Code becomes Kimi K3. The OpenAI and Google picks stay put. Nothing about how the review works changes — only which four models do it.
What
Refreshes the
cursor-reviewmodel panel per the BE-4817 spike audit against the livecursor-agent modelscatalog (2026-07-27). Two slots superseded, two unchanged..github/workflows/cursor-review.yml—judge_modelinput defaultclaude-opus-4-8-thinking-max→claude-opus-5-thinking-max(the judge is documented as matching the panel's highest reasoning tier, so it moves with the Anthropic slot)..github/workflows/cursor-review.yml— "Define panel models" heredoc (the single source of truth thereviewmatrix consumes viafromJSON):claude-opus-4-8-thinking-max→claude-opus-5-thinking-max,kimi-k2.7-code→kimi-k3-max.gpt-5.6-sol-maxandgemini-3.1-prounchanged. The catalog comment block above it is rewritten to record the new audit date and rationale; its structure (single-source-of-truth note, README-sync note) is preserved..github/cursor-review/README.md— lab/model table and thejudge_modelrow of the inputs table..github/cursor-review/prompt-judge.md— the attribution example that names a panel model verbatim (found by the repo-wide grep the ticket asked for).Panel shape (8 jobs / 4 labs / adversarial + edge-case) is unchanged.
Why these ids
Every claim in the new comment block was checked against the actual catalog printed by the preflight job of
Comfy-Org/comfy-cloud-mcp-serverrun30314000838(job90135615477, 2026-07-27T23:24Z), not taken from the ticket on faith:claude-opus-5-thinking-max - Opus 5 1M Max Thinking— present verbatim, no(NO ZDR)marker.kimi-k3-max - Kimi K3— present verbatim, no(NO ZDR)marker. (kimi-k3-high/kimi-k3-lowalso exist;maxis the top tier.)claude-fable-5-*entry carries(NO ZDR), which is why Fable stays excluded from a panel that reads private-repo diffs.gpt-5.3-codex-*; there is no 5.6 codex variant.gemini-3.1-prois still the only Pro-line Gemini entry; 3.5/3.6 are Flash tier.Cost: Opus 5 is priced identically to Opus 4.8 ($5/$25 per M), so the Anthropic swap and the judge bump are cost-neutral. Kimi K3 ($3/$15) vs K2.7 Code ($0.95/$4) is ~3.2x/3.75x per token on this lab's two panel cells — roughly +10-15% total panel cost per PR. That increase was accepted by the spike audit and is now recorded in the comment block.
Testing
python3 -m unittest discover -s .github/cursor-review/tests -p 'test_*.py'— 40 passed.check_agents_md.py --root .(passed; the one warning is the pre-existing missing-CODEOWNERS DRI warning, unrelated to this change).cursor-review.ymlwith PyYAML and re-parsed the heredoc as JSON to confirm the pin list is exactly["gpt-5.6-sol-max", "claude-opus-5-thinking-max", "gemini-3.1-pro", "kimi-k3-max"]— a YAML/JSON typo in the heredoc would otherwise only surface at run time.reviewhasneeds: [gate, diff-size, preflight]and its matrix isfromJSON(needs.preflight.outputs.models), so the preflight catalog check fails the run loudly on an unknown id rather than silently dropping a lab. Caveat: that gate does NOT cover this PR.ci-cursor-review.ymldeliberately pins the reusable workflow to a mergedmainSHA (so a PR cannot weaken the panel reviewing it), so this PR's own cursor-review run validated the previous pins. The new ids are verified by hand against the live catalog printed by that run's preflight job (30321904319, 2026-07-28T02:01Z), which listsclaude-opus-5-thinking-maxandkimi-k3-maxverbatim. Preflight will gate them for real on the first PR after this merges and the caller pin is bumped.Judgment calls / notes
judge_modelis not covered by the preflight check. The catalog validation only walks the pins in/tmp/models.json;JUDGE_MODELis not among them, so a bad judge id would fail at judge time instead of preflight. I verifiedclaude-opus-5-thinking-maxagainst the live catalog by hand (above). Extending preflight to validate the judge id too would be a real improvement but is outside this ticket's scope — happy to file it separately.groom.ymlline 241 still mentionsclaude-opus-4-8in a doc comment ("can pin an older id (e.g.claude-opus-4-8) to hold a run steady"). It is neither of the two ids the ticket targets, it belongs to a different workflow with an independent model input, and it is illustrating an older id — so the sentence is still accurate. Deliberately left alone.bump-cursor-review-callers.ymlwithworkflow_dispatchexists for that and is tracked separately).