DEV Community: Sam Chen

Replayable or It Didn't Happen: Five Anti-Patterns in Free-Model Debugging

Sam Chen — Tue, 27 Oct 2026 13:07:05 +0000

It failed once. Then it passed. Which run do you trust?

Most people guess. That guess is usually the real bug.

Here is the rule I use now: if you cannot replay a request, you cannot debug it. Replay means same prompt, same parameters, stored response. Everything below follows from that.

I keep hitting the same five anti-patterns when teams debug against free model access and free servers. Each one has a symptom you can spot, a root cause you can name, and a cheap replacement pattern.

Anti-pattern 1: The Single-Run Verdict

Symptom: one green run closes the ticket. One red run opens it again.

Root cause: sampled output is stochastic. A single run measures luck, not behavior.

Replacement: run it k times and store a pass rate. Write the threshold down before you run.

# k=5 is enough to see flakiness. It is not enough for statistics.
for i in 1 2 3 4 5; do python replay.py --run --tag baseline; done
python replay.py --report --tag baseline
# baseline: 3/5 pass (0.60)

A 3/5 today and a 3/5 tomorrow is stable. A 5/5 today and a 2/5 tomorrow is a regression you can prove.

Anti-pattern 2: The Vanishing Request

Symptom: "it worked yesterday" and nobody can rebuild yesterday's prompt.

Root cause: prompts are assembled at runtime from templates, retrieval, and user text. Nothing stores the exact final string.

Replacement: hash model + prompt + params, and append every call to a JSONL log. Replay by hash.

No hash, no bug report. A screenshot is not a request.

Why hash instead of storing the prompt? A hash is safe to commit, share in a ticket, and diff. The prompt stays in the log file, which stays local.

Anti-pattern 3: The Infinite Transcript

The symptom shows up late in a session. Answers get shorter, quality drops, and the quota disappears faster than the token math predicts.

Root cause: every turn re-sends the whole history. Token spend grows with the square of turn count, not linearly.

Replacement: give each turn an explicit budget. Summarize old turns into a fixed block. Trim the retrieved context before you trim the instructions.

# Explicit budget beats implicit growth.
BUDGET = {"system": 400, "retrieved": 1200, "history": 600, "answer": 800}

Track those four numbers per call. If one drifts, you found the quota leak.

Anti-pattern 4: The Assumed-Idle Server

Symptom: the first call times out. The third call is fast. You "fix" a bug that was never yours.

Root cause: free servers go idle. Cold start looks exactly like a model failure from inside your code.

Replacement: measure transport before you judge content. Split errors into timeout, http_status, and bad_content.

# Five probes. Note cold vs warm. Do not judge from one number.
for i in 1 2 3 4 5; do
  curl -sS -o /dev/null -w "probe $i: %{http_code} %{time_total}s\n" "$MC_ENDPOINT"
done

If probe 1 is slow and 2-5 are fast, your timeout is a cold-start problem. Raise the client timeout. Do not touch the prompt.

Anti-pattern 5: The Leaky Replay Log

The symptom is a runs.jsonl in a pull request. The root cause is logging the whole request object because it was convenient.

Replacement: log the hash and a redacted parameter set. Read keys from the environment only. Add the log to .gitignore on day one.

printf 'runs.jsonl\n.env\n' >> .gitignore
git status --short   # should show neither file

The artifact: a replay harness you can actually keep

This is stdlib-only Python. I have not run it against your endpoint; treat it as a template and adjust the request shape to your client.

# replay.py — record once, replay by hash. Stdlib only.
import hashlib, json, os, sys, time, urllib.request

LOG = "runs.jsonl"
ENDPOINT = os.environ["MC_ENDPOINT"]          # base URL from the project page
KEY = os.environ["MC_API_KEY"]                # never hardcode this

def fingerprint(model: str, prompt: str, params: dict) -> str:
    blob = json.dumps({"m": model, "p": prompt, "k": params}, sort_keys=True)
    return hashlib.sha256(blob.encode()).hexdigest()[:16]

def call(model: str, prompt: str, params: dict):
    body = json.dumps({"model": model, "messages": [{"role": "user", "content": prompt}], **params}).encode()
    req = urllib.request.Request(ENDPOINT, data=body, headers={
        "Content-Type": "application/json",
        "Authorization": f"Bearer {KEY}",
    })
    t0 = time.time()
    try:
        with urllib.request.urlopen(req, timeout=90) as r:
            payload = json.loads(r.read())
        return {"ok": True, "payload": payload, "ms": int((time.time() - t0) * 1000)}
    except Exception as e:
        # classify transport failure separately from bad content
        return {"ok": False, "error": type(e).__name__, "ms": int((time.time() - t0) * 1000)}

def record(tag: str, model: str, prompt: str, params: dict):
    fp = fingerprint(model, prompt, params)
    result = call(model, prompt, params)
    row = {"tag": tag, "fp": fp, "model": model, "params": params,
           "prompt_chars": len(prompt), "ok": result["ok"], "ms": result["ms"]}
    with open(LOG, "a", encoding="utf-8") as f:
        f.write(json.dumps(row, ensure_ascii=False) + "\n")
    print(fp, result["ok"], result["ms"], "ms")

