Use case

Models for code review: what a diff review actually costs

Reviewing a diff is input-heavy and output-light, so the input rate decides the bill. The same 100k-token review runs $0.033 on Claude Sonnet 5 and $0.0056 on Gemini 3 Flash.

A diff review is an input-heavy request

Take a realistic review: 100,000 tokens of diff, surrounding files and instructions going in, and 2,000 tokens of findings coming back. That ratio is 50:1, so the input rate is doing almost all of the work in the total.

Run that shape through four ids at their consumer rates — official per-token price times the model's multiplier. Claude Sonnet 5 (0.1×, $0.30/M in, $1.50/M out) costs $0.030 + $0.003 = $0.033. Claude Opus 5 (0.1×, $0.50/$2.50) costs $0.055. Grok 4.6 (0.1×, $0.20/$0.60) costs $0.0212. Gemini 3 Flash (0.1×, $0.050/$0.30) costs $0.0056.

At one review per pull request the difference is invisible. At 1,000 reviews a day it is $33 against $5.60 — roughly 6× — and that gap is the reason to know which shape your review actually has before picking anything.

Pipe a real diff into a review request and print the usage the gateway reports.

export TOKEN_SHARE_KEY="<your-pool-api-key>"

git diff origin/main...HEAD | jq -Rs '{
  model: "grok-4.6",
  messages: [
    {"role": "system", "content": "Review this diff. List correctness bugs only, with file and line. If there are none, say so."},
    {"role": "user", "content": .}
  ]
}' | curl -sS https://token-share.app/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "Content-Type: application/json" \
  -d @- | jq -r '.choices[0].message.content, "--- usage ---", (.usage | tostring)'

Whether the diff fits is a separate question from price

A review only works if the diff plus the context you send around it fits in the window. The catalog spreads across five rungs: 200,000 tokens (Claude Sonnet 4.6, Grok Composer 2.5 Fast, Claude Haiku 4.5 Stable), 272,000 (GPT 5.5, GPT 5.4, GPT 5.4 Mini), 372,000 (the GPT 5.6 family), 500,000 (Grok 4.6 and 4.5), and 1,000,000 on every 1M-context Claude and every Gemini id.

Most single pull requests fit anywhere on that ladder. Where it stops being true is a review that needs the changed files plus their callers plus a schema plus a design document — that is a large-codebase problem, and the window becomes the constraint before the price does.

The other ceiling is output. A review that emits inline suggestions rather than a summary can be long: Grok tops out at 65,536 output tokens, the older GPT ids and the 200k Claude ids at 64,000, and the 1M-context Claude ids and the GPT 5.6 family at 128,000.

An agentic reviewer changes the arithmetic

The single-shot review above sends one request. A reviewer that calls tools — read a file, grep for callers, run the tests — sends the whole growing transcript again on every turn, so the input tokens are re-billed each time and the total climbs much faster than the number of turns.

Every text model in the catalog carries the tools capability, so that pattern is available on all of them. Two ids stop there: Grok Composer 2.5 Fast and Claude Haiku 4.5 Stable are text plus tools with no extended thinking, while the rest add thinking on top.

If the reviewer re-sends a stable prefix — the same coding standards, the same architecture notes — that prefix is the part worth caching rather than re-reading at full rate. The economics of long tool-calling loops are the subject of the agents page.

How to decide, without taking anyone's word for it

Review quality is not something a price table can rank. What a table can tell you is what each attempt costs, and at $0.0056 to $0.055 per review the experiment is cheaper than the discussion about it.

Take twenty merged pull requests where you already know what was wrong, run them through two or three ids with the same prompt, and count real findings against false alarms. A model that flags six imaginary bugs per review costs you engineer time that dwarfs any per-token difference; a model that misses the one that mattered costs more than that.

There are three request shapes here — OpenAI-shaped ids answer on /v1/responses, Anthropic-shaped ones on /v1/messages, and Grok and Gemini on /v1/chat/completions — and within a shape, swapping ids is a one-field change. Running the same diff through several ids is a loop, not a migration.

Common questions

Does a cheaper model just mean a worse review?

Price here is set by the official per-token rate times the multiplier, not by a quality grade — Gemini 3 Flash and Claude Sonnet 5 both carry a 0.1× multiplier and differ because their official rates differ. Whether the cheaper id finds your bugs is measurable on your own merged pull requests, and that measurement is the only answer worth having.

Why is the output price almost irrelevant in these numbers?

Because a review reads far more than it writes. In the 100,000-in / 2,000-out example, output is 2% of the tokens; on Claude Sonnet 5 it is $0.003 of a $0.033 request. If your reviewer emits inline patches instead of a summary, that ratio moves and the output rate starts to matter — recalculate with your own numbers rather than reusing these.

Can I run review on a schedule against every open pull request?

That is a batch workload wearing a review costume: the per-request cost stops mattering and the daily total takes over. At 1,000 reviews a day the 100k-token example runs $5.60 on Gemini 3 Flash and $55 on Claude Opus 5. Estimate the monthly figure before you turn the schedule on.