Why a 960KB binary changes the AI agent deployment story
Most AI agent SDKs are shipped as a package on top of a language runtime. You pip install something, or you npm install something, and at the bottom of that dependency tree there is a Python interpreter or a Node.js runtime measured in the low hundreds of megabytes, with its own set of native modules, its own transitive dependencies, and its own startup cost.
That is the default because, for most of the things an agent SDK does, it does not matter. The agent loop is glue. The expensive part is the call to the model. A few hundred milliseconds of cold start, a few dozen megabytes of resident memory — neither shows up next to a 4-second LLM round trip.
tokenworm’s README quietly bets that this default is wrong for a growing share of cases. The CLI binary is 960KB in ReleaseSmall mode. It cold-starts in 8ms. Idle memory is 2.4MB. There is no Node runtime to bootstrap, no Python interpreter to import, no Docker image to pull. It is a single Zig-compiled executable that you invoke and that exits.
This post is about why that combination — small, fast, no runtime — changes which deployment shapes are tractable, not just which benchmarks look pretty.
What the comparison table actually says
The README publishes a vs-table against Claude Agent SDK and OpenAI Agents SDK. Three rows in that table do most of the work:
| tokenworm | Claude Agent SDK | OpenAI Agents SDK | |
|---|---|---|---|
| Runtime dependency | None | Node.js or Python | Node.js or Python |
| Binary size | 960KB | N/A (~200MB runtime) | N/A (~200MB runtime) |
| Cold start | 8ms | ~500ms (480ms in the perf table) | ~500ms (520ms in the perf table) |
| Idle memory | 2.4MB | ~45MB | ~38MB |
Those numbers come straight from the README’s own benchmarking on an Intel i7-13700K. We are not going to relitigate them here — the point is what they let you do, not whether they are good numbers in isolation.
Cold start matters when you invoke the agent often
A 480ms cold start is fine for an interactive chat session. You start the agent once, you talk to it, you close it. That cold start is a rounding error against the lifetime of the session.
It stops being fine the moment you invoke the agent often. A few concrete cases the README’s deployment story unlocks:
CI runners. A CI job that invokes an agent ten times — once per failing test, say, to suggest a fix — pays the cold-start cost ten times. At 480ms each that is 4.8 seconds of pure startup overhead per job. At 8ms each it is 80ms. Multiply by a thousand jobs per day across an org and the difference is non-trivial wall-clock time and non-trivial compute cost.
Pre-commit hooks. A pre-commit hook that runs an agent to triage a commit message has to be invoked on every commit, by every developer, every time. A 480ms startup hurts every commit; an 8ms startup is below the perception threshold. The hook becomes usable.
LSP integrations. An editor extension that consults an agent on every file save, or every cursor pause, multiplies the cost by the user’s typing speed. Again, 480ms is unworkable and 8ms is invisible.
Many short tasks. Any harness that spawns one agent per task — fan out across a thousand prompts, take the best answer — pays cold start per fan-out. The deployment shape is the difference between hours and minutes.
None of these are exotic. They are the deployment shapes a coding-agent SDK gets asked to support now, by the engineers actually trying to wire one in.
Binary size matters when you ship the agent somewhere
There is a separate question of where the binary has to go.
If your deployment story is “we ship a Docker image”, binary size is mostly an afterthought. The image is already big. Adding a Node runtime is normal. The Python interpreter is normal. Nobody notices.
If your deployment story is “we ship a CLI tool that users brew install”, the size matters. Users notice 200MB downloads. Users complain when the install takes minutes. The npm package for an agent SDK plus its native modules can easily be hundreds of megabytes once everything is resolved.
If your deployment story is “we embed the agent in our existing app”, the math gets sharper still. The README highlights this: libtokenworm.so is an embeddable library. You can link it into a Rust CLI, a Go service, a desktop app, a mobile binary. A 960KB shared library is something you can pull along; a 200MB language runtime is something you architect around.
The README’s “deployment model” row reads “Embeddable library (libtokenworm.so)” vs “Package dependency” for both alternatives. That phrase — package dependency — is the giveaway. The alternatives assume your runtime already has the language. tokenworm assumes nothing about your runtime at all.
The idle-memory ratio
The third number is idle memory. tokenworm reports 2.4MB idle; the alternatives report 38–45MB. That ratio is roughly 15-20x.
Idle memory is the part of the cost that scales with concurrency. If you are running one agent, no one cares. If you are running a hundred concurrent agents on the same host — a fleet of background workers triaging issues, say, or an array of subagents drilling into different parts of a codebase — 45MB per worker times 100 is 4.5GB just to be idle. 2.4MB per worker is 240MB.
The agentic systems people are actually building are increasingly parallel. Fan-out subagents are normal. Long-running supervisor processes that spawn ephemeral workers are normal. The README’s “5 LLM providers” and “18 lifecycle hooks” presuppose that the deployment shape is more involved than a single REPL.
The Zig 0.16 commitment
The README is also specific about the implementation language: Zig 0.16. This is worth noticing because it is doing two things at once.
First, it is a credibility signal. Zig is a small, low-level systems language with no GC, explicit allocators, and comptime metaprogramming. You do not pick Zig if your design priorities are “fast iteration on a script”. You pick Zig if you want the binary characteristics tokenworm is reporting: small footprint, predictable performance, no hidden control flow.
Second, it is a constraint on the contributor surface. A Python agent SDK can be modified by anyone who knows Python; a Zig 0.16 agent SDK is going to attract a narrower set of contributors. That is not necessarily a downside — for an SDK whose value proposition is its disciplined runtime characteristics, contributors who already think that way are probably the right set. But it is the trade.
The shape of the bet
The README is making a concrete bet: a non-trivial share of agent deployments care about runtime characteristics that current Node/Python SDKs cannot deliver. CI fanout, embeddable use, pre-commit triage, LSP, fleet workers, mobile/desktop binaries, edge functions — every one of those benefits from a 960KB, 8ms, 2.4MB agent core.
For deployments that do not care — interactive REPLs, hosted notebooks, single-call backends — the cost calculus is genuinely different and the existing SDKs are fine. tokenworm is not claiming to displace them there.
What the binary size unlocks is a different deployment surface: one where the agent is an embeddable component, not a service. That is the shift the README is actually selling. The numbers are the evidence. The C ABI, the .tworm session blob, the OS-native sandbox, the multi-provider switch — these are the implementations that make the embeddable story coherent.
If you have been waiting for the agent SDK that can ship in the place a CLI tool ships, this one fits in the place a CLI tool fits. That, more than any single benchmark, is the change.