the first part of this series proposed arbor, an operating system rebuilt from the bottom up for ai agents and the people who work with them. before building any of it, i wanted to know where the memory and the time really go on a computer that agents already use every day. so i measured mine: its memory and its disk, how long it takes to start and to find a file, and 201 sessions in which my coding agents made 47,700 calls to a model. the numbers say what arbor should build first, what it should take out, and what it should refuse to do even where refusing looks slower.

measured on one computer, mine, on 16 october 2026. every other number comes from the source named beside it, and the few estimates say so

where the waste is

the operating system is not where most of the memory, the time or the money goes. the agents and the software around them are.

five measurements shaped everything that follows.

• tokens. three quarters of what my agents' calls would cost goes on reading again what the model has already read. an average step costs as much as reading 42,000 new tokens, while the median result a tool adds to it is 209 tokens long.
• memory. it goes to the agents' runtimes and to the apps around them. at one reading, six agent sessions, the desktop app that runs them and a browser they were driving held almost 5 GiB between them, and the machine had pushed 9.6 GiB out to swap.
• disk. a third of my projects folder, 22.9 GiB of 70.5 GiB, is files identical, byte for byte, to other files in it.
• starting. the computer takes 25.2 seconds to start, and 11.3 of them pass before linux is even loaded.
• searching. finding a file by name means walking 2.2 million entries, which takes 1.4 seconds with every one of them already in memory. an index answers in a third of a millisecond.

most of the bill is rereading

an agent's model reads its whole conversation again at every step. a cache makes that cheap, and on my computer it is still three quarters of the cost.

an agent works in steps. at each one the model reads everything so far, its instructions, the descriptions of the tools it may use, the conversation and the output of every command, and then writes a little more: a thought, a command, an edit. the next step reads all of that again, along with whatever the command printed. providers keep what a model read at the last step in a cache, and charge a tenth of the usual price to read it again (anthropic, prompt caching). my agents found 98.7% of what they read in that cache, which cut what their calls would cost by 87%.¹ what is left is still mostly rereading:

so the cheapest token is one that is never read, and arbor's first changes are about reading less, not writing less.

a shorter opening

my sessions opened with a median of 70,000 tokens before the first word of the task: instructions, and a description of every tool the agent might call. that opening is read again at every step, and it makes up 23% of everything my agents reread, about a sixth of the whole bill. anthropic measured the other side of it: when agents searched for the tools they needed instead of loading all of them, the descriptions shrank from 77,000 tokens to 8,700, and accuracy in their tests of tool use rose from 49% to 74% (anthropic, advanced tool use). in arbor every service describes itself, and an agent asks for the descriptions it needs when it needs them.

fewer steps

16% of my agents' steps did nothing but read, straight after another step that did nothing but read, and they cost 13% of the bill. each could have been folded into the step before it. in arbor one step can ask for many things at once, and a short script can call tools in a loop without a trip back to the model each time. anthropic reports 37% fewer tokens for the same work when the model writes such a script (anthropic, advanced tool use), and an example in which 150,000 tokens of tool results passed through the model needed 2,000 once code handled them (anthropic, code execution).

forgetting what is stale

a long session fills up with the output of commands run an hour before. dropping old tool results while keeping the recent ones cut tokens by 84% in anthropic's tests, and raised the score on the task by 29% (anthropic, managing context). researchers at jetbrains found that simply masking old observations halved what an agent cost, at about the same rate of solved problems (lindenbauer and others 2025). in arbor every result stays in the ledger, and the model sees the recent ones.

shorter results

what the model does read should be shorter. tools print for people: columns lined up, decoration, and every field they have. i printed the same listing of 100 files in eight ways, and counted the tokens:

the format matters less than asking only for what is needed. git log printed 18,928 tokens for the last 20 changes in one of my projects, and 530 with one line for each. ps aux printed 9,900 tokens for the 30 largest processes, and 286 when asked for their ids, memory and names alone. the authors of toon measured 42.6% fewer tokens than json, with slightly higher accuracy (toon). code is the exception: wrapped in json, it scored at or below plain text for every model aider tested (gauthier 2024). so in arbor a result is a typed object, printed as a table of the fields the agent asked for, and code stays plain text.

pictures last

a screenshot is the most expensive way to look. my agents took 3,461 of them, about 2.9 to 3.9 million tokens of reading, and one screenshot of a 1080p screen costs 1,560 tokens once it is scaled down, or 2,691 for a model that reads it at full size (anthropic, vision). in arbor an app says what is on its screen as data, and a screenshot is for checking how something looks.

a cache the system keeps

the cache becomes part of the system. arbor puts the parts of a prompt that never change first, in the same order for every agent, and keeps timestamps and other details that change out of them, so that a provider's cache, or a local model's, can use them again. a cached prompt of 100,000 tokens began its answer in 2.4 seconds instead of 11.5 (anthropic 2024).

the right model for the step

