How much memory does a Claude Code session use?

Measured in August 2026 on Claude Code 2.1.232, on a Linux VPS with 2 vCPUs and 922 MB of RAM, and cross-checked on an Apple Silicon Mac.

• Right after start, before any prompt: about 290 MB RSS. Even claude --version peaks at 288 MB. That is the cost of loading the binary.
• A real session after 44 minutes of work: 392 to 436 MB RSS.
• Of that, 262 to 278 MB is private anonymous memory and 128 to 155 MB is file-backed pages of the binary itself.
• Starting a second session on the same machine reduced available memory by 116 MB, not 400. The binary's file pages are shared between processes.

Since version 2.x, the claude command is a single-file executable built with Bun, about 323 MB on Linux and 307 MB on macOS. It is no longer a node process running a JavaScript file. The npm package only downloads that executable. Most of the resident memory is the runtime and the code it loads, not your conversation. An idle session held open for minutes does not grow.

The part that does grow during a session is Bun's native allocator, not the JavaScript heap. On the Mac, a 10-minute session had 269 MB in the native heap and about 7 MB in the JavaScript VM.

Because the growth is in the native heap, the JavaScriptCore environment variables do nothing useful. In testing, BUN_JSC_forceRAMSize and BUN_JSC_gcMaxHeapSize moved usage by 0 to 8 MB, and BUN_JSC_useJIT=false stopped the binary from starting at all. MIMALLOC_PURGE_DELAY=0 looked like a 20 MB saving on macOS, but that is how macOS reports reclaimable memory; on Linux it changed nothing. Do not put any of these in a deployment.

• First session: budget 400 MB.
• Each additional session on the same machine: about 120 MB.
• A 1 GB VPS runs one session comfortably, and two or three with swap or zram configured.
• Sessions you are not using do not need to stay resident. Exit them and bring them back with claude --resume; the transcript is on disk. Resuming sessions.

On Linux, read /proc/<pid>/status and look at RssAnon (private memory, the number that adds up across sessions) and RssFile (shared binary pages). RSS alone counts the shared pages once per process and overstates the cost of every session after the first.

for pid in $(pgrep -x claude); do
  echo "pid $pid"
  grep -E 'RssAnon|RssFile' /proc/$pid/status
done

The requirements on the own-server page come from these numbers: plan for 1 GB of usable memory per session you run at once, knowing that the first one costs the most.