How it works

Designs and measures

Each design runs on its own copy of the drive and the workload, on one simulated clock. A design is a cache layout (one object per slot or file, or objects packed into segments), an eviction policy, optionally a filesystem and page cache, and a drive: a flash translation layer with greedy garbage collection, behind a host write limit.

Host WA is the bytes the device receives per byte the clients store. Drive WA is the bytes the flash programs per byte the device receives, garbage collection included. Sustainable is the host write rate the drive keeps up with at its current drive WA: when the design's demand reaches it, clients slow down. Small writes cost the drive more than their bytes: on the fitted EC2 drives at full fill, random 4 KiB writes settled about 14% below 8 MiB writes and 64 KiB about 6%. The model's flash translation layer gives part of that, and a cost per byte written that falls with the length of the contiguous run each write extends gives the rest; it charges nothing for the part of a contiguous run beyond about 165 KiB, and no size between 128 KiB and 8 MiB was measured.

In the browser the drive, cache and rates are divided by a scale factor of 32 so the simulation fits in memory; sizes are not, and every rate and byte count shown is multiplied back to the real system.

Load on a trace

The trace presets send their requests in trace order at an even rate, without their recorded times, so the load does not follow the trace's day. Each design's rate is set so that its bottleneck, the busiest of the drive's time, the host read and write caps, the CPU and the filesystem locks, is busy for a target share of the time on average (70% unless set). The rate is cut back when the requests owed exceed 10 minutes at the target rate and have grown since the last half-hour. Each half-hour, the designs that replay the same trace (for the Copilot presets, at the same share of sessions and days) all take the lowest of those rates, so they send the trace's requests in the same order at the same rate, and the comparison is between designs under one load. A design with "Leave deletes out" sends the same requests without the deletes, at the same rate, so it moves through the trace ahead of the others by the deletes' share; one with "Each set writes a new key" sends them to new keys.

"Held at" is the mean target rate over the last quarter of the run, and "Could hold" each design's own rate over the same quarter. The load can instead be set for each design at its own rate, or held at a set rate. A design that sends the requests faster than the trace's own rate (for the Copilot presets, at their share of sessions) reaches the end sooner, and the trace then starts over, so the run lasts its length.

GitHub Copilot presets

These replay the GitHub Copilot Coding Agent Traces 2026: a week of coding agent sessions, with each call's time, model and token counts (sources and changes: Licences). The trace has no content and no block hashes, so a call's cached prefix is built from the counts: either the previous call's prompt and completion, as if prompts only grow, or no more than what the provider reported cached. The served file names no models; the KV bytes per token are the chosen open-weight model's, from its published config.

The week's days are overlaid, so a session also runs, as one of its own, at its time of day on the other days. The served copy holds one session in ten of the dataset; a quarter of its sessions are replayed, and at that share the calls average 0.37 a second over the week, so a design that holds about that rate covers about a day of the trace per day of drive time. Each pass after the first replays its sessions as sessions of their own with their own blocks; on models with little KV per token a 48-hour run can pass through the week several times. The calls can also be sent at their recorded times, with the load set by admitting new sessions; sessions run for hours, so the load then trails the target, about one half-hour in three is saturated, and the replay can fall from minutes to hours behind.

Blocks are 256 tokens unless set otherwise, and each block is one item. The block size is part of the design: at 3,200 B per token, 256-token blocks put about 3.4 million files on the drive for file per object against about 0.8 million at 1,280, with very different write amplification. In the browser each block holds 1/32 of its KV, so the scaled drive replays whole sessions; what is fixed per item or per command, such as 4 KiB alignment, does not shrink with the block, which counts most for models with little KV per token. The drive's extent cost is charged at the block's full size.

Meta key-value preset

This replays day 1 of the 202401 key-value cache traces Meta published with CacheLib (sources and changes: Licences), from a cluster whose hosts each cache in about 42 GB of DRAM and 930 GB of SSD. The browser's copy holds the requests to one key in 32, and a read that misses writes nothing unless misses are written back. The trace's own values average about 1 KB, too little to load a drive, so every value is set to 256 KiB, which makes the trace's keys 1.4 times what the default drive's cache holds. In 48-hour runs of each engine preset on its own, from 4,183 to 8,877 requests per second, the hit rate was 89% to 92%.

Two options change how the trace's writes reach the cache. "Each set writes a new key" gives every set a key of its own and sends later requests for that key to it, so an overwrite leaves the old value cached, unread, until it is evicted, in every layout. "Leave deletes out" drops the trace's deletes.

Memory in the browser

Every design runs in your browser, in a worker of its own, and its memory grows with what the simulated drive holds: a larger drive and smaller values or blocks take more. Where the browser allows, each design keeps part of its simulated drive's map, 4 bytes per 4 KiB of the scaled drive's flash, spare area included, in a temporary file in the site's private browser storage, removed when the run ends, or the next time the site is opened if the page closed first.

The page does not start a comparison if it estimates one design needs more than 2.6 GB, or all of them more than the device allows (1.2 GB on a phone or tablet, 6 GB otherwise). It stops a design, keeping its results so far, whose memory grows past 2.6 GB anyway, and stops all of them if together they hold more than the device allows or their memory grows past 1.5 GB on a phone or tablet or 8 GB otherwise. The estimate is the most that measured designs of the same layout and object count held, most of them at an unlimited request rate; a design can hold more, and the page then stops it.

What it is checked against

Each layer is checked against measurements on a reference drive. The drive model matches fio and a segment cache there; file per object on XFS matches the step in throughput but writes more after it than measured; the ext4 profile does not reproduce its measured allocator ageing. The latency figures are estimates from queue depth, not measured distributions.