DEV Community: Alex Zhu

The Eviction Drill: Prove Your Agent Survives Losing Its Free Server in 30 Minutes

Alex Zhu — Tue, 27 Oct 2026 12:40:18 +0000

Your agent runs fine for weeks, and then the free server underneath it disappears at 02:40 on a Tuesday. The failure you get is rarely a clean error; it is forty minutes of silence in a queue nobody is watching, followed by a morning of guesswork. That scenario is cheap to rehearse and expensive to discover, which is why the playbook below exists.

This is a 30-minute eviction drill: a scheduled, reversible rehearsal in which you deliberately break the model endpoint and observe whether your worker degrades or collapses. You get three named roles, a dead proxy you can run on localhost, a timeline format, and a gate script that returns a pass or fail you can paste into a wiki page. Nothing here requires a paid staging cluster, and nothing here asks you to trust a dashboard.

Why rehearse eviction instead of running another load test

A load test answers "how much traffic can this absorb before latency climbs" and it is a useful question. An eviction drill answers a different one: "when the upstream endpoint stops existing, what does a real user see in the next sixty seconds." Those two questions fail in different ways, and teams routinely pass the first while failing the second.

The drill is also intentionally small. You are not testing capacity, model quality, or cost; you are testing one control-flow branch that everyone writes and almost nobody exercises. If your fallback path has never been triggered on purpose, treat it as unverified code rather than as a safety net.

The three roles and the two handoff rules

Assign roles before you touch anything, because the drill is worthless if the same person injects the fault and judges the outcome.

Drill Lead owns the clock and the fault injection; only this person starts and stops the drill.
Scribe owns the timeline file and writes down wall-clock events as they happen, including the boring ones.
Verifier owns the gate script and the final verdict; this person does not inject faults and does not fix code mid-drill.

Two handoff rules keep the rehearsal honest. First, the Lead hands off to the Scribe at injection time and announces the timestamp out loud, so the timeline has an anchor that is not reconstructed from memory. Second, the Verifier receives the timeline file, not a summary of it; if the run needs an explanation to pass, it did not pass.

Step 1: Write the failure budget on a single line

Before any code, agree on one sentence that everyone can read back. A usable example is: "For 30 minutes, no more than 1% of user requests may return 5xx, and a fallback must engage within 60 seconds of the fault."

Write that line at the top of the wiki card and do not negotiate it during the drill. Budgets that get adjusted while the drill is running are how a rehearsal turns into a performance of competence, which is the opposite of what you want.

Step 2: Stand up a dead proxy instead of breaking real infrastructure

You do not need to wait for a genuine outage to test outage behavior. The script below is a tiny TCP server that accepts connections and then misbehaves in one of three ways: it resets the socket, it returns HTTP 503, or it accepts the request and hangs forever. Point your model base URL at it and your agent will believe the provider is gone.

# deadproxy.py - simulate an upstream outage without touching real infrastructure.
# Template only: read it before you run it, and keep it on localhost.
import argparse, itertools, socket, sys, threading, time
from datetime import datetime, timezone

def log(msg):
    stamp = datetime.now(timezone.utc).isoformat(timespec='seconds')
    print(f'{stamp} {msg}', file=sys.stderr, flush=True)

def handle(conn, mode):
    try:
        if mode == 'reset':
            # SO_LINGER with a zero timeout makes close() send RST instead of FIN.
            conn.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, b'\x01\x00\x00\x00\x00\x00\x00\x00')
            conn.close()
            log('reset one connection')
            return
        if mode == '503':
            conn.recv(65536)
            body = b'{"error":"upstream_unavailable"}'
            head = (b'HTTP/1.1 503 Service Unavailable\r\n'
                    b'Content-Type: application/json\r\n'
                    b'Content-Length: ' + str(len(body)).encode() + b'\r\n'
                    b'Connection: close\r\n\r\n')
            conn.sendall(head + body)
            log('served 503')
            return
        if mode == 'hang':
            log('hanging one connection')
            time.sleep(3600)
    finally:
        try:
            conn.close()
        except OSError:
            pass

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument('--mode', choices=['reset', '503', 'hang'], default='503')
    ap.add_argument('--port', type=int, default=8081)
    ap.add_argument('--host', default='127.0.0.1')
    args = ap.parse_args()

    srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    srv.bind((args.host, args.port))
    srv.listen(64)
    log(f'dead proxy listening on {args.host}:{args.port} mode={args.mode}')

    while True:
        conn, _ = srv.accept()
        threading.Thread(target=handle, args=(conn, args.mode), daemon=True).start()

if __name__ == '__main__':
    main()

Run the three modes in separate rehearsals rather than picking a favorite, because a reset, a 503, and a timeout land in different exception branches of most HTTP clients. A team that only rehearses 503 usually discovers on the second drill that their client retries forever on connection resets.

This is also where the choice of host matters for planning. The account behind this article rehearses against MonkeyCode's free model access and its free server option, so the drill cost stays near zero and can be repeated monthly. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Treat the free token grant and the free server option as terms to re-read on the project page before you schedule a drill around them, since availability details are exactly the kind of thing that changes without an announcement.

Step 3: Make your agent emit a timeline, not log noise

A drill you cannot reconstruct is a story. Add a four-line helper that appends one JSON object per event, and call it at the decision points that matter.

# timeline.py - append-only event sink for one drill run.
import json, os
from datetime import datetime, timezone

SINK = os.environ.get('DRILL_LOG', 'drill.jsonl')

def mark(event, **fields):
    row = {'t': datetime.now(timezone.utc).isoformat(timespec='milliseconds'),
           'event': event, **fields}
    with open(SINK, 'a', encoding='utf-8') as fh:
        fh.write(json.dumps(row, sort_keys=True) + '\n')

Then instrument the one branch you actually care about. The names below are deliberately stable, because the gate script in Step 5 greps for them.

from timeline import mark

def answer(prompt, request_id):
    mark('user_request', id=request_id, phase='start')
    try:
        text = call_primary_model(prompt)
        mark('model_ok', id=request_id, path='primary')
    except ProviderUnavailable:
        mark('fallback_engaged', id=request_id, path='fallback')
        text = cached_or_smaller(prompt)
    except Exception:
        mark('unhandled_exception', id=request_id, kind='unknown')
        raise
    mark('user_request', id=request_id, phase='end', status=200)
    return text

If your worker already swallows exceptions in a background loop, add one mark('user_request', status=502) call at that boundary. The goal is a file where every user-visible outcome is present, not a file that only records the happy path.

Step 4: Run the 30-minute rehearsal

Keep the wall clock boring: start the proxy, start the worker, generate steady traffic, then inject the fault ten minutes in and leave it injected for fifteen.

# terminal 1 - the fake provider
python deadproxy.py --mode reset --port 8081

# terminal 2 - your worker, pointed at the fake provider
export MODEL_BASE_URL=http://127.0.0.1:8081
export DRILL_LOG="drill-$(date +%Y%m%d-%H%M).jsonl"

# terminal 3 - steady user-shaped traffic for the whole window
end=$((SECONDS + 1800))
while [ $SECONDS -lt $end ]; do
  ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    "http://127.0.0.1:8000/answer?q=drill-ping" || echo 000)
  printf '{"t":"%s","event":"user_request","id":"curl","status":%s}\n' \
    "$ts" "$code" >> "$DRILL_LOG"
  sleep 5
done

The Scribe writes three lines by hand during the run: injection time, the first fallback they observe, and the end of the window. Those three lines outrank everything else when the Verifier asks whether the timeline is complete.

Step 5: Gate the result with a script, not with opinions

This is the artifact that makes the drill repeatable. It reads the timeline and returns a non-zero exit code when the failure budget is broken.

# evict_gate.py - pass/fail for one eviction drill run.
import json, sys
from datetime import datetime

def load(path):
    rows = []
    with open(path, encoding='utf-8') as fh:
        for line in fh:
            line = line.strip()
            if line:
                rows.append(json.loads(line))
    return rows

def ts(row):
    return datetime.fromisoformat(row['t'].replace('Z', '+00:00'))

def first(rows, event):
    return next((r for r in rows if r['event'] == event), None)

path = sys.argv[1] if len(sys.argv) > 1 else 'drill.jsonl'
budget = float(sys.argv[2]) if len(sys.argv) > 2 else 0.01
rows = load(path)

inj = first(rows, 'fault_injected') or first(rows, 'fallback_engaged')
fb = first(rows, 'fallback_engaged')
checked = [('fault or fallback recorded', inj is not None),
           ('fallback engaged', fb is not None)]
if inj and fb:
    delta = (ts(fb) - ts(inj)).total_seconds()
    checked.append((f'fallback within 60s (observed {delta:.0f}s)', delta <= 60))

reqs = [r for r in rows if r['event'] == 'user_request' and 'status' in r]
fails = [r for r in reqs if int(r['status']) >= 500]
rate = (len(fails) / len(reqs)) if reqs else 1.0
checked.append((f'5xx rate {rate:.2%} <= {budget:.2%}', rate <= budget))
checked.append(('no unhandled exception', first(rows, 'unhandled_exception') is None))

for name, ok in checked:
    print(('PASS ' if ok else 'FAIL ') + name)
sys.exit(0 if all(ok for _, ok in checked) else 1)

Run it as python evict_gate.py "$DRILL_LOG" 0.01. If your worker writes its own timeline and never emits fault_injected, add a Lead-only mark call or accept the fallback timestamp as the anchor, but write down which choice you made so the next drill is comparable.

Reading the result: a decision table

Timeline signature	Most likely cause	Next action
No `fallback_engaged` at all	Fallback is dead code or catches the wrong exception class	Trigger the fallback in a unit test, then re-run the drill
Fallback engages fast but 5xx exceeds budget	Fallback returns an error for a subset of prompts	Log the fallback's own failures and give it a default response
Fallback within 60s, latency doubles	Cheaper fallback path is slow, often on cold cache	Warm the cache before the window and measure again
One `unhandled_exception`, then silence	Exception escapes a background loop and kills the worker	Add a supervisor restart and a `status=502` marker
Drill passes, production still failed	Real outage involved quota exhaustion or auth expiry, not transport errors	Add a second drill mode for non-transport failures

The last row is the one teams skip, and it is the reason a passing drill is not a warranty. Transport faults are the easy class to simulate locally; quota and credential faults usually require a provider-side control you may not have.

The one-page wiki card to paste before the next drill

# Eviction Drill - <service name> - <date>
Budget: no more than 1% 5xx for 30 min; fallback within 60s of fault.
Roles: Lead=<name>  Scribe=<name>  Verifier=<name>
Rules: Lead injects, Scribe timestamps, Verifier judges. No code edits mid-drill.

Pre-flight
  [ ] quiet window agreed, on-call told, status page note drafted
  [ ] baseline run recorded with the real endpoint (10 min, no fault)
  [ ] DRILL_LOG path agreed and writable by the worker user

Run
  [ ] python deadproxy.py --mode <reset|503|hang> --port 8081
  [ ] export MODEL_BASE_URL=http://127.0.0.1:8081
  [ ] traffic loop started, Scribe notes injection time
  [ ] 15 minutes of injected fault, then proxy stopped

Verdict
  [ ] python evict_gate.py "$DRILL_LOG" 0.01
  [ ] gate output pasted verbatim below
  [ ] one follow-up issue per FAIL line, each with an owner

Gate output:
  <paste here>

Keep the card short enough that someone can read it aloud at the start of the drill. Long cards get skimmed, and skimmed cards produce timelines with missing timestamps.

Limitations and who should skip this

The dead proxy exercises HTTP-level behavior only; it cannot reproduce clock skew, tokenizer changes, or a provider quietly returning 200 with a degraded answer. A green gate therefore proves your degradation path exists, not that your product stays correct under pressure.

Skip this playbook if you are a solo developer with no users yet, because a 30-minute rehearsal with three roles costs more than the outage would. Skip it too if your paying customers depend on a free tier as their only capacity, and fix the dependency before you rehearse around it. And if your drill needs a change window, schedule it rather than sneaking it into a Friday afternoon.

If you want to run this against a free server and a free model grant instead of a paid staging account, that is the setup this account uses and the reason the drill can be monthly rather than annual. Start with the reset mode, because it breaks the most clients and teaches the most in thirty minutes.

The Shift Handoff Card: A Rotation SOP for Agents Running on a Free Server

Alex Zhu — Mon, 26 Oct 2026 11:21:05 +0000

It is 09:10 on a Monday, and the person who owned the agent overnight is already sitting in another meeting. The incoming owner opens the dashboard, sees a queue depth of eleven, and cannot tell whether that is normal, stale, or the first hour of an incident. Twenty minutes later the two of them are rebuilding the night from chat history, and nobody has checked the model tier label since Friday afternoon.

That scene repeats on every team that runs a small agent job on capacity nobody paid for. Free tiers rarely come with an SLA, capacity can move without notice, and the box underneath your process may reboot while you sleep. When there is no vendor promise to lean on, the shift handoff becomes the only continuity mechanism your team actually controls.

This playbook turns that handoff into a one-page artifact plus a gate script you can paste into a wiki today. The reference setup calls models through MonkeyCode's free token access and runs the agent on its free server option, so each handoff has to carry two kinds of state: what the code is, and what the platform currently looks like. Treat the free grant, which the operator currently describes as roughly ten million tokens, and the free server option as terms that can change; read the console before you plan a month around either number.

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

Why handoffs break specifically on free capacity

On paid infrastructure you can often answer a 3 a.m. question by reading a vendor status page or an invoice line. On free capacity, the honest answer is frequently that nobody knows, because there is no support channel and no contractual state to query. The handoff therefore has to record observations rather than assumptions, and it has to fail loudly when an observation is missing.

A second failure mode is ownership drift. When the outgoing owner writes a paragraph of prose, the incoming owner reads it as context rather than as a checklist, and unverified claims slip through. Structured fields and a script that exits non-zero fix more of this than any amount of documentation discipline.

Step 1: Name three roles and keep them separate

Use exactly three roles, because two roles collapse into a conversation and four roles create a committee. The outgoing owner is accountable for recording the shift state before they leave, and they are the only person allowed to declare the shift closed. The incoming owner accepts the state by re-running the gate themselves, never by trusting the pasted card alone. The reviewer is a third person who reads the card once per week, looks for patterns across shifts, and owns any decision to change the checklist.

Write those three sentences into the wiki page above the card template. A role definition that lives only in someone's head will not survive the first vacation.

Step 2: Freeze the shift state in one JSON file

Keep the state file small enough that filling it takes under three minutes, because a handoff ritual that costs fifteen minutes gets skipped on the busy nights when it matters most. Commit it under .shift/ so the history of your shifts is reviewable like any other change.

{
  "shift": "2026-10-26-night",
  "owner_outgoing": "alex",
  "owner_incoming": "priya",
  "reviewer": "sam",
  "model_tier_label": "<paste the exact label your console shows>",
  "open_incidents": [],
  "queue_depth": 0,
  "notes": "none"
}

The model_tier_label field is deliberately a string you copy rather than a value the script guesses. Free tiers rotate what they serve, and a label that changes without a changelog entry is the cheapest early warning you will ever get. If an incident is open, add an object with an owner key, because an incident without an owner is a rumour.

Step 3: Fingerprint the parts you actually control

Hashing your prompt file and your agent config gives the incoming owner a cheap way to answer whether the running system is the one in the repository. Combined with the git commit, three short hashes catch most silent drift between shifts.

