Probing a Free Tier Before You Hand It an Agent

Illustrative scenario, not a record of a run: a small team wants to move a nightly agent loop — read an issue, propose a patch, run the test suite, open a PR — off a paid runner and onto a free-tier workspace. Before moving anything, they want three answers. Does the workspace remember yesterday's state? Can model spend be attributed to a phase? What happens to a half-finished job when the machine restarts at 03:00?

Those are testable questions. None of them require trusting a landing page, and none of them require you to run an expensive benchmark first.

Question one: what survives a restart

The cheap version of "is my data persistent?" is a marker file with a timestamp. Write it on the first visit, read it on the second, and compare the hostname as well as the clock. The script below is illustrative and has not been executed for this article; treat it as a specification you can adapt, not as a result.

#!/usr/bin/env bash
# probe.sh — illustrative, unexecuted. Records what a workspace remembers between visits.
set -euo pipefail

PROBE_DIR="${PROBE_DIR:-$HOME/.agent-probe}"
mkdir -p "$PROBE_DIR"

stamp() { date -u +%Y-%m-%dT%H:%M:%SZ; }

if [[ -f "$PROBE_DIR/visits.log" ]]; then
  printf 'return-visit %s host=%s\n' "$(stamp)" "$(hostname)" >> "$PROBE_DIR/visits.log"
else
  printf 'first-visit  %s host=%s\n' "$(stamp)" "$(hostname)" >> "$PROBE_DIR/visits.log"
fi

{ uname -a; git --version 2>/dev/null || echo 'git: absent'; } | tee "$PROBE_DIR/env.txt"

visits=$(wc -l < "$PROBE_DIR/visits.log")
echo "visits=$visits"
[[ "$visits" -ge 2 ]] && exit 0 || exit 10

Run it once, close the session, come back later, run it again. Exit code 10 on the second run means the directory did not persist; exit 0 with two timestamps means it did. The hostname column is the part people skip — if it changes between visits, you are on a different machine and any "state" you observe belongs to shared storage, not to the process you left behind.

Question two: can you attribute token spend

A single number at the end of a run tells you almost nothing. What you want is a per-phase ledger, written by your own code, so a surprising total can be pinned to planning, patching, or verification instead of blamed on the model.

ledger() { # $1 = phase, $2 = free-text note
  printf '{"ts":"%s","phase":"%s","note":"%s"}\n' \
    "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$1" "$2" \
    >> "$PROBE_DIR/token-ledger.jsonl"
}

ledger plan   "context sent before any file was touched"
ledger patch  "call that produced the diff"
ledger verify "test output fed back into the loop"

This ledger records your side of the conversation, not the provider's counter, so the only useful reading comes from comparing the two pairwise. If the provider's number grows faster than your estimate, the usual cause is context being resent on each turn rather than the diff itself being large. That distinction matters because it changes the fix: trim the prompt, not the patch.

Question three: what a restart does to a half-finished job

The restart problem is an idempotency problem, and it is cheap to handle if you decide the trade-off in advance. Hash the issue identifier together with the base commit, write the hash after the patch lands, and skip work you have already done.

key=$(printf '%s' "${ISSUE_ID}:${BASE_SHA}" | sha256sum | cut -d' ' -f1)
if grep -qx "$key" "$PROBE_DIR/done.keys" 2>/dev/null; then
  echo "already applied: $key"; exit 0
fi
# ... apply patch here ...
printf '%s\n' "$key" >> "$PROBE_DIR/done.keys"

Be honest about the boundary: writing the key and applying the patch are two operations. A crash between them leaves you either a duplicate patch or a skipped job, and no amount of shell arithmetic removes that window. Pick the failure you can tolerate, and log enough to detect that you hit it.

What belongs on a free tier at all

Workload	Keep it local	Reasonable on a free workspace
Repository with production secrets in history	Yes	No
Public repo, short test suite	—	Yes
Builds over roughly an hour	Yes	Usually no, restarts hurt
Prompt or model regression checks	—	Yes, if you store outputs
Anything needing a pinned model version	Yes	Verify first

Read the table as a starting position, not a ruling. The middle column matters more than the right one.

Where this probe is blind

A free allowance rarely comes with a pinned model version, so a prompt that behaved on Monday can behave differently on Friday without anyone shipping code. Keep a golden set of ten to twenty prompts and diff the outputs across days; that is the only drift detection that survives an opaque upgrade. The probe also says nothing about network egress, disk ceilings, or how long an idle workspace stays alive, and those limits are exactly the ones that change quietly.

Where a project like MonkeyCode fits

Nothing above is specific to one provider — the probe works against any workspace. The reason to point it at MonkeyCode is the combination on offer: an open-source project with free model access and a free server option, both operator-supplied statements rather than things this article measured. The operator states the free allowance is on the order of ten million tokens; I have not verified that figure, and allowances of this shape change often, so read the current number on the project's own page before you size a workflow around it.

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

The honest placement is narrow. Use it for the probe itself, for prompt regression runs, and for short-lived experiments where a lost workspace costs you ten minutes. Do not treat it as a CI replacement for a team that needs a service-level commitment, and do not put private repositories on it until you have read its documentation and your own policy.

Who should not use this approach

If your agent touches customer data, regulated code, or anything you would not paste into a public issue, stop at the table above and keep the loop local. If reproducibility is a requirement, a free tier with a floating model version is the wrong substrate regardless of price. And if you cannot spare two sessions to run a probe, you certainly cannot spare the afternoon a silent restart will cost you later.

Run the probe twice if you try this, and keep both visit logs next to the ledger. That comparison will tell you more about whether the workspace is ready for your loop than any first-impression review, including this one.