What a separate guard process per agent turn costs: in-process vs fresh proxy vs long-lived session
Median turn latency, one turn at a time: 6.1 ms in-process, 120.7 ms with a fresh guard proxy per turn, 48.2 ms with a long-lived guard; the guard's own share was 25.0 ms per action and under 0.5 ms per read.
MeasurementWhere does it stop?Re-checked
- Designed for
- To measure the latency and process size that a fresh guard process per agent turn adds, against an unguarded in-process path and a long-lived guard, and whether a product needs an embeddable guard.
What was tested
In an agent product, a scripted model answering at once ran turns of one read and one action, so every number is overhead. Three modes: the product’s unguarded in-process tool path, a fresh guard proxy and tool server per turn, and one long-lived guard per conversation. Runs went singly and in parallel, each repeated, on one Apple M4.
What we observed
One turn at a time, median latency was 6.1, 120.7 and 48.2 ms (p95 17.8, 160.8, 98.6); the repeat gave 4.3, 119.7 and 41.8 ms (p95 6.5, 148.9, 46.9). Starting processes took about 65 ms per guarded turn. The guard’s own share was 25.0 ms per action, 15.3 ms of it the durable intent record before sending, and 0.3 to 0.4 ms per read.
What this means for Heimdall
Most per-turn cost was process start-up, not judging. It bears on the delegate’s duty to record before the effect.
Limits
One macOS machine under background load; p95 moved up to twofold between runs. Disk sync dominates the guard’s share and differs on Linux. The measured product is private and raw per-turn data was not kept, so outsiders cannot rerun it.
What remains open
Measure on a Linux production host.