Hoeveel RAM heeft een VPS voor een coding agent nodig?

Hoeveel RAM heeft een VPS voor een coding agent nodig?

Begin met 4 GB RAM en 2 vCPU voor één coding agent die continu actief is en in een repository werkt. Schakel over naar 8 GB RAM en 4 vCPU zodra een language server of een Docker-build onderdeel van de sessie wordt. Bij de meeste repositories gebeurt dit al op dag één. Het agentproces zelf is klein. De toolchain die de agent namens u aanstuurt, gebruikt het meeste geheugen en de meeste rekenkracht.

[
  {
    "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
  }
]

Elke rij hierboven gaat ervan uit dat het model ergens anders draait, achter een API die u via het netwerk aanroept. Die aanname bepaalt de volledige sizingvraag. Stel dit daarom eerst vast.

Draait u de agent of het model?

Een coding agent die een cloudmodel aanroept, is een netwerkclient met een gekoppelde shell. De agent stuurt bestanden en een plan naar een API, wacht op het antwoord en bewerkt daarna lokaal bestanden en voert lokaal opdrachten uit. Tijdens het wachten gebruikt de agent vrijwel geen CPU. Het eigen geheugengebruik bedraagt enkele honderden megabytes. Daarom is een bescheiden CPU-machine hiervoor geschikt.

Het model zelf uitvoeren is een ander product waarvoor andere hardware nodig is. De gewichten blijven in het geheugen zolang de server actief is. Een model met 7 miljard parameters dat naar 4 bits is gekwantiseerd, heeft alleen voor de gewichten ongeveer 5 GB nodig. Daar komt de key/value-cache nog bij. Die groeit mee met de lengte van de context. Met alleen CPU levert een gedeelde vCPU enkele tokens per seconde. Eén agenttaak kan duizenden tokens genereren. Werk dat via een API minder dan een minuut duurt, neemt lokaal daardoor het grootste deel van een uur in beslag. Als dat is wat u wilt, moet u de capaciteit afstemmen op VRAM (videogeheugen van de GPU) en lezen wat een VPS met een GPU daadwerkelijk biedt in plaats van deze pagina te gebruiken.

Alles hieronder gaat uit van het gebruik van een cloudmodel.

Wat het geheugen daadwerkelijk gebruikt

[
  {
    "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
  }
]

Dit zijn gebruikelijke gepubliceerde cijfers voor middelgrote projecten. Gebruik ze als indicatie van de verhoudingen, niet als garantie voor uw code.

De grafiek bevat 6 rijen en de agent is het goedkoopst. Bij inactiviteit gebruikt deze ongeveer 250 MB, omdat hij één conversatie en een kleine bestandscache bijhoudt en verder niets. Een TypeScript-language server bereikt tijdens het indexeren ongeveer 2000 MB. Hij bouwt een typegrafiek op voor elk bestand dat vanuit uw tsconfig.json bereikbaar is en houdt die grafiek vervolgens in het geheugen om het volgende verzoek snel te kunnen beantwoorden. rust-analyzer overschrijdt in een grote workspace vaak 4000 MB om dezelfde reden, voor elke crate in de workspace.

Headless Chrome gebruikt ongeveer 350 MB voor de browser en één tabblad. Elk extra tabblad is een extra proces van het besturingssysteem. Een Node-test met vier workers bestaat uit vier Node-processen en bereikt daarom een piek van ongeveer 3000 MB. Een Docker-imagebuild bereikt een piek van ongeveer 2500 MB. Tijdens de build voert de container namelijk de eigen compiler van uw project uit, terwijl de daemon layers wegschrijft.

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

Lees de kolom available van free -h, niet de kolom free. Linux gebruikt elke vrije pagina voor de diskcache. Daarom is free op een volledig gezonde machine klein en zegt deze waarde niets. available geeft aan hoeveel geheugen een nieuw proces daadwerkelijk kan krijgen.

Drie werkende configuraties