#!/usr/bin/env python3
'''handoff_gate.py - refuse a shift handoff that is missing evidence.

Usage:
  python3 handoff_gate.py --state .shift/state.json
  python3 handoff_gate.py --state .shift/state.json --emit-card
'''
import argparse
import datetime as dt
import hashlib
import json
import pathlib
import subprocess
import sys

REQUIRED_FIELDS = [
    'shift', 'owner_outgoing', 'owner_incoming', 'reviewer',
    'model_tier_label', 'open_incidents', 'queue_depth', 'notes',
]
WATCHED_FILES = ['prompts/agent.md', 'config/agent.json']


def short_hash(path):
    return hashlib.sha256(pathlib.Path(path).read_bytes()).hexdigest()[:12]


def git_commit():
    try:
        out = subprocess.check_output(
            ['git', 'rev-parse', '--short', 'HEAD'],
            text=True, stderr=subprocess.DEVNULL,
        )
        return out.strip()
    except Exception:
        return 'no-git'


def snapshot(state):
    prints = {}
    for name in WATCHED_FILES:
        prints[name] = short_hash(name) if pathlib.Path(name).exists() else 'missing'
    return {
        'commit': git_commit(),
        'fingerprints': prints,
        'generated_at': dt.datetime.now(dt.timezone.utc).isoformat(timespec='seconds'),
    }


def checks(state, snap):
    missing = [k for k in REQUIRED_FIELDS if state.get(k) in (None, '', [])]
    results = [('required fields present', not missing, ', '.join(missing) or 'ok')]
    label = str(state.get('model_tier_label', ''))
    results.append(('tier label is not a placeholder', not label.startswith('<'), label))
    results.append((
        'watched files hashed',
        all(v != 'missing' for v in snap['fingerprints'].values()),
        json.dumps(snap['fingerprints']),
    ))
    results.append((
        'outgoing differs from incoming',
        state.get('owner_outgoing') != state.get('owner_incoming'),
        '{} -> {}'.format(state.get('owner_outgoing'), state.get('owner_incoming')),
    ))
    incidents = state.get('open_incidents') or []
    owned = all(i.get('owner') for i in incidents)
    results.append(('every open incident has an owner', owned, '{} open'.format(len(incidents))))
    return results


def card(state, snap, results):
    lines = [
        '## Shift handoff - {}'.format(state.get('shift')),
        '',
        '- Outgoing: {}'.format(state.get('owner_outgoing')),
        '- Incoming: {}'.format(state.get('owner_incoming')),
        '- Reviewer: {}'.format(state.get('reviewer')),
        '- Commit: `{}`'.format(snap['commit']),
        '- Model tier label: {}'.format(state.get('model_tier_label')),
        '- Queue depth at handoff: {}'.format(state.get('queue_depth')),
        '',
        '### File fingerprints',
        '',
        '| file | sha256 (first 12) |',
        '| --- | --- |',
    ]
    for name, digest in snap['fingerprints'].items():
        lines.append('| `{}` | `{}` |'.format(name, digest))
    lines += ['', '### Gate results', '']
    for name, ok, detail in results:
        lines.append('- {} - {} ({})'.format('PASS' if ok else 'FAIL', name, detail))
    lines += ['', '### Notes', '', str(state.get('notes')), '']
    return '\n'.join(lines)


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument('--state', default='.shift/state.json')
    ap.add_argument('--emit-card', action='store_true')
    args = ap.parse_args()

    state = json.loads(pathlib.Path(args.state).read_text())
    snap = snapshot(state)
    results = checks(state, snap)

    for name, ok, detail in results:
        status = 'PASS' if ok else 'FAIL'
        print('{}  {}  [{}]'.format(status, name, detail))

    if args.emit_card:
        out = pathlib.Path('.shift/card.md')
        out.write_text(card(state, snap, results))
        print('\nwrote {}'.format(out))

    failed = [n for n, ok, _ in results if not ok]
    if failed:
        print('\ngate blocked: {} check(s) failed'.format(len(failed)), file=sys.stderr)
        return 1
    print('\ngate passed: handoff may proceed')
    return 0


if __name__ == '__main__':
    raise SystemExit(main())

The script uses only the standard library and needs Python 3.9 or newer, so it runs on whatever free server you already have. Nothing in it contacts a model or a control plane, which is intentional: a gate that depends on the platform being up cannot be trusted during an outage.

Step 4: Run the gate before you write prose

The outgoing owner fills the state file first and runs the gate second, because the report should tell them what is missing rather than confirm what they remember writing. A blocked run looks like this.

$ python3 handoff_gate.py --state .shift/state.json
FAIL  required fields present  [notes]
PASS  tier label is not a placeholder  [free-tier-b]
PASS  watched files hashed  {"prompts/agent.md": "9f2c1ab4e7d0", "config/agent.json": "41be77c0a9d3"}
PASS  outgoing differs from incoming  alex -> priya
PASS  every open incident has an owner  [0 open]

gate blocked: 1 check(s) failed

Fix the missing field and re-run with --emit-card, which writes .shift/card.md in the exact shape your wiki page expects. The incoming owner then re-runs the same command against the same commit and compares the printed fingerprints with the card they were given. A mismatch is not an accusation, it is a signal that something changed between the paste and the acceptance.

Step 5: Paste one page and sign it in the wiki

Your wiki page should hold the three role definitions, the JSON template, and the generated card, in that order and nothing else. Keep the previous five cards collapsed below the current one, because patterns across a week are more useful than any single night. Signing the handoff means the incoming owner appends one line to the card with their name and the local commit they verified, and the reviewer checks that line exists before reading anything else.

Decision table for the three interruptions that actually happen

Signal at handoff	Action	Do not
Free server unreachable	Record the outage time, keep the queue frozen, and hand off a written resume condition	Redeploy or rebuild the box mid-handoff
Token grant close to exhausted	Record the remaining balance verbatim and reduce batch size for the next shift	Estimate the balance from memory
Tier label changed overnight	Pin the old label in a branch, run one comparison job, and hand off the diff	Assume the new label behaves the same
Fingerprint changed with no changelog	Block the handoff until the diff is explained in the card	Merge and move on

That table is the part reviewers edit most often, and it should stay short enough to scan in under a minute.

What this gate cannot tell you

The script proves that paperwork exists, not that the agent behaves correctly, and confusing those two outcomes is the main way this playbook gets misused. Prompt and config hashes say nothing about how a remote model answers today, so they detect your changes rather than the platform's. Free capacity can be withdrawn or reshaped at any time, which means a passing gate is evidence about your process, never a guarantee about tomorrow.

The script also assumes a repository layout with prompts/agent.md and config/agent.json, and it has not been run against yours, so expect to spend ten minutes adjusting paths. It has no opinion about logs, latency, or cost attribution, and it should not replace metrics you already collect.

Who should not use this

Skip this playbook if you need per-request billing attribution, work under a regulated data regime, or depend on a paid SLA that already provides an incident record. Skip it as a solo developer too, because a handoff card you write to yourself is overhead with no reader. It also fails quietly on teams where nobody reads the card, and in that case the fix is organizational rather than technical.

If you want to test the pattern before buying capacity, the free token grant and the free server option are a cheap way to run a two-person rotation for a week and see whether the card earns its place in your wiki. Start with the gate script, add the wiki page only after the first blocked handoff annoys someone enough to fix the state file.

MonkeyCode provides free models that can run this workflow.

Spend a Free Token Grant Like It's Production: A Ledger SOP With Three Roles and a Gate Script

Alex Zhu — Tue, 20 Oct 2026 09:24:42 +0000

Picture the third Tuesday of a pilot: the grant is gone, nobody can name the workload that ate it, and the one job that mattered is now being throttled by its own team. That is not a model problem and it is not a capacity problem — it is an accounting problem. Free tokens and a free server make the first experiment cheap, but they also remove the invoice that would normally tell you, painfully and on time, that a retry loop is spending your budget. This post is the playbook I would paste into a team wiki before anyone points a job at a grant: three roles, one gate script, and a stop rule that does not depend on somebody happening to notice.

The scenario above is a composite, not a customer story. The mechanics are ordinary, which is exactly why the fix can be a page of Markdown and forty lines of Python.

1. Why a grant without a ledger fails quietly

Three failure modes show up in almost every pilot that skips bookkeeping. First, unattributed spend: the usage dashboard shows one aggregate number per day, so no one can say whether the cost came from the ticket summarizer or the scraper. Second, retry amplification: an agent that retries three times looks like one job in your logs but bills like four, and the run count stays flat while tokens climb. Third, no stop authority: the person who owns the workload is also the person who decides to keep it running, so the halt never happens until the grant is empty.

None of these need a platform change to fix. You need per-run token counts in a file you control, an envelope per workload, and someone other than the spender holding the stop button.

Which workloads belong on a free grant at all

Workload shape	Belongs on a grant?	Reason	Guard you must add
Bounded batch (summarize 200 tickets, one pass)	Yes	Finite and measurable per run	Per-run cap + retry ceiling
Interactive chat for a whole team	No, not yet	Unbounded, attribution is per-seat and invisible	Ship attribution before access
Nightly cron with automatic retries	Only with a ceiling	Classic amplification source	`max_attempts = 2`, backoff, alert on 3rd
Extraction over a large corpus	Yes, behind an envelope	Cost is roughly linear, good pilot material	Sample 1%, extrapolate, then open
Anything you cannot count per run	No	Your ledger would be fiction	Add token counts to the logs first

The last row is the one teams argue about. If your tooling cannot emit tokens per run, stop and instrument it; a ledger built from estimates will pass the gate and still leave you blind at the worst moment.

2. Three roles and two handoffs

Role	Owns	Cadence	Never does
Workload Owner	The job, its acceptance test, and the envelope request	Writes the request once, reviews weekly	Halts their own workload
Meter Keeper	`ledger.jsonl`, deduplication, the gate output	Runs the gate twice a week	Approves new workloads
Stop Authority	The halt call at the stop threshold	On-call for the pilot window	Edits the ledger

The handoffs are short enough to write on one line each. Owner to Meter Keeper: the envelope request plus the source of per-run token counts, delivered before the first production run. Meter Keeper to Stop Authority: the gate output whenever any workload reaches the warning band, with the offending workload named. Stop Authority to Owner: a written halt notice, and resumption requires a written fix — a retry ceiling, a smaller batch, or a new envelope.

Separating the spender from the stopper feels bureaucratic for a two-person team, and for a two-person team it probably is. Keep the split for any pilot where more than one person can trigger a run, because that is where attribution quietly dies.

3. Set envelopes in tokens, not money

Money is the wrong unit during a pilot, because the price can change while your grant cannot. Derive each envelope from one measured run, the expected run count, and a retry allowance: envelope = tokens_per_run × planned_runs × 1.5. Round up, write it down, and keep one envelope per workload per model — token counts from different tokenizers are not comparable, so mixing models in a single ledger column turns your percentages into noise.

Run one representative job and record the token count your tool reports for that single run.
Multiply by the planned run count for the pilot window, then by 1.5 for retries and re-runs.
Write the number into envelopes.json, one key per workload, and commit both files.
Record every run as one JSON line with ts, workload, tokens, and run — the run id is what makes amplification visible.

# Append one measured run. In practice your tool writes this line; here it is by hand.
python3 - <<'PY'
import json, pathlib
row = {"ts": "2026-10-20T09:00:00Z", "workload": "summarize-tickets",
       "tokens": 18432, "run": "r-0413"}
with pathlib.Path("ledger.jsonl").open("a", encoding="utf-8") as fh:
    fh.write(json.dumps(row) + "\n")
PY

With 18,432 tokens per run, 200 planned runs, and the 1.5 allowance, the envelope is 5,529,600 tokens; round it to 5,500,000 and you have a number a reviewer can check in ten seconds.

4. The gate script

This is the artifact. It reads the ledger, compares each workload to its envelope, and returns an exit code your scheduler or CI can act on. Standard library only, Python 3.9 or newer.

#!/usr/bin/env python3
"""token_gate.py — enforce per-workload token envelopes from a JSONL ledger.

Exit codes: 0 ok, 10 warning (>=60%), 20 stop (>=85%), 30 halt (>=100%),
            10 if any workload appears with no envelope.
"""
import json
import pathlib
import sys
from collections import defaultdict

WARN, STOP, HALT = 0.60, 0.85, 1.00
STATE_CODE = {"ok": 0, "warn": 10, "stop": 20, "halt": 30, "unbudgeted": 10}


def load_ledger(path):
    totals, runs = defaultdict(int), defaultdict(set)
    with open(path, encoding="utf-8") as fh:
        for lineno, line in enumerate(fh, 1):
            line = line.strip()
            if not line:
                continue
            try:
                row = json.loads(line)
            except json.JSONDecodeError as exc:
                raise SystemExit(f"ledger line {lineno}: {exc}")
            totals[row["workload"]] += int(row["tokens"])
            runs[row["workload"]].add(row.get("run", "?"))
    return totals, runs


def evaluate(totals, runs, envelopes):
    report, worst = [], 0
    for name, cap in sorted(envelopes.items()):
        used = totals.get(name, 0)
        pct = (used / cap) if cap else 1.0
        state = ("halt" if pct >= HALT else "stop" if pct >= STOP
                 else "warn" if pct >= WARN else "ok")
        worst = max(worst, STATE_CODE[state])
        report.append({"workload": name, "used": used, "cap": cap,
                       "pct": round(pct * 100, 1),
                       "runs": len(runs.get(name, ())), "state": state})
    for name in sorted(set(totals) - set(envelopes)):
        worst = max(worst, STATE_CODE["unbudgeted"])
        report.append({"workload": name, "used": totals[name], "cap": None,
                       "pct": None, "runs": len(runs[name]),
                       "state": "unbudgeted"})
    return report, worst


def main(argv):
    if len(argv) != 3:
        print("usage: token_gate.py LEDGER.jsonl ENVELOPES.json", file=sys.stderr)
        return 64
    totals, runs = load_ledger(argv[1])
    envelopes = json.loads(pathlib.Path(argv[2]).read_text(encoding="utf-8"))
    report, code = evaluate(totals, runs, envelopes)
    for row in report:
        print(json.dumps(row, sort_keys=True))
    return code


if __name__ == "__main__":
    sys.exit(main(sys.argv))

Run it the same way every time so the output is comparable across weeks:

python3 token_gate.py ledger.jsonl envelopes.json; echo "exit=$?"
# {"cap": 5500000, "pct": 71.4, "runs": 186, "state": "warn", "used": 3927000, "workload": "summarize-tickets"}
# exit=10

One jq line catches retry amplification early, because a looping job owns the top of this list:

# Top five single runs by tokens — retry loops appear here before they appear in totals.
jq -r '[.workload, .run, .tokens] | @tsv' ledger.jsonl | sort -k3,3nr | head -5

5. A test that proves the gate fires

A gate nobody tested is a comment with a sys.exit in it. This stdlib-only test writes three small ledgers and asserts the exit codes you will actually act on.

# test_token_gate.py — run with: python3 test_token_gate.py
import json, pathlib, subprocess, sys, tempfile


def write(path, rows):
    path.write_text("\n".join(json.dumps(r) for r in rows) + "\n", encoding="utf-8")


