FAQ: A Free Model Lease Is Not a Server Lease

Your free model just said the patch landed cleanly. Did the free server actually accept that same patch? I keep seeing this leap in review threads.

A cheap answer turns into a deploy story fast. Then that box still serves yesterday's old binary. Who actually owns that gap in your story?

Why does this myth keep winning?

People still love one receipt for two separate gifts. A free model session feels like real compute. A free server option feels like real hosting.

I keep hearing them merged into one stack. That quiet merger is the actual bug here. Those two leases can fail on their own.

MonkeyCode offers free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I treat those lines as availability claims only.

I do not treat them as a quota sheet. I will not invent model names in this note. I will not invent hardware or duration either.

If a console shows numbers, those numbers win. A screenshot from last month is not a contract. Write the date next to any number you paste.

Which claims keep showing up?

These lines show up after a green chat. Each one sounds practical at first quick glance. Each one quietly skips a real host receipt.

1. "The model wrote the file, so the server has it."
2. "The free box is up, so the model saw my repo."
3. "One retry covers both the chat and the host."
4. "Free access means this path is a release path."
5. "A health URL alone proves the patch bytes."

Do you want a cleaner mental model now? I split this world into two separate ledgers. A model ledger records only the model calls.

A server ledger records files and live processes. Neither ledger inherits the other side's lease. You store both lines before you claim a win.

Myth 1: Is the reply the diff?

The model can describe a file almost perfectly. That text still lives only in the transcript. It is still not an inode on the host.

I ask one blunt question every single time. Where is the content hash from that host? If you cannot paste it, you do not have a diff.

Corrected model: generation is not the same as placement. Placement still needs a write on that host. Then you hash the exact path you named.

Myth 2: Did a live box see the repo?

A free server can boot with an empty home. Your repo may sit only on your laptop. Uptime alone does not mount your git remote.

I check three facts before I trust a read. Which user account is actually running that process? Which directory is the real current working directory?

Which git remote URL is actually configured there? I write those three answers in the note. I do not accept a shrug as an answer.

Corrected model: reachability is not the same as context. Real context means a cwd plus working credentials. Without those facts, the model is only guessing.

Myth 3: Can one retry heal both sides?

A model retry only spends another model call. A server retry restarts a process or job. Those clocks are not the same clock.

People mash one shared button for both failures. The chat pane retries all on its own. The host still keeps the old process running.

Which failure did you actually mean to hit? Name it in the note before you click again. A second click without a name is noise.

Corrected model: name the failing ledger before you retry. You then retry only that one failing ledger. Record the new id beside the old id.

Myth 4: Does free mean release-ready?

Free access only answers a narrow cost question. It does not answer a real promotion question. A real release needs owners, logs, and rollback.

I would not ship customer traffic this way. A small demo can still live here safely. A production pager should not depend on this.

Corrected model: price and promotion are different gates. You should pass the cheap gate first here. Then you pass the release gate on purpose.

Myth 5: Does health prove the bytes?

A 200 from /health means the process answered. It does not mean your patch is on disk. It does not mean the model read that disk.

I want a content hash, not a smile code. You compare the content hash you actually expected. Then compare the hash the host actually prints.

Corrected model: liveness is not the same as integrity. Integrity is a digest over the named path. Liveness is only a short timeout story here.

What is the corrected picture?

Hold two leases in your head at once. A model lease buys only fresh text generation. A server lease buys a place to run.

A lease does not copy files by sympathy. A lease does not share retries with the other. You reconcile them with hashes and call ids.

A two-ledger decision table

Use this table before you start the argument. Pick the row that actually matches the evidence. Do not pick the row that matches the vibe.

Evidence you hold	Model ledger	Server ledger	What you may claim
Transcript only	Call happened	Unknown	The model spoke
Host hash only	Unknown	File exists now	The box has bytes
Both ids and same hash	Call happened	Write matches	Placement matched this call
Health 200 only	Unknown	Process answered	The process is up
Retry of chat only	New call id	Old state likely	You did not retry the host

Read that last column out loud before you post. If it feels smaller than your Slack message, shrink the message. I do this small check before I reply.

An unexecuted check you can copy

This script is a proposal, not a lab report. I have not executed it against your host. Please label it that way in your notes.

It assumes a local shell on the server. It assumes curl and sha256sum both exist there. It does not assume any vendor product name.

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

