Measured logged in: MendCode now holds less memory and disk than pi
Five coding CLIs, logged in, at their real prompt, answering the same question. MendCode went from 145 to 130 MB at the prompt, from about 200 to 139 MB after a reply, and from 3.5 to 2.6 KB on disk per session.
Earlier figures on this site came from MendCode alone, at an empty prompt. This time every CLI was measured the way a person uses it: signed in, at its usable prompt, answering the same question in the same small project. That showed a cost the old figures never saw: the first answer of a session took MendCode from 145 to about 200 MB.
How it was measured
The same run for every tool, on one Mac
- A pseudo-terminal of 160 by 45, a temporary HOME with only that tool's login copied in (Claude Code keeps its login in the keychain, so it ran on the real HOME with no user settings or MCP servers).
- gpt-6-luna for MendCode, pi, Codex and OpenCode; Haiku for Claude Code.
- The question: read src/theme.ts and list each color with its hex value, without editing anything.
- Memory of the tool's whole process tree at the prompt (after 12 s), right after the reply and 30 s later: resident size (RSS) and physical footprint, the figure Activity Monitor shows.
- Disk: every byte the session stored. For MendCode, every column of every row of that session in its database; for the others, their session files.
- Three alternating launches per MendCode tier and for pi; medians.
Results
At the prompt / after the reply, and disk per session
| Tool | RSS | Footprint | Disk |
|---|---|---|---|
| MendCode minimalist | 129 / 138 MB | 63 / 67 MB | 2.5 KB |
| MendCode balanced | 130 / 139 MB | 64 / 66 MB | 2.6 KB |
| MendCode full | 131 / 140 MB | 64 / 69 MB | 2.6 KB |
| pi | 133 / 139 MB | 81 / 88 MB | 2.85 KB |
| Claude Code (Haiku) | 289 / 314 MB | 146 / 152 MB | 302 KB |
| Codex CLI | 310 / 507 MB | 215 / 330 MB | 43 KB |
| OpenCode 1.19.5 | 1,220 / 1,324 MB | 551 / 591 MB | 28 KB |
MendCode is lower than pi at the prompt, level with it right after the reply in resident size, and 15 to 22 MB lower in footprint throughout. Its peak footprint is 78 to 80 MB against pi's 96 to 98.
Where a turn's memory went
Five causes, each measured before and after
- Settings were read over a thousand times in a first turn, each read parsing the stored JSON and validating every key. They are kept validated until the stored text changes. After the reply: about 200 → 160 MB.
- The runtime gives each chunk of a streamed response its own 256 KB buffer, freed only by a collection: about 32 MB for a short answer. Each buffer is released once it is decoded.
- The 81 tool schemas of the first request were built during the turn. They are built before it, eight at a time with a short collection in between.
- The pages a collection frees are handed back to the system after the idle and start-up collections. Footprint at the prompt: 72 → 65 MB.
- A terminal that runs MendCode in one process now drops the DFG JIT tier, like a terminal that only draws: 6 MB lower at the prompt and after a turn. Scanning files for the code graph, the one loop that needed DFG, runs in a short process of its own with every tier, so building the graph is no slower (1.8 s for this repository's 3,288 files).
Where the bytes went
A short session is mostly small rows, and zstd learns little from a row of a few hundred bytes. Most of what such a row holds is MendCode's own spelling: the JSON envelope of a model message, tool names and argument keys, the orientation block that opens every session, event types and their keys.
Three changes, 3.5 → 2.6 KB
- Small model messages are deflated against a frozen dictionary of that spelling when it is smaller. On a real data directory's 6,495 small messages: 46 % smaller than as text, against 31 % with zstd alone.
- Short sealed turns use a second dictionary of event envelopes: 17 % smaller than with zstd alone on real turns under 4 KB. Longer turns keep zstd.
- Calls outside a turn (titles, summaries) were counted once per session; no report read that column. They roll up per day, model and project.
What is not better yet
Measured the same way
- CPU per turn: MendCode spends 1.1 to 1.5 s on this question, pi 0.2 s, for about as many frames. Each MendCode frame rebuilds every row (about 7 ms); pi redraws only what changed. That is the next piece of work.
- Resident size 30 s after the reply moves between 93 and 141 MB for both tools, depending on when macOS takes back freed pages; footprint stays lower for MendCode.
- Sessions written by this version cannot be opened by earlier ones.