FAQ: Four Myths About the Model Owning Host State

Does the model own your host state?

Does your free model know the host state?
I keep hearing that confident claim daily.
It is almost never actually true in practice.

The model only predicts the next tokens.
The server still owns processes and installed packages.
Those two layers should never share a ledger.

Why do teams fuse inference with the machine?
Free replies land inside the same browser tab.
The remote host then feels strangely present.

A free server also feels cheap and disposable.
People skip inventory commands without much guilt.
They trust whatever the model asserted earlier.

Name the split before you debug

Disclosure: This article was prepared as part of MonkeyCode's product outreach.
MonkeyCode provides free model access and a free server option.

I treat that product only as one example.
These checks still work on any remote agent host.

I keep three ledgers and never just one.
Model context is text from this turn.

Host state covers OS, cwd, and packages.
Repo state covers git, lockfiles, and tests.

The model never holds the host ledger.
Unless you measured it and pasted results.

Did a host process actually print this line?
If it did not, treat the line as guesswork.

Myth 1: The free model inventories the host

Claim: The free model inventories the host each turn.

Repeated line: The session is connected, so PATH is visible.
It must already see Python and Docker.

That belief skips the only honest measurement tool.
The honest measurement tool is the host shell.

uname -srm
id -un
pwd -P
command -v python3 || true
python3 -V 2>/dev/null || true
command -v node || true
command -v git || true
git rev-parse --show-toplevel 2>/dev/null || true

That output is host state, not model memory.
A free model has no package database.
A free server does, after you query it.

Paste the probe into the following model turn.
Then the model can discuss this actual host.
Otherwise it describes some generic developer laptop.

Myth 2: A named binary exists on the server

Claim: The chat named pytest, so pytest already exists.

Repeated line: Popular tools ship on every free server.
Training data mentions pytest in countless snippets.

Check the binary with command -v instead.
Never treat the chat transcript as which output.

need="python3 pytest ruff docker npm"
for c in $need; do
  if command -v "$c" >/dev/null 2>&1; then
    printf 'present %s -> %s\n' "$c" "$(command -v "$c")"
  else
    printf 'missing %s\n' "$c"
  fi
done

A name inside a sentence is not a path.
Your free server may lack every popular tool.
I treat each binary as missing until proven.

Myth 3: Chat install means the package stayed

Claim: The model installed the dependency for me.

Repeated line: The next turn can import that module.
The free server surely kept the virtualenv around.

Install and prove inside one script together.
Treat this block as a proposed check only.
Point the import at a package you actually declared.

# proposed check — label it unexecuted until you run it
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -q -r requirements.txt
python - <<'PY'
import sys
print("executable", sys.executable)
import pytest
print("pytest", pytest.__file__)
PY

If that import fails, the narrative failed too.
The install may have run in another directory.
The virtualenv may never have been activated.

Side effects live only on the host filesystem.
They die with the workspace and the shell.
The model cannot store a venv inside tokens.

Did the process exit with status zero?
Did the import print a real file path?
Those two answers are the only proof.

Myth 4: Both free flags share one snapshot

Claim: Free inference and free compute are one environment.

Repeated line: One product tab means one mental machine.
One free label then covers every failure domain.

Split the receipts with this small decision table.

Question	Ask the model	Ask the host
OS and arch	never	uname -srm
Canonical cwd	never	pwd -P
Git HEAD	never	git rev-parse HEAD
Installed tools	never	command -v
Next refactor idea	yes	no
Whether tests failed	after logs	test runner

"Free model" only means token generation here.
"Free server" only means a remote machine here.
They can fail in completely different ways.

The model can respond while git is missing.
The host can be healthy while advice is invented.
I refuse to merge those two outage types.

Dump facts, then let the model talk

Do not argue with the chat log here.
Dump host facts and hash the file.
Feed only that block back into context.

Treat the next script as a proposed probe.
Run it on the agent server, not locally.

#!/usr/bin/env bash
# host_facts.sh — proposed probe for the agent server
set -euo pipefail

out="${1:-/tmp/host_facts.txt}"
{
  echo "### host_facts"
  echo "date_utc $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo "uname $(uname -srm)"
  echo "user $(id -un)"
  echo "pwd $(pwd -P)"
  echo "shell ${SHELL:-unknown}"
  echo "python $(command -v python3 || echo missing)"
  echo "python_ver $(python3 -V 2>&1 || true)"
  echo "node $(command -v node || echo missing)"
  echo "git $(command -v git || echo missing)"
  echo "git_root $(git rev-parse --show-toplevel 2>/dev/null || echo none)"
  echo "git_head $(git rev-parse HEAD 2>/dev/null || echo none)"
  echo "venv ${VIRTUAL_ENV:-none}"
} >"$out"

if command -v sha256sum >/dev/null 2>&1; then
  sha256sum "$out"
else
  shasum -a 256 "$out"
fi
cat "$out"

Run that script on the remote server shell.
Then paste the file into the model prompt.
Ask for a plan, not an imagined inventory.

Proposed loop

1. Run host_facts.sh on the server.
2. Paste the hashed block into context.
3. Ask the model for a plan only.
4. Execute commands through the host shell.
5. Re-run the probe after any install.
6. Diff the two dumps without mercy.

If the dump did not change, nothing installed.
The chat cannot override a missing diff.

Decision rules I apply to every claim

When the loop argues, I score each claim.

• Chat invented the OS: discard that turn.
• Chat named a missing binary: change the plan.
• Chat claimed a virtualenv: print sys.executable.
• Chat claimed tests passed: run the test runner.
• Chat claimed a commit: read git log -1.

No claim crosses without a matching host line.
That single rule is the whole method.

What about network installs during the agent loop?
I still require a second probe after pip.
A download story is not a site-packages path.

Limitations

This probe is not a full security audit.
It will not catch hidden or privileged processes.
It will not prove outbound network policy either.

A free server can still be a shared machine.
Do not dump secrets into the fact file.
Do not print env or concatenate dotenv files.

The model can still ignore your pasted facts.
Short fact blocks survive context pressure better.
Long dumps get truncated without any warning.

I am not publishing timings in this FAQ.
I am not publishing model names either.
Those details change and go stale fast.

This is not a benchmark of any free tier.
It is a hygiene checklist for agent loops.

Who should skip this

Skip this if you need a signed host inventory.
Skip this if the host cannot run a shell.
Skip this when policy forbids even tiny probes.

Do not park secret production data on free servers.
Do not treat free inference as a package manager.
Do not skip lockfiles because the model remembers pip.

If you already have CI, keep CI as the gate.
The probe is only for the agent loop.
It is not a release oracle at all.

Compare one probe with one question

Want a fast way to feel the split?
Run the probe once on the remote host.
Then ask the model which OS you have.

Compare those two answers without any charity.
A match means you pasted the facts well.
A miss means you just caught the myth.

Keep the ledgers split from this point.
That is the entire FAQ in one line.