In my first Gigatoken post, I tested its 1,000x claim against my tokeniser workload. On that workload, the tokeniser core ran 30x to 40x faster, including 37.6x on a million-token request split into 1,024 segments. The result was well below 1,000x. I wanted to understand where the gain came from.

I followed the path Gigatoken optimises most aggressively: tokenisers that apply BPE (byte pair encoding) to UTF-8 bytes, including GPT-2 and the tiktoken family. This is the path behind its headline throughput and the one exercised by my benchmark. The project has no technical paper yet, so what follows is my interpretation of Marcel Rød’s source comments, optimisation diary, profiling reports and commit history.¹ Gigatoken describes SentencePiece as less optimised and does not support WordPiece.²

How BPE turns bytes into tokens

The tokenisers in this article turn UTF-8 text into a sequence of integers. Their vocabularies map byte sequences to token IDs. A token might represent a whole word, part of a word, punctuation or a single byte.

Encoding runs as a pipeline. Pretokenisation is the coarse split immediately before BPE: it divides the continuous byte stream into spans using model-specific rules, commonly expressed as a regular expression. Each intermediate span is a pretoken, which BPE consumes to produce the final model tokens. For GPT-2’s r50k tokeniser:

" Gigatoken optimises pretokenisation for CPU microarchitectures."
→ [" Gigatoken", " optimises", " pretokenisation", " for", " CPU", " microarchitectures", "."]

BPE turns those seven regex spans into fifteen GPT-2 model tokens. The distinction matters because one pretoken can produce several model tokens.

The hard boundaries also explain why the spans are independent. BPE is forbidden to merge across them, so a merge inside one pretoken cannot create or remove a candidate pair in another. The encoder can process each pretoken separately, then concatenate their token IDs in the original order.

Inside one pretoken, BPE starts from bytes or initial symbols. Its merge table was learned when the tokeniser was trained and is fixed during encoding. Each legal adjacent pair has a numeric rank, and the lower rank wins. For the ` microarchitectures pretoken, one of the later steps merges [it] [ect] into [itect]; the final GPT-2 pieces are [ micro] [arch] [itect] [ures]`. The encoder looks up the affected neighbouring pairs again after every merge, chooses the next best candidate and repeats until no legal merge remains. The surviving symbols map to token IDs.³

What Gigatoken changes inside the Rust core

Traditional Python tokeniser APIs inspect Python input objects and assemble Python-facing results; Gigatoken can read borrowed byte buffers and assemble a flat token buffer in Rust. The service I benchmarked already uses a Rust tokeniser core, so I exclude those API-boundary gains and examine the CPU and memory work inside tokenisation.⁴

I group the Rust-core changes into four families: 64-byte boundary classification, cached pretoken encodings, compact pair-rank tables for misses and parallel work split at safe pretoken boundaries. These are the four main hot-path changes for the BPE tokenisers in scope. The available measurements use different machines, cache states and controls, which prevents a clean apportionment of the overall speed-up. Each result needs its own baseline.

1. Pretokenise 64 bytes at a time

A general-purpose regex engine finds one matching span after another. Gigatoken’s mask scanner asks which positions in a 64-byte input block begin pretokens. The block sets the scanner’s working width. Pretokens can continue across its edges.

The first classification pass handles ASCII, where one byte represents one character and simple byte comparisons can identify letters, digits, spaces, newlines, apostrophes and other categories. SIMD performs these comparisons across several byte positions at once. Each position is called a lane, and each lane holds one byte here. Four 16-byte NEON loads cover the batch on ARM, two 32-byte AVX2 loads cover it on x86, and AVX-512 can load all 64 bytes at once. The comparisons become separate 64-bit class masks, with one bit for each input byte. Bytes at or above 0x80 go to a second Unicode pass.⁵

Gigatoken’s loader recognises a fixed set of tokeniser patterns and selects dedicated Rust code for each one. For each mask-scanner family, the implementation expresses the regex’s boundary rules as operations over the class masks. The code treats each mask as a row of 64 on/off positions. A shift slides one row left or right so each byte lines up with its neighbour. AND keeps positions where two conditions are true, OR combines alternatives, and NOT selects positions outside a class. SIMD has finished once it creates the masks; ordinary 64-bit integer operations then combine them into boundary bits.

