Last Thursday a platform lead asked me a question I get about once a month: "We're running on free AI capacity. When do we have to decide whether to stay?"
I asked him one thing back. What does leaving cost you, in engineer-hours? Silence for a few seconds. Then: "We'd have to rewrite the CI wrapper and port the prompt library. Maybe two weeks?"
That's the number that decides. Not the token count. Not the seats. The exit.
Free capacity gets priced at zero, so most teams quietly treat it as infinite. It isn't. It's a loan, and the balloon payment is called migration — the work you do the day the terms change, the allowance runs out, or your security review catches up with you.
Quick context on why this is showing up now: DEV's front page over the past week carried a lot of AI fatigue discussion (a "AI Fatigue? Yea I know." post picked up 106 reactions on Oct 13) and a piece arguing AI tools improved while the software around them didn't (96 reactions, Oct 9). Community signal is not evidence, but it's a decent hint that teams are consolidating lanes instead of adding them. Consolidation decisions need a number.
Here's the number, and here's how to compute it yourself.
Step 0: Name the three columns
This sheet only makes sense if you're comparing real alternatives. I use three:
- Free hosted lane. Concretely, for this walkthrough: MonkeyCode's free model access plus its free server option. The operator describes both as available at no cost, with a stated free allowance of 10 million tokens. Verify current terms on the project page before you build a budget on them — that is true of every free tier, including this one.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Paid hosted lane. Any per-seat or per-token plan with a contract, an SLA, and a billing line you can point at during a renewal conversation.
Self-host. You run it. This only exists as a column if the project is open source and the repository's current docs actually support the deployment you need — MonkeyCode is an open-source project, so check its repo before assuming this path is available to you.
The mistake I see most often is comparing column 1 against column 2 by sticker price and comparing column 1 against column 3 by nothing at all.
Step 1: Measure your own burn, not someone else's
A stated allowance is meaningless until it's divided by your consumption. So measure it. Ten merged PRs is enough to get a usable median.
- Pick 10 merged PRs from the last month that used the lane.
- Log the usage number your client reports for each one, plus whether the PR needed a rewrite after review.
- Take the median of the clean ones. Keep the messy ones as a separate "rework" bucket.
Do not use a vendor's tokens-per-task figure. It's measured on someone else's code, at someone else's review standard. If you can't measure 10 PRs, you can't run this sheet yet — that's a real answer.
Step 2: Convert the allowance into runway months
# exit_ledger.py — free-lane runway and exit break-even
# Inputs below are ILLUSTRATIVE. Replace with your measured values.
from dataclasses import dataclass, replace
@dataclass
class Inputs:
free_tokens: float # operator-stated allowance; re-verify before budgeting
tokens_per_pr: float # YOUR measured median, tokens per merged PR
prs_per_month: float # YOUR merged PRs per month on this lane
saved_hours_month: float # engineer-hours saved per month vs next-best option
hourly_cost: float # fully loaded $ per engineer-hour
exit_hours: float # one-time hours to leave or migrate the lane
residual_hours: float # monthly overhead the free lane adds (rework, governance)
def runway_months(i: Inputs) -> float:
burn = i.tokens_per_pr * i.prs_per_month
return i.free_tokens / burn if burn else float("inf")
def net_savings_month(i: Inputs) -> float:
return (i.saved_hours_month - i.residual_hours) * i.hourly_cost
def break_even_month(i: Inputs) -> float:
net = net_savings_month(i)
if net <= 0:
return float("inf") # the free lane costs more than it saves
return (i.exit_hours * i.hourly_cost) / net
def reversal_exit_hours(i: Inputs) -> float:
"""Exit hours at which savings never amortize inside the runway."""
return (net_savings_month(i) * runway_months(i)) / i.hourly_cost
def sensitivity(i: Inputs, exits=(20, 40, 80, 160), savings=(8, 16, 24)):
for h in savings:
row = []
for e in exits:
j = replace(i, exit_hours=e, saved_hours_month=h)
row.append(f"{break_even_month(j):.1f}")
print(h, row)
Filled with illustrative numbers — my example, not a benchmark:
| Variable | Value |
|---|---|
free_tokens |
10,000,000 (stated allowance, 2026-10-15) |
tokens_per_pr |
45,000 (illustrative median) |
prs_per_month |
40 |
saved_hours_month |
24 |
hourly_cost |
$85 |
exit_hours |
60 |
residual_hours |
10 |
Run it and you get: burn 1.8M tokens/month, runway ≈ 5.6 months, net savings ≈ $1,190/month, break-even ≈ 4.3 months, and a reversal threshold of ≈ 78 exit hours.
Read that last one out loud, because it's the whole point. If porting the CI wrapper and the prompt library takes more than roughly 78 engineer-hours, the free lane's savings never pay back inside its own runway. You would have saved money by starting on the paid column.
Step 3: Sensitize, then set a hard gate
Single-point answers are how teams get burned. Run the grid.
| break-even month ↓ / exit hours → | 20 | 40 | 80 | 160 |
|---|---|---|---|---|
| net $850/mo | 2.0 | 4.0 | 8.0 | 16.0 |
| net $1,190/mo | 1.4 | 2.9 | 5.7 | 11.4 |
| net $2,040/mo | 0.8 | 1.7 | 3.3 | 6.7 |
And sensitize the runway, because burn is the variable you control least:
| PRs/month | Burn | Runway on 10M |
|---|---|---|
| 20 | 0.9M | 11.1 months |
| 40 | 1.8M | 5.6 months |
| 80 | 3.6M | 2.8 months |
Now the gate. I use break-even ≤ 60% of runway, because free terms move and my measurements are median-based, not precise. At 5.6 months of runway that's a 3.4-month ceiling, which at $1,190/month of net savings caps your exit at about 48 engineer-hours.
Write that cap on the ticket before the pilot ends. Gates that aren't written down before you're attached to the outcome are not gates.
Who owns it, when it expires, when you leave
A ledger without an owner is a spreadsheet. So attach three fields:
- Owner: one named person, not a team. This is usually the EM or platform lead who can actually stop the PRs.
- Expiry: a date, not "when the allowance runs out." I default to the runway month minus one, so you decide with a month of margin.
- Exit criteria: the measured condition that sends you to column 2, written as a number. Example: "if measured burn exceeds 2.5M tokens/month for two consecutive months, move to the paid lane and re-run the sheet."
On the expiry date, do one of three things: renew the free lane with fresh terms, move to paid, or migrate to self-host. Doing nothing is also a choice, and it's the expensive one.
Who should not use this sheet
Be honest about the fit criteria, including the ones that disqualify you:
- You have no single owner. Without one person able to kill the lane, the exit cost grows silently.
- Your data path isn't cleared. Cost math does not override a security review. Resolve the review first.
- You expect less than about two months of use. Then the free lane is the right answer and the ledger is overkill — just use it and don't build tooling around it.
- You can't measure tokens per PR yet. Measurement is step 1 for a reason.
And a fairness caveat in the other direction: for a solo developer or a two-person side project, exit cost is near zero and none of this matters. Free is free. This sheet is for teams where migration is a project, not an afternoon.
The question that reverses you
My example lands on "commit, with a 48-hour exit cap." Yours will land somewhere else, and that's fine. A sheet like this is a conversation tool, not objective truth — it makes the disagreement legible, it doesn't settle it.
So here's what I'd actually want to know from you: which single input flips your answer? The exit hours, the burn per merged PR, or the residual overhead? If it's the burn, you can only find out by measuring, and a free lane is the cheapest place to get that measurement.
That's the honest role MonkeyCode plays in this method: it's the column you use to collect a real month of tokens_per_pr before you sign anything. Its free model access and free server option are what make the measurement phase cheap; the ledger does the deciding.
Top comments (0)