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

A developer has detailed a risk-based routing workflow for AI coding tasks, arguing that the key question is not which model is best but which tasks require the strongest model. The approach assigns tasks to free-tier models based on blast radius, with objective gates and a JSON log to measure routing decisions. The workflow is provider-agnostic and was prepared as part of MonkeyCode's product outreach, which offers free model access and a free server option.

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. When every prompt goes to the most expensive model by default, two things happen: The fix isn't a blog-post benchmark. It's a per-task routing rule plus a log you can audit weekly. 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: Routing only works if each tier has an objective accept/reject gate. Mine is: bash /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. 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: This is deliberately the same philosophy as my earlier evaluation-suite post: small, runnable, and honest about failure counts instead of average-case impressions. 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. "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.