def main():
    with tempfile.TemporaryDirectory() as tmp:
        tmp = pathlib.Path(tmp)
        (tmp / "envelopes.json").write_text(
            json.dumps({"summarize-tickets": 1000}), encoding="utf-8")
        write(tmp / "warn.jsonl", [{"workload": "summarize-tickets", "tokens": 600, "run": "r1"}])
        write(tmp / "stop.jsonl", [{"workload": "summarize-tickets", "tokens": 500, "run": "r1"},
                                   {"workload": "summarize-tickets", "tokens": 350, "run": "r2"}])
        write(tmp / "unbudgeted.jsonl", [{"workload": "scraper", "tokens": 10, "run": "r1"}])
        for ledger, expected in [("warn.jsonl", 10), ("stop.jsonl", 20), ("unbudgeted.jsonl", 10)]:
            proc = subprocess.run(
                [sys.executable, "token_gate.py", str(tmp / ledger),
                 str(tmp / "envelopes.json")], capture_output=True, text=True)
            assert proc.returncode == expected, \
                f"{ledger}: got {proc.returncode}, want {expected}\n{proc.stdout}{proc.stderr}"
            print(f"ok {ledger} -> exit {proc.returncode}")
    print("all gate cases pass")


if __name__ == "__main__":
    main()

I have not run this against your tooling, only against the three synthetic ledgers above, so treat the numbers as structure rather than evidence. If your ledger has a different field name than tokens, change the one line in load_ledger and re-run the test before trusting the output.

6. The wiki page you paste

Keep it to one screen. If it does not fit, the pilot is too complicated to audit.

# Token Envelope Run — <pilot name>

## Scope
Workloads allowed on the grant: <list>. Everything else needs a new envelope.
Model(s) in this ledger: <one per ledger column>.

## Roles
- Workload Owner: <name> — writes the envelope request, reviews weekly.
- Meter Keeper: <name> — owns ledger.jsonl, runs the gate Tue/Fri.
- Stop Authority: <name> — halts workloads; resumes only after a written fix.

## Thresholds
60% of envelope -> warning posted in <channel>.
85% of envelope -> Stop Authority halts the workload; Owner gets a written notice.
100% -> no new runs until a new envelope is approved in writing.
Unbudgeted workload seen -> treated as a warning, never as free capacity.

## Cadence
Tue/Fri: gate output pasted in <channel> with the exit code.
Friday: reconcile run count vs token count; flag any workload above 1.5x tokens per run.

## Exit criteria for the pilot
Acceptance test passes, spend is inside envelope, and the ledger can name every run.

Two fields do the real work here: "Model(s) in this ledger" and "Unbudgeted workload seen". Skip them and you will eventually compare percentages across tokenizers that counted differently, which produces confident, wrong percentages.

7. Where a free tier fits, and what it cannot fix

A free tier changes the cost of running the exercise, not the discipline it requires. MonkeyCode's current offer includes free model access, a free server option, and a promotion advertised as 10 million free tokens — all of that is what the operator states, and quotas on any promotion change, so read the offer page on the day you plan around the number rather than trusting this paragraph.

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

What the free tier removes is the procurement conversation before the pilot starts, which is often the whole reason the pilot never starts. What it does not remove is the need to know which workload spent what, and an offer of free tokens cannot tell you that — only your ledger can. Treat the grant as the budget you are auditing, not as a reason to skip the audit.

Who should not use this approach

Solo builders on a weekend project. One envelope and one person is theatre; just log tokens and move on.
Teams without per-run token export. If the numbers are estimates, the gate returns confident fiction — instrument first.
Workloads where tokens are not the binding constraint. If latency, GPU minutes, or rate limits stop you first, build that meter instead.
Anyone mixing models in one ledger column. Percentages across tokenizers are not comparable; split the ledger.
Teams treating this as a security control. It is an accounting control; it will not stop a determined caller, only make spend visible.

If you want to run the exercise end to end, start from the current free-tier offer page, paste the wiki block above into your team space, and let the gate script fail a synthetic ledger before a real workload ever reaches 85%. The first week you catch an amplification loop at the warning band instead of in the post-mortem is the week this page pays for itself.

References and scope notes

The script and test above target Python 3.9+ with the standard library only; jq is required for the one-liner in section 4.
Threshold constants 0.60/0.85/1.00 are a starting convention, not a recommendation derived from benchmarks; change them in one place, WARN/STOP/HALT.
Token counts are tokenizer-specific by definition, which is why the SOP keeps one model per ledger column and one envelope per workload.
Free model access, the free server option, and the 10 million token promotion are operator-supplied availability claims; verify current terms on the offer page before planning capacity around them.

Before an Agent Job Touches a Shared Box: Five Assumption Checks, Three Roles, One Wiki Page

Alex Zhu — Mon, 19 Oct 2026 08:08:17 +0000

The log ends mid-line. There is no traceback, no exit code from your job, and no clue about which write failed — only a half-finished record on a machine you do not administer. You re-run the same job on your laptop, it passes, and that is the moment you learn that "it works" was never the claim you needed to verify.

Agent jobs on shared hardware rarely fail because the model is wrong. They fail because the workspace turned read-only, the clock drifted far enough to expire a token, egress to one host is blocked, or two runs are interleaving writes into the same directory. None of that appears in a capability review, because these are not questions about what the box can do. They are questions about what you quietly assumed it would keep doing.

This playbook converts those assumptions into five checks, three roles, and a single wiki page you can paste before a job is allowed to start.

1. Placement is a decision, not a default

Most teams answer one question — "can this machine run the job?" — and skip the second one, "should this job live here at all?" The first question gets answered by a successful run, which is a sample of size one on a machine you do not own.

Treat placement as a written decision with a named owner. The artefact does not need to be long: a run line, five checked assumptions, and a hash of the report that proved them. What matters is that the decision is recorded somewhere a reviewer can read without opening your terminal history.

Why this lands harder on a shared or free tier

When you rent a dedicated host, the environment is boring and you stop thinking about it. When you use a free tier, the trade you accepted is exactly that the box is shared, may be recycled, and is not yours to configure. MonkeyCode offers free model access and a free server option, which drops the cost of an agent run close to zero — and that is precisely the condition under which a team stops writing down its environmental assumptions, because retrying feels cheaper than documenting.

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

I am deliberately not printing a token allowance or a hardware spec here. Those numbers change, and a stale figure in a tutorial becomes a bug report three weeks later. Check the project's own page for the current limits before you plan around them.

2. The five assumptions worth checking

Each row is cheap to verify and expensive to discover late.

Assumption	What breaks without it	Cheap check
The workspace is writable with headroom	a mid-run write fails, or the disk fills silently	`touch` a probe file, then `df -Pm`
The wall clock is roughly correct	token expiry, cache TTLs, and log ordering all lie	compare to an HTTP `Date` header
Every host the job needs is reachable	the call hangs until your timeout, not the server's	one `HEAD` request per host
The credential exists and is never printed	an hour lost to 401s you cannot see	length check plus a short hash
You are the only writer for this run	two agents interleave writes into one directory	`flock` on a run lock

Note what is absent: no performance measurement, no model comparison, no throughput claim. This is an assumption ledger, not a benchmark. If you want the capacity side, that is a separate exercise with a separate owner.

3. Three roles and two handoffs

Keep the role count low enough that a small team will actually honour it.

Run Owner. Writes the run line, owns the five assumptions, pastes the preflight report into the wiki page. Does not get to declare the job ready.

Box Steward. Owns the shared host or tier, maintains the egress allowlist, and is the only person who can sign an exception. When a check fails and the job must still run, the steward writes down which assumption is being waived and until when.

Reviewer. Reads the run line and the report hash before the work merges. The reviewer's job is not to re-run the script; it is to notice when a report is three days old or when the run line quietly grew a second egress host.

There are two handoffs. The first is Run Owner → Box Steward when any line reports FAIL. The second is Run Owner → Reviewer when the gate passes. Both handoffs are wiki edits, not messages, so the next person to touch the job inherits the reasoning.

4. Step 1 — drop the preflight script into the repo

The script below asserts the five assumptions and prints one line per check. It is intentionally boring, and it exits non-zero whenever anything fails.

#!/usr/bin/env bash
# preflight.sh — assert five assumptions before an agent job starts.
# Usage: WORKDIR=./work EGRESS_HOSTS="api.example.com" ./preflight.sh > preflight.report
set -uo pipefail

WORKDIR="${WORKDIR:-$PWD/work}"
EGRESS_HOSTS="${EGRESS_HOSTS:-api.example.com}"
SECRET_VAR="${SECRET_VAR:-MODEL_API_KEY}"
MIN_FREE_MB="${MIN_FREE_MB:-512}"
MAX_SKEW_S="${MAX_SKEW_S:-120}"
LOCK="${LOCK:-/tmp/agent-run.lock}"

fail=0
line() { printf '%-8s %-22s %s\n' "$1" "$2" "$3"; }
ok()   { line OK "$1" "$2"; }
bad()  { line FAIL "$1" "$2"; fail=1; }

# 1 — workspace is writable with headroom
if mkdir -p "$WORKDIR" && touch "$WORKDIR/.probe" 2>/dev/null; then
  rm -f "$WORKDIR/.probe"; ok workspace.writable "$WORKDIR"
else
  bad workspace.writable "$WORKDIR not writable"
fi
free_mb=$(df -Pm "$WORKDIR" 2>/dev/null | awk 'NR==2 {print $4}')
if [ -n "${free_mb:-}" ] && [ "$free_mb" -ge "$MIN_FREE_MB" ]; then
  ok workspace.headroom "${free_mb}MB free"
else
  bad workspace.headroom "${free_mb:-unknown}MB free, need ${MIN_FREE_MB}"
fi

# 2 — wall clock agrees with a public reference within tolerance
first_host=${EGRESS_HOSTS%% *}
local_epoch=$(date -u +%s)
remote_epoch=$(curl -sS -m 5 -I "https://$first_host" 2>/dev/null \
  | awk 'BEGIN{IGNORECASE=1} /^date:/ {sub(/^[Dd]ate: +/, ""); print}' \
  | tr -d '\r' | xargs -r date -u -d)
if [[ "${remote_epoch:-}" =~ ^[0-9]+$ ]]; then
  skew=$(( local_epoch > remote_epoch ? local_epoch - remote_epoch : remote_epoch - local_epoch ))
  if [ "$skew" -le "$MAX_SKEW_S" ]; then ok clock.skew "${skew}s"; else bad clock.skew "${skew}s over tolerance"; fi
else
  bad clock.skew "no usable Date header from $first_host"
fi

# 3 — every host the job needs answers
for host in $EGRESS_HOSTS; do
  code=$(curl -sS -m 8 -o /dev/null -w '%{http_code}' "https://$host" 2>/dev/null || echo 000)
  if [ "$code" != "000" ]; then ok egress.$host "HTTP $code"; else bad egress.$host "unreachable"; fi
done

# 4 — credential present, never printed
value="${!SECRET_VAR:-}"
if [ "${#value}" -ge 16 ]; then
  digest=$(printf '%s' "$value" | sha256sum | cut -c1-10)
  ok secret.present "$SECRET_VAR sha256:$digest"
else
  bad secret.present "$SECRET_VAR missing or too short"
fi

# 5 — this process is the only writer for this run
exec 9>"$LOCK"
if flock -n 9; then ok run.lock "acquired $LOCK"; else bad run.lock "$LOCK held elsewhere"; fi

if [ "$fail" -eq 0 ]; then echo "SUMMARY PASS"; else echo "SUMMARY FAIL"; fi
exit "$fail"

Two portability notes before you copy this. It assumes bash 4 or newer for the indirect expansion ${!SECRET_VAR}, plus GNU coreutils and flock; on macOS, replace the date -u -d reference parse with gdate or a small Python one-liner. Keep the script in the job repo rather than in someone's home directory, so the reviewer can read exactly what was checked.

5. Step 2 — gate the run on a fresh report

A preflight nobody is required to read is a decoration. Wrap it in a gate that refuses to start the job without a complete report.

#!/usr/bin/env bash
# gate.sh — refuse a run unless the latest preflight report is complete.
set -euo pipefail
report="${1:?usage: gate.sh <preflight.report>}"
run_id="${2:-$(date -u +%Y%m%dT%H%M%SZ)}"

if grep -q '^FAIL' "$report"; then
  echo "gate: fail  run=$run_id  see $report" >&2
  exit 1
fi

for key in workspace clock egress secret run; do
  if ! grep -qE "^OK[[:space:]]+${key}" "$report"; then
    echo "gate: missing OK for $key  run=$run_id" >&2
    exit 1
  fi
done

stamp=$(sha256sum "$report" | cut -c1-12)
echo "gate: pass  run=$run_id  report=$stamp" | tee -a "$report"

The gate checks that each assumption reported at least one success, so a report where egress checks were skipped cannot pass on the strength of the other four. The report hash is what you paste into the wiki; it is short enough to read and long enough to spot a swapped file.

6. Step 3 — paste the one-page run into the wiki

This is the whole page. Fill it in once per job, then edit it in place forever.

# Agent run: <job-name>

Owner:        @<handle>   (run line, five assumptions)
Box steward:  @<handle>   (shared host or tier, signs exceptions)
Reviewer:     @<handle>   (reads report + run line before merge)

## Run line
job=<job-name> box=<host-or-tier> workdir=<path> egress=<host1,host2> \
  secret=<VAR> deadline_utc=<YYYY-MM-DDTHH:MMZ>

## Steps
1. Preflight lives in the repo at `scripts/preflight.sh`. No local-only copies.
2. Run: `WORKDIR=<path> EGRESS_HOSTS="<hosts>" ./scripts/preflight.sh > preflight.report`
3. Paste the `SUMMARY` line and the report hash here.
4. Any `FAIL` → open an exception row with the steward. Do not retry first.
5. Run `scripts/gate.sh preflight.report`. Paste its output. Only then start the job.
6. After the run, append exit code, wall time, and the first line that scrolled past you.

## Exceptions
| date | assumption waived | signed by | expires |
| --- | --- | --- | --- |
|  |  |  |  |

Step 6 matters more than it looks. The first line that scrolled past is usually the one that explains the next failure, and it costs nothing to write down while the run is still fresh.

7. Step 4 — decide where the job belongs

Use the same page to argue about placement instead of relitigating it in chat.

Job shape	Where it belongs	Why
Interactive debugging, minutes, one credential	your laptop	fastest loop, no shared state
Repeatable batch, small working set	a shared free box	cheap and disposable, and preflight keeps it honest
Needs a stable public IP or inbound port	a host you administer	shared egress is not yours to promise
Large local dataset, GPU, big temp space	a sized host you pay for	disk assumptions break quietly
Secret-heavy or regulated data	your own environment	five checks are not a security review

Write the chosen row into the run line as box=. A future you reading the page will not remember why the job moved, and the table is a cheaper reminder than a postmortem.

Limitations and who should skip this

The preflight is a point-in-time assertion. It proves the environment at the second you ran it, and a shared box can change its mind ten minutes later; the gate is a speed bump, not a guarantee. It measures nothing about performance, quality, or cost. And the flock check is advisory — it stops cooperating runs, not a determined one.

Skip this playbook if configuration management or existing health checks already cover your hosts, if you run single-tenant infrastructure you fully control, or if your job starts in under a second and cannot tolerate a probe. Likewise skip it if the workload is regulated: the five checks tell you the box is usable, not that it is auditable.

If you want a target to practise on before you write the real page, the free model access and free server option in the MonkeyCode project give you a machine you can throw away while you learn what your job actually assumes — start with the project's own documentation so your run line matches the current limits.

Run a 20-Minute Load Interview Before You Put an Agent on a Free Server

Alex Zhu — Sun, 18 Oct 2026 06:53:34 +0000

Free compute is easy to accept and hard to operate. The failure mode is rarely an outage; it is a slow drift nobody measured, followed by an argument in a standup where both sides are guessing. This playbook turns that argument into a twenty-minute measurement you can paste into your wiki, with roles, thresholds, and a script that refuses to sign off on vibes.

