DATASET 004 / RELEASE-MODE PROBES
Parallel Coding Agent Terminal Benchmarks from GridBash
Twenty live coding agents make the terminal part of the workload. These numbers isolate two hot paths that were wasting CPU before the agents even got it.
Benchmark results
| Workload | Before | After | Reduction | Speedup | Change |
|---|---|---|---|---|---|
| Render an unchanged 120x40 terminal pane | 273.6 μs | 75.3 μs | 72.5% | 3.6x | Cache the fully rendered pane cell buffer |
| Filter ANSI terminal output into history text | 26.1 μs | 14.4 μs | 44.8% | 1.8x | Add an ASCII-run fast path and avoid duplicate allocations |
What these probes test
GridBash is a Rust terminal grid for running real PTY-backed Codex, Claude Code, Gemini CLI, and other command-line agents. A large grid repeatedly revisits terminal panes even when most panes did not change during that frame. The first probe measures that unchanged render path for a 120×40 pane.
The second probe measures the path that turns ANSI terminal output into searchable history text. Coding agents produce a lot of mostly ordinary ASCII mixed with control sequences. Treating ordinary runs as ordinary runs avoids per-character overhead and duplicate allocations.
What changed in the implementation
- Cached fully rendered pane cell buffers instead of rebuilding unchanged styled lines every frame.
- Skipped idle PTY routing maps and workload scans until an event or visible state change required them.
- Kept output batches in arrival order while replacing tree-based batching with constant-time hash lookups.
- Added an ASCII-run path, tracked character counts during filtering, and removed duplicate control-sequence allocations.
- Replaced sleeping-pane text allocation with direct frame-buffer clearing.
None of those changes makes a model reason faster. They reduce orchestration overhead so the machine spends less time repainting quiet panes while active agents are compiling, testing, or producing output.
How to reproduce the benchmark
Clone GridBash, use a release build, and run ignored benchmark probes on one test thread. The serialized thread count reduces competition between the two microbenchmarks; it does not remove normal machine-to-machine variance.
git clone https://github.com/jasonsuhari/gridbash.git
cd gridbash
cargo test --release benchmark_ -- --ignored --nocapture --test-threads=1The release containing these optimizations was also checked with 174 release tests, three intentionally ignored probes, Clippy with warnings denied, launcher tests, and a release build. Exact output will vary by hardware and later code changes, so compare before and after on the same machine and commit.
What the dataset does not claim
This is not evidence that 20 agents deliver 20 times more software. It is not an end-to-end benchmark of Codex against Claude Code. It does not measure task correctness, merge rate, token cost, or developer attention. It measures two specific GridBash hot paths before and after specific optimizations.
That narrowness is the point. A benchmark should tell you what was measured before it tells you what to believe. For the surrounding resource and integration architecture, read the coding agent orchestration guide.
Why terminal overhead matters at agent scale
A human terminal can waste a little CPU without anyone noticing. A grid of active agents multiplies output parsing, history maintenance, screen updates, routing, and redraw work. If the interface starves input handling, the operator loses the ability to interrupt or redirect the very system that is creating the load.
The practical design rule is to bound work per event-loop turn, cache unchanged state, and preserve responsiveness before chasing maximum output throughput. Observability that freezes under the workload it observes is decorative.
Dataset notes
- Version: 1.0.0
- Measurement unit: microseconds per benchmark iteration
- Command:
cargo test --release benchmark_ -- --ignored --nocapture --test-threads=1 - Source: GridBash engineering devlog
- Last reviewed: 2026-07-17