12 Cents a Code Review
How We Run Gemini as Our AI Code Reviewer
We build internal tools for departments across the whole company. Every pull request, on every one of those tools, gets an AI review before a human looks at it.
That part is not new. What changed is the bill.
Why we moved
Our AI PR review used to run on Claude. The reviews were good. The cost was not something I could defend for much longer.
Code review is a volume game. Every push, on every PR, on every repo. A few cents too many per review turns into a real line item very quickly.
So we looked at Gemini.
I did not want to build a reviewer from scratch. And I did not have to. There is an open-source GitHub Action that does exactly this: gemini-review-action, built and maintained by Darren a fellow Google Developer Expert.
It reviews the PR with full codebase context, posts inline findings, and runs on Vertex AI. It is a small install. You add a workflow file and you are reviewing.
Thank you Darren ❤️
What we run with it
We rolled it out to about 40 repositories.
From August to 14 October 2026 it ran 2,667 reviews. The total cost was about $321. That is roughly 12 cents per review.
For a reviewer that reads every PR and never gets tired, I think that is a very good deal.
There are also no API keys. Not in a single repo secret. The action authenticates to Vertex AI through Workload Identity Federation, so GitHub proves who it is to Google Cloud and gets a short-lived token. Nothing to rotate, nothing to leak.
If you take one thing from this article, take that. Keyless is the default you want for anything that runs in CI.
The comparison that actually matters
Early on, one PR had already been approved by a human. The comment was “LGTM”.
Then the Gemini reviewer ran on the same PR and flagged issues nobody had seen.
That moment changed how I think about this. I had spent a lot of time asking whether Gemini reviews as well as Claude. That is the wrong question for most teams.
Get Sascha Heyer’s stories in your inbox
Join Medium for free to get updates from this writer.
The real comparison is not Gemini against Claude. It is a reviewer against no reviewer. Against a tired human on a Friday afternoon. Against “LGTM”.
Why I contributed upstream instead of forking
Running something on 40+ repos shows you its edges fast.
The easy path is a fork. Patch what bothers you, keep it private, move on. I did not want that. A fork means I maintain a second copy forever, and everyone else hits the same problems I already solved.
So every fix went back upstream. Darren was quick and generous with reviews, and these are merged now:
- 🧵 Resolving threads the reviewer agrees are fixed. When the reviewer sees a finding was addressed, it resolves its own thread. Branch protection stops blocking on feedback that is already settled.
- 🙈 Not ingesting a competing reviewer’s findings. If another bot comments on the PR, you can exclude it from the prompt. Otherwise the reviewer happily repeats someone else’s findings as its own.
- 💰 Honest cost reporting. The action now reports an estimated cost per review, and prices cached input correctly instead of overstating the savings.
- 🏷️ Vertex billing labels. Every request is labeled, so review spend shows up separately in Cloud Billing. That is the only reason I can give you the numbers above.
- 🔁 Retries. A flaky GitHub API call no longer throws away a review that was already finished.
- 📌 SHA-pinning guidance. The docs now recommend pinning the action to a commit SHA, not a tag, and warn about concurrency settings that quietly run two reviews at once.
- 📄 A cap on large files. One huge generated file could exhaust the context and kill the review. Now it cannot.
None of these are big. Together they make the tool better for everyone who uses it, not just us.
The bigger point: review with a different model
Here is the part I find most interesting.
More and more teams review code with a different model family than the one that wrote it. I think that is the right instinct.
A model that wrote the code tends to agree with itself. It made a choice for a reason, and it finds the same reason convincing when it reads the diff back. Same model, same blind spots.
A reviewer from a different family brings different training, different habits, different things it notices.
So if your team writes most of its code with Claude a Gemini reviewer gives you that second opinion. For cents.
Try it, and help make it better
If you are on GitHub and Google Cloud, give gemini-review-action a try. Start with one repo. Use Workload Identity Federation from day one. Pin it to a SHA.
And if you hit an edge, send a PR. Darren is very welcoming, and every fix you push upstream is one less problem for the next team.
Let me know how it goes. I would love to hear what you find ❤️