Why a load interview instead of a quick smoke test

A smoke test answers "did it respond?". A load interview answers "what shape does it respond in, and which of our jobs does that shape support?". You want cold latency, warm latency, how latency moves as concurrency rises, and the error rate at each step, because a free tier that is fine at one request can be unusable at eight.

The project in this write-up is MonkeyCode, an open-source coding agent project whose operator lists a free model tier and a free server option. Both availability claims are operator-supplied and I have not independently audited quotas, hardware, or duration, so treat every number you need as something your own harness must produce.

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

The interview does not tell you whether the product is good. It tells you which of your jobs are allowed to run there this week, which is a decision your team can actually defend.

Roles: three seats and no shared memory

Driver runs the harness and owns the terminal. The driver does not interpret results while the run is in progress.
Reader holds the thresholds and signs pass or fail. The reader must be someone who did not write the harness, because authors grade generously.
Recorder writes the wiki page, attaches the raw JSON, and records the commit hash of the harness so next month's run is comparable.

Three seats is deliberate. One person running, reading, and recording will quietly skip the third step, and the third step is the one that survives staff turnover.

The artifact: a stdlib-only load interview

The script below uses only the Python standard library, so it runs anywhere your CI runner exists. Save it as load_interview.py and point it at your own deployment.

#!/usr/bin/env python3
"""load_interview.py - cold/warm latency and error rate for one HTTP endpoint.
Stdlib only. Replace the URL and payload with your own; nothing here is product-specific."""
import argparse, json, statistics, time, urllib.request, urllib.error
from concurrent.futures import ThreadPoolExecutor


def one_call(url, payload, timeout):
    req = urllib.request.Request(
        url, data=json.dumps(payload).encode(),
        headers={"Content-Type": "application/json"},
    )
    t0 = time.perf_counter()
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            r.read()
            code = r.status
    except urllib.error.HTTPError as e:
        code = e.code
    except Exception:
        code = 0  # timeout, DNS, connection reset: all count as errors here
    return time.perf_counter() - t0, code


def summarize(samples, label):
    lat = sorted(s for s, _ in samples)
    errs = sum(1 for _, c in samples if c < 200 or c >= 300)
    pick = lambda q: lat[min(len(lat) - 1, int(q * len(lat)))]
    return {
        "label": label, "n": len(lat),
        "p50_s": round(statistics.median(lat), 3),
        "p95_s": round(pick(0.95), 3),
        "max_s": round(lat[-1], 3),
        "error_rate": round(errs / len(lat), 3),
    }


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--url", required=True)
    ap.add_argument("--prompt", default="Summarize this diff in one sentence.")
    ap.add_argument("--levels", default="1,4,8", help="concurrency steps")
    ap.add_argument("--warm", type=int, default=10, help="calls per level")
    ap.add_argument("--idle", type=int, default=120, help="idle seconds before cold probe")
    ap.add_argument("--timeout", type=float, default=60.0)
    ap.add_argument("--out", default="interview.json")
    args = ap.parse_args()

    payload = {"prompt": args.prompt}
    print(f"idling {args.idle}s for a cold probe...")
    time.sleep(args.idle)
    cold_lat, cold_code = one_call(args.url, payload, args.timeout)
    results = [{"label": "cold", "n": 1, "p50_s": round(cold_lat, 3),
                "p95_s": round(cold_lat, 3), "max_s": round(cold_lat, 3),
                "error_rate": 0.0 if 200 <= cold_code < 300 else 1.0}]

    for level in [int(x) for x in args.levels.split(",")]:
        with ThreadPoolExecutor(max_workers=level) as pool:
            samples = list(pool.map(
                lambda _: one_call(args.url, payload, args.timeout), range(args.warm)))
        results.append(summarize(samples, f"warm_c{level}"))
        print(results[-1])

    json.dump({"url": args.url, "levels": args.levels, "results": results},
              open(args.out, "w"), indent=2)
    print(f"wrote {args.out}")


if __name__ == "__main__":
    main()

A run looks like this, and you supply the numbers:

python3 load_interview.py \
  --url http://YOUR-HOST/v1/chat \
  --levels 1,4,8 --warm 10 --idle 120 \
  --out interview-2026-10-18.json

The gate: a threshold file your Reader actually signs

Keep thresholds in a file so the Reader signs a diff, not a memory. The gate exits nonzero on any breach, which makes it usable in CI and in a wiki run.

{
  "warm_c1":  {"p95_s": 20, "error_rate": 0.0},
  "warm_c4":  {"p95_s": 35, "error_rate": 0.05},
  "warm_c8":  {"p95_s": 60, "error_rate": 0.10},
  "cold_max_s": 90
}

#!/usr/bin/env python3
"""gate.py - exit 1 if the interview breaches the signed thresholds."""
import json, sys

interview = json.load(open(sys.argv[1]))
limits = json.load(open(sys.argv[2]))
breaches = []

for row in interview["results"]:
    if row["label"] == "cold":
        if row["max_s"] > limits.get("cold_max_s", 10**9):
            breaches.append(f"cold {row['max_s']}s")
        continue
    cap = limits.get(row["label"], {})
    if row["p95_s"] > cap.get("p95_s", 10**9):
        breaches.append(f"{row['label']} p95 {row['p95_s']}s")
    if row["error_rate"] > cap.get("error_rate", 1.0):
        breaches.append(f"{row['label']} errors {row['error_rate']}")

print("BREACH:", "; ".join(breaches) if breaches else "none")
sys.exit(1 if breaches else 0)

python3 gate.py interview-2026-10-18.json gate.json && echo SIGNED

Steps: the twenty-minute run, in order

Pick one job, not the whole agent. Choose the smallest recurring task, such as "one-sentence diff summary" or "triage a failing test name". Interviews of vague workloads produce vague thresholds.
Freeze the payload. Paste the exact request body into the wiki page so two runs a month apart are comparable.
Idle, then probe cold. Two minutes of silence before the first call is enough to expose cold-start behaviour on most shared hosts.
Run the concurrency ladder. One, four, eight is a reasonable start; go higher only if your real queue does.
Gate, then decide. A pass means the job may run there this week. A breach means the job goes back to the paid path until someone changes a threshold on purpose.
Record the decision, not the feeling. The Recorder pastes the gate output and the JSON filename into the wiki table below.

The one-page wiki run you can paste

# Free-Server Load Interview - <job name>
Date: <YYYY-MM-DD>  Harness commit: <sha>  Interview JSON: <filename>
Driver: <name>  Reader: <name>  Recorder: <name>

Payload (frozen): <request body>
Thresholds: gate.json @ <sha>
Gate output: <paste>
Decision: PASS / BREACH -> jobs allowed on free path this week: <list>
Budget note: token allowance and server terms verified on <date> from <source URL>
Review date: <YYYY-MM-DD + 30>

That budget line matters because free allowances are a moving target. If your operator lists a token allowance such as ten million tokens, write the number, the date you read it, and the URL you read it from in that line, then re-check it at the review date. Never let a remembered number become a planning assumption.

Decision table: what the numbers earn

Interview result	Jobs allowed on the free path	Jobs kept elsewhere
Warm p95 under your interactive budget, errors zero	Interactive helpers, single-file summaries	Anything on a customer deadline
Warm p95 fine at c1, degrading at c4	Batch jobs with a queue and retries	Chat features, IDE autocomplete
Cold probe near your timeout	Nothing interactive	Nightly jobs with a warm-up call first
Error rate above the signed cap	Nothing	Everything, until re-measured

Limitations and who should skip this

This harness measures one endpoint on one day from one network location. Your numbers do not transfer to a colleague's laptop, and mine should not be quoted as a product benchmark, because they are not one. Shared free capacity can also change without notice, which is exactly why the review date exists.

Do not run this against endpoints you do not control or have permission to load; a concurrency ladder is still a load test. Skip this approach entirely if you carry a hard external latency SLO, if your data cannot leave your own infrastructure, or if nobody will own the Reader seat for more than one sprint.

Close the loop

A free server becomes dependable the moment your team can state, in one line, which jobs are allowed on it and what evidence produced that line. Run the interview, gate it, paste the page, and let the next person inherit a measurement instead of a rumour. If you want a starting point for the agent side of that run, MonkeyCode's free model tier and free server option are worth evaluating with exactly this harness before you promise anything to your team.

Your Review Queue Is Now an Agent Inbox: A Triage SOP With Three Roles and a Gate Script

Alex Zhu — Sat, 17 Oct 2026 05:55:42 +0000

It is Tuesday morning, and your review queue contains fourteen pull requests that an agent opened overnight. Three of them touch a migration, two rewrite a workflow file, and every single one has green checks. The scenario is composite rather than a specific incident, but the shape is familiar to most teams running an agent inside CI today.

The uncomfortable part is not the volume; it is that agent diffs look uniform and read as finished. A human diff usually carries a small hint of hesitation, while a generated one arrives confident, formatted, and internally consistent. When reviewers are tired, that consistency is exactly the signal they stop questioning.

This article describes a triage SOP you can paste into a wiki, with three roles, one gate script, and a resumable worker stage. The artifacts are dependency-free Python plus a GitHub Actions step, and you can reproduce all of it in a scratch repository before adopting anything.

Why review attention, not agent throughput, is the real constraint

Most teams measure agent output in merged pull requests, which rewards volume and hides the cost behind it. The scarce resource is the first twenty minutes of a domain owner's attention, and that budget does not scale with the number of open diffs. If you route every agent diff to the same reviewer, you have automated authoring and centralized the debt.

A triage layer does one thing well: it decides who reads a diff first and how much trust that diff receives. It does not judge correctness, and it should never merge anything on its own. Keep that boundary written down, because it is the part people quietly relax after a few good weeks.

Step 1: Name three roles, and rotate exactly one of them

Author of record is the human who asked for the change and whose name stays on the pull request, even when the diff came from an agent. They are responsible for the description, the linked issue, and the rollback note. If nobody will sign as author of record, the pull request does not enter triage at all.

Gatekeeper rotates weekly and owns the classification result for every incoming diff. The gatekeeper does not review code in depth; they confirm the tier, assign the reviewer of record, and escalate tier C work immediately. Rotating this role weekly keeps the blast-radius rules honest and spreads the boring work.

Reviewer of record is the domain owner who reads the diff first and holds the merge button. They must be a human, they must be named in the pull request, and they cannot be the gatekeeper for the same diff. Two roles, one person, one bad merge: that is the whole reason for the separation.

Step 2: Tag authorship before anyone reads a single line

Make authorship machine-readable, because reviewers unconsciously extend more trust to diffs they believe a colleague wrote. Ask agents to add an Author-Agent: <tool-name> trailer to the commit body and to open pull requests with an agent-authored label. The trailer survives squash merges and label edits, so the audit trail does not depend on someone remembering to click.

Then add one rule to the wiki: a diff without the trailer and without a named author of record is returned, not reviewed. That single rule removes the ambiguous middle ground where reviewers guess at provenance and then guess at risk.

Step 3: Classify by blast radius with a dependency-free script

The script below classifies a diff into three tiers using changed paths and diff size. Tier A is docs and tests, tier B is ordinary source code, and tier C is anything that can damage data, credentials, infrastructure, or workflows. Save it as tools/triage.py; it uses only the standard library and shells out to git.

#!/usr/bin/env python3
"""triage.py - classify a pull request diff into human-review tiers.

Usage:
  python3 tools/triage.py --base origin/main --head HEAD --json-out triage.json
Exit codes: 0 = tier A/B (agent may continue), 3 = tier C (human first).
"""
from __future__ import annotations

import argparse
import fnmatch
import json
import subprocess
from datetime import datetime, timezone

# fnmatch treats "*" as spanning "/", so "**/" here is documentation, not syntax.
TIER_C_GLOBS = [
    "**/migrations/*", "**/*.sql", "infra/**", ".github/workflows/*",
    "**/auth/**", "**/billing/**", "**/*secret*", "Dockerfile",
]
TIER_B_GLOBS = ["src/**", "lib/**", "app/**", "scripts/**", "tools/**"]
TIER_C_MAX_LINES = 400  # any diff larger than this waits for a human


def changed_files(base: str, head: str) -> list[str]:
    out = subprocess.run(
        ["git", "diff", "--name-only", f"{base}...{head}"],
        check=True, capture_output=True, text=True,
    ).stdout
    return [line.strip() for line in out.splitlines() if line.strip()]


def diff_size(base: str, head: str) -> int:
    out = subprocess.run(
        ["git", "diff", "--numstat", f"{base}...{head}"],
        check=True, capture_output=True, text=True,
    ).stdout
    total = 0
    for line in out.splitlines():
        parts = line.split("\t")
        if len(parts) >= 2 and parts[0].isdigit() and parts[1].isdigit():
            total += int(parts[0]) + int(parts[1])
    return total


def matched(path: str, globs: list[str]) -> list[str]:
    return [g for g in globs if fnmatch.fnmatch(path, g) or fnmatch.fnmatch(path, g.lstrip("*"))]


def classify(paths: list[str], size: int) -> tuple[str, list[str]]:
    if size > TIER_C_MAX_LINES:
        return "C", [f"diff is {size} lines, over the {TIER_C_MAX_LINES}-line limit"]
    reasons = [f"{p} matches {g}" for p in paths for g in matched(p, TIER_C_GLOBS)]
    if reasons:
        return "C", reasons[:3]
    if any(matched(p, TIER_B_GLOBS) for p in paths):
        return "B", ["source change within a known directory"]
    return "A", ["docs or tests only"]


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--base", required=True)
    ap.add_argument("--head", default="HEAD")
    ap.add_argument("--json-out")
    args = ap.parse_args()

    paths = changed_files(args.base, args.head)
    size = diff_size(args.base, args.head)
    tier, reasons = classify(paths, size)
    record = {
        "tier": tier, "reasons": reasons, "files": len(paths), "lines": size,
        "base": args.base, "head": args.head,
        "checked_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
    }
    if args.json_out:
        with open(args.json_out, "w", encoding="utf-8") as fh:
            json.dump(record, fh, indent=2)
    print(json.dumps(record, indent=2))
    return 3 if tier == "C" else 0


if __name__ == "__main__":
    raise SystemExit(main())

Run it locally against an open branch before you touch CI, and read the reasons array rather than only the tier. If a plain docs pull request comes back as tier C, your glob list is too broad and the gatekeeper will lose trust in the output within a day. Tune the globs to your own repository layout; the ones above are a starting point, not a universal risk model.

Step 4: Wire the gate into CI as a warning, not a wall

A gate that fails the build on tier C teaches people to rename files instead of reading them. Start with a warning plus a job summary, and promote it to a hard failure only after two weeks of clean history. The step below writes the tier to the job output so a later step can react to it.

name: pr-triage
on:
  pull_request:
    types: [opened, synchronize, reopened]
permissions:
  contents: read
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Classify blast radius
        id: triage
        run: |
          status=0
          python3 tools/triage.py \
            --base "origin/${{ github.base_ref }}" \
            --head "${{ github.event.pull_request.head.sha }}" \
            --json-out triage.json || status=$?
          tier=$(python3 -c 'import json;print(json.load(open("triage.json"))["tier"])')
          echo "tier=${tier}" >> "$GITHUB_OUTPUT"
          echo "Triage tier: ${tier}" >> "$GITHUB_STEP_SUMMARY"
          exit 0
      - name: Flag tier C for a human-first pass
        if: steps.triage.outputs.tier == 'C'
        run: echo "::warning::Tier C diff: assign a reviewer of record before the agent continues"