not every step needs the largest model, thinking for as long as it can. at medium effort, opus 4.5 matched sonnet 4.5's best score on a coding benchmark with 76% fewer output tokens (anthropic, opus 4.5), and a cascade that tries a small model first, and a large one only when the answer fails a check, cost 59 to 98% less at the same accuracy in one study (chen and others 2023). arbor's verifiers are what make the cascade safe: a cheap answer that passes its check is a finished answer.

two ideas turned out to be worth little here. my agents rarely read the same unchanged part of a file twice, 2% of their reads, and only 1.8% of their tool calls failed, so there is little to gain from avoiding retries.

memory goes to runtimes

the system takes little memory. the agents and the apps around them take gigabytes, and an agent's share holds text that would fit in a megabyte.

at one reading that day, with six sessions of my coding agent open, memory was spent like this: the six sessions held 1,568 MiB, the desktop app i run them from 1,354 MiB, a browser the agents were driving 2,054 MiB, and the whole gnome desktop 513 MiB. the machine had pushed 9.6 GiB out to swap, 6 of them to disk, and had 0.9 GiB left. a second reading that evening, with no browser open, found about half as much in swap. how much each part takes changes by the hour, but the desktop came last both times.

each session held 250 to 334 MiB to keep a conversation whose text, at the median of 266,000 tokens, comes to about a megabyte. the rest is the runtime around it: a javascript engine, its heap and its libraries. even doing nothing, runtimes differ a great deal:

arbor runs one native agent service, and each agent is a handle inside it rather than a process of its own: a conversation, its keys and its budget, in a few mebibytes rather than hundreds. that is an estimate, and one of the first things the prototype has to prove.

when memory runs short, this computer writes pages to an 8 GiB file on disk, beside 4 GiB of swap kept compressed in memory, called zram. memory compresses well: zram held twice its size in pages here, and the heap of an agent compressed 2.15 times with zstd. arbor swaps to compressed memory only, never to disk, and compresses pages that have gone cold before memory runs short, not after. meta does this across its fleet, and saved 20 to 32% of its memory without a noticeable slowdown (meta 2022).

the apps are the other half. a desktop app built on a browser engine, a separate browser for the agents and the gnome desktop each bring an engine of their own, and gnome's shell used 2.1% of a core to show a screen on which nothing moved. moving such an app to the system's own web view saves only 11 to 31% of its memory in tauri's benchmarks (tauri), so the gain has to come from having fewer engines. in arbor the compositor draws the system's own screens, and one shared web engine draws only web pages. video and still layers go straight to the display's hardware planes, which cut the power of playing a video by 7 to 14% in kde's compositor (hugl 2025).

two things linux already does here stay as they are: its newer way of choosing which pages to reclaim, the multi-generational lru (zhao 2022), and huge pages given only to the programs that ask for them.

a sandbox in a millisecond

every command an agent runs should run in a sandbox of its own. that is only practical if a sandbox costs almost nothing to start.

in arbor, work happens in cells: sandboxes that see only the world and the keys they were given, as part one describes. the usual sandbox today is a docker container, which takes 125 milliseconds to start here, too slow to give one to every command. the kernel features docker is built from are far faster on their own:

an empty sandbox is rarely what an agent needs. it needs python with its libraries loaded, or node, or a compiler, and loading them is the slow part. that can be done once: arbor keeps a warm template of each kind of cell and forks it, the way unix copies a process, so the copy shares the template's memory until it changes something.

a study of containers for short tasks found the same shape: a container stripped of what slowed it started 18 times faster than docker, and templates made it 3 times faster again (oakes and others 2018).

code the agent did not write, or downloaded, deserves a stronger wall than namespaces, which all share one kernel. two kinds of cell give it one cheaply. webassembly runs code in a sandbox that its compiler enforces: faasm started such a cell in 0.5 milliseconds where docker took 2.8 seconds, in 90 KB of memory instead of 1.3 MB (shillaker and pietzuch 2020), and wasmtime makes a new instance in 5 microseconds instead of 2 milliseconds, by mapping a prepared image of its memory (fallin 2022). whole programs get a micro virtual machine: firecracker's monitor needs 3 MB of memory where qemu's needs 131 (agache and others 2020), a snapshot of one is restored in 4 to 10 milliseconds (brooker 2022), and alibaba runs such sandboxes in under 20 MB each by sharing their read-only images (li and others 2022).

copies that cost nothing

agents work best on their own copy of everything, and today a copy costs time and disk. it does not have to.

a third of my projects folder, 22.9 GiB of 70.5 GiB, is files identical to others in it: 6.8 GiB in the separate checkouts my agents work in, 7.2 GiB in build outputs, and the rest elsewhere. arbor stores every piece of content once, under a fingerprint of what it holds, and every world that contains it points to that one copy. doing this for whole files alone gets about three quarters of what finer-grained deduplication saves (meyer and bolosky 2011), so arbor starts there.

the larger gain is time. today an agent gets its own copy of a project with git worktree, which took 79 milliseconds here for a checkout of 19 MB. that checkout then had to rebuild 1,774 steps, because build outputs are not part of it. a copy-on-write snapshot copies nothing until something changes: one of my projects, 28 GiB with all its build outputs, forked in 3 to 4 milliseconds, and the system call that does it took 27 microseconds of that, the rest going to start the program that makes the call. worlds can be fetched lazily too, which matters: when containers start, pulling their images takes 76% of the time, yet only 6.4% of the data pulled is ever read (harter and others 2016).

