Remove model name from core-reviewer

[avleen]

Opus 4.5 is now out. The pricing for it has dropped dramatically. By raw token counts it's still more expensive than Sonnet 4.5, but Opus 4.5 uses far fewer tokens to do the same work:

https://www.anthropic.com/news/claude-opus-4-5#:~:text=New%20on%20the%20Claude%20Developer%20Platform

Set to a medium effort level, Opus 4.5 matches Sonnet 4.5’s best score on SWE-bench Verified, but uses 76% fewer output tokens. At its highest effort level, Opus 4.5 exceeds Sonnet 4.5 performance by 4.3 percentage points—while using 48% fewer tokens.

As a comparison, this is the cost of running a detailed code review on sonnet:

/cost
  ⎿  Total cost:            $1.88
     Total duration (API):  10m 30s
     Total duration (wall): 5m 16s
     Total code changes:    0 lines added, 0 lines removed
     Usage by model:
         claude-3-5-haiku:  40.5k input, 4.0k output, 0 cache read, 0 cache write ($0.0484)
          claude-opus-4-5:  3.0k input, 7.0k output, 320.0k cache read, 53.0k cache write ($0.68)
            claude-sonnet:  682 input, 17.5k output, 1.4m cache read, 123.6k cache write ($1.15)

And this is Opus:

/cost
  ⎿  Total cost:            $0.81
     Total duration (API):  3m 9s
     Total duration (wall): 6m 39s
     Total code changes:    0 lines added, 0 lines removed
     Usage by model:
         claude-3-5-haiku:  11.8k input, 982 output, 0 cache read, 0 cache write ($0.0133)
          claude-opus-4-5:  1.1k input, 11.7k output, 375.1k cache read, 49.1k cache write ($0.79)

The Opus review is of higher quality and consistently finds more medium to high priority issues to resolve.

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Summary by CodeRabbit

• Documentation

  • Removed a deprecated "model" front-matter reference from the code review documentation; content and guidance remain unchanged.

• Chores

  • Updated documentation metadata to reflect removal of the obsolete entry; no functional or behavior changes.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Removed the public/front-matter field model (previous value: sonnet) from agents/code-reviewer.md; no other content or behavior changes were made.

Changes

Cohort / File(s)	Summary
Code Reviewer Front-matter agents/code-reviewer.md	Public/front-matter field model removed (previous value: sonnet); file content otherwise unchanged.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

• Check that removing the model front-matter is intentional and won't break consumers that expect it.
• Confirm no tooling or CI relies on the model: sonnet entry.

Poem

🐰📄 I nudged a line and hopped away,
The model tag has gone today.
No other change, just lighter fluff—
A tiny tweak, that’s all, enough. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The PR title states 'Remove model name from core-reviewer' but the actual file changed is 'agents/code-reviewer.md' (not 'core-reviewer'). The file name mismatch makes the title misleading.	Correct the title to 'Remove model name from code-reviewer' or another accurate reference to the actual file being modified.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 319ae98 and 7f678a1.

📒 Files selected for processing (1)

• agents/code-reviewer.md (0 hunks)

💤 Files with no reviewable changes (1)

• agents/code-reviewer.md

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[nickolasclarke]

I think this should be parameterized into a CLAUDE.md param or similar.

[avleen]

I think this should be parameterized into a CLAUDE.md param or similar.

Could be done.. I'm new to skills though :-) Any hints or examples on how to do that correctly?

[avleen]

On doing some more research, I think the choices come down to:

1. Be opinionated (my opinion is: default to Opus 🙂 )
2. Remove this completely and let a user's default model be picked.

I couldn't get Claude to consistently apply the right model if I specified it in CLAUDE.md.

If we choose (1), users will have to fork and maintain a local copy if they want changes. Not great, but probably happening already anyway.
If we choose (2) we might avoid some divergence.

@obra thoughts?

[trancong12102]

I vote for option 2

[obra]

I'm inclined to remove the explicit model being set. That'd mean we get a sane default and that instructions in CLAUDE.md should allow customization.

[avleen]

Done!