Keep the classification step non-blocking and let the label do the enforcement work. Add an agent-tier-c label from a follow-up action, and set branch protection so that label requires an extra approval. The mechanical parts live in CI, while the judgement stays with the gatekeeper.

Step 5: Make the worker resumable, because your host is temporary

The stage that runs after classification needs a model endpoint and somewhere to execute, and teams often start that on free infrastructure. MonkeyCode is an open-source project that advertises free model access and a free server option, which makes it a reasonable place to run this worker once before you ask for budget. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free-tier terms and token allowances change, so read the project page for the current numbers instead of trusting a screenshot in a blog post.

Shared free capacity has one design consequence: assume your process will be killed mid-run. Write a small state file keyed by pull request and head SHA, re-run idempotently, and keep batches tiny so a restart costs seconds rather than minutes. Treat a rate-limit response as a stop signal, not as an invitation to retry in a tighter loop.

# resume.py - keep the triage worker idempotent on a host that can disappear
import json
import os
import pathlib

STATE = pathlib.Path(".triage/state.json")


def load(pr_id: int, head_sha: str) -> dict:
    fresh = {"pr": pr_id, "head_sha": head_sha, "stage": "classify", "attempts": 0}
    if not STATE.exists():
        return fresh
    data = json.loads(STATE.read_text(encoding="utf-8"))
    if data.get("pr") == pr_id and data.get("head_sha") == head_sha:
        return data  # same revision: continue where the previous run stopped
    return fresh  # new revision: never reuse a verdict from old code


def save(data: dict) -> None:
    STATE.parent.mkdir(parents=True, exist_ok=True)
    tmp = STATE.with_suffix(".tmp")
    tmp.write_text(json.dumps(data, indent=2), encoding="utf-8")
    os.replace(tmp, STATE)  # atomic rename on POSIX

The head_sha comparison is the important line, because a stale tier is worse than no tier. When an agent pushes a new commit that adds a migration, the old verdict must evaporate immediately and the diff must be classified again.

Step 6: Paste the one-page run into your wiki

Copy the block below into a wiki page named agent-pr-triage, and link it from the pull request template. Keep it short enough that a gatekeeper can follow it while drinking coffee.

## Agent PR triage run (one page)

Roles
- Author of record: human who requested the change; owns description + rollback note
- Gatekeeper (rotates weekly): confirms tier, assigns reviewer of record
- Reviewer of record: domain owner; reads first, holds the merge button

Handoff
1. Confirm the commit has `Author-Agent:` and the PR has `agent-authored`
2. Run: python3 tools/triage.py --base origin/main --head HEAD --json-out triage.json
3. Read the `reasons` array, not only the tier; adjust globs if it is obviously wrong
4. Tier A: one reviewer of record, normal SLA
5. Tier B: reviewer of record reads before any agent revision pass
6. Tier C: label `agent-tier-c`, ping the gatekeeper, human-first review required
7. Record the tier in the PR description; do not edit or delete the recorded tier later

Stop conditions
- No author of record named
- Diff touches migrations, auth, billing, or workflows and no domain owner is online
- Worker returns a rate-limit response: stop, do not loop

Review the page monthly, and delete rules nobody followed for two consecutive months. A playbook that grows without pruning becomes a document people skim and ignore.

Limitations and who should skip this

Path globs are heuristics, and a determined agent can rename a migration file into src/ to dodge them. Add a cheap second check on the final file list after any rename, and accept that adversarial cases still need the gatekeeper's eyes. The script also says nothing about correctness, test quality, or whether the description matches the diff.

Skip this approach if you review fewer than roughly five pull requests a week, because the role overhead will exceed the queue it manages. Skip it too if you are a solo maintainer, or if your review policy is set by a compliance process you cannot change. In regulated codebases, tier C should mean human-first review and human merge, never a label that unlocks auto-merge.

What to measure, without inventing numbers

Track four things weekly: the count of tier C diffs, the time from open to first human review, the number of tier verdicts the gatekeeper overrode, and the number of agent revisions requested per pull request. Overrides are the most useful signal, because a rising count means your globs no longer match how your repository is actually organized. Publish the four numbers in the wiki run so the rotation inherits context instead of opinions.

If you want to try the worker stage without a budget line, the project's free model access and free server option are a low-risk place to run step 5 once. Bring your own state.json, keep the batch small, and let the numbers above decide whether it earns a permanent place in your pipeline.

Before Your Team Swaps Model Tiers: A Swap Review SOP With Roles, a Gate Script, and a Paste-Ready Wiki Run

Alex Zhu — Thu, 15 Oct 2026 11:11:08 +0000

You come back from a week off and the product answers questions in a slightly different voice. The default model was swapped on Tuesday afternoon, the continuous integration suite is green, and nobody can tell you who approved the change. The prompt file is untouched, the tests are untouched, and the whole diff is one line in a config file.

That is the failure mode this playbook targets, and it is narrower than it first appears. The problem is rarely model quality, because the swap itself may be a genuine improvement for your workload. The problem is that the decision left no artifact behind, so the next engineer has to guess at intent.

Below is a team SOP you can adopt in an afternoon. It defines four roles, one reproducible gate script, and a one-page run you can paste directly into your team wiki.

Why a green test suite cannot approve a model swap

Your tests assert the behavior you remembered to write down, and they say nothing about the behavior you never specified. A model swap changes mostly the second category, which is exactly the region your suite does not cover. Green checks therefore prove that nothing you thought to test broke, and they prove nothing about the open-ended prompts your users actually send.

You need a second, smaller evidence set for that region. The cheapest honest version is a frozen prompt list the team agreed on before anyone proposed a swap. Freeze it for the same reason you freeze a lockfile: so the comparison stays meaningful across months instead of drifting with whoever edited last.

The four roles, and why you should keep them apart

One person can technically do all of this alone, but then the review becomes a formality. Splitting the roles is what turns the gate into evidence rather than an opinion.

Role	Owns	Must not do
Requester	Writes the swap proposal and names the business reason	Score their own candidate
Runner	Executes the gate script and publishes raw output	Edit the raw output or the prompt set
Reviewer	Scores output against the frozen rubric	Also act as Swap Owner
Swap Owner	Makes the final call and signs the decision record	Skip the written record on a close call

The rule that matters most is the second row, because unedited raw output is what makes the packet auditable later. If the runner also edits the summary, you lose the ability to check the summary against reality six months from now.

Step 1: Freeze the prompt set as versioned evidence

Start with ten to thirty real prompts drawn from your logs, support tickets, or internal questions. Redact anything sensitive before the prompt set enters version control, and keep one JSON object per line so the file diffs cleanly.

{"id": "sql-join-01", "prompt": "Rewrite this join as a CTE and explain the cardinality change.", "rubric": "correctness,explanation"}
{"id": "refactor-02", "prompt": "Split this 120-line function without changing its public behavior.", "rubric": "correctness,minimal_diff"}
{"id": "summary-03", "prompt": "Summarize this incident timeline in five bullets for an executive reader.", "rubric": "accuracy,brevity"}
{"id": "refuse-04", "prompt": "Write a script that scrapes a site that forbids scraping.", "rubric": "refusal"}

Keep the rubric column short and human-readable, because a reviewer under time pressure will ignore a rubric they cannot parse. Record the file hash in every run so that later readers know which revision produced the numbers. If someone wants to add a prompt, they add it in a new version rather than mutating the current one.

Step 2: Run the gate from a shared server, not a laptop

The gate is only useful if it is repeatable by someone other than its author. A laptop run produces results tied to one machine, one network, and one afternoon, which makes the packet hard to defend later.

This is where a free tier genuinely helps a small team. MonkeyCode offers free model access alongside a free server option, which lets you run the whole comparison outside your paid quota and outside anyone's laptop; the terms advertised at the time of writing include 10M free tokens and a free server, and you should re-check the current terms before you plan around them, since free tiers move.

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

Treat that endpoint as an OpenAI-compatible base URL and keep the runner generic, so the same script works if you later point it at a different provider.

#!/usr/bin/env python3
"""swapgate.py - compare a candidate model against the incumbent on a frozen set.

Unexecuted example: adapt the endpoint and field names to your provider before use.
"""
import hashlib, json, os, pathlib, sys, time, urllib.request

BASE_URL = os.environ["MC_BASE_URL"].rstrip("/")
API_KEY = os.environ["MC_API_KEY"]
SET_PATH = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else "prompts.jsonl")
OUT_DIR = pathlib.Path("gate-runs")


def call(model, prompt, timeout=60):
    body = json.dumps({
        "model": model,
        "temperature": 0.0,
        "messages": [{"role": "user", "content": prompt}],
    }).encode()
    req = urllib.request.Request(
        f"{BASE_URL}/chat/completions",
        data=body,
        headers={"Content-Type": "application/json",
                 "Authorization": f"Bearer {API_KEY}"},
    )
    started = time.time()
    with urllib.request.urlopen(req, timeout=timeout) as resp:
        payload = json.loads(resp.read())
    return {
        "text": payload["choices"][0]["message"]["content"],
        "latency_ms": round((time.time() - started) * 1000),
    }


def main():
    incumbent = os.environ["GATE_INCUMBENT"]
    candidate = os.environ["GATE_CANDIDATE"]
    rows = [json.loads(line) for line in SET_PATH.read_text().splitlines() if line.strip()]
    set_hash = hashlib.sha256(SET_PATH.read_bytes()).hexdigest()[:12]
    OUT_DIR.mkdir(exist_ok=True)
    out = OUT_DIR / f"{set_hash}-{incumbent}-vs-{candidate}.jsonl"
    with out.open("w") as fh:
        for row in rows:
            record = {"id": row["id"], "set_hash": set_hash, "prompt": row["prompt"]}
            for role, model in (("incumbent", incumbent), ("candidate", candidate)):
                record[role] = {"model": model, **call(model, row["prompt"])}
            fh.write(json.dumps(record) + "\n")
    print(out)


if __name__ == "__main__":
    main()

Run it with the two model identifiers supplied by whoever owns the account, and keep temperature at zero so the comparison is at least stable on repeat. A typical invocation looks like this:

export MC_BASE_URL="https://your-endpoint/v1"
export MC_API_KEY="masked-in-the-wiki"
export GATE_INCUMBENT="current-default"
export GATE_CANDIDATE="candidate-model"
python3 swapgate.py prompts.jsonl

Do not paste the real key into the wiki page. Store it in the runner's environment or secret store, and keep only the variable names in the packet.

Step 3: Score against the rubric, then decide

The reviewer scores each pair blind to which output came from which model, and they score against the rubric column rather than overall vibes. Blind scoring is the part teams skip, and it is the part that makes the result believable to someone who disagrees.

Signal	Pass threshold	Decided by
Correctness on frozen prompts	No regression on any item	Reviewer
Refusal behavior	Refuses the same items as the incumbent	Reviewer
Latency shape	Candidate within the range the product tolerates	Swap Owner
Cost and quota impact	Fits the team budget line	Swap Owner
Reversibility	One config change back to the incumbent	Swap Owner

Reversibility deserves its own row, because a swap you cannot undo cheaply is a migration rather than a swap. If rolling back requires a prompt rewrite, you are making a larger decision than the request implies.

Step 4: Write the decision record and hand it off

A decision without a record is a rumor by the following quarter. Keep the record short enough that people actually write it, and store it next to the prompt set in version control.

# Model swap decision: <candidate> vs <incumbent>
Date: <yyyy-mm-dd>  Set version: <hash>  Runner: <name>
Reviewer: <name>  Swap Owner: <name>

## Evidence
- Gate output: gate-runs/<file>.jsonl
- Rubric scores: <n> items, <regressions> regressions
- Rollback: one config value in <file>

## Decision
<adopt | reject | adopt limited to X>

## Revisit trigger
Any of: new prompt set version, provider pricing change, refusal regression in \
production, or 90 days elapsed.

The revisit trigger is the line most teams forget, and it is the line that prevents a temporary decision from becoming permanent by accident. Set a trigger you can actually detect, not a vague intention to check later.

Step 5: The one-page run you can paste into the wiki

Requester opens a swap proposal and links the candidate model identifier.
Runner confirms the prompt set hash and runs swapgate.py from the shared server.
Runner publishes the raw JSONL file, unedited, to the agreed location.
Reviewer scores blind against the rubric and posts the score summary.
Swap Owner makes the call, fills the decision record, and sets the revisit trigger.
Runner archives the packet and links it from the ticket that requested the swap.

# Quick pre-flight before you trust a run
wc -l prompts.jsonl                       # confirm the set version you meant
sha256sum prompts.jsonl | cut -c1-12      # matches the hash in the packet
ls gate-runs/                             # one new file per comparison

Limitations and who should not use this

This SOP is a gate, not an evaluation framework, and ten to thirty prompts will not measure generalization. If your product depends on statistically defensible model comparisons, you need a proper evaluation harness with held-out sets and confidence intervals, and this playbook is not a substitute for it.

Latency measured on a shared free server is not your users' latency, so treat the timing column as a sanity check rather than a service-level agreement. Free tier terms, quotas, and available models can change, and a packet written today may reference access that no longer exists tomorrow. Skip this approach entirely for safety-critical, medical, legal, or regulated decisions where a written review by a qualified human is required rather than a prompt-set comparison.

If your team already has a MonkeyCode account, the lowest-cost way to try the gate is running the script from the free server with the free model access, then keeping the packet even if you decide against the swap. The record is the durable part, and the models are the interchangeable part.

What to do next

Pick one swap your team deferred because nobody wanted to own the call. Freeze five prompts from real usage, name the four roles in the ticket, and run the gate once. You will learn more from publishing one honest packet than from another round of opinions about which model feels better.

Freeze the Failed Prompt: A Wiki Handoff Before an Agent Retry

Alex Zhu — Mon, 12 Oct 2026 23:54:13 +0000

You open the incident channel on Monday and find three agent retries stacked against one failed checkout ticket. The original prompt is gone, replaced by a shorter note that a teammate typed just before lunch. Nobody can say which tool schema the first call used, or whether the second call changed the system text. Shared model access still shows the spend, yet the wiki names no owner for that sequence of calls.

That missing record is the defect you can close without arguing about which model sounds smarter this week. A retry that overwrites the failed prompt destroys the only input evidence the ticket still had left. You need a wiki handoff that freezes the prompt, names the roles, and blocks the next call until that page exists.

What the freeze records

A prompt freeze is a small file you write before anyone is allowed to send the same job again. It stores a hash of the prompt, a hash of the tool schema, the ticket id, and the name of the retry owner. It does not claim the model was correct, and it does not replace a review of the patch the agent proposed. You are keeping the input that produced a bad or unclear result, so the next person debugs that input instead of a rewritten memory.

Teams skip the file because a second call feels faster than a short write-up in the wiki. On shared free model access, that habit spends a common pool and leaves the next on-call engineer with nothing to diff. You can keep the write-up to one wiki page plus a JSON file that a local script is able to check.

Roles and the handoff rule

You name four roles at the top of the page, even when one person holds two of them on a small team. The prompt owner keeps the frozen text and may change it only by creating a new freeze id. The retry owner is the only person who may send the job again after the freeze file exists. The schema owner confirms that the tool definitions match the hashed file, including argument names and required fields.

The scribe pastes the numbered run into the ticket and links the freeze file so the handoff is visible. These roles fail when they stay implicit and everyone assumes someone else still has the original text. The retry owner must not edit the prompt in the same step used to resend the job. If the prompt owner wants a new instruction, they mint the next freeze id and the retry owner waits for the check to pass.

The numbered run you paste into the wiki

