A Zero-Budget Overnight Code Review Pipeline for Solo Repos

A solo developer can now get a nightly code review for free using a batch pipeline that leverages MonkeyCode's free model access and a free server option. The script, overnight-review.sh, collects the last 24 hours of commits, sends the diff to a model via an HTTP call, and writes a review file, keeping costs at zero. The pipeline is designed to be product-agnostic, treating the model as an interchangeable endpoint to survive model swaps.

A solo founder can get a second pair of eyes on every pull request without paying for a seat. The method is to run review as a scheduled batch job instead of an interactive chat. This article builds a small, reproducible pipeline that uses MonkeyCode's free model access and a free server option to turn any Git repo into a nightly-reviewed codebase. The bill stays at zero; the limits stay visible. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Interactive AI coding sessions burn tokens on context re-sends, idle turns, and repeated explanations. A scheduled job sends one prompt per day and stores the answer. For a solo founder, that difference decides whether a free quota lasts a week or a quarter. AI coding tools made every developer a reviewer. A solo dev is also the author, the release manager, and the person who fixes the 2 a.m. incident. A nightly batch review is a cheap way to add a second reader without adding a second salary. The pipeline below reads the last 24 hours of commits, sends the diff to a model, and writes a review file. It does not replace tests. It does not claim to understand the whole codebase. It finds what a careful reader would find in a diff. MonkeyCode's free offering currently includes 10 million tokens and a free server option. The exact model behind the endpoint can change, so this pipeline treats the model as an interchangeable HTTP call. That is intentional. The script should survive a model swap without a rewrite. Set two environment variables on the server: MC ENDPOINT and MC KEY . Nothing else in the pipeline is product-specific. Save this as overnight-review.sh and make it executable: bash /usr/bin/env bash overnight-review.sh — batch code review for a solo repo set -euo pipefail REPO DIR="${1:-.}" SINCE="${2:-24 hours ago}" MAX CHARS="${MAX CHARS:-20000}" cd "$REPO DIR" 1. Find the commit that was current before the review window. BASE=$ git rev-list -n 1 --before="$SINCE" HEAD || true 2. Collect the day's commits and the diff. git log --since="$SINCE" --pretty=format:"%h %s" /tmp/review commits.txt if -n "$BASE" ; then git diff "$BASE" HEAD -- . ': exclude .lock' /tmp/review diff.txt else git show HEAD -- . ': exclude .lock' /tmp/review diff.txt fi 3. Guard the character budget. CHARS=$ wc -c < /tmp/review diff.txt if "$CHARS" -gt "$MAX CHARS" ; then echo "Diff is $CHARS chars; truncating to $MAX CHARS." head -c "$MAX CHARS" /tmp/review diff.txt /tmp/review diff trimmed.txt mv /tmp/review diff trimmed.txt /tmp/review diff.txt fi 4. Build a strict prompt. cat /tmp/review prompt.txt <<EOF You are reviewing a pull request for a solo developer. Review the diff below. Output one line per issue: SEVERITY: file:line - message Severity is BLOCKER, SHOULD-FIX, or NIT. Only report issues visible in the diff. Do not invent problems. Commits in this window: $ cat /tmp/review commits.txt Diff: $ cat /tmp/review diff.txt EOF 5. Send to the model. Endpoint and key come from the environment. This call is a template: replace it with your compatible endpoint. if -n "${MC ENDPOINT:-}" && -n "${MC KEY:-}" ; then curl -sS -X POST "$MC ENDPOINT" \ -H "Authorization: Bearer $MC KEY" \ -H "Content-Type: application/json" \ --data "$ jq -n --rawfile p /tmp/review prompt.txt '{prompt: $p}' " \ review.out echo "Review written to review.out" else echo "MC ENDPOINT and MC KEY are not set. Prompt saved to /tmp/review prompt.txt" fi Dependencies: git , curl , and jq . The script needs a clone of the repo on the server, plus read access to the branch being reviewed. The script does four things: it collects the day's commits, builds a diff from the commit before the window to HEAD , truncates the diff to a character budget, and builds a prompt that demands a strict output format. The prompt format matters. SEVERITY: file:line - message forces parseable output. The instruction "Only report issues visible in the diff" reduces hallucinated problems. A truncated diff still produces a review, but line numbers may drift; that is an accepted trade-off of the budget guard. A common heuristic is that one token equals roughly four characters of code. That is an estimate, not a model spec. The real ratio depends on the tokenizer and the language. | Changed lines | Approx. chars | Rough tokens chars / 4 | Share of a 10M budget | |---|---|---|---| | 200 | 8,000 | 2,000 | 0.02% | | 1,000 | 40,000 | 10,000 | 0.1% | | 5,000 | 200,000 | 50,000 | 0.5% | The point is simple: a daily diff of a few hundred lines consumes a negligible slice of a 10 million token budget. Even a heavy week of 5,000 changed lines stays under one percent. The quota is not the constraint for a solo repo; prompt quality is. Install the script on the free server and add a cron entry: 0 3 /home/you/bin/overnight-review.sh /path/to/repo /var/log/overnight-review.log 2 &1 Run it manually once first: bash overnight-review.sh . , then inspect review.out . If the output is empty, check the endpoint and the key; if it is noise, tighten the prompt; if the diff is missing, check the branch state on the server. The output file is raw material, not a verdict. A useful triage rule set: A healthy output looks like this: BLOCKER: src/auth.go:142 - token is compared with == instead of a constant-time compare SHOULD-FIX: src/api.go:88 - error is swallowed before the retry logic NIT: src/main.go:12 - unused import after refactor The same rule set works every morning and takes five minutes. It catches the mistakes that a tired solo dev ships at 2 a.m. The model is the reader; the founder is still the reviewer. This pipeline has hard limits. It sees only the diff, not the surrounding architecture, and it cannot run the tests. It can hallucinate line numbers when the diff is truncated, and it has no memory of yesterday's review unless the prompt carries it forward. The 10 million token figure and the free server are current as of the operator's last verification; quotas and availability can change without notice. Do not use this approach for security-sensitive code, regulated work, or anything where a wrong review has legal weight. Do not use it as an excuse to skip tests. Teams with a real review process do not need it. Solo founders who ship daily and want a zero-bill safety net are the audience. The pipeline is deliberately boring, and that is its strength. A scheduled job, a strict prompt, and a triage list cost nothing to run and compound in value. MonkeyCode is open source, and the free tier is a low-friction way to test this exact workflow; the script works with any compatible endpoint, so the switching cost stays low.