Comparing AI Agent Runtimes on On-Premise Linux: Measuring Startup, Memory, CPU, and Latency of Node.js, Bun, Deno, and a Rust Native Binary

Abstract

Measured evidence is lacking on whether the Node.js family or a Rust native binary is the better runtime for running AI agents on on-premise Linux. Prior language comparison studies address CPU-bound benchmarks and do not cover agent loops dominated by waiting for LLM responses. This study implements the same agent loop, consisting of conversation history transmission, SSE stream parsing, and tool subprocess execution, once in JavaScript (run on Node.js 24, Bun 1.4, and Deno 2.9) and once in Rust (tokio multi-threaded and single-threaded), isolates server time with a mock LLM server, and measures them in an aarch64 Linux container. Startup time for 1 session was 3.8 ms for Rust and 35.6 ms for Node.js. At 500 concurrent sessions, Rust's peak RSS was 159.7 MB, smaller than Bun's 383.9 MB and Node.js's 775.8 MB, and the median orchestration overhead was 2.24 ms for Rust (multi-threaded), 174.09 ms for Bun, and 299.58 ms for Node.js. At around 10 sessions, the differences were small. The musl static binary was 1.44 MiB, more than 50 times smaller than the JavaScript runtime binaries. The results were obtained on a single virtual machine, and reproduction on x86 bare metal is left for future work.

Key Contributions

• We implement the same protocol and loop once in JavaScript (shared across the three runtimes) and once in Rust, and present a measurement method that isolates server-side time with a mock LLM server.
• We measure memory, overhead, and CPU time across 1–500 concurrent sessions, and report that the differences grow with concurrency and that even single-threaded Rust shows smaller overhead than the JavaScript runtimes.
• We jointly report startup time, long-running resident RSS, and deployment artifact size, and summarize the acceptance and rejection of three pre-registered hypotheses.

Conclusion

Even in agent loops dominated by LLM waiting, the choice of runtime produced measurable differences as the number of concurrent sessions grew. Across the tested 1–500 sessions, the Rust implementation kept the median orchestration overhead at or below 6.26 ms, and was the smallest in startup time, memory, CPU time per turn, and deployment size alike. The JavaScript runtimes had small overhead at around 10 sessions but exceeded the predefined criteria at 100 sessions or more, and the extent of this varied considerably even among Node.js, Bun, and Deno. Future work requires repeated measurements on x86 bare-metal on-premise servers, workloads that include real LLM latency and TLS, resident measurements lasting several hours or more, and comparison with multi-process Node.js configurations.