The Free AI Server Stayed Up for 48 Hours. My Probe Script Was the Fragile Part.

How much can you trust a free AI server with a job that runs while you sleep? That question stopped being theoretical two days ago, when a background summarization task outgrew my laptop and I had nowhere cheap to put it. My budget was zero, my deadline was soft, and the job had to survive two full nights without me watching it. So I pointed a small probe at MonkeyCode's free tier — a 10M-token model allowance plus a free server option, as the current offering was described to me — and started taking field notes.

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

What I was trying to do

The job was deliberately boring: every fifteen minutes, pull the latest items from a handful of RSS feeds, ask the model for a one-sentence summary of each, and append the results to a JSONL file. Nothing user-facing, nothing urgent, and nothing that had to finish by a specific clock time. I wanted to answer one question only: can a free model endpoint and a free server carry a small unattended workload for 48 hours without me holding its hand?

Let me be clear about what this is not: this is not a load test. A load test asks how many requests a server can swallow per minute, and I already wrote that playbook. A survival test asks a quieter question — does your job still exist on Tuesday morning, and is the data still readable when you come back?

The setup, and the one rule I set early

I deployed the probe on the free server option and pointed it at the free model endpoint every 300 seconds. One rule governed everything: write to disk before doing anything clever with the response. A pipeline that parses before it persists is a pipeline that can lose the raw truth forever, and I have been burned by that exact mistake before.

#!/usr/bin/env python3
"""48-hour survival probe for a free model endpoint.

Prints one JSON line per observation to stdout;
redirect stdout to a file so the log survives dropped sessions.
Adjust `payload` to the request shape your endpoint expects.
"""
import argparse, json, time, urllib.request, urllib.error
from datetime import datetime, timezone

def now_iso():
    return datetime.now(timezone.utc).isoformat()

def probe(model_endpoint, health_endpoint, payload, timeout=30):
    row = {"ts": now_iso()}
    try:
        t0 = time.monotonic()
        with urllib.request.urlopen(health_endpoint, timeout=timeout) as resp:
            row["health_status"] = resp.status
            row["health_ms"] = round((time.monotonic() - t0) * 1000, 1)
    except Exception as exc:
        row["health_error"] = f"{type(exc).__name__}: {exc}"
    try:
        req = urllib.request.Request(
            model_endpoint, data=json.dumps(payload).encode(),
            headers={"Content-Type": "application/json"}, method="POST")
        t0 = time.monotonic()
        with urllib.request.urlopen(req, timeout=timeout) as resp:
            row["model_status"] = resp.status
            row["model_ms"] = round((time.monotonic() - t0) * 1000, 1)
            row["usage_header"] = resp.headers.get("X-Usage")
            data = json.load(resp)
            row["output_len"] = len(data.get("text", data.get("output", "")))
    except urllib.error.HTTPError as exc:
        row["model_status"] = exc.code
        row["model_error"] = exc.read().decode("utf-8", "replace")[:200]
    except Exception as exc:
        row["model_error"] = f"{type(exc).__name__}: {exc}"
    print(json.dumps(row), flush=True)

if __name__ == "__main__":
    ap = argparse.ArgumentParser()
    ap.add_argument("--model-endpoint", required=True)
    ap.add_argument("--health-endpoint", required=True)
    ap.add_argument("--interval", type=int, default=300)
    ap.add_argument("--hours", type=float, default=48)
    args = ap.parse_args()
    deadline = time.monotonic() + args.hours * 3600
    payload = {"prompt": "Summarize the attached feed items in one sentence.", "max_tokens": 64}
    while time.monotonic() < deadline:
        probe(args.model_endpoint, args.health_endpoint, payload)
        time.sleep(args.interval)

Run it like this, so a dropped SSH session cannot kill your notes:

nohup python3 probe.py \
  --model-endpoint "$MODEL_URL" \
  --health-endpoint "$HEALTH_URL" \
  --interval 300 --hours 48 \
  >> probe_log.jsonl 2> probe_errors.log &

When the run finishes, this tiny summarizer turns the log into something you can reason about:

#!/usr/bin/env python3
import json, sys

