The 1 GB Agent and the 8 GB Model: Two Memory Budgets on One Machine

A machine that runs an always-on agent comfortably can be an unusable machine for a local model. The two workloads share a box, share a word — memory — and share nothing else about how they consume it. One of them waits; the other one works.

The confusion is not careless. Both sides publish a number, both numbers are in gigabytes, and they look comparable. They are not: one is a floor for a process that sits idle between messages, the other is a floor for a file that has to be resident in full before the first token appears. In practice they differ by most of an order of magnitude, and the mistake people make is buying one machine sized for the smaller number and then discovering they wanted the other one.

Two workloads, one box

An agent gateway is a process that spends almost all of its time waiting — on a model API, on a chat webhook, on a scheduled job to come due. Its memory footprint is a Node or Python runtime, some conversation history, a few open sockets. It does not get bigger when the answer is long, because the answer is being generated somewhere else.

A local model is the opposite. The weights are read from disk once and held in RAM for as long as the model is loaded. Before the first token there is a fixed cost you cannot avoid, and during generation there is a per-token cost paid in memory bandwidth, because every token requires reading the whole weight set again.

So the two numbers answer different questions. The agent’s number answers “how much room does the process need to exist”. The model’s number answers “how much room does the thing it calls need to exist”. If both live on the same box, you add them — and the second term dominates.

What the agent projects actually print

Both major open agents publish their own floors, and they agree closely:

	OpenClaw	Hermes Agent
Minimum	1 GB RAM, 1 core, 500 MB free disk, 64-bit OS	1 GB memory, 1 core, 500 MB data volume
Recommended	2 GB+ RAM, 16 GB+ storage	2–4 GB memory, 2 cores, 2+ GB disk
What pushes it up	many skills, browser use	browser automation

OpenClaw’s documentation states the minimum plainly, and its own Raspberry Pi page adds the reason the recommended figure is higher: the Pi is only the gateway, so the workload is modest. Hermes gives the same shape and names the culprit explicitly:

“Browser automation (Playwright/Chromium) is the most memory-hungry feature. If you don’t need browser tools, 1 GB is sufficient.”

That is a useful calibration. A text-only agent on a 1 GB box is not a compromise; it is what the projects expect. The figure doubles when you hand the agent a browser, because a headless Chromium is a second application, not a flag.

OpenClaw’s own DigitalOcean walkthrough sizes the machine at “Basic, Regular, 1 vCPU / 1 GB RAM / 25 GB SSD” and cites roughly $6/month for it. That is the reference point for the rest of this article: 1 GB is the normal, supported, documented size for an agent host.

What the model costs, computed rather than quoted

Model sizing is arithmetic, and the arithmetic is short enough to do on paper. A quantised model holds each weight in a fixed number of bits:

gigabytes ≈ parameters in billions × bits per weight ÷ 8

An 8-billion-parameter model at 4 bits per weight is about 4 GB. The same model at 8 bits is about 8 GB. A 13–14B model at 4 bits lands near 7 GB, and with runtime overhead and a working context it crosses 8 GB. That band — 8 GB and up — is what the title of this article refers to, and it is the range most people mean when they say “a small local model”.

You do not have to trust the formula. Every model library prints a size next to each tag, and ollama list prints one for each model you have pulled. That number is the weight set on disk, which is also the weight set in memory. Read it first, before you read any blog post about requirements, including this one.

Then add the two things the size column does not include. The first is the KV cache — the attention state for the conversation, which grows with context length and with how many requests run at once. Ollama’s own documentation says so directly:

“Required RAM will scale by OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH.”

The second is the runtime’s own overhead, which varies by backend and is the reason a 4 GB file does not run comfortably on a 4 GB machine. Ollama’s FAQ describes the loading rule in terms of available memory rather than total:

“If your system has sufficient available memory (system memory when using CPU inference, or VRAM for GPU inference) then multiple models can be loaded at the same time.”

Available, not total. On a box that is also running an agent, a database and a web server, those are different numbers, and the gap is where out-of-memory kills come from.

The sentence that settles the argument

You do not have to take any of the above on faith, because the projects say it themselves. From OpenClaw’s DigitalOcean page, in a section about keeping a small Droplet smooth:

“Prefer API-based models (Claude, GPT) over local ones — local LLM inference does not fit in 1 GB.”

And from the Raspberry Pi page, about the recommended setup for that hardware:

“Since the Pi only runs the gateway, use cloud-hosted API models — do not run local LLMs on a Pi, even small models are too slow to be useful.”

This is an agent project telling you not to put a model on the hardware it just recommended. That is not marketing caution; it is the maintainers drawing the line between the two workloads in public. If you are planning a single small box for both, this is the paragraph to plan around.

Swap keeps the agent alive. It does not help the model.

The DigitalOcean walkthrough recommends a 2 GB swapfile on a 1 GB Droplet, installed before onboarding. Read what that is for: it is insurance against the kernel killing the gateway during a spike, so the process survives and the conversation continues. Swap absorbs a transient allocation, then the pressure passes.

A loaded model does not create transient pressure. Its weights are resident for as long as it is loaded, so a model that spills into swap stays in swap, and every generated token pays disk latency to read weights back. The result is not a slow agent that still works; it is an agent that appears hung. If you see a swap file being actively read during generation, the answer is a bigger machine or a smaller model, not a bigger swap file.

The order to size things in

Most sizing mistakes are ordering mistakes. Do this sequence and the plan choice at the end becomes obvious:

1. Decide where inference runs. API or local. This is the fork; every other number depends on it, and it is a decision about cost and privacy rather than about hardware.
2. If API: size the agent. 1 GB is documented and sufficient for a text agent; go to 2 GB if you want a browser, several skills, or headroom you do not have to think about again.
3. If local: size the model first. Take the file size, add the KV cache for your context length, add runtime overhead, and that total is a floor before the agent gets any memory at all.
4. Only now look at plans. Compare the RAM column, not the vCPU count. An agent is I/O bound and one core is genuinely enough; a model is memory bound and cores are almost irrelevant without the RAM to hold the weights.

Step 4 is where the price difference appears, and it is not small. The gap between a 1 GB and an 8 GB plan is usually several times the monthly cost, which is exactly the gap between “an agent” and “an agent that also runs a model”.

What this does not decide

Three things are outside this article. Quantisation quality is one: 4-bit is not free, and whether it is good enough for your task is a question about your task. GPU availability is another, and it changes the arithmetic completely because the weights then live in VRAM. The third is whether you need a VPS at all — if the honest answer is “a shared plan and a cron job”, then the shared-plan limits are the ones worth reading, not these.

Two practical follow-ups. Once the machine exists, five counters tell you whether you got what the plan promised — particularly whether available ever reaches the advertised figure. And if the appeal of all this is not paying a monthly bill, read the free-tier exclusions first: free compute has its own memory policy, and it is enforced.

The mistake is not choosing a small machine. It is choosing one machine for two workloads whose floors differ by a factor of eight, and finding out at the point where the kernel starts killing processes instead of the point where you are comparing prices.