How much overhead does AgentSight add?

The direct answer: 2.9% was an average across three end-to-end workflows

AgentSight’s paper measured wall-clock runtime for repository understanding, code writing, and repository compilation with and without AgentSight. The reported task-level overheads were 3.4%, 4.9%, and 0.4%; their arithmetic mean is about 2.9%. The result supports a modest historical claim: in those three tested workflows, the original system added a small average end-to-end runtime cost. It does not establish a fixed overhead for every workload, capture mode, machine, agent, or current release.

What exactly was measured?

The paper records Ubuntu 22.04, Linux 6.14.0, Claude Code 1.0.62, Claude 4, and the eunomia-bpf/bpf-developer-tutorial repository. The three workflows were Claude’s /init repository-understanding task, generation of a bpftrace CPU-frequency script, and a parallel repository build. Each workflow was executed three times without AgentSight and three times with AgentSight. The raw experiment records are still available in the current v1.0.25 source tree at commit 0080545f7c6b, which makes it possible to inspect the individual timings rather than only the paper’s summary row.

The published means and the variability behind them

The standard deviations above are recomputed from the raw three-run records, not copied from the paper. They matter because the sample is small. For repository understanding, the AgentSight runs were 115.196 s, 111.916 s, and 169.884 s; that last run pulls the mean upward and produces a 32.56 s sample standard deviation. For code writing, the AgentSight runs ranged from 20.08 s to 29.01 s. Compilation was much tighter: 91.79–93.55 s with AgentSight.

This is runtime overhead, not a measured CPU-utilization percentage

The evaluation question and Table 1 are explicitly about runtime overhead. The measured quantity is elapsed task time. A 2.9% average wall-clock delta should not be silently restated as “2.9% CPU overhead,” because CPU utilization, CPU time, memory pressure, I/O, event volume, and wall-clock latency are different metrics. A current deployment can have low elapsed-time impact while still adding measurable CPU work, or vice versa when the workload is dominated by remote-model latency.

Three runs are enough for a smoke benchmark, not a tight confidence interval

With only three observations per condition, one slow agent response or external-service delay can move the mean materially. The repository-understanding AgentSight median is 115.196 s even though its mean is 132.332 s; the baseline median is 131.221 s. That reversal is a warning against treating the 3.4% mean delta as a stable per-run tax. The compilation mean difference is only 0.32 s, smaller than the 0.88 s sample standard deviation of the AgentSight runs. These measurements are useful descriptive evidence, but they do not support a precise universal confidence bound.

The historical result is not a v1.0.25 performance guarantee

The benchmark environment used Claude Code 1.0.62 and the implementation described by the 2025 paper. AgentSight has changed substantially since then: current v1.0.25 includes additional agent-native, saved-session, Direct Node, and frontend workflows alongside Linux eBPF recording. The old benchmark is still valuable because the raw measurements are public and the experiment is understandable, but it should be cited as a historical evaluation of a particular workload and system configuration. If your decision depends on current overhead, benchmark the current binary and the exact capture path you plan to deploy.

Measure the capture mode you actually intend to use

“AgentSight overhead” is not one indivisible mechanism. A live Linux recording can include kernel event capture, process-lineage filtering, file/network observation, TLS uprobes, userspace parsing, SQLite writes, and an optional local web server. By contrast, agentpprof can analyze existing local session history offline without running the eBPF capture path at all. Decide first which features matter to your deployment, then measure that configuration instead of enabling every signal and generalizing the result to lighter modes.

A better current benchmark alternates conditions and keeps the raw runs

For a deployment decision, use the same repository snapshot, agent/model configuration, prompt, machine, kernel, network path, cache policy, and AgentSight version. Run more than three repetitions when the agent or network is noisy. Alternate or randomize baseline and traced conditions instead of running all baselines first, so time-of-day and service drift are less likely to bias one side. Record elapsed time, user/system CPU time, peak RSS, and AgentSight event counts; report the individual runs plus median, mean, dispersion, and a confidence interval when the sample supports one. For compilation-style tasks, state whether caches are warm or cold. For model-heavy tasks, separate provider latency from local instrumentation cost where possible.

Use the normal record path, but do not confuse correctness with low overhead

The current product workflow remains sudo agentsight record -- <command>. Before comparing timings, confirm that the traced run actually captured the signals you expected; a “fast” run with an attachment failure is not a valid overhead measurement. Conversely, a correct trace with higher event volume may legitimately cost more than one with aggressive filtering. Performance acceptance should therefore pair two tests: did the recorder capture the required behavior, and did the measured cost stay inside the latency/resource budget for this workload?

# Baseline: repeat the exact workload and retain /usr/bin/time output
/usr/bin/time -f 'elapsed=%e user=%U sys=%S maxrss_kb=%M' <agent-command>

# Traced: repeat the same workload under the current AgentSight recorder
/usr/bin/time -f 'elapsed=%e user=%U sys=%S maxrss_kb=%M' \
  sudo agentsight record -- <agent-command>

What number should you use?

For describing the published experiment, use: “AgentSight reported 2.9% average end-to-end runtime overhead across three tested developer workflows, with per-workflow means of 3.4%, 4.9%, and 0.4%.” For capacity planning, do not use 2.9% as a constant. Use a current benchmark of your own representative workload and state the AgentSight version, capture mode, environment, repetitions, and variability next to the result. The more model- or network-dominated the task, the less an end-to-end percentage tells you about the local cost of instrumentation by itself.