Route AI Coding Tasks by Risk: A Free-Tier-First Workflow You Can Actually Measure

Most discussions about AI coding tools start with "which model is best?" I've found that's the wrong first question. The better question is: which of my tasks actually need the strongest model, and which ones don't? In my earlier posts I wrote about building a small evaluation suite for AI coding models and a falsification loop for reviewing AI-generated refactors. This post is the missing piece between them: a routing layer that decides, per task, whether a free-tier model is good enough - and a way to measure whether that decision was right, instead of trusting vibes. The problem: paying frontier prices for boilerplate work When every prompt goes to the most expensive model by default, two things happen: - You burn budget on tasks a weaker model handles fine (renaming, boilerplate, docstrings, simple test generation). - You never build intuition for where the strong model genuinely matters, because you never see the failure distribution of the cheap one. The fix isn't a blog-post benchmark. It's a per-task routing rule plus a log you can audit weekly. Step 1: Classify tasks by blast radius, not difficulty Difficulty is subjective. Blast radius - what breaks if the output is wrong and you don't catch it - is not. I use three tiers: | Tier | Task examples | Failure cost | Default route | |---|---|---|---| | Low | Rename/refactor with compiler backing, boilerplate, doc comments, unit test scaffolding, commit message drafts | Caught by compiler/CI in seconds | Free/cheap model | | Medium | New function in an existing module, bug fix with a clear reproducer, small migration script | Caught by code review or tests, costs an hour | Free model first, escalate on failure | | High | Concurrency changes, auth/payment logic, schema migrations on live data, security-sensitive parsing | May reach production silently | Strongest available model + mandatory human review | Two rules make this table work: - Escalation is cheap, so bias toward the free tier. If the free model's output fails your checks, you escalate that one task. You lose minutes, not money. - Tier High is non-negotiable. Anything whose failure mode is "silent wrongness in production" never starts on the free tier, no matter how confident you feel. Step 2: A gate that every AI output must pass Routing only works if each tier has an objective accept/reject gate. Mine is: #!/usr/bin/env bash # gate.sh - run after applying any AI-generated change. # Exit 0 = accept, non-zero = escalate to a stronger model or do it by hand. set -e echo "== typecheck ==" npx tsc --noEmit # swap for: mypy, go build, cargo check... echo "== existing tests ==" npm test -- --silent # must pass with zero new failures echo "== diff sanity ==" # Reject diffs that touch files outside the task's declared scope. # I pass the allowed path prefix as $1, e.g. ./gate.sh src/billing/ git diff --name-only | grep -v "^$1" && { echo "FAIL: change escaped declared scope"; exit 1; } || true echo "PASS" The scope check matters more than it looks. In my experience the most common free-tier failure isn't wrong logic - it's the model "helpfully" editing files you didn't ask about. A one-line git diff filter catches that class entirely. Step 3: Log every routed task, review weekly This is the part that turns routing from a superstition into a measurement. One line of JSON per task: {"date":"2026-08-11","tier":"low","route":"free","gate":"pass","escalated":false,"minutes":6} {"date":"2026-08-11","tier":"medium","route":"free","gate":"fail","escalated":true,"minutes":19} {"date":"2026-08-11","tier":"high","route":"strong","gate":"pass","escalated":false,"minutes":31} After two weeks, answer three questions from the log: - What percentage of free-routed tasks passed the gate on the first attempt? (My threshold: if it drops below ~60% for a tier, that tier's routing rule is wrong.) - When tasks escalated, did the strong model actually fix it, or was the task misclassified as Medium when it was really High? - Are High-tier tasks sneaking into the free route? (Any "yes" here is a process bug, fix the table, not the model.) This is deliberately the same philosophy as my earlier evaluation-suite post: small, runnable, and honest about failure counts instead of average-case impressions. Where the free tier comes from Routing toward a free tier only helps if you actually have one. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode currently offers free model access and a free server option, which is what makes a free-first routing rule practical to run as an individual - the "free route" in the table above is a real default rather than a hypothetical one, and the free server means the logging/gate scripts can run somewhere other than your laptop. I won't quote specific model names, quotas, or performance numbers here, because those change and you should verify them yourself against the current offering; the workflow in this post is deliberately provider-agnostic, and the gate + log will tell you within two weeks whether the free tier is pulling its weight for your codebase. Limitations, and who shouldn't do this - Tiny codebases and solo weekend projects: if you write ten AI-assisted tasks a week, the log overhead exceeds the savings. Just use whatever model and move on. - Domains where correctness is unverifiable by tests (e.g., ML feature engineering without ground truth, UX copy): the gate script can't catch silent wrongness, so routing by gate results gives false confidence. - Regulated or security-critical code: the High tier in my table should probably be "no AI generation at all, AI-assisted review only." A routing table is not a compliance story. - The classification itself is a judgment call. Expect to misclassify for the first two weeks; the weekly log review exists precisely to correct that. The takeaway "Which model is best" is a benchmark question. "Which model is sufficient for this task, and how would I know if it wasn't" is an engineering question. A blast-radius table, an objective gate, and a one-line-per-task log will answer it for your own workflow in about two weeks - and whatever free tier you route to, you'll know exactly how much it's earning its place. If you try this, I'd genuinely like to hear what your pass-rate numbers look like; that's the dataset nobody publishes. Top comments (1) Blast radius is the right axis. The thing I would add is a shadow-routing period, where the cheap model gives an answer but the strong model still decides. You get failure data before the router is allowed to save money.