Minimumconfiguratie: 4 GB RAM, 2 vCPU, 50 GB schijfruimte. Eén agentsessie, één repository, één language server en builds waarvoor u bereid bent te wachten. Deze configuratie werkt, maar de out-of-memory killer zal ingrijpen zodra een grote testrun samenvalt met een language server die indexeert. Voeg swap toe en beperk het aantal build workers.

Comfortabel: 8 GB RAM, 4 vCPU, 100 GB schijfruimte. Eén agent, Docker en een headless browser voor tests, met voldoende ruimte voor één tijdelijke piek tijdens een build. Dit is de configuratie die de meeste individuele ontwikkelaars moeten kiezen. Met een verdubbeling van het aantal vCPU's wordt de wachttijd voor builds ook ongeveer gehalveerd. Dat merkt u veel vaker dan een tekort aan geheugen.

Team: 16 GB RAM, 8 vCPU, 200 GB schijfruimte. Vier gelijktijdige sessies, elk met een eigen checkout en een eigen toolchain. Dimensioneer voor de piekbelasting. Vier inactieve agents kosten bijna niets, terwijl vier gelijktijdige testruns vier keer zoveel kosten als de piekwaarde in de bovenstaande rij.

In augustus 2026 kost de stap van de eerste naar de laatste rij bij jaarlijkse VPS-facturering ongeveer vier keer zoveel per maand: onderaan enkele dollars per maand en bovenaan tientallen dollars. Controleer de actuele aanbieding voordat u plannen maakt, want deze bedragen veranderen. De server is zelden het duurste onderdeel. Voor iedereen die dagelijks met een agent werkt, loopt de factuur voor de model-API snel hoger op dan de serverfactuur. Beperk daarom wat de agent mag uitgeven voordat u een kleinere server kiest. Voor de build zelf behandelt de handleiding voor het uitvoeren van een coding agent op een VPS het instellen van het account en het actief houden van de sessie nadat u de verbinding verbreekt.

Waarom u geen schijfruimte meer hebt voordat het RAM op is

[
  {
    "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
  }
]

Tel die regels bij elkaar op. Dan is een schijf van 50 GB bijna vol voordat u één regel code hebt geschreven. Docker neemt met ongeveer 20 GB het meeste ruimte in. BuildKit bewaart namelijk elke tussenlaag van elke build totdat u deze opruimt.

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

docker system df toont per categorie hoeveel ruimte kan worden vrijgemaakt. Voer het daarom voor en na het opruimen uit. Het filter until=168h verwijdert de build-cache die ouder is dan een week en behoudt de cache van deze week. Die cache bespaart u nog steeds tijd. docker image prune -a gaat verder en verwijdert elke image die door geen enkele container wordt gebruikt. Verwacht daarom dat de volgende build de images opnieuw moet downloaden.

Node-projecten falen op een minder voor de hand liggende manier. npm install maakt honderdduizenden kleine bestanden aan. Daardoor kan het bestandssysteem zonder inodes komen te zitten, terwijl df -h nog steeds vrije gigabytes rapporteert. De schrijfactie mislukt dan met No space left on device op een schijf die half leeg lijkt.

df -h /
df -i /

Als IUse% de waarde 100 rapporteert, verwijdert u de node_modules-mappen van branches waarop u niet meer werkt. U kunt ook overstappen op pnpm. Daarbij wordt elke pakketversie één keer opgeslagen en met hard links in elk project beschikbaar gemaakt.

Logs zijn de stille oorzaak. Een agent die voortdurend actief is, schrijft sessietranscripten. Het systemd-journal groeit standaard eveneens tot een aanzienlijk deel van de schijfruimte.

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

Stel SystemMaxUse=200M in /etc/systemd/journald.conf in en voer sudo systemctl restart systemd-journald uit om deze limiet permanent te maken. Een eenmalige vacuumactie maakt namelijk alleen de ruimte van vandaag vrij.

Swap: wat het oplevert en wat het verbergt

