Two Free Offers, Two Failure Modes: Route AI Work by Blast Radius, Not by Lane

Two tabs open. Both say free. One is a token allowance on a hosted model endpoint; the other is a server you can run somewhere. My platform lead looked at them and asked the reasonable question: "So which one do we take?"

It took me a week to notice that the question was malformed. They are not two versions of the same offer. They fail in completely different ways, on different timelines, against different budgets. Choosing between them like flavors is how teams end up with a free model quota nobody trusts and a box nobody patches.

Here is the reframe that actually helped: stop picking a lane for the team. Route individual change sets, and let the two offers absorb the classes of work they are genuinely good at.

Why this keeps going wrong

Look at what developers were writing on DEV last week. On 2026-10-13, a post titled "AI Fatigue? Yea I know." collected 164 reactions and 101 comments. Two days later, "I Vibe-Coded My Way Out of Angular Upgrades" picked up 88 reactions and 56 comments about shipping model-authored diffs into a real codebase. Different moods, same underlying constraint.

Neither thread is about generation speed. Both are about the cost that lands after generation — reading, verifying, and owning the diff. That cost does not care which lane produced the code. It only cares how big and how dangerous the change was.

So ask yourself: if your reviewers are the bottleneck, does a faster or cheaper generator change your throughput at all?

The two offers fail differently

	Free model access	Free server option
Primary currency	Tokens / requests	CPU, memory, disk, egress
Failure mode	Review debt — output arrives faster than it can be verified	Ops debt — patching, upgrades, restarts, who is on call
Shows up as	Rising review latency, rubber-stamped approvals	Silent drift, surprise downtime, config archaeology
Detected by	Reviewer queue depth	Uptime and patch-lag tracking
Reverses when	Review latency exceeds one business day	Nobody owns the box for two consecutive weeks

Read that table again. The left column is a people constraint. The right column is an ownership constraint. A team can be perfectly staffed for one and completely unstaffed for the other, which is exactly why a single "free tier yes/no" decision keeps producing bad outcomes.

Workload fission: route the change, not the team

Borrow the idea from fault-tolerant systems. You do not ask "is this system safe?" You ask what a failure would cost, and you place controls accordingly. Do the same with AI-authored diffs.

Two axes decide the route:

1. Reversibility — can this be reverted in one commit, with no data migration, no customer notification, no third-party side effect?
2. Blast radius — if it is wrong in production, how many users, how much money, how many hours of incident response?

That gives four buckets, and only three of them should ever touch a free lane:

• Low blast, reversible — docs, tests, fixtures, log messages, internal tooling. Free model lane. One reviewer, same day.
• Low blast, hard to reverse — schema tweaks, cache key formats, anything with a write path. Paid lane or free lane with an owner sign-off.
• High blast, reversible — feature flags, config toggles behind an off switch. Paid lane, plus a kill-switch check.
• High blast, hard to reverse — auth, billing, migrations, public API contracts. Human-authored or human-rewritten. No exceptions older than 30 days.

Is that last line too rigid? Maybe. But I have never regretted it, and I have definitely regretted the alternative.

A 60-line router you can run today

Scores are a conversation tool, not objective truth. The point is to make the routing rule explicit and identical for everyone, instead of letting whoever is on triage that morning decide.

#!/usr/bin/env python3
"""route_ai_work.py - classify one change set into a review lane.

Stdlib only. No network calls. Feed it a JSON file.
"""
import json
import sys

WEIGHTS = {
    "files_changed": 1.0,
    "lines_added": 0.05,
    "lines_deleted": 0.10,      # deletion is riskier than addition
    "touch_migrations": 25.0,
    "touch_auth": 25.0,
    "touch_billing": 25.0,
    "touch_public_api": 15.0,
    "touch_ci_config": 10.0,
}

LANES = [
    (0,  30,       "free-model lane",  "one reviewer, same day"),
    (30, 60,       "paid-model lane",  "one reviewer + owner sign-off"),
    (60, float("inf"), "human-author lane", "two reviewers, no model-authored diff"),
]

def score(change):
    total = 0.0
    for key in ("files_changed", "lines_added", "lines_deleted"):
        total += change.get(key, 0) * WEIGHTS[key]
    for flag in change.get("flags", []):
        if flag not in WEIGHTS:
            raise SystemExit(f"unknown flag {flag!r}; add it to WEIGHTS first")
        total += WEIGHTS[flag]
    return round(total, 1)