def report(tag: str):
    rows = [json.loads(l) for l in open(LOG, encoding="utf-8") if l.strip()]
    rows = [r for r in rows if r["tag"] == tag]
    if not rows:
        return print("no rows for", tag)
    ok = sum(1 for r in rows if r["ok"])
    med = sorted(r["ms"] for r in rows)[len(rows) // 2]
    print(f"{tag}: {ok}/{len(rows)} ok, median {med} ms")

if __name__ == "__main__":
    args = dict(zip(sys.argv[1::2], sys.argv[2::2]))
    if "--run" in sys.argv:
        record(args.get("--tag", "adhoc"), args.get("--model", "default"),
               "Summarize this diff in five bullet points: <paste here>", {"temperature": 0})
    if "--report" in sys.argv:
        report(args.get("--tag", "adhoc"))

Run it twice. The second run gives you a repeatable number instead of a memory.

The decision table I actually use

Evidence	Likely owner	Next move
Same `fp`, different output, temperature 0	Model or provider	Pin params, re-run 5x, keep the spread
Same `fp`, `ok: false`, `TimeoutError`	Transport / cold start	Preflight, raise timeout, retry once
Different `fp` on every run	Your code	Log the assembled prompt, fix the builder
Prompt chars jump 3x mid-session	Your code	Add the context budget
`4xx` on first call only	Auth or quota	Check key scope and remaining quota

That table settles most "is it the model?" arguments in under a minute. Print it. Tape it to the monitor.

Where the free tier fits

The MonkeyCode project is open source, and it currently advertises a free model allotment of 10 million tokens plus a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I use it as the cheap target for the harness above: record a baseline against the free endpoint, keep the fingerprint log, then compare any later change against that baseline. That is a boring use, and boring is the point. Numbers and quotas move, so confirm the current figures on the project page before you size anything around them.

Limitations matter here. A free endpoint has no SLA you can lean on. Model versions can change under the same name. Server behavior on a free host is not production behavior.

Who should not use this approach

You need sub-second p99 latency. A free server is not that.
You handle regulated data. A replay log is still a data store.
You need reproducibility guarantees from the provider. Pin to a paid contract instead.
You ship on a single sample and call it tested. Fix that habit first.

The checklist

Hash every request. Store the hash, not the secret.
Run k=5 before you judge anything.
Budget context per turn, in writing.
Probe the server before you blame the model.
Keep runs.jsonl out of git.

So: next time a call fails, ask the boring question first. Can I replay it?

If the answer is no, you have a logging bug, not a model bug. Fix that one first, and the free tier becomes a lab bench instead of a slot machine.

Give the harness a try on one endpoint and one prompt. Ten minutes of recording buys you weeks of not guessing.

No Invoice, No Excuse: A Request Ledger for Free Model Access

Sam Chen — Mon, 26 Oct 2026 11:37:56 +0000

Free tier means no invoice. It does not mean no budget.

You are spending something every call. You just cannot see the receipt. So write your own ledger first.

I keep watching the same failure. A side project runs fine for two weeks. Then a model endpoint starts answering slowly. Or it stops answering. Nobody knows which of the six scripts did it.

Is that a model problem? A quota problem? A retry loop you forgot about? You cannot tell, because you never recorded the calls.

This post is an anti-pattern catalog plus one small artifact. The artifact is a SQLite request ledger. It takes twenty lines and it answers those questions later.

The five anti-patterns

Each one has a symptom you recognize, a root cause you usually miss, and a replacement pattern.

1. Counting calls instead of work

Symptom: your counter says 40 calls today. Your free allowance is already gone.

Root cause: calls are not equal. A 200-character classification prompt and a 40,000-character code review are one call each. The counter is measuring the wrong unit.

Replacement: record input and output size per call. If the response carries a usage field, store the real token numbers. If it does not, store character counts and label them as a proxy. Never pretend they are tokens.

2. Logging after the retry loop, not inside it

Symptom: one logical task produces zero rows, or one row, or nine. You cannot reproduce it.

Root cause: the log line sits after the loop. Exceptions skip it. Early returns skip it. The information exists only on the attempt that failed.

Replacement: write the row in finally. Add an attempt column. A failed call is data, not noise.

3. Timestamping at write time

Symptom: the burn curve looks flat. Latency looks suspiciously small. Everything looks fine at 3am.

Root cause: you stamped the row when the insert ran. Under concurrency, that is minutes after the request opened.

Replacement: capture a UTC wall clock at request open, and a monotonic clock for duration. Store both. Only one of them is safe for subtraction.

4. Buffering rows in memory until exit

Symptom: the run that crashed is missing from the ledger. That is exactly the run you care about.

Root cause: a list appended in RAM, flushed by an atexit handler that never fired.

Replacement: append-only SQLite with WAL mode and a commit per row. Boring and crash-safe.

5. One error bucket called `error`

Symptom: 60% error rate. No idea what that means.

Root cause: a 429, a 500, and a malformed prompt all collapse into the same string.

Replacement: classify at write time. rate_limited, server_error, refused, timeout, ok. Five buckets change the whole conversation.

The artifact: a twenty-line ledger

This is the shape I use. It runs as written once you supply a send() function.

# ledger.py
import datetime, os, sqlite3, time, uuid

DB = os.environ.get("LEDGER_DB", "requests.db")

SCHEMA = """
CREATE TABLE IF NOT EXISTS calls (
  call_id      TEXT PRIMARY KEY,
  attempt      INTEGER NOT NULL,
  task         TEXT NOT NULL,
  model        TEXT NOT NULL,
  started_utc  TEXT NOT NULL,
  wall_ms      INTEGER NOT NULL,
  in_chars     INTEGER NOT NULL,
  out_chars    INTEGER NOT NULL,
  status       TEXT NOT NULL,
  http_status  INTEGER,
  host         TEXT NOT NULL
);
CREATE INDEX IF NOT EXISTS idx_started ON calls(started_utc);
"""

def open_ledger(path=DB):
    con = sqlite3.connect(path, timeout=5)
    con.execute("PRAGMA journal_mode=WAL")
    con.execute("PRAGMA synchronous=NORMAL")
    con.executescript(SCHEMA)
    return con

Now the wrapper. Note the finally block and the two clocks.

def classify(http_status):
    if http_status == 429:
        return "rate_limited"
    if http_status and 500 <= http_status < 600:
        return "server_error"
    if http_status and 400 <= http_status < 500:
        return "refused"
    return "error"

def call_model(con, send, task, payload, model="free-tier",
               host="laptop", max_attempts=3):
    for attempt in range(1, max_attempts + 1):
        started = datetime.datetime.now(datetime.timezone.utc).isoformat(timespec="seconds")
        t0 = time.monotonic()
        status, code, out = "error", None, ""
        try:
            resp = send(payload)
            code = getattr(resp, "status_code", None)
            out = resp.text
            status = "ok" if code and 200 <= code < 300 else classify(code)
            return out
        except TimeoutError:
            status = "timeout"
            raise
        finally:
            con.execute("INSERT INTO calls VALUES (?,?,?,?,?,?,?,?,?,?,?)",
                (str(uuid.uuid4()), attempt, task, model, started,
                 int((time.monotonic() - t0) * 1000),
                 len(str(payload)), len(out), status, code, host))
            con.commit()

That is the whole idea. Every attempt lands on disk. Nothing is inferred later.

Three queries that pay for the ledger

Run these after a day of real work.

-- 1. burn curve (characters are a proxy until you have real token counts)
SELECT substr(started_utc, 1, 13) AS hour,
       COUNT(*) AS calls,
       SUM(in_chars + out_chars) AS chars
FROM calls WHERE status = 'ok'
GROUP BY hour ORDER BY hour;

-- 2. retries that never paid off
SELECT task, COUNT(*) AS attempts, SUM(status = 'ok') AS oks
FROM calls GROUP BY task
HAVING oks = 0 ORDER BY attempts DESC;

-- 3. error mix by class
SELECT status, COUNT(*) AS n FROM calls
GROUP BY status ORDER BY n DESC;

Query 2 is the one that changes behavior. A task with twelve attempts and zero successes is not slow. It is broken.

Where MonkeyCode fits

I use MonkeyCode's free model access to run these batteries. The free server option matters for the same reason.

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

Here is the useful part: the free tier is the ideal place to calibrate a ledger, because mistakes cost you nothing but time. Free model access and the free server option are described on the project's own site. Check that page for the current allowance and terms. Those numbers move, and I will not quote a figure that may already be stale.

Run the same battery twice. Once on your laptop. Once on the free server.

LEDGER_DB=laptop.db python run_battery.py
ssh free-server 'LEDGER_DB=server.db python run_battery.py'

Then diff the two ledgers. That comparison is the whole point.

Reading the diff

Keep it mechanical:

Server p95 much lower than laptop p95? You were network-bound. Your code was fine.
Both p95s high and similar? You are queue-bound at the model. Reduce prompt size or batch less.
Server shows rate_limited, laptop does not? Shared egress. Back off, do not add retries.
Both show refused on one task only? That is your payload, not the platform.
Identical ok counts and identical latency? You learned your workload is not latency-sensitive. Good news.

Who should not use this approach? If you already have provider-side usage analytics and structured traces, this ledger is duplicate work. Skip it. If you make ten calls a week, skip it too. The ledger earns its keep at a few hundred calls and more.

What the ledger will not tell you

Character counts are not tokens. Real token accounting needs the usage field from the response. Store both if you can.

A ledger also cannot tell you why a prompt was rejected. It only proves it was. Read the body you logged alongside the status.

And it will not survive multi-process writers on a network filesystem. That is a SQLite limitation, not a clever workaround.

No invoice does not mean no budget. Write the receipt yourself, then go measure something real on a free tier.

The Cold Boot Audit: Six Anti-Patterns a Warm Free Tier Hides

Sam Chen — Tue, 20 Oct 2026 09:45:00 +0000

Your app is not portable. It is warm.

A free box keeps state you never declared. Caches, temp files, and hand-typed env vars all survive. Then you migrate, and boot fails at 3 a.m.

So I stopped asking "does it run?" I ask a harder question now. Does it boot from nothing?

Here is the audit I use, six anti-patterns it catches, and where it is useless.

The audit is one stdlib file

No agents. No dashboards. Three assertions and a JSON report.

#!/usr/bin/env python3
"""coldboot.py - fail fast on hidden warm-state assumptions."""

import json
import os
import sys
import time
import urllib.error
import urllib.request

REQUIRED = ["APP_ENV", "DATABASE_URL", "SESSION_SECRET", "PUBLIC_ORIGIN"]
SUSPECT = {"changeme", "dev", "test", "secret", "localhost", "127.0.0.1"}


def check_env() -> dict:
    """Assert the env contract instead of trusting the box."""
    missing = [k for k in REQUIRED if not os.environ.get(k, "").strip()]
    weak = [k for k in REQUIRED if os.environ.get(k, "").strip().lower() in SUSPECT]
    return {"check": "env_contract", "ok": not missing and not weak,
            "missing": missing, "weak": weak}


def check_ready(url: str, budget_s: float = 45.0) -> dict:
    """Measure time to first 200. Treat it as a budget, not a hope."""
    started = time.monotonic()
    last_error = None
    while time.monotonic() - started < budget_s:
        try:
            with urllib.request.urlopen(url, timeout=3) as resp:
                if resp.status == 200:
                    elapsed = round(time.monotonic() - started, 2)
                    return {"check": "readiness", "ok": True, "seconds": elapsed}
        except (urllib.error.URLError, TimeoutError) as exc:
            last_error = str(exc)
        time.sleep(0.5)
    return {"check": "readiness", "ok": False, "error": last_error}


def check_data_dir(path: str) -> dict:
    """Prove the data dir is the only thing you actually persist."""
    probe = os.path.join(path, ".coldboot_probe")
    try:
        with open(probe, "w", encoding="utf-8") as fh:
            fh.write(str(time.time()))
        return {"check": "data_dir", "ok": True, "path": path}
    except OSError as exc:
        return {"check": "data_dir", "ok": False, "path": path, "error": str(exc)}


def main() -> int:
    url = os.environ.get("HEALTH_URL", "http://127.0.0.1:8080/health")
    report = [check_env(), check_ready(url), check_data_dir("/data")]
    print(json.dumps(report, indent=2))
    return 0 if all(item["ok"] for item in report) else 1


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

This is a proposal, not a benchmark. I have not run it against your service.

Force the failure with a read-only root

Docker makes hidden writes loud. Mount nothing writable except /tmp and one data dir.

docker build -t app:cold .
docker run --rm --read-only --tmpfs /tmp \
  -e APP_ENV=production \
  -e HEALTH_URL=http://127.0.0.1:8080/health \
  -v coldboot-data:/data \
  app:cold ./coldboot.py

If that command dies, your free tier was doing quiet work. That is the finding.

Six anti-patterns, one check each

1. Cache as a dependency

Symptom: first 200 arrives after 40s. Later requests are instant.
Root cause: nobody measured the request after a restart.
Replacement: a cold-start budget in CI, enforced by check_ready.

Warm numbers flatter every design. Budget the cold path instead.

2. Env edits that only exist on the box

Symptom: redeploy works, a second instance crashes on import.
Root cause: SESSION_SECRET was typed into a shell once, months ago.
Replacement: check_env at boot, so you crash-loop instead of 500ing.

3. IP allowlists that describe the old box

Symptom: database auth fails only from the new region.
Root cause: the credential was pinned to an egress IP, not a role.
Replacement: run the audit from two networks before cutover.

4. `/tmp` as a database

Symptom: uploaded files vanish after a restart.
Root cause: no writer ever named a durable path.
Replacement: exactly one data dir, asserted by check_data_dir.

5. Unpinned installs

Symptom: the rebuild resolves different versions than production.
Root cause: no lockfile, or a lockfile nobody installs from.
Replacement: build the image in CI, then boot that image. Not pip install.

6. The invisible boot step

Symptom: healthy process, empty tables, 500s on first read.
Root cause: migrations were run by hand once, then forgotten.
Replacement: migrations in the entrypoint, gated before the health route.

Diff two reports, not two opinions

Run warm first. Then destroy the box, rebuild, run again.

check	warm run	cold run	verdict
`env_contract`	pass	fail on `SESSION_SECRET`	ship blocker
`readiness`	0.4s	38.9s	over budget
`data_dir`	pass	fail, read-only root	path not declared

Two JSON files in the repo beat a long migration meeting. The diff is the argument.

Where a disposable target and free models help

You want a box you can delete without ceremony. That is the whole point of the exercise.

MonkeyCode's free server option is one candidate for a throwaway target: deploy the app, run the audit, tear it down. Its free model access fits one narrow job here. Paste the JSON report and ask for a triage checklist a human can review.

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

Both availability claims come from the operator. Confirm current terms on the project page before you plan around them. Do not assume they are permanent.

And never let a model decide pass or fail. The script decides. The model only sorts.

Who should skip this

Single stateful node with no migration plan. Fix the plan first.
Teams already booting every commit in ephemeral CI. You have this check.
Static sites where the boot path is not the risk.
Anyone chasing throughput. This audit says nothing about load.

The one question before you migrate

Can I delete this box and rebuild it, tonight, without reading my notes?

If the answer needs a meeting, run the audit. If a check fails, you found it cheap. Keep the report in the repo and re-run it after every dependency bump.

If you want a throwaway target to test against, the free server option is worth a look — just read the current terms first.

Two Sessions, One Repo: Four Drift Anti-Patterns and a Preflight Script

Sam Chen — Mon, 19 Oct 2026 08:27:16 +0000

The drift between your AI session and your second box is a contract problem.

It is not a model problem. It is not a luck problem. It is a missing file.

You asked for code in one window. It ran there, so you shipped it. Then it met a different host and quietly fell over.

Who is surprised by that? Only someone who has not done it twice yet.

Here are four anti-patterns I keep seeing, with the replacement pattern for each. Then comes the script I actually run.

Anti-pattern 1: The Chat-Only Spec

Symptom: You cannot rebuild the change without scrolling a transcript.

The instructions lived in a conversation. The repo has no record of the goal, the constraints, or the stop condition.

A week later you ask the same assistant for a fix. It guesses at your conventions, because it has nothing to read.

Root cause: The spec was treated as conversation, not as an artifact. Conversation is ephemeral and per-window. A repo is neither.

Replacement: Put the contract in the repo as a file. Keep it short and boring.

<!-- CONTRACT.md -->
# Task contract
Goal: add /healthz returning 200 with a JSON body
Constraints:
- no new runtime dependencies
- do not touch src/billing/**
Stop when: tests pass and diff is under 200 lines
Verify with: npm test && ./preflight.sh

Now every session reads the same file. The stop condition is visible to you too, which matters more.

Is the constraint list longer than five items? Then the task is too big. Split it.

Anti-pattern 2: The Inherited Runtime

Symptom: Works locally, dies on the second box with a syntax or API error.

Your laptop has the runtime you installed months ago. The other host has whatever its image shipped with.

Root cause: The runtime version was never written down, so it was never checked. Nobody can diff a value that does not exist.

Replacement: Pin it in a one-line file and assert it at startup.

# .runtime-version
v22.11.0

# assert-runtime.sh
want="$(cat .runtime-version)"
have="$(node --version)"
if [ "$want" != "$have" ]; then
  echo "runtime drift: want $want, have $have" >&2
  exit 1
fi

Call the assertion from your start script, not from your memory. Memory is the thing under test here.

Anti-pattern 3: The Unwritten Environment

Symptom: Boot fails with an undefined key, or worse, silently uses a default.

Your .env has eleven keys. The other box has nine. Nobody knows which two are missing until something 500s.

Root cause: The set of required keys was never declared. Absence is invisible without a checklist.

Replacement: Commit a sample file with keys and empty values. Check every key on boot.

# .env.sample (committed)
DATABASE_URL=
HEALTH_PORT=8080

# every key listed in .env.sample must exist in the environment
missing=0
while IFS= read -r line; do
  key="${line%%=*}"
  case "$key" in ''|\#*) continue ;; esac
  if [ -z "${!key:-}" ]; then
    echo "missing env key: $key" >&2
    missing=1
  fi
done < .env.sample
exit "$missing"

Remember to export before checking: set -a; . ./.env; set +a.

A missing key should stop the boot. A default value should be a decision, not an accident.

Anti-pattern 4: The Unbounded Diff

Symptom: The change touches files you never asked about, and you approve it anyway.

An assistant with no stop condition keeps improving things. Formatting drifts. A helper gets "cleaned up." Review becomes archaeology.

Root cause: There is no review budget, so there is no signal that the task escaped its box.

Replacement: Set a diff budget and fail loudly when it is exceeded.

total="$(git diff --numstat | awk '{a+=$1; d+=$2} END {print a+d+0}')"
budget="${DIFF_BUDGET:-200}"
if [ "$total" -gt "$budget" ]; then
  echo "diff is $total lines, budget is $budget: split the task" >&2
  exit 1
fi

Exceeding the budget is not a failure of the model. It is a signal that your contract was vague.

The artifact: one preflight script, run on two boxes

Here is the whole thing. It is plain bash and has no dependencies beyond git and curl.

#!/usr/bin/env bash
# preflight.sh - run before you accept any change, on every box.
set -uo pipefail

fail=0
say() { printf '%-4s %s\n' "$1" "$2"; }

# 1. Runtime matches the pin.
want="$(cat .runtime-version 2>/dev/null || echo missing)"
have="$(node --version 2>/dev/null || echo none)"
if [ "$want" = "missing" ]; then
  say FAIL "no .runtime-version file"; fail=1
elif [ "$want" != "$have" ]; then
  say FAIL "runtime drift: want $want, have $have"; fail=1
else
  say OK "runtime $have"
fi

# 2. Every declared env key is present.
if [ -f .env.sample ]; then
  while IFS= read -r line; do
    key="${line%%=*}"
    case "$key" in ''|\#*) continue ;; esac
    if [ -z "${!key:-}" ]; then
      say FAIL "env key not set: $key"; fail=1
    fi
  done < .env.sample
fi

# 3. The service answers on the box you think you are on.
url="${HEALTH_URL:-http://127.0.0.1:8080/healthz}"
code="$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$url" || echo 000)"
if [ "$code" = "200" ]; then
  say OK "health $url"
else
  say FAIL "health $url -> $code"; fail=1
fi

# 4. The change is small enough to read.
total="$(git diff --numstat | awk '{a+=$1; d+=$2} END {print a+d+0}')"
if [ "$total" -gt "${DIFF_BUDGET:-200}" ]; then
  say FAIL "diff is $total lines; split the task"; fail=1
else
  say OK "diff $total lines"
fi

# 5. Print a receipt you can compare across boxes.
say OK "host $(hostname) | $(date -u +%FT%TZ)"
if [ "$fail" -eq 0 ]; then say OK "preflight passed"; else say FAIL "preflight blocked"; fi
exit "$fail"

Run it like this:

set -a; . ./.env; set +a
chmod +x preflight.sh
./preflight.sh

Then run it on the other box, with the same commit checked out. Compare the receipts.

Same runtime, same env keys, same health answer, same budget verdict? The two boxes agree. That is all a contract is.

On the second host, hostname differs by design. Everything else should match. When it does not, you found the drift before a user did.

Where the second box comes from

This is the part of my workflow where a free server option is genuinely useful. I need a second, cheap host to run the same script against, and I do not want it on my laptop.

MonkeyCode bundles free model access and a free server option. I use the free models for the small mechanical changes, and the free server as the second box in the receipt comparison. That is the whole role it plays here.

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

One honest caveat: free tiers are offered as-is by whoever runs them. Do not treat any free host as permanent infrastructure. Do not assume it keeps your data, your uptime, or your configuration.

A decision table for what belongs where

Work type	Laptop	Second box	Notes
Prompt drafting, renames, test scaffolds	Yes	No	Cheap and revertible
Environment parity check	Yes	Yes	This is the point of the second box
Anything touching secrets or customer data	Yes	No	Keep it off shared hosts
Long-running jobs, queues, cron	No	No	Use a host you actually control
Production traffic	No	No	Nothing here is a prod story

Print the table in your repo if your team argues about this. Arguing about a table is cheaper than arguing about an outage.

What the script will not catch

Be clear about the limits. This is a drift detector, not a test suite.

It does not tell you the code is correct. It tells you the boxes agree.
It cannot see missing data, permissions, or network policy you never declared.
It trusts .env.sample to be complete. A stale sample passes happily.
It measures line counts, not risk. A two-line change can still ruin your week.

So keep real tests. Keep a rollback. Keep a human who reads the diff.

Who should skip this

You should not use this pattern if any of these are true.

You handle regulated or personal data and cannot use a third-party box for the check.
Your workload needs GPUs, persistent storage, or long-lived background processes.
Your team already has staging parity and CI that runs the same assertions per commit.
You cannot pin a runtime because the platform controls the image.

For those cases, keep the four replacement patterns and drop the free host. The contract file and the budget check cost nothing.

The short version

Two sessions drift because nothing forces them to agree.

So write the contract down. Pin the runtime. Declare the env keys. Cap the diff. Run the same script on both boxes and compare receipts.

If you want a second box without a credit card, the free server option is the cheapest way I have found to get one. Just keep the receipt, and read it before you merge.

Four Anti-Patterns That Live at the Model Boundary

Sam Chen — Sat, 17 Oct 2026 06:13:05 +0000

Most AI features do not fail inside the model. They fail at the seam between model output and your code. That seam is where free tiers become production incidents.

I keep meeting the same four shapes there. Here is the catalog: symptom, root cause, replacement. The code below is a harness, not a benchmark.

Why the boundary, not the model

Model news moves weekly. Integration patterns barely move. Free model access made calls cheap; it did not make output shapes stable.

So the durable skill is not prompt poetry. It is contract discipline around an unreliable producer. Ask yourself one question before shipping any AI feature. What does my code do with a payload it did not expect?

Anti-pattern 1: Stream first, validate never

Symptom: users see half an answer, then a red toast. Your logs show duplicate calls for one user action.

Root cause: you wired the token stream straight into the UI. Validation happens after rendering, so a broken payload already reached a human.

Replacement pattern: buffer, validate, commit.

Stream tokens into a server-side shadow buffer.
On stream close, parse and check the schema.
Emit exactly one of two events: result or rejected.
Keep the raw buffer for a day so you can replay it.

Streaming status is fine. Streaming unvalidated content is not.

Anti-pattern 2: The prompt is a string literal

Symptom: a refactor changes behavior and nobody notices. Someone "cleans up" whitespace, and your JSON rate drops.

Root cause: the prompt lives inline with application code. No fixture, no hash, no diff review.

Replacement pattern: prompts as versioned files with a pinned hash.

Store each prompt in prompts/<name>.txt.
Record sha256(prompt) in every stored result row.
Add one golden fixture per prompt to CI.
Fail the build when the hash changes without a fixture update.

A prompt change is a schema change. Treat it like one.

Anti-pattern 3: The anonymous fallback

Symptom: two runs of the same input give different answers, and your table cannot explain why. Support tickets become archaeology.

Root cause: you added a fallback path and saved only the text. The row does not name which model, version, or prompt produced it.

Replacement pattern: stamp provenance into the artifact, not the log file.

Add three columns to the table that stores results: model_id, prompt_sha, attempt. Then make one query your daily check.

SELECT model_id, COUNT(*)
FROM results
WHERE created_at > now() - interval '1 day'
GROUP BY 1 ORDER BY 2 DESC;

If an unexpected model_id shows up, you learned something. If the column is missing, you learned nothing, forever.

Anti-pattern 4: No capability contract

Symptom: the demo works on the model you tested. A different model returns prose, a markdown fence, or a truncated object.

Root cause: the expected output shape lives in your head and in a comment. Nothing executable enforces it.

Replacement pattern: explicit schema plus exactly one repair attempt.

Validate required keys and types in code, not in prose.
On failure, send one repair prompt with the validation error attached.
Cap repairs at one. Two repairs usually means your contract is wrong.
Return a typed error to the caller instead of a string guess.

A harness you can run in five minutes

I want a test loop that fails for the right reasons. This is the setup where MonkeyCode's free model access and free server option are relevant. The operator states free model access, currently advertised at 10 million tokens, plus a free server option. Verify the current numbers and terms in the console before you rely on them.

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

First, a mock model with no dependencies beyond the Python 3.11 standard library. It returns invalid JSON on the first call, then valid JSON.

# mock_model.py
import json, os, threading
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

STATE = {"calls": 0}
LOCK = threading.Lock()

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers.get("Content-Length", 0)))
        with LOCK:
            STATE["calls"] += 1
            n = STATE["calls"]
        if os.environ.get("MOCK_MODE", "flaky") == "flaky" and n == 1:
            content = '{"answer": "yes", "confidence": '   # truncated
        else:
            content = json.dumps({"answer": "yes", "confidence": 0.9})
        out = json.dumps({"id": f"mock-{n}",
                          "choices": [{"message": {"content": content}}]}).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(out)))
        self.end_headers()
        self.wfile.write(out)

    def log_message(self, *args):
        pass

if __name__ == "__main__":
    ThreadingHTTPServer(("127.0.0.1", int(os.environ.get("PORT", "8765"))),
                        Handler).serve_forever()

Second, the client with a budget ledger, one validator, and one repair.

# contract.py
import json, os, urllib.request

BASE = os.environ.get("MODEL_BASE", "http://127.0.0.1:8765")
BUDGET = int(os.environ.get("CALL_BUDGET", "3"))
LEDGER = {"spent": 0}
REQUIRED = {"answer": str, "confidence": (int, float)}

def validate(payload):
    if not isinstance(payload, dict):
        return ["not an object"]
    problems = []
    for key, typ in REQUIRED.items():
        if key not in payload:
            problems.append(f"missing {key}")
        elif not isinstance(payload[key], typ):
            problems.append(f"{key} has wrong type")
    c = payload.get("confidence")
    if isinstance(c, (int, float)) and not 0 <= c <= 1:
        problems.append("confidence out of range")
    return problems

def call(prompt, hint=""):
    if LEDGER["spent"] >= BUDGET:
        raise RuntimeError("budget exhausted")
    LEDGER["spent"] += 1
    body = json.dumps({"prompt": prompt + hint}).encode()
    req = urllib.request.Request(f"{BASE}/v1/chat", data=body,
                                 headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.loads(r.read())["choices"][0]["message"]["content"]

def get_answer(prompt):
    raw = call(prompt)
    try:
        parsed = json.loads(raw)
    except json.JSONDecodeError:
        parsed = None
    if not validate(parsed):
        return parsed, "ok"
    raw = call(prompt, "\nReturn JSON only. No prose.")
    try:
        parsed = json.loads(raw)
    except json.JSONDecodeError:
        return None, "unparseable after one repair"
    problems = validate(parsed)
    return (parsed, "ok") if not problems else (None, "; ".join(problems))

Third, run it. Expected output is the repaired object, with two calls spent.

python -m unittest test_contract -v
python mock_model.py &
python -c "import contract; print(contract.get_answer('is 2+2 4?')); print(contract.LEDGER)"
# ({'answer': 'yes', 'confidence': 0.9}, 'ok')
# {'spent': 2}

When you move off the mock, change one variable: export MODEL_BASE=<your endpoint>. If you take the free server option, confirm the runtime you actually get before you plan around it.

What the harness proves, and what it does not

It proves your parser, your validator, and your repair path behave. That is the part you control. It does not measure model quality, latency, or cost per answer.

Three honest limits:

One repair masks a broken contract. Fix the prompt instead.
A local mock cannot reproduce remote rate limits. Test those separately.
The ledger counts calls, not tokens. Do not confuse the two.

Decision table

Situation	Free model access	Paid tier
Prototype with strict schema checks	Good fit	Overkill
Load test at production concurrency	No	Yes
Latency-sensitive user path	Measure first	Usually
Regulated data	Check terms first	Check terms first
Batch backfills with retries	Fine with a ledger	Fine

Who should skip this

Skip this approach if you need a contractual SLA. Skip it if your output must be identical across runs. Skip it if you cannot inspect the data handling terms for the region you serve.

Free access is a development convenience. It is not a capacity plan.

The one habit that survives

Write the validator before the prompt. Then ask what your code does with garbage. If the answer is "it shows the user", you found your next anti-pattern.

If you want a sandbox for this harness, MonkeyCode's free model access is a low-risk place to start. Keep the mock in CI, and keep the validation strict.

Three Retry Anti-Patterns That Quietly Burn a Free Model Quota

Sam Chen — Thu, 15 Oct 2026 11:20:30 +0000

Most retries against a free model quota are wasted work. Your agent hits a wall, retries, and burns the same dead budget three more times.

You have probably seen that loop in a log. It looks like activity. It is not progress.

Here is a catalog of three retry anti-patterns. Each entry has symptoms, a root cause, and a replacement pattern you can ship today.

The shift that broke old retry code

AI coding agents are everywhere this month. Free model tiers are part of why.

But a free tier fails differently from a paid API. A paid API fails when it is down. A free tier fails when it is used up.

One state is transient. The other is terminal until a window resets. Your HTTP client cannot tell them apart.

So what should the retry loop actually inspect?

Anti-Pattern 1: Treating every 429 as a slow-down

Symptoms

The same step retries three to five times with zero change.
Every log line shows an identical 429 and an identical body.
The run dies with max retries exceeded several minutes later.

Root cause

The policy was copied from a rate-limited paid API. There, 429 means "slow down". On a free tier, 429 often means "budget exhausted". Retrying a terminal state only delays the failure.

Replacement pattern

Classify the failure before you sleep and retry.

Read Retry-After when the server sends it, and honour it.
Scan the body for quota keywords. Halt on those.
Cap transient retries at three attempts per step.
Add jitter so parallel workers do not thunder.

# Sketch. Not run against any specific provider endpoint.
RETRYABLE = {429, 500, 502, 503, 504}
TERMINAL = {400, 401, 403, 404, 422}
QUOTA_HINTS = ("quota", "exhausted", "credit", "limit reached")

def classify(status: int, body: str) -> str:
    lowered = body.lower()
    if status in TERMINAL:
        return "fail_fast"
    if status == 429 and any(h in lowered for h in QUOTA_HINTS):
        return "halt_and_report"   # no retry, no sleep
    if status == 429:
        return "backoff"           # respect Retry-After
    if status in RETRYABLE:
        return "backoff"
    return "halt_and_report"

The important line is halt_and_report. A terminal state deserves a human decision, not a loop.

Anti-Pattern 2: Counting tokens after the run

Symptoms

The agent finishes a long plan, then discovers it ran out mid-way.
Nobody can say how much of the budget the run consumed.
The failure report arrives after all the useful work is gone.

Root cause

Cost tracking is bolted on as post-hoc reporting. That is accounting, not control. By the time the number appears, the decision window has closed.

Replacement pattern

Keep a ledger that runs ahead of the model.

Estimate the cost of the next step before you send it.
Hold a reserve for the fix pass. Twenty percent is a reasonable start.
Stop at the ceiling and write a checkpoint.
Never let the provider be the first thing to tell you the budget is gone.

from dataclasses import dataclass

@dataclass
class Ledger:
    budget: int             # operator-stated figure; verify your own terms
    spent: int = 0
    reserve: float = 0.20   # room for the repair pass

    def ceiling(self) -> float:
        return self.budget * (1 - self.reserve)

    def can_afford(self, estimate: int) -> bool:
        return self.spent + estimate <= self.ceiling()

Call can_afford before each step. When it returns False, stop cleanly and persist state.

Anti-Pattern 3: Re-running the whole plan after one bad step

Symptoms

Step 7 fails, and the run restarts from step 1.
Already-verified steps get regenerated with different output.
Costs double while confidence drops.

Root cause

The plan is treated as one atomic request. It is not. A plan is a sequence of separately verifiable steps, and only one of them failed.

Replacement pattern

Resume from a fingerprint, not from the top.

Hash each step's inputs into a short fingerprint.
Persist fingerprint -> ok when a step verifies.
Re-emit only steps without a verified fingerprint.
Store partial output hashes so truncation is detectable.

import hashlib, json

def step_fingerprint(step: dict) -> str:
    payload = json.dumps(step, sort_keys=True).encode()
    return hashlib.sha256(payload).hexdigest()[:12]

def pending(plan, checkpoints):
    for step in plan:
        fp = step_fingerprint(step)
        if checkpoints.get(fp) == "ok":
            continue        # verified work is skipped, not repeated
        yield step, fp

Skip verified work. Recompute the failure only.

The decision table I keep next to the loop

Failure	Retry?	Wait	Persist first
`429` plus quota keyword	No	—	checkpoint + ledger
`429`, no quota keyword	Yes, max 3	`Retry-After`, else exp + jitter	attempt count
`500` / `502` / `503` / `504`	Yes, max 5	exp backoff + jitter	attempt count
`400` / `422` schema error	No	—	payload + prompt hash
Truncated stream	Yes	immediate	partial output hash

Print this table in the run header. It is cheap, and it ends arguments later.

Where a free tier actually belongs

Free model access fits throwaway and exploratory work best. Prototypes, harness tests, and one-off refactors are good candidates.

The MonkeyCode project offers free model access and a free server option. The team states the free allowance is 10 million tokens. Check the current terms yourself before you build anything on a number.

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

Used that way, the tradeoff is honest. A free server is fine for a harness that runs for minutes. It is not capacity planning, and it is not a substitute for paid guarantees.

Run the ledger before the model, not after. That one habit survives every tier change.

Limitations and who should skip this

Teams with hard SLAs should budget for a paid tier. Free quotas reset on someone else's schedule.
Long-running batch jobs should not depend on a scratch server.
Anyone who cannot verify quota terms should not build billing logic on them.
The classifier above is a sketch. Test it against your provider's real error bodies.
Quota keywords differ per provider. Copy the hints from actual responses, not from a blog post.

What to do next

Pick one anti-pattern and delete it this week. Start with the classifier; it is roughly ten lines.

Then add the ledger. Then add fingerprints.

If you want a free tier and a free server to run the harness on, the MonkeyCode project page is the entry point. Bring the ledger with you.

Five Anti-Patterns Before a Free Host Sees Code

Sam Chen — Tue, 13 Oct 2026 01:05:21 +0000

I do not trust a nodding chat model.
I trust a contract file that fails closed.
If your free session only agrees, you lack a design.

That sounds harsh to a busy shipping team.
It is also a cheap bug that hides inside speed.
A green chat log is not a release gate.

The conclusion up front

Free drafts are cheap, and cheap agreement is dangerous.
A scratch host can show a page, not own your data.
Your contract file is the only gate that stays put.

You still need a schema, nasty cases, and a host role.
You still need a checker that exits non-zero.
You still need a human who can read a diff.

Name the tool, then get back to work

Disclosure: This article was prepared as part of MonkeyCode's product outreach.
This outreach brief presents MonkeyCode as an open-source project.
It mentions free model access and a free server option.

I will not invent quotas, model names, hardware, or duration.
Those numbers were not verified for this draft.
Would you bet a sprint on a sentence I refused to source?

Why this showed up again

Developers are arguing about models that agree too fast.
Some posts blame the model for soft, flattering answers.
I blame the workflow that treats agreement as review.

I am not citing a lab study from this week.
I am using that public argument as a warning, not a dataset.
Your repo can fail the same way without any leaderboard.

What a contract means here

Replacement

You write the failing cases before the implementation.
The model may still draft the handler code.
It must not be the only author of the tests.

The replacement workflow

Work in this order, even when the chat feels done.
Speed is fine after the contract exists, not before.

Write a schema file that lists the required keys.
Write a cases file with reject inputs you invented.
Write a host file with the role and scan paths.
Run the local checker and fix every printed error.
Only then ask a model to draft the handler.
Re-run the checker before you upload anything at all.
Use a free server only while the role says scratch.

MonkeyCode can help on the draft step and the scratch host.
Feed it the schema, not a dump of customer rows.
If you remove the product name, the order still holds.

Proposed checker

Treat this script as an unexecuted local example.
It uses only the Python standard library here.
It does not call any network API at all.

#!/usr/bin/env python3
'''Local contract check. Proposal only, not a vendor SDK.'''
import json
import re
import sys
from pathlib import Path

ROOT = Path(__file__).resolve().parents[1]
SECRET = re.compile(
    r'(?i)(api[_-]?key|secret|token|password)\s*[:=]\s*\S+'
)

def load(name):
    path = ROOT / 'contract' / name
    return json.loads(path.read_text())

def main():
    schema = load('schema.json')
    cases = load('cases.json')
    host = load('host.json')
    errors = []
    required = schema.get('required', [])
    if not required:
        errors.append('schema has no required keys')
    for case in cases.get('cases', []):
        if 'input' not in case or 'expect' not in case:
            errors.append('case missing input or expect')
    role = host.get('role')
    if role not in {'scratch', 'system-of-record'}:
        errors.append('host role is missing or unknown')
    if role == 'scratch' and host.get('stores_user_data'):
        errors.append('scratch host must not store user data')
    for rel in host.get('scan_paths', []):
        path = ROOT / rel
        if not path.is_file():
            errors.append('scan path missing: %s' % rel)
            continue
        text = path.read_text(errors='ignore')
        if SECRET.search(text):
            errors.append('secret-like text in %s' % rel)
    if errors:
        print('\n'.join(errors))
        return 1
    print('contract ok')
    return 0

if __name__ == '__main__':
    sys.exit(main())

Put the file at tools/check_contract.py in the repo.
The parent lookup assumes that exact file path.
Change ROOT if your repo layout actually differs.

Sample files

These files are illustrations, not a production capture.
Copy them, then break them, then fix the breaks.
Would a silent pass on broken files fool you?

contract/host.json:

{
  "role": "scratch",
  "stores_user_data": false,
  "scan_paths": ["README.md", "src/handler.py"]
}

contract/schema.json:

{
  "required": ["id", "status"],
  "additionalProperties": false
}

contract/cases.json:

{
  "cases": [
    {"input": {}, "expect": "reject"},
    {"input": {"id": ""}, "expect": "reject"},
    {"input": {"id": "a", "status": "nope"}, "expect": "reject"}
  ]
}

Run the checker from the repository root directory.
A non-zero exit means you do not upload yet.
A zero exit only means the files agree internally.

python3 tools/check_contract.py
echo "exit=$?"

A local pre-push hint

Treat this hook as a proposal, not a team policy.
It will annoy you on purpose during rushed pushes.
Annoyance is cheaper than a secret on a public log.

#!/bin/sh
python3 tools/check_contract.py || exit 1

Save that snippet as a local pre-push hook.
Make the hook executable, then document the command.
A teammate without the hook still needs the same check.

Decision table

Symptom	Root cause	Replacement
Chat only praises the plan	Prompt asked for agreement	Require three breaking inputs
Keys rename between runs	No pinned response schema	Reject missing or extra keys
Secret text reaches a log	Scratch path felt private	Scan files and redact prompts
Demo host holds real state	Role was never recorded	Label host and block scratch writes
Tests cheer one happy string	Model wrote its own exam	You own the failing cases

Read the row that matches your last real incident.
If two rows match, fix the secret row first.
A leaked token outruns a messy schema every time.

Failure analysis you can rehearse

Break the sample on purpose before you trust the script.
A checker you never broke is just another nod.

Delete the required list and expect a schema error.
Set stores_user_data to true while the role is scratch.
Paste a fake token line into the scanned handler.
Drop the expect field from one case object.
Point scan_paths at a file that does not exist.

Each break should print a reason and exit non-zero.
If a break stays silent, your checker is theater too.
Fix the checker before you blame the model again.

Limitations

This checker never calls the model by itself.
It cannot prove the handler matches the cases.
You still need a real test runner for that gap.

The secret regex misses encoded blobs and split strings.
It can also flag toy examples if you scan them.
Point scan_paths at source files, not at this writeup.

I did not verify quotas, regions, hardware, or retention.
Do not quote this piece as a pricing or status page.
Vendor pages change, and this draft will not follow.

Short sentences can sand off real edge cases.
The table and the script carry the precise part.
If they disagree with your policy, keep your policy.

Who should skip this

Skip it when the data is regulated or customer confidential.
Skip it when you need an audit sign-off this week.
Skip it when nobody on the team will read diffs.

Skip it if the free server must be your only database.
That wish is the host-role anti-pattern in a new coat.
Should a disposable box be your system of record?

Skip it if the contract will not live in version control.
A checker with stale files is another nodding reviewer.
You already know how that particular story ends.

Questions worth asking out loud

What input would make this function lie to you?
Where does the prompt go if the vendor logs it?
Is this host allowed to remember a single user?

If you cannot answer those, stop the upload.
Ask the model for a counterexample, not a compliment.
Write that counterexample into the cases file first.

One next step

Pick a tiny handler you already understand well.
Write three reject cases before you open a session.
Run the checker, then decide if a scratch host helps.

If MonkeyCode is already your tool, feed it the schema only.
Keep the free server labeled scratch until a human promotes it.
The same gate still works if you later change vendors.

Your Model Graded Its Own Homework

Sam Chen — Sun, 11 Oct 2026 21:23:57 +0000

A green log is not a finished patch. I start from that rule every single time. If the generator also wrote the test, you graded nothing.

I keep a short catalog for free model drafts. Each entry lists a symptom, a cause, and a replacement. I do not need a new slogan to spot the miss.

What I refuse to trust

Free model access can draft a unified diff. A free server can run that diff one time. Neither option is allowed to define the expected behavior.

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

Do you want a draft, or do you want a verdict? I want the draft, and I keep the verdict. I use those two options as a rehearsal bench only.

I do not treat a chat reply as a specification. I do not treat a remote exit code as proof. A friendly log can still hide a fake oracle.

Anti-pattern 1: the model writes the oracle

Symptom

The new tests mention the same names as the patch. They pass on the first remote run you try. You feel finished, and that feeling is the trap.

Root cause

One generator filled both sides of the check. The test encodes the implementation you just accepted. It cannot catch a wrong idea with a pretty shape.

Replacement

I write two fixture files before I ask for any code. One file holds the input object I care about. The other file holds the output I will accept.

The model may not edit either fixture file. Could a stranger fail this test without your patch? If the answer is no, your oracle is fake.

Write a stricter fixture, then ask the model again. Then rerun the compare before you trust the color. These commands are an unexecuted example, not a lab report.

mkdir -p rehearsal/contract
printf '%s\n' '{"n": 4}' > rehearsal/contract/input.json
printf '%s\n' '{"ok": true, "double": 8}' > rehearsal/contract/expect.json
test -s rehearsal/contract/expect.json && echo "fixture ready"

Change the expected numbers to match your real rule. Do not let the model pick them after it sees the diff. Pair the files with a short note you wrote yourself.

# Behavior note

Input n is an integer from 0 to 20.
Return ok true only when n is even.
Return double as n times 2 when ok, else 0.

That note is the spec the model is allowed to see. If the note and the fixture disagree, fix the note first. Do not ask the model to reconcile your own contradiction.

Anti-pattern 2: fixtures arrive after the diff

Symptom

The patch lands in the branch before any example. The sample numbers show up later in the same chat. Those numbers match the code you already wanted.

Root cause

You let the result choose the requirement after the fact. Time order is the actual bug, not the syntax. A contract should be older than the candidate patch.

Replacement

I record file times before I send any prompt. The gate fails when the fixture is newer than the patch. That rule feels strict, and it should feel strict.

stat -c '%Y %n' rehearsal/contract/expect.json rehearsal/patch.diff

Did the output change, or did the narration change? Grade the fixture, not the paragraph under the function. A longer file is not a stronger fix.

Run this gate after the remote log comes home

This script is a proposal you can read today. I am not publishing timing numbers or success rates. It checks shape, notes, and a plain JSON compare.

It does not deploy, install, or call a network. Treat every command below as unexecuted sample code. Adapt paths if your repo layout differs from this example.

#!/usr/bin/env python3
"""Local contract gate. Proposal, not a measured benchmark."""
import json
import sys
from pathlib import Path

ROOT = Path("rehearsal")
NEED = ("input.json", "expect.json", "notes.md")

def fail(msg: str) -> None:
    print(f"REJECT {msg}")
    sys.exit(2)

def main() -> None:
    box = ROOT / "contract"
    if not box.is_dir():
        fail("missing contract dir")
    for name in NEED:
        if not (box / name).is_file():
            fail(f"missing {name}")
    expect = json.loads((box / "expect.json").read_text())
    got_path = ROOT / "server_out.json"
    if not got_path.is_file():
        fail("missing server output")
    got = json.loads(got_path.read_text())
    if got != expect:
        fail("output != fixture")
    notes = (box / "notes.md").read_text().strip()
    if len(notes) < 40:
        fail("notes too thin")
    print("PASS local contract compare")

if __name__ == "__main__":
    main()

Copy the remote stdout into rehearsal/server_out.json before the run. Then invoke the gate and read the exit code yourself. A non-zero exit means reject, not a warmer prompt.

python3 rehearsal/gate_patch.py
echo "exit=$?"

A pass means your output matched the fixture you wrote. A pass does not mean the patch is wise or safe. A pass does not mean the remote host was clean.

Preflight before the prompt

I run four checks before I ask for any draft.

Confirm both fixture files exist and are non-empty.
Confirm notes.md states the behavior in plain words.
Scan the prompt text for keys before you paste.
Send the contract, not your whole repository tree.

grep -nE '(AKIA|BEGIN PRIVATE KEY|password\s*=)' prompt.txt && echo "stop"

That sniff is a seatbelt, not a full secret scanner. If it prints stop, I rewrite the prompt without the secret. I never paste a live environment file to save time.

Where a free model and a free server fit

I ask for a patch against notes.md, not against a vibe. I send no secrets and no environment file with the ask. I run the candidate once on the free server option.

I bring stdout home and compare it on my machine. MonkeyCode is the bench this rehearsal is written around. Free model access drafts the patch from the notes I wrote.

The free server option runs that draft away from my laptop. I still own the contract, the fixture, and the reject. Remove the product name and the gate still stands.

I am not stating a token quota in this article. I am not naming a model identifier or a hardware size. I am not promising how long any free offer stays up.

Check the live offer before you plan a week around it. Terms move, and stale numbers become confident lies. A missing quota line is safer than a fabricated one.

Is a fake quota more helpful than an honest gap? No, because a fake number schedules work you cannot finish. I would rather send you to the current page.

Who should not use this approach

Skip this if you cannot read a diff line by line. Skip this if the change touches auth, payments, or private data. Skip this if you need a certified or reproducible release build.

A free remote host is a rehearsal room, not a release gate. Skip this if your fixture says only "make it better." That sentence is a mood, not a contract you can test.

Write the input, write the output, then ask for code. Teams with no human reviewer should not adopt this flow. The script can reject a mismatch, not a bad product idea.

Judgment stays with a person who can own the merge. If that person is absent, do not automate the yes. Wait until a reviewer can read the deletions.

What I keep on the next pass

I keep four questions on a card beside the keyboard.

Who wrote the oracle that this run claims to satisfy?
Which file is older, the fixture or the candidate patch?
What did the host add that my lockfile does not list?
Which lines disappeared, and where is the note?

If any answer is mush, I stop the merge right there. The draft can stay on the branch until the note exists. The verdict stays with me, not with the remote log.

If you already keep fixtures in git, rehearse this once. Use a free model pass only to draft against your notes. Use one free server run only to collect the remote log.

Then let the local script be the only grade you trust. That is the whole offer I am willing to make today. No countdown, no ranking claim, and no borrowed story.

The Free Host Said Yes. Your Fence Card Is Still Blank.

Sam Chen — Sat, 10 Oct 2026 17:48:38 +0000

A free coding host is not a production fence. I treat a trial login as a risk, not as a vault. That shortcut turns into debt before the first merge.

Do you want the short version before the long catalog? Write the fence card on your laptop before any send. If that card fails, the free box never sees the prompt.

This piece is an anti-pattern catalog, not a product tour. Each item names a symptom, a root cause, and a replacement. I offer the checker as a proposal, not as a measured benchmark.

What the card is for

You have a coding task that a free model can draft. A free server can hold the scratch step off your laptop. That pair is useful, but it is not a vault or an SLA.

I keep the exploratory step behind a fence card. The card does not trust a happy status page or a long chat. Would you merge a patch you cannot explain tomorrow?

Anti-pattern 1: One shared trial key

The symptom is one free key shared across every chat tool. The root cause is a trial login used as a team identity. The replacement is a task id bound to one prompt file.

Shared keys hide who sent the prompt in the first place. They also hide which client the pasted text belonged to. Can you name the owner of yesterday's session right now?

Store the key in a local secret store, never in the repo. Rotate it when a teammate leaves the scratch workflow. A key in a dotfile will leak the moment you share a zip.

Anti-pattern 2: The prompt becomes the spec

The symptom is a requirement that lives only in a chat scroll. The root cause is speed, because the answer made the thread into law. The replacement is a short task file checked in before any call.

A chat scroll is not a reviewable spec for the next person. A task file is small, diffable, and deliberately boring to read. I want the next reviewer to open a file, not a vibe.

Put the goal, the non-goals, and the stop rule in that file. If you cannot write the stop rule, you are not ready. Why would a remote host know your stop rule better than you?

Anti-pattern 3: Two clients, one scratch disk

The symptom is two client notes sharing one server workspace. The root cause is reuse of a disk that stayed dirty. The replacement is one task, one empty workspace, and a wipe note.

Leftover files are not harmless clutter on a scratch disk. They become the next prompt's context by accident. Would you leave two customers' notes in one unlocked drawer?

Name the workspace after the task id before you copy files in. Refuse the run when a foreign task id is still on disk. Wipe is part of the task, not a chore you might remember later.

Anti-pattern 4: Trial host as a CI runner

The symptom is a pull request job starting on the trial host. The root cause is spare-capacity thinking, and free looked like owned CI. The replacement keeps CI on a runner you administer yourself.

Untrusted pull request code plus a shared host is a bad mix. I cannot cite an isolation promise for a trial box in this draft. If you need a hardened runner, this path is the wrong path.

Do not forward webhooks at the free host to save a bill. A saved bill is a poor trade for an unreviewed remote shell. Who owns the blast radius when that shell runs a stranger's script?

Anti-pattern 5: Pins with no local resolver

The symptom is a generated lockfile committed without a local resolve. The root cause is fluency, so a finished-looking file skipped the resolver. The replacement regenerates pins with your own package tool.

A fluent lockfile can still name a package you never chose. Your resolver is the check, and the model output is only a draft. Did you run the install on a machine you actually control?

Diff the regenerated pins against the model draft before you commit. If the diff is huge, stop and read the package names aloud. A huge pin diff is a question, not a gift.

Anti-pattern 6: A pool limit dressed up as a bug

The symptom is a mid-file death that you treat as a code bug. The root cause is a missing local budget file. A pool limit then looks like a logic crash.

The replacement writes a cap beside the task and stops on it. I will not invent a token count, a duration, or a machine size. Those numbers move, and a stale blog figure becomes a trap.

Check the vendor page on the same day you plan the run. Write the cap as a plain integer you are willing to spend. When the run hits the cap, save state and stop the session.

Guessing that the pool is infinite is how scratch work eats the day. A false crash can burn an afternoon that should have been a stop. Do you want a budget line, or another hour of fake debugging?

The replacement pattern

The replacement pattern is a fence card, not a longer prompt. You fill seven lines in a local card file. A script refuses the send when any line is blank.

The free model and the free server stay behind that refusal. Here is the card I want sitting next to the task file. Treat it as a proposal you can adopt, not as a lab result.

The card protects the next reviewer from a chat-only spec.
The card protects a second client from a dirty scratch disk.
The card protects your CI from a trial host you do not run.

task_id=2026-10-10-fence-01
workspace=empty
clients=one
secrets_in_prompt=no
ci_target=owned-runner
budget_cap=budget.txt
wipe_after=yes

Seven lines keep the rule obvious to a reviewer. A blank line is a failed review, not a minor nit. If a line is blank, you are not ready for a remote draft.

Run the checker before the send

Fail closed on your laptop

The script below is unexecuted example code for the local check. It reads the card file and the task file only. It does not open a network connection of any kind.

This parser reads KEY=value lines and does not source the card. It is not a full secret scanner, so do not pretend otherwise. I am not shipping this as a tested release.

#!/usr/bin/env bash
# Proposal only. Fail closed before any free-host prompt.
set -euo pipefail

card="${1:-fence-card.env}"
prompt="${2:-task.md}"

test -f "$card" || { echo "missing card"; exit 2; }
test -f "$prompt" || { echo "missing task file"; exit 2; }

get() {
  key="$1"
  line=$(grep -E "^${key}=" "$card" | head -n 1 || true)
  test -n "$line" || { echo "missing $key"; exit 2; }
  printf '%s' "${line#*=}"
}

task_id=$(get task_id)
workspace=$(get workspace)
clients=$(get clients)
secrets_in_prompt=$(get secrets_in_prompt)
ci_target=$(get ci_target)
budget_cap=$(get budget_cap)
wipe_after=$(get wipe_after)

test "$workspace" = "empty" || { echo "workspace must start empty"; exit 3; }
test "$clients" = "one" || { echo "one client per scratch task"; exit 3; }
test "$secrets_in_prompt" = "no" || { echo "prompt must stay free of secrets"; exit 3; }
test "$ci_target" = "owned-runner" || { echo "do not aim CI at the trial host"; exit 3; }
test -f "$budget_cap" || { echo "budget cap file missing"; exit 3; }
test "$wipe_after" = "yes" || { echo "plan the wipe before the run"; exit 3; }

if grep -E -q 'AKIA[0-9A-Z]{16}|-----BEGIN |api[_-]?key[[:space:]]*[:=]' "$prompt"; then
  echo "prompt looks like it carries a secret marker"
  exit 4
fi

mkdir -p .fence
printf '%s\n' "task_id=$task_id" "card=$card" "prompt=$prompt" > ".fence/${task_id}.decision"
echo "fence card passed for $task_id"

Run the checker like this before you open a remote session. Create a one-line budget file before you expect a pass. A missing budget file is a failed card, not a warning.

printf '%s\n' "set-your-cap" > budget.txt
chmod +x fence-card.sh
./fence-card.sh fence-card.env task.md
echo "exit=$?"

A non-zero exit means you stay on the laptop and fix the card. A zero exit means the card is complete, not that the code is correct. You still review the diff on a machine you trust.

Where the free step belongs

I send the free step only after the checker prints a pass. The model may draft, and the server may run one scratch command. The laptop still owns the spec, the pins, and the final diff.

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

MonkeyCode, for this draft, is relevant only after the card passes. The operator-supplied note is free model access plus a free server option. The operator also describes the project as open source.

I am not linking a repository, because no primary URL was supplied here. I am not stating a quota, a chip type, a time box, or permanence. Read the current project docs before you plan around either option.

If those docs disagree with this paragraph, trust the docs. A blog post is a workflow note, not a contract or a status page. Would you put a client export on a host you cannot describe?

That pair can hold an exploratory draft and a scratch command. It should not hold customer data, production deploys, or shared CI. Silence in the docs is a stop sign, not a blank check.

Six questions before the send

Use these six checks when you decide whether the send is allowed. One failed check blocks the send, even if the other five pass. I would rather lose a draft than mix two clients on one disk.

Stay local when the task file is not already in git.
Wipe first when the workspace does not start empty.
Stop now when the prompt shows a secret marker.
Do not retarget CI onto a host you do not administer.
Do not start when the budget file is missing from disk.
Do not start when you cannot wipe the workspace afterward.

These checks are a habit, not a certification of the remote host. A printed list still needs a human who will honor a failed row.

What the card does not prove

Leave the numbers on today's docs

The grep line is a tripwire, not a certified secret scanner. A clever paste can still sneak past a short pattern list. Use a real scanner when your org already runs one.

The card does not prove isolation on a remote host. It does not prove uptime for the remote host. It does not prove that a zero price will last.

Free access can change, so keep a local fallback ready. I did not run a benchmark for this script. I did not time a model, and I did not measure a server.

The checker only tests that the budget file exists. It does not parse the integer, so you still have to honor it. A file full of jokes is a pass, and that is a real limit.

If you need numbers, measure your own task and date the note. Paste the date next to the figure so the next reader sees the age. An undated metric is how old limits sneak into new posts.

Who should skip this path

Skip this path when the data is regulated or under a client contract. Skip it when you need a stated service level or a fixed machine shape. Skip it when the team will not keep the card inside review.

Also skip it if you cannot wipe the scratch workspace after the task. A free server you cannot reset is a shared disk with a login page. Are you comfortable reading that disk out loud in a retro?

A five-step local test

Drop a fake key marker into the task file and confirm exit code four.
Set the workspace value to dirty and confirm exit code three.
Remove the budget file and confirm the script stops before a pass.
Pass a clean card and confirm the decision file appears.
Keep that file next to the task so review can see the refusal trail.

Do not point this test at production, because the pass is only local. That plan is enough to trust the gate you actually have. It is not enough to trust a remote host you have not read.

Read the host policy on the same day you decide to use it. If the policy is silent on isolation, do not invent a promise. A quiet policy page is not the same thing as a guarantee.

Close the loop on your laptop

Free model access can speed a draft you already scoped. A free server can hold scratch work after the card passes. Neither one replaces the card, the task file, or the wipe plan.

I start with the card, and the remote step stays optional after that. If you already use that free model access, run this checker first. Then read today's limits in the project docs before you plan load.

Keep the final merge on a repository you control and can revert. A remote draft is only a guest in your workflow. Your repo is the host, and the host sets the rules.

The Transcript Looked Done. You Still Have No Receipt.

Sam Chen — Fri, 09 Oct 2026 14:16:09 +0000

A clean transcript is not a review record. I want a local receipt before any free session touches my branch. If that receipt is empty, I do not share the work.

Does a confident last reply count as proof? No, I keep seeing summaries outrun the diff. The chat can sound finished while the tree is still a guess.

The hole I am naming

I am not repeating my older stop-loop note. I am not repeating the allowlist note either. This catalog is about the transcript you keep after the model goes quiet.

A transcript is only a story of tokens. A review record is a set of files you can rerun. I mix those two views when I am tired.

Do you mix those two views as well? Yes, I still catch it in late reviews. A receipt is how I catch that mix.

Free model access makes another turn feel cheap. A free server makes a scratch run feel disposable. Cheap and disposable are not the same as checked.

I still need the receipt on my laptop. No news page was attached to this draft. I will not invent a headline, a score, or a quota.

If a number is missing here, that is on purpose. Stale product figures can waste a whole sprint. I would rather show the check than a stale number.

What sits in the receipt

I keep four files next to the diff. They are plain text, and they are boring. Boring is what I want on a Friday merge.

prompt.txt holds the exact text I am willing to send.
claim-ledger.txt maps each claim to a file and a command.
replay.txt stores the command, the exit line, and a log hash.
receipt.sha256 names those files so a later edit is obvious.

None of these files makes the model correct. They make my shortcut visible to a reviewer. That is the whole point of this catalog.

Anti-pattern 1: The summary replaces the diff

Symptom

The pull request text is the model's closing paragraph. Reviewers reply to tone, and nobody names a line. The bug can hide under a smooth ending.

Root cause

The chat is ordered by time, and the diff is not. I let the easier view win the review. Have you merged a paragraph you never opened?

Replacement

I write the ledger before I open the request. Each claim points at one path and one check. If I cannot point, I delete the claim.

claim: empty names are rejected
file: src/parser.py
check: python -m unittest tests.test_parser

Ask yourself this before you paste a summary. Can a teammate run the check without opening the chat? If the answer is no, the summary is still a story.

Anti-pattern 2: Price becomes a privacy control

Symptom

A key, a customer id, or a raw trace sits in the prompt. The word free made that paste feel small. A small paste can still become a large leak.

Root cause

I treated a billing label as a safety boundary. A billing label does not redact my files. Who told me that price was a control?

Nobody told me that, and I just hoped. Hope does not redact a prompt file either. I still have to run the search myself.

Replacement

I run a loud search before I send anything. This is not a full secret scanner at all. It catches the obvious leaks I keep repeating.

# proposal - unexecuted in this article
rg -n -i 'api[_-]?key|secret|password|BEGIN ' prompt.txt

decision: reject empty names in parser
rejected: coerce empty names to guest
ledger: claim-ledger.txt
stop: do not add a network call

Would I want that digest in the repo later? If I would not, I should not send the longer log. The longer log is how old mistakes return.

The order I follow

I follow the same order on every branch. I do not reorder it because a session feels friendly. A friendly session is still not a receipt.

I write prompt.txt with fake sample values only.
I write the claim ledger before I ask for a patch.
I run the redaction search and stop on any hit.
I ask for a patch only after those files exist.
I save the command and the exit line in the replay file.
I run the receipt script and read every bad exit.
I read the diff myself before I share the branch.

That order is the replacement pattern for this catalog. Each step leaves a file or an exit code. If a step has neither, I am still in the anti-pattern.

The check I run before a share

Here is the bundle I keep beside the branch. It is a proposal, not a timed benchmark. Do not quote this script as a measured result.

#!/usr/bin/env bash
# receipt-check.sh - local check before share
set -euo pipefail

need() {
  test -s "$1" || exit 2
}

need prompt.txt
need claim-ledger.txt
need replay.txt

if rg -n -i 'api[_-]?key|secret|password|BEGIN ' prompt.txt; then
  printf '%s\n' 'redaction hit'
  exit 3
fi

if rg -n '^claim:.*bugfix' claim-ledger.txt >/dev/null; then
  if ! rg -n '^test:' claim-ledger.txt >/dev/null; then
    printf '%s\n' 'bugfix claim without test line'
    exit 4
  fi
fi

sha256sum prompt.txt claim-ledger.txt replay.txt > receipt.sha256
printf '%s\n' 'receipt ok'

I invoke it from the worktree, not from memory. A bad exit means I stay local and fix the file. I do not negotiate with that exit code in chat.

bash receipt-check.sh

Exit 2 means a required file is missing or empty. Exit 3 means the prompt search hit a secret-like string. Exit 4 means a bugfix claim has no test line.

I fix the file that failed, then I run the script again. I do not negotiate with the exit code in chat. A model apology is not an exit code.

How I read the exits

Exit	Meaning	Next move
0	Crude checks passed on the three files	Read the diff once more, then share
2	A required file is missing or empty	Write the file before any session
3	Prompt search hit a secret-like string	Strip it and use a fake sample
4	Bugfix claim without a test line	Add a test path or drop the claim

This table is a rule for my own branches. It is not a service level from any vendor. If your team needs signatures, this table is too small.

Where the free options fit

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

I mention MonkeyCode once, as one optional workbench. It offers free model access and a free server option. I do not name a model in this draft.

I do not state a token quota or a duration. An outreach note mentioned a free token pool. I will not repeat an unverified figure here.

No primary page was attached for me to check. Stale quotas are how teams plan the wrong week. Confirm the current docs yourself before you depend on them.

The workflow stays on my laptop until the receipt check passes. I write the prompt file, then I run the script. Only then do I ask a free model for a patch.

A free server can run the command stored in the replay file. I still commit the receipt next to the diff. The session log does not become the record.

If your team already hashes prompts, try this check on one branch. Tell me which table row feels too strict. That is the only ask I will make here.

Who should not use this

Do not use this script as a compliance archive. It has no signature, no clock sync, and no reviewer identity. A regulated repo needs a heavier trail than this.

Do not use the check to hide a diff you cannot read. The script checks that files exist and look non-empty. It does not understand your parser or your threat model.

Do not point the search at live production secrets. Use a fake sample when you test the pattern. I mean that as a hard stop, not a tip.

Skip the free server when the job needs private paths. Customer data and long-lived credentials stay off that box. Keep those runs on a machine you already trust.

The free option is for scratch work you can lose. If losing the run would hurt, do not start it there. A missing receipt is cheaper than a leaked trace.

Limits I am willing to say out loud

The search pattern misses secrets that look like normal words. The ledger can still be filled with confident lies. I can hash a bad prompt and still be wrong.

The check raises the cost of skipping a review step. It does not make me honest by itself. I still have to read the diff with my own eyes.

I did not execute these commands against a live product. Treat every block as a proposal until you run it. Verify current product terms before you plan a sprint.

Terms move, and my files should still make sense. That is the bar I am willing to keep. If the bar feels low, add a signature and keep the files.

The Free Loop Kept Going. I Never Set a Stop.

Sam Chen — Thu, 08 Oct 2026 09:53:58 +0000

A free model reply is not a release decision. A free server log is not an audit trail either. I still want a local fence before any agent runs.

That fence sits on the branch I plan to merge. I do not trust a scratch host to invent it later. If the stop is missing, the green line is theater.

This is a composite review rule, not a measured outage report. I am not timing a cluster for this post. I am writing the stop I want in git.

Does a green free run mean the patch is safe to merge? It does not, and I want that said first. It only means some host answered a prompt I sent.

Why free access keeps lying to me

Free model access feels like permission to wander. I add another file because the call looks cheap. I retry a vague prompt and call the result research.

Vibe-coded patches are filling review queues this season. The model often sounds sure of the fix. The run record is still empty of stops.

Would I ban a free server for scratch work? No. I would ban unbounded use of that server. A scratch host can help, then it must stop.

The debt is not the model voice. The debt is the missing fence around retries, context, secrets, and model identity. Those four failures stack quietly.

Anti-pattern 1: Retry until something looks green

Symptoms

The same file shows three overlapping edits.
Logs repeat one tool name without a new goal.
A flaky check passes only on the final try.

Root cause

I treated free calls as an endless budget. The price felt like zero, so I never set a max. The loop then chased a green line, not a reviewable diff.

Replacement

Cap attempts in the runner before the first call. Exit when the cap hits. Do not ask the model whether it feels done.

# Proposal only. This cap is local policy, not a benchmark.
MAX_ATTEMPTS = 2

def allow_attempt(n: int) -> None:
    if n < 0:
        raise SystemExit("attempt fence: bad counter")
    if n >= MAX_ATTEMPTS:
        raise SystemExit("attempt fence: stop and read the diff")

Two is my personal policy, not a law of nature. You can pick three if your suite is slow. Write the number down before you prompt.

What should the runner do after that exit? Leave the worktree dirty and visible to me. Do not auto-commit, and do not open a pull request.

If I raise the cap mid-run, I have restarted the anti-pattern. The new number belongs in a new commit. Reviewers should see the change of mind.

Anti-pattern 2: Upload the world because the call is free

Symptoms

Answers cite paths I deleted last week.
Latency jumps without a real code change.
Two files in the bundle disagree on one type.

Root cause

I skipped a context budget and called it thorough. Free access is not a design for relevance. More files often add noise, not truth.

Replacement

Build a short manifest, then count bytes on disk. Refuse the send when the local cap breaks. Send a map of files, not the whole world.

# Unexecuted teaching example. Tune the byte cap locally.
find src tests -type f \( -name '*.py' -o -name '*.md' \) \
  | sort > /tmp/fence-manifest.txt
wc -c $(cat /tmp/fence-manifest.txt) \
  | awk '$1 > 80000 { print "bundle fence"; exit 2 }'

Eighty thousand bytes is a classroom number, not a vendor quota. I want that refusal on my laptop first. The free server should never see a rejected bundle.

Should tests enter the bundle by default? Sometimes yes, when they explain intent. Fixtures with live customer rows should not. I keep a deny file beside the manifest.

# deny.txt — paths that never leave the machine
.env
.env.*
secrets/
fixtures/live/

The deny file is plain text on purpose. I can diff it like any other review. A hidden client toggle would fail that simple test.

Anti-pattern 3: Treat the free session as a vault

Symptoms

A key shape shows up in a shared transcript.
A teammate can replay the prompt from logs.
Rotation starts in chat instead of the secret store.

Root cause

I confused a free server option with a private enclave. Convenience is not custody of my keys. The host may log prompts for its own reasons.

Replacement

Scan the outbound bundle for obvious secret shapes. Block the upload on the first match. Then read the bundle anyway, because scanners miss novel formats.

import re
import sys

PATTERNS = (
    r"AKIA[0-9A-Z]{16}",
    r"-----BEGIN ",
    r"(?i)api[_-]?key\s*=",
    r"(?i)secret[_-]?key\s*=",
)

def main() -> None:
    blob = open(sys.argv[1], encoding="utf-8", errors="replace").read()
    for pattern in PATTERNS:
        if re.search(pattern, blob):
            raise SystemExit("redaction fence: secret shape in bundle")

if __name__ == "__main__":
    main()

Is this a full data-loss program? It is not, and I will not pretend. It catches the paste mistakes I worry about most. New token formats will still slip through.

I also refuse to send shell history to any scratch host. History is full of one-off exports. Those lines look harmless until a key is sitting there.

Who owns the deny file on a team? A named reviewer, not the agent. If nobody owns redaction, do not use this flow at all.

Anti-pattern 4: Swap the model when the free path blips

Symptoms

Monday notes name one model id.
Wednesday's patch reads like another writer.
Style checks fail while behavior checks still pass.

Root cause

I treated free model access as a stable contract. The client was allowed to pick whatever was up. I never stored a pin in the run record.

Replacement

Require a model id in a local policy file. If the server cannot echo that id, stop the job. Do not improvise a cousin model to save the demo.

# run-fence.yml — local policy, not a published quota
model_id: "set-by-operator"
max_attempts: 2
max_bundle_bytes: 80000
fail_closed: true

I will not invent a model name for you in this note. Pin the id your current docs actually list. If that id disappears, fail closed and reread the docs.

How do I check the echo without a stale URL in print? I keep the HTTP path out of this article. A copied endpoint rots faster than the rule. Fill the path from the page you trust today.

def echo_matches(pin: str, echoed: str) -> bool:
    if not pin or pin == "set-by-operator":
        raise SystemExit("model fence: pin is still a placeholder")
    return pin.strip() == echoed.strip()

A placeholder pin must never count as a match. That guard looks petty until review day. A surprise substitute is a different experiment, so stop.

The local fence, step by step

I run this as a preflight, before any scratch host is called. Each step is local. Each failure exits nonzero. None of these steps ask the model for permission.

Read run-fence.yml and reject a placeholder model id.
Build the manifest, then subtract every path in deny.txt.
Fail if bundle bytes exceed max_bundle_bytes.
Run the secret scan and stop on the first hit.
Increment the attempt counter and stop at max_attempts.
Call the scratch host only after those checks pass.
Compare the echoed model id with the pin, then stop on drift.
Write a tiny report file and leave the merge decision to me.

# Proposal. I have not executed this as a published bench.
def ready_to_review(report: dict) -> bool:
    return (
        report["attempts"] <= report["max_attempts"]
        and report["secret_scan"] == "pass"
        and report["bundle_bytes"] <= report["max_bundle_bytes"]
        and report["model_echo"] == report["model_pin"]
    )

If ready_to_review is false, I do not open the pull request. I fix the fence or the bundle first. I do not ask the model to talk me out of a red check.

Where does the report live? Next to the diff, in the branch, as a small text file. Chat scrollback is not the record. A future reviewer cannot see my closed tab.

Where a free server is allowed to help

MonkeyCode is one host I can point at this fence. It offers free model access and a free server option for a scratch run.

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

I am not stating a token quota, a chip type, or a duration. I am not stating that the free option is permanent. I have not published latency numbers here. If the current docs disagree with this paragraph, believe the docs.

What do I send that host? Only a bundle that passed the deny list and the secret scan. What do I require back? An echoed model id that matches my pin. What do I do on a mismatch? I stop, then I pick a pin the docs still list.

# Sketch only. Set FENCE_MODEL from run-fence.yml yourself.
test -n "$FENCE_MODEL" || { echo "missing pin"; exit 2; }
test "$FENCE_MODEL" != "set-by-operator" || exit 2
echo "local fence ready pin=$FENCE_MODEL"

Would I call this path a production deploy? I would not. It is a scratch path with brakes on it. Production still needs your normal CI, review, and secret store.

Question	I require locally	A free server may do
Who sets the stop?	The fence file in git	Nothing, until I upload
Where do secrets live?	The secret store only	Nowhere in the prompt
Which model ran?	The pinned id	Echo that id or fail
What does green mean?	Tests I trust already ran	A sample, not a merge vote
What if the host blips?	Fail closed	No silent model swap

Can the free server be my only CI? No, and I do not want that shortcut. Can it be a first pass before CI? Yes, if the fence file is in the same commit. Reviewers should see the policy with the patch.

Who should skip this approach

Skip this if you need a signed availability contract today. Free access is an option, not an SLA I can hand an auditor. I will not dress it up as one.

Skip this if production keys live in the repo and nobody owns redaction. A sample regex is not your compliance boundary. Fix ownership before you automate uploads.

Skip this if you need a fair public benchmark. I gave no hardware notes and no latency table. Anyone inventing those numbers is guessing, including me.

Use it if you maintain a small service and want a cheaper scratch loop. Use it if reviewers already read diffs and you only need a hard stop. The fence is the product of this workflow, not the host.

What I refuse to count as proof

A calm paragraph from the model is not proof. A timestamp on a free server is not proof. A green badge from an unpinned model is not proof either.

Proof, for this rule, is boring and local. Attempts stayed under the cap I wrote down. The secret scan exited clean on the bundle. The echoed model id matched the pin I set.

Then I still read the diff myself. The fence only earns a review, not a merge. If I skip that read, I have rebuilt the original anti-pattern with extra files.

If you want a scratch host for that first pass, start from the current MonkeyCode docs for free model access and the free server option. Pin an id your docs name today. I would rather hear what the fence blocked than hear that the chat felt smart.

Bring a Kill Card or Leave the Scratch Host Alone

Sam Chen — Thu, 08 Oct 2026 07:41:19 +0000

A free server is a scratch lane, not a release gate. Free model access is a budgeted probe, not a blank check. I keep both ideas in one fence file.

Do you keep a fence, or only a chat log? What dies first when the free box disappears tonight?

The point I will not soften

Speed is useless if the session cannot be killed. A green page on a free box proves almost nothing. It does not prove secrets stayed off the box.

It does not prove your laptop can replay the change. Are you debugging the app, or a host that vanished?

What I am willing to claim

I want a scratch lane when the question is still small. Disclosure: This article was prepared as part of MonkeyCode's product outreach. That brief names free model access and a free server option.

The same brief calls the project open source. I still verify the repo license before I depend on it.

I do not have a live quota sheet in front of me. I will not invent model names, caps, or uptime. Check the project docs before you plan a demo.

Docs move, and a blog number goes stale fast. A stale cap in a post is worse than no cap. Would you bet a demo on a number I refused to invent?

How this catalog is built

Each item below has a symptom, a cause, and a fix. I want you to steal the fix, not the slogan. Would you merge a patch you cannot replay tomorrow?

Anti-pattern: no step meter

Symptom: the agent edits files long after the task ends. You look up and the branch is a junk drawer.

Root cause: the prompt never named a maximum step count. Free model access makes that omission feel cheap. Cheap is not the same thing as safe.

Replacement: put max_steps in a card before you prompt. I stop the run when the card hits that number. Do you stop, or do you hope the model gets bored?

Anti-pattern: secrets hitch a ride

Symptom: a dotenv file sits in the folder you upload. The free server boots, and the key boots with it.

Root cause: you treated a scratch box like a private vault. A free option does not change secret handling rules.

Replacement: deny env files and key paths in the card. I refuse the session if those paths exist in the tree. Can you name every secret that left your laptop today?

Anti-pattern: the box never dies

Symptom: an old probe URL still answers a week later. You forgot which task created that public endpoint.

Root cause: the session card never required a teardown step. Free servers still leave traces if you skip cleanup.

Replacement: teardown equals required, or the checker fails. I write the kill command next to the start command. If I cannot kill it, I do not start it.

Anti-pattern: lockfile drift

Symptom: tests pass on the hosted box and fail at home. The import error names a version you do not run.

Root cause: nobody diffed the box image against the lockfile. A free server image is not your source of truth.

Replacement: record the lockfile hash in the session card. I compare that hash before I trust a green log. Which hash did your last green run actually use?

Anti-pattern: live rows in the prompt

Symptom: the prompt includes a real customer email or token. The model reply quotes that row back at you.

Root cause: you used live data because fake data felt slow. Free model access is still a data exit.

Replacement: synthetic fixtures only, checked into a tiny folder. I paste a fixture id, never a production record. Would you read that prompt aloud in a team channel?

Anti-pattern: the scratch host hardens

Symptom: a frontend constant points at the free server host. A teammate clones the repo and hits your old probe.

Root cause: the demo URL never had an expiry note. Replacement: keep the host in an untracked local file.

I add that filename to gitignore before the first commit. Did your last commit contain a host you do not own?

The four moves I make instead

I want one card, one checker, and one local receipt. The card names the task, the cap, and the deny list. The checker fails closed when a required key is absent.

The receipt is a local file, not a chat scrollback. This checker is a proposal I have not executed live. Label it as a sample, then run it on a toy tree.

I write the fence card before I touch the prompt box.
I run the checker and I keep the red output.
I probe on the free server only after a local accept.
I tear the box down and I keep the local receipt.

Sample card and checker

The format below is mine, not a vendor schema. Change the keys if you must, but keep the fail-closed rule.

# session.fence — proposal format, not a product schema
task_id=probe-184
max_steps=12
max_minutes=25
teardown=required
network=off
lock_hash=unset
deny_glob=.env
deny_glob=*.pem
allowed_path=src/parser

#!/usr/bin/env python3
# Proposal checker. Not executed against a live host.
import argparse
import pathlib
import sys

REQUIRED = ('task_id', 'max_steps', 'max_minutes', 'teardown', 'network')

def parse_card(text):
    card = {'deny_glob': [], 'allowed_path': []}
    for raw in text.splitlines():
        line = raw.split('#', 1)[0].strip()
        if not line or '=' not in line:
            continue
        key, val = [part.strip() for part in line.split('=', 1)]
        if key in ('deny_glob', 'allowed_path'):
            card[key].append(val)
        else:
            card[key] = val
    return card

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument('--card', required=True)
    parser.add_argument('--root', default='.')
    args = parser.parse_args()
    root = pathlib.Path(args.root)
    card = parse_card(pathlib.Path(args.card).read_text(encoding='utf-8'))
    missing = [key for key in REQUIRED if not card.get(key)]
    if missing:
        print('fence reject: missing ' + ','.join(missing))
        return 2
    if card.get('teardown') != 'required':
        print('fence reject: teardown must be required')
        return 2
    if card.get('network') != 'off':
        print('fence reject: network must be off for this probe')
        return 2
    try:
        steps = int(card['max_steps'])
        minutes = int(card['max_minutes'])
    except ValueError:
        print('fence reject: caps must be integers')
        return 2
    if steps < 1 or steps > 20 or minutes < 1 or minutes > 40:
        print('fence reject: caps outside the probe window')
        return 2
    hits = []
    for pattern in card['deny_glob']:
        hits.extend(path for path in root.glob(pattern) if path.is_file())
    if hits:
        print('fence reject: denied files present')
        for hit in hits:
            print(hit)
        return 3
    receipt = root / 'tmp' / 'fence-receipt.txt'
    receipt.parent.mkdir(parents=True, exist_ok=True)
    body = 'task_id={}\nmax_steps={}\nlock_hash={}\n'.format(
        card['task_id'], steps, card.get('lock_hash', 'unset')
    )
    receipt.write_text(body, encoding='utf-8')
    print('fence accept: ' + card['task_id'])
    return 0

if __name__ == '__main__':
    sys.exit(main())

Local policy, not a product promise

The numeric caps in code are my policy, not a vendor limit. I picked a small window so a probe cannot wander all day. You should pick your own window, then keep it fail closed.

The receipt stores the task id, the step cap, and the lock hash. It does not store prompts, secrets, or customer rows.

I create the card before I open any chat window. I run the checker from the repo root, not from memory.

mkdir -p scripts tmp
printf '%s\n' 'tmp/' 'session.local.host' >> .gitignore
python3 scripts/fence_check.py --card session.fence --root .
sha256sum package-lock.json | awk '{print $1}'

I store the receipt under tmp, and I commit nothing there. I delete the scratch host before I close the laptop.

A reject on missing teardown is a success, not a bug. A reject on a pem file is the whole point. Do not weaken the card to get a green line.

A table I use before I upload

Situation	Free server probe	Laptop only
Toy bug, synthetic input, teardown written	Allow	Also fine
Dotenv, pem, or a customer row nearby	Deny	Required
You need the run tomorrow, or an audit trail	Deny	Required
Lockfile hash on the host is unknown	Deny	Required
Step cap and kill command already written	Allow	Also fine

I allow a free server only in the probe column. I deny it for secrets, production data, and long jobs. If a row says deny, I stay on my laptop.

Why would you rent risk for a task you can run locally?

Toy test plan

Seed a toy tree with a fake dotenv file. Expect exit code 3, and expect the path printed.

Delete the teardown line and expect exit code 2. Set network to on and expect a hard reject.

Use a clean tree and expect a receipt under tmp. Confirm that receipt path is listed in gitignore.

I treat a failed check as a blocked session, not a warning. I do not continue in chat while the checker is red. Have you ever talked a red gate into silence?

Limits I will not hide

A glob deny list is not a full secret scanner. The checker cannot see steps inside a remote agent. It cannot prove the free server stayed up.

It cannot prove a vendor quota will remain tomorrow. Hash notes do not replace a real lockfile install. Dotfile matches depend on the Python you actually run.

This card does not replace diff review or test ownership. I assume a free server can vanish without notice. Keep a laptop copy, or you do not have a copy.

Who should skip this lane

Skip it if you need an audit letter for a customer. Skip it if the data is regulated or personal. Skip it if the only copy of the work lives remotely.

Skip it if you cannot delete the box the same day. A laptop-only repro is slower, and that is fine. I would rather be slow than stuck with a mystery host.

One next step

Read current MonkeyCode docs before you trust a free lane. Then run a fence card before the first prompt. I would rather you bounce off the checker than leak a key.

DEV Community: Sam Chen

Replayable or It Didn't Happen: Five Anti-Patterns in Free-Model Debugging

Anti-pattern 1: The Single-Run Verdict

Anti-pattern 2: The Vanishing Request

Anti-pattern 3: The Infinite Transcript

Anti-pattern 4: The Assumed-Idle Server

Anti-pattern 5: The Leaky Replay Log

The artifact: a replay harness you can actually keep

The decision table I actually use

Where the free tier fits

Who should not use this approach

The checklist

No Invoice, No Excuse: A Request Ledger for Free Model Access

The five anti-patterns

1. Counting calls instead of work

2. Logging after the retry loop, not inside it

3. Timestamping at write time

4. Buffering rows in memory until exit

5. One error bucket called error

The artifact: a twenty-line ledger

Three queries that pay for the ledger

Where MonkeyCode fits

Reading the diff

What the ledger will not tell you

The Cold Boot Audit: Six Anti-Patterns a Warm Free Tier Hides

The audit is one stdlib file

Force the failure with a read-only root

Six anti-patterns, one check each

1. Cache as a dependency

2. Env edits that only exist on the box

3. IP allowlists that describe the old box

4. /tmp as a database

5. Unpinned installs

6. The invisible boot step

Diff two reports, not two opinions

Where a disposable target and free models help

Who should skip this

The one question before you migrate

Two Sessions, One Repo: Four Drift Anti-Patterns and a Preflight Script

Anti-pattern 1: The Chat-Only Spec

Anti-pattern 2: The Inherited Runtime

Anti-pattern 3: The Unwritten Environment

Anti-pattern 4: The Unbounded Diff

The artifact: one preflight script, run on two boxes

Where the second box comes from

A decision table for what belongs where

What the script will not catch

Who should skip this

The short version

Four Anti-Patterns That Live at the Model Boundary

Why the boundary, not the model

Anti-pattern 1: Stream first, validate never

Anti-pattern 2: The prompt is a string literal

Anti-pattern 3: The anonymous fallback

Anti-pattern 4: No capability contract

A harness you can run in five minutes

What the harness proves, and what it does not

Decision table

Who should skip this

The one habit that survives

Three Retry Anti-Patterns That Quietly Burn a Free Model Quota

The shift that broke old retry code

Anti-Pattern 1: Treating every 429 as a slow-down

Symptoms

Root cause

Replacement pattern

Anti-Pattern 2: Counting tokens after the run

Symptoms

Root cause

Replacement pattern

Anti-Pattern 3: Re-running the whole plan after one bad step

Symptoms

Root cause

Replacement pattern

The decision table I keep next to the loop

Where a free tier actually belongs

Limitations and who should skip this

What to do next

Five Anti-Patterns Before a Free Host Sees Code

The conclusion up front

5. One error bucket called `error`

4. `/tmp` as a database