Swap is de moeite waard, omdat een kleine overschrijding daardoor leidt tot traag werk in plaats van een gestopt proces. Stel de grootte in op de helft van het RAM-geheugen, tot ongeveer 4 GB. Op een build-server is er weinig reden om verder te gaan.

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 moet nu /swapfile vermelden met de grootte die u hebt opgegeven. Zonder de regel /etc/fstab is de swap na de volgende reboot verdwenen en keert de server stil terug naar het oude gedrag. Als fallocate antwoordt met Operation not supported, maakt u het bestand met sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 en gaat u verder vanaf chmod.

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

Een lage swappiness zorgt ervoor dat de kernel eerst de diskcache vrijgeeft voordat programmageheugen naar schijf wordt verplaatst. Daardoor blijft een language server responsief.

Dit is het deel dat swap verbergt. Wanneer een job echt meer geheugen nodig heeft dan de server beschikbaar heeft, besteedt de kernel zijn tijd aan het verplaatsen van pagina's tussen RAM en schijf in plaats van uw build uit te voeren. Er crasht niets. Alles wordt traag en de load average loopt op terwijl de CPU niet actief is.

vmstat 1 10

Aanhoudende niet-nulwaarden in de kolommen si en so betekenen dat er voortdurend wordt geswapt. De oplossing is dan minder gelijktijdigheid of meer RAM, en nooit meer swap. Op een kleine server levert sudo apt install -y zram-tools gecomprimeerde swap die in RAM wordt opgeslagen en in /etc/default/zramswap wordt geconfigureerd. Dit is veel sneller dan een swapbestand. Het gebruikt RAM om RAM te besparen en helpt daarom bij koude pagina's, maar niet bij een build die daadwerkelijk meer werkgeheugen nodig heeft.

Waarom uw coding agent lijkt vast te lopen

Dit is de meest verkeerd gediagnosticeerde fout op een kleine agentserver. Een opdracht retourneert niets, de agent wacht en de sessie lijkt vastgelopen. Het proces is door de kernel beëindigd door de out-of-memory-killer (OOM-killer). Het ontving SIGKILL en kon daarom geen foutmelding afdrukken, geen log wegschrijven en de agent niet informeren over wat er was gebeurd. De agent ziet een leeg resultaat en geen afsluitbericht.

De kernel registreert dit wel:

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

Een echte regel ziet er als volgt uit:

