Three environments, one patch, three different answers.
You have seen this shape before: the change is green on the author's laptop, red in CI, and "works on the free box" for whoever happened to configure it six weeks ago. Nobody wrote down where AI-assisted work is supposed to run, so it runs everywhere and is trusted nowhere.
Here is the constraint that should end the argument early: if reproducing your evidence takes longer than reviewing the diff, you are not reviewing code — you are reviewing memory.
So stop arguing about which model wrote the patch. Argue about placement, because placement is what produces the evidence a reviewer will actually trust.
The three numbers that decide placement
I use three measurements per workload. All three are cheap to collect and none of them require a benchmark suite.
| Variable | Definition | Unit | How you get it |
|---|---|---|---|
| TTG | Time-to-green: wall-clock minutes for a reviewer, from a clean checkout, to a passing check | minutes (median) | Run the script below 3–5 times |
| SD | Secret-distance: count of distinct credentials or permissions the check needs from the host | integer, min 0 | Grep the check's env references, then read the list |
| RR | Rerun-rate: share of AI-assisted changes whose check a reviewer actually re-runs | 0.0–1.0 | Sample 20 merged changes and count |
Two notes before the math. TTG is a speed number, not a correctness number — a fast wrong check is worse than a slow right one. And RR is a proxy, not proof; it measures reviewer behavior, and reviewer behavior drifts.
Measuring TTG with a script, not a wiki page
The DEV front page spent last week arguing that coding agents need scripts rather than markdown files (dev.to/dannwaneri, 2026-11-05). Same logic applies to your placement policy: if the policy is prose, it will rot. If it is a command, it will get re-run.
#!/usr/bin/env bash
# ttg.sh — median time-to-green from a clean checkout.
# Usage: TTG_RUNS=3 ./ttg.sh <git-url> <ref> "<check-command>"
set -euo pipefail
REPO="${1:?repo url}"
REF="${2:?branch or sha}"
CHECK="${3:?e.g. 'npm ci --no-audit && npm test'}"
RUNS="${TTG_RUNS:-3}"
IMAGE="${TTG_IMAGE:-node:22-bookworm}"
for i in $(seq 1 "$RUNS"); do
start=$(date +%s)
if docker run --rm "$IMAGE" bash -lc "
set -euo pipefail
git clone --quiet --depth 1 --branch '$REF' '$REPO' /w
cd /w
$CHECK
" >/dev/null 2>&1; then ok=1; else ok=0; fi
end=$(date +%s)
echo "run=$i ok=$ok seconds=$((end-start))"
done
Then summarize, keeping only runs that actually went green:
TTG_RUNS=5 ./ttg.sh git@github.com:acme/api.git main 'npm ci --no-audit && npm test' \
| awk -F'seconds=' '/ok=1/{print $2}' | sort -n \
| awk '{a[NR]=$1} END{print "median="a[int((NR+1)/2)]" green_runs="NR}'
Two deliberate choices. No cache volume is mounted, because a warm box is not a clean box — if you measure warm, label it warm. And the script fails loudly: if 2 of 3 runs are red, TTG is undefined, and that undefined value is the most useful finding you will get all week.
Estimating SD without lying to yourself
SD is not how many secrets exist. It is how many the check needs from whatever host runs it.
grep -rEoh '\$\{?[A-Z][A-Z0-9_]{2,}' \
--include='*.sh' --include='*.yml' --include='*.yaml' --include='*.toml' . \
| tr -d '${}' | sort -u
That output is a lower bound, not a truth. Take the list, cross out the harmless ones (CI, NODE_ENV, LOG_LEVEL), and count what remains. A read-only throwaway test database counts as 1. A sandbox write key counts as 1. A production token counts as 1 — and also as a hard stop, which we will get to.
A filled example, with the arithmetic shown
The inputs below are illustrative, chosen to demonstrate the method. They are not measurements from a real team, and you should not quote them as benchmarks.
| Workload | TTG (min) | SD | RR | Placement |
|---|---|---|---|---|
Docs-site copy fix, check = make build
|
3 | 0 | 0.20 | Laptop |
| API service, check = unit + integration | 9 | 1 (throwaway test DB) | 0.70 | CI, or a free hosted box |
| Billing migration, check needs sandbox write key | 14 | 3 | 0.95 | CI only, inside your own perimeter |
Read the third column before the first. The docs fix has a tiny TTG but almost nobody re-runs it, so a faster lane buys you nothing. The billing migration has an RR near 1.0, which means TTG is paid on almost every change — that is where placement money lives.
Break-even: how many minutes must a paid lane save?
Define four variables and label your own numbers:
-
H= loaded engineer cost per hour, all-in -
N= AI-assisted changes per week that trigger a reviewer rerun -
S= reviewer minutes saved per change by the faster lane -
P= price of the paid lane per month, per seat or per workspace
monthly_value = N × 4.33 × (S / 60) × H
breakeven_S = P / (N × 4.33 / 60 × H)
With H = 90, N = 25, S = 6:
monthly_value = 25 × 4.33 × 0.1 × 90 = $974
Now the sensitivity pass, which is the whole point:
| Scenario | Monthly value |
|---|---|
| S = 6 min | $974 |
| S = 3 min | $487 |
| S = 1 min | $162 |
| S = 6 min, but the paid lane adds 2 min of queueing per change (net S = 4) | $650 |
| S = 6 min, but you can't attribute the minutes (treat S = 0) | $0 |
And the number that should rearrange your priors — break-even for a $40/seat tool at those inputs:
breakeven_S = 40 / (25 × 4.33 / 60 × 90) ≈ 0.25 minutes ≈ 15 seconds
Fifteen seconds. At a 25-changes-a-week cadence, almost any paid lane pays for itself on paper. Which tells you the pricing question is not your real question. Your real question is whether you can measure S at all. If you cannot, the model returns zero and every proposal is vibes.
Four hard gates that override the arithmetic
Scores lose to gates. Run these first, in order.
- G1 — Data class. If the check needs a write-scoped production credential, or touches production data, no third-party free box runs it. Not scored, not weighted. Refused.
- G2 — Reproducibility. If a reviewer cannot get green from a clean checkout in one documented command, no lane gets chosen. Fix the check first; TTG is meaningless without a green.
-
G3 — Attribution. If you cannot point at the specific minutes saved, set
S = 0. Guessed minutes inflate every break-even table you will ever build. -
G4 — Cost ceiling. If free-lane TTG exceeds 15 minutes, re-run the arithmetic against CI at your
Hbefore assuming free is cheaper. Fifteen is a proposal, not a law — move it to your own numbers.
Where a free lane actually fits
This is where the free tier earns its place, and where I would start measuring rather than stop deciding.
MonkeyCode offers free model access and a free server option — the operator states 10 million free tokens as of this writing on 2026-11-09, and the project is open source. Verify the current terms yourself before you plan around them; free offers are the most churn-prone line item in any cost model I have seen.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Against the gate above, the fit is narrow and specific:
- Good fit: SD = 0 workloads — builds, linters, docs, unit tests with a throwaway database. TTG here is often the 3–10 minute band, which is exactly where a reviewer skips the rerun and starts trusting the author.
- Good fit: getting your first TTG data point. One number today beats a procurement deck next quarter, and cheap tokens make 5-run medians affordable.
-
Bad fit: anything with
SD ≥ 1. A sandbox write key on someone else's free box is a decision you will explain to your security team later. See G1. - Unproven for you: self-hosting. Open source makes the code inspectable; it does not by itself promise a self-host path, hardware profile, or support. Confirm that before you write "self-host" into a plan.
Self-host versus paid: fill in your own units
When the free lane is ruled out by G1, you have two comparators. I refuse to invent prices for either, so here is the shape with your units to fill in.
| Line item | Self-host in your VPC | Paid managed |
|---|---|---|
| Compute | VM/GPU rate × hours | included or metered |
| Operational time | your H × patching + upgrades + on-call hours/mo |
usually bundled, verify |
| Data handling | your controls, your audit burden | needs a DPA you can actually read |
| Switching cost | low if you containerize, high if you don't | vendor-shaped |
| Failure mode | you own the pager | they own the pager, you own the SLA gap |
Self-host wins when SD is high and your controls are already strong. Paid wins when your operational hours are the scarce resource. The free lane wins when SD is zero and you need a number this afternoon.
Owner, expiry, and exit criteria
A placement decision without an expiry date is just a rumour with a diagram.
- Owner: the platform lead owns TTG and RR measurement. The tech lead owns SD classification. One name each, in the doc, not a team name.
- Expiry: re-measure monthly. Free offerings, prices, and model behavior all move; a Q1 decision quoted in Q4 is a fabrication.
- Exit: two consecutive months where free-lane TTG exceeds your ceiling, or any workload where SD rises above 0, moves that workload out. No debate round required.
- Archive rule: when a lane is retired, keep its last TTG card and the date. The number is the argument next time.
Limitations, stated plainly
TTG measures speed, not correctness, and it is noisy at n=3. RR measures reviewer habit, which can be gamed by making reruns annoying. The break-even model assumes the saved minutes are real and additive, and they often are not — context switching eats them. The thresholds 15 minutes and SD ≥ 1 are proposals from one reviewer's experience, not findings from a controlled study.
Treat the whole thing as a conversation tool, not objective truth. Its job is to move an argument from "the free box feels slow" to "the free box medians at 19 minutes on this workload, here are the five runs, here is the owner, here is the review date."
Who should not do this
Solo developers with one repository and no CI: skip it. The gate costs more than the ambiguity it removes — use your laptop, keep one script, move on.
Teams in regulated data: start at G1 and stay there until you have a written answer. The arithmetic is not your bottleneck.
Teams whose checks are already red on main: fix that first. A placement policy on top of an unreproducible build is decoration.
So: which number would actually move you? TTG crossing your ceiling, or SD crossing zero? Write that threshold down before you evaluate any lane, free or paid — otherwise you will keep shopping for tools when the real problem is that nobody measured the last one.
If you want the first data point cheaply, run ttg.sh against a free box instead of your laptop. It costs an afternoon and it turns a preference into a number.
Top comments (0)