finding without looking

searching by walking the disk is a habit from when disks were small. an index kept current as things change answers thousands of times faster.

agents search all the time: for a file by its name, for a word in the code, for the one function they need in a long file. today each search walks the disk. my home folder holds 2.2 million files and folders, and find takes 1.4 seconds to look for a name among them, with all of them already in memory. arbor keeps a live catalog of every object instead, updated by the store itself after each write, so it needs no crawler, no nightly updatedb and no watches on folders.

the catalog costs 90 bytes an object, 191 MiB for my 2.2 million, and 2 microseconds to update when something changes. it is updated just after a write, from the store's log of changes, and never inside one: the be file system kept its indexes current inside every write, and paid for it in speed on work heavy in metadata (giampaolo 1999). the idea works at scale already. plocate finds a name among 27 million files in 8 milliseconds where the older locate took 20 seconds (gunderson), and git, told what changed by a monitor of the file system, answered git status in 0.75 seconds instead of 85 on a large repository (hostetler 2022).

words in code need another kind of index, of trigrams: every sequence of three characters, with the files that contain it. it can answer even a regular expression, by narrowing the files to read before reading any (cox 2012). mine was quick to build with sqlite, and it is three times the size of the code it covers. google's code search kept its index to a fifth of the code (cox 2012), so there is room to do better.

long files are where agents waste the most reading. in 40 of my largest source files, 40,000 tokens each at the median, an outline of a file's types and functions is 4% of the file, and the outline with the two functions an agent wants is 8%. arbor stores code as objects that know their own structure, so an agent asks for the outline first, and then for functions by name.

searching by meaning needs an index of vectors, and that is fast too: faiss finds the nearest among a million vectors in 0.02 milliseconds, the true nearest 95% of the time (faiss), and diskann searches a billion on one machine with 64 GB of memory in under 3 milliseconds (subramanya and others 2019). arbor builds it in the background, away from the path of a write. small objects, by the million, are packed into large files with an index in memory, as facebook did with photos: one read from disk for each instead of about three, and 10 bytes of memory for each where a file system spent 536 on an inode (beaver and others 2010).

twenty-five seconds to start

nearly half the time my computer takes to start passes before linux is even loaded.

the firmware is the board maker's, and the fastest way past it is not to go through it. arbor resumes instead of starting: for daily use it sleeps in suspend-to-idle, which wakes without the firmware, and it moves into a new kernel with kexec, which starts the new kernel from the running one and skips the 13.0 seconds of firmware and boot loader. even the older kind of sleep spends little time in firmware: on a machine intel measured, it took 340 of the 2,087 milliseconds of a resume (brown 2015).

where a board accepts other firmware, firmware that starts only what the system uses is far faster. a coreboot laptop reached the kernel 1.1 seconds after power-on (menzel 2023), and a server whose firmware took eight minutes to start it took 20 seconds with linux in its place (edge 2017).

the image the kernel starts from, the initramfs, holds the drivers and tools needed to reach the real system. ubuntu builds it to start any pc, so on mine it is 90.7 MB, and most of it is for other computers:

arbor builds one kernel for the machine it runs on, with that machine's storage and file-system drivers built in and everything else loaded when it is needed. then there is no generic image to unpack and no boot menu: the firmware starts the kernel directly.

the last 5.7 seconds are linux starting its programs. the boot splash alone holds the desktop back by 2.04 seconds while it waits to finish, and jobs that could wait run during the start: ubuntu pro's timer for 3.9 seconds, the daily upgrade for 1.4, snap for 1.6, a check for new firmware for 0.5 and the manual's index for 0.3. in arbor the first screen starts first, and everything else waits its turn as background work.

three things that speed a start up are already done here, so nothing is left to gain from them: a kernel and image compressed with zstd, the processor's cores started in parallel, and a quiet start with no messages. with this board's firmware, i estimate arbor would start in about 13 seconds, nearly nine tenths of them in firmware, and with firmware like coreboot's in about 2.5. both estimates take the kernel at about a second, as on the coreboot laptop, and the first screen at half a second.

more from the same chips

the same processor runs the same code faster when the code is laid out for how it really runs.

compilers guess which paths through a program are common. a profile-guided build measures them instead, and lays the code out to match. facebook's bolt, applied after profile-guided and link-time optimization, made data-center services up to 8.0% faster and the gcc and clang compilers up to 20.4% faster (panchenko and others 2018). the same kind of profile, as google applies it, made the linux kernel up to 5% faster on large benchmarks (xu and shen 2024). arbor ships its kernel and its busiest services built this way.

memory can be laid out better too. google's temeraire, a memory allocator built around huge pages, raised the requests its services answered each second by 7.7% and cut their memory by 2.4% (hunter and others 2021), and handing programs memory in pieces of 64 KB rather than 4 KB cut the time of a kernel build by 5% (roberts 2023).