The author’s detailed optimisation notes and isolated scanner measurements use GPT-2’s r50k pretokeniser, so I use the same worked example here.⁵ Its 64 ASCII bytes fill one complete scanner block. Under r50k’s rules, a leading space can join the letter, number or punctuation run after it. Shifting the class masks supplies the previous-position relationship for every byte at once. The boundary rules mark starts at byte offsets 0, 10, 20, 36, 40, 44 and 63, producing ·Gigatoken, ·optimises, ·pretokenisation, ·for, ·CPU, ·microarchitectures and .; here · represents a space byte.

Bit-parallel regex evaluation and SIMD block classification predate Gigatoken. Its contribution is specialising those techniques for the fixed patterns used by model tokenisers.⁶

The mask scanner must reproduce the regex’s boundaries. A pretoken can cross a 64-byte edge, so the scanner carries information from the preceding character and looks beyond the right edge where a rule needs it. Each batch returns the starts it can prove. Gigatoken calls any uncertain stretch a bad zone and re-derives its boundaries exactly. Invalid UTF-8 can create a bad zone, as can ordinary text whose boundary conditions remain ambiguous at the edge of a block.

Differential tests compare the combined mask and fallback output with the reference across crafted edge cases, 4,000 generated inputs and OpenWebText samples.⁵

Unicode stays exact

About 21% of batches in OpenWebText, a web-text corpus, contain at least one non-ASCII byte. UTF-8 breaks the ASCII pass’s one-byte-per-character assumption: one character can occupy several bytes, and those individual bytes do not reveal whether the character is a letter, number or whitespace. The SIMD pass therefore records their positions in a non-ASCII-byte mask for a second classification pass.

The second pass completes the same 64-position masks. For this r50k path, Gigatoken finds each UTF-8 lead byte, decodes its code point and uses a packed table of about 272 KiB to classify the character as a letter, number, whitespace or other. It stamps that class across every byte of the UTF-8 character, preventing a continuation byte from becoming a false boundary, then adds those results to the masks used by the tokeniser’s boundary rules.

Any region the masks cannot settle falls back to Gigatoken’s scalar walker. The walker uses ordinary integer instructions and advances one span boundary at a time. It also handles CPUs without the required SIMD features, the incomplete tail of a buffer and bad zones such as invalid UTF-8 or ambiguous batch-edge cases. For r50k on the OpenWebText sample, about 0.4% of batches require scalar re-derivation.⁷

When boundaries are requested one at a time, the scanner finds the lowest set bit with trailing_zeros and clears it with mask &= mask - 1.⁸ The hot encode path converts each mask into a flat buffer of boundary offsets, collects up to 256 spans, then processes them in a counted loop. The counted loop reduces data-dependent control flow in boundary discovery and consumption. Cache probes, BPE misses and token emission still carry their own branches and dependent work.

On GPT-2/r50k over a 1 GB OpenWebText sample, the mask scanner reached 2,460 to 2,600 MB/s against 983 MB/s for Gigatoken’s scalar reference, an isolated 2.5x to 2.6x improvement.⁵ That figure covers boundary detection. Turning each span into token IDs remains downstream work.

2. Cache the final IDs for each pretoken

After pretokenisation, an encoder normally runs the BPE merge loop for each span. Gigatoken memoises the final token-ID sequence for the exact bytes of each ordinary pretoken. For an unseeded pretoken, the first occurrence computes the tokeniser’s normal answer; later occurrences copy the saved IDs. Each cache entry stores one pretoken’s final IDs; merge histories and whole-request outputs stay outside the cache.

Pretokens up to 15 bytes use a custom short-key table, while longer ones use a separate map. The short table is seeded with exact results for vocabulary byte strings from 1 to 15 bytes. A reused tokeniser instance keeps its results across calls and continues warming.

For a fixed tokeniser, the same pretoken bytes always produce the same IDs, so the cache can replay them without changing the result. The tokeniser’s own rules generate seed values because a vocabulary entry’s ID can differ from the required answer. The 128-bit key contains the complete short byte string and its length, and the table compares that full key after hashing. A hash collision triggers another probe. Full-key comparison prevents it from returning another pretoken’s tokens. Differential tests compare the cached path with uncached encoding across the supported tokeniser families.⁹¹⁰

