The argument started in the team channel at 9:40 on a Tuesday. One engineer pasted a link to a free AI coding server and called it good enough. Another replied that self-hosting is the only responsible choice. By lunch, nobody had mentioned the actual codebase.
That's the pattern I keep seeing. Teams treat the free-versus-self-hosted question as a matter of principle. It isn't. It's a measurement problem.
Your repo has a shape. That shape decides the answer before you ever open a pricing page.
Three dimensions that decide the answer
Token appetite. How many tokens does your average diff consume, plus the instructions, plus the back-and-forth? Context churn. How often does a fresh conversation have to re-learn your codebase? Latency tolerance. Does a slow response break your flow, or just delay a batch job?
A team shipping small, focused pull requests has a different appetite than a team doing weekly mega-refactors. The same free tier can feel unusable in an interactive session and invisible in an overnight test run. Most comparisons skip this part because it requires actual work.
A fit test you can run from your terminal
Here's the reproducible part. The script below reads your git history and estimates the token appetite of your last N commits. It calls no model and needs no API key. It uses one heuristic: roughly four characters per token, a conservative average for mixed code, prose, and symbols.
#!/usr/bin/env bash
# fitcheck.sh — estimate your repo's token appetite from git history
set -euo pipefail
N="${1:-50}"
REPO="${2:-.}"
cd "$REPO"
echo "Analyzing last $N commits in $(basename "$(pwd)")"
echo "---"
total_tokens=0
max_tokens=0
declare -A file_hits
for i in $(seq 0 $((N - 1))); do
diff_text=$(git show --format="" --unified=3 "HEAD~$i" 2>/dev/null || true)
chars=$(printf '%s' "$diff_text" | wc -c)
tokens=$((chars / 4))
total_tokens=$((total_tokens + tokens))
if (( tokens > max_tokens )); then
max_tokens=$tokens
fi
while IFS= read -r f; do
file_hits["$f"]=$(( ${file_hits["$f"]:-0} + 1 ))
done < <(git show --name-only --format="" "HEAD~$i" 2>/dev/null || true)
done
avg_tokens=$((total_tokens / N))
echo "Average diff tokens per commit: $avg_tokens"
echo "Largest diff tokens: $max_tokens"
repeated=0
for hits in "${file_hits[@]}"; do
if (( hits > 1 )); then
repeated=$((repeated + 1))
fi
done
echo "Files touched more than once: $repeated"
echo "Projected monthly burn (20 commits/day): $((avg_tokens * 20 * 22)) tokens"
Run it like this:
chmod +x fitcheck.sh
./fitcheck.sh 50 /path/to/your/repo
The output is an estimate, not a bill. Tokenizers vary by model, and real prompts add overhead this script deliberately ignores. But the relative shape is what matters. A repo projecting 2 million tokens a month and a repo projecting 200 million are not in the same conversation.
The 4-characters-per-token rule is deliberately conservative. Code is denser than prose, and a unified diff carries context lines that a real assistant would also see. If anything, the script undercounts what a full prompt with instructions and file excerpts would cost. That bias is fine for a fit test. You want the order of magnitude, not the invoice.
Reading the numbers
If your average diff stays under roughly 2,000 tokens and your monthly projection fits inside the free allocation, the free tier is structurally sufficient. The only remaining question is latency, and that needs a live test. If your projection blows past the allocation by an order of magnitude, no amount of enthusiasm fixes the math. You need self-hosting, a paid tier, or a serious change in how you chunk work. And if the same files keep reappearing in commit after commit, you're a candidate for context reuse — but only if the server you pick actually supports it. That's a feature question, not a pricing question.
| Fit signal | Verdict | Action |
|---|---|---|
| Projection under 60% of free allocation | Good fit | Run a 30-minute live latency test |
| Projection between 60% and 100% | Borderline | Watch real usage for two weeks |
| Projection over 100% | Bad fit | Self-host, pay, or split work into smaller units |
| Same files touched repeatedly | Context reuse candidate | Verify the server caches context before relying on it |
| Strict data residency or audit needs | Bad fit regardless of math | Self-host or use a compliant paid option |
The case that keeps coming up
MonkeyCode keeps showing up in my feeds, so I ran the framework on it. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The project is open source, and it offers two things that matter here: free model access with a 10-million-token allocation, and a free server option so you can try it without standing up your own inference host. I'm not going to recite the marketing numbers back at you. Run the script instead.
Take a worked example. A mid-sized service repo with 7,000-token average diffs and 20 commits a day projects to roughly 3.1 million tokens per month. That fits inside a 10-million allocation with room to spare. The verdict is a trial, not a migration. A monorepo with heavy generated code, averaging 90,000 tokens per diff, projects past 40 million. The free tier runs out before the work does. That's not a product failure. It's a fit failure, and the script catches it in under a minute.
Who should not use the free option
Teams with data-residency requirements, because your code crosses a network boundary. Anyone generating code for regulated systems where provenance and audit trails matter. And repos so large that the context window alone would consume the allocation before the first useful answer. Also, if you're wiring an AI server into a CI pipeline, a free server without an SLA is a risk you're pricing, not a cost you're avoiding.
The free-versus-self-hosted debate is usually a proxy for something else. Nobody wants to be the person who picked the wrong tool. The fix is to stop picking and start measuring. Your git history has been keeping score for years. Read it.
Clone the project, run fitcheck.sh against your own repo, and let the numbers pick your side.
Top comments (0)