[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 geeft aan hoeveel geheugen dat proces gebruikte toen het werd beëindigd. Let op welk proces is geselecteerd: de kernel baseert de score voornamelijk op het geheugengebruik. Daarom beëindigt de kernel vaak de language server of de agent, en niet de build die de server over de grens duwde. Daarom lijkt het probleem precies alsof "de agent is uitgevallen".

Binnen Docker laat hetzelfde incident een duidelijker spoor achter. De container wordt afgesloten met code 137. Dat is 128 plus signaal 9.

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

"OOMKilled": true bevestigt dat de container zijn geheugenlimiet heeft bereikt en niet zelfstandig is gecrasht.

De oplossing is om de opdracht die veel resources gebruikt een eigen limiet te geven. Dan wordt de build beëindigd in plaats van de agent:

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

De build wordt nu bij 4 GB beëindigd en de agent blijft actief. Een onverklaarbare vastloper verandert daardoor in een gewone mislukte opdracht met een leesbare exitcode. Hiervoor is een systemd-gebruikerssessie vereist. Voer loginctl enable-linger $USER daarom uit op een server die u uitsluitend via SSH bereikt. MemoryHigh= beperkt het proces bij de drempelwaarde in plaats van het te beëindigen. Dat is vaak een betere instelling voor een build die u liever langzaam laat voltooien.

Stel dit eenmalig in met geheugenlimieten in Compose

Als de tools van de agent in containers worden uitgevoerd, stelt u de limiet in het Compose-bestand in. Dan geldt deze bij elke uitvoering.

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

Docker Compose v2 past deploy.resources.limits toe bij een gewone docker compose up. De swarm-modus is daarbij niet betrokken. De oudere sleutel mem_limit: 2g werkt nog steeds. De volledige handleiding voor geheugenlimieten in Compose behandelt reservations en wat er gebeurt wanneer een container de limiet bereikt. Als Docker nog niet op de server staat, installeert u eerst Docker op een VPS installeren.

Eén valkuil kost mensen een middag. Een container met een limiet van 2 GB leest nog steeds de host-/proc/meminfo en het aantal CPU's van de host, omdat geen van beide door namespaces wordt afgeschermd. Een testrunner die het aantal workers bepaalt op basis van het aantal CPU's, start acht workers in een container van 2 GB op een host met acht vCPU's. Daarna stopt het proces met exitcode 137. Stel de waarden handmatig in:

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

--max-old-space-size is uitgedrukt in MB en begrenst de V8-heap. Stel deze waarde lager in dan de containerlimiet. Dan geeft Node een foutmelding die u kunt lezen, in plaats van stil te verdwijnen:

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

Die melding is nuttig, omdat deze de bereikte limiet en het proces vermeldt dat de limiet heeft bereikt. De OOM-killer doet dat nooit.

Meerdere agentsessies op één server uitvoeren

Plan per sessie, niet per persoon. Twee sessies op dezelfde repository betekenen nog steeds twee language servers, twee sets buildcaches in het geheugen en twee testruns als beide agents op hetzelfde moment actief worden. Daarom springt de teamrij naar 16 GB.

Stel voor elke gebruiker een harde limiet in. Zo kan één sessie die uit de hand loopt de hele server niet onbruikbaar maken:

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

Vervang 1001 door de UID die id -u heeft weergegeven. systemctl show moet MemoryMax=6442450944 weergeven zodra de gebruiker is ingelogd. Wanneer alles in de sessie van die gebruiker meer dan 6 GB gebruikt, beëindigt de kernel een proces binnen haar slice. Alle andere sessies blijven werken. Voor een agent die als service en niet in een terminal wordt uitgevoerd, plaatst u MemoryMax= in het unitbestand. Dat is de te volgen aanpak wanneer u een agent als always-on service zelf host.

FAQ

Is 2 GB aan RAM genoeg voor een coding agent?

Voor het agentproces wel. Voor het werk dat het uitvoert, zelden. De agent gebruikt ongeveer 250 MB, maar één TypeScript language server kan op een repository van gemiddelde omvang 2000 MB bereiken. Daarmee gebruikt een systeem met 2 GB al swap. 2 GB is geschikt voor het bewerken van configuratiebestanden en kleine scripts. Gebruik 4 GB als minimum voor alles wat compileert of een testsuite uitvoert.

Heb ik een GPU nodig om een coding agent op een VPS uit te voeren?

Niet als de agent via een API een cloudmodel aanroept. Deze workload is netwerkgebonden. Een gewone CPU-VPS is daarom de juiste machine en een GPU blijft ongebruikt tegen aanzienlijk hogere kosten. U hebt alleen een GPU nodig als het model zelf op dezelfde machine draait. Dan gaat het niet meer om RAM, maar om VRAM en de modelgrootte.

Hoeveel swap moet ik aan een agent-VPS toevoegen?

De helft van het RAM, tot ongeveer 4 GB. Swap beschermt u tegen een korte overschrijding. De kernel kan dan inactieve geheugenpagina's naar schijf verplaatsen in plaats van een proces te beëindigen. Swap voegt geen bruikbaar geheugen toe. Als vmstat 1 voortdurend verkeer toont in de kolommen si en so, is het systeem aan het thrashen. Kies dan voor minder parallelle workers of een groter plan.

Waarom loopt mijn coding agent midden in een build vast?

De build is vrijwel zeker beëindigd door de OOM-killer van de kernel. Die stuurt SIGKILL. Daardoor wordt niets afgedrukt en wacht de agent op een pipe die nooit vol raakt. Voer sudo dmesg -T | grep -i "killed process" uit en controleer de procesnaam en de waarde van anon-rss. Los dit op door de build met systemd-run --user --scope -p MemoryMax=4G te begrenzen en het aantal workers te verlagen, of door naar een RAM-tier met meer geheugen over te stappen.