def route(total):
    for low, high, lane, review in LANES:
        if low <= total < high:
            return lane, review
    return "unrouted", "escalate"

if __name__ == "__main__":
    change = json.load(open(sys.argv[1]))
    total = score(change)
    lane, review = route(total)
    print(f"{change.get('id', 'unnamed')}\tscore={total}\t{lane}\t{review}")

A fixture, so results are comparable across teams

{"id": "ENG-4412", "files_changed": 6, "lines_added": 210, "lines_deleted": 40, "flags": ["touch_migrations"]}

$ python3 route_ai_work.py fixture_paid.json
ENG-4412    score=45.5  paid-model lane one reviewer + owner sign-off

Three fixtures I keep in the repo, with expected output, so anyone can sanity-check a weights change before it ships:

• docs-only: 2 files, +30 / -5, no flags → score=4.0 → free-model lane.
• migration: above → score=45.5 → paid-model lane.
• auth-plus-api: 12 files, +600 / -150, flags touch_auth, touch_public_api → score=97.0 → human-author lane.

Calibrate the weights before you trust them. Take 20 PRs you already merged, 10 that went clean and 10 that caused a follow-up fix, and check whether the router separates them. If it does not, your weights are wrong, not your reviewers.

Where the two offers actually fit

Here is where this stops being abstract for me. The offer I have been evaluating is MonkeyCode, an open-source project whose operator describes two things: free model access with a token allowance, and a free server option.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I am deliberately not putting numbers on the allowance or the hardware in this post. Those are operator-supplied claims that I have not independently verified, and a quota you read from me is a quota you will argue about later with no source. Verify them yourself, on the date you verify them, and write the date in your own ledger.

What I will say is how the two options map onto the routing above:

• Free model access is the natural fuel for the low-blast, reversible bucket — the docs, tests, and internal-tooling work that would otherwise queue behind a human because it feels too small to schedule. It is a bad fit for the human-author bucket, and no amount of free tokens changes that.
• The free server option is a different decision entirely. It helps when you have a workload that needs to sit somewhere you control — an internal proxy, a scheduled job, an eval harness. It only helps if you can answer "who patches it?" with a name, not a shrug.

Note what is missing from that list: nothing about replacing your paid lane. Routing is about placement, not substitution.

Hard gates, an owner, and an expiry

Write these down before the first free-lane PR merges:

1. Gate: no free-lane merge without a named reviewer in the same timezone, same day.
2. Gate: if review latency for the free lane exceeds one business day for five consecutive working days, the lane is paused until the queue clears.
3. Owner: one person owns the server option, including patch lag. If the owner changes teams, the option stops — automatically, not by discussion.
4. Expiry: every routing exception expires in 30 days and must be re-justified by a re-run of the router, not by memory.
5. Exit: if two incidents in a quarter trace back to model-authored diffs in a bucket you classified as low blast, that bucket gets reclassified upward permanently.

Sensitivity: what would reverse this routing

Run these three what-ifs. Any one of them can flip the plan.

• If your median PR review latency is already above one business day, the free-model lane's advantage mostly evaporates. You are review-bound, and adding generation capacity just deepens the queue.
• If migrations, auth, and public API changes are more than 40% of your change count, most work routes to the human bucket anyway and the free lane becomes a rounding error. Check the count, not the vibe.
• If your server option has no owner after two weeks, its true cost is unbounded — and no token allowance offsets an unpatched box.

Which of those three numbers is closest to flipping for you? That is the one to measure first.

Who should not use this

• Solo developers with no review queue. Routing exists to protect reviewers. If you are the only reviewer, you already are the gate — just write the flags file and skip the ceremony.
• Teams under compliance regimes that require provenance on every diff. Do the classification, but expect the free lane to be empty.
• Anyone who wants the router to decide. It ranks work. It does not own outcomes. If a human cannot defend the routing at postmortem time, the routing was wrong.

If you want to try the offers, try them against one bucket — the low-blast reversible one — for two weeks, with the gates above written down first. That is the whole experiment. Everything else is a lane decision you do not have to make yet.