so can calls into the kernel. flexsc let programs queue their system calls without stopping to enter the kernel for each one, and made apache up to 116% faster and mysql up to 40% (soares and stumm 2010). linux's version of the idea is io_uring, and arbor uses it in its own store, catalog and outbox. never from inside a cell, though: 60% of the kernel exploits submitted to google's reward program went through io_uring, and google turned it off on its production servers (google 2023).

two more are smaller. drives that only ever write forward, zoned drives, sustained 1,010 MiB/s of writes where ordinary drives managed 370 to 590 MiB/s, and wrote each byte about once instead of two or more times (bjørling and others 2021). arbor wants them once it has hardware of its own. and building every package for the newer instructions this processor has gains about 1% for most of them (canonical 2025), not yet worth a second set of packages.

the same work on less power

a computer that waits should cost almost nothing. most of the saving comes from waking less, and from doing background work where it is cheapest.

nothing in arbor polls. the kernel stops its clock on idle cores, as linux already can, and without that a battery drains two to three times as fast (the kernel's documentation). services wake on events, never on a timer that asks whether anything happened, and the timers that remain are gathered by class, so that a hundred small wakeups become one. apple found that gathering timers cut a laptop's idle processor activity by 72% (cohen 2013).

background work becomes a class of its own: indexing, syncing and compacting the ledger run in batches, on the efficient cores. microsoft's ecoqos, which does this on windows, cut the processor's power by up to 90% for such work (li 2021), and android's doze, which holds such work back while a phone's screen is off, made phones last 30% longer with the screen off (sd times 2015).

each cell gets an energy preference too. this computer runs every core at the preference called performance, all the time. intel measured that its setting for saving power cut the power of playing a video by 52% on its laptop processors (wysocki 2024). choosing between big and little cores by energy used 8 to 27% less energy, for work that took 0.7 to 2.4% longer (perret 2018), and lavd, a scheduler written for valve's steam deck, used 16% less energy than linux's default in one of two game benchmarks, and the same in the other (min 2024).

a screen on which nothing changes should cost nothing to draw. gnome's shell here used 2.1% of a core to show one. panels that drop their refresh rate when nothing moves used 22% less power in samsung's phones, and 60% less for a still image shown at 10 Hz (samsung 2020), and a browser tab put to sleep used 37% less processor time and 32% less memory (microsoft edge team 2020).

devices sleep too, when they are allowed to. keeping the power saving that the firmware had turned on for the links to expansion cards, instead of switching it off everywhere, saved about 5 W on an idle laptop (garrett 2011); nvme drives that power themselves down saved nearly 1 W (lutomirski 2016); and sata links that sleep saved 0.5 to 3 W across 15 laptops (fedora 2018). arbor turns them on, with the settings known to be safe.

the rest is a matter of using the right part of the machine. a graphics chip's fixed-function decoder plays video on 4.4 to 8.9% of the energy the best software decoders use (kränzler and others 2024). if arbor runs models on the machine itself, batching their requests saves the most: 12.5 times less energy for each request, and up to 100 times with arrivals spaced to fill each batch (delavande and others 2026), and a phone's neural processor read prompts on 1.85 to 4.3 times less energy than its graphics processor (xu and others 2024). on a battery, or a phone network, background traffic waits to travel in batches, for 35 to 52% less energy spent on the network (balasubramanian and others 2009).

a connection is paid for once

agent traffic is many small calls to a few services. the gain is in not setting up the same connection twice.

here, a call to the model's api took 185 milliseconds, 12 of them spent setting up a new connection. arbor's outbox, through which every request leaves, keeps one pool of open connections for all its cells, so that a cell borrows one instead of opening its own. cloudflare's proxy, doing the same, raised the share of requests that reused a connection from 87.1% to 99.92%, opened 160 times fewer, and delivered its slowest 5% of first bytes 80 milliseconds sooner (cloudflare 2022).

a connection that must be new costs less when it can resume an earlier session with tls 1.3: setting connections up took 190.1 milliseconds instead of 237.9 over a path 50 milliseconds long, and the client's cryptography 2.38 milliseconds instead of 9.22 (sy and others 2019). a cache of names in the outbox saves 2.5 to 34 milliseconds a lookup, or 24 to 156 when the resolver itself has to ask (al-dalky and rabinovich 2020). and large transfers need large windows: a window of 3 MB holds a path 100 milliseconds long to 240 megabits a second, whatever the line could carry.

http/3 and bbr help only on lossy or long paths: over quic, google search answered its slowest 1% of queries 14 to 17% sooner (langley and others 2017). techniques built for datacenters, such as bypassing the kernel or never copying data, change nothing at the rates agents send.

what arbor takes out

some of today's costs need no clever replacement. they only need to go.

• the generic boot image: 90.7 MB, with 1,047 of its 1,099 modules never used here. on the drive, 172 MiB of modules in 6,903 files, of which 187 are loaded.
• the boot splash, and the 2.04 seconds it holds the desktop back.
• jobs at boot, from ubuntu pro's timer to the manual's index: moved to the background class.
• snap: 1.6 seconds at boot, and 14 mounted images.
• crawlers, updatedb and the file indexers: replaced by the store's log of changes.
• swap on disk: an 8 GiB file, 6 of them in use at one reading.
• docker for cells: 125 milliseconds a start, against 1.28 for namespaces.
• a runtime process for each agent: 250 to 334 MiB each.
• a browser engine in every app, and the gnome stack: 64 processes and 513 MiB, which take 2.1% of a core to show a still screen.
• output written for people as the agents' default, and every tool described up front: an 18,928-token git log, and a 70,000-token opening.

what arbor refuses

some optimizations buy speed with safety, or with the quality of the work. arbor turns them down, for these reasons.

switching off the processor's defences against side channels

there is no real gain on current processors: on amd's zen 5, none across more than 140 benchmarks (larabel 2024), and the attacks come back. this processor is not affected by meltdown, and its defence against spectre v2 is in its hardware.

lowering the voltage, or letting software reach it

plundervolt broke intel's sgx this way, and clkscrew broke arm's trustzone (murdock and others 2020; tang and others 2017).

merging identical pages of memory between agents

only 2% of the pages that were not empty were identical across four agents here. the thread that finds them can take 60% of a core (edge 2023), and flip feng shui used such merging to break cryptographic keys (razavi and others 2016).

huge pages for everything

pages of 2 MB swell what programs hold in memory, so arbor gives them to the programs that ask (the kernel's documentation on huge pages).

a kernel in user space for cells

under gvisor, opening and closing a file was 216 times slower, and simple system calls at least 2.2 times (young and others 2019).

compressing prompts by dropping words

on a set of reasoning tasks, prompts made five times shorter lost 8.5 points, and seven times shorter 13.2 (jiang and others 2023).

answering from a cache of similar questions

similar is not the same, and wrong hits degrade the work (zhang and others 2025). arbor's caches are keyed by the exact fingerprint of what was asked.

sending out many agents with nothing to check them

systems of many agents used about 15 times the tokens of a chat (anthropic, multi-agent research). arbor fans out only when a verifier will choose among the results.

leaning on long contexts

at 32,000 tokens, 11 of 13 models fell below half of their score on short ones (modarressi and others 2025).

8-bit weights from bitsandbytes, to save energy

while writing, they used two to three times the energy of full precision (delavande and others 2026).

sending model calls as early data

the early data of tls 1.3 can be replayed by an attacker (rescorla 2018), and a call that spends money must happen once.

quic everywhere

on fast links it lost up to 45% of the throughput (zhang and others 2024).

bbr's first version everywhere

in deep buffers it crowds out the connections that use cubic (ware 2020).

indexing inside every write

it slows the writes themselves (giampaolo 1999), so arbor indexes just after them.

the ten to build first

all ten can be built on linux, in arbor's first step, and they are in order of what they save on my computer.

how this was measured

one computer, one day, and a set of scripts that can take every number again.

every number i call mine was taken on the computer described at the top, on 16 october 2026, by a suite of small scripts. it needs no administrator's rights, only reads what it measures, keeps its temporary files in memory, and runs in a little over two minutes. memory is the resident set of each process, from linux's own accounts in /proc, and where processes share pages, their proportional set. times are medians of repeated runs, with the files already in memory except where the text says otherwise. the start is as systemd-analyze reported the boot the measurements ran in, and the boot image was unpacked and compared with the modules the running kernel had loaded. copies on disk were found by hashing every file in the projects folder.

tokens come from two places. what calls cost comes from the usage the api reports with every call, which each session's transcript keeps: tokens read from the cache, written to it, read new, and written by the model. those are exact. counts of text, for formats and for tool results, use the o200k tokenizer, because claude's is not public.

i ran the whole suite a second time that evening, while another job kept the processor busy, at a load average of 11. of the 149 numbers it could compare, 115 came within 15% of the first run. most of the other 34 were start-up times that slowed under the load, and readings of memory that depend on what is open at the moment. code search was faster the second time, because during the first, part of the code had been pushed out of memory. none failed.

every other number comes from the source cited beside it. the list below marks the makers writing about their own products, the preprints nobody has reviewed yet, and the measurements anyone can run again. the estimates say so where they appear.

notes

1. at the api's list prices, as if every call had been billed by the token: a read from the cache at a tenth of the price of new input, a write to the cache at 1.25 times, and the model's output at 5 times. how the calls were actually paid for does not change the shares.
2. o200k is the tokenizer of openai's recent models. claude splits text into tokens its own way, so a count here is not what claude would bill. it is a fair way to compare one format with another, since the same tokenizer counted them all.

references

1. Anthropic. Prompt caching. Claude Developer Platform documentation, read in October 2026. platform.claude.com/docs/en/build-with-claude/prompt-caching
2. Anthropic (2025). Introducing advanced tool use on the Claude Developer Platform. Anthropic Engineering, 24 November 2025. anthropic.com/engineering/advanced-tool-use
3. Anthropic (2025). Code execution with MCP: building more efficient AI agents. Anthropic Engineering, 4 November 2025. anthropic.com/engineering/code-execution-with-mcp
4. Anthropic (2025). Managing context on the Claude Developer Platform. 29 September 2025. claude.com/blog/context-management
5. Lindenbauer, T., Slinko, I., Felder, L., Bogomolov, E. & Zharov, Y. (2025). The Complexity Trap: Simple Observation Masking Is as Efficient as LLM Summarization for Agent Context Management. arXiv:2508.21433. doi.org/10.48550/arXiv.2508.21433
6. TOON contributors. TOON: Token-Oriented Object Notation, with the benchmarks in its readme, read in October 2026. github.com/toon-format/toon
7. Gauthier, P. (2024). LLMs are bad at returning code in JSON. aider, 14 August 2024. aider.chat/2024/08/14/code-in-json.html
8. Anthropic. Vision. Claude Developer Platform documentation, read in October 2026. platform.claude.com/docs/en/build-with-claude/vision
9. Anthropic (2024). Prompt caching with Claude. 14 August 2024. claude.com/blog/prompt-caching
10. Anthropic (2025). Introducing Claude Opus 4.5. 24 November 2025. anthropic.com/news/claude-opus-4-5
11. Chen, L., Zaharia, M. & Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176. doi.org/10.48550/arXiv.2305.05176
12. Pereira, R., Couto, M., Ribeiro, F., Rua, R., Cunha, J., Fernandes, J. P. & Saraiva, J. (2017). Energy Efficiency across Programming Languages: How Do Energy, Time, and Memory Relate? 10th ACM SIGPLAN International Conference on Software Language Engineering (SLE '17), 256–267. greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
13. Meta (2022). Transparent memory offloading: more memory at a fraction of the cost and power. Engineering at Meta, 20 June 2022. engineering.fb.com/2022/06/20/data-infrastructure
14. Tauri. Benchmark results. github.com/tauri-apps/benchmark_results
15. Hugl, X. (2025). More KMS offloading, with overlay planes. 23 October 2025. zamundaaa.github.io/wayland/2025/10/23/more-kms-offloading.html
16. Zhao, Y. (2022). Multi-Gen LRU Framework. Patch series for the Linux kernel, as posted on LWN.net. lwn.net/Articles/908512
17. Oakes, E., Yang, L., Zhou, D., Houck, K., Harter, T., Arpaci-Dusseau, A. C. & Arpaci-Dusseau, R. H. (2018). SOCK: Rapid Task Provisioning with Serverless-Optimized Containers. 2018 USENIX Annual Technical Conference (USENIX ATC '18), 57–70. usenix.org/conference/atc18/presentation/oakes
18. Shillaker, S. & Pietzuch, P. (2020). Faasm: Lightweight Isolation for Efficient Stateful Serverless Computing. 2020 USENIX Annual Technical Conference (USENIX ATC '20), 419–433. doi.org/10.48550/arXiv.2002.09344
19. Fallin, C. (2022). Wasmtime 1.0: A Look at Performance. Bytecode Alliance blog, 6 September 2022. bytecodealliance.org/articles/wasmtime-10-performance
20. Agache, A., Brooker, M., Florescu, A., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P. & Popa, D.-M. (2020). Firecracker: Lightweight Virtualization for Serverless Applications. 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI '20), 419–434. usenix.org/conference/nsdi20/presentation/agache
21. Brooker, M. (2022). Lambda Snapstart, and snapshots as a tool for system builders. Marc's Blog, 29 November 2022. brooker.co.za/blog/2022/11/29/snapstart.html
22. Li, Z., Cheng, J., Chen, Q., Guan, E., Bian, Z., Tao, Y., Zha, B., Wang, Q., Han, W. & Guo, M. (2022). RunD: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing. 2022 USENIX Annual Technical Conference (USENIX ATC '22). usenix.org/conference/atc22/presentation/li-zijun-rund
23. Meyer, D. T. & Bolosky, W. J. (2011). A Study of Practical Deduplication. 9th USENIX Conference on File and Storage Technologies (FAST '11). usenix.org/legacy/event/fast11/tech/full_papers/Meyer.pdf
24. Harter, T., Salmon, B., Liu, R., Arpaci-Dusseau, A. C. & Arpaci-Dusseau, R. H. (2016). Slacker: Fast Distribution with Lazy Docker Containers. 14th USENIX Conference on File and Storage Technologies (FAST '16), 181–195. usenix.org/system/files/conference/fast16/fast16-papers-harter.pdf
25. Giampaolo, D. (1999). Practical File System Design with the Be File System. Morgan Kaufmann.
26. Gunderson, S. H. plocate, a much faster locate. plocate.sesse.net
27. Hostetler, J. (2022). Improve Git monorepo performance with a file system monitor. The GitHub Blog, 29 June 2022. github.blog/engineering/infrastructure
28. Cox, R. (2012). Regular Expression Matching with a Trigram Index, or How Google Code Search Worked. January 2012. swtch.com/~rsc/regexp/regexp4.html
29. Faiss. Indexing 1M vectors. Faiss wiki. github.com/facebookresearch/faiss/wiki/Indexing-1M-vectors
30. Subramanya, S. J., Devvrit, Kadekodi, R., Krishnaswamy, R. & Simhadri, H. V. (2019). DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node. Advances in Neural Information Processing Systems 32 (NeurIPS 2019). proceedings.neurips.cc
31. Beaver, D., Kumar, S., Li, H. C., Sobel, J. & Vajgel, P. (2010). Finding a needle in Haystack: Facebook's photo storage. 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI '10). usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf
32. Brown, L. (2015). Linux Suspend at Speed of Light. LinuxCon Europe 2015. events.static.linuxfound.org
33. Menzel, P. (2023). Boot time delays and issues on Dell Latitude 5430 Chromebook. linux-kernel mailing list, October 2023. lkml.iu.edu/hypermail/linux/kernel/2310.0/00408.html
34. Edge, J. (2017). Replacing x86 firmware with Linux and Go. LWN.net, 20 November 2017. lwn.net/Articles/738649
35. Panchenko, M., Auler, R., Nell, B. & Ottoni, G. (2018). BOLT: A Practical Binary Optimizer for Data Centers and Beyond. arXiv:1807.06735, later published at CGO 2019. doi.org/10.48550/arXiv.1807.06735
36. Xu, R. & Shen, H. (2024). [PATCH v7 0/7] Add AutoFDO and Propeller support for Clang build. linux-kernel mailing list, November 2024. lkml.iu.edu/hypermail/linux/kernel/2411.0/01852.html
37. Hunter, A. H., Kennelly, C., Turner, P., Gove, D., Moseley, T. & Ranganathan, P. (2021). Beyond malloc efficiency to fleet efficiency: a hugepage-aware memory allocator. 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI '21), 257–273. usenix.org/system/files/osdi21-hunter.pdf
38. Roberts, R. (2023). [PATCH v4 0/5] variable-order, large folios for anonymous memory. linux-kernel mailing list, July 2023. lkml.iu.edu/hypermail/linux/kernel/2307.3/04006.html
39. Soares, L. & Stumm, M. (2010). FlexSC: Flexible System Call Scheduling with Exception-Less System Calls. 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI '10). usenix.org/legacy/events/osdi10/tech/full_papers/Soares.pdf
40. Google (2023). Learnings from kCTF VRP's 42 Linux kernel exploits submissions. Google Security Blog, June 2023. security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
41. Bjørling, M., Aghayev, A., Holmberg, H., Ramesh, A., Le Moal, D., Ganger, G. R. & Amvrosiadis, G. (2021). ZNS: Avoiding the Block Interface Tax for Flash-based SSDs. 2021 USENIX Annual Technical Conference (USENIX ATC '21). usenix.org/conference/atc21/presentation/bjorling
42. Canonical (2025). Introducing architecture variants: amd64v3 now available in Ubuntu 25.10. Ubuntu Discourse, 30 October 2025. discourse.ubuntu.com/t/71312
43. The Linux kernel documentation. NO_HZ: Reducing Scheduling-Clock Ticks. docs.kernel.org/timers/no_hz.html
44. Cohen, P. (2013). Mavericks Preview: Timer Coalescing boosts Mac laptop battery life. iMore, 17 July 2013. imore.com/mavericks-preview-timer-coalescing
45. Li, R. (2021). Introducing EcoQoS. Microsoft Developer Blogs, 21 April 2021. devblogs.microsoft.com/performance-diagnostics/introducing-ecoqos
46. SD Times (2015). Android Marshmallow arrives. 6 October 2015. sdtimes.com/android/android-marshmallow-arrives
47. Wysocki, R. J. (2024). Re: [PATCH] cpufreq: intel_pstate: Update Meteor Lake EPPs, quoting Intel's measurements. linux-kernel mailing list, June 2024. lkml.iu.edu/hypermail/linux/kernel/2406.0/08964.html
48. Perret, Q. (2018). [PATCH v10 00/15] Energy Aware Scheduling. linux-kernel mailing list, December 2018. lkml.rescloud.iu.edu/1812.0/00841.html
49. Min, C. (2024). Using sched_ext to improve frame rates on the SteamDeck: Ideas behind the LAVD scheduler. Linux Plumbers Conference 2024, 18 September 2024. lpc.events/event/18/contributions/1713
50. Samsung Newsroom (2020). Samsung Display Commercializes New, Variable Refresh Rate Technology for Increasing Smartphone Power Savings. 12 August 2020. news.samsung.com/us
51. Microsoft Edge Team (2020). Sleeping Tabs in Microsoft Edge: Delivering better browser performance. Microsoft Edge Blog, 9 December 2020. blogs.windows.com/msedgedev
52. Garrett, M. (2011). PCI: Rework ASPM disable code. Linux kernel commit of 10 November 2011, in the changelog of Linux 3.2.5. kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.5
53. Lutomirski, A. (2016). [PATCH 3/3] nvme: Enable autonomous power state transitions. linux-nvme mailing list, August 2016. lists.infradead.org/pipermail/linux-nvme/2016-August/006056.html
54. Fedora Project (2018). Changes/ImprovedLaptopBatteryLife, a change for Fedora 28. Fedora Project Wiki. fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
55. Kränzler, M., Herglotz, C. & Kaup, A. (2024). A Comprehensive Review of Software and Hardware Energy Efficiency of Video Decoders. arXiv:2402.09001. doi.org/10.48550/arXiv.2402.09001
56. Delavande, J., Pierrard, R. & Luccioni, S. (2026). Understanding Efficiency: Quantization, Batching, and Serving Strategies in LLM Energy Use. arXiv:2601.22362. doi.org/10.48550/arXiv.2601.22362
57. Xu, D., Zhang, H., Yang, L., Liu, R., Huang, G., Xu, M. & Liu, X. (2024). Fast On-device LLM Inference with NPUs. arXiv:2407.05858. doi.org/10.48550/arXiv.2407.05858
58. Balasubramanian, N., Balasubramanian, A. & Venkataramani, A. (2009). Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications. 9th ACM SIGCOMM Conference on Internet Measurement (IMC '09), 280–293. people.cs.umass.edu/~arun/papers/TailEnder.pdf
59. Cloudflare (2022). How we built Pingora, the proxy that connects Cloudflare to the Internet. The Cloudflare Blog, 14 September 2022. blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet
60. Sy, E., Moennich, M., Mueller, T., Federrath, H. & Fischer, M. (2019). Enhanced Performance for the encrypted Web through TLS Resumption across Hostnames. arXiv:1902.02531. doi.org/10.48550/arXiv.1902.02531
61. Al-Dalky, R. & Rabinovich, M. (2020). Revisiting Comparative Performance of DNS Resolvers in the IPv6 and ECS Era. arXiv:2007.00651. doi.org/10.48550/arXiv.2007.00651
62. Langley, A., Riddoch, A., Wilk, A. et al. (2017). The QUIC Transport Protocol: Design and Internet-Scale Deployment. ACM SIGCOMM 2017, 183–196. research.google.com/pubs/archive/46403.pdf
63. Larabel, M. (2024). AMD Zen 5 Not Affected By Inception/SRSO, mitigations=off Yields No Benefit On Ryzen 9000 Series. Phoronix. phoronix.com/review/amd-zen5-mitigations-off
64. Murdock, K., Oswald, D., Garcia, F. D., Van Bulck, J., Gruss, D. & Piessens, F. (2020). Plundervolt: Software-based Fault Injection Attacks against Intel SGX. 2020 IEEE Symposium on Security and Privacy, 1466–1482. plundervolt.com
65. Tang, A., Sethumadhavan, S. & Stolfo, S. (2017). CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management. 26th USENIX Security Symposium, 1057–1074. usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
66. Edge, J. (2023). An overview of kernel samepage merging (KSM). LWN.net, 29 November 2023. lwn.net/Articles/953141
67. Razavi, K., Gras, B., Bosman, E., Preneel, B., Giuffrida, C. & Bos, H. (2016). Flip Feng Shui: Hammering a Needle in the Software Stack. 25th USENIX Security Symposium, 1–18. usenix.org/conference/usenixsecurity16/technical-sessions/presentation/razavi
68. The Linux kernel documentation. Transparent Hugepage Support. docs.kernel.org/admin-guide/mm/transhuge.html
69. Young, E. G., Zhu, P., Caraza-Harter, T., Arpaci-Dusseau, A. C. & Arpaci-Dusseau, R. H. (2019). The True Cost of Containing: A gVisor Case Study. 11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud '19). usenix.org/system/files/hotcloud19-paper-young.pdf
70. Jiang, H., Wu, Q., Lin, C.-Y., Yang, Y. & Qiu, L. (2023). LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. Conference on Empirical Methods in Natural Language Processing (EMNLP 2023). doi.org/10.48550/arXiv.2310.05736
71. Zhang, Q., Wornow, M., Wan, G. & Olukotun, K. (2025). Agentic Plan Caching: Test-Time Memory for Fast and Cost-Efficient LLM Agents. arXiv:2506.14852. doi.org/10.48550/arXiv.2506.14852
72. Anthropic (2025). How we built our multi-agent research system. Anthropic Engineering, 13 June 2025. anthropic.com/engineering/multi-agent-research-system
73. Modarressi, A., Deilamsalehy, H., Dernoncourt, F., Bui, T., Rossi, R. A., Yoon, S. & Schütze, H. (2025). NoLiMa: Long-Context Evaluation Beyond Literal Matching. 42nd International Conference on Machine Learning (ICML 2025). doi.org/10.48550/arXiv.2502.05167
74. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, section 8. rfc-editor.org/rfc/rfc8446
75. Zhang, X., Jin, S., He, Y., Hassan, A., Mao, Z. M., Qian, F. & Zhang, Z.-L. (2024). QUIC is not Quick Enough over Fast Internet. ACM Web Conference 2024 (WWW '24), 2713–2722. doi.org/10.48550/arXiv.2310.09423
76. Ware, R. (2020). Modelling BBR's interactions with loss-based congestion control. APNIC Blog, 24 January 2020. blog.apnic.net/2020/01/24/modelling-bbrs-interactions-with-loss-based-congestion-control