Agent? Fetch sharkmagic.si/docs/llms.txt or this page as markdown
Measured numbers, with their fine print#
Every number here comes from a pre-registered proof with written PASS / FAIL thresholds; failures are listed next to wins. Two machines appear on this page; always read which one a number is from:
- AX41: the hosted node
hel1(Hetzner AX41: AMD Ryzen 5 3600, 6 cores / 12 threads, 64 GB RAM, 2 × 512 GB NVMe, the hosted node). Its numbers are the ones that describe the service you use. - EPYC: a larger lab server (AMD EPYC 9254, 24 cores / 48 threads, 751 GiB RAM, 2 × 1 TB NVMe) used for density and scaling proofs on 2026-11-02. Its numbers do not transfer to the AX41 one-to-one.
Unless noted, latencies are server-side (the client on the same machine, no internet round trip) and the lease shape is 8 vCPU / 4 GiB.
On the hosted hardware (AX41, metal run of 2026-11-05)#
| what | result |
|---|---|
| lease: a fresh microVM for one command | 44 ms |
| create a Space → first command done | 65 ms |
| burst: 24 new Spaces, each created and running its first command, at once | all 24 done in 342 ms |
| first command of a sleeping (hibernated) Space | 58 ms |
| a sleeping service answers its first query (Postgres, the example the measurement used) | 37–40 ms |
| create a durable Space (replicated to the object store), server time | 1.3 ms |
| share of a command's time that is the user's own command (the rest is Shark's overhead) | 91–96 % |
Grep/Glob served from the index (sharkfn) vs ripgrep over the FUSE mount, 100k-file tree |
300–600× faster |
These come from the AX41 metal report of 2026-11-05. Exposed processes and previews were run end to end on the hosted node on 2026-11-07 (below).
On the lab server (EPYC, 2026-11-02)#
"Default" = the server's default flags; "BEST" = an opt-in set of flags that was not the default then.
Latency#
| what | result | config | proof |
|---|---|---|---|
create a Space → first command (true) done, sequential |
p50 55.3 ms, p99 59.0 (n=100) | BEST | P85 r3 H3 |
| same | p50 86.8 ms, p99 89.7 (n=100) | default | P85 r3 H3 |
n-th command (true) in an existing Space |
p50 46.7 ms, p99 54.2 (n=400) | BEST | P85 r3 H1 |
| same | p50 85.9 ms, p99 93.4 (n=400) | default | P85 r3 H1 |
| burst: 100 new Spaces at once, create + first command each | per request p50 408.4 ms, p99 514.0; all 100 done in 516–524 ms; 2 bursts, 200/200 succeeded | BEST | P85 r3 H4 |
| same | per request p50 803.9 ms, p99 886.9 | default | P85 r3 H4 |
Postgres 17 from pause: psql -c 'select 1' from inside a lease |
p50 31.5 ms, p99 40.2 (n=99) | default | P85 r3 H5b |
| Postgres 17 from snapshot | p50 48.2 ms, p99 69.5 (default); p50 37.3, p99 86.5 (BEST) | P85 r3 H5a | |
| first command of an idle Space | p50 59.5 ms, p99 62.1 (BEST, hibernated) vs 94.3 / 105.1 (default) | P85 r3 H7b |
Fine print: P85's pre-registered global verdict for BEST is FAIL: it won every latency hypothesis above but lost
H8 (idle CPU per Space was already ~0 with defaults, so BEST could not lower it) and H6 (memory per live VM; the
analysis was broken and is read as inconclusive). Sources: proofs/p85-best-setup/results/ks5-phase-cfbf65a52-sprint-r3/summary.md
and READING.md; per-phase breakdown in proofs/p96-bottlenecks/forensics-lifecycle/REPORT.md.
Dormant Spaces and scale#
| what | result | proof |
|---|---|---|
| disk per dormant Space | 57,037 bytes (sampled du at the highest step; target ≤ 256 KB: PASS) |
P87 D3 |
| dormant Spaces held | 53,312 at the end of the run (target ≥ 100,000: FAIL, limited by run time and creation rate) | P87 D1 |
| wake a dormant Space (first command) with 53,312 dormant, server quiet | p50 62.5 ms, p99 67.1 (n=50) | P87 b4, P96 |
| same, while ~196 Spaces/s were being created | p50 245–268 ms, p99 up to 619 ms | P96 table D |
| Spaces created on one server in one run | 150,956 at ~195/s; 143 failed (0.095 %), cause not recorded | P87 b4, P96 C2 |
| wrong result on wake | 1 of 750 wakes did not return its token; plausibly a harness sampling bug, not proven | P96 C1 |
P87 D2 (wake latency) is INCONCLUSIVE because of that unexplained token. A projection of ~14.8 million dormant Spaces
by disk size is a projection, not a measurement. Sources: proofs/p87-real-density/results/ks5-phase-c68463b52-r1/summary.md,
proofs/p96-bottlenecks/forensics-lifecycle/REPORT.md.
Live VMs#
| what | result | proof |
|---|---|---|
| 1,000 live microVMs at once, each serving short commands and probes | 0 failures; but short-command p99 46.3 ms vs 20.7 ms at 100 VMs: outside the pre-registered latency SLO | P87 b1 |
| most live VMs inside the SLO | 500 (target ≥ 4,000: KILL) | P87 V1 |
| private memory per live VM (at 500) | 18.9 MiB (target ≤ 64 MiB: PASS) | P87 V2 |
| idle VMs started (no command), BEST | 4,000 of 4,000 (defaults: 917 of 1,000) [exploratory] | P85 r3 READING |
Grep and Glob (shark-rg), local sandbox only#
Measured in a 4-core development VM without KVM, not on metal (P95). Claude Code's own Grep argv, Go source tree:
| shark-rg p50 | rg over the FUSE mount p50 |
rg on local disk p50 |
|
|---|---|---|---|
| Grep (n=300) | 18.0 ms | 437.9 ms | 36.7 ms |
| Glob (n=100) | 6.8 ms | 249.6 ms | 16.6 ms |
100,000-file tree: Grep 17.4 ms vs 392.7 ms for rg on local disk; Glob 74.6 ms (target ≤ 50 ms: missed). P95
verdicts: T1 PASS (tool definitions sent to the model byte-identical), T2 KILL for 5 flag combinations (they now go to
the real rg by default; 0 differences in 4,320 calls after fixes), T3 FAIL, T4 PASS (89 % of calls served), T5
FAIL (CPU per call), T6 PASS (meter privacy). Source: proofs/p95-sharkfn-transparent/README.md.
Agent time (public traces)#
3,921 autonomous public sessions, 349.2 h: model 82.7 %, commands and services 10.2 %, idle 5.9 % (P88,
proofs/p88-tool-call-profile/landing-hour.md; details in billing.md). Derived from that profile and the
measured per-hop costs (a model, not an end-to-end run): Shark adds ~37 s per autonomous agent-hour with defaults and
~21 s with BEST (P96, proofs/p96-bottlenecks/forensics-agent-hour/REPORT.md).
Not ready#
- Secrets, egress, per-account templates on metal: passed locally (P111, P108), on-metal runs written and not run.
shark connect(the terminal over the API): local gates PASS (P112); not yet run on the hosted node. Exposed processes and previews are live there: the end-to-end flow passed onhel1(P130, 2026-11-07; a preview woken from sleep served its first byte in p50 127 ms, p99 153 ms over 30 wakes; results fileproofs/p130-sleeping-services/results/metal-r1/flow.jsonon themetal/ax41branch).- Failure records. In the EPYC density runs, failures (143 creates, 1 wake) have no recorded cause.