Last post I argued the harness is portable: point Claude Code at whatever model you want and the coupling to a lab’s billing turns out to be a string in an environment variable. This week I proved it by adding Grok, so you can run Grok 4.5 on an X subscription inside Claude Code. Then, because the setup makes it trivial, I did something recursive: I let Grok 4.5 code-review its own integration, and let Opus grade Grok’s review.
The Spectrum Completes
Adding Grok was the easiest of the three subscription backends, and the reason is a policy, not a protocol. There’s a spectrum on using your subscription token inside a tool the lab didn’t ship:
- Anthropic banned it. OAuth tokens from Pro/Max accounts are prohibited in any other product, and it’s enforced.
- OpenAI shrugged. No clause either way; tolerated in practice.
- xAI blessed it. It publicly endorsed third-party OAuth login, and Grok’s backend speaks the Anthropic API natively, so the integration needed no translation at all.
Grok is the open extreme. The lab furthest behind on the model is furthest ahead on letting you take it anywhere, which is exactly the move you’d expect when your lead is a rounding error: being the platform people build on beats being the one they’re locked into.
The Recursive Review
The tool is claude-launcher, the wrapper I’ve been building for exactly this. Install it with bun add -g claude-launcher, then claude-launcher -g points Claude Code at grok-4.5 on your X subscription (-c does the same for a ChatGPT plan). So: launch it, then run /code-review high at the launcher’s own source. It worked end to end. It spawned eight parallel finder subagents, collected their output, and returned ten findings, each with a file, a line, and a confident failure scenario. On its face, a thorough review.
Ten Findings, Two Real
Then I cross-verified every one against the code and had Opus grade the batch. The scorecard:
- Two were real. Both low-severity latent gaps: a token refresh that kept a stale key if the response omitted a field, and a default-value fallback that diverged from its sibling. Both fixed in a minute.
- One was a fair cleanup. Two backend branches that genuinely duplicate logic. True, but not a bug.
- Seven didn’t survive. Some overstated impact: a code path that self-heals on the next request, reported as “every request fails.” Some flagged working-as-intended: a graceful fallback to a safe default, called a defect. One flagged a concurrency “bug” that, read carefully, is the code being correct.
Ten confident findings, two worth acting on, and nothing critical. That last part is its own small reassurance. It isn’t the point.
Grok found real patterns, then told me with equal confidence which of them were fires. It was wrong about the fires most of the time.
Why Review Is the Cruel Test
Execution and review reward opposite things. Execution tolerates being wrong: Grok is fast enough that a bad edit is a two-second reject-and-retry, and its token efficiency makes that loop cheap. Review is the inverse. A review’s entire value is calibration, telling you which of a hundred things deserve your attention. A false alarm there costs more than a miss, because it burns the scarcest resource in the loop: your trust that a flagged thing is real. A reviewer that cries wolf eight times in ten trains you to ignore it, which is worse than no reviewer at all.
This is the same axis I keep circling. Opus 4.8’s headline feature was honesty: self-verification and calibrated confidence. Grok 4.5’s headline was efficiency. Those aren’t the same virtue, and review needs the first one. The axis that matters is calibration, not price: a model can be cheap and calibrated, or fast and not. Sol is cheap and, in my experience, a razor-sharp reviewer. Grok 4.5 is cheap and traded that away. The pairing is the point, not the price tag.
The Bookkeeping Tell
There was a smaller tell in the same run. Mid-review, Grok began calling the tool that reads a subagent’s output with IDs that didn’t exist. It had invented plausible-looking task IDs instead of using the real ones. The review limped on, but it was hallucinating its own bookkeeping. Fast hands, shaky memory for precise state, and the efficiency that makes it a good executor (fewer tokens, less deliberation) is the same trait that makes it a poor clerk.
It isn’t “Grok is bad.” Grok 4.5 completed a real multi-agent review end to end, on a subscription, through a translation layer, which a year ago was science fiction. Its benchmarks are real, its speed is real, and for building it’s a genuinely good, cheap option. The claim is narrower, and it cuts across every lab: recall is not precision, and the task decides which one you’re buying.
What I Actually Do With It
The same shape as plan big, execute small, now across vendors instead of within one:
- Grok for the hands. Scaffolding, refactors, the fast agentic middle where you verify the output quickly anyway.
- A calibrated model for the verdict. Review, architecture calls, anything where a confident-wrong answer is expensive to trust. Fable and Opus earn that seat, and in my experience so does Sol: it’s the sharpest reviewer of the lot.
Bring-your-own-model makes that a per-task choice instead of a per-subscription one. You stop picking a lab and start picking an instrument.
The frontier converged to a rounding error, but convergence is per-axis. “Opus-class” on an intelligence index and “trustworthy in the reviewer’s chair” are different measurements, and a single leaderboard number hides the gap between them. The cheapest way I’ve found to see it is the one I stumbled into this week: let the model grade its own homework, then let a more calibrated one mark the grading. Ten findings. Two real. The other eight were the lesson.
Related Posts
