FAQ: Five Myths About Memory on a Free Agent Box

You cloned a repo on a free agent box. The chat answered as if it owned every file. Did the model hold those files, or only a path?

I keep seeing developers fuse three stores. They tell one story. The box tells another.

This FAQ names the stores, then the myths. Then you get a probe you can actually run.

What this FAQ is not

This writeup is not a product bake-off. This writeup is not a latency or quality chart.

I am not grading any model here. I am splitting a mental model that keeps collapsing.

The three stores, named out loud

Name the stores before you argue with the agent. Otherwise every confident answer collapses into mush.

1. Context window — tokens the model can attend to now.
2. Remote disk — files the shell on that box can touch.
3. Your laptop — keys, repos, and browsers you still own.

The chat UI is not a fourth durable store. It is a view, and sometimes a liar.

After every agent claim, ask which store spoke.

Where I run the probes

I needed a box that was not my laptop. I also needed a model without standing up billing.

MonkeyCode offers free model access and a free server option. That pair is enough to run the probes below.

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

I will not name models in this article. I will not quote quotas or machine shapes. Those details move. The store split does not.

Treat the box as untrusted disk space. Treat the model as untrusted text with tools.

Myth 1: "I cloned it, so the model has the repo"

Clone is a disk write. Attention is a token budget.

Did a tool read the files into the thread? If nobody read them, the model has a path, not a repo.

A tree listing is not the source tree. A README snippet is not the module graph.

Evidence you can collect

Run this on the box. Treat it as a probe, not a benchmark.

# probe_repo_vs_context.sh
# Example workflow. Run on the remote Linux box.
# find -printf assumes GNU find.
set -euo pipefail
ROOT="${1:-.}"
echo "disk_file_count=$(find "$ROOT" -type f ! -path '*/.git/*' | wc -l)"
echo "disk_bytes=$(du -sb "$ROOT" | awk '{print $1}')"
echo "largest_files:"
find "$ROOT" -type f ! -path '*/.git/*' -printf '%s\t%p\n' 2>/dev/null \
  | sort -nr | head -n 5
echo "store_hint=disk_only_until_a_tool_reads"

Now count chat reads. How many files did a tool actually open?

Zero reads means store two is full and store one is empty. Stop saying the model "has" the repo.

Corrected model: clone populates disk. Only reads populate context.

Myth 2: "pip install taught the model the library"

Install writes wheels onto disk. It does not patch weights.

Can the shell import that package right now? That check is only a disk fact. Can the model recite the real kwargs? That question is only a context fact.

Those two facts diverge more often than people admit. The split shows up in boring, expensive debugging.

Split the proof

# probe_install_vs_weights.sh
# Example workflow. This is not a model score.
python3 - <<'PY'
import importlib.util
import sys
mod = "pytest"
spec = importlib.util.find_spec(mod)
print(f"python={sys.executable}")
print(f"disk_has_{mod}={spec is not None}")
if spec and spec.origin:
    print(f"origin={spec.origin}")
PY

That one print belongs only to store two. A fluent docstring in chat is store one. Those two answers can disagree without anyone noticing.

Ask the agent for one call signature. Then open the installed package on disk. Compare the two lines side by side.

Corrected model: packages live on disk. APIs live in tokens, or they do not.

Myth 3: "A file on the free server is my private workspace"

Do you even know whose hostname that is? Do you know who last used the image?

You probably cannot answer either question yet. So the workspace is not yours in any strong sense.

A .env on that box is a secret on someone else's disk. A secret in the prompt is a secret in logs you do not retain.

Neither one is your laptop keychain. Stop mixing those threat models.

Redact, then inventory

# probe_secret_surfaces.sh
# Example workflow. Review output before you paste it.
echo "user=$(id -un)"
echo "host=$(hostname)"
echo "home=$HOME"
echo "cwd=$(pwd)"
echo "env_suspect_keys:"
env | awk -F= '{print $1}' | grep -Ei 'KEY|TOKEN|SECRET|PASSWORD|CREDENTIAL|^AWS_'
echo "home_dot_entries:"
ls -la "$HOME" | awk '{print $9}' | grep -E '^\.' | head -n 20

Would you paste that dump into a public ticket? If not, do not store real values there.

Corrected model: free disk is convenient scratch. It is not a vault.

Myth 4: "The next chat continues the same machine"

Maybe it does, but you should prove it anyway.

