The mistake I see most often with agent hosting is sizing for the wrong thing. Someone runs one agent, it uses 400 MB, and they conclude agents are cheap to host. Then they scale to a real crew and the box starts swapping at 3 a.m.
One agent is cheap. That's not the interesting case.
Where the memory actually goes
An agent that only fires off API calls to a model is light — it's mostly waiting on the network. You could run a dozen of those on a small plan and never notice.
The RAM disappears when agents start holding state. Conversation history that grows every turn. A working set several agents read and write. A vector store for long-term memory sitting in the same process. The moment your architecture stops being "call API, forget" and becomes "remember, coordinate, hand off," memory becomes the constraint, not CPU.
CrewAI, LangGraph, AutoGPT-style loops — they all trend this way as they get serious. The framework doesn't eat the RAM; the state does.
Rough sizing, honestly
I won't pretend there's a formula, because there isn't — it depends entirely on how much each agent keeps around. But a practical feel from running these:
Light, API-bound agents — you don't need Pro at all here; a NAT or dedicated-IP plan ($3–20) handles it. Pro earns its place once shared state pushes you past ~32 GB.
32 GB — the sweet spot for a real multi-agent system: 5–10 agents with shared memory plus a vector database that's actually useful. Most people land here.
64 GB — bigger fleets, longer histories, a memory index in the millions of vectors, or several services co-located. This is where one box replaces the three smaller ones you'd otherwise juggle.
80 GB — heavy, memory-bound work: large in-memory datasets, many concurrent agents, or agents plus local model inference on the same host.
Start below where you think you need to be. Watch htop for a day. Resize up when you see swap, not before — guessing high just wastes money.
The part that's hard to buy
Here's the thing that makes this awkward: renting 64 GB of RAM is easy. Renting 64 GB with crypto and no identity check is not. Most hosts that sell serious memory cheaply do it behind a card and a KYC form.
If your agent provisions its own server, or the workload touches data you'd rather not tie to a name, that combination — high memory, crypto, no KYC, and orderable by the agent itself over MCP — is the actual product. It's not cheaper per gigabyte, and I've written separately about why that comparison misleads. It's available on terms almost nobody offers.
So what do you do
If your agents are light and API-bound, don't overthink it — a small NAT or dedicated-IP plan is plenty, skip the whole high-memory question. If you're running a real fleet that holds state, size by what's actually in memory, start at 32 GB, and move up when the graph tells you to.
When you're there, the Pro line covers 32 to 80 GB with a dedicated IP and nightly backups. Pick the tier that matches your working set, not your ambitions.
Top comments (0)