Free Compute Is a Lease, Not a Gift

Free tiers are great for disposable work. They are terrible for load-bearing work. Pick that boundary before you pick a product.

I keep seeing the same failure. A team gets free model access and a free server. Two weeks later, a cron job, a dashboard, and someone's demo all depend on it. Nobody knows when it stops, or what breaks first.

The cost was never the problem. The missing contract was.

The free tier problem is drift, not price

Free resources do not fail politely. They expire, throttle, or vanish while your job is mid-write.

Three failure modes show up again and again:

1. Time drift. The box outlives your attention. Nobody remembers the expiry date.
2. Spend drift. Token usage creeps until the ceiling hits during a demo.
3. State drift. The only copy of a result lives on a machine with no promise of tomorrow.

None of these are billing problems. All three are contract problems.

Write the contract as a lease

My position is simple. Every experiment on free capacity gets a lease file, and nothing runs without one.

A lease has three required fields and one optional one:

• Deadline. An absolute UTC timestamp, never "in two hours."
• Token ceiling. A hard number, not a vibe.
• Sink. A durable path outside the free machine where results land.
• Teardown. The command that revokes access and stops work.

Here is the file. Copy it, edit it, keep it in git next to the code it governs.

{
  "id": "exp-2026-10-20-a",
  "deadline_utc": "2026-10-20T18:00:00+00:00",
  "token_ceiling": 200000,
  "usage_file": "usage.json",
  "sink": "results/exp-2026-10-20-a.jsonl",
  "teardown": "./teardown.sh"
}

Two details matter more than they look. The deadline is absolute, so timezone bugs cannot extend it. The sink is a path in your repo, so the free box is never the system of record.

A gate that refuses to start

The point of a gate is refusal. A warning you can ignore is decoration.

This script is plain Python 3.11 with no dependencies. Review it before you run it. It exits non-zero when the lease is invalid.

#!/usr/bin/env python3
"""lease_check.py - refuse to start when the lease is invalid."""
import json
import sys
from datetime import datetime, timezone
from pathlib import Path

LEASE = Path("lease.json")

def main() -> int:
    lease = json.loads(LEASE.read_text())
    deadline = datetime.fromisoformat(lease["deadline_utc"])
    left = (deadline - datetime.now(timezone.utc)).total_seconds()

    usage = Path(lease["usage_file"])
    spent = json.loads(usage.read_text())["tokens"] if usage.exists() else 0
    ceiling = int(lease["token_ceiling"])

    if left <= 0:
        print(f"REFUSE: lease {lease['id']} expired {-left / 60:.0f} min ago")
        return 2
    if spent >= ceiling:
        print(f"REFUSE: {spent}/{ceiling} tokens spent, write the sink")
        return 3

    print(f"OK: {left / 60:.0f} min left, {ceiling - spent} tokens left")
    return 0

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

Wire it in front of your runner, not inside it. One line, hard stop.

python3 lease_check.py || exit 1
python3 run_experiment.py \
  --out results/exp-2026-10-20-a.jsonl \
  --max-tokens 200000

The ceiling is enforced twice on purpose. The gate blocks a bad start. The runner caps a long one.

Teardown must be boring

Teardown is where free tiers actually get abandoned. Make it three steps, in this order.

1. Stop work. Nothing should write after the sink closes.
2. Flush the sink. Commit before you delete anything.
3. Revoke access. Credentials die last, so recovery stays possible.

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

lease_id="$(jq -r .id lease.json)"

pkill -f "experiment:${lease_id}" || true

test -s "results/${lease_id}.jsonl" || {
  echo "refuse teardown: sink is empty"; exit 1
}
git add "results/${lease_id}.jsonl"
git commit -m "sink: ${lease_id}" || true

rm -f .env.local || true
echo "torn down ${lease_id}"

Run it twice. It should succeed both times. A teardown that only works once is a cleanup task, not a contract.

What belongs on free capacity

Workload	Use free capacity?	Reason
Throwaway benchmark harness	Yes	Replaceable, results already in git
Prompt regression suite	Yes	Fixed inputs, small deterministic outputs
Cron job that pings customers	No	Needs uptime and durable state
The only copy of a dataset	No	Sink rule violated at day zero
Long training run	No	The lease expires mid-run
Integration tests with scoped keys	Yes	Rotatable credentials, no customer data

Read the table as a filter, not a ranking. The question is never "is this free?" The question is "is this disposable?"

What hurts, and who should walk away

This pattern has real costs. Say them out loud before adopting it.

• Teardown can fire mid-run and kill a slow experiment. Budget for retries.
• Token counting differs between providers. Treat your ceiling as approximate, then subtract a safety margin.
• The lease file is a new artifact to review. Small, but not zero.
• A ceiling cannot rescue a bad prompt. It only limits the damage.

Do not use this approach if you need an uptime commitment, a compliance audit trail, or regulated data handling. Do not use it if nobody on the team will own the deadline. A lease with no owner is a countdown timer nobody watches.

Where MonkeyCode fits

The pattern above needs cheap, expendable capacity. That is exactly what free tiers are good at, and nothing more.

MonkeyCode is an open-source project that offers free model access and a free server option. The operator indicates a 10M-token allowance as part of that offer. I am not going to dress that up as an architecture. It is capacity, and capacity needs a contract.

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

Use it as the first row of the table. Run a harness, write to a git sink, tear the box down, and keep the results. If you want to test the lease pattern without spending money, that is a reasonable place to start.

My closing position

Measure free resources in minutes and tokens, not in gratitude. A tier you cannot expire is a dependency you did not choose.

Write the lease first. Then pick the platform. The order matters more than the tool.