A solo founder ships a small internal tool on a Friday night. It calls a hosted model a few hundred times a day. It runs on one small box. By Monday the disk is full and the spend log is a guess.
Free infrastructure makes that Monday cheap to reach. MonkeyCode offers free model access and a free server option, according to the operator's own description. That is enough to ship. It is not enough to sleep.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
The real gap is not price. The gap is two missing guards. One guard caps spend before a request leaves the process. The other guard reports death before a user does.
Guard one: a ledger that refuses
A token cap in your head is not a cap. A cap needs a row in a database and a refusal path. The snippet below uses only the Python standard library.
It reserves budget with an idempotency key, so a retry cannot double-charge you. It returns False instead of raising, so the caller decides what a refusal means.
# budget.py (Python 3.9+, stdlib only)
import os, sqlite3, time
DB = os.environ.get("LEDGER_DB", "ledger.db")
CAP = int(os.environ.get("DAILY_TOKEN_CAP", "200000"))
SCHEMA = """
CREATE TABLE IF NOT EXISTS spend(
key TEXT PRIMARY KEY,
day TEXT NOT NULL,
tokens INTEGER NOT NULL,
created INTEGER NOT NULL);
CREATE INDEX IF NOT EXISTS spend_day ON spend(day);
"""
def connect(path=DB):
con = sqlite3.connect(path, isolation_level=None, timeout=5)
con.executescript(SCHEMA)
return con
def used_today(con, day):
q = "SELECT COALESCE(SUM(tokens),0) FROM spend WHERE day=?"
return con.execute(q, (day,)).fetchone()[0]
def reserve(con, key, tokens, day=None):
"""True if the budget allows it, False if the day is spent."""
day = day or time.strftime("%Y-%m-%d")
con.execute("BEGIN IMMEDIATE")
try:
con.execute(
"INSERT INTO spend(key,day,tokens,created) VALUES(?,?,?,?)",
(key, day, tokens, int(time.time())))
if used_today(con, day) > CAP:
con.execute("ROLLBACK")
return False
con.execute("COMMIT")
return True
except sqlite3.IntegrityError:
con.execute("ROLLBACK")
return True # same key seen before: already reserved
The reservation lands before the network call. That ordering matters. A crash after the write costs you a few tokens. A crash before the write costs you the cap.
Estimate tokens roughly as characters divided by four, plus your max output. Rough numbers are fine here. The ledger protects a budget, not an invoice.
# worker.py
import os, uuid
from budget import connect, reserve
def estimate(prompt, max_out=600):
return len(prompt) // 4 + max_out
def run(prompt):
con = connect()
key = uuid.uuid4().hex # reuse this key on retries
if not reserve(con, key, estimate(prompt)):
return {"ok": False, "reason": "daily_cap_reached"}
return call_provider(prompt, key) # your HTTP call, same key on retry
def call_provider(prompt, key):
base = os.environ["PROVIDER_BASE_URL"] # from your provider's docs
raise NotImplementedError((base, key))
Set the base URL and key from environment variables. Read the provider's current docs for the exact path and model identifier. Do not hardcode either one in the repository.
The operator currently advertises a free token allowance in the millions. Terms change without notice. Read the live page before you design against any number.
Guard two: a watchdog that speaks
A free server fails quietly. The process stays "up". The disk fills. Requests time out. Nobody notices until a customer writes in.
A watchdog is three checks and a file. Disk, memory, and service state. Write the result as JSON, then alert once.
#!/usr/bin/env bash
# /opt/guards/watchdog.sh
set -uo pipefail
SERVICE="${SERVICE:-monkeyworker}"
DISK_MAX="${DISK_MAX:-85}"
HB="${HEARTBEAT:-/var/tmp/heartbeat.json}"
fail=0
disk=$(df -P / | awk 'NR==2{gsub("%","",$5); print $5}')
mem=$(free -m 2>/dev/null | awk '/Mem:/{printf "%d", $7*100/$2}')
state=$(systemctl is-active "$SERVICE" 2>/dev/null || echo unknown)
[ "${disk:-100}" -ge "$DISK_MAX" ] && fail=1
[ "$state" != "active" ] && fail=1
printf '{"ts":%s,"disk_pct":%s,"mem_avail_pct":%s,"service":"%s","ok":%s}\n' \
"$(date +%s)" "${disk:-0}" "${mem:-0}" "$state" \
"$([ $fail -eq 0 ] && echo true || echo false)" > "$HB"
[ $fail -eq 0 ] || curl -fsS -m 5 -X POST "${ALERT_URL:-}" -d @"$HB" || true
exit $fail
Run it from cron every five minutes. Keep the exit code. A non-zero exit is the alert channel of last resort.
chmod +x /opt/guards/watchdog.sh
*/5 * * * * /opt/guards/watchdog.sh >> /var/log/watchdog.log 2>&1
Supervise the worker with a real unit file. Restart on failure. Cap restarts so a crash loop cannot spin forever.
# /etc/systemd/system/monkeyworker.service
[Unit]
Description=indie worker
After=network-online.target
[Service]
ExecStart=/usr/bin/python3 /opt/app/worker.py
Restart=on-failure
RestartSec=10
StartLimitBurst=5
EnvironmentFile=/opt/app/.env
[Install]
WantedBy=multi-user.target
A reproducible check
The guards are testable without a provider. Set the cap to three and force five reservations with distinct keys. Exactly three should pass.
DAILY_TOKEN_CAP=3 python3 - <<'PY'
from budget import connect, reserve
con = connect(":memory:")
print([reserve(con, f"k{i}", 1) for i in range(5)])
PY
# expected: [True, True, True, False, False]
Force the watchdog to fail on purpose, then confirm the exit code. A guard you never saw fail is a guard you cannot trust.
DISK_MAX=0 HEARTBEAT=/tmp/hb.json ./watchdog.sh; echo "exit=$?"
cat /tmp/hb.json
# expected: exit=1 and "ok":false
Where the free path fits
| Situation | Free server and free models |
|---|---|
| One internal tool, low traffic | Fits. Ship today. |
| Weekend prototype, real users | Fits, with the two guards. |
| Paid customers, uptime promise | Pay for capacity. |
| Regulated data, audit trail | Not here. |
The pattern is the same in every row. Free buys time. Guards buy sleep.
What this approach will not do
One box is not a cluster. A reboot is still downtime. A watchdog detects failure, it does not prevent it.
A ledger caps your own usage. It cannot stop a provider from changing the allowance. Keep the cap below the advertised number, and keep the alert on.
The tool also assumes a Linux box with systemd, curl, and df. Strip those and the shell script is a skeleton, not a product.
Teams with a p95 latency target should not ship this way. Anyone storing payment data should not either. A pricing error that touches money needs a human review step, not a cron job.
The part worth copying
Write down your failure budget before launch. One reboot per week is acceptable. One silent disk fill is not. Then make each guard produce evidence.
If the free tier is the reason you can ship this month, start with the two scripts above. The MonkeyCode free model access and free server option are worth a look for exactly that use case. Verify the current terms first, then put a cap on the number that matters to you.
Top comments (0)