On the author’s 1 GB GPT-2/OpenWebText run, the table accumulated about 1.3 million unique short pretokens and served 99.4% of lookups as hits. About 90% of pretoken occurrences emitted one token and 98% emitted no more than two.¹⁰ In that workload, most spans skip the pair-rank lookups, merge decisions and scratch-state updates described in the next section. A hit finds the cached entry and copies its token IDs.

Fetch the key and answer together

Once caching removes the merge algorithm from the common path, the remaining cost is a largely random table lookup. Processors fetch memory in fixed blocks called cache lines. The x86 machines discussed here use 64-byte lines; the Apple M3 Pro in my benchmark uses 128-byte lines. L1 is the smallest and fastest cache near each core; L2 and the shared last-level cache hold more data at higher latency. A load that misses them may leave the core waiting for main memory.

A short pretoken and its length fit in one 128-bit key. A hash chooses an aligned home pair in the open-addressed table. Where available, Gigatoken calculates the hash with CPU checksum instructions; other targets use a portable arithmetic fallback. Each entry is 32 bytes, so both candidates form one 64-byte probe bucket that fits within a hardware cache line on both architectures. Gigatoken loads both keys and inline values together, compares the complete keys, and selects the match in registers. The common probe requests the bucket’s cache line and avoids a metadata fetch followed by a dependent random load of the value.

Collisions probe later buckets. Up to four token IDs live inside an entry; larger answers spill into a separate append-only token buffer. Offsets and lengths keep cache entries valid across buffer reallocations.

Gigatoken processes up to 256 pretokens as a group. While it discovers their spans, it asks the CPU to prefetch each future target line into L2. During the probe pass it requests promotion into L1 sixteen entries before use. The CPU may ignore a prefetch hint. When it honours one, independent work overlaps the memory fetch and reduces the chance that the probe waits for that line.

The common inline emit path also spends a few extra stores to remove control flow. It reserves room for four token IDs and writes all four lanes from the cache entry. The cursor advances only by the true count, so unused lanes are overwritten by the next result or truncated at the end. That avoids a count-dependent ladder of one-token, two-token, three-token and four-token branches.

The published A/B measures the combined probe-and-emit design: memoisation, staged prefetch, inline four-token values and flat output. On the campaign’s cold 10 GB GPT-2/OpenWebText benchmark, that combination was 27.6% faster in the single-threaded path that materialised the token IDs and 6.2% faster on the multithreaded path.⁹

Reduce address-translation work on Linux

The cache works on ordinary memory pages. On Linux, huge pages can reduce the address-translation overhead as a randomly probed table grows. Before a core can load a cache entry, it must translate the program’s virtual address into a physical address. The processor keeps recent translations in a translation lookaside buffer, or TLB. If the translation is absent, a page-table walk must find it first. On Zen, a software prefetch that misses the data TLB may be dropped, weakening the prefetch ladder described above.

A 64 MiB table occupies 16,384 ordinary 4 KiB pages. Full backing by 2 MiB huge pages reduces that to 32 pages. Gigatoken therefore aligns a large short-cache allocation to 2 MiB on Linux and calls MADV_HUGEPAGE before the memory is first touched. If Linux honours the hint, fewer translations have to cover the same table.

In a separate Zen 5 whole-encode comparison, huge pages reduced warm page walks from about 28.6 million to about 2,300 per pass and improved warm throughput by 7.3%.¹¹ Because the A/B covered the input and output, the result captures address translation across the whole path. The allocation hint is Linux-specific and does nothing on macOS.

3. Make pretoken-cache misses cheaper

A pretoken-cache hit skips BPE. On a miss, the encoder must run the merge loop for that pretoken. Each merge changes up to two neighbouring candidates, so the next choice depends on the previous one. Gigatoken keeps that ordering serial while shortening pair-rank lookups and reusing temporary storage.

Some BPE vocabularies assign merged token IDs in merge-priority order, allowing the ID to rank a candidate. Others store merge rank separately from token ID.¹² Gigatoken preserves whichever ordering the tokeniser defines. For an ID-as-rank vocabulary that fits its packed representation, pairs whose IDs are both below 2,048 use a dense 16 MiB grid; other pairs use a packed sparse table. Both replace a general map with a shorter chain of dependent memory loads.¹³

