Run the Cheap Review First

Most code review errors are boring. They are typos, wrong variable names, missing null checks, and copy-paste mistakes. A free model catches these reliably. A paid model catches them slightly faster. The difference rarely matters. The expensive model earns its money later, on the second pass, when the review turns architectural. Most teams run these two passes in the wrong order. They send every diff to the most powerful model they can afford. Then they run out of budget and patience before the interesting questions get asked.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free models and free server make the two-queue design practical for a solo developer or a small team. The free tier is not a compromise here. It is the correct tool for the first pass.

The two-queue rule is simple. Every incoming diff gets classified into one of two queues. The fast queue handles mechanical errors. The slow queue handles design problems. The fast queue runs on free models. The slow queue runs on the best model you can justify. The classification is the hard part, and it is a script, not a feeling.

Think of a hospital triage desk. A paper cut does not go to surgery. A chest pain does not wait in the minor injuries line. Code review needs the same discipline. Most diffs are paper cuts. A few are chest pains. Routing them correctly is worth more than upgrading the model.

Here is a routing script that reads a diff and assigns a risk score. Save it as queue-diff.py.

#!/usr/bin/env python3
"""queue-diff.py — route a diff to the fast or slow review queue."""
import re
import sys

def risk_score(diff_text: str) -> int:
    score = 0
    added = re.findall(r"^\+[^+]", diff_text, re.MULTILINE)
    score += len(added) // 50
    if re.search(r"TODO|FIXME|HACK", diff_text):
        score += 2
    if re.search(r"except:|except\s", diff_text):
        score += 1
    if re.search(r"password|token|secret|api[_-]?key", diff_text, re.IGNORECASE):
        score += 5
    return score

def main() -> None:
    diff = sys.stdin.read()
    score = risk_score(diff)
    print("SLOW_QUEUE" if score >= 5 else "FAST_QUEUE")

if __name__ == "__main__":
    main()

Run it in a review pipeline like this:

git diff origin/main...HEAD | python3 queue-diff.py

The script is deliberately naive. It does not understand semantics. It understands signals. A diff touching a secrets file goes to the slow queue. A config change with two lines goes to the fast queue. A fifty-line refactor goes to the slow queue. The threshold is a starting point, not a law.

The fast queue review prompt is short. Ask the free model to check three things. Are names consistent? Are there null or undefined risks? Are there obvious copy-paste errors? That is the entire brief. No architecture questions. No style debates. The output is a list of concrete findings or a single word: clean.

The slow queue review prompt is different. It asks about coupling, error propagation, and whether the change matches the surrounding design. This is where a stronger model changes the outcome. This is where the paid tier earns its cost. Running this prompt on every tiny diff is how teams burn their budget on noise.

The two-queue design changes the economics of review. A team of five reviewing ten pull requests a day can route most diffs to the fast queue. The free models handle the mechanical pass. The slow queue sees only the diffs that matter. The result is a review process that scales with attention, not with token spend.

MonkeyCode fits this workflow because both queues are available in one client. The free models cover the fast queue without a subscription. The free server removes the local hardware requirement, which matters on a company laptop. The setup is a config change, not a migration. The project is open source, so the limits are visible in the repository. Check the current numbers there before planning around them.

The decision table for queue assignment looks like this:

Diff characteristic	Queue	Why
Config, docs, styles	Fast	Mechanical changes, low blast radius
One function, clear scope	Fast	Free models handle local errors
Cross-module refactor	Slow	Design questions dominate
Auth, secrets, payments	Slow	Failure cost is high
Generated code	Fast	Nobody should review it deeply

The approach has limits. Free models still hallucinate on ambiguous code. The fast queue can miss subtle concurrency bugs. A free server adds network latency and sends code off-device. Teams under compliance rules should skip the server and run a local model instead. Solo developers on air-gapped machines cannot use this workflow at all. The two-queue rule is a budget strategy, not a quality guarantee.

Some teams should not use this approach at all. Teams reviewing security-critical code. Organizations with strict data residency policies. Projects where every line is a liability. These teams need the slow queue for everything. The free tier does not help them, and pretending otherwise is how review pipelines rot.

The core lesson stands. Run the cheap review first. Reserve the expensive review for the diffs that deserve it. The free models are not a downgrade. They are the first pass of a two-stage process, and they are the stage that runs most often.

If you want to try the two-queue setup, clone the open source repository and check the current free model list and server status. The script in this article is yours to keep. It works with any client that reads a diff from stdin. The review budget is the real constraint, and this workflow spends it where it counts.