Five Free-Tier Myths That Break Your First Deploy (and a 60-Line Probe to Test Them)

My script worked at 11pm. At 9am it returned 502.

Nothing in my code changed. The host did. That gap is where most "free tier" advice goes wrong.

Everyone is shipping small AI tools right now. Free model access plus a free server option makes the first deploy feel free. It is not free of physics.

Here are five claims I keep reading. Each one has a cheap probe.

Myth 1: "A free server is an always-on server"

It is usually an idle-tolerant server. That is different.

Many free hosts suspend an instance after a quiet window. The next request pays the wake-up cost. Your first user of the morning gets the bill in latency.

Ask yourself: did I ever measure the first request after five minutes of silence?

If not, you measured the warm path. The warm path is not the path your users take.

Myth 2: "Local disk is disk"

On my laptop, a file I write stays written. On a free host, it often does not.

Some free tiers give you an ephemeral filesystem. It survives the request and dies with the instance. The next request may land somewhere else entirely.

So your "cache" is a coin flip. Your SQLite file is a coin flip. Your uploaded temp file is a coin flip.

Is that a bug in the platform? No. It is a missing line in your assumptions.

Myth 3: "A token allowance is a rate limit"

These are two different ceilings. You hit whichever is lower.

A token allowance is a budget. A rate limit is a speed. A burst of 30 tiny requests can trip the speed ceiling while the budget is barely touched.

So "I have plenty of tokens left" proves nothing about throughput. It only proves you have budget left.

Count requests per minute, not tokens per month.

Myth 4: "Concurrency is a config flag"

A single worker process handles one request at a time. Set workers=8 and you have eight. Set nothing and you have a queue.

Your five parallel calls do not run in parallel. They wait in line. The last one measures the sum, not the max.

Does that matter for a demo? No. Does it matter the moment two people click at once? Yes.

Myth 5: "A 200 from /health means the service works"

A shallow health check tests the web server. It does not test the model call.

Your /health returns {"ok": true} while the upstream model is timing out. Your uptime monitor is green. Your users are not.

A health check that never touches the dependency is decoration.

The probe: five checks, one script

Here is the artifact. It is stdlib-only Python. Point BASE_URL at your own deployment.

#!/usr/bin/env python3
# probe.py - five free-tier checks against your own deployment. stdlib only.
import json, os, statistics, time, urllib.error, urllib.request
from concurrent.futures import ThreadPoolExecutor

BASE = os.environ["BASE_URL"].rstrip("/")

def call(path, payload=None, timeout=60):
    data = None if payload is None else json.dumps(payload).encode()
    req = urllib.request.Request(
        BASE + path, data=data, headers={"content-type": "application/json"}
    )
    t0 = time.perf_counter()
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            return r.status, r.read()[:300], round((time.perf_counter() - t0) * 1000)
    except urllib.error.HTTPError as e:
        return e.code, e.read()[:300], round((time.perf_counter() - t0) * 1000)
    except Exception as e:
        return 0, str(e).encode()[:300], round((time.perf_counter() - t0) * 1000)

def check_disk():
    token = str(int(time.time()))
    call("/note", {"text": token})
    code, body, _ = call("/note")
    print(f"[2] disk: wrote {token}, survived={token.encode() in body}")

def check_rate(n=30):
    codes = [call("/generate", {"prompt": "ping"})[0] for _ in range(n)]
    print(f"[3] burst: {n} calls -> {sorted(set(codes))}, 429s={codes.count(429)}")

def check_concurrency(n=5):
    with ThreadPoolExecutor(max_workers=n) as pool:
        times = [r[2] for r in pool.map(lambda _: call("/generate", {"prompt": "ping"}), range(n))]
    print(f"[4] parallel: n={n} median={statistics.median(times)} ms max={max(times)} ms")

def check_deep_health():
    code, body, _ = call("/health?deep=1")
    print(f"[5] deep health: {code} {body[:80]!r}")

def check_sleep(idle_seconds=300):
    print(f"[1] idling {idle_seconds}s before the wake-up call")
    time.sleep(idle_seconds)
    code, _, ms = call("/generate", {"prompt": "ping"})
    print(f"[1] cold path: {code} in {ms} ms")

if __name__ == "__main__":
    check_disk()
    check_rate()
    check_concurrency()
    check_deep_health()
    check_sleep()  # slow on purpose; run it last

The endpoints the probe expects

The probe is generic. Your app has to expose four paths. This is a contract, not a framework.

The deep health handler is the one people skip. Here is the shape I use:

@app.get("/health")
def health(deep: int = 0):
    if not deep:
        return {"ok": True}
    try:
        ask_model("ping")  # your actual model call, small prompt
        return {"ok": True, "dep": "up"}
    except Exception as e:
        return JSONResponse({"ok": False, "err": str(e)[:200]}, status_code=503)

Thirty lines of app. Sixty lines of probe. That is the whole setup.

Read the output like an operator

Do not just stare at numbers. Map each signal to a decision.

Run it twice. Once right after deploy, once after a quiet hour. The second run is the honest one.

Where MonkeyCode's free options fit

I used the free model access for the /generate call and the free server option to host the reference app. Both are operator-supplied availability claims. Check the project page for current limits before you plan anything around them, because free tiers move.

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

The honest framing: it is an open-source project that removes the setup cost of a first AI-backed tool. It does not remove the constraints above. Nothing does.

What it gave me was a target. A deployed app I could point BASE_URL at in under an hour. That is worth more than a feature list, because the probe needs something real to hit.

Limitations of this approach

• The probe measures your deployment, not the platform's SLAs.
• One run is a snapshot. Free tiers change policy without a changelog email.
• A 300-second idle window is a guess. Your host may use a different one.
• The burst test can trip abuse protections. Keep n small and run it once.
• These numbers say nothing about output quality. That is a separate test.

Who should not use this

If you need a hard uptime guarantee, skip free tiers entirely. Buy the SLA.

If your workload needs persistent local disk, skip it too. You will fight the filesystem every week.

If you handle regulated data, do not deploy to a shared free host to save an afternoon.

And if you cannot re-run the probe after each platform change, you are guessing again. Guessing is fine for a weekend demo. It is not fine for anything with users.

My ask

Run the probe before you write the launch post.

If you try MonkeyCode's free options, post your table — cold path, burst codes, parallel median. I would rather read your numbers than another thread about how free it all is.