Short and medium spans use fixed local rank and neighbour arrays with a linear scan. Long spans use reusable index arrays as a linked list plus a minimum heap, a priority queue that returns the lowest rank. On the ID-as-rank path, Gigatoken retains those arrays and the heap capacity between calls, avoiding fresh allocations for each cache miss. Both paths preserve merge priorities and choose the leftmost candidate when ranks tie.

On a 1 GB GPT-2 run on Zen 5, widening the dense grid to 16 MiB improved whole-encoder single-threaded throughput by 2.8% with a cold pretoken cache.¹³ Once warm, the cache’s 99.4% hit rate starves this path of work, and the gain disappears.¹⁰

4. Parallelise across proven boundaries

Hugging Face Tokenizers and tiktoken parallelise across caller-supplied inputs, so a million-token document remains one item. Gigatoken finds proven boundaries inside that document and assigns its chunks to several workers.¹⁴

Gigatoken cuts at proven pretoken boundaries, which BPE cannot cross. Added and special tokens stay intact. Inputs with no safe cut stay serial. Tests compare the parallel output with the serial token IDs in their original order.¹⁴

Keep coordination outside the token loop

Workers share immutable vocabulary and pair-rank tables. Each worker owns its pretoken cache and scratch buffers, keeping locks and cross-core traffic from shared writes out of the per-pretoken loop.

Workers claim chunks through an atomic counter. Because the chunks are arranged from largest to smallest, the largest are claimed first while smaller tail chunks keep cores busy near the end. Strict ordering prevents a large chunk from starting late and becoming the final straggler.¹⁴

Copy results while the tail is still encoding

Gigatoken reserves flat output space and uses a commit cursor to copy the ready prefix while later chunks are still encoding. This overlaps result copying and first-write page allocation with useful work. If the reservation is too small, it gathers the completed chunk buffers after encoding.¹⁴

In separate A/B comparisons, the 16-thread path was 6.2% faster with strict handout plus parallel gathering and 4.4% faster with opportunistic prefix copying, each against its own control.¹⁴

The closest published total comes from the campaign’s final same-session comparison on a cold 10 GB GPT-2/OpenWebText encode. Its documented single-thread path reached 1,039 MB/s, while the 16-thread path reached 8,792 MB/s. That is about 8.5x the wall throughput, equivalent to cutting the 10 GB encode from roughly 9.6 to 1.14 seconds. Each worker runs the scanner, cache and miss paths described above, so parallelism scales the faster core.¹⁴

What parallelism costs

Exclusive worker state removes shared-cache locking from the per-pretoken hot path. The trade-off is a cache per worker and duplicated warm-up work. In the author’s 16-worker profile, the state slots accumulated about 16 million distinct entries between them, compared with 5.5 million for a single cache. Aggregate multithreaded CPU time was 14.7 seconds against roughly 11 seconds for Gigatoken’s single-thread run, even though wall time fell sharply. The request finished sooner by spending more aggregate CPU work and memory.

Initial short-cache sizing is clamped between roughly 2 and 128 MiB per state slot, depending on the predicted share of the batch. The tables can continue to grow, however. The short cache has no eviction, and the long-key maps and token arenas are append-only. The pool keeps that memory across requests. One user processing several terabytes reports in an open issue that Gigatoken eventually consumed the RAM and swap of a 1 TB server.¹⁵

The wall-time gain therefore comes with a production requirement: long-running workloads with continually changing input need a way to bound or evict retained cache state.

What the Rust core achieved

Gigatoken’s 1,000x headline compares its native whole-buffer API with Hugging Face Tokenizers through its Python-facing batch API. Hugging Face’s encoder also runs multithreaded Rust. The headline includes the advantages of handing Gigatoken one 11.9 GB byte buffer, letting it find its own split points and avoiding compatibility work at the Python boundary.¹⁶

My service already used a multithreaded Rust tokeniser core. My benchmark therefore compared two Rust cores. As I reported in my first Gigatoken post, the timed million-token, 1,024-segment count path fell from about 159 milliseconds to 4.24 milliseconds, a 37.6x speed-up.

