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.

You dey run the agent, or you dey run the model?

Coding agent wey dey call cloud model na network client wey get shell attached. E dey send files and plan go API, wait for reply, then edit files and run commands locally. While e dey wait, e dey use almost no CPU. The agent memory na hundreds of megabytes, na why modest CPU box be the correct machine.

To run the model by yourself na different product for different hardware. The weights dey remain for memory as long as server dey up. Model wey get 7 billion parameters and quantised to 4 bits get about 4 GB weights (Llama 2 7B ships as 3.83 GB for Q4_0 and 4.08 GB for Q4_K_M), and publisher list 6.3 to 6.6 GB RAM to run am without GPU after runtime overhead don enter calculation. Longer contexts need more, because key/value cache dey grow as context length dey increase. For CPU only, shared vCPU dey produce few tokens per second, and one agent task fit emit thousands of tokens, so work wey take under one minute against API fit take most of one hour locally. If na this you want, size for VRAM (video memory for GPU) and read wetin VPS wey get GPU really dey give you instead of this page.

Everything below 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 go 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 50 GB disk nearly full before you write one line of code. Docker na the biggest single item, at around 20 GB, because BuildKit dey keep every intermediate layer for every build until you tell am make e stop.

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

docker system df dey print reclaimable space for each category, so run am before and after. until=168h filter dey keep cache records wey build don use for the last week and delete the rest. E dey use last use, no be age, so layer wey you create one month ago but reuse yesterday go survive, and na this cache still dey save your time. docker image prune -a go further and remove every image wey no container dey use, so expect the next build to pull again.

Node projects dey fail for more strange way. npm install dey write hundreds of thousands small files, so 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, wey dey store each package version once and hard-link am inside every project.

Logs na the quiet one. Agent wey dey run all the time dey write session transcripts, and systemd journal dey grow and 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 and run sudo systemctl restart systemd-journald to make that limit permanent, because one-off vacuum only go free space for 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.

Why your coding agent look like e hang

This na the failure wey people dey diagnose wrong pass for small agent box. Command return nothing, agent dey wait, and session look frozen. Kernel out-of-memory (OOM) killer kill the process. E receive SIGKILL, so e no fit print error, flush log, or tell agent wetin happen. Agent 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 hold when e die. Note the process wey kernel choose: kernel mostly score by memory wey process dey use, so e often kill language server or agent instead of the build wey push the box pass limit. Na exactly why the symptom look like "agent spoil".

Inside Docker, the same event dey leave cleaner fingerprint. Container dey 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 don now dey get killed at 4 GB and agent survive, so mystery hang turn ordinary failed command with readable exit code. This need systemd user manager, and ordinary SSH login dey start one for you, so command work over SSH as e be. loginctl enable-linger $USER na only for keeping user units running after you log out. MemoryHigh= dey throttle process when e reach the limit instead of killing am, and this 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.