A new thread can mean a new container. It can also mean a warm home directory. The product UI may stay quiet about that. The model will still narrate a continuous machine.

Leave a marker. Read it later.

# probe_persistence.sh
# Example workflow. Run at session start, then in a later thread.
MARKER="${HOME}/.three_store_marker"
echo "now_utc=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "pid=$$"
echo "host=$(hostname)"
if [ -f "$MARKER" ]; then
  echo "marker_exists=yes"
  echo "----- prior marker -----"
  cat "$MARKER"
  echo "----- end marker -----"
else
  echo "marker_exists=no"
fi
{
  echo "pid=$$"
  echo "host=$(hostname)"
  echo "home=$HOME"
  echo "written_utc=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
} > "$MARKER"
echo "wrote=$MARKER"

Did the next thread lose the marker file? Then store two reset under your feet. Do not trust "as I did earlier".

Did the marker survive while the hostname changed? You inherited a disk, not a process.

Corrected model: session memory is not disk memory. Measure both.

Myth 5: "The box keeps state, so I can skip git"

Free disk still feels like a real workspace. It remains scratch space you do not own.

Did the image get recycled under you? Did another session clobber your checkout directory? You will not get a git reflog from that.

The remote you control is the source of truth. The box is a checkout you might lose.

Make the remote prove it

# probe_git_truth.sh
# Example workflow. Run inside the working tree.
set -euo pipefail
git rev-parse --is-inside-work-tree
echo "head=$(git rev-parse --short HEAD)"
echo "branch=$(git branch --show-current)"
echo "remote=$(git remote -v | head -n 2)"
echo "dirty_stat:"
git status --porcelain
echo "unpushed:"
git log --oneline '@{u}..HEAD' 2>/dev/null || echo "no_upstream_or_no_commits"

Dirty and unpushed is not "saved on the agent". It is risk on a disk you do not own.

I push before I trust any long tool loop. You should push on that same cadence.

Corrected model: git remote is durable. Free home directories are not.

How to read a false claim

The agent will speak in your laptop's grammar. Translate each sentence into a store.

• "I know this codebase" → which files entered the window?
• "I installed it" → which interpreter imports it right now?
• "We did this yesterday" → did the marker file survive?
• "That's secret-safe" → which store holds the bytes?
• "It's committed" → what does git status print on the box?

If you cannot point at a store, the claim is theater.

A decision table you can print

Use this when the agent sounds sure.

Agent claim	Store it might mean	What you run	If it fails, you learned
"I have the repo"	disk, maybe context	find plus the read log	clone is not attention
"pytest is installed"	disk	python3 -c "import pytest"	install is not weights
"I'll remember next time"	disk, or nothing	marker file across threads	a thread is not a machine
"The secret is safe here"	none of the three	secret-key inventory	free disk is not a vault
"It's saved"	laptop remote, not box	git status and git log	scratch is not backup

Print that table and keep it beside the myths.

A 15-minute workflow

Do this once per new box image. Do not turn the probes into ceremony.

1. Open a fresh thread on the free server.
2. Run probe_persistence.sh first and save the hostname.
3. Clone only what you need, then run the repo probe.
4. Install nothing until the disk probe says the package is missing.
5. Refuse real secrets. Use placeholders in the thread.
6. Run probe_git_truth.sh before any long edit loop.
7. Start a second thread. Run the marker probe again.
8. Write one line: which stores survived?

That one line is the actual lesson. The model's self-report is not the lesson.

Limitations

This probe does not measure any model quality. It also does not measure queue time.

It does not prove isolation across other tenants. It also does not prove log retention.

I have not given any hardware specs. I have not given SLAs or uptime stories.

If the vendor changes the image, your marker story changes. Re-run the probes after every image change.

Which readers should skip this whole approach?

• People who already isolate agents on runners they own.
• People who need compliance evidence, not a shell checklist.
• People who will paste .env files into any chat anyway.
• People who want a laptop replacement, not a scratch box.

Do you need durable state across days? Use a remote you control, and push often.

Do you need real secrets in the loop? Keep them outside the thread and outside the free disk.

What I want you to stop saying

Stop saying that the model installed it. The shell did that, or nobody did.

Stop saying that the box is a backup. Check git status and the marker file.

Stop saying that the thread is a disk. Threads vanish, and disks get wiped without notice.

Ask the store question out loud first. Then run one probe before you argue. Only then talk about what actually happened.

If you run the marker probe, comment which stores survived. Redact secrets before you paste anything.