Together, the four mechanisms show how Gigatoken changes the way tokenisation runs on the hardware: classify 64 bytes at once, lay common cache probes out in 64-byte buckets, shorten the BPE miss path and parallelise at safe boundaries. GPU kernels receive this scrutiny as a matter of course. CPU preprocessing should too.

Gigatoken’s figure measures its fastest path over an 11.9 GB OpenWebText file. My use case is an online tokenizer: mixed text, requests ranging up to a one-million-token context window, sometimes split into 1,024 segments, with an HTTP boundary around the work.

I measured between 30x and 40x in the tokenizer core. That is a large improvement, but the gap from 1,000x is too wide to dismiss as benchmark noise.

Where the thousand comes from

A tokenizer splits text into pieces, repeatedly merges byte pairs and emits token IDs. The normal implementation is already fast Rust, but parts of its hot path still behave like general software. A regex engine performs pretokenization. Bounds checks and unpredictable branches sit inside tight loops. Threads exchange work. Language bindings move data between Python and Rust.

Its pretokenizers replace general regex execution with specialised state machines. On the current fast path, architecture-specific SIMD classifies 64-byte blocks into bit masks, then bitwise operations derive most boundaries in parallel. Ambiguous Unicode regions take an exact scalar path. Common byte-pair results are cached so repeated words can skip most of the merge work. Predictable branches, local memory access and independent workers reduce CPU stalls and coordination overhead.¹

The benchmark script loads the corpus into memory before timing. Gigatoken receives it as one large byte document and finds safe boundaries where it can divide the work between cores. This avoids pre-splitting the input through Python and gives the scheduler an enormous, regular slab of work. It is an in-memory encoding benchmark, rather than a file-I/O benchmark. On a 144-core AMD EPYC machine, Gigatoken reports 24.53 GB/s for GPT-2 against 24.8 MB/s for Hugging Face, or 989x. On an Apple M4 Max it reports 8.79 GB/s against 6.9 MB/s, or 1,268x.²

Both results use the workload best suited to Gigatoken’s native API. Gigatoken’s own documentation says its compatibility mode is slower and does not reach 1,000x. The headline is therefore a best case, rather than a general expectation for replacing an existing tokenizer.

What happened in my workload

I compared Gigatoken with the Hugging Face tokenizers Rust library using identical prepared bytes. Before timing anything, I required the two implementations to produce the same token IDs. The parity checks passed across representative BPE, byte-fallback and tiktoken-style model families.

The preliminary direct results below use a GLM tokenizer on an Apple M3 Pro. Each workload contains mixed prose, code and structured text.

Gigatoken sustained roughly 168 to 238 million tokens per second as the batch grew towards the context limit. The baseline stayed near 4 to 7 million.

The missing 970x

My service cannot hand Gigatoken an 11.9 GB file and disappear. It receives bounded requests, preserves segment boundaries, returns nested results and pays for HTTP, serialisation and scheduling. The baseline is also called through its native Rust interface, so Gigatoken cannot win by removing Python overhead that was never present.

Small requests expose fixed costs. Segmentation limits how freely work can be divided. At the HTTP boundary, faster tokenization leaves a larger fraction of time in everything surrounding it. This is Amdahl’s law: speeding up one part of a system has diminishing effect once the unchanged work dominates the total time.

The 1,000x headline did not survive this workload. The million-token segmented case was 37.6x faster, cutting core processing time from about 159ms to 4ms while preserving every token ID. The claim did not transfer to production, but the speedup did.

So I reach for it on everything. When it can’t crack a task, I rarely stop to ask whether a hammer was the right tool. I just wait for a bigger one, the next model with a longer window and a higher benchmark. But hand someone a hammer and everything starts to look like a nail. Some tasks were never nails.

For one shape of work, there is another way. A lot of real work isn’t deep and sequential. It’s wide and shardable: audit every file in this repo, review every dependency, document every subsystem, check every source. Point a single long-context agent at that and it’ll get there, but you will pay dearly for the privilege.

That question is why I built the Doubleword Agent Swarm, my open-source reimplementation of the agent swarm Moonshot introduced in the Kimi K2.5 report: an LLM orchestrator designs its own team of bounded-context workers and fans them out in parallel over a task. This post is the story of how I built it, and what happened when I pointed it at a real codebase, side by side with a single long-context agent.

