How many coding agents fit on a 4 vCPU, 8 GB server?

How it was measured

The server had 4 vCPU, 8 GB of memory (7.6 GB as Linux reports it) and 4 GB of swap, with the kernel’s swappiness at 10, so it frees cache before it swaps. It ran Ubuntu 24.04 with Claude Code 2.1.309, Codex 0.164.0, Docker, Node.js 24 and Google Chrome 156 installed. Every session got the same prompt in an empty folder: build a notes app with create-next-app (it installed Next.js 16.4.3) whose home page lists notes from PostgreSQL and has a form to add one, run the database in a container from the postgres:17 image, make the production build pass, then run the dev server and check in a headless Chrome that a note added through the form appears on the page, and leave the server and the database running. Each session was given its own ports for its server and its database. They ran in their non-interactive modes, claude -p and codex exec, with approvals off, and nobody answered them.

Before the rounds, one create-next-app run filled npm’s cache and the postgres:17 image was pulled, as they would be on a machine already in use. A sampler read memory, swap, load and processor time every two seconds and every process every ten. The rounds ran one after another between 14:35 and 15:15 UTC, with everything stopped between them. Each session counts as finished when it gave its final answer. Its work was checked afterwards: every session’s production build had completed and every database was running, and in the rounds of one and of four, each agent reported that its browser check had passed.

Four rounds on one server

Peak memory used, swap written, and how long the processor was full, with all four vCPU at least 95% busy:

How long each session took to finish its job:

The eight were five Claude Code sessions and three Codex, and the four were two of each. The idle server used 0.6 GB.

Eight at once: one hard minute

The strain came at the start. Memory used climbed from 2.2 GB at the 16th second to 6.5 GB at the 48th, and peaked at 7.0 GB. Between the 30th and the 65th second the kernel wrote 1.5 GB to swap, and it read about 0.7 GB back over the next two minutes, most of it by the 80th second. That is when each session would have been installing its app’s packages, the job’s first step, which took 25 seconds alone on the idle server. The processes were not read at that moment, so this is the likeliest cause rather than an observed one. From then on memory used mostly stayed between 1.6 and 4 GB while the sessions built, served and checked their apps, and the swap sat idle. The processor was fully busy for about 68 seconds in all, most of it in the first minute, and went on working hard, though not flat out, until near the third minute. The load average peaked at 9.6.

No session failed or stopped. The five Claude Code sessions took 132, 139, 150, 171 and 186 seconds, against 95 for the one run alone. Most of the extra time was in their commands: their installs, builds and checks took 88 to 106 seconds against 43 alone, while their waits on the model came to 41 to 86 seconds against 52. The comparison rests on one solo run, and single runs vary: in the round of four, on a server that was seldom busy, two Claude Code sessions on the same job took 89 and 187 seconds. The three Codex sessions took 292, 379 and 382 seconds, faster than the one Codex session run alone, at 584, so these figures make no claim of a Codex slowdown.

Every session here started in the same second, which puts the eight sessions’ first steps in the same minute. Sessions started minutes apart would spread that minute out; the test does not show by how much.

Four sessions, each with a browser open

An agent driving a browser through a tool keeps it open for the whole session, and a browser is the largest single thing a coding session runs. So in the last round, each of four sessions had its own headless Chrome running from the start, used it for its check, and left a tab open on its app at the end. Memory peaked at 4.2 GB near the start, then mostly stayed between 2 and 3 GB. Nothing went to swap, and the processor was fully busy for about 4 seconds in all.

What takes the memory

The agents are the light part. Read from each session’s processes at their peak, in non-interactive sessions of one and a half to ten minutes:

Interactive sessions doing longer work have been read higher: 394 to 573 MB for a working Claude Code session, and about 420 MB for Codex at rest across its processes (what Claude Code and Codex need from a server). Chrome’s processes share much of their memory, so the sum of their figures overstates it; the machine’s own total in the rounds table is the figure to plan by. So what fills a server is less how many agents run than how many of them build or hold a browser at the same moment. A larger app needs more: a production build of a mid-sized web app has been measured at about 1.8 GB on its own (running many Claude Code sessions from one).

A video encode beside them

After the eight-session round finished, with five of its dev servers and all eight databases still running and about 3.2 GB of memory in use, the server re-encoded a 60-second 1080p test clip with ffmpeg 6.1 (x264, preset medium, CRF 23). It took 152 seconds. The same encode on the idle server took 147 and 151 seconds. Servers and databases that are waiting hold memory and almost no processor. The encode kept all four vCPU at 97 to 99% for its whole run, so one started while agents were building would compete with them; the test did not run that case.

What happens to the servers when a session ends

An unattended session that starts a dev server does not always leave it running. In all six Codex runs, the dev server was gone once the session ended; in the run examined, Codex had run it as a command held open inside the session. In six of Claude Code’s eight runs, the session started its server so that it outlived the session, then exited with the server still answering. In the other two, the session itself kept running after it gave its answer. In the one left running long enough, Claude Code had started the server as a background task; about ten minutes on the server stopped, and the session took a new turn by itself to start it again.

What the test does not show

• More than eight. Eight was the most tried at once, so the test does not say where the limit lies.
• Slower or larger models. Claude Haiku 5.5 and GPT-6 Luna are their labs’ small, fast models. A slower model leaves a session waiting longer between commands, which may overlap the sessions’ builds less; the test does not show it either way.
• Larger apps and longer sessions. Each job was a small app built in one and a half to ten minutes, not a large codebase or a session that runs for hours and grows its context.
• Repeats. Each round ran once, on one Friday afternoon UTC.
• Staggered starts. Every session in a round started in the same second.