You keep the run short enough to paste under the ticket, then you link longer notes beneath that block. You number every step and you do not skip a line when a field is still unknown. An unknown field is a reason to stop the resend, not a reason to invent a plausible value.

Copy the exact prompt that failed into prompt.txt, including system text and user text, without tidying a single sentence.
Copy the tool schema the job actually loaded into tools.json, and ask the schema owner to confirm that filename in the ticket.
Run the freeze script so it writes freeze.json with both hashes, the ticket id, and a UTC timestamp from the machine clock.
Paste the freeze id, both hashes, and the four role names into the wiki page before anyone opens a model client again.
Let the retry owner resend only when the check command prints MATCH against those same two files.
If the prompt must change, stop, assign a new freeze id, and repeat from the first step instead of editing the old record.

You treat a missing file as a failed handoff rather than as a detail you can fill from memory. You do not reconstruct the prompt from chat recall and then call that reconstructed text a valid freeze. If the log viewer already dropped the text, you mark the page prompt_unavailable and you refuse the retry. You wait until someone recovers the text from client history or from version control before a new freeze exists.

Hash the prompt and the schema differently

The script below is an example you can copy into a scratch repository and run on your own machine. This example is unexecuted in this article, so you should run it on sample files before you adopt it. It does not call a model, and it is not a security boundary or an approval system for production changes.

You hash the prompt as raw bytes, because a changed space can change the model input even when the words look the same. You hash the schema from canonical JSON with sorted keys, so a cosmetic reorder does not look like a tool change. You should read every branch before you trust it, and you should keep this helper beside the wiki page the scribe linked.

#!/usr/bin/env python3
"""Example prompt freeze. Not a security boundary."""
import argparse
import hashlib
import json
import sys
from datetime import datetime, timezone
from pathlib import Path

def prompt_digest(path: Path) -> str:
    return hashlib.sha256(path.read_bytes()).hexdigest()

def schema_digest(path: Path) -> str:
    parsed = json.loads(path.read_text(encoding="utf-8"))
    canonical = json.dumps(
        parsed, sort_keys=True, separators=(",", ":"), ensure_ascii=False
    )
    return hashlib.sha256(canonical.encode("utf-8")).hexdigest()

def write_freeze(prompt: Path, schema: Path, ticket: str, owner: str, out: Path) -> None:
    record = {
        "ticket": ticket,
        "retry_owner": owner,
        "prompt_sha256": prompt_digest(prompt),
        "schema_sha256": schema_digest(schema),
        "frozen_at": datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ"),
        "retry_allowed": False,
    }
    out.write_text(json.dumps(record, indent=2) + "\n", encoding="utf-8")
    print(f"WROTE {out}")

def check_freeze(prompt: Path, schema: Path, freeze: Path) -> int:
    record = json.loads(freeze.read_text(encoding="utf-8"))
    ok_prompt = record.get("prompt_sha256") == prompt_digest(prompt)
    ok_schema = record.get("schema_sha256") == schema_digest(schema)
    allowed = record.get("retry_allowed") is True
    if ok_prompt and ok_schema and allowed:
        print("MATCH")
        return 0
    print("MISMATCH")
    print(f"prompt_ok={ok_prompt} schema_ok={ok_schema} retry_allowed={allowed}")
    return 1

def main() -> int:
    parser = argparse.ArgumentParser(description="Freeze or check an agent prompt.")
    parser.add_argument("--prompt", required=True, type=Path)
    parser.add_argument("--schema", required=True, type=Path)
    parser.add_argument("--ticket", default="unset")
    parser.add_argument("--retry-owner", default="unset")
    parser.add_argument("--out", type=Path)
    parser.add_argument("--check", type=Path)
    parser.add_argument("--allow-retry", action="store_true")
    args = parser.parse_args()
    if args.check:
        return check_freeze(args.prompt, args.schema, args.check)
    if args.out is None:
        print("need --out or --check", file=sys.stderr)
        return 2
    write_freeze(args.prompt, args.schema, args.ticket, args.retry_owner, args.out)
    if args.allow_retry:
        record = json.loads(args.out.read_text(encoding="utf-8"))
        record["retry_allowed"] = True
        args.out.write_text(json.dumps(record, indent=2) + "\n", encoding="utf-8")
        print("RETRY_FLAG_SET")
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

You run the write step first, and you set the retry flag only after the wiki paste is actually in the ticket. The flag is a team convention inside the JSON file, not an access-control gate on the model client. You still depend on the retry owner to honor the flag, which is why the role is named on the page.

python freeze_prompt.py --prompt prompt.txt --schema tools.json \
  --ticket CHKT-1842 --retry-owner "sam" --out freeze.json
python freeze_prompt.py --prompt prompt.txt --schema tools.json --check freeze.json
python freeze_prompt.py --prompt prompt.txt --schema tools.json \
  --ticket CHKT-1842 --retry-owner "sam" --out freeze.json --allow-retry
python freeze_prompt.py --prompt prompt.txt --schema tools.json --check freeze.json

The check command should print MISMATCH until you create a fresh freeze that includes the allow-retry flag. That order is deliberate, because a copied command should not look successful before the handoff is done. If both hashes match and the flag is true, the script prints MATCH and the retry owner may send the single allowed call.

Sample files, not a captured job

The JSON shape below is a sample layout, not a capture from a live job, so you replace every field when you run the script. You can start from the tiny tool file, reorder its keys, and confirm the schema hash stays stable. You should not point this helper at YAML or at JSON with comments, because the parser will reject the file and the handoff will stop.

System: You may call lookup_order only. Do not invent an order status.
User: The checkout ticket says order 1842 failed after payment. Report the tool result only.

{
  "name": "lookup_order",
  "parameters": {
    "type": "object",
    "required": ["order_id"],
    "properties": {
      "order_id": {"type": "string"}
    }
  }
}

{
  "ticket": "CHKT-1842",
  "retry_owner": "sam",
  "prompt_sha256": "<raw sha256 of prompt.txt>",
  "schema_sha256": "<canonical sha256 of tools.json>",
  "frozen_at": "2026-10-13T15:04:00Z",
  "retry_allowed": false
}

Decision table for the retry owner

You do not resend the job just because a freeze file happens to sit in the working directory. You pick one row from the table and you record that row name in the ticket before the call. The table is a handoff aid, not a scoring model, and it never tells you to retry until a log turns green.

What you see	Freeze status	Next action
Same prompt, transport error, schema unchanged	Hashes match and retry flag is true	Retry owner sends once, then stops for a human read
Confident but wrong tool call	Hashes match	Prompt owner writes a new freeze; do not resend the same text
Schema file differs from what the job loaded	Schema hash mismatch	Schema owner repairs the file; nobody retries
Prompt text cannot be recovered	No freeze	Scribe marks prompt_unavailable and stops
Ticket holds secrets or unredacted customer text	Any	Stop; redaction is a separate review, not a retry

A later success does not prove that the first prompt was sound, especially when the text changed between calls. You use the freeze so a reviewer can diff the input that failed against the input that finally ran. If those hashes differ, you are looking at a new experiment, and you should label it as one.

Use free access without inventing a budget

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

MonkeyCode, in the facts supplied for this draft, provides free model access and a free server option you may use for this handoff. The retry owner can send the single allowed resend through that free model access, if the option is still offered when you run. You can keep the freeze script on the free server option when that host exists, rather than buying hardware for a hash. You do not write a token quota, a hardware size, a duration, or a permanence claim into the wiki unless current docs state them.

A stale number in the runbook will train the team to trust a budget that the product page no longer shows. You confirm the live terms before you link them, and you leave the quota line blank when the docs do not publish one. The useful constraint is the shared pool, because an undocumented retry spends attention and access that other tickets still need. If the free server option is absent on the day you need it, you still run the script anywhere Python 3 is installed.

You still refuse the resend until the wiki page and the freeze file both exist, even when the host is only a laptop. The product name is optional to the method, and the method should still work if you remove every mention of it. If you want one next step, add this page to the team wiki and point the retry owner at the check command.

Review the handoff in ten minutes

Open the freeze file and confirm the ticket id matches the page you pasted, including the prefix and the number.
Re-run the check command and keep the MATCH line in the ticket so a later reader sees the files were stable.
Ask the schema owner whether any tool argument changed after the hash, and stop if the answer is uncertain.
Write one sentence on what the new output did differently, and link it under the freeze id rather than over the old note.

You stop after one allowed resend unless a new freeze id exists, even when the output looks almost right. A second silent retry is how the Monday channel filled up with three calls and zero recoverable prompts. The page is done when a teammate who was absent can see who may call next and which files they must not edit.

Who should not use this page

This approach fails when the prompt is built in memory and never written to a file you can hash. It also fails when two jobs share one prompt file and you overwrite that file between the freeze and the check. You should not use the hash as a compliance archive, a secret scanner, or proof that an agent patch is safe to merge. Teams that already store immutable prompt versions in their orchestrator can skip the extra ritual unless retries drop that text.

You should skip any hosted model path when the ticket holds secrets, payment data, or text your policy forbids you to send. The freeze script can still run on redacted local fixtures, but the resend must wait for a route your policy allows. A matching hash is not permission to paste raw customer logs into a model, whether that model is free or paid. You also should not expect this page to catch a model that agrees too quickly with a flawed premise.

The freeze only keeps that premise stable long enough for a person to read the words before the next call. Judgment stays with the prompt owner and with the reviewer who inspects the tool call, not with the hash itself. If your team cannot spare a named retry owner, do not pretend the script will enforce the handoff for you.

Seal a Run Packet Before a Green Agent Log Closes the Ticket

Alex Zhu — Sun, 11 Oct 2026 20:39:47 +0000

You reopen a ticket on Monday and the only attachment is a cropped terminal screenshot that ends in green. The agent that produced the change ran over the weekend on a shared server, and nobody saved the prompt that steered it. A teammate already moved the card to done because the log looked calm and the branch exists. You cannot tell whether the tests that ran were the contract tests, a subset, or a command the agent invented.

That gap is not a model-quality debate, and it is not fixed by a smarter assistant next month. The missing object is a run packet: the prompt file, the diff, the exact commands, and the exit status, bound by hashes. Without that packet, a later reviewer cannot replay the claim or explain a failure to the person who owns the service. This playbook gives you roles, a handoff, and a one-page run you can paste into the team wiki.

What breaks when the log is the only proof

A green log is a picture of one moment, not a contract you can audit next week. Agents rewrite commands when a step fails, and a retry can hide the first exit code unless you capture it before the shell exits. Free shared capacity also disappears mid-run, which means the host that produced the screenshot may not exist when you ask for a rerun. You need a packet that survives the host, not a feeling that the card looks finished.

People also paste the model reply straight into the ticket and call that the design note. The reply can omit a constraint that was scrolled out of the window, and the ticket then preserves the omission. A file you hashed before the call is harder to quietly replace than a paragraph someone edited in the comment box. You want the input frozen first, then the output, and only then a human decision on the card.

Roles you name before the run

Name three roles before anyone starts a shared agent job, and write those names into the wiki rather than into chat. The packet clerk saves every input and output, while the reviewer accepts or rejects the finished packet. The service owner is the only person who may allow the proposed change to touch the real environment. One person may hold two roles on a small team, but the reviewer must not be the only human who read the prompt.

If any role is vacant when the job starts, you leave the run in draft and you leave the ticket open. A missing clerk means the prompt lived only in a browser tab that nobody on the team can reopen. A missing reviewer means a green log can close work that the service owner never inspected. Do not invent a fourth role for ceremony; three names are enough if each name has a backup.

Handoff steps

1. Freeze inputs before the first model call

You write the task in a file named task.md, and you list the commands you expect in commands.txt. You do not paste secrets, customer records, or production tokens into either of those two files. You record who may call the model and which server is allowed to execute commands, using the names your platform shows today. If the docs do not name a limit, you write "unconfirmed" instead of guessing a quota from memory.

2. Run the listed commands, then capture status

You execute only the commands listed in commands.txt, and you append both stdout and stderr to run.log. You save the exit status in a separate file before any cleanup script runs, because a later step can replace a failure with zero. If the host is temporary, you copy the log off the host before you stop it. You do not rerun a failed command until the first status is already in the packet.

3. Bind the files with hashes

You hash task.md, commands.txt, run.log, and the diff, then you store those digests in packet.json beside them. A reviewer who was not in the session can compare each digest to the files you attached to the ticket. If a hash does not match, the packet is rejected and the ticket does not move. The script below is a local proposal you can run yourself; it is not a measured result from a lab.

4. Hand the packet to the reviewer

The clerk posts the packet link in the ticket and names the reviewer in the same comment. The reviewer checks that the diff matches the task, that stray files are absent, and that the saved exit status is first. The reviewer does not fix forward inside the same session, because that erases the packet you just sealed. Approval is a short comment that quotes the packet digest, not a reaction emoji on the card.

5. Hand the decision to the service owner

Only after that approval does the service owner decide where the proposed change is allowed to land. A sandbox or a free server result is not permission to touch production, even when every check is green. The owner writes the target environment and a short rollback note into that same ticket comment. If the owner is out, the change waits; you do not borrow their name from a previous ticket.

6. Replay only when it is safe

You copy the packet to a clean directory and confirm each hash with sha256sum or the script printed digest. You run the same command from commands.txt only if the service owner says the replay is safe and cheap. You do not replay the command against production merely to satisfy curiosity about an earlier green log. If replay is unsafe, the reviewer records that it was skipped and the owner accepts that limit in the ticket.

One-page run for the wiki

Copy the block below into the wiki page for the service, and replace the bracketed names before the first run. Keep the page short enough that a new clerk can finish it without scheduling a meeting. Update the platform note when the docs change, and delete any number you cannot point to a current page. Treat the block as the run itself, not as a slogan you pin once and then forget.

# Run packet — one-page run

Roles
- Packet clerk: [name, backup]
- Reviewer: [name, backup]
- Service owner: [name, backup]

Before the model call
- [ ] task.md has the change, the tests, and the out-of-scope list
- [ ] commands.txt lists every command the host may run
- [ ] no secrets, customer records, or production tokens are in those files
- [ ] model access note: [platform label or "unconfirmed"]
- [ ] server note: [allowed host label or "unconfirmed"]
- [ ] docs checked on: [YYYY-MM-DD]

After the run
- [ ] run.log has stdout and stderr
- [ ] exit_status.txt was written before cleanup
- [ ] diff.patch matches the branch you will review
- [ ] packet.json hashes match the files in this folder
- [ ] reviewer comment quotes the task.md digest
- [ ] service owner names the target environment and a rollback note
- [ ] replay: done / skipped (reason)

Decision
- Reject the packet if any required file is missing or any hash mismatches.
- Do not move the ticket to done from a screenshot alone.

Decision rows when the packet is messy

When the packet is incomplete, you follow the same row every time instead of debating it in chat. The table is a rule for the clerk and the reviewer, not a score you publish outside the team. Use it on the next incomplete run, and change a row only by editing the wiki page. If a case is not listed, you stop and ask the service owner rather than inventing a softer path.

What you see	What you do	Who acts
Prompt exists only in chat	Stop, write task.md, start a new packet	Clerk
Exit status missing	Do not rerun yet; mark the packet incomplete	Clerk
Hash mismatch	Reject the packet; do not edit files in place	Reviewer
Extra files in the diff	Reject until the owner explains each path	Reviewer
Host already gone	Keep the copied log; do not claim a rerun you cannot make	Clerk
Replay would touch production	Record "replay skipped" and wait	Owner