For wide, shardable work, a swarm of bounded agents beats one long-context agent on cost and on output. The model designs the team. I build the scaffolding, and it’s small.

What the hammer costs

To make it concrete, I picked a job I needed done: a security audit of control-layer, Doubleword’s open-source AI gateway, 512 source files and about 2.4M tokens of unique source. Find real vulnerabilities (injection, leaked secrets, broken auth, unsafe file handling). I ran it both ways, one long-context agent and the swarm.

I ran the single agent first: Claude Opus, a 1M-token window, no chunking, just “audit the repo”. It works. The trouble is what it costs. An agent loop re-sends the growing transcript with every turn, so by the time my metered run had covered ~7% of the repo, it had already burned 27.7M tokens, 95% of them cache reads, the same transcript shipped back again and again.¹ Projected over the full repo, the audit lands around 300M tokens: a 2.4M-token codebase, amplified ×125.

Reading the codebase once costs 2.4M tokens. The remaining ~297M is the agent re-reading what it has already seen.

The alternative: a swarm

Don’t make one agent re-read everything. Split the repo across many bounded workers, each reading only its own slice, once, all at the same time. That’s an agent swarm.

It’s how every company already works. The CEO is the most capable (and most expensive) person in the building, and the wrong one to personally trawl through every file. So they don’t. They hire specialists with tight remits, hand each a bounded task, and never see the mountain of material those specialists wade through. What comes back is a short, high-level summary. The raw work stays with the specialist. The same setup works here, just with agents: the orchestrator plays CEO, the workers are its specialists, and only their conclusions ever travel back up.

Who designs the team?

In February 2026, Moonshot published the Kimi K2.5 technical report.² Its agent-swarm result is the framework I built on: scale out, not just up. A trainable orchestrator spawns specialised sub-agents and runs them in parallel, trained with PARL (Parallel-Agent Reinforcement Learning), where only the orchestrator learns and the sub-agents stay frozen. The headline numbers: 4.5× lower latency than a single agent, and +17.8 points on BrowseComp.³ What’s new is that the swarm designs itself: decomposition and team width are the model’s call, not a hand-written workflow.

What’s in the weights is only the orchestration instinct: how to decompose, delegate, reconcile. The runtime that makes a swarm real (spawn, isolate, parallelise, aggregate) lives in Moonshot’s hosted product, not in the open weights. An open endpoint gives me what it has always given me: messages and tools in, tool calls and text out.

That gap became the project: the weights bring the instinct, I build the body. doublewordai/swarm is that body, my from-scratch interpretation of Moonshot’s swarm, built on the Open Responses API, model-agnostic (default: moonshotai/Kimi-K2.6).⁴

The architecture

Everything I kept from the paper, and everything I added, compresses to four principles:

1. A self-designing orchestrator. The model decides the team and the decomposition, not me.
2. Bounded local context. Each worker sees only its slice, and returns only results.
3. Structural anti-groupthink. Independent verification before any finding counts.
4. Synthesis. One final pass reconciles everything into a deliverable.

Left to right: the repo is cloned and compressed into a budgeted map; the orchestrator designs a team and dispatches scoped tasks in parallel waves; ephemeral workers investigate and return findings only; findings are deduped, challenged by verifiers, and reconciled by a synthesizer into report.md. Four blocks, one per principle.

Block 1: the orchestrator designs the team

The orchestrator gets the repo map up front and can probe with read_file and grep before committing to a plan. Then it builds its team with two tools, create_subagent(name, system_prompt) and assign_task(agent, prompt), the literal tool surface Kimi K2.5/K2.6 were RL-trained on.⁵ It authors each specialist’s system prompt itself. In one real audit run it invented a persona I never asked for:

# the orchestrator wrote this prompt (persona registered once)
create_subagent(
    name="injection-filesystem",
    system_prompt="You hunt injection and unsafe file access…",
)

# every task spawns a fresh agent with that persona
assign_task("injection-filesystem", "Audit cli.py …")
assign_task("injection-filesystem", "Trace cost.py …")

The division of labour matters: the model decides who does what; the harness decides which tools each role may hold. Each dispatching turn is a wave: width is parallelism, follow-up waves fill gaps.

Block 2: workers see only their slice

