Your Repo's Token Burn Rate Settles the Hosting Argument

Last month a four-person team spent a weekend fighting NVIDIA driver versions. They were self-hosting a coding model because, in their words, free tiers are for toy projects. When they finally wired up usage logging, the number was 1.8 million tokens per month. The managed free tier they had dismissed would have absorbed that workload with margin to spare.

I have also watched the reverse failure. A solo developer built a week of momentum on a free allowance, hit the ceiling on a Friday night, and lost the entire weekend waiting for the quota to reset. Same mistake, mirrored: the hosting decision was made on ideology instead of arithmetic.

The current AI coding discourse keeps offering two poles. One says free tiers are a trap designed to lock you in. The other says self-hosting is the only serious option. Both are wrong in the same way. They skip the only number that matters: your actual token burn rate.

Every AI-assisted workflow has a burn rate. It is a function of how often you invoke the model, how large your context windows are, and how much code you actually change. That rate is measurable before you commit to any hosting decision. Once you measure it, most of the hosting argument evaporates.

Here is a five-minute way to estimate the floor of your burn rate from git history. It counts the tokens in your diffs over the last few months:

#!/usr/bin/env python3
"""Estimate a lower bound for your repo's monthly token burn."""
import subprocess
import sys
from datetime import datetime, timedelta

CHARS_PER_TOKEN = 4  # conservative heuristic for source code

def diff_text(repo: str, since: str) -> str:
    return subprocess.run(
        ["git", "-C", repo, "log", f"--since={since}", "-p", "--no-color"],
        capture_output=True, text=True, check=True,
    ).stdout

def estimate_tokens(text: str) -> int:
    return max(1, len(text) // CHARS_PER_TOKEN)

def main() -> None:
    repo = sys.argv[1] if len(sys.argv) > 1 else "."
    months = int(sys.argv[2]) if len(sys.argv) > 2 else 3
    since = (datetime.now() - timedelta(days=30 * months)).isoformat()
    total = estimate_tokens(diff_text(repo, since))
    monthly = total // months
    if monthly == 0:
        print("Not enough diff activity to estimate. Use a longer window.")
        return
    print(f"Diff tokens over {months} months: {total:,}")
    print(f"Lower-bound monthly burn: {monthly:,}")
    print(f"A 10M-token monthly allowance covers ~{10_000_000 // monthly} months of this diff volume")

if __name__ == "__main__":
    main()

Run it with python3 burn_rate.py /path/to/repo 3. The output is a floor, not a ceiling. Real API usage runs three to ten times higher than raw diff size, because every request carries the prompt, the relevant file contents, and the conversation context. Calibrate the multiplier against your own usage logs once, and you have a number you can plan around.

That number feeds a simple decision table:

Fit criterion	Free managed tier	Self-hosted / paid
Monthly burn	Under roughly a third of the allowance	Sustained volume near or above the cap
Latency	Network round-trip is acceptable	Sub-second response or offline required
Data boundary	No regulated or PII data in prompts	Code must not leave the network
Ops capacity	No GPU budget or dedicated maintainer	Team already runs GPU infrastructure

The free managed tier fits when your monthly burn stays under roughly a third of the allowance, your latency requirements tolerate network round-trips, your codebase has no regulated data, and nobody on the team wants to own GPU operations. Self-hosting fits when any of those conditions flips: sustained volume, sub-second response needs, compliance boundaries, or an existing infrastructure team that already runs this kind of workload.

Walk three typical profiles through that table. A solo developer changing a few thousand lines a month lands at one to three million tokens, has zero ops appetite, and no compliance layer. The free managed tier is not a compromise for that person; it is the rational optimum. A five-person startup shipping daily lands at ten to twenty million tokens with a steep growth curve. The free tier works as an onboarding ramp, but the migration path to a paid or self-hosted setup should be planned before the allowance becomes the critical path. A company handling customer data under a compliance regime cannot use a managed free tier at any price, because the data boundary is the product. They should self-host and budget for a maintainer, because a GPU that nobody owns is a liability, not an asset.

To make this concrete, take MonkeyCode as a test case. It is an open-source coding assistant that ships both a free managed server and a self-hostable version, which makes it a clean instance of the tradeoff above. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free managed tier includes a token allowance — the operator's documentation cites 10 million tokens — plus a hosted server, so the framework applies directly. If your measured burn is under eight million tokens a month with room for spikes, the free server covers you. If you are above that, or your data cannot leave your network, the self-host path exists for the same engine. Same arithmetic, same conclusion.

The limitation of this approach is that it only measures volume. It does not measure value. A million tokens spent on a well-scoped refactor can be worth more than ten million spent on churn. It also does not measure failure cost: the free tier that fits today can become a bottleneck the day your team doubles, and the self-hosted box that fits today can become a time sink the day its driver breaks. Re-run the measurement quarterly, and treat the hosting decision as a living number instead of a settled identity.

Who should not use this framework? Teams with regulated data should skip the free managed tier entirely and go straight to self-hosting. Teams already burning more than the allowance should not treat the free tier as a permanent home. And anyone who thinks "free" means "no governance" should read the logs before they read the marketing — every generated line still needs review, and the review cost is the same on both sides of the table.

Run the script on your own repo this week. The number it prints will tell you which side of the table you are actually on, and it will end the hosting argument faster than any comment section can.

MonkeyCode provides free models that can run this workflow.