rows = [json.loads(line) for line in open(sys.argv[1]) if line.strip()]
lat = sorted(r["model_ms"] for r in rows if "model_ms" in r)
errs = [r for r in rows if "model_error" in r or r.get("model_status", 200) >= 400]
print(f"observations={len(rows)} errors={len(errs)}")
if lat:
    p95 = lat[min(len(lat) - 1, int(len(lat) * 0.95))]
    print(f"latency p50={lat[len(lat)//2]:.0f}ms p95={p95:.0f}ms max={lat[-1]:.0f}ms")

Field notes

Hour 0–2: the usage header was not where I expected it

I assumed token usage would come back in a response header, and my first draft of the probe trusted that assumption. The header was either absent or named differently than I guessed, which amounts to the same outcome from where I sat. Rather than fight the API contract, I logged what I could actually measure — raw status, latency, and output length — and moved on. The lesson: run a dry run before the real run, and never let your cost accounting depend on a field you have never seen in the wild.

Hour 6: the first request after idle was slow

The health endpoint answered instantly, but the model call right after a quiet stretch took several times longer than the median. I logged it as a data point instead of a failure, because a cold start only becomes an outage when your client timeout is tuned to the median instead of the worst case. Set the timeout for the slowest acceptable response, not the typical one, and your probe will start teaching you things.

Hour 14: my probe script was the fragile part

Here is the honest headline of these notes: the free server never blinked, and I almost lost my entire dataset because of my own laziness. I had been watching the probe's console output through an SSH session, and when that session dropped, everything printed to stdout went with it. I fixed it by redirecting stdout to an append-only file and running under nohup, and after that the log survived every network mood swing. When you evaluate a free server, assume your instrumentation is the weakest link and design accordingly.

Hour 26: a 429 is a schedule signal, not an error

My own loop accidentally fired three requests in quick succession at one point, and the endpoint answered with a 429 that looked alarming in the raw log. I did not retry hot; the job skipped that cycle and ran again on the next 300-second interval, which cost nothing because the work is idempotent. Free tiers enforce fairness by throttling, and the cheapest way to respect that is to let your schedule absorb the rejection instead of hammering the rate-limit window.

Hour 32: my token math drifted

Do the arithmetic with me: 48 hours at one call every 15 minutes is 192 calls, and at roughly 1,000 input tokens plus 1,500 output tokens per call, that lands around 480,000 tokens for the whole run. I planned for that number, then watched my system prompt grow as I added instructions and watched output length creep up with it, which meant my budget model needed a refresh after every prompt edit. The 10M-token allowance handled this workload with room to spare, but the real lesson is the habit — re-run the math whenever the prompt changes, because the next job will not be this small.

Hour 40: the server stayed up; my monitor fell asleep

My health check went silent at hour 40, and for a confusing stretch I thought the free server had finally given up. The truth was more embarrassing: my laptop had gone to sleep, so the only watchdog in the entire setup was the one thing that snoozes. Run the monitor somewhere that does not sleep, or accept the gap and make sure your workload never depends on the monitor being awake.

Hour 48: what I would repeat

• Append-only JSONL with flush-on-write, because losing raw observations teaches you nothing.
• A warm-up request after every idle stretch, so cold starts happen on my terms instead of on the first real call of the day.
• Treating 429 responses as "skip this cycle" rather than retrying, because idempotent work forgives a missed slot.
• Logging a snippet of the raw response when something fails, so the error is debuggable at 3 AM.

And what I would drop: retrying inside the same cycle, trusting a usage header before a dry run, and storing any state in memory that a dropped session can take with it.

When this setup fits, and when it does not

If your job...	A free model tier plus a free server...
Runs on a schedule and tolerates a skipped cycle	fits well
Is idempotent and logs before parsing	fits well
Needs a hard completion deadline	does not fit; use a paid tier with an SLA
Returns responses to a waiting user	does not fit until you measure p95 under real traffic
Bursts to hundreds of concurrent calls	does not fit; throttle it or batch it

Honest limitations

A 48-hour run is a sample, not a guarantee; a full week changes the picture, and free-tier terms and quotas can change underneath you. The 10M-token allowance and the free server option are the offering as it was described to me at the time of writing, so verify the current terms and the project's own docs before building anything on top of them. I measured a single workload shape against a single endpoint, so your latency distribution will differ, and this is neither a security review nor a benchmark of the platform.

If you run this probe against your own free endpoint for even one night, I would genuinely like to see the resulting JSONL, because the most informative line is always the error you did not expect. That is why I kept the script stupid and the log raw — and it is the same reason the free server survived while my probe nearly did not.