Hermes TUI benchmark — Ink (current UI) vs OpenTUI (new engine)

Both UIs were run as real binaries in a real terminal, fed the exact same scripted conversations by a fake gateway, and measured from outside the process. Every number below is the typical of repeated runs (median) unless said otherwise. 103 result files · sha 50e34713b · node v26.3.0 · generated 2026-06-11T04:05:28.897Z

The verdict — who won what

  red = Ink (current UI) wins  ·    green = OpenTUI (new engine) wins  ·    grey = tie

One-line summary: OpenTUI is the smoother UI (scrolling, streaming) and Ink is the lighter one (memory, first paint). Everything else is a wash — including reliability, where both recover from a killed gateway with the transcript intact.

Memory at real workloads — what sessions actually look like

The memory debate was framed around 200–300-message sessions. The real session database says that band is the top 5–10%: the typical session is ~20 messages, 90% stay under 182, and the longest real sessions reach ~1941 messages (the longest 1 in 100 — p99) — and at that tail the memory gap widens to 2.9×.

Scroll responsiveness — where OpenTUI wins

Frame smoothness while streaming — where OpenTUI wins

Typing echo & first reply paint

Keystroke echo is a tie — 1–2ms on both, far below anything a human can perceive. The one real difference: after pressing Enter, Ink paints the first reply text in 44ms vs OpenTUI's 107ms. (Single run per UI.)

CPU cost of streaming — including the terminal's side of the work

The hypothesis that Ink's bigger output stream costs meaningfully more CPU in the terminal emulator did not hold at this workload: Ink did push more bytes (3.8MB vs 3.3MB), but the tmux server burned ~0.4 CPU-seconds either way.

Crash recovery — we shot the gateway mid-stream and watched what happened

Each scenario kills, freezes, or yanks something out from under the UI on a live session, then checks: did the UI survive, did the gateway come back, did the stream resume, is the final transcript identical to an undisturbed run, and is anything left running afterwards?

Result: a tie. Both UIs auto-respawn a killed gateway and finish with a byte-identical final transcript and zero orphan processes. Ink respawns faster (~35–87ms vs ~1.0s), but both are well within "didn't lose anything".

Startup

Stress appendix — beyond real usage

Everything below streams 3,000–10,000 messages into one session — past the longest session ever recorded in the real database (~1941 msgs). It shows where the engines break, not what daily use feels like.

Stress-run numbers (3,000-msg marathons + one 10,000-msg run)

Reading guide: "typical" = median; the bracketed range is the middle half of runs (interquartile range). "slowest 1 in 100" = p99. OpenTUI's syntax styling visibly degrades past ~1,400 rendered rows in these marathons (style-handle exhaustion fallback); older OpenTUI runs also show a post-stream crash that was fixed before the latest runs.

Low-memory survival (1GB Docker container)

Run health — can you trust these numbers?

Determinism gate: each UI replayed the same input twice and must produce a pixel-identical final screen (same fingerprint). If this fails, none of the comparisons above are meaningful.

⚠ some runs were flagged: the test rig itself lagged (results kept, but read with care):

Methodology: docs/plans/opentui-bench-suite.md. Real binaries on a real PTY (120×40), fake gateway via HERMES_PYTHON (zero UI changes), outside-the-process /proc sampling, 2GB cgroup caps via systemd. Instrumented diagnostic runs are flagged and never headlined.