Audit Your Free AI Coding Tier: Five Claims, One Run Ledger

It is 23:40, and the same prompt has produced a clean patch in one browser tab and a mangled one in another, so you start deleting variables: model, timezone, working directory, that stray file from three commits ago. Two hours later you have a diff you cannot explain and a suspicion that the free tier you are leaning on is not the thing you think it is. The uncomfortable part is that most of these questions do have answers, but only if you recorded evidence while the run was still happening.

The five claims below are the ones I keep seeing repeated in free-tier discussions, and each one gets the same treatment here: state it plainly, try to falsify it with a command you can run, then write down the mental model that survives. The artifact is a small run ledger you can drop into any repository in about fifteen minutes. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I mention the project's free model access and free server option later because they are what I used to run the loop, but the harness itself is provider-agnostic and wraps any CLI you can invoke.

Myth 1: The free token allowance is a budget

The claim sounds reasonable enough: you have a fixed amount of free usage, therefore you have a budget, therefore you can plan work around it. What a token allowance actually limits is consumption, while the thing that decides whether your week goes well is the number of runs that end in an accepted change. Two developers can burn identical token counts and get wildly different value, because one retries a failing prompt eleven times while the other spends one run writing a test first. Replace the budget metaphor with a yield metric, and the allowance stops being a planning input.

The metric worth tracking is tokens or runs per accepted change, where "accepted" means a human reviewed the diff and kept it. That annotation is one extra line after review:

# after human review, mark the run as kept
printf '{"run_id":"%s","kept":true}\n' "$RUN_ID" >> run-ledger.jsonl

Myth 2: A free server is a pinned environment

The claim goes: if the code executes on the provider's machine, the environment is fixed, therefore the results are reproducible. A remote machine fixes where the process runs, not what the process sees, and those two things are easy to confuse when the workspace persists between sessions. Timezone, locale, installed tool versions, and a dirty working tree all float unless something captures them at run time. The model that survives is simple: a server is a location, a fingerprint is an environment, and only the fingerprint travels with the run.

Myth 3: The same model label means the same behaviour

If both runs report the same model name, the outputs should be comparable, or so the claim goes. Sampling defaults, context truncation, hidden system prompts, and routing between backends all break that assumption quietly, and none of them appear anywhere in the model label. Compare runs by input and environment fingerprint instead, and treat the label as a hint rather than a guarantee. When two runs disagree, the fingerprint tells you whether you changed something or the service did.

Myth 4: A zero exit status means a verified run

Exit status 0 only means the process finished without signalling an error, which is fully compatible with an empty patch, a patch to the wrong file, or a test suite that quietly skipped itself. Hash the artifacts and compare them against an expected digest, and the green checkmark becomes evidence rather than vibes. The check is one line in CI or your shell:

sha256sum -c expected.sha256   # fails loudly when the artifact drifts

Myth 5: Free means the run costs nothing

The tokens may cost nothing, but the review never does, because every unrecorded run pushes work onto a human who must reconstruct context later. Recording a fingerprint and a log hash while the run is in flight costs a few seconds and removes most of that future reconstruction. The number that matters is not price per token but elapsed human minutes per accepted change.

The artifact: a fifteen-minute run ledger

The harness wraps any CLI invocation, computes an environment fingerprint, times the run, and appends one JSON line per execution. Treat it as a template rather than a tested release: run shellcheck over it, and adapt the command capture to whatever your agent CLI actually accepts.

#!/usr/bin/env bash
# run-ledger.sh — record what one AI coding run actually depended on.
set -euo pipefail

LEDGER="${LEDGER:-./run-ledger.jsonl}"
RUN_ID="${RUN_ID:-$(date -u +%Y%m%dT%H%M%SZ)-$$}"
RUN_CMD="${RUN_CMD:?export RUN_CMD to the CLI invocation you want to audit}"

fingerprint() {
  {
    uname -srm
    printf 'TZ=%s LC_ALL=%s LANG=%s\n' "${TZ:-unset}" "${LC_ALL:-unset}" "${LANG:-unset}"
    python3 -c 'import platform;print("python",platform.python_version())' 2>/dev/null || true
    node --version 2>/dev/null || true
    git rev-parse HEAD 2>/dev/null || echo no-git
    git status --porcelain 2>/dev/null | sha256sum | cut -c1-16
  } | sha256sum | cut -c1-16
}

FP="$(fingerprint)"
started="$(date +%s)"
set +e
LOG="$(eval "$RUN_CMD" 2>&1)"
STATUS=$?
set -e
finished="$(date +%s)"

python3 - "$RUN_ID" "$FP" "$STATUS" "$((finished - started))" "$LOG" "$LEDGER" <<'PY'
import hashlib, json, sys
run_id, fp, status, seconds, log, ledger = sys.argv[1:7]
record = {
    "run_id": run_id,
    "env_fingerprint": fp,
    "exit_status": int(status),
    "wall_seconds": int(seconds),
    "log_sha256": hashlib.sha256(log.encode()).hexdigest()[:32],
    "log_bytes": len(log.encode()),
}
with open(ledger, "a", encoding="utf-8") as fh:
    fh.write(json.dumps(record, sort_keys=True) + "\n")
print(json.dumps(record, sort_keys=True))
PY

Two runs, one variable, and a comparison that takes four seconds is the whole point of the exercise:

RUN_CMD='your-agent-cli --prompt "add a retry test for fetch_user"' ./run-ledger.sh
TZ=Asia/Tokyo RUN_CMD='your-agent-cli --prompt "add a retry test for fetch_user"' ./run-ledger.sh
jq -r '[.run_id,.env_fingerprint,.exit_status,.log_sha256]|@tsv' run-ledger.jsonl

If both rows carry the same fingerprint but different log hashes, you now have evidence that behaviour moved outside your control, which is a claim you could not have made last night. Running a loop like this needs two things: somewhere to execute it and something to execute it with, which is where the project's operator-supplied free tier becomes relevant, since it advertises free model access for the agent call and a free server option for hosting the ledger job. Token allowances, model line-ups, and server specifications change without notice, so read the project's current page before you plan a quarter around any of them. If you want to try the harness end to end, wrap a single command first and confirm one accepted change before automating anything.

Choosing your level of evidence

Situation	What the ledger alone buys you	What you should add
Learning an API, one-off scripts	Drift detection between attempts	Nothing more; keep it disposable
Shared repository with several contributors	A shared record of what each run saw	Commit fingerprints in the PR template
Recurring flaky agent behaviour	Proof that inputs were identical	Raw fingerprint text, not only the hash
Deterministic fixtures or snapshot tests	Almost nothing	Pinned toolchain and a fixed sampling setup
Regulated audit evidence	Not sufficient on its own	Your existing signed, tamper-evident tooling

Limitations and who should not use this

The ledger only measures what you wrap, so any work that happens inside a chat window and never reaches the command line stays invisible to it. Hashing a log detects drift but says nothing about correctness, which means the harness is a complement to tests you already trust, never a replacement. Because the fingerprint is a hash, it tells you that something changed rather than which variable changed, so print the raw block as well while debugging. Anyone who needs a signed, tamper-evident audit trail should keep using their compliance tooling instead of a personal JSONL file, and anyone whose runs are purely interactive and never revisited should skip the recording tax entirely, since it buys nothing without review.

These myths survive because each one saves a little effort today and charges interest tomorrow, which is exactly the trade a free tier makes easy to accept. If you keep only two habits from this, keep the fingerprint and the log hash, because together they answer the question that started the night. Then run the same prompt twice tomorrow with a different TZ, and let the ledger tell you which part of the system you actually control.