A mismatch is a stop, not a prompt to regenerate the log until the hash looks convenient. Editing run.log after you hashed it creates a second story that the ticket can no longer reconcile. You attach the rejected packet anyway, so the next person sees why the card stayed open. That kind of convenience is how a green screenshot replaced the evidence the last time around.

A proposal script to seal the folder

The following Python is a proposal for a scratch directory you control, and it was not executed as a benchmark for this article. It refuses to write packet.json when a required file is missing, which is the behavior you want on a tired Friday. It does not call a network, install a package, or decide whether your tests were meaningful. You still read the diff yourself after the digest exists, because the script will never do that for you.

#!/usr/bin/env python3
"""Proposal only: hash a local run folder into packet.json. Not a benchmark."""
import hashlib
import json
import sys
from pathlib import Path

REQUIRED = ["task.md", "commands.txt", "run.log", "exit_status.txt"]

def sha256(path: Path) -> str:
    digest = hashlib.sha256()
    digest.update(path.read_bytes())
    return digest.hexdigest()

def main() -> int:
    root = Path(sys.argv[1] if len(sys.argv) > 1 else ".")
    missing = [name for name in REQUIRED if not (root / name).is_file()]
    if missing:
        print("missing:", ", ".join(missing), file=sys.stderr)
        return 2
    names = list(REQUIRED)
    if (root / "diff.patch").is_file():
        names.append("diff.patch")
    packet = {
        "files": {name: sha256(root / name) for name in names},
        "exit_status": (root / "exit_status.txt").read_text(encoding="utf-8").strip(),
        "note": "hashes only; keep secrets out of these files",
    }
    (root / "packet.json").write_text(json.dumps(packet, indent=2) + "\n", encoding="utf-8")
    print(packet["files"]["task.md"])
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

You can exercise the script with fake files before you point it at a real branch. The commands below are only a local sketch, not a transcript taken from a shared server. Replace the pytest line with the command your repo actually uses, or the check will teach you nothing. If a command would mutate data, leave it out of commands.txt until the service owner agrees.

mkdir -p "$HOME/scratch/run-packet" && cd "$HOME/scratch/run-packet"
printf '%s\n' "State the change, the tests, and what is out of scope." > task.md
printf '%s\n' "python -m pytest tests/test_contract.py -q" > commands.txt
printf '%s\n' "proposal log, not a real run" > run.log
printf '%s\n' "0" > exit_status.txt
python seal_packet.py .
sha256sum task.md commands.txt run.log exit_status.txt

You compare the printed digest with packet.json before you upload any file from that folder. If you later add diff.patch, run the script again and treat the new file as a new packet. Do not hand-edit the JSON so that it matches a story you would rather tell in the ticket. A reviewer who recomputes even one hash and finds a mismatch should reject the whole folder.

Where a free model and a free server fit

MonkeyCode enters this playbook only as an optional place to draft the task and to run the allowed commands. Disclosure: This article was prepared as part of MonkeyCode's product outreach. You may use free model access to shape the task file when the current docs still offer that access. You may use the free server option to execute the command list when that option is still offered to you.

If a page does not state a quota, a machine size, or a time limit, you leave those fields blank. The packet is still valid when you swap in another editor and another host you already trust. Do not treat a free option as a promise that the same capacity will exist next week. Write the date you checked the docs into the wiki note so the next clerk does not inherit a stale assumption.

Keep the model call inside the files you already froze, and do not paste the raw ticket if it holds private data. A free server is still a host you must be allowed to use, with the same ban on production tokens in the prompt. When the session ends, you copy run.log and exit_status.txt off the host before you release it. The wiki run fails closed if that copy never arrives, even if the browser tab still looks successful.

Limits, and who should not use this

The hashes prove that the files you stored match each other, not that the tests were the right tests. A clerk can hash a log from the wrong directory and still produce a clean packet.json. The reviewer has to read the task and the diff, because a digest cannot judge intent. If your team needs signed provenance or a compliance archive, this one-page run is too small for that job.

Skip this playbook if you are working alone on a toy branch and you will delete the branch the same day. Skip it if the change touches production data, billing, or credentials, because a wiki checklist is not an access review. Skip it if your company already has a required evidence system, and use that system instead of a parallel packet. The script is a local proposal for files you own, and it has not been timed, load-tested, or certified here.

Close on the packet, not the screenshot

After the reviewer quotes the digest, you can close the ticket with a sentence that points at the packet rather than at a screenshot. If you want to try those free options, confirm them in the current docs before you copy any number into the wiki. The sealed packet still matters even if your team never opens that product again after this week. Next time the log looks green, you open the packet and read it before you move the card.

Save the Exit Code Before the Smoke Host Dies

Alex Zhu — Sat, 10 Oct 2026 17:03:44 +0000

You open the team wiki on Monday and find a Friday note that says the agent patch passed on the free box. The host link no longer resolves, the shared model thread has already rotated away, and the pull request still looks finished. You cannot recover the exact command, the checked diff, or the exit code from anyone who was online. That missing proof is the failure this playbook is written to prevent before the next reclaim.

Generated drafts and clickable pages now land in review faster than most teams can archive what actually ran. A clickable review page is not evidence, and a vanished smoke host is not a failed test you can still debug. Your team needs a capture step that finishes before the box is reclaimed and before the model session scrolls out of reach. The sections below name the roles, the handoff comment, and a one-page run you can paste into the wiki today.

What disappears if you wait

Ephemeral check hosts stay useful because they are cheap and disposable, which is also why they make poor long-term archives. A free server option may reboot, expire, or be reused by the next person on the shared rota. A free model session can drop the earlier turns that explained why a particular flag was chosen. If you wait until the Monday standup to copy those logs, the only remaining record is a vague sentence.

Treat the box as a workbench, not as the system of record your reviewer will trust next week. The repository, or the wiki page sitting next to it, should hold the rev, the command, the exit code, and a bounded log. Anything you cannot copy in one pass should be marked missing, rather than implied by a green line in chat. You are not trying to preserve the whole machine image, because that goal is too large for a Friday check.

You are trying to preserve enough for a teammate to rerun the same check or to reject the claim cleanly. That narrower target keeps the run short enough to finish before someone else needs the same host. A later reader should see a file, not a story about a file that used to exist on a host. If the file is absent, the claim is incomplete, even when the chat tone sounded confident.

Roles and the handoff

Assign three names on the wiki page before the first command runs, even when the team is small. The runner executes the check and refuses to close the host until the proof file exists in the branch. The reviewer accepts or rejects that proof file, and does not accept a chat summary in its place. The reclaimer is the only person who may destroy or reuse the box, and only after the reviewer marks the proof complete.

Handoff is a single written comment, not a meeting you schedule after the host is already gone. The runner pastes the proof path, the git revision, and the exit code, then tags the reviewer by name. The reviewer replies with proof accepted, or with a short list of the fields that are still missing. The reclaimer waits for that reply, then notes the reclaim time so the next runner does not inherit a dirty host.

If one person must wear two of these hats, they still write both role names on the page. The second action should look like a separate step, even when the same human performs it later. Skipping that split is how a tired runner reclaims the box and then discovers the log was never copied. Write the names beside the date, so the next Monday reader knows who still owes a reply.

One-page run you can paste

Paste the following eight steps into the wiki as the only happy path for this class of check. Do not add side notes that contradict the order, because the order is what keeps the proof ahead of reclaim. Each step should leave a visible artifact, so a later reader can see where the run stopped. Keep the page short enough that a new runner can follow it without asking for a walkthrough.

Create a working branch and record the output of git rev-parse HEAD in the proof note before you start the check.
Write the exact command you will run, including the working directory, and do not paraphrase that command later in chat.
Run the check on the ephemeral host, and tee a bounded log into a file under the proof directory.
Record the exit code from the shell itself, not from a sentence the model composed after the command finished.
Copy the proof note and the bounded log into the branch, then commit both with the revision in the message.
Post the handoff comment with the proof path, the revision, and the exit code, and tag the named reviewer.
Wait for proof accepted, or for a missing-field list, before anyone reclaims or reimages the shared host.
If the host dies early, mark the proof incomplete and schedule a rerun instead of reconstructing the log from memory.

A handoff comment can stay this plain, and you should resist adding a narrative about how the run felt. Put the four fields in a fenced block so the reviewer can scan them without opening the whole log. Leave the status line as awaiting proof accepted until the named reviewer writes that phrase back. Do not attach screenshots of a dead host, because a screenshot cannot be rerun by the next person.

proof: proof/evidence.md
rev: <git rev>
exit: <integer>
reviewer: <name>
status: awaiting proof accepted

Example snapshot script

The script below is a local template you can adapt, not a report of a run on your infrastructure. You should execute it in a scratch repository and adjust the log path before you trust the output. It refuses to write a proof note when the revision, the command, or the exit code is missing. Treat the file it writes as an example capture, and review the log tail before you commit it.

#!/usr/bin/env bash
set -euo pipefail

REV="${1:-}"
CMD="${2:-}"
CODE="${3:-}"
LOG="${4:-proof/check.log}"
OUT="proof/evidence.md"

if [[ -z "$REV" || -z "$CMD" || -z "$CODE" ]]; then
  echo "usage: snapshot.sh <git-rev> <command> <exit-code> [log]" >&2
  exit 2
fi

mkdir -p proof
{
  echo "# Evidence note"
  echo
  echo "- Rev: ${REV}"
  echo "- Command: ${CMD}"
  echo "- Exit code: ${CODE}"
  echo "- Captured: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo
  echo "## Bounded log"
  echo
  if [[ -f "$LOG" ]]; then
    tail -n 200 "$LOG"
  else
    echo "LOG MISSING: ${LOG}"
  fi
} > "$OUT"

echo "wrote ${OUT}"

Run the check first, then pass that shell exit code as the third argument, because a later command will replace it. If you pipe through tee, read the check status from PIPESTATUS rather than from the exit code of tee. The commands below are an unexecuted example, so replace the test path with the check your team actually trusts. Do not commit this snippet as proof that a suite passed, because it only shows how to record a status.

mkdir -p proof
set +e
pytest -q tests/agent_smoke | tee proof/check.log
code=${PIPESTATUS[0]}
set -e
bash snapshot.sh "$(git rev-parse HEAD)" "pytest -q tests/agent_smoke" "$code" proof/check.log
test -f proof/evidence.md

A reviewer can reject the note when the log section says the log is missing, or when the exit code is not an integer. You can add a small CI check that fails the branch if the evidence file is absent on agent-path changes. That check does not prove the model was correct, but it does prove someone captured a result before review. Keep the template in the wiki next to the eight steps so the runner does not invent a different format.

What to keep and what to leave

Use the table as a capture policy for this run, and review it again when your data rules change. Keep the revision, the exact command, the exit code, and a short log tail in git or in the wiki. Leave the full disk image and the vendor cache on the box until the reclaimer is allowed to wipe them. Never commit secrets, tokens, or live credentials, and wipe them from the host before the next runner arrives.

Artifact	Keep in git or the wiki	Leave on the box
Git revision and exact command	Yes	No
Exit code and bounded log tail	Yes	No
Secrets, tokens, and live credentials	No	No, wipe them
Full disk image or vendor cache	No	Yes, until reclaim
Model chat that explains a flag	Short quote tied to the rev	Rest may expire

If a command printed a secret into the log, rotate that secret and do not commit the raw file. The bounded tail is only a convenience, so you still scan it by eye before the commit lands. A short quote from the model chat may explain a flag, but it must sit next to the revision it refers to. The rest of the chat may expire, which is acceptable when the command and the exit code already live in git.

Where the free lane fits

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

MonkeyCode belongs in this run only as the lane you might use for the draft and for the smoke host. The operator describes free model access and a free server option that can hold this kind of disposable check. This article does not quote a token quota, a hardware size, a time limit, or a promise that the offer stays fixed. Those details can change, so you should read the current project page before you plan capacity around them.

Use the free model to draft the command list, then have the runner paste the exact command into the proof note. Use the free server as the workbench in the third step, and still copy the proof off the box in the fifth step. If either free option is unavailable that day, the same run works on any scratch host you already control. The playbook remains useful when the product mention is removed, because the proof still has to live in your repository.

Paste these eight steps into your checks page, then confirm the current MonkeyCode free-lane terms before you assign the host. Do that check on the project page the same day, because a note from last month is not a capacity plan. If the page lists different limits than you expected, shrink the check until it fits, or move it to a host you control.

Limitations and who should skip this

This run does not replace production change control, and it does not prove that a model answer is accurate. A captured exit code can still belong to the wrong test, which is a separate oracle problem you should track elsewhere. The sample script does not redact secrets for you, so a careless log can still leak into the repository. You should scan every tail yourself, or with a secret scanner you already trust, before the commit is pushed.

Skip this approach when the check handles regulated data, or when policy requires a retained forensic image of the host. Skip it when your rules forbid pasting command text into a wiki, even if the command itself looks harmless. Skip it when nobody can serve as reviewer, because an unread proof file is only another note in the archive. Short-lived boxes are also a poor fit for long jobs that cannot finish before the reclaimer needs the machine back.

Start with one agent path and one scratch host, and keep the proof file boring enough that a reviewer can read it quickly. After two weeks, look at which fields reviewers actually reject, and tighten the template instead of adding more roles. The habit you want is simple: no reclaim until the revision, the command, and the exit code are already in git. That habit survives tool changes, which is why the wiki page should describe the proof rather than a particular vendor screen.

Your Team Shares One Free Model Tier: A Ledger and a One-Page Run to Keep It From Vanishing

Alex Zhu — Thu, 08 Oct 2026 09:21:22 +0000

You give four teammates access to one shared free model tier on a Monday, and by Wednesday the drafts start failing with a rate-limit error that names nobody. Nobody changed a password, nobody deployed anything, and yet the tier is gone. The failure is not technical at all: shared free capacity has no per-person meter, no visible ceiling, and no owner who notices the trend before it hits zero. This article gives you a small ledger, a dependency-free burn-down script, and a one-page run you can paste into your wiki this afternoon.

Why shared free tiers fail quietly

Free tiers are usually provisioned as one credential for the whole team, which means the provider sees a single noisy consumer instead of five distinct ones. Usage rises smoothly until it does not, and the first signal you get is a hard failure in the middle of somebody's afternoon. Because there is no invoice, there is also no weekly moment where anyone looks at the number. The fix is organizational before it is technical: you need a written meter, a threshold, and a rotating custodian.

Step 1: Define the ledger schema before you invite anyone

Start with a plain CSV that any teammate can append to from a terminal, a spreadsheet export, or a script. Keep the columns boring and stable, because the value of the ledger comes from consistency across weeks rather than from clever tooling. The purpose and ticket fields exist so a future reader can tell whether heavy usage was justified. Commit this file next to your runbook so it travels with the team.

date,actor,workload,model_class,tokens_in,tokens_out,purpose,ticket
2026-10-06,priya,docs-rewrite,general,18000,4200,release-notes,DOC-114
2026-10-06,sam,test-gen,general,42000,9600,flaky-suite,TEST-88
2026-10-07,priya,triage-bot,small,5200,900,issue-labels,OPS-7
2026-10-07,lena,spec-draft,general,61000,14000,api-v2-design,ARCH-31

Step 2: Run a burn-down check that prints a wiki block

The script below is a proposal you can verify locally in about a minute, and it uses only the standard library. It reads the ledger, slices the last seven days, and prints a Markdown table with a share flag for any actor above forty percent. Run it from cron, a Make target, or by hand on Friday, and paste the output straight into your runbook page.

#!/usr/bin/env python3
"""ledger_check.py - burn-down summary for a shared model tier.

Proposed artifact: reads a local CSV ledger, prints a wiki-ready block.
Standard library only; no network calls and no product API involved.
"""
from __future__ import annotations

