A Zero-Budget Overnight Code Review Pipeline for Solo Repos

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:

#!/usr/bin/env bash
set -euo pipefail

REPO_DIR="${1:-.}"
SINCE="${2:-24 hours ago}"
MAX_CHARS="${MAX_CHARS:-20000}"

cd "$REPO_DIR"

BASE=$(git rev-list -n 1 --before="$SINCE" HEAD || true)

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

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

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

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.

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.