How Much RAM Coding Agent VPS Need?

How much RAM coding agent VPS need?

Start with 4 GB RAM and 2 vCPU for one coding agent wey dey work for repository all the time. Move go 8 GB RAM and 4 vCPU as soon as language server or Docker build join the session. For most repositories, this one dey happen from day one. The agent process itself small. Na the toolchain wey the agent dey control for you dey use most of the resources.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

Every row above assume say model dey run somewhere else, behind an API wey you dey call through network. This assumption dey decide the whole sizing question, so settle am first.

Agent dey run, or na model dey run?

Coding agent wey dey call cloud model na network client wey shell attach to am. E dey send files and plan go API, wait for reply, then e edit files and run commands locally. While e dey wait, e hardly use CPU. The agent memory usage dey measure in hundreds of megabytes. Na why modest CPU box fit do this work.

To run the model by yourself na different product for different hardware. The weights go remain for memory as long as server dey up. Model wey get 7 billion parameters and dem quantise am to 4 bits need roughly 5 GB for the weights alone. This one no include key/value cache wey dey grow as context length increase. For CPU only, shared vCPU fit produce just few tokens per second. One agent task fit emit thousands of tokens. So work wey take less than one minute through API fit take most of one hour locally. If na this you want, size the system for VRAM (video memory for GPU), and read wetin VPS with GPU really give you instead of this page.

Everything wey follow assume say na cloud-model case.

Wetin really dey use the memory

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

Those figures na common published values for mid-size projects. Use dem as general pattern, no be promise about your own code.

The chart get 6 rows, and the agent na the cheapest one. E dey around 250 MB when idle because e dey keep one conversation and small file cache, and nothing more. TypeScript language server fit reach about 2000 MB while e dey index, because e dey build type graph for every file wey e fit reach from your tsconfig.json, then e keep that graph for memory so e fit answer the next request quickly. rust-analyzer for large workspace commonly pass 4000 MB for the same reason, across every crate for the workspace.

Headless Chrome dey cost about 350 MB for the browser plus one tab, and every extra tab na another operating system process. Node test run wey get four workers na four Node processes, so e fit peak near 3000 MB. Docker image build fit peak near 2500 MB because the build dey run your project own compiler inside the container while the daemon dey write layers.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

Read the available column for free -h, no be the free column. Linux dey use every free page for disk cache, so free fit small for machine wey dey completely healthy, and e no tell you anything. available na wetin new process fit actually get.

Configurations three wey dey work

Minimum wey fit work: 4 GB RAM, 2 vCPU, 50 GB disk. One agent session, one repository, one language server, and builds wey you fit wait for. This tier dey work, but e go meet the out-of-memory killer the first time one big test run overlap with language server wey dey index. Add swap and limit your build workers.

Comfortable: 8 GB RAM, 4 vCPU, 100 GB disk. One agent, plus Docker, plus headless browser for tests, with enough spare capacity for one build spike. Na this tier most single developers suppose buy. If you double the vCPU count, build wait time go roughly reduce by half. You go notice this much more often than memory.

Team: 16 GB RAM, 8 vCPU, 200 GB disk. Four concurrent sessions, and each one get im own checkout and toolchain. Size am for peak usage, because four idle agents cost almost nothing, but four test runs wey happen at the same time go cost four times the peak figure for the row above.

As of August 2026, the step from the first row to the last one dey roughly four times the monthly price for annual VPS billing: single-digit dollars every month for the bottom, and tens of dollars for the top. Check the current listing before you plan, because those numbers fit change. The server rarely be the expensive part. For anybody wey dey drive agent every day, model API bill go pass server bill quickly, so limit wetin the agent fit spend before you reduce the server size. For the build itself, the walkthrough for running a coding agent on a VPS explain how to set up the account and keep the session alive after you disconnect.

Why disk space finish before RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

Add all those rows together, and a 50 GB disk don nearly full before you write one line of code. The biggest single item na Docker, at around 20 GB, because BuildKit dey keep every intermediate layer from every build until you tell am to stop.

docker system df
docker builder prune --filter until=168h

docker system df dey show reclaimable space for each category, so run am before and after. The until=168h filter dey remove build cache wey pass one week, and keep this week's own, because na that cache still dey save you time. docker image prune -a dey go further and remove every image wey no container dey use, so expect the next build to download dem again.

Node projects fit fail for more strange way. npm install dey write hundreds of thousands of small-small files, so the filesystem fit run out of inodes while df -h still dey report free gigabytes. The write go then fail with No space left on device for disk wey still look half empty.

df -h /
df -i /

If IUse% read 100, delete the node_modules directories for branches wey you no dey use again, or switch to pnpm. E dey store each package version once and hard-link am inside every project.

Logs na the quiet one. An always-on agent dey write session transcripts, and the systemd journal dey grow until e take part of the disk by default.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Set SystemMaxUse=200M inside /etc/systemd/journald.conf, then run sudo systemctl restart systemd-journald to make that limit permanent, because one-time vacuum only go return the space wey dey available today.

Swap: wetin e dey buy, and wetin e dey hide