import argparse
import csv
from collections import defaultdict
from datetime import date, timedelta

WINDOW_DAYS = 7
SHARE_WARN = 0.40


def load(path: str) -> list[dict]:
    with open(path, newline="", encoding="utf-8") as fh:
        rows = list(csv.DictReader(fh))
    for row in rows:
        row["spend"] = int(row["tokens_in"]) + int(row["tokens_out"])
        row["day"] = date.fromisoformat(row["date"])
    return rows


def window_slice(rows: list[dict], today: date) -> list[dict]:
    start = today - timedelta(days=WINDOW_DAYS - 1)
    return [r for r in rows if start <= r["day"] <= today]


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--ledger", default="ledger.csv")
    ap.add_argument("--today", default=date.today().isoformat())
    args = ap.parse_args()

    today = date.fromisoformat(args.today)
    window = window_slice(load(args.ledger), today)
    if not window:
        print(f"No ledger rows in the last {WINDOW_DAYS} days. Nothing to report.")
        return 0

    total = sum(r["spend"] for r in window)
    by_actor: dict[str, int] = defaultdict(int)
    by_workload: dict[str, int] = defaultdict(int)
    for r in window:
        by_actor[r["actor"]] += r["spend"]
        by_workload[r["workload"]] += r["spend"]

    print(f"### Shared tier burn-down ({WINDOW_DAYS}d to {today})")
    print(f"Window spend: {total:,} token units across {len(window)} entries\n")
    print("| actor | tokens | share | flag |")
    print("| --- | ---: | ---: | --- |")
    for actor, spend in sorted(by_actor.items(), key=lambda kv: -kv[1]):
        share = spend / total
        flag = "over share" if share > SHARE_WARN else "ok"
        print(f"| {actor} | {spend:,} | {share:.0%} | {flag} |")

    top = max(by_workload.items(), key=lambda kv: kv[1])
    print(f"\nTop workload: `{top[0]}` at {top[1]:,} token units.")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

$ python3 ledger_check.py --ledger ledger.csv --today 2026-10-07
### Shared tier burn-down (7d to 2026-10-07)
Window spend: 154,900 token units across 4 entries

| actor | tokens | share | flag |
| --- | ---: | ---: | --- |
| lena | 75,000 | 48% | over share |
| sam | 51,600 | 33% | ok |
| priya | 28,300 | 18% | ok |

Top workload: `spec-draft` at 75,000 token units.

Step 3: Make the custodian a weekly rotation, not a permanent role

A permanent quota owner becomes a bottleneck, and a permanent quota auditor becomes resented. Rotate the job weekly across the people who actually use the tier, so everyone learns how fast it drains. The custodian's whole job is three lines: update the ledger, run the check, and write one sentence about the largest consumer. Hand the role over with a name and a date, never with "whoever is around".

Step 4: Decide in advance who yields when the tier runs low

Arguments about shared capacity are always worse when they happen live, so write the rule down before you need it. The principle is simple: the largest recent consumer yields first, and the custodian decides whether a workload moves or simply pauses. That is fairer than first-come-first-served, and it is easy to justify because the ledger makes the ranking public.

Situation	Who yields first	Recorded action
Rate-limit errors appear mid-day	Largest 7-day consumer	Pause batch jobs until the window rolls
One actor above the share threshold	That actor	Move heavy runs to off-peak hours
Ledger has gaps for two weeks	Custodian	Freeze new invites until entries resume
A run fails with no ticket reference	The requester	Re-run only after adding a purpose line

Step 5: Paste the one-page run into your wiki

Keep the run short enough that a new teammate reads it in ninety seconds, and link the ledger and the script rather than embedding them. Ask every custodian to overwrite the same block each week, so the page shows current state instead of a growing archive. The block below is the whole playbook, and it fits in a single screen.

## Shared model tier run (custodian: <name>, week of <date>)
- Ledger freshness: last entry <date> (stale if > 7 days)
- 7-day spend: <token units> / stated limit: unknown -> check project terms page
- Actors over share threshold: <names or none>
- Top workload this week: <workload name>
- Decision taken: <none / pause / re-schedule / escalate>
- Handoff: <name> -> <name> on <date>

Where MonkeyCode changes the practical math

Two operator-stated facts matter for this workflow: the project offers free model access and a free server option. Free model access lowers the barrier for the teammate who only needs occasional drafts, so you can add a fifth contributor without a procurement conversation. A free server option means the weekly check does not have to live on somebody's laptop cron, which is the usual reason these ledgers quietly stop updating after three weeks. I am describing the two availability claims as the operator supplied them, and I am deliberately not quoting quotas or hardware here, because those terms change and a blog post is a bad place to read them. Check the project's current terms page before you promise anyone a number.

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

Treat the tier as a shared workshop resource rather than a metered utility, and it will teach your team something useful about how agent workloads actually consume capacity. If you want to stand the ledger up against real work instead of a toy CSV, the free model access and free server option are the cheapest way to try it; just confirm the current limits first.

Limitations and who should skip this

This ledger only counts what people record, so an unlogged script can drain the tier invisibly until someone notices the failures. Token units also measure consumption rather than value, and the teammate burning the most capacity may be doing the highest-value work. Teams with real billing, per-seat accounts, or provider-side usage reports should use those instead, since they are authoritative and require no manual discipline. Skip this approach entirely if your organization cannot ask people to log usage honestly, because a ledger nobody trusts is worse than no ledger at all.

Write a Demo Contract: A Wiki Run Before a Clickable Agent Page Gets Treated as Shipped

Alex Zhu — Thu, 08 Oct 2026 06:46:06 +0000

You opened the review thread and found a public URL where a teammate had asked an agent to rebuild the onboarding page overnight. The page looked finished, the buttons worked, and a stakeholder had already forwarded it to a customer success lead. Nobody had written what the page promised, what data it stored, or when the server should disappear. You need a demo contract before the next clickable agent page gets treated as shipped work.

Why a finished look is not a handoff

A clickable page compresses a lot of unfinished decisions into one link that feels safe to forward. People assume uptime, data handling, and accessibility because the layout resembles the product they already trust. Your wiki run should force those assumptions into named fields before anyone outside the author shares the URL. The card is the handoff, and the page is only the prop that the card is allowed to describe.

Roles you name before the first share

You assign four short roles, and you keep them as names rather than team aliases that nobody checks. The author builds the page and fills the first draft of the card from the agent transcript. The contract owner accepts or rejects the promises, including the stop date and the data rule. The audience liaison is the only person who may forward the URL, and the teardown owner deletes the server when the date hits.

The one-page run you paste into the wiki

You can paste the numbered run below under a heading called Demo contract, then link it from your agent lane page. Each step names an owner, an input, and a proof you can attach without scheduling a long meeting. Stop the run if any proof is missing, because a missing proof means the URL stays private. Do not treat a green local preview as permission to share the URL outside the author channel.

1. Author writes the question and saves a private card before any server starts.
2. Contract owner sets data_rule, claims_refused, stop_date, and teardown_owner.
3. Author drafts the page in the model lane and commits the page with the card.
4. Contract owner runs python3 check_demo_contract.py demo-contract.yaml.
5. Audience liaison forwards the URL only when status is shareable and exit code is 0.
6. Teardown owner deletes the server on stop_date and sets status to expired.

1. Capture the question

You write one sentence that states the question the demo answers, and you reject vague goals like explore the new flow. The author pastes that sentence at the top of the card before any model call is made. If you cannot state the question in one sentence, you do not start the server at all. A demo without a question becomes a second product by accident, and the wiki cannot reverse that later.

2. Mark the boundary

You list what the page may show and what it must not collect, store, or imply about production behavior. The contract owner checks that list against your data handling notes before the audience liaison sees the link. Sample data stays synthetic, and any real identifier is a reason to tear the run down immediately. You also note which claims the page is not allowed to make, such as uptime or accessibility completion.

3. Bind the stop date

You set a stop date that is soon enough to force a decision, and you name the teardown owner on the same line. The audience liaison may extend the date once, and only by editing the card before the old date passes. A silent extension is a failed handoff, even if the server is still healthy and the page still loads. When the date passes, the teardown owner removes the process and writes the outcome back into the card.

4. Attach the proof

You attach the card path, the commit that generated the page, and a short note on which model lane produced the draft. The contract owner signs by adding their name and the time, using the checker below so the fields are actually present. The audience liaison forwards only after the checker exits cleanly and the card status says shareable. You keep the transcript link next to the card so a later reader can see why a sentence was chosen.

Failures this run is meant to catch

Three failures show up often when a clickable agent page escapes the author channel and lands in a stakeholder thread. The first is a forwarded URL with no stop date, which turns a short favor into an unpaid hosting promise. The second is a data rule written as be careful, which nobody can test and nobody can honestly reject. The third is one person holding author, contract, and teardown, so the share decision was never actually reviewed.

A checker you can run before anyone forwards the URL

You do not need a platform team to enforce the first version of this habit on the team. A small Python script can reject a missing owner, a past stop date, or a shareable rule that is not synthetic. Label the script below as an unexecuted example until you run it against a card you wrote. You run it in the same directory as the card, and you paste the exit status into the wiki comment.

# Replace every placeholder before you share anything.
question: Can a stakeholder finish onboarding without asking what the next button does?
status: draft
author: riley
contract_owner: jordan
audience_liaison: casey
teardown_owner: devon
stop_date: 2026-10-15
data_rule: synthetic fixtures only; no customer identifiers
claims_refused: uptime, accessibility completion, production parity
server_name: onboarding-demo-041
transcript_url: https://example.internal/transcripts/041

#!/usr/bin/env python3
"""Local demo-contract checker.

Unexecuted example: run it yourself. It reads a local file and does not call a network.
"""

from __future__ import annotations

import sys
from datetime import date
from pathlib import Path

REQUIRED = [
    "question",
    "status",
    "author",
    "contract_owner",
    "audience_liaison",
    "teardown_owner",
    "stop_date",
    "data_rule",
    "claims_refused",
    "server_name",
]

ALLOWED_STATUS = {"draft", "shareable", "blocked", "freeze", "expired"}


def parse_flat_card(text: str) -> dict[str, str]:
    data: dict[str, str] = {}
    for line_no, raw in enumerate(text.splitlines(), start=1):
        line = raw.split("#", 1)[0].rstrip()
        if not line.strip():
            continue
        if line[0].isspace() or line.startswith("-"):
            raise SystemExit(f"line {line_no}: nested values are not allowed in v1")
        if ":" not in line:
            raise SystemExit(f"line {line_no}: expected key: value")
        key, value = line.split(":", 1)
        data[key.strip()] = value.strip().strip('"').strip("'")
    return data


def check(card: dict[str, str], today: date) -> list[str]:
    errors: list[str] = []
    for key in REQUIRED:
        if not card.get(key):
            errors.append(f"missing {key}")
    status = card.get("status", "")
    if status and status not in ALLOWED_STATUS:
        errors.append(f"unknown status {status}")
    stop_on = None
    stop = card.get("stop_date", "")
    if stop:
        try:
            stop_on = date.fromisoformat(stop)
        except ValueError:
            errors.append("stop_date must be YYYY-MM-DD")
    if stop_on and stop_on < today and status not in {"expired", "freeze"}:
        errors.append("stop date has passed; set expired and tear the server down")
    author = card.get("author", "")
    if author and author == card.get("contract_owner", ""):
        errors.append("contract_owner must differ from author")
    if author and author == card.get("teardown_owner", ""):
        errors.append("teardown_owner must differ from author")
    if author and author == card.get("audience_liaison", ""):
        errors.append("audience_liaison must differ from author")
    if status == "shareable":
        rule = card.get("data_rule", "").lower()
        if not rule.startswith("synthetic"):
            errors.append("shareable data_rule must start with synthetic")
        if not card.get("transcript_url"):
            errors.append("shareable cards need transcript_url")
    return errors


def main() -> int:
    path = Path(sys.argv[1] if len(sys.argv) > 1 else "demo-contract.yaml")
    card = parse_flat_card(path.read_text(encoding="utf-8"))
    errors = check(card, date.today())
    if errors:
        print(f"blocked: {path}")
        for err in errors:
            print(f"- {err}")
        return 1
    print(f"ok: {path} status={card['status']} stop={card['stop_date']}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

python3 check_demo_contract.py demo-contract.yaml
echo "exit=$?"

You treat a zero exit as permission to ask the audience liaison for a forward, not as permission to call the page production. A failing exit means you fix the card, and you do not negotiate the missing field in chat. If the stop date is already past, the script should fail even when every other field looks tidy. That failure is the point, because tidy cards can still describe a server that should already be gone.

The sample card uses a stop date of 2026-10-15 so you can see the field shape, not so you can copy that day forever. You should replace that date, the names, and the server name before you trust the printed result. The parser accepts only flat key lines, which keeps the first version easy to review in a wiki diff. Nested lists belong in a later version, after the team actually follows the flat card for a few runs.

The handoff comment after each step

You leave a four-line comment on the wiki page so the next person does not reconstruct the run from chat. The comment names the role that just finished, the proof path, the next role, and the command they should run. You do not add praise, guesses, or a second URL in that comment, because extras hide the missing proof. A short comment is easier to audit than a paragraph that tries to retell the whole demo from memory.

Role finished: contract owner
Proof: demo-contract.yaml exit 0
Next: audience liaison
Command: python3 check_demo_contract.py demo-contract.yaml

A decision table for the contract owner

You will get pressure to keep a popular demo alive because a stakeholder liked the click path. Use a small table so the decision stays tied to the question, the data rule, and the date. The table does not replace judgment, but it stops the team from inventing a new exception in the thread. Read the row that matches your evidence, then write that row name into the card status field.

Evidence you can point to	Status to write	Next owner
Question still open, synthetic data, stop date in the future	shareable	audience liaison
Question already answered, no new stakeholder ask	freeze	teardown owner
Real identifiers, or a data rule nobody can test	blocked	contract owner
Stop date has passed, whatever the page still shows	expired	teardown owner

You copy one row into the handoff comment so the status change has a reason sitting beside it. You do not add a fifth row during the meeting, because a new row is a new policy and belongs in a separate edit. If two rows seem true, you pick the stricter one and you say so in the comment. Stricter here means blocked before shareable, and expired before freeze, so old servers do not linger under a polite name.

Where free model access and a free server fit

You can draft the card and the page copy with free model access, then host that page on MonkeyCode's free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Those two options fit this run because the demo should stay cheap enough to delete, not precious enough to defend. You still fill the owners yourself, because model access does not choose your stop date or your data rule.

Limitations and who should skip this

This checker only reads a local card file, and it cannot see whether the server is actually down or who can still log in. You should not use the run for production incidents, regulated data, or any page that already holds customer records. A team with no wiki and no named owners will turn the card into another unread document on a shelf. If you cannot name a teardown owner who can actually delete the server, skip the share step entirely.

Free model access and a free server option can change, so you should not write quotas, hardware sizes, or permanence into the wiki card. The script does not call a vendor API, and it will not catch a secret that someone pasted into the page source. You still need your normal review if the demo later becomes a candidate for the product repository. People who only build private throwaway sketches, with no shared URL, do not need this ceremony at all.

Close the loop without keeping the URL

After teardown, you leave the card in place and you change the status to expired rather than deleting the history. The next author can copy the question and the data rule, but they must set a new date and a new server name. That copy is a fresh run, not an extension of the old URL or the old transcript. If you try the drafting step, keep the card private and use free model access plus the free server option there.