audit64 · one run27.2× RSS ratio
441 vs. 11,981 MiB at 64 workers. This is sampled process-tree RSS, not unique physical-memory accounting.
Evidence · July 2026
On one 32 GB Mac, Pixir used less sampled process-tree memory than a process-per-worker CLI baseline. Completion and elapsed time varied by workload. These results describe those configurations—not a universal speed or quality advantage.
codex exec workersHistorical results, not benchmarks of the 0.1.17 candidate or Astra. The proc-pressure report identifies gpt-5.5 / low effort and a pinned Pixir 0.1.5 benchmark binary; some older Codex version stamps are unavailable.
audit64 · one run441 vs. 11,981 MiB at 64 workers. This is sampled process-tree RSS, not unique physical-memory accounting.
Completion variedThe first audit64 run completed 64/64 on both arms. A later ladder completed 199/205 in Pixir and 205/205 in the baseline.
No blanket speed claimOne comparable 64-worker run took 113 s vs. 112 s. The earlier audit64 run lacks a valid baseline batch timer.
01 · Memory
Both arms audited 64 modules from this repository. The published samples reproduce a 27.16× ratio between their peak RSS values. This comparison has one repetition.
audit64 · July 5 · N=64 · shared axis, 0–11,981 MiB
Peak of 187 Pixir samples and 545 baseline samples. Sampling can miss short-lived peaks; the tracked process set and timing window matter.
A separate synthetic ladder at N=1, 2, 4 and 8, with three repetitions per level, estimated marginal RSS of 6.5 MiB per additional Pixir child (bootstrap 95% interval: 4.9–7.7), versus 96.8 MiB (95.9–97.5) for the baseline. Those intervals describe that small ladder, not the N=64 run or every machine.
No N=150 projection is plotted here. These measurements do not establish a swap threshold or the footprint of hundreds of concurrent workers. RAM workspace storage is also a different metric from process RSS.
02 · Processes
The separate proc-pressure experiment measured the tracked process trees, including helpers. A shared BEAM runtime is not literally one OS process. Its real-work measurements include transport and client overhead.
| Measured total | Pixir delegate | Process-per-worker |
|---|---|---|
| Peak OS processes | 6 | 474 |
| Peak threads | 45 | 6,111 |
| Peak process-tree RSS | 482 MiB | 8,236 MiB |
| Kernel CPU | 16.9 s | 187.1 s |
| Involuntary context switches | 0.69 M | 4.93 M |
Different experiment, date and cache state from audit64 above. These totals are not evidence that all implementations of one architecture have the same cost.
N=1–32, five repetitions per level, gpt-5.5 / low effort. The controlled low-ambient condition suppressed background activity; it was not a typical idle Mac. Values below are marginal slopes with bootstrap 95% intervals.
| Per additional worker | Pixir | Baseline |
|---|---|---|
| Peak threads | 0.0 [0.0, 0.0] | 100.5 [94.9, 104.4] |
| Peak OS processes | 0.0 [0.0, 0.0] | 8.0 [7.1, 8.7] |
| Involuntary context switches | 2,445 [1.4k, 4.1k] | 45,018 [42.8k, 47.9k] |
| Kernel CPU | 0.04 s [0.03, 0.06] | 1.30 s [1.25, 1.37] |
03 · Time & completion
| Experiment | Pixir | Baseline |
|---|---|---|
| Synthetic · N=16 · one run | 28.9 s | 21.4 s |
| Synthetic · N=32 · one run | 25.0 s | 38.2 s |
| audit64 · July 5 · N=64 | 202 s | Unavailable |
| proc-pressure · July 6 · N=64 | 113 s | 112 s |
The audit64 baseline has a reported maximum child duration of about 96 s, but its batch timer was contaminated by an orchestrator bug. That number is not an equivalent end-to-end comparison with Pixir's 202 s.
| Run set | Pixir | Baseline |
|---|---|---|
| audit64 · July 5 | 64/64 | 64/64 |
| proc-pressure · loaded ladder | 199/205 | 205/205 |
| Pixir acceptance rerun · two builds | 204/205 | Not rerun |
The loaded ladder lost six Pixir children: three WebSocket reads, one WebSocket close and two provider server errors. Three retained partial output. The acceptance rerun used different builds; it is not a controlled estimate of a fix's effect.
04 · Transport
The export records 31 HTTP/SSE calls among 673 Pixir provider calls (4.6%). All 64 children completed that run. Completion alone does not prove the absence of duplicated effects.
| Reason | Calls |
|---|---|
| websocket_handshake_failed | 17 |
| websocket_degraded | 13 |
| websocket_closed | 1 |
N=16 and N=32 synthetic runs recorded no fallback; one N=8 repetition did. These are different workloads with limited repetitions, not a measured universal WebSocket threshold at 64 workers.
05 · Tokens & findings
audit64 asked both arms to inspect the same 64 modules. Both produced schema-valid JSON. Pixir reported fewer uncached input tokens, but more total input and output tokens.
| Metric | Pixir | Baseline |
|---|---|---|
| Total input tokens | 7,828,640 | 6,183,081 |
| Uncached input tokens | 1,470,112 | 1,812,137 |
| Reported output tokens | 120,645 | 73,432 |
These are usage counters, not a price quote or an answer-quality score. A completed Codex turn is not interchangeable with a Pixir provider call; call-count differences do not establish that one arm worked more deeply.
The two arms agreed on four candidate major documentation findings. Agreement is useful corroboration, but the shared model can also share errors. Independent adjudication is needed before calling those findings correct or claiming superior quality.
06 · Method & sources
From a Pixir source checkout, inspect the spec and rehearse before any paid or quota-consuming run:
mix deps.get
mix escript.build
./pixir delegate --spec docs/benchmarks/scale/audit64-spec.json --dry-run --json --timeout-ms 1200000 The dry-run does not call the model. Running without it launches up to 64 workers and consumes your configured provider quota. Historical results are not promises for a different model, version or machine.