Who Gets the Free AI Lane First? Use This Four-Gate Assignment Sheet

A team has one free AI lane and fourteen candidate workloads. The intuitive allocation is by seniority or by who asked loudest. That rule usually hands the lane to the noisiest team rather than the safest workload, and the first bad night ends the experiment for everyone.

The alternative below is an assignment sheet, not a procurement doc. It ranks workloads by two measurable axes — burst ratio and blast radius — then applies four hard gates before anyone gets access. Everything here is a decision aid; it is a conversation tool, not objective truth.

Scenario note: the numbers in the tables are illustrative placeholders, not measurements from a real team or product.

Why seniority and request volume both fail

• Volume hides shape. A workload with 40 requests a day that triples on release days stresses a lane more than a steady 120-a-day workload. Daily totals hide this; a percentile ratio does not.
• Seniority hides reversibility. The team with the strongest case for access may also own the workload with the longest revert path. Those are separate questions and should be scored separately.
• Loudness hides fallback. A workload is only safe on a shared free lane if a second path exists — another endpoint, a queued retry, or a manual runbook — when the lane is unavailable.

The two axes, defined

Variable	Definition	Where it comes from
B — burst ratio	p95 daily requests ÷ p50 daily requests for the same workload	Your own gateway, proxy, or app logs
H — revert hours	Wall-clock hours to undo the worst plausible bad output of one run	The owning team's honest estimate, written down
F — fallback	A second path that works without the free lane	Owner names it; someone else verifies it once

Two thresholds, chosen by you and written down before scoring: B_max and H_max. A team that cannot name B_max in advance will rationalize it after seeing the scores.

Compute burst ratio from logs you already have

The script below is illustrative and was not executed for this article. It assumes you can export a CSV with date,workload rows.

# illustrative only - not run, not validated against a real log export
import csv, statistics
from collections import defaultdict

per_day = defaultdict(lambda: defaultdict(int))
with open("ai_requests.csv") as f:
    for row in csv.DictReader(f):
        per_day[row["workload"]][row["date"]] += 1

def burst_ratio(daily_counts):
    if len(daily_counts) < 2:
        return None          # not enough days to say anything
    p50 = statistics.median(daily_counts)
    if p50 == 0:
        return None          # sparse workload: percentile ratio is noise
    p95 = statistics.quantiles(daily_counts, n=20)[18]
    return round(p95 / p50, 2)

for workload, counts in sorted(per_day.items()):
    print(workload, burst_ratio(list(counts.values())))

Prerequisites and an honest check:

1. At least 20 days of history per workload, covering at least one release cycle. Fewer days means the p95 is really a max in disguise.
2. Verify one workload by hand: sort its daily counts, take the index at 95%, divide by the median. If the script disagrees with your hand calc, fix the script before trusting any row.
3. Treat None as "insufficient evidence", not as a low score. Sparse workloads need two weeks of shadow logging first.

The assignment sheet, filled in

Illustrative scores for four of the fourteen candidates:

Workload	p50/day	p95/day	B	H	F named?	Gate result
Changelog summarizer	12	14	1.2	0.5	Yes (manual edit)	Pass — first in queue
Test-name suggester	30	33	1.1	1	Yes (skip step)	Pass
Release-note generator	20	140	7.0	2	No	Hold — fails B and F
Migration script reviewer	6	6	1.0	48	No	Reject — fails H regardless of burst

Note what the sheet does to the loudest case. The migration reviewer is the highest-stakes workload and the lowest-volume one; a burst-based argument would wave it through, and H = 48 blocks it anyway. That is the point of scoring both axes.

The four hard gates

Apply in order. A workload that fails any gate leaves the queue; it does not "go to the end".

1. Capacity headroom. Peak demand must sit under your usable free capacity with margin. Let Q be the free capacity you actually observe for your workload, confirmed in the product console rather than assumed. Require p95/day ≤ 0.7 × Q. The 0.7 is your margin, not a product limit — pick it and write down why.
2. Revertibility. H ≤ H_max. If a bad run cannot be undone inside that window by the owning team, the workload is not a free-lane candidate.
3. Data classification. If the inputs cannot leave your controlled environment under current policy, stop. Self-hosted or paid in-boundary options are the correct comparison, and the free lane is not in the running.
4. Owner and expiry. Name one owner and one review date, defaulting to 30 days. No owner, no access.

Break-even: when the free lane stops fitting

Escalate a workload off the free lane when any of these holds for two consecutive review periods:

• p95/day > 0.7 × Q — headroom gate about to fail
• More than 3 lane-unavailable days in a 20-day window, and F was exercised during them
• H grew because the workload's outputs now touch something harder to revert

The third one is the quiet failure. A workload can stay well inside capacity while becoming far more expensive to revert, and the capacity number will look fine the whole time.

Where the free server option changes the analysis

Free model access and the free server option together mean the lane can be a place to run a job, not only a model endpoint to call. That shifts H in a way model-only access does not: generated artifacts, intermediate state, and any scheduled jobs can live on that server, so a bad run may leave residue beyond a bad response.

Ask two extra questions before assigning a workload to the server option:

• Does the job write anything that must be deleted, not just corrected?
• Who can reach that state besides the owner?

If the answers are "yes" and "not sure", the workload is not ready for the server option even if it passes gates 1, 2 and 3.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source project offering free model access and a free server option for teams to try; current limits, available models, and environment details should be read from its own documentation before you set Q, because those specifics change and none are asserted here.

Who should not use this approach

• Teams without 20 days of request logs. You cannot compute B; log in shadow mode first.
• Regulated or contractually restricted data. Self-hosted or in-boundary paid deployment is the comparison to make, not a shared free lane.
• Workloads needing throughput guarantees. A shared free lane has no SLA you can put in a design doc.
• Anyone who will skip the owner and expiry fields. The sheet exists to make access revocable; without those two columns it is a wish list.

Run it in one sitting

1. Export 30 days of request counts per workload.
2. Compute B; hand-verify one row.
3. Collect H and F from owners in writing.
4. Set B_max, H_max, and your margin once, together, before scoring.
5. Fill the sheet, apply the four gates, assign the lane to the first pass.
6. Diarise the review date.

If you only take one thing from this: a free lane goes to the workload that is cheap to reverse and steady in shape, and it keeps going to that workload only until the numbers say otherwise.

Which would reverse your allocation first — a burst ratio above B_max, or a revert estimate higher than the team expected? That answer is the variable worth logging next month.