You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
E11's density/throughput numbers (knee at c=8, ~39-43 execs/sec) were driven by a synthetic "closed-loop-per-slot" model issuing trivial Execs (true, cat >/dev/null) back-to-back with no think-time gap and no real tool-call payload. This issue is the full validation experiment: replace the synthetic driver with a real agent loop (real model calls, real tool calls) and see whether the throughput/latency picture — and the "sandbox overhead hides behind think-time" argument — survives contact with realistic traffic.
Everything currently measured (E10's 52.74 ms, E11's throughput ladder) is a mechanism measurement, isolated from real workload shape. This is what turns it into a service-level measurement.
It also tests whether the current synthetic-Exec shape (near-instant commands) has been hiding any latency that real tool calls (longer-running commands, larger outputs, more filesystem activity) would expose — e.g., mount-at-acquire cost, or Σ PSS growth under real memory usage rather than idle standbys.
What's already known / where to look
Driver: deploy/microvm/e11-density.sh, drivingModel: "closed-loop-per-slot" — the code path that would need a real alternative. The script already supports a model-stub hook: SH_E11_MODEL_STUB_CMD (see deploy/microvm/EXPERIMENTS.md's "Model-stub dependency gap" note — "absent one it drives the mix itself directly, a disclosed stand-in for the real stub, not the stub itself").
The harness (harness/) and Pi coding agent (pi-fork/) already run real agent sessions elsewhere in the repo; the P6 density work used a model stub with a declared latency profile (300ms TTFT, 12ms/token) rather than a live model — a middle ground between fully synthetic and fully real that's worth considering as a cheaper intermediate step.
Open item from EXPERIMENTS.md's "what happens next" list: "Live gate at low concurrency — validation, not a headline number... blocked on: a model key and a deployed relay." This issue is effectively that item, scaled up from a validation gate to a full density re-run.
Should this reuse the existing E11 ladder shape (sweep c, look for a knee), or does a real workload's arrival pattern (bursty, not closed-loop) need a different driving model entirely?
What tool-call mix is representative — the repo already has a git-chain-based tool workload from the P6 work that could be reused rather than invented from scratch.
Suggested scope for a first cut
Depends on #257 landing first (calibration data). Once available: repeat the c=1,2,4,8 ladder with a declared-latency model stub matching the measured think-time distribution, and check whether the knee position and throughput ceiling change materially from the fully-synthetic baseline.
Part of #256 (P4 epic: next experiments after the metal STOP).
Summary
E11's density/throughput numbers (knee at c=8, ~39-43 execs/sec) were driven by a synthetic "closed-loop-per-slot" model issuing trivial Execs (
true,cat >/dev/null) back-to-back with no think-time gap and no real tool-call payload. This issue is the full validation experiment: replace the synthetic driver with a real agent loop (real model calls, real tool calls) and see whether the throughput/latency picture — and the "sandbox overhead hides behind think-time" argument — survives contact with realistic traffic.Why this matters
What's already known / where to look
deploy/microvm/e11-density.sh,drivingModel: "closed-loop-per-slot"— the code path that would need a real alternative. The script already supports a model-stub hook:SH_E11_MODEL_STUB_CMD(seedeploy/microvm/EXPERIMENTS.md's "Model-stub dependency gap" note — "absent one it drives the mix itself directly, a disclosed stand-in for the real stub, not the stub itself").harness/) and Pi coding agent (pi-fork/) already run real agent sessions elsewhere in the repo; the P6 density work used a model stub with a declared latency profile (300ms TTFT, 12ms/token) rather than a live model — a middle ground between fully synthetic and fully real that's worth considering as a cheaper intermediate step.EXPERIMENTS.md's "what happens next" list: "Live gate at low concurrency — validation, not a headline number... blocked on: a model key and a deployed relay." This issue is effectively that item, scaled up from a validation gate to a full density re-run.Open questions for the spec
Suggested scope for a first cut
Depends on #257 landing first (calibration data). Once available: repeat the c=1,2,4,8 ladder with a declared-latency model stub matching the measured think-time distribution, and check whether the knee position and throughput ceiling change materially from the fully-synthetic baseline.
Part of #256 (P4 epic: next experiments after the metal STOP).