This is the paper’s key lever, the one that pays for everything: context sharding. Each task spawns a fresh, throwaway agent. It self-gathers exactly the context it needs (read_file, grep, plus whatever capability tools its role grants), works for a few rounds, calls submit_results, and is gone. Only schema-valid results and a status line return to the orchestrator; the worker’s research is discarded, never re-sent.

Context integrity and cost turn out to be the same lever pulled once: no single context ever overflows, and per-agent token usage stays low. That’s why fanning out hundreds of workers stays cheap, and why the 300M-token bill from earlier never materialises. (The v1 toolset is deliberately read-only, so it’s safe to point at any repo.)

Block 3: every finding meets a skeptic

A swarm of enthusiastic hunters produces enthusiastic false positives. So before anything counts, each candidate finding is handed to an independent verifier whose only job is to refute it, and which defaults to “not real” when unsure. Survivors ship with adjusted severity; refuted findings are dropped and counted.

This stage is my addition; the paper’s orchestrator reconciles inline. It’s optional and per-brief; --verify-votes N turns it into a majority-vote panel.

Block 4: one pass writes the report

Finally, a single tool-free synthesis call reconciles the confirmed findings into the deliverable: report.md for humans, findings.json for machines. Its shape comes from the brief, not the engine, which brings me to the part I like most.

Swap the brief, keep the engine

Nothing in the engine mentions auditing. The loop (orchestrate, shard, verify, synthesize) is byte-identical for every task. What a swarm does is a brief: ~50 lines of data binding prompts to roles, a result schema (enforced at submit_results: invalid items are dropped, not trusted), and a tool selection per role:

# src/briefs/onboarding.py (abridged)
from . import Brief, register

register(Brief(
    name="onboarding",
    description="Document a codebase's subsystems for newcomers.",
    orchestrator_prompt="You are the lead author … call dispatch_workers once …",
    worker_prompt="Document ONLY your assigned files: purpose, key components, deps …",
    synthesis_prompt="Assemble an onboarding guide: overview, per-subsystem sections …",
    result_schema={...},
    result_key="sections",
    worker_tools=("read_file", "grep"),
    verifier_prompt=None,   # set a prompt to switch the adversarial verify stage on
))

Two briefs ship in the box, audit and onboarding, and the ones I could write are an afternoon each: a dependency review (one worker per dependency: version drift, advisories, upgrade risk), a refactor plan (workers map usage per module, the synthesizer sequences the steps), wide research (one worker per source; verifiers refute unsupported claims).

The receipts

The two runs, side by side:

The swarm’s run, measured: 348 API calls, 5.2M tokens in, ~450k out, about 53× fewer tokens and 45× cheaper at Doubleword’s Kimi K2.6 pricing ($0.95/M input, $4/M output).⁶ The output held up, too. The verifier stage refuted and dropped roughly half of the candidate findings before any of them reached me, so what survived came with severity, file:line, and a suggested fix attached.

Nobody’s waiting: the flex tier

A swarm is a just-get-it-done workload: hundreds of concurrent calls, and no human watching any single one. It’s throughput-bound: what matters is when the whole wave lands, not when each call returns.

Doubleword’s flex tier is priced for this. Individual calls may run longer, but global throughput holds, so end-to-end wall-clock stays roughly the same, at ~30% off.⁷

service_tier = "flex"   # was "priority"

Run it on your repo

The quickest path is the dw CLI, which sets up auth, endpoint, and model in one step:

dw login
dw examples clone swarm
cd swarm
dw project setup

Then point a brief at a repo:

dw project run audit      -- --repo psf/requests --max-files 20         # audit a GitHub repo
dw project run onboarding -- --path ./my-service                        # document a local directory
dw project run audit      -- --repo psf/requests --service-tier flex    # run on flex tier for 30% cost saving!
dw project run report                                                   # print the latest run's report

Each run writes results/<brief>-<slug>/: the synthesized report.md, structured findings.json, swarm-tree.json (the team the orchestrator designed, worth reading at least once), and summary.json with tokens, cost, and step counts.

Everything is open: the harness is on GitHub, it speaks the Open Responses API, and it’s model-agnostic: -m any tool-caller you like, Doubleword’s or otherwise.

Doubleword is built for this kind of high-throughput inference, and I’d love to see what you fan out. Clone the swarm, write a brief, and go run parallel agents.