# UNEXECUTED EXAMPLE. Fill paths from your own session.
MODEL_ID_FILE="${MODEL_ID_FILE:-./model_call_id.txt}"
EXPECT_HASH_FILE="${EXPECT_HASH_FILE:-./expected.sha256}"
TARGET="${TARGET:-./app.py}"
HEALTH_URL="${HEALTH_URL:-http://127.0.0.1:8080/health}"

echo "ledger,key,value"

if [[ -f "$MODEL_ID_FILE" ]]; then
  model_id="$(tr -d '[:space:]' < "$MODEL_ID_FILE")"
  echo "model,call_id,${model_id}"
else
  echo "model,call_id,MISSING"
fi

if [[ -f "$TARGET" ]]; then
  host_hash="$(sha256sum "$TARGET" | awk '{print $1}')"
  echo "server,path,${TARGET}"
  echo "server,sha256,${host_hash}"
else
  echo "server,path,MISSING"
  host_hash=""
fi

if [[ -f "$EXPECT_HASH_FILE" ]]; then
  expect="$(awk '{print $1}' "$EXPECT_HASH_FILE")"
  echo "compare,expected,${expect}"
  if [[ -n "$host_hash" && "$host_hash" == "$expect" ]]; then
    echo "compare,match,yes"
  else
    echo "compare,match,no"
  fi
else
  echo "compare,expected,MISSING"
fi

health_code="$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 "$HEALTH_URL" || echo curl_fail)"
echo "server,health_http,${health_code}"
echo "server,user,$(id -un)"
echo "server,cwd,$(pwd)"

Keep paths free of commas or the row splits. sha256sum is a coreutils command, not a shell builtin. If it is missing, use shasum -a 256 instead.

Run it on the server, not on your laptop. Save that stdout right next to the transcript. That saved pair is your only real artifact.

bash two_ledger_check.sh | tee receipts.tsv

Then I ask these three plain questions next. Does that saved model call id look real? Does the compare match field actually say yes?

Does the server health field say 200 now? A missing call id means you never left the story. A match of no means the bytes differ.

A curl_fail means you checked the wrong port. A timeout is not a hash match in disguise. I record the raw line before I interpret it.

Commands I paste beside the chat

I do not trust a paragraph without a command. I paste these commands right after the script. Each one answers one broken table cell only.

id -un && pwd && git rev-parse --show-toplevel
git status --short && git rev-parse HEAD
stat -c '%U %Y %n' ./app.py
sha256sum ./app.py
ss -ltnp | awk 'NR==1 || /:8080/'

The id line tells me the user and cwd. The git line tells me whether a repo exists. The stat line tells me owner and mtime.

The hash line is the server ledger entry. The socket line shows who holds the port. If git rev-parse fails, stop claiming a repo read.

That failure is evidence, not a tool bug. A dirty work tree is not a successful write. An empty git status is not a model confession.

The stat flag in that snippet is GNU specific. On macOS, switch to stat -f before you run it. ss may hide process names without extra rights.

Treat a blank process field as unknown, not proof. A hidden process name is not a clean bill. I would rather see unknown than invent an owner.

How I read a mismatch

Start with the smallest broken cell you see. Please do not restart the whole world yet. I want one cause, not a new myth.

• Missing model id: save the call id before you edit.
• Missing path: you targeted the wrong cwd or user.
• Hash mismatch: the write went elsewhere or never ran.
• Health fail: the process is down or bound elsewhere.
• Health pass plus hash miss: liveness lied about bytes.

Each bullet is a next command, not a vibe. I paste the command output under the bullet. Then the whole review thread gets much quieter.

What this check does not prove

A matching hash is still a narrow win. It only says this path matched this digest. It does not say your tests already passed.

It does not say the free option lasts. Availability can still change without a blog post. Check the console on the day you care.

It does not name a model for you. It does not set a quota for you. Those fields belong to the vendor page you can see.

I am not claiming any benchmark in this note. I am not claiming any customer result here. If I lack a number, I leave the cell blank.

Who should skip this check?

Skip this flow if you need a signed release. Skip it if your policy forbids free hosts. Skip it if secrets would land in a transcript.

Skip it if you cannot open a shell on the box. The check script needs that shell to be open. A screenshot of chat cannot replace that shell.

Skip it if two teams share one free box. You will not know who wrote the file. Get a private path on that box first.

A short close

I still like free model access for drafts. I still like a free server for a sandbox read. I do not let either receipt sign the other.

If you want that pair, try MonkeyCode and keep both receipts. The current docs should beat any sentence I wrote. Your own console should beat both of them.