Swap dey worth adding, because e turn small overshoot into slow work instead of dead process. Make the size half of RAM, up to about 4 GB. For build box, no plenty reason to go beyond that.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show suppose list /swapfile now with the size wey you request. Without the /etc/fstab line, swap go disappear after the next reboot, and the box go quietly return to the old behaviour. If fallocate answer Operation not supported, build the file with sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 and continue from chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Low swappiness tell the kernel to reclaim disk cache before e push program memory go disk. This help language server remain responsive.

Now na the part wey swap dey hide. When job really need more memory pass wetin the box get, kernel go spend time dey move pages between RAM and disk instead of running your build. Nothing go crash. Everything go crawl, and load average go rise while CPU dey idle.

vmstat 1 10

Steady non-zero numbers for si and so columns mean say continuous swapping dey happen. The fix na less concurrency or more RAM, never more swap. For small box, sudo apt install -y zram-tools provide compressed swap wey dey held for RAM, and dem tune am for /etc/default/zramswap. E much faster pass swap file, and e dey spend RAM to save RAM, so e help with cold pages but e no help build wey need real working memory.

Wetin make your coding agent look like e hang

This na the failure wey people misdiagnose pass for small agent box. Command go return nothing, agent go wait, and session go look frozen. Kernel OOM killer kill the process because memory finish. E receive SIGKILL, so e no fit print error, flush log, or tell agent wetin happen. Agent go see empty result and no exit message.

Kernel dey record am:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

Real line fit look like this:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss na how much memory that process dey hold when e die. Notice which process kernel choose: kernel mostly score processes based on memory wey dem dey use, so e often kill language server or agent instead of the build wey push the box pass limit. Na exactly why symptom go look like "agent spoil".

Inside Docker, the same event dey leave clearer sign. Container go exit with code 137, wey be 128 plus signal 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true confirm say container hit im memory limit instead of crashing by itself.

The solution na to give the expensive command im own limit, so build go die instead of agent:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

Build go now die for 4 GB and agent go survive. This go turn mysterious hang to normal failed command with readable exit code. This one need systemd user session, so run loginctl enable-linger $USER for box wey you only dey reach through SSH. MemoryHigh= dey slow the process when e reach the threshold instead of killing am. This one often better for build wey you prefer make e finish slowly.

Set am once with Compose memory limits

If agent tools dey run inside containers, put the limit for Compose file so e go apply every time dem run.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 dey apply deploy.resources.limits for plain docker compose up, so swarm mode no dey involved. The older mem_limit: 2g key still dey work. The complete guide to Compose memory limits dey explain reservations and wetin go happen when container reach im limit. If Docker never dey for the server, first install Docker on a VPS.

One mistake fit waste person whole afternoon. Container wey get 2 GB limit still dey read host /proc/meminfo and host CPU count, because namespace no cover either one. Test runner wey dey choose worker count from CPU count go start eight workers inside 2 GB container for eight vCPU host, then e go die with 137. Set the numbers by hand:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size dey for MB and e cap V8 heap. Set am below container limit so Node go throw error wey you fit read instead of just disappearing:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

That message dey useful because e name the limit wey dem hit and the process wey hit am. OOM killer no dey do that.

Run plenty agent sessions for one box

Plan for each session, no be for each person. Two sessions for the same repository still mean two language servers, two sets of build caches for memory, and two test runs if both agents busy at the same time. Na why the team row jump reach 16 GB.

Give each user hard ceiling, so one session wey run out of control no fit bring the whole box down:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

Replace 1001 with the UID wey id -u print. systemctl show suppose echo MemoryMax=6442450944 after the user don log in. When everything for that user session pass 6 GB, the kernel go kill one process inside her slice, and every other session go continue to work. If agent dey run as a service instead of for terminal, put MemoryMax= for its unit file instead. Na this pattern you suppose follow when you self-host agent as service wey always dey on.

FAQ

2 GB of RAM dey enough for coding agent?

For the agent process, yes. But for the work wey e dey do, most times no. The agent dey use around 250 MB, but one TypeScript language server fit reach 2000 MB for a medium-size repository. That one alone fit push 2 GB machine enter swap. 2 GB dey okay for editing config files and small scripts. Use 4 GB as the minimum for anything wey dey compile or run test suite.

I need GPU to run coding agent for VPS?

No, if the agent dey call cloud model through API. That workload dey depend mainly on network, so ordinary CPU VPS na the correct machine. GPU go just dey idle while the price high pass. You only need GPU when the model itself dey run for the same machine. For that case, the question change from RAM to VRAM and model size.

How much swap I suppose add to agent VPS?

Use half of RAM, up to around 4 GB. Swap fit protect you from short memory overshoot, because the kernel fit move cold pages go disk instead of killing process. E no add usable memory. If vmstat 1 shows steady traffic for the si and so columns, the machine dey thrash. The solution na fewer parallel workers or bigger plan.

Why my coding agent dey freeze for middle of build?

The kernel OOM killer almost certainly kill the build. E send SIGKILL, so nothing print and the agent dey wait for pipe wey no go ever fill. Run sudo dmesg -T | grep -i "killed process" and check the process name plus the anon-rss value. Fix am by limiting the build with systemd-run --user --scope -p MemoryMax=4G and reducing worker count, or move go one RAM tier higher.