TheDaily Front

TL;DR: AI companies are secretly buying, scanning, and destroying millions of physical books to train their models, permanently locking human knowledge inside private corporate servers. Anna’s Archive is urgently calling on volunteers worldwide to scan and upload books before this cultural heritage disappears forever.

Several AI companies are acquiring large quantities of secondhand books through intermediaries, scanning and destroying them, all to obtain training data “untouched by machines” from before 2022.

Anthropic’s “Project Panama” was exposed in a $1.5 billion copyright settlement. In early 2024, they launched this highly confidential project. The company has spent tens of millions of dollars purchasing millions of paper books, scanning them, training its Claude LLM, and then destroying them all. It’s outrageous is that it’s legally permissible, but ethically, it’s an extremely serious crime against humanity.

So why destroy physical books? Behind it lies the AI race and the interests of capital:

1. It prevents these books from being scanned and used for training by competitors.
2. It avoids legal risks.
3. Destroying books is cheaper than lossless scanning.

After AI companies massively scan and destroy physical books, they become the only ones in the world with digital copies. Knowledge is permanently monopolized on private servers.

This battle for old books reveals a paradox: while promising to “make human knowledge accessible,” AI companies are dismantling the most solid carriers of human knowledge. The public may gain more intelligent AI assistants, but at the cost of a vast amount of knowledge resources disappearing from the public domain.

Shadow libraries

As the world’s largest shadow library, Anna’s Archive needs a plan to combat the destruction of physical books by AI companies. After all, the emergence of shadow libraries is the greatest miracle of knowledge sharing in the 21st century. Along with other shadow libraries, we’re building a digital library of Alexandria, an inextinguishable light of humanity.

We need the help of volunteers worldwide to scan materials (including books, journal articles, newspapers, magazines, ancient books, rare books, and other materials) from every library and archive around the world and upload them to the shadow library for knowledge preservation, especially those that are easily lost. If every person scans a book, and there are 10 million volunteers worldwide, we can obtain 10 million pieces of invaluable wealth.

• For small scans and uploads, we usually award recognition and lifetime membership to Anna’s Archive.
• For large-scale scans and uploads of books, we can help pay for the scanning fees and other rewards.

Time is running out

Since the beginning of 2025, AI-generated content has accounted for more than half of newly published internet content. A frightening reality emerges: if much of the future content consists of AI-generated books and papers, will humans be able to distinguish them? Once AI has absorbed even the last sentence written by humans on paper, all that will remain on the internet will be AI’s own words. In such a world, how can human civilization be preserved?

Shadow libraries offer the best answer. If you want the memory of human civilization to no longer be monopolized, if you want future generations to be able to read all of humanity’s wealth for free, if you don’t want publishers making a fortune while authors receive little, then please help us. Please make any contribution you can, whether it’s scanning and uploading books, purchasing books and papers to scan and upload, or donating. With the efforts of all humanity, the monopoly on knowledge will be broken. Each of us can make history.

This is a race against time. Our ideal is to scan and upload all the world’s publications before publishers completely block knowledge, and before AI companies scan and destroy all the world’s books and papers.

- Anna’s Archive volunteer “u”

It is a sign of the times that Amazon gets to call this fair use while huge corporations try to sue the Internet Archive out of business.

This 404 report justly been getting considerable coverage.

Amazon is buying massive quantities of books, scanning them for AI training data, and destroying them in the process. 

A 404 Media investigation was able to reveal Amazon’s book buying operation, which hasn’t been previously reported, by placing a tracking device in a rare book we suspected would be acquired by an AI company for training data, and following it around the country to its final destination. 

That final destination was an Amazon warehouse in Las Vegas, Nevada. Amazon employees who work at this location say all they do is receive massive shipments of printed books which they then cut the bindings off in order to scan the books more quickly. The printed book is destroyed in the process. The logo of the Amazon team that works at this warehouse, called VGT3, is a dinosaur, brandishing its teeth and with a book in its hands.

...

We’re not revealing the titles of the books included in the shipment we tracked, but they are rare, meaning there are not many copies of them in circulation. Sometimes that’s because not many copies of them were ever printed, and sometimes because they are in a foreign language not many people speak. As the bookseller who sold them told me, there are not many people in the world who would care about them in the same way people might care about the first edition of Oliver Twist, but that doesn’t mean they’re not valuable. 

“There are different types of value,” the bookseller said. “There's monetary value, obviously, but there are a lot of other types of value. There's historical value, intellectual value, sentimental value. All sorts of things, and all of those the AI companies don't care about. They just want the content as a bunch of words strung together.”

As mentioned elsewhere, this is also IP theft on a massive scale. 

There is, however, one aspect which hasn't gotten to play it deserves, namely how a genuinely ethical and public spirited company handles the same problem.

Scanning all the Books: The Work of Scribes for the Internet Archive
Anne-Laure Freant

In 1996, computer engineer Brewster Kahle founded the Internet Archive with the mission to provide "universal access to all knowledge." Today, that vision drives the methodical work happening in scanning centers where operators carefully digitize books one page at a time, preserving both the content and the physical integrity of centuries-old volumes.

The Internet Archive's approach stems from a fundamental disagreement with the digitization methods that emerged in the early 2000s. When Google launched its Books project in 2004, it revolutionized the scale of digital libraries but introduced a troubling trade-off: speed versus preservation. Google's industrial approach often involved destructive scanning—cutting book spines and dismantling bindings to facilitate rapid automated processing.

The Internet Archive chose a different path. "At the Internet Archive, we never destroy a book by cutting off its binding. Instead, we digitize it the hard way, one page at a time". That led to the adaptation of machines and software to fit the very specific purpose of the Internet Archive, and to a job: book scanner, or scribe operator.

Just to be clear, the destructive method is faster and cheaper but given the tremendous resources of Amazon and the spectacular amount of money that has been spent and in many cases demonstrably wasted pumping up the AI bubble, that's not much of an excuse. Arguably even worse when you remember this is all going to train the latest of Amazon's crappy Nova series. 

This was a choice they made, just like setting up massive fossil fuel power plants now rather than taking the time to increase nuclear and renewable capacity was a choice, just like stealing the intellectual property of countless writers and artists was a choice, just like rolling out products that weren't ready for prime time was a choice, just like setting up ridiculously at complex and deceptive financing schemes rather than growing the industry in a sustainable way was a choice.

The deepseek-v4-flash-vision-exp model accepts images alongside text, so you can ask the model to describe pictures, read text from screenshots, analyze charts, and more.

Supported image formats: JPEG, PNG, GIF, and WebP. The format is detected from the actual file content, not from the file name or the declared MIME type.

---

Sending Images

There are three ways to provide an image to the model. All of them use the standard OpenAI-compatible Chat Completions format, where content is an array of blocks instead of a plain string. The same three methods are also available in the Responses API, where images are carried in input_image content parts.

The base_url for the examples below is https://api.deepseek.com.

1. Base64-encoded image (inline)

Encode the image and embed it directly in the request as a data: URL. This is the simplest option for local files. The encoded data counts toward the 48 MiB request body limit (see Limits).

import base64
from openai import OpenAI

client = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")

with open("image.jpg", "rb") as f:
    b64 = base64.b64encode(f.read()).decode("utf-8")

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/jpeg;base64,{b64}"},
                },
            ],
        }
    ],
)
print(response.choices[0].message.content)

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <DeepSeek API Key>" \
  -d '{
    "model": "deepseek-v4-flash-vision-exp",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "text", "text": "What is in this image?"},
          {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,<BASE64_DATA>"}}
        ]
      }
    ]
  }'

2. External image URL

Pass a publicly accessible http(s) link and the model downloads the image for you. The URL must be at most 8192 characters, the image file may be at most 32 MiB, and the download must complete within 60 seconds. If your link is longer, use a base64 data URL or the Files API instead.

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this image."},
                {
                    "type": "image_url",
                    "image_url": {"url": "https://example.com/image.jpg"},
                },
            ],
        }
    ],
)
print(response.choices[0].message.content)

3. Reference a file uploaded via the Files API

Upload an image once with the Files API, then reference its file_id in your requests. This is the best option when you reuse the same image across multiple requests, or when the image pushes the request body over the 48 MiB inline limit. Unlike inline images, images referenced via Files API file_id may be up to 64 MiB and are not subject to the 32 MiB per-image check.

Use a file content block with the returned file_id (which has the form file-api-...):

response = client.chat.completions.create(
    model="deepseek-v4-flash-vision-exp",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {"type": "file", "file_id": "file-api-xxxxxxxxxxxxxxxx"},
            ],
        }
    ],
)
print(response.choices[0].message.content)

Alternatively, a file block can carry the image inline as base64 via file_data instead of file_id (the two are mutually exclusive):

{
  "type": "file",
  "file_data": "data:image/jpeg;base64,<BASE64_DATA>",
  "filename": "image.jpg"
}

---

Detail Level

For image_url inputs you can optionally set a detail field to control how the image is processed:

ValueBehaviorlowThe image is downscaled to 512×512 before inference. Faster and cheaper when fine visual detail is not important.highKeeps the original image. (Provided for compatibility; equivalent to original.)originalKeeps the original image.autoAutomatic selection. Currently equivalent to original.

{
  "type": "image_url",
  "image_url": {"url": "https://example.com/image.jpg", "detail": "low"}
}

---

When to Use the Files API

Inline images (base64 or file_data) count toward the request body size limit of 48 MiB. Consider the Files API when:

• A single request would exceed the body size limit.
• The image is larger than 32 MiB, which is only possible through the Files API.
• You reference the same image in multiple requests and want to avoid re-uploading it each time.

---

Token Usage

Images are converted into tokens based on their dimensions, and these tokens are billed together with your text tokens.

Before inference, every image is automatically resized:

• Images with a total pixel count below roughly 384×384 are scaled up while preserving their aspect ratio.
• Larger images are scaled down while preserving their aspect ratio, so that the total pixel count after resizing is roughly that of an 800×800 image.

As a result, there is an upper bound of 384 tokens per image: for example, a 2000×2000 image and a 5000×5000 image consume the same number of tokens after resizing. When a request contains multiple images, each image is counted independently under the same rule — there is no separate calculation for multi-image requests.

To estimate the token cost of an image of a specific size, use the image token calculator on the Token & Token Usage page.

---

Limits

LimitValueSupported formatsJPEG, PNG, GIF, WebPExternal URL length8192 charactersRequest body size48 MiBMax single image size (base64 / external URL)32 MiBMax single image size (Files API file_id)64 MiBMax images per request600Max total image size per request64 MiB without file_id images; up to 200 MiB including file_id imagesMax image dimension8192 px per side; drops to 4096 px per side when a request contains 15 or more images

For storage and upload quotas of files uploaded via the Files API, see Files API: Limits.

---

Restrictions

• Images are supported in user messages only: images in system or assistant messages return a 400 error.
• Only vision models (deepseek-v4-flash-vision-exp) accept images; other models return a 400 error ("This model does not support image").
• User text containing the reserved image placeholder token is rejected with a 400 error.

---

Using Images with the Anthropic API

In addition to the OpenAI-compatible endpoint above, you can send images through the Anthropic-compatible /messages endpoint (base_url = https://api.deepseek.com/anthropic). For general setup, see Anthropic API.

The difference is the shape of the image content block. Instead of image_url, Anthropic uses an image block with a source object whose type is one of base64, url, or file:

import anthropic

client = anthropic.Anthropic()  # ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic

message = client.messages.create(
    model="deepseek-v4-flash-vision-exp",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "What is in this image?"},
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/jpeg",
                        "data": "<BASE64_DATA>",
                    },
                },
            ],
        }
    ],
)
print(message.content)

The three source variants mirror the OpenAI methods above:

source.typeEquivalent OpenAI methodNotesbase64Base64-encoded imageRequires a media_type field (image/jpeg, image/png, image/gif, or image/webp).urlExternal image URLMax 8192 characters.fileFiles API file_idRequires the header anthropic-beta: files-api-2025-04-14.

---

Using Images with the Responses API

The deepseek-v4-flash-vision-exp model also accepts images through the OpenAI-compatible Responses API. The same three input methods (base64 data URL, external http(s) URL, Files API file_id) and the same limits apply; only the content part shape differs — images are carried in input_image parts, either in user / developer messages or in the output of function_call_output / custom_tool_call_output items:

response = client.responses.create(
    model="deepseek-v4-flash-vision-exp",
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": "What is in this image?"},
                {"type": "input_image", "image_url": "https://example.com/image.jpg", "detail": "low"},
            ],
        }
    ],
)
print(response.output_text)

The input_image part supports a detail field with the same semantics as above (low / high / original / auto). detail is ignored when the image is provided via file_id, and image_url and file_id are mutually exclusive.

For field semantics, restrictions (images in system / assistant messages are rejected with a 400 error), and tool-output images, see the Responses API guide.

Progress in large language models is usually reported as what the best model can now do that no model could do before. That is the direction that produces headlines, and it has indeed been truly incredible. Each step up at the top of the range lets a model handle a kind of task that was previously out of reach, whether that is fixing a bug that spans a whole codebase or, lately, making progress on outstanding mathematical problems that had not been solved by anyone.

There is a second direction of progress that gets less attention, which is how cheaply a given level of capability can be bought. A great deal of useful work does not require the smartest model available, but a model that is good enough, applied many thousands of times. Reading every scientific paper on a topic, checking every contract in an archive for a particular clause, or summarizing every thread in a large discussion forum are tasks of this kind. For these, the question is not whether a model exists that can do the job, but whether it can do the job ten thousand times within a budget. The ceiling unlocks new kinds of tasks; the floor unlocks volume.

When you pick a model for an application you are trading off how capable it is against how much each call costs. For agentic coding I have focused almost entirely on capability, with the general sense that the improved quality of the work is worth the money, even when far cheaper models exist that are reasonably capable. My attention was recently drawn to the cost of the floor. We are measuring how often datasets shared on the DANDI Archive are reused in later publications, which means reading on the order of ten thousand candidate papers with a model and asking of each one whether it actually reused the data. At today’s prices a full pass over the corpus costs a little over a hundred dollars with a model whose capability was at the frontier in the spring. At the prices of this past March, the same pass with the same level of capability would have cost several thousand dollars, and a year ago that capability was not available at any price. That change in the floor is what turned the analysis from a thing we could do on a sample into a viable project. I have been surprised by the progress across the cost spectrum, particularly how intelligent cheap models have become.

Artificial Analysis has been benchmarking intelligence and price across hundreds of models for a couple of years, and enough of that data is accessible to reconstruct the tradeoff. In particular, this plot shows the intelligence index vs. the cost per task, providing a realistic cost estimate for different levels of model capability. The top line is what they define as the “Pareto line,” the most capable models at a given price point. This line describes the true frontier of LLMs. I pulled data from artificialanalysis.ai and looked at how the Pareto frontier has moved as new models have been released. I think it is worthwhile to take a beat to review this progress and make some predictions for the next few months.

The short version: the level of intelligence that cost $1.22 per task in February costs $0.022 today, a 56x drop in under six months, and the rate of decline is accelerating. At the measured pace, a 100x drop for a given capability level takes about a year, and the question worth asking is not whether that happens but what it changes.

The Artificial Analysis Intelligence Index

The capability axis throughout this post is the Artificial Analysis Intelligence Index, so it is worth being clear about what that number is. The current version, v4.1.1, is a weighted average over nine evaluations grouped into four categories: agentic tasks at 34%, coding at 24%, scientific reasoning at 24%, and general capability at 18%. The weighting reflects where the field’s attention is: a third of the score comes from a model’s ability to complete multi-step agentic work, not from answering exam questions. The component evaluations, their weights, and the scoring details are documented in Artificial Analysis’s intelligence benchmarking methodology.

What you end up with is a single number that represents model capability, sort of like an IQ for LLMs. It isn’t perfect, and two models with the same score may have different strengths, but I have found that this score does a reasonably good job of indicating a model’s capability.

As a reference point, Anthropic’s “Claude 4.5 Sonnet (Reasoning)” was for me and many others the first time a model felt capable enough to use in an agentic harness for writing code. At the time I was using Cline, and this model provided substantial productivity gains over auto-complete and copy/paste workflows. That model had an intelligence score of 37.4 (based on today’s intelligence scoring system). The top current model is Claude Opus 5 max effort, at 63.1.

To give a more visceral sense of what the different index levels mean, I borrowed Simon Willison’s pelican benchmark: prompt a model with “Generate an SVG of a pelican riding a bicycle” and look at what comes back. It is not what the index measures, but it is a task anyone can judge by eye. The panels below use the GPT-5.6 family at four points on the index: Luna at low, high, and xhigh effort, and Sol at max effort. I generated three samples per model and show the first one; all of them are in the site repository.

Index 33.9
GPT-5.6 Luna (low)

Index 47.0
GPT-5.6 Luna (high)

Index 50.1
GPT-5.6 Luna (xhigh)

Index 60.9
GPT-5.6 Sol (max)

First of three samples from each model for the prompt "Generate an SVG of a pelican riding a bicycle", generated through OpenRouter on August 20, 2026. Intelligence Index scores are from Artificial Analysis.

The progression is visible: more detail, better proportions, and a pelican that is clearly riding the bicycle instead of hovering over it.

Measuring Cost per Task

Cost per token is easily available, but different models can use a very different number of tokens, so a better indication of the cost of a model needs to take this into account. Cost per task is Artificial Analysis’s own measured number: the average cost in USD to run one task from their Intelligence Index evaluation suite, including the input, reasoning, and answer tokens actually billed during the run. The website displays it but the free API tier does not include it, so I scraped it from the data embedded in each model’s page on the site, covering both the models they currently benchmark and retired models whose pages still carry the measurement (older Claude Opus and Sonnet versions, the GPT-5.x line, and others). That yields measured cost for 137 models reaching back to DeepSeek V3 in December 2024, each paired with a release date and an Intelligence Index score on the current scale.

How the Frontier Has Moved

The charts in this section are a snapshot from August 19, 2026, the date this post was written. A live version of both charts and the tier table, refreshed every week from the same source, is on the LLM Cost Frontier dashboard.

The chart below plots intelligence against measured cost per task and traces the Pareto frontier, the cheapest way to reach each intelligence level, as it stands today and as it stood at two month intervals over the past year, using each model’s release date to reconstruct what was available. The chart builds up one frontier at a time, pauses on the full picture, and repeats; use the button to stop it. Hover any point for the model behind it.

Intelligence Index against measured cost per Intelligence Index task (log scale). Small points are all 137 measured models at their last measured cost, tinted by the two month window in which they were released (models from before August 2025 are grouped with the August 2025 window). Hollow points, both small and large, are open weights models; filled points are proprietary. Hover a point for its details, including whether Artificial Analysis has retired it from live benchmarking. Each line traces the cheapest way to reach a given Intelligence Index among models released by the snapshot date; markers are the frontier models themselves. Where successive frontiers share a segment, the older line is drawn on top, so a newer line is visible only where the frontier actually moved. Models whose pages no longer carry a measured cost (o3 and GPT-5.3 Codex among them) are absent (see caveats).

Each successive frontier sits above and to the left of the last: more intelligence at the same cost, or the same intelligence for less. The pace of that movement is accelerating. Through the second half of 2025 the frontier inched forward: only two small bumps between August and October, and a single one between October and December. The February and April frontiers each moved a large part of the curve, and the last two snapshots have replaced the frontier almost entirely, with ten of the eleven June frontier models new since April and fifteen of today’s sixteen new since June.

The right edge tells the capability story. The ceiling of the frontier rose from index 35.3 in August 2025 (GPT-5 at $0.26 per task) to 37.4 that October (Claude 4.5 Sonnet), 48.4 in February (Claude Sonnet 4.6), 55.0 in April (Claude Opus 4.7 at $2.23), 62.1 in June (Claude Fable 5 at $3.14), and 63.1 today (Claude Opus 5 at $2.34): twenty eight Intelligence Index points in a year. The left half shows the rising intelligence of cheap models. As of August 19, 2026, the GPT-5.6 Luna effort ladder now owns almost everything below index 52, with the level that was the August 2025 ceiling available for $0.0088 per task. The June 2026 frontier was unusually dominated by open weights models: six of its eleven models were open (MiMo-V2.5, DeepSeek V4 Pro, MiniMax-M3, and GLM-5.2 among them), and they held the whole middle of the range from index 38 to 53. In earlier snapshots open models appeared only at the bottom of the range, and today, after the GPT-5.6 Luna release, only two of sixteen frontier models are open.

Note that a single model can cover a large part of this range through different reasoning levels: the GPT-5.6 Luna ladder runs from $0.0088 at low effort to $0.047 at max and covers the whole lower half of the frontier, while Claude Opus 5 spans $0.43 at low effort to $2.34 at max and buys about ten Intelligence Index points along the way. Effort is now a key dial in the cost/intelligence trade-off, and as a consequence, cost and intelligence are inextricably linked.

The records plot below tracks the cheapest measured cost per task achieved by any released model at or above a given Intelligence Index tier. The series reaches back to mid 2025 for the lower tiers, and higher tiers appear when they become available.

Each step is a released model that set a new low for its tier; hollow markers are open weights models and filled markers are proprietary. A tier's line begins when the first model with measured cost crosses that Intelligence Index threshold. GPT-5.6 Luna is placed at its launch price from July 9 and at its current price from the July 30 price cut; all other costs reflect current prices (see caveats).

Tier	First measured crossing	Cost collapse	Halving time
Index ≥ 30	Aug 2025 (GPT-5 high)	29x	~73 days
Index ≥ 40	Feb 2026 (Claude Sonnet 4.6)	56x	~28 days
Index ≥ 50	Mar 2026 (GPT-5.4 xhigh)	35x	~29 days
Index ≥ 60	Jun 2026 (Claude Fable 5 max)	3.8x	~34 days

A capability level is first reached by a large frontier model at a premium price. After some time, cheaper models arrive at the same level, and the record steps down by an order of magnitude or more. The ≥ 40 tier opens with Claude Sonnet 4.6 in February at $1.22 per task, undercut within two days by Gemini 3.1 Pro Preview at $0.33; MiMo-V2.5-Pro, an open weights model, cut the record to $0.034 in April, and GPT-5.6 Luna on high effort holds it at $0.022 today. The ≥ 50 tier follows the same arc a month behind: GPT-5.4 crossed it in March at $1.10, GPT-5.5 and then GLM-5.2 and Grok 4.5 walked the record down through the spring, GPT-5.6 Luna’s xhigh setting took the record at $0.16 when it launched on July 9, and OpenAI’s 80% price cut on July 30 brought it to $0.032, a 35 fold drop in five months.

The first crossing is a maximum effort frontier model priced at launch premium, most often from Anthropic or OpenAI. Following this, small distilled models from the big labs (the GPT-5.6 Luna line holds three of the four current records), and open weights releases (MiMo, DeepSeek V4, GLM, Hy3) drive rates down dramatically. Across the tiers with enough history to measure, the records halve roughly every four to ten weeks.

The top tier is where the premium survives. Only six models score 60 or above, and the cheapest of them, Grok 4.6, still costs $0.84 per task. But that record has fallen 3.8x since June, and if the pattern from lower tiers holds, a distilled model at this level should collapse the price within a couple of quarters.

To me, the most impressive result is the low price of OpenAI’s “GPT-5.6 Luna” given its intelligence. Now, the intelligence of Anthropic’s “Claude 4.5 Sonnet (Reasoning)” that set off the coding harness revolution 10 months ago is available using “GPT-5.6 Luna (medium)” for 1/40th the cost! That figure depends on the July 30 price cut; at Luna’s launch price three weeks earlier, it would have been 1/8th.

Caveats

The most important limitation is that costs are the latest measured values indexed by release date, not historical measurements taken at release. Prices get cut over a model’s life, so early points reflect any cuts since launch, which biases the analysis toward understating the collapse and toward dating it too early. The one cut I have corrected for is the largest recent one: OpenAI cut GPT-5.6 Luna’s prices by 80% on July 30, 2026, three weeks after its July 9 release (Terra was cut by 20% on the same day and Sol was unchanged). Since a price cut does not change the number of tokens a task uses, I reconstructed Luna’s launch cost per task by scaling the measured value by the price ratio, and in the records chart and table Luna’s records are dated to the cut, not to the release. This lengthens the measured halving times for the three lower tiers by a few days each. Other models may have had cuts I did not find, and a retired model’s last measured price may not be the one it launched at. Coverage is the second issue. Retired models are included only when their pages still carry the measurement, which recovered 44 of 228 retired models with prices and scores; the rest, o3, GPT-5.3 Codex, and everything from the GPT-4 era among them, are invisible, so the oldest frontiers rest on fewer models than actually existed and the true opening price of the lower tiers was likely set by models this analysis cannot see.

The retired models’ Intelligence Index scores are on the current scale, but the Index itself is one aggregate of many evaluations. And cost per task on an evaluation suite is a reasoning heavy workload with long prompts; a chat workload with short prompts and short answers would scale differently across models, particularly between reasoning and non-reasoning variants.

Predictions

Extrapolating measured rates is risky, since each collapse is a competition event and not a law, but the arcs have been regular enough to be worth putting numbers on. At the ≥ 60 tier’s current halving time of about 34 days, Grok 4.6’s $0.84 record falls below ten cents around the start of December. Index 55, which Grok 4.5 holds at $0.36 today, should cost under a dime by mid October. The ceiling is harder to call: it climbed twenty eight points over the year but only one point since June, which reads as saturation of the current index, not a slowdown in the models, so I expect the next milestone there to be an index revision, not a big number. And if the pattern of the last four tiers holds, whatever the revised index calls the frontier will debut at a few dollars per task and be commoditized within a quarter.

The Two Directions of Progress

The two directions of progress serve different kinds of work. A higher ceiling changes what is possible at all: the tasks that no model could do last year and one model can do now. A lower floor changes what is affordable at scale: the tasks that one model could already do, but not ten thousand times. The literature scan that motivated this post is a floor problem. The model only needs to read a paper and answer a well defined question, which models well below the current frontier handle reliably, but it needs to do that for every candidate paper, and the difference between $1 and $0.02 per paper is the difference between a pilot study and a complete census. Legal discovery, systematic reviews, large scale data curation, content moderation, and customer support triage have the same shape, and all of them get cheaper by an order of magnitude roughly every few months without any change in the work itself. The practical consequence is that the set of problems worth attempting with a model is expanding from both ends at once, and the expansion at the cheap end is the one that is easy to miss.

Cheaper Intelligence Means More Spending on It

A natural reading of these charts is that spending on LLMs should be falling. The opposite is happening. In 1865 William Stanley Jevons observed that more efficient steam engines, which needed less coal per unit of work, had increased Britain’s total coal consumption instead of reducing it, because cheaper work found far more uses. The same dynamic applies when the cost of a unit of intelligence falls by 30x. The work that was already being done gets cheaper, but the much larger effect is the work that was not being done at all because it did not clear the bar. This phenomenon became known as the Jevons paradox. Our literature scan is a small example: at last year’s prices it would have been run once on a sample, if at all, and at this year’s prices we run it on the whole corpus, repeat it when the pipeline changes, and are planning to run each positive result three times to reduce noise. The cost per paper fell by more than an order of magnitude and our total spend on the project went up. Demand for intelligence at a given price appears to be highly elastic, and as long as that holds, the falling frontier translates into more tokens consumed, not fewer dollars spent.

The motion of the frontier is more predictable than any individual release. Every capability tier so far has followed the same arc: premium debut, rapid commoditization, a settled record held by a distilled or open weights model at a few percent of the debut price. If a capability exists at any price today, the sensible planning assumption is that it will exist at commodity price within months. For system design, that argues for architectures where the model is a swappable component and the routing between capability tiers is explicit, because the tier boundaries themselves have not settled and show no sign of settling soon.

The model routers appearing on the market are a sign that this is being operationalized. OpenRouter now offers a router that takes a minimum capability score and sends each request to the cheapest model on the Artificial Analysis frontier that clears it, so that a system benefits from the moving frontier automatically, with no developer tracking it. Hardcoding a model name into an application has become the fastest way to overpay.

What Changes at 100x

If the pace of the last year holds, the capability that cost a dollar per task at the start of 2026 will cost a cent by the end of it, and the index 60 models that cost a few dollars per task today will be under a dime within a couple of quarters. I want to be careful not to overreach from a year of data, but a few consequences follow directly from the numbers.

Reading everything becomes the default. At a cent per document, a model can read every paper in a field, every record in an archive, every email, or every message in a support queue as a matter of routine, and the question shifts from which documents to look at to which questions to ask of all of them. Projects like our reuse census stop being projects and become monitoring: the scan can run on every new publication as it appears. Multi-pass workflows become the norm, since running a task three times and taking a consensus costs less than running it once did a few months earlier, and the accuracy gains from that are large. And the capability tiers themselves stop being a meaningful way to describe a system, because a pipeline will route each step to whatever level of intelligence it needs at whatever that level costs that week. The scarce resource in that world is not intelligence but the judgment about what to point it at, the ground truth to check it against, and the systems to run it at scale. Those are the parts of the work that are not getting cheaper.

Model metadata pulled from the Artificial Analysis free API, and measured cost per task scraped from the model pages on artificialanalysis.ai, on August 19, 2026. The figures are kept current on the LLM Cost Frontier dashboard. Corrections welcome.

TL;DR

Our Qwen3-TTS 1.7B CustomVoice implementation achieves 10 requests per second (RPS) and sub-50 ms p95 time-to-first-audio (TTFA) while maintaining real-time playback on a single NVIDIA H100 SXM.

Benchmark chart comparing p95 audible TTFA across serving engines as RPS increases

We compare five implementations: ours, vLLM-Omni, SGLang-Omni△, VoxServe, and M*, under Poisson open-loop traffic. After tuning each implementation for low-latency streaming, ours is the only one to achieve sub-50 ms p95 TTFA. We maintain sub-50 ms p95 TTFA through 10 RPS and keep it below 100 ms even at 20 RPS.

Our system produces approximately 630 characters per second at 10 RPS. At $4.29 per hour for a 1× H100 SXM instance, this translates to ~$2 per 1M characters at full utilization1. For comparison, ElevenLabs V3 is $100 / 1M and Cartesia Sonic 3.5 is $49 / 1M at a higher TTFA.

We open source the implementation and benchmark. Our methodology is explained below.

---

Defining “Real-time” TTS

Let’s start by discussing what a real-time TTS server needs to achieve. We think it’s a four-part problem:

1. Low Audible TTFA: Time from request dispatch to the first audible sample must be low.
2. Zero underruns: Once playback starts, the client must not run out of buffered audio.
3. Capacity: 1 and 2 must hold as RPS increases.
4. Non-malformed output: Speech must be intelligible.

We choose Qwen3-TTS CustomVoice 1.7B because it is one of the most popular TTS models with a permissive license.

Based on the above definition, we target low p95 audible TTFA with zero underruns while maintaining high RPS on a single NVIDIA H100 SXM.

All benchmarks run for five minutes under Poisson open-loop traffic to approximate real workloads, following Fireworks AI’s LLM benchmark. Each engine receives the complete text in a single HTTP request, while audio output remains streamed. We detect audible TTFA, reconstruct playback from received PCM, and evaluate the completed audio using Deepgram STT.

How Do Other Engines Perform?

The table below shows the upstream/default result at 1 RPS for each engine. We only apply changes for compatibility in this run.

Engine	p95 audible TTFA	p95 leading silence	Requests with underruns
vLLM-Omni	277.883 ms	90 ms	100%
SGLang-Omni△	1,140.69 ms	80 ms	0%
VoxServe	315.064 ms	30 ms	0%
M*	1,159.956 ms	90 ms	0%

These defaults have substantial room for improvement. We tune each serving engine for its own latency, continuity, quality, and capacity requirements.

1. Remove leading silence

The first PCM returned by a model can contain tens of milliseconds of silence before the first sustained sound. This gap pushes audible TTFA back like so:

Diagram of TTS latency terms: time to first byte, leading silence, and audible TTFA

We add a dynamic trim. It detects sustained speech from short RMS windows, removes samples before onset, and streams the remaining audio normally. This change improves TTFA by ~80ms but does not make model inference itself faster.

2. Tune frame accumulation

We also tune how many codec frames are collected before decoding and releasing an audio chunk.

Smaller initial chunks reduce TTFA, but provide less playback headroom and create more frequent decoder work. Larger chunks are easier to batch and make continuous playback safer, but delay the first audible output. A useful configuration therefore starts with a small chunk and increases the chunk size for later output.

The exact knobs differ by engine: vLLM-Omni exposes settings such as codec_chunk_frames and codec_chunk_ramp; the other engines provide equivalent chunk or stride controls. We iterate over these values to find the config that best matches: low p95 TTFA, zero underruns and stable behavior as load increases.

Performance after tuning existing serving engines

The following table shows the selected no-underrun profile for each engine after leading-silence and frame-accumulation tuning.

Engine	p95 TTFA (1 RPS)	p95 TTFA (6 RPS)
vLLM-Omni	56.815 ms	93.451 ms
SGLang-Omni△	120.879 ms	273.700 ms
VoxServe	49.3 ms	363.2 ms
M*	104.035 ms	179.501 ms

VoxServe reaches sub-50 ms p95 TTFA at 1 RPS, while the other three engines do not. By around 6 RPS, every engine is at roughly 100 ms p95 TTFA or higher2.

---

How We Optimized Qwen3-TTS

We first need to understand Qwen3-TTS architecture. It is a 3-part model performing hierarchical multi-codebook generation. The Talker predicts the first codebook token for each audio frame, the Code Predictor generates the remaining 15 codebook tokens, and the causal Codec converts codebook tokens into waveform samples.

Each module has its own compute profile, batching behavior, and latency requirements. Rather than optimizing each module in isolation, we focus on a broader question: how should a serving system coordinate these heterogeneous tasks?

1. Bringing three modules under one scheduler

Most Qwen3-TTS serving implementations are split into two stages: the Talker and Code Predictor run together, while the Codec runs separately. This separation enables token generation and waveform decoding to overlap across requests.

We take this a step further. We expose the Talker, Code Predictor, and Codec as three independently schedulable tasks. The key is not merely splitting them into parts, but bringing all three onto a shared scheduling surface managed by one scheduler. This design draws inspiration from M* (arXiv).

With this setup, the scheduler can decide whether to run the Talker, advance the Code Predictor, or prioritize a Codec job that is approaching its playback deadline. It can also batch requests waiting for the same module. Instead of following a fixed execution order, we can rearrange work according to urgency.

Combining the Talker and Code Predictor may appear more efficient because it removes an intermediate boundary. However, the combined operation can become a non-preemptible unit of work that blocks more urgent Code Predictor or Codec jobs. Keeping the modules separate creates shorter units of work and gives the scheduler more opportunities to interleave requests.

2. Scheduling around the needs of speech streaming

Speech streaming has two distinct notions of urgency.

Before the first chunk of audio arrives, every millisecond increases TTFA, so we need to prioritize this path. But once playback begins, the goal changes: the next chunk only needs to arrive before the current audio finishes playing. Producing it earlier provides no user-visible benefit.

Thus, we give high priority to requests that have not produced their first audio, while established streams become urgent only as they approach a playback deadline.

Running every urgent request alone would destroy batching efficiency. Instead, our scheduler selects an urgent request as an anchor and fills the rest of the batch with compatible work. This helps the critical request meet its deadline while making effective use of the GPU.

This policy works especially well because all three modules share a scheduling surface, allowing the scheduler to choose both the request and the pipeline stage to advance.

3. Exploiting the regular structure of the Code Predictor

The Code Predictor is an autoregressive transformer, but its execution is unusually regular. It always performs a fixed number of steps (15) per frame to fill the remaining audio codebooks.

We exploit its fixed structure to preallocate its KV cache and capture the entire frame-generation loop as a single CUDA graph. We also use a Triton attention kernel specialized for its short, bounded context.

By replacing a host-driven sequence with a fixed GPU program, we lower latency and simplify the execution system.

4. Rebuilding the Codec around cached state

The Qwen3-TTS Codec is made up of Transformers and CNNs. Generating the next audio chunk depends on both the Transformer context and convolutional state from previous chunks.

A naive implementation reprocesses the full frame history on every update, repeatedly decoding old audio as the utterance grows.

To avoid this, we use a state-cache-based Codec. Each request retains the Transformer context and convolutional state needed by the next chunk. Incremental decoding then reuses this cached state and processes only newly arrived frames instead of replaying the full history.

Initializing the state cache from the first frame adds overhead and hurts TTFA. We therefore use full decoding for the first audio, then switch to state-cached incremental decoding for efficient sustained playback.

We similarly vary chunk sizes over the course of a request. Smaller chunks let playback begin quickly, while larger chunks improve batching and GPU efficiency during sustained playback.

5. Additional serving optimizations

We capture CUDA graphs for a predefined set of batch sizes. If a ready cohort exceeds the largest captured batch size, we split it across scheduling turns rather than falling back to eager mode.

We also avoid unnecessary CPU–GPU synchronization. For example, while EOS is suppressed, generation cannot terminate, so we defer the termination check until EOS is enabled. This lets the CPU prepare and submit subsequent work without waiting for the GPU.

Finally, we support input streaming for modular speech-to-speech systems. As an upstream LLM generates tokens, the TTS model can begin synthesizing speech before receiving the complete response, reducing end-to-end latency.

What’s Next?

Qwen3-TTS is just the beginning of our work on multimodal inference. We plan to extend our scope to image, video, and world models, as well as fine-tuning. Our ultimate vision is to simulate the world 1:1 through realtime multimodal inference.

△ Upstream SGLang-Omni support was still incomplete at the time of testing in mid-August 2026. GitHub

1 This estimate excludes networking, idle capacity, and operational overhead.

2 Note that the only change we make outside the configuration file is leading silence trimming. Despite our effort, there might be a configuration that slightly edges out ours.

Cobalt is an open-source application platform for Kobo e-readers: a launcher, a signed App Store, a Rust SDK, and a runtime that keeps every app in its own unprivileged process.

Install it once over USB. Every app after that installs, updates and removes on the reader itself, over Wi-Fi. A reboot returns to the stock Kobo reader.

Install on your Kobo Read the source

The Cobalt launcher on a Kobo Clara BW showing Settings, App Store, Terminal, AI Chat, Audiobooks, Components, Daily Brief, Feeds and Gutenbird

The launcher on a Kobo Clara BW.

Not affiliated with Rakuten Kobo

A Kobo Clara BW running Audiobook Studio, Gutenbird, Terminal, Hacker News, Sidekick and the App Store, then installing, playing, removing and reinstalling Sudoku over Wi-Fi

Recorded on-device at 3× speed. Watch as video.

Running on a Kobo.

Every app is a static ARM binary running as its own unprivileged process on stock hardware. The App Store installs, updates and removes them over Wi-Fi, with signatures verified before anything launches.

arXiv papers and coding agents, on the panel.

These are photographs of the device, not simulator captures. The arXiv app reads the HTML rendering arXiv publishes for every paper since December 2023: abstracts, sections, math and result tables, paginated for the panel.

An arXiv preprint section titled 'A hard optimization problem and its relaxation' rendered on a Kobo Clara BW

A preprint, page 8 of 54, on the panel.

A results table from an arXiv paper comparing language models, rendered on a Kobo e-reader

A results table from the same paper.

Mathematical notation and a numbered algorithm from an arXiv paper on a Kobo e-reader

Math notation and a numbered algorithm.

Sidekick on a Kobo showing a question from Claude Code with three tappable answers and a 'Leave it for the terminal' button

Sidekick showing a question from Claude Code, with tappable answers.

Sidekick's watching screen on a Kobo, paired with a machine on the local network, showing the last answer sent

Sidekick paired over the local network, waiting for the next question.

The apps.

Every screenshot below is a capture from a Kobo Clara BW. Store apps version independently of the platform; the rest ship with the platform install.

Cobalt launcher app grid on e-ink

Launcher

Opens installed apps and always keeps a route back to the Kobo reader.

Cobalt App Store catalog listing installed and available apps

App Store

Installs, updates, removes and reinstalls signed apps over Wi-Fi.

Newest machine learning preprints listed in the arXiv app on a Kobo

arXiv

Browses a subject's newest preprints and reads the full text on the panel.

A complete 81-cell Sudoku game on a Kobo Clara BW

Sudoku

Store-only by design: installing it proves delivery of an app the USB package never contained.

The letter S filling the Kobo panel while the front light sends it in Morse

Morse

Sends a typed message in Morse on the front light, one letter across the whole panel.

An audiobook player with cover art, position and transport controls on e-ink

Audiobook Studio

Researches, writes, narrates and plays an original audiobook.

A shelf of book covers from an OPDS catalogue on a Kobo

Gutenbird

Reads any OPDS library: Project Gutenberg, Standard Ebooks, Open Library, or yours.

A ranked list of Hacker News stories on a Kobo e-reader

Hacker News

Top, New, Ask and Show stories with complete comment threads.

Subscribed feeds and articles in the Feeds app

Feeds

Discovers a site's feed and presents its articles without the site's layout.

A numbered daily news brief on e-ink

Daily Brief

Collects the day's stories in the background while you use another app.

An AI answer displayed as readable text on the Kobo panel

AI Command Center

Asks a question and turns the answer into touch-friendly reading.

A coding agent request with tappable responses in Sidekick

Sidekick

Approve or deny requests from coding agents, away from the keyboard.

A shell and touch keyboard on the Kobo display

Terminal

A panel-native shell with keys that send input immediately.

Cobalt typography and UI components on e-ink

Components

The UI toolkit's controls, layouts, typography and states, on the panel.

Battery status and hardware facts in Settings

Settings

Connectivity, hardware, and platform updates, kept separate from Store.

A persistent to-do list with completed items

Todo

A persistent list with touch entry and completed-item states.

A completed game of tic-tac-toe on e-ink

Tic-tac-toe

Two players, partial refreshes for individual cells.

The Kobo hall sensor responding to a magnet

Magnet

Locates the hall sensor behind the bezel and reports its changes.

An app is one Rust file.

Implement KoboApp, describe screens declaratively, and the runtime handles layout, e-ink refresh planning, Back navigation and lifecycle.

Apps don't open device resources; they ask. Network, storage, audio, frontlight and Wi-Fi are capability-gated, and a refusal comes back as a value the app can handle.

E-ink UI

Text, tiles, dialogs, keyboards, pagination, partial refresh planning

Simulators

Browser and runtime simulators with layout diagnostics

Async work

HTTPS, ranged downloads, cancellable tasks, scheduled wakes

State

Atomic per-app keyed storage

Shipping

Signed static ARMv7 binaries, published when an app PR merges

kobo new my-app
cd my-app
kobo dev

Read the SDK docs

use kobo_sdk::{
    ActionId, Context, KoboApp, ScreenBuilder,
};

#[derive(Default)]
struct Hello { taps: u32 }

impl KoboApp for Hello {
    fn on_start(&mut self, ctx: &mut Context) {
        self.show(ctx);
    }

    fn on_action(
        &mut self, ctx: &mut Context, a: ActionId,
    ) {
        if a == kobo_sdk::action_id("tap") {
            self.taps += 1;
        }
        self.show(ctx);
    }
}

impl Hello {
    fn show(&self, ctx: &mut Context) {
        let screen = ScreenBuilder::new("hello")
            .top_bar("Hello")
            .heading(format!("{} taps", self.taps))
            .button("tap", "Tap me")
            .build();
        ctx.set_screen(screen);
    }
}

fn main() {
    let app = Hello::default();
    let _ = kobo_sdk::run("hello", app);
}

Signed packages, verified before launch.

Store reads a signed catalog from a fixed GitHub release. Each package holds one ARM executable and a signed canonical manifest. The runtime verifies the catalog, the package, the installed manifest and the binary before an app runs.

App releases are independent of platform releases: merging an app PR builds it for ARM, signs it, and updates the catalog. No Cobalt version bump, no reinstall. The app simply appears in Store.

The Cobalt platform itself also updates over Wi-Fi, through Settings, on a channel separate from the app catalog. The USB cable is only ever needed once.

Install and catalog transactions are recovery-safe; an interrupted update leaves the reader with the version it had.

Publish your own app →

The Cobalt App Store installing an app over Wi-Fi on a Kobo Clara BW

Sudoku arriving over Wi-Fi.

Installing from source.

1. Charge a Kobo Clara BW (N365) and connect it over USB. Other models are refused, not guessed at.
2. Run the setup:

git clone https://github.com/BandarLabs/Cobalt.git
cd Cobalt
rustup target add armv7-unknown-linux-musleabihf
cargo run -p kobo-cli -- setup

3. Restart the reader and open Cobalt from Kobo's menu.
4. Open Store. Everything from here on arrives over Wi-Fi.

The complete walkthrough, including recovery steps, is in docs/INSTALL.md.

Contribute an app.

App contributions are regular pull requests. If it runs on your device and the PR shows it running, it gets merged and published.

1. Build it. Add the app as a workspace package under apps/<app-id>/ and register it in apps/catalog.json.
2. Test it. Add unit and layout tests, and run it in the browser and runtime simulators.
3. Run it on your own device. A real Clara BW, not just the simulator.
4. Open a PR with a gif or photos of it running. Once reviewed and merged, the publish workflow signs it and it appears in Store. No platform release needed.

Own a different Kobo model? Porting is welcome too; open an issue first so the device profile can be agreed. Full details in docs/CONTRIBUTING_APPS.md.

Device support and safety.

Cobalt does not replace Kobo's boot chain. Device writes are gated on an exact hardware and firmware match, and a reboot returns to the stock reader. The first installation does modify files on the user storage partition, and it is provided without warranty.

Only the Clara BW profile has been hardware-tested. Don't install on another model until it has a reviewed, hardware-tested profile. Cobalt is an independent project, not affiliated with Rakuten Kobo.

There's a version of computing history where the desktop OS that won wasn't Windows. Not because the alternative was Unix-based or because Apple pulled off something different, but because an operating system designed at the University of Tokyo in 1984 was ambitious enough to try to replace the file system with a hypermedia document model, run on a custom Japanese CPU architecture, and encode 1.5 million characters, only to have a US trade report single it out as an unfair trade barrier in 1989.

That project was TRON (The Real-time Operating system Nucleus), a real, government-backed Japanese computing initiative whose desktop variant, BTRON, was named in a US trade barrier report and effectively killed before it could reach schools nationwide. Meanwhile, its embedded counterpart, ITRON, quietly became one of the most deployed operating systems in history.

TRON's history has since attracted some genuinely wild conspiracy theories, including one claiming that Japan Airlines Flight 123 was deliberately crashed in order to target the TRON developers on board, despite there being no evidence that any TRON developers were even on the flight. But the strangest part of the story isn't even a conspiracy theory: BTRON's hypermedia desktop was decades ahead of what the market could support, and SoftBank founder Masayoshi Son may have helped sink it from the inside.

Ken Sakamura designed an OS family for the whole of Japanese society

He wanted all of it, silicon included

Ken Sakamura was a researcher at the University of Tokyo when he launched the TRON Project in 1984. It was an ambitious undertaking; he wanted a vertically integrated computing architecture that Japan could build its entire digital infrastructure on, from the microcontroller in a washing machine to the workstation on a desk to the telecom switch in a central office. The project had five sub-architectures: ITRON for embedded real-time systems, BTRON for personal computers, CTRON for mainframes and telecom switching, MTRON for cross-system coordination, and STRON, a hardware implementation of the real-time kernel.

The project designed its own CPU architecture, the TRON VLSI CPU, which Hitachi manufactured as the Gmicro/200 series. Hitachi actually produced and sold it, and it ended up powering some Japanese workstations and embedded systems throughout the late 1980s. Sakamura's team also drew up its own TRON keyboard layout, designed for efficient Japanese text input alongside programming symbols, and a real-time peripheral bus called micro-BTRON, based on IEEE 802.5 and intended as an alternative to MIDI for connecting "electronic stationery" peripherals, though that bus never shipped in a commercial product. The idea was that every layer, from silicon to user interface, would be designed together, with no compatibility debt to existing platforms.

The character encoding system, TRON Code, was arguably the most ambitious part. It supported multi-plane character switching via 0xFE escape codes, with 31 defined planes of 48,400 characters each, giving a theoretical capacity of 1,500,400 characters. By 1999, B-right/V R2 shipped with roughly 130,000 characters across 14 defined planes, covering JIS levels 1 and 2, Chinese GB 2312, Korean KS C 5601, Unicode's non-CJK range, and the Mojikyo collection of rare historical characters, and users could register new characters for free through the TRON Character Resource Center. To put that in perspective, Unicode 1.0 in 1991 defined 20,902 unified CJK ideographs, and TRON's CJK coverage exceeded Unicode's for well over a decade. A large part of that count came from Mojikyo, though, which separately encodes variant glyphs that Unicode unifies into single code points.

You can see the ambition from the very beginning, as the 1996 demo release includes a character-code viewer that lists its planes side by side: Japanese basic, Japanese supplementary, Chinese GB, Korean KSC, and 6-dot Braille. Braille is there as a first-class plane rather than an accessibility add-on bolted on later, and Unicode didn't encode Braille patterns at all until version 3.0 in 1999. For its time TRON Code was the best answer anyone had to a problem the rest of the industry was years from solving.

The project was backed by an actual organization: the TRON Association, established in 1986. Its members included Hitachi, Mitsubishi, Fujitsu, NEC, Matsushita, and Toshiba... basically every major Japanese electronics company of the era. On top of those domestic companies, foreign companies could join too, and several did. TRON was royalty-free and its specifications were open, which was a deliberate choice that would later allow ITRON to spread. The Japanese government, through MITI, supported the project as a national technology strategy, giving it the kind of institutional backing that most operating system projects could only dream of.

On top of all this, BTRON proposed something radical for desktops.

BTRON's desktop was decades ahead of where computing actually went

The file and the application were implementation details

09-jis-level1-table-2133x1200

BTRON's core idea was that the user-visible primitive on a desktop computer shouldn't be a file or the application, but the typed document part. In other words, a block of content with a stable identity and a declared type. Parts can contain other parts, and the same mechanisms that embed a figure in a report can also embed a report in a workspace, meaning that there was no special case for a top-level file.

This model could be found across the interface as well, and you can browse a container in 1B/V3 and see each entry carries its type in parentheses after the name. For example, a document called 中国・韓国料理ガイド（図形）, meaning "Chinese and Korean Cuisine Guide (Graphics)", describes this file as an image. In comparison, DOS would have given you an extension.

Parts were connected by typed links, stored in a system-managed link store rather than fragile string paths. Links survived renames, edits, and reorganizations, and applications weren't owners of files but handlers for part types. According to the BTRON3 specification, the first two halfwords of an application ID are the data type it applies to, and only the third distinguishes rival handlers for the same type. When a document contained writing, a table, and a figure, opening those parts made the system launch each one's registered handler to draw its own content inside the parent document's window. If no handler exists, or the handler fails to draw, the system strikes a diagonal line through the region where the content should have been.

BTRON's document model, showing real and pseudo bodies

BTRON also used a file system model called real-body/pseudo-body, which replaced the tree-structured directory hierarchy with an arbitrary directed graph. Files can exist in multiple locations without duplication, linked by the system rather than by symlinks or shortcuts, and the dictionary that powers Japanese text input is addressed the same way a cooking guide would be. Here, the TRON Application Databus format carries structured data between applications using a chunked segment structure with a common header, so a spreadsheet cell and a paragraph of text could be composed into the same document without the user ever having to think about file formats. Applications can skip data types they don't support, making interoperability a core aspect of the system.

Arguably, this is the same concept that tools like Roam, Logseq, and Obsidian have been rediscovering over the last decade. But BTRON proposed it as the fundamental OS abstraction in the mid-1980s, paired with a custom CPU and a real-time microkernel underneath. It's not that BTRON's implementation would feel smooth by modern standards, because the hardware it ran on was too slow for that, but the architecture was doing something conceptually different from anything that shipped commercially in the West at the time.

06-microscript-figure-2133x1200

1B/V3 comes with a number of sample documents that show exactly this concept. One demonstration is a Microscript figure, which is a drawing canvas holding a green ball and a sloped surface, each a named object, with a text section dubbed SCRIPT in the same space. You can open the script and see "DEFINE 半径（ボール．W／2）", defining a radius as half the ball's width, then "SET 新Y ボール．Y+半径+速度Y／4" which advances the ball's position on each step. The script addresses the figure's contents as "ボール．X" and "斜面．W", meaning object and property, and the entire file is a single document rather than a program loading data files. Sure, a bouncing-ball simulation is a small thing to build, but the point is that it's a typed part inside the document instead of a dedicated application that owns it.

BTRON was made available in a small number of products in Japan: for example, the BrainPad TiPO PDA from Seiko Instruments had a version with a touchscreen and stylus. As well, B-right/V (also called Cho-Kanji) was available on commodity PC hardware through Personal Media Corporation, a company that still lists the software on its Japanese-language website today. This is 1B/V3, and I got the demo disk working in 86Box on an Apple Silicon Mac. All it needs, at minimum, is a mid-90s Pentium clone with 16MB of RAM and a Cirrus Logic video card.

Unfortunately, BTRON never got the distribution it needed, and by 1989 it had a much bigger problem than adoption.

The US government named TRON in a trade barrier report

Buried in Section 7

us-government-tron-operating-system-concerns

In April 1989, the Office of the US Trade Representative published its annual National Trade Estimate Report on Foreign Trade Barriers. Buried in Section 7, "Other Barriers," was a section about TRON. The report stated that the US had concerns about Japanese government market intervention to support the TRON OS and identified two specific markets where TRON was receiving government advantage.

The first advantage it was deemed to be benefiting from was in the industry of educational PCs. The Japanese Ministry of Education and MITI were developing a standard specification for computers being introduced into middle schools nationwide, and the specification was built around TRON. The second was NTT's next-generation digital communications network, which planned to adopt CTRON, the telecom variant. The report noted that while several US companies were members of the TRON Association, none were in a position to sell TRON-based products in either market.

The NTE report was an annual survey of foreign trade barriers, and it wasn't a sanctions list. The more aggressive Super 301 process, established by the 1988 Trade Act, was a separate mechanism that could escalate a dispute into investigation and negotiation, and TRON was never designated a Super 301 priority. The actual Japan designations that year were supercomputers, satellites, and forest products, as Carla Hills' May 25 statement confirms. No sanctions were ever applied to TRON, but it was clear that the US government had been spooked for some reason by the TRON project.

In fact, Ken Sakamura was surprised that it had been named at all. In an interview with Japan's Yomiuri Shimbun published in August 2026, he said: "TRON is open to the world, and American companies can use it freely. Why would it become a target of trade friction? I had no idea what was going on."

The TRON Association sent a written protest to the US government, and the US sent an inspection team to investigate as a result. By Sakamura's account, the matter was closed over a dinner where the USTR told him "On investigation, it turned out that BTRON is no harm. We are sorry for causing troubles to you if any." Unfortunately, by June 1989, the school adoption was dead.

Even though the legal reality was that TRON's naming in the survey was resolved, that mattered less than the reputational hit it took as a result. Japanese manufacturers interpreted the dispute as a signal that TRON had angered the US government, and staying associated with it could threaten their American business. Companies withdrew from TRON PC development left and right, and Yomiuri quotes an industry source describing the outcome bluntly: "TRON itself was never denied, but it became an OS with a blemish from America. We can't use it."

Funnily enough, the USTR's complaint had some validity to it. After all, the objection to TRON didn't come from it being closed off or exclusionary, but that the Japanese government was steering its procurement of two huge markets toward a domestic standard. This had the effect of excluding foreign vendors regardless of whether TRON's spec was open or not. However, what happened after, namely the reputational damage, is a lot harder to justify.

There's another side to this story, though, and it reframes things a little bit. In a book from Scott Callon in 1995, "Divided Sun: MITI and the Breakdown of Japanese High-Tech Industrial Policy," he argues that BTRON was already struggling with internal coordination problems and delayed hardware before the trade dispute, which made the controversy a convenient way to exit the market. An academic paper published in 2003, titled "Three Attempts at De-Wintelization," frames this dispute as just another event in a longer pattern of Japanese efforts to challenge the Wintel monopoly, each of which failed for a combination of political and structural reasons.

Even still, Matsushita Communication Industrial shipped the PanaCAL ET in 1990, which was a BTRON educational PC, but the momentum was well and truly gone at this stage. But there was another factor too, one that Sakamura himself would later describe as the real cause of the damage.

SoftBank's founder may have weaponized the report against BTRON

He published a book called 'The Tron Revolution' first

sakamura-son-accusation Credit: TRON 30 year anniversary page

There's a book from Japanese reporter Eiji Oshita, written in 1999 as a biography about Masayoshi Son. In the book, titled "Masayoshi Son: The Young Lion of Entrepreneurship," Oshita writes that Son had a direct incentive to sabotage the TRON project. Oshita states that Son was building a software distribution business around importing American PC software, and if TRON-based, Windows-incompatible PCs became the standard in Japanese schools (which was a captive market), then his business model would take a serious hit.

Oshita's biography further describes Son lobbying MITI officials, politicians, and business leaders to oppose TRON's adoption, arguing that TRON would isolate Japan from global computing standards. The TRON Association published an editorial in its own TRONWARE magazine in December 1999 titled "People who blocked the TRON project," which stated that "the person who destroyed BTRON using the USTR was not an American company, but a Japanese person."

Stranger still, the strongest corroboration of this allegation comes from Ken Sakamura himself. On the official TRON Project 30th Anniversary website, published sometime in 2014, Sakamura wrote a section called "An Unexpected Ending" that directly names Son. He describes how the Oshita biography details Son mobilizing every connection he had to oppose BTRON, and in Sakamura's own words: "I have to admit I was impressed by his thoroughness."

Son's SoftBank publishing division had published a book called "The Tron Revolution" in December 1988, four months before the USTR report that named TRON as a trade barrier.

All of this is from machine translations of Oshita's biography, the TRON project anniversary site, and other sources that appear to have never been published in English. It's important to know that the Yomiuri series approaches this claim far more apprehensively than Sakamura does: It says that "there was talk that Son opposed TRON," rather than outright accusing him of it. We don't know for sure if Son killed BTRON, but it's hard to dismiss Sakamura's own words as merely a rumor.

Sakamura goes further as well when he accuses Son, stating that Son used the US trade process as his way of sabotaging the project. He said that the person who destroyed BTRON did so "through what was essentially reputational damage leveraging the USTR," which isn't necessarily a claim that Son manufactured the NTE report, just that he exploited its existence. This particular detail, amongst many others, I couldn't find translated to English anywhere else, and it comes from someone who was essentially the father of the entire project.

To be fair to Sakamura as well, it actually lines up well with what happened, and explains several aspects of it. It certainly makes more sense than a claim that Son's lobbying and the US complaint were totally unrelated.

The embedded variant nobody noticed is in billions of devices

ITRON survived and became valuable infrastructure

Installing Java on Windows

While BTRON was dying, it was ITRON that was quietly spreading around the world. As an embedded real-time operating system, it didn't need a monitor, a keyboard, or a 1.5-million-character encoding space. All it needed was to be small, deterministic, and royalty-free, which it was. Remember the Java installer saying "3 billion devices run Java"? Yeah, we'll get to that in a second.

ITRON, and later T-Kernel, shipped in digital cameras, car engine control units, mobile phones, factory automation equipment, and home appliances. Casio's QV-10, the camera widely credited with sparking the digital camera revolution, ran on TRON, and Toyota even used it in engine control systems. On top of that, many first wave Japanese mobile phones ran on it too. In fact, this LinuxInsider article from 2003 calls ITRON "the most popular operating system in the world," and while nobody has published hard numbers since, the Yomiuri series reported that TRON-based operating systems still run in roughly 60% of the world's embedded devices.

TRON even got its own Java specification in the late 1990s, and it combined ITRON's real-time kernel with Sun's Java Runtime Environment. Commercial applications such as Aplix's JBlend came after, and Aplix says that JBlend shipped on more than 800 million devices. Not all 800 million of those were JTRON devices, since JBlend later became a portable Java platform that Aplix deployed across multiple operating systems, and there's no published breakdown of how many ran on ITRON. But it does mean that when that old Java installer proudly told you "3 billion devices run Java," some unknown number of those devices were almost certainly running Java alongside TRON.

A standardization effort has since cemented its longevity. In 2018, micro-T-Kernel 2.0 was adopted as IEEE standard 2050-2018, and in 2023, the IEEE recognized the TRON Real-time Operating System Family as an official Milestone, installing a plaque at the University of Tokyo. The TRON Forum, the successor to the original Association, still maintains the specifications and licenses the technology. Even more interesting is that, by Sakamura's account, Microsoft joined the TRON Project in 2003, through the efforts of its then-US vice president Furukawa. Microsoft really does seem to have a habit of supporting would-be competitors these days.

Unsurprisingly, the ambitious and politically targeted desktop variant failed. But it was the embedded variant nobody in the West paid attention to that managed to succeed to the point of becoming an important building block of day-to-day infrastructure. The same project produced what could well be the world's most-used operating system and an operating system that failed entirely, and it was the project that everyone was paying attention to that actually failed. You can still buy a BTRON implementation today if you know where to look, since Personal Media Corporation's website is still up and still selling Cho-Kanji, in Japanese only. The project's lasting mark on computing is invisible, though, running in the devices around you that you never think about as having an operating system at all.

Sakamura received the Takeda Prize jointly with Linus Torvalds and Richard Stallman, for spreading open architecture worldwide. After all, the same open approach that made TRON vulnerable in a trade dispute, the assumption that being open was protection enough, is what let ITRON spread without friction afterwards. Sakamura's apology, though, arrived after the damage had been done over dinner in 1989. The industry had already abandoned the project by that stage.

BTRON's hypermedia ideas are being rediscovered by a new generation of tools that don't know they're recreating a 40-year-old design. The character encoding is archived and the CPU is a museum piece. But the real-time kernel that nobody seemed to think of as an important piece of the puzzle still runs in places you'd never guess, and it's hard to think of a better legacy than that.

When Microprose greenlit Sid Meier's Pirates! in 1986, the company—which Meier founded along with Bill Stealey back in 1982—was mostly known for vehicle sims (Gunship, Spitfire Ace, F-15 Strike Eagle) and dry strategic wargames like Crusade in Europe.

Pirates was something different. It's hard to pin it down to a genre even today, but it certainly wasn't like previous Meier titles—even though it's the first game to be called Sid Meier's Something or Other. At the time the game came out in 1987, it was generally called an "action adventure" game; this is somewhat hard to square with the way most people today would understand the genre. It has basically nothing in common with contemporaries like Castlevania, Metroid, or The Legend of Zelda.

There's no platforming of any kind; controlling the player character directly and individually is restricted to brief sword-fighting sequences. Those have controls and mechanics that are totally unlike any other game combat I've seen. It tries to create the feeling of an Errol Flynn fencing duel with an elaborate control scheme that's more like a mutant version of a fighting game; you can thrust (which is fast) or slash (which does more damage), or parry; you can also either aim low, or high, or down the middle.

Those motions are mapped to the eight-direction joystick commonly used for games on the Commodore 64 and other eighties computers—or, if you don't have one of those, they're mapped to the keyboard numpad. Some ports of the game let you do it with the mouse, or with awkward combinations of mouse clicks and keyboard input.

This description makes the swordfighting in Pirates sound terrible and indeed it is hard to defend; the 2004 remake substantially simplified it, but that simplification only peels away its skin to reveal a strange quasi-rhythm game buried underneath. It still feels in no way like a concession to "standard" combat design.

But what you have to understand about playing this game—whether the original 1987 version, the many 1988 ports, the beautiful 1993 remaster Pirates! Gold with its 256-color graphics, or the modernized 2004 remake—is that if you encounter it at an early age it will open a rift in your brain. When I asked Nic Tringali (designer of The Banished Vault and Amberspire) about it, they put it perfectly: "Pirates! feels unstuck in genre, not quite an open-world game or a role-playing game, not only economic strategy or resource management. It has a goal for a clear thematic position for the player to inhabit and uses the systems and friction to reach that. The peculiarities of its design are unique and inseparable—the wind always blowing east comes to mind, and dueling a rival captain immediately winning a sea battle—and are not solely driven by video game genre expectations, or pre-packaged ideas redressed in a pirate theme."

Meier was working in an era where genre and mechanics were still unsettled, undefined things. In his 2020 memoir—would you believe it's called Sid Meier's Memoir!—Meier pointed out that "The good news was there were very few preconceived notions back then about what a game was supposed to be. The bad news was there were no tried-and-true conventions, either." All of Pirates is like this; a bunch of first-principles attempts at extricating game mechanics from all the half-remembered pirate tropes rattling inside Meier's brain.

The resulting game takes all these romanticized ideas pointing towards a genre—Treasure Island, Errol Flynn movies, Peter Pan, the centuries-old distillation of the Black Legend into anglophone culture—and treats them not as story beats to play out or as window dressing, but as the grounding rules of a clockwork world that you can poke and prod at. The game models the way silver travels on mule trains all the way from Potosí to be loaded up on ships in Panama, and from there along the ports of Gran Colombia until the Treasure Fleet, heavy with the blood of the Americas, leaves for Spain. The game models the way that a pirate's harsh life wears you down over time, each merchant ship captain or colonial guard that you fight seeming that little bit faster until you have to admit that your sword arm just isn't what it used to be. The game seeds the Caribbean with an elaborate, randomized quest to find your long-lost family, chasing down a laundry list of villainous aristocrats to rescue relative after relative from indentured servitude on obscure plantations.

To modern design sensibilities, I think there's a risk one might look at Pirates and see a bunch of minigames in a trenchcoat. In reality, what that game is expressing is a way of thinking about games that we've tamped down over the years as the medium has built up its own library of conventions, tropes, and recycled ideas.

Pirates is hewn from its underlying themes in a very raw way, but so are many other games of this era. Cinemaware, a now largely forgotten studio, made a whole very successful business out of this style of design. Their 1989 title, It Came from the Desert, gleefully jumps around in presentation and perspective—one moment a rudimentary first-person shooting gallery, the next a top-down shmup, all wrapped up in a visual novel wearing the skin of a strategy game. The original Dune video game—not Dune II, the origin point of real-time strategy as we know it—was essentially an attempt at capturing the whole scope of the 1984 David Lynch movie, oscillating between a strategy game about spice extraction and a visual novel-like adaptation of the movie's plot.

Pirates was immensely successful in its own time, and this exact style of design thinking was then adapted to Microprose's follow-ups—classics like Covert Action and Sword of the Samurai. Pirates essentially changed the studio's whole identity, something that was incredibly hard to do even in those days.

And yet, this entire era of video games feels like a hole that has been carved out of the collective memory of the medium. It is, in truth, a reflection of how niche the computer game market really was in those days; for every Amiga 500 sold, Nintendo sold 23 NESs and 45 Game Boys. The era of IBM PC consolidation and true mass adoption of PC gaming was a few years away in the late 1980s; and by the time the remade DOS version of Pirates arrived in 1993, it was competing with platform-defining games like Wolfenstein 3D. This 1982-1990 era of PC gaming is, really, better known through dubious CDs packed in with magazines, discount-bin collections put out by failing publishers, and abandonware sites.

Don’t let the absence of a flying car in your garage distract you: we are definitely now living in a version of the future out of J.G. Ballard or William Gibson.

Every day I notice a news story that startles or alarms me, that feels like pure cyberpunk, nestled between reports about council bin collections and cabinet reshuffles.

“The first ever IV Drip clinic to appear in the centre of a shopping mall, our Westfield clinic is a must-stop shop when doing a bit of retail therapy. From Vitamin Drips to Instant Vitamin D Testing, Get A Drip Westfield has it all. Book your appointment today!”

Publicity for Get A Drip Limited

This made me think of Michael Moorcock’s habit of opening stories or chapters with startling newspaper clippings that revealed the future apocalypse already underway in the present, or Ballard’s typographic collages. So I began snipping.

“A video has been shared on social media with claims it shows a robotic dog patrolling the grounds of a ‘migrant hotel’. But this is false – while the footage does appear to show a robotic dog, it was filmed in the grounds of a building housing a religious group in Crewe.”

Full Fact, 4 November 2025

It’s not quite Blade Runner but it might be Robot Jox or Bubblegum Crisis.

“Soul ‘musician’ Sienna Rose has made headlines this week as suspicions mount that her music is a product of artificial intelligence… On Spotify, her sound is described as a blend of the ‘elegance of classic soul with vulnerability of modern R&B’, while she is simply referred to as ‘an anonymous neo-soul singer’. Many fans have taken note of the reference to her anonymity, which makes her 2.6million monthly listeners all the more staggering.”

NME, 17 January 2026

In the middle of a video about stationery and everyday tech on YouTube the other day there was a passing shot of two robots kickboxing in a cage; another robot was taking coffee orders at a kiosk. This was (blandly) “cool to see”.

“British police have helped seize a record nine-tonne haul of cocaine from a ‘narco sub’ in the Atlantic Ocean… The mammoth seizure weighed nearly as much as a school bus and the sub was 230 nautical miles from the Azores when it was intercepted… The semi-submersible eventually sank before authorities could take all its cargo, sending 35 of the 300 packages to the bottom of the Atlantic.”

Sky News, 27 January 2026

What the visionaries got wrong, it turns out, was what would go digital. Did anybody bet on cigarettes? Or scooters? Or that neon would be replaced by LEDs?

“A humanoid robot named Edward Warchocki chased away a herd of wild boars in Warsaw, shouting ‘Go away!’ in Polish as the animals fled into the forest, in video footage released on Sunday…”

Reuters, 14 April 2026

My personal moment of future shock came when a delivery robot trundled past me on Gloucester Road in Bristol, weaving between Saturday afternoon drunks and stoners, some of whom chased it and blocked its way.

“Four child-sized humanoid robots take the stage at an arena in eastern Seoul, and as the opening beats of a song by K-pop star G-Dragon begin, they start to dance… Arms swinging, legs stepping in sync, heads bobbing, wigs and baggy clothes swishing, until – mid-performance – one of them seemingly malfunctions and has to be removed from the stage… Welcome to Galaxy Robot Park, a new 16,500 square metre facility in Gangdong district that its creators claim is the world’s first robot theme park.”

The Guardian, 25 May 2026

More often, the shock is that there is no shock. My mum uses the voice-activated computer in her house to remind herself to take the sprouts off the boil.

“[Shania] Collins had enjoyed modest success as a sprinter, with contracts from Puma and Adidas. But by 2024, with her career stalled and earnings shrunk, she retired at 29 to begin a long screening process to follow her parents into working for the [Drug Enforcement Agency]… Then organizers of the Enhanced Games, a controversial sports startup, got in touch last fall with an offer. The organizers were planning a one-day competition of sprinting, swimming and weightlifting in Las Vegas that would not only allow but encourage doping. And it paid the kind of money that might take some athletes years to make — six-figure salaries, on top of prize money of up to $250,000 for event winners and $1 million for a world record.”

NBC News, 26 May 2026

All of this technological advancement, apparently utterly mundane and running in the backgrounds of our lives, is accompanied by a sense of apocalyptic weirdness both in the climate and the culture.

“Meta has quietly embedded face-recognition technology for its smart glasses into an app downloaded to millions of phones… Code discreetly added to Meta’s AI app over multiple updates this year shows that the feature, internally called ‘NameTag’, identifies people captured by the glasses’ camera and, when activated, alerts the wearer when it recognizes someone.”

Wired, 4 June 2026

Blade Runner had its acid rain. We have wildfires taking out suburban housing estates in the English Midlands and heat buckling railway tracks.

“Two arrests have been made during a police operation using drone technology to target anti-social driving… Dorset Police said its operation on 29 May was in direct response to concerns raised by people living in Sandbanks, Poole… A police drone was deployed over the area to give a higher vantage point to spot any offences of poor driving, allowing officers to then intercept motorists on the ground, said Dorset Police.”

BBC, 6 June 2026

My brother, a data scientist, told me yesterday that it is now possible to prompt a large language model (LLM) to produce a three-dimensional digital model which you can then realise with a 3D printer. It’s not quite “Tea, Earl Grey, hot,” but it’s alarmingly close.

“While spending money on video games is not uncommon, EVE Online stands out because players’ assets can be permanently destroyed; their real-world cash outlay gone in seconds… The game’s financial system is so complex that in 2025, a former economist from the Central Bank of Iceland was hired to oversee it… Playing EVE Online can take hundreds of hours. Some see it as a second job, dedicating up to 35 hours per week to their virtual duties on top of their real-world nine-to-fives.”

BBC, 6 June 2026

At work, people send AI bots to attend meetings for them and it’s no more than an annoyance – a question of etiquette. If you’d told me this was possible when I was reading Neuromancer as a teenager in a concrete council house I’d have been awestruck.

“Stranger Than Heaven is an action-adventure game that spans fifty years… On Friday evening… Snoop Dogg took to the stage of Summer Game Fest to confirm Tupac’s involvement in Stranger Than Heaven as Amaru, which was the late rapper’s middle name. ‘The Tupac estate and my son and myself, we work very closely together,’ Snoop explained. ‘So it just made sense to put him in this game, because his likeness and his spirit still lives on. I just felt like it was so connected to what we’re doing.’

NME, 8 June 2026

Another moment of future shock was when a former colleague posted on LinkedIn about his first ride in a self-driving taxi in San Francisco. It was a novelty, sure, but mostly just a fun story he could use to liven up his feed. Most people didn’t comment, they just gave it a weak “thumbs up”.

“During mealtimes, Vincent Zhang, a tech worker in Shanghai, has a habit of whipping out his phone to check on his ‘virtual parents’: a middle-aged couple online, armed with an endless stream of warm words for their imaginary child… In one of their most popular videos, the pair coos to the camera. ‘Are you tired from work and study lately? Don’t push yourself too hard. Mum and Dad know that you have endured a lot.’ … In the comments, many call the couple mum and dad, telling them about their lives and asking for birthday blessings.”

BBC, 13 June 2026

There are AI-generated posters in my local pub. My local supermarkets have signs warning shoppers that they’re using facial-recognition technology. It doesn’t feel like science fiction because everything surrounding it is so ordinary: facial recognition scanners; two for one on Doritos; images conjured from a prompt; pool, 50p a game, and roast potatoes on the bar on Sunday afternoon.

“AI-generated photos and videos featuring Russian soldiers have gained popularity on social media since mid-2025. They are most often posted by relatives of Russian servicemen fighting in Ukraine… The quality varies. In some videos, the AI generates figures without limbs or produces grotesquely distorted faces.”

BBC, 14 June 2026

How do you write science fiction in this context? Anything you come up with will seem farfetched, until it actually happens three weeks later and nobody bats an eyelid.

“US President Donald Trump celebrated his 80th and America’s 250th birthday with an Ultimate Fighting Championship (UFC) event on the White House lawn… Trump and thousands of other mixed martial arts fans watched on as American fighter Justin Gaethje beat Spanish-Georgian opponent Ilia Topuria to win the lightweight championship in the main event.”

BBC, 14 June 2026

When Moorcock and Ballard repurposed contemporary newspaper clippings they were saying, stop, look – can you believe this shit? But does stopping and looking actually help?

“The alt-pop US musician and internet personality Oliver Tree was among six people who died when the helicopter he was travelling in collided with another in Brazil… The 32-year-old had been on a world tour when the crash occurred over Rio de Janeiro on Sunday. One of the helicopters then fell onto the car park of a dealership, setting around 20 vehicles ablaze… With his distinctive bowl haircut, he was known for hits including Life Goes On, Miss You and Alien Boy.”

BBC, 15 June 2026

The human ability to resist stopping, to look away, to adjust to a new reality, absorb changes, and move on, is extremely useful.

“Banks say that criminals are engaging in more sophisticated fraud at greater volume with the use of artificial intelligence (AI)… Criminals have used AI to mimic the voices of celebrities, and even those of the victims’ family and friends, which has enabled them to carry out the crime at a greater scale.”

BBC, 15 June 2026

I’ve often wondered how long it would take me to adapt if I suddenly found myself fifty or a hundred years in the future. I suspect the answer is about 48 hours.

“The Trump administration on Tuesday announced a ban on new foreign-made humanoid robot imports to the US over ‘unacceptable risks’ to America’s national security… The move applies to advanced robots – including humanoid and four-legged machines. Many of them are made in China, which is competing with the US to develop robotics and artificial intelligence (AI).”

BBC, 29 July 2026

Because everyone around you would be totally unfussed by whatever unimaginable technological advances were occurring around them: “That? Huh. I suppose it is a bit odd, now you mention it. Do you want another HobNob?”

Maybe we should have just moved everyone to Linux.

Encore builds and deploys backend applications, and since mid-2022 every one of those builds has run inside a Firecracker microVM. Firecracker strips the emulated hardware down to what a Linux kernel needs, giving each build the isolation of a virtual machine with startup close to the cost of a container.

Firecracker drives KVM, so it needs a Linux host with /dev/kvm, which no Mac has, and most engineers at Encore develop on a Mac. The maintainers have no plans to close that, given they turned down a working proof of concept built on Apple's Virtualization.framework and said they do not plan to support macOS any time soon.

So for four years, working on the build system meant working on it somewhere else. We wanted to run the same build system on our laptops while keeping Firecracker in production, so we built crackling, a single microVM API that drives Firecracker on Linux and Apple's hypervisor on macOS; booting the same images on both required rebuilding much of the Linux image toolchain to run on macOS.

Four years of developing on a shared remote machine

We onboarded each engineer with a script you ran once. It SSHed into the shared build machine as root, pulled your public key from https://github.com/<you>.keys and created you a user, then added you to the kvm and docker groups so you could reach the hypervisor and run containers. It copied the VM images into your ~/images and hard-linked the firecracker binary into your ~/binaries, since every user needed it under their own tree on the one box. You ended up with a personal environment in a datacentre, reachable over Tailscale, sitting next to everybody else's.

Getting a change onto that environment took a second script, which read your username and your port out of the CUE config, from a gitignored per-engineer file, because we all shared that host and had to agree not to collide. Binaries were the easy half: we cross-compiled with GOOS=linux GOARCH=amd64, rsynced the results across, and counted the transferred files to work out whether anything needed restarting.

Images were the hard half, because Firecracker boots a block device and Docker produces layers. We could not find an existing tool that converted Docker layers into a block device Firecracker could boot, so we built the conversion ourselves, half on your laptop and half over SSH:

# tools/dev-builder/deploy-dev-builder.sh
docker save -o "$imagesdir/$name.tar" "$docker_image"
tar -C "$layersdir" -xf "$imagesdir/$name.tar"          # explode the layers
tar -C "$dst/" -xf "$imagesdir/$name.tar" manifest.json

rsync -azP $layersdir  ${username}@builder:~/images/
rsync -azP "$dst"      ${username}@builder:~/images/

ssh ${username}@builder -- \
    "bash -l -s squash_layers \"images/${outputdir}\" \"images/${name}\"" < $scriptpath

That last line pipes a shell function into a login shell on the far end and runs it there. The bash was later rewritten in Go, but the pipeline and the host did not change. We had squash_layers re-extract every layer in manifest order, delete the .wh..wh..opq whiteout markers with find because tar will not apply them for us, write a hardcoded /etc/resolv.conf since the VM had no DNS otherwise, pull the image's environment variables out of the Docker config with jq, and finally call mksquashfs to produce something Firecracker could boot. We keyed a cache on the Docker image id so the whole path could be skipped when it matched. It ran whenever you had changed anything in the image, which was most of the time if you were working on the guest side.

Restarting took a third SSH, to kill your container and start its replacement:

docker run --privileged \
    -v ~/socks:/var/lib/buildsvc/socks:rw   -v ~/logs:/tmp/encore-builds:rw \
    -v ~/.keys:/.keys:ro                    -v ~/binaries:/usr/local/bin:ro \
    -v ~/images:/usr/lib/buildsvc/images:ro \
    --env-file service-envs \
    --device /dev/kvm --device /dev/net/tun \
    -p $port:9060 --name "${username}-builder" -d -t buildsvc-tester

Firecracker is running inside a Docker container there, so we had to pass --privileged, /dev/kvm and /dev/net/tun through, because the process inside that container was going to create tap devices and boot virtual machines of its own.

Firecracker expects those tap devices to attach to a host bridge, and inside a Docker container there is no host bridge. So we built one, in a shell script that ran before buildsvc, the build service itself, came up:

# tools/dev-builder/container/start.sh
ip link add docker0 type bridge
ip link set eth0 master docker0
addr=$(ip address show eth0 | grep inet | xargs | cut -d " " -f2)
ip address del $addr dev eth0
ip address add $addr dev docker0 broadcast 172.17.255.255
ip link set docker0 up
ip r add default via 172.17.0.1 dev docker0

The script builds a bridge named docker0 inside the container, enslaves the container's own eth0 to it, then moves the IP address off eth0 and onto the bridge. The tap devices then had something to attach to that looked enough like a real Docker host.

The build system ran everywhere except our laptops

The setup worked, which is why it lasted from 2022 until we finally replaced it. What it cost was harder to justify at a company whose whole pitch is that backend development should be smooth: that you should be able to write your application, run it locally, and have the infrastructure follow from the code rather than from a pile of YAML you maintain by hand. Meanwhile the part of our product that turns a git push into a running application was the one thing we could not run on the machines we write software on.

Because the build system was remote, a local breakpoint would never fire and reading logs meant tailing a file over SSH. Attaching a profiler first required copying it onto the box. Every guest-side change also went through docker save and an rsync of the exploded image, followed by extraction and mksquashfs on the shared host while other engineers ran their own builds there.

The loop was long enough that you thought twice before trying something speculative, and what we wanted was to run the build system on a Mac, natively, booting the same images, on the machine we were already sitting in front of.

One API over two hypervisors with little in common

We looked at what already existed first, and running Linux in a VM on macOS has several working implementations: Apple's own container reached 1.0 this June, Lima and Tart have been doing it for years, and podman can too, through libkrun. You can even get /dev/kvm inside a Linux VM on an M3 or later running macOS 15, which runs Firecracker unmodified.

None of them spans both hosts, though, and the nested route still leaves you inside a Linux VM on the subset of laptops that support it. Adopting any of them would have left us with a second, differently-behaved way of running builds that only exists on laptops.

Crackling is a daemon and CLI that boot OCI images as lightweight Linux VMs on both platforms, with one agent inside the guest and one protocol driving it either way. Firecracker remains the backend on Linux, and on macOS it is Apple's Virtualization.framework, or VZ, which is the prefix on every type it exports.

We kept the core crate independent of either hypervisor. It describes a machine through MachineSpec, which carries vcpus, mem, kernel, rootfs, extra_disks, nics, vsock, and per-backend extras, while MachineState tracks it at runtime.

Both backends implement MachineBackend: start, shutdown, pause, resume, snapshot, wait, dispose, and, where available, connect_vsock. Backend dispatch is static because only one can exist for a given target, while the trait gives both implementations a shared contract and lets tests substitute an in-memory backend.

Their capabilities still differ: Firecracker has host tap devices and its MMDS metadata service, while Apple's framework has a built-in NAT device, virtiofs directory sharing, and Rosetta translation for running x86 binaries in an arm64 guest. Each backend returns an error naming any requested feature it cannot implement:

// crates/crackling-core/src/backend.rs
pub enum Feature {
    Snapshot,
    /// Creating a machine from a previously captured snapshot.
    /// Distinct from `Snapshot`: VZ can capture (entitlement permitting)
    /// but crackling never restores there, while Firecracker does both.
    SnapshotRestore,
    Mmds, VirtioFs, Rosetta,   // Firecracker / VZ / VZ
    /// Host tap network device (Firecracker).
    TapNetwork,
    /// Built-in NAT network device (VZ).
    NatNetwork,
    MemoryBalloon, Entropy, Vsock,
    /// Machines outlive the controlling process and can be re-attached
    /// (Firecracker). VZ machines live in-process and can never be adopted.
    Adoption,
}

Each backend reports what it supports on the current host before any machine exists, allowing the daemon to adjust a spec before create. Requests for unavailable networking modes, adoption, or snapshot restore fail at the API boundary with the unsupported feature named.

On Linux, each VM is a separate firecracker child process, driven over its REST API on a Unix socket by a small HTTP/1.1 client written for that limited API surface. Those processes can outlive the daemon. A transient systemd scope keeps the service manager from reaping them, and we persist both the PID and its start time so PID reuse cannot make an old record point to an unrelated process. On restart, the daemon opens a pidfd and checks the instance id over the API socket. Anything it cannot identify is left running. VZ machines live inside our process and end with it, so on macOS Adoption returns an error.

Both backends are built and tested on every pull request, on an x86_64 Ubuntu runner for Firecracker and an arm64 macOS runner for VZ. The daemon's backend-agnostic logic runs against the mock backend on each runner, and the VZ tests require no hypervisor, code-signing, or guest image.

The crackling CLI drives a daemon over gRPC; the daemon boots machines through a facade that selects one of two hypervisor backends at compile time, and both talk to the same in-guest agent over vsock.

The backend is chosen at compile time; the guest agent is the same binary on both.

The one thread Apple's framework insists on

Implementing the VZ backend came with a strict threading constraint: VZVirtualMachine, VZVirtualMachineConfiguration, and the framework's device objects are !Send + !Sync, while every VM call and completion handler must run on the serial dispatch queue that created the VM. The rest of the daemon is tokio, which moves futures between worker threads whenever it likes, so no arrangement can hold a VM object across an await point and satisfy both constraints.

We create and access every VM on one process-global serial DispatchQueue, with the VM registry available only to closures dispatched onto that queue so access stays serialized and the objects never reach tokio's threads. The async half is an ordinary Send + Sync + Clone handle that dispatches a closure carrying nothing but Send data, then awaits the reply:

// crates/crackling-vz/src/reactor.rs
reactor().queue.exec_async(move || {
    match build_configuration(&cfg) {
        Ok(vm_cfg) => {
            // SAFETY: we pass the reactor's own serial queue; the VM is
            // stored and only ever used from this queue henceforth.
            let vm = unsafe {
                VZVirtualMachine::initWithConfiguration_queue(
                    VZVirtualMachine::alloc(), &vm_cfg, &reactor().queue)
            };
            let id = shared.id;
            if let Ok(mut g) = reactor().state.vms.lock() {
                g.insert(id, ReactorVm { vm, shared });
            }
            let _ = reply.send(Ok(()));
        }
        Err(e) => { /* mark Failed, then: */ let _ = reply.send(Err(e)); }
    }
});

The dispatch API requires Send + 'static closures, so the compiler prevents a !Send VM object from being captured. The registry and the reactor that holds it still need hand-written Send and Sync impls; the queue invariant depends on those two implementations.

VZVirtualMachineConfiguration is !Send too, so we split lowering into two phases: a MachineSpec becomes a structure containing only Send data on tokio, then that structure becomes a VZVirtualMachineConfiguration on the queue. A completion handler receives a raw NSError pointer that is valid only for the duration of the block, so we convert it into an owned error on the queue before replying. Dropping the last handle to a machine dispatches a dispose, because the framework requires that release on its own queue too.

Building a bootable Linux image without Linux

The VZ backend could now create and control a VM, but booting one still required replacing the Linux-only image pipeline. Turning an OCI image into a bootable root filesystem normally requires root and a loop mount, neither of which exists on macOS, while building an initramfs usually calls the cpio binary. The kernel tree's own extract-vmlinux is written for x86 bzImage and cannot unpack an arm64 kernel.

Neither hypervisor boots anything until it has an uncompressed kernel image, and the vmlinuz an arm64 distribution ships is usually an EFI zboot file, which is a small EFI executable wrapping a compressed payload that the firmware would normally decompress at boot. There is no firmware here, so we unwrap it ourselves. The MZ and zimg signatures identify the format, and the header gives us the payload's offset, size, and compression:

// crates/crackling-image/src/kernel.rs
// EFI zboot: "MZ" at offset 0 and the "zimg" signature at offset 4.
if bytes.len() > 64 && &bytes[0..2] == b"MZ" && &bytes[4..8] == b"zimg" {
    let payload_offset = u32::from_le_bytes(bytes[8..12].try_into().unwrap()) as usize;
    let payload_size = u32::from_le_bytes(bytes[12..16].try_into().unwrap()) as usize;
    let comp_end = bytes[24..32].iter().position(|&b| b == 0).unwrap_or(8);
    let compression = std::str::from_utf8(&bytes[24..24 + comp_end]).unwrap_or("");
    let end = payload_offset
        .checked_add(payload_size)
        .filter(|&e| e <= bytes.len())
        .ok_or_else(|| ImageError::Kernel("zboot payload out of range".into()))?;
    let raw = match compression {
        "gzip" => gunzip(&bytes[payload_offset..end])?,
        other => return Err(ImageError::Kernel(
            format!("unsupported zboot compression: {other:?}"))),
    };
}

Hand Virtualization.framework a compressed kernel and it fails at start with a generic internal error and no detail attached. The virtualization entitlement was our first suspect, and we lost an afternoon re-signing binaries before looking at the kernel. We now check for the ARMd signature at offset 0x38, which identifies a raw arm64 Image, and report a compressed kernel before trying to boot it.

The kernel needs a root filesystem to boot into, so we apply OCI layers entirely in userspace and honor .wh. whiteout entries as squash_layers did with find, but in-process and without a cleanup pass afterwards. Pulling the image also required a custom platform resolver because the default keys off the host OS and never matches a linux/arm64 image for a request from a Mac.

Booting the rootfs from RAM requires an initramfs: a newc-format cpio archive inside a gzip stream. We generate both layers in pure Rust, and by default the rootfs remains in memory until the VM stops.

We unpack and normalize an image once, write a .built sentinel, and publish the completed output by atomic rename so a crash leaves the existing cache untouched. Each VM clones the cached rootfs using clonefile on APFS, a per-file FICLONE reflink on Linux filesystems that support it, or a plain copy elsewhere, and the RAM path repacks that clone into the VM's own initramfs.

Getting a shell inside the VM

Once the kernel and rootfs booted, crackling needed a way to run commands and move data inside the guest. Both platforms provide vsock, and Alpine's virt kernel ships AF_VSOCK as loadable modules, so the guest /init loads vsock, vmw_vsock_virtio_transport_common and vmw_vsock_virtio_transport, among others, before anything can listen. Those modules carry a vermagic string that must match the running kernel exactly, and a mismatch fails at load with nothing useful downstream: the VM boots, the agent never comes up, and the host waits for a connection that never arrives. We fetch the kernel and its modules from one linux-virt package so they stay in step. Mounting ext4 pulls in a crc32c hash even with checksums disabled, so crc32c_generic and libcrc32c have to be loaded, and an interactive shell needs /dev/pts mounted before openpty will work.

Every VM runs the same agent, a static musl binary built for aarch64-unknown-linux-musl on the Mac and x86_64-unknown-linux-musl for amd64 hosts. It listens on AF_VSOCK and uses a small framed protocol: an 8-byte header followed by either an encoded control frame or raw bytes for bulk data, with one connection per operation. The protocol supports exec with streamed stdout and stderr, an interactive shell on a PTY, cp in both directions, and forward, which turns a connection into a tunnel to a port inside the guest.

The agent uses vsock for control, leaving the guest without manual network configuration or an SSH daemon installed by crackling. Outbound networking is a separate opt-in, while inbound access is available only through a control-plane forward authenticated with a per-VM token generated at boot.

On macOS the host end of that transport is a VZVirtioSocketDevice connection whose file descriptor has to be dup(2)ed immediately, because the framework closes the original when its Objective-C object deallocates. On Linux it is a Unix socket with a text handshake, and the reply has to be read one byte at a time:

// crates/crackling-firecracker/src/machine.rs
// Read the reply one byte at a time so we never swallow payload
// bytes past the newline (a real hazard with buffered reads).
stream.write_all(format!("CONNECT {port}\n").as_bytes()).await?;
let mut line = Vec::with_capacity(16);
loop {
    let b = stream.read_u8().await.map_err(Error::Io)?;
    if b == b'\n' { break; }
    line.push(b);
}

The macOS and Linux implementations differ, but both return a byte stream connected to the agent for crackling shell, exec and cp.

Apple does not let third parties snapshot a VM

Firecracker captures memory and device state natively through PUT /snapshot/create, and a spec carrying restore_from spawns a fresh VMM, checks the snapshot's host fingerprint, loads the snapshot paused and resumes it without booting. Upstream only restores onto a matching architecture and Firecracker version, so the fingerprint check protects the operation when we suspend an idle sandbox and resume it on another host.

Apple's framework appears to offer the same thing, since VZVirtualMachine exposes saveMachineStateToURL, and validateSaveRestoreSupport on the configuration asks whether it is eligible. We wrote the implementation and the validator returned successfully, but the save failed with VZErrorInternal. It fails even on a minimal VM carrying little more than a vsock device, which makes an unserializable device an unlikely explanation.

Running a VM needs com.apple.security.virtualization, which any developer can sign for, while saving one additionally needs com.apple.private.virtualization, which Apple does not grant to third-party applications. Since the validator does not check for the second one, the framework reports the operation as supported, fails when you call it, and returns the same generic internal error that a bad kernel produces.

What runs on a Mac now

An engineer clones the build system, runs it on their laptop, and boots the OCI images used for Encore's builds and deploys through the same agent and vsock path. The shared host is gone, along with the docker save piped through rsync and the hand-built bridge inside a privileged container, and you can put a breakpoint in the build system and hit it.

The local workflow looks like this:

$ crackling run --image alpine:3.20
0c1f8f3c-7b21-4a5e-9a10-2b4c6d8e0f11   running   alpine:3.20

$ crackling exec 0c1f8f3c-7b21-4a5e-9a10-2b4c6d8e0f11 uname -a
Linux (none) 6.6.142-0-virt ... aarch64 Linux

$ crackling shell 0c1f8f3c-7b21-4a5e-9a10-2b4c6d8e0f11
~ # cat /etc/alpine-release
3.20.10

Introduction

When evaluating high-performance database architectures, the conversation often centers on horizontal scaling, distributed partitioning, and query optimization. However, for mission-critical transactional systems like financial ledgers, the real bottleneck is rarely the network or the query planner; it is the operating system kernel, memory fragmentation, and unpredictable tail latency. TigerBeetle, a specialized financial ledger database written in Zig, challenges conventional database design by prioritizing extreme mechanical sympathy, static resource allocation, and custom zero-copy interfaces.

I have spent years analyzing distributed storage engines, and TigerBeetle’s architectural choices stand out as a masterclass in modern performance engineering. By rejecting dynamic memory allocation at runtime, bypassing the kernel cache via direct I/O, and leveraging a single-threaded execution loop backed by Viewstamped Replication (VSR), TigerBeetle achieves throughput rates exceeding hundreds of thousands of transactions per second with predictable, sub-millisecond tail latencies.

In this article, I will deconstruct the core architectural pillars of TigerBeetle. We will examine how static allocation eliminates runtime garbage collection and memory fragmentation, how custom zero-copy interfaces minimize CPU-to-memory bus overhead, and how Zig’s compile-time capabilities enforce strict safety guarantees without sacrificing raw hardware performance. My goal is to provide engineering leaders and systems architects with actionable insights into these low-level design patterns, enabling you to apply similar performance-engineering principles to your own high-throughput systems.

Static Allocation: Eliminating Runtime Memory Overhead

In traditional database systems, memory management is highly dynamic. As queries arrive, the database allocates memory for connection buffers, query plans, temporary sort buffers, and transaction state. While modern memory allocators like jemalloc or tcmalloc are highly optimized, they are not immune to thread contention, memory fragmentation, and unpredictable latency spikes during peak loads. In a financial ledger where a single delayed transaction can disrupt downstream payment pipelines, these latency spikes (often referred to as the "noisy neighbor" or "long tail" problem) are unacceptable.

TigerBeetle addresses this by completely eliminating dynamic memory allocation (malloc, free, or their equivalents) after the initialization phase. When the TigerBeetle process starts, it calculates and allocates all the memory it will ever need for its lifetime. This includes memory for network buffers, storage cache, transaction logs, and consensus state machines. Once the initialization phase is complete, the allocator is effectively frozen, and the system runs entirely within pre-allocated, static arrays and ring buffers.

This design choice has profound implications for system predictability and reliability:

1. Zero Memory Fragmentation: Because memory is never freed and reallocated at runtime, heap fragmentation is physically impossible. The system will never run out of memory (OOM) mid-transaction due to fragmented free lists.
2. Deterministic Tail Latency: Without a memory manager searching for free blocks or running garbage collection cycles, execution paths remain highly deterministic. Every CPU cycle is dedicated to processing transactions, not managing memory metadata.
3. Hardware-Level Predictability: Pre-allocated memory blocks can be aligned precisely to CPU cache lines (typically 64 bytes) and page boundaries (4KB or huge pages). This alignment minimizes translation lookaside buffer (TLB) misses and cache line bouncing.

To illustrate the difference between this static paradigm and traditional dynamic database architectures, consider the following structural comparison:

Architectural Attribute	Traditional Dynamic Databases	TigerBeetle Static Architecture
Memory Allocation	Dynamic (runtime heap allocation)	Static (pre-allocated at startup)
Tail Latency (p99.99)	Variable (impacted by GC/fragmentation)	Deterministic (sub-millisecond bounds)
I/O Path	Buffered I/O via Kernel Page Cache	Direct I/O (O_DIRECT) with io_uring
Concurrency Model	Multi-threaded with locks/latches	Single-threaded event loop (Disruptor pattern)
Data Layout	Variable-length rows/documents	Fixed-size structs (128-byte accounts/transfers)
Failure Domain	Dynamic out-of-memory (OOM) risks	Predictable compile-time/startup-time limits

However, static allocation is not a free lunch. It introduces a major engineering trade-off: rigidity. Because all buffers are fixed in size, you must define the maximum number of concurrent connections, the maximum batch size, and the maximum storage cache size at startup or compile time. If your workload exceeds these pre-defined limits, TigerBeetle will not dynamically scale its memory usage; instead, it will apply backpressure or reject incoming requests. I find this trade-off highly acceptable for financial systems, where predictability and safety are far more valuable than elastic, unpredictable scaling.

Custom Zero-Copy Interfaces and Kernel Bypass

Even with static memory allocation, a database can easily become bottlenecked by the operating system's I/O stack. In a standard database, writing a transaction to disk involves copying data from user-space buffers to kernel-space page caches, and eventually flushing those pages to physical storage. This process involves multiple system calls, context switches, and memory copies, all of which consume precious CPU cycles and memory bandwidth.

TigerBeetle bypasses these bottlenecks by implementing a custom, zero-copy I/O path. It achieves this by combining direct I/O (O_DIRECT) with Linux’s modern asynchronous I/O interface, io_uring.

When TigerBeetle receives a batch of transactions over the network, the data is read directly into a pre-allocated static buffer. This buffer is registered directly with io_uring. When it is time to persist these transactions to the write-ahead log (WAL) on disk, TigerBeetle submits an I/O request to io_uring pointing to the exact same memory address. The kernel's storage driver reads directly from this user-space memory block and writes it to the NVMe controller via Direct Memory Access (DMA), completely bypassing the OS page cache.

This zero-copy pipeline ensures that data is never copied between different memory locations as it moves from the network interface card (NIC), through the CPU, and down to the physical storage media.

To make this zero-copy mechanism highly reliable and performant, TigerBeetle structures its core data entities—Accounts and Transfers—as fixed-size, 128-byte structs. This exact sizing is highly intentional. Because 128 bytes is a multiple of standard CPU cache lines (64 bytes) and sector sizes (typically 512 bytes or 4096 bytes), TigerBeetle can pack these structs perfectly into memory pages and disk sectors. There is no need for complex serialization or deserialization protocols like JSON, Protocol Buffers, or even custom binary encoders. The memory representation of an Account struct in Zig is identical to its on-disk representation. Persisting an account is as simple as passing its memory address directly to the disk controller.

Here is a conceptual implementation of how TigerBeetle leverages Zig’s type system to define these fixed-size structs and manage zero-copy batching safely without runtime allocations:

const std = @import("std");

/// A highly optimized, 128-byte representation of a financial account.
/// Explicit alignment ensures that arrays of this struct align perfectly with CPU cache lines.
pub const Account = struct {
    id: u128,
    user_data: u128,
    reserved: [48]u8, // Pad to ensure exact 128-byte size and future-proofing
    ledger: u32,
    code: u16,
    flags: u16,
    debits_pending: u64,
    debits_posted: u64,
    credits_pending: u64,
    credits_posted: u64,
};

/// A pre-allocated batch of accounts designed for zero-copy I/O operations.
pub const AccountBatch = struct {
    const MaxEvents = 8192;
    
    // Static array allocated at startup/compile-time
    items: [MaxEvents]Account align(4096),
    count: usize,

    pub fn init() AccountBatch {
        return .{
            .items = undefined, // Left uninitialized to avoid startup overhead; populated explicitly
            .count = 0,
        };
    }

    /// Returns a direct slice of the memory to be passed to io_uring or network sockets.
    /// This operation is completely zero-copy and carries zero runtime allocation cost.
    pub fn as_bytes(self: *anyopaque) []const u8 {
        const self_typed: *AccountBatch = @ptrCast(@alignCast(self));
        const total_size = self_typed.count * @sizeOf(Account);
        const byte_ptr: [*]const u8 = @ptrCast(&self_typed.items);
        return byte_ptr[0..total_size];
    }
};

This code demonstrates how Zig allows us to enforce memory alignment (align(4096)) at the type level. By aligning the static batch to a 4KB page boundary, we satisfy the strict alignment requirements of O_DIRECT and DMA transfers. The as_bytes function performs a safe, compile-time validated pointer cast that exposes the raw backing memory of our struct array as a byte slice, ready to be transmitted over the wire or written to disk with zero copies.

The Single-Threaded Execution Loop and VSR Consensus

Many modern databases attempt to maximize throughput by parallelizing transaction execution across multiple CPU cores using complex locking mechanisms, MVCC (Multi-Version Concurrency Control), or actor models. However, parallelizing transactional state updates—especially in financial ledgers where account balances must be strictly checked and updated sequentially—introduces severe lock contention, thread synchronization overhead, and the risk of deadlocks.

TigerBeetle bypasses these issues by adopting a single-threaded execution model for its core state machine, heavily inspired by the LMAX Disruptor pattern. All transaction validation, balance checks, and ledger updates are executed sequentially on a single, dedicated CPU thread.

While a single-threaded architecture might sound like a bottleneck, it is incredibly fast when freed from the overhead of thread context switching, mutex acquisition, and cache invalidation. Because only one thread ever modifies the ledger state, TigerBeetle does not need locks, semaphores, or complex concurrency controls. The execution thread can run at maximum CPU frequency, pulling batches of transactions from a lock-free ring buffer and processing them sequentially in L1/L2 cache.

To keep this single thread fully saturated with work, TigerBeetle relies on aggressive batching and a custom consensus protocol based on Viewstamped Replication (VSR).

Instead of processing transactions one by one, TigerBeetle groups them into large batches (e.g., up to 8,192 transfers per batch). The consensus layer replicates these batches across the network to follower nodes. Once a batch is committed by the consensus quorum, it is handed off to the single-threaded execution loop. The execution loop processes the entire batch in a single pass, updating the in-memory state and writing the results to the storage engine in a single, sequential disk write. This batching strategy transforms what would be thousands of small, random disk and network I/O operations into a single, highly efficient sequential operation, maximizing the physical throughput of NVMe drives and network interfaces.

Memory Layout, Cache Locality, and Zig's Type System

At the hardware level, the speed of your code is largely determined by how efficiently you utilize the CPU's cache hierarchy. A modern CPU can access registers in less than a nanosecond and L1 cache in about one nanosecond. However, accessing main memory (RAM) takes around 50 to 100 nanoseconds—an eternity in high-performance systems. If your database engine is constantly chasing pointers across the heap (a common occurrence in languages with heavy object references like Java, Go, or Python), the CPU will spend most of its time stalled, waiting for data to arrive from RAM.

TigerBeetle is designed to maximize cache locality by keeping data contiguous in memory. Because accounts and transfers are represented as flat, fixed-size structs packed tightly into contiguous static arrays, the CPU's hardware prefetcher can easily predict memory access patterns. When the execution loop processes a batch of transfers, the CPU pre-fetches subsequent transfers into the L1/L2 cache before the execution thread even requests them, virtually eliminating CPU stalls.

Zig’s type system is uniquely suited for this style of performance engineering. Unlike C++, which allows implicit memory allocations and complex copy constructors, Zig enforces explicit control over every byte of memory. There is no hidden control flow, no implicit type coercion that could trigger a copy, and no runtime overhead from a virtual method table (vtable) unless explicitly designed.

Furthermore, Zig's compile-time execution engine (comptime) allows TigerBeetle to perform extensive validation of data structures, alignments, and system configurations at compile time rather than runtime. For example, TigerBeetle uses comptime to verify that the size of its storage blocks is a perfect multiple of the disk sector size, and that all critical structs are aligned to cache line boundaries. If an architectural change violates these performance-critical constraints, the build will fail immediately, preventing performance regressions from ever reaching production.

Conclusion

TigerBeetle’s core system architecture demonstrates that extreme performance is not achieved by adding complexity, but by systematically removing it. By rejecting dynamic memory allocation, bypassing the OS kernel with zero-copy direct I/O, and utilizing a single-threaded execution loop, TigerBeetle aligns its software architecture perfectly with the physical realities of modern hardware.

For engineering leaders and systems architects, the takeaways from TigerBeetle’s design are clear:

• Design for Predictability First: If your system requires low tail latency, eliminate dynamic runtime allocations in favor of static, pre-allocated resource pools.
• Embrace Batching to Amortize Overhead: Batching is the ultimate performance multiplier. It converts expensive, random I/O and network operations into highly efficient, sequential pipelines.
• Align Software with Hardware Limits: Structure your core data models to align with CPU cache lines and disk sector boundaries to maximize hardware efficiency and minimize CPU stalls.

By adopting these mechanical sympathy principles, you can build systems that are not only orders of magnitude faster but also significantly more reliable and predictable under extreme load.

My father passed recently, and he was twice my age. I am approximately the same age that he was when I was born, and I am now “the old generation” - there’s no one left in the generation above me.

At the same time, I recently joined a company that skews younger-than-me. When I joined Google in 2011, I had just turned 30, and was in the mainstream demographics of Google in 2011. There were a bunch of more senior folks, with the very senior ones being in their 50s and having completed stints at Bell Labs. I admired a lot of these “greybeards” (even though this is a sexist term - what’s the right female equivalent? There were a few very senior female engineers that I would love to include).

So perhaps it is natural that I am reflecting on “what were the important realizations that I made since my early 20s that had a profound impact on the way I think about the world”? In some sense: What are the insights I had that made me “more mature”, for some positive definition of “mature”?

This post tries to list them.

1. The importance of understanding your own incentive structure, and not believing everything you think.

I recently wrote a Twitter thread about the topic. Oppenheimer was very publicly guilt-ridden about the creation of the nuclear bomb, and von Neumann at some point quipped “some people profess guilt to claim credit for sin”. In my young years, particularly in situations when I had 0day that nobody else had, I agonized about the responsibility that comes with having 0day. Should I fix them? Should I use them for good? Will the world be harmed this way? Or that way?

In the end, it turns out that - while individuals matter - many ideas have a “time at which they are ripe”, and the actions of the individual matter less than the individual thinks in that moment. There is also almost no way to predict the ways in which what you do impacts the broader world.

If you were asked: “Would it be good if this 0day was used to apprehend a terrorist?” you would probably say “this is good”. If you were asked “would it be good if this 0day is used to arrest someone and then torture and waterboard him 183 times?”, you would probably say “this is bad”. So if your 0day was used to capture KSM, it is probably good? Or bad? Things get very complicated very quickly.

Is closing 0days good for society, because it makes everything safer? Or is it enabling oppression, because buggy systems are easier to bypass?

There are no good answers, and your own incentive structure will greatly influence how you choose your beliefs. In the end, people want to be the heroes of their own story, and at the same time they have basal needs for recognition, for material goods, etc. - so they will try to construct a narrative that allows them to satisfy their basal needs while also remaining the hero of their saga.

Anxiety about the impact of your work is self-flattering, and you have to recognize it as such, and keep it in check - it’s sugar for your ego, but history will largely route around you, because while individual decisions matter in specific situations, the overall flow of history is less sensitive to the individual than the individual thinks. The broader lesson, though, is: Do not believe everything you think. Examine your own incentive structures carefully. Ask yourself what alternative narratives for your behavior and beliefs could be, especially if they contradict the narrative of the heroic saga you’re constructing for yourself. Carefully weighing the question “how might I be the villain in this story?” is an important and valuable skill.

Similarly, meta-cognition - just observing your own thoughts in a detached manner, and then being able to interpret, analyze, and contextualize them with regards to your own incentive structures, is a great skill to cultivate.

2. Monocausal determinism is an illusion, and largely does not exist outside of computer debugging.

The monocausal determinism that young computer enthusiasts get used to is an illusion that generations of electrical and process engineers spent their lives perfecting and maintaining. It is because of these engineers that computer scientists could largely get away without probabilities or any empirical grounding in the past. There is an argument that you have so many natural scientists that crossed over into AI because CS education was for a long time too focused on reasoning within the deterministic monocausal illusion.

The reality is: Computing machines are physical devices, which includes wear & tear, differences in quality between items, and “probabilistically deterministic behavior”, e.g. it’ll appear deterministic most of the time if not shaken too much. If pushed a bit - be it temperature, voltage, electromagnetic fields, or even rapid memory accesses to adjacent DRAM rows - determinism has a tendency to go out of the window, the illusion collapses, and we’re dealing with a very different beast.

FWIW - this also makes me wonder about model alignment, because even a perfectly aligned model will be subject to random bit flips in inference, and it’s hard for me to imagine that you can maintain any reasonable guarantees in the presence of bit flips to inopportune values at inopportune times.

The real world is one where very few things that happen have a single reason, and very few truly deterministic transmission mechanisms. Everything is probabilistic, and everything is multicausal.

Measurement noise is real, experiment design is difficult.

Interestingly, if you think about this carefully, you also realize that the scientific method is a classifier that is intentionally biased against accepting something as true - so that we only accept things as true that are beyond any reasonable doubt true.

A somewhat fascinating corolary of this is that there exists a large class of true things that will never be scientifically shown as true.

3. The dichotomy between reason and emotion is a cultural construct, and neither grounded in neuroscience nor in logic.

With some digging, it turns out that the western belief that reason and emotion are two ends of a spectrum is a purely cultural construct, as is the belief that “higher-order” reason needs to reign in “basal” emotions, or that “emotions” intrude on “rationality”.

In most non-western cultures, achieving integration between rational deliberation and impulses and emotions is more common, and it turns out that this is much closer to the biological reality.

From a neuroscience perspective, it is clear that emotional valuation is part of a larger decision-making machinery that tends to not function properly if the emotional valuation component is damaged or removed. There is also a large component where things that your brain struggles to articulate verbally are transmitted via emotions, as well as actual feedback from your sensory organs in your body. Fun trivia: Your gut’s enteric nervous system contains as many neurons as the entire cerebral cortex of a dog. Your body also forward-deploys neurons in your muscles and extremities, as a form of latency optimization. Your body is feeding you extra information, and most of this shows up in the shape of emotions.

Which brings us to the logical argument why attempting to “remove” emotions from decision-making is a bad idea: Clearly, having the ability of leveraging more information for decision-making will improve the quality of decisions. Attempting to eliminate a particular source of information almost certainly makes the quality of your decisions worse.

This is not to say one should act on impulse alone, but it is certain that integrating the full spectrum of information - which includes emotions - in your decisions is a wise idea.

I am sure that if I think more carefully, I will come up with more insights, but these three are important enough that they show up in my life with astonishing regularity.

Hope this is helpful to someone.

Backed by a $10 billion planned investment over the next decade, Micron Research Labs will unite academia, government, startups and industry to advance the memory and compute breakthroughs that will define the AI era

BOISE, Idaho, Aug. 20, 2026 (GLOBE NEWSWIRE) -- Micron Technology, Inc. (Nasdaq: MU) today unveiled Micron Research Labs, a U.S.-based long-horizon premier research institution headquartered in Boise and backed by a planned $10 billion investment over the next decade. Building on Micron’s technology and manufacturing leadership, the new hub will bring together customers, academia, government and the broader semiconductor ecosystem to pursue breakthroughs beyond today's technology roadmaps and help define what's possible in the decades ahead. Key research areas include critical memory technologies, advanced memory and compute architectures, packaging and future semiconductor manufacturing.

As the first dedicated memory research hub of its kind in the U.S., Micron Research Labs will center on a flagship Boise campus designed to support advanced research across critical technology domains. The planned investment will also fund extensive university collaborations, global satellite labs and deep ecosystem partnerships, creating a connected research network focused beyond the next generation of technologies for the AI era.

“The decisions we make today will determine who leads the AI economy of tomorrow, and America's AI future will be built on American-made memory," said Sanjay Mehrotra, Chairman, President and CEO of Micron Technology. "With a planned $10 billion investment in Micron Research Labs, we are looking around the corner to the memory and compute systems the future will demand, bringing together the best minds across academia, government, startups and industry. This builds on the more than $250 billion we have separately committed to manufacturing and R&D across the United States, because as the only U.S.-based manufacturer of memory, we have long believed in the future that AI is now making real.”

Micron Research Labs is founded on a simple conviction: The future of memory and compute is too important and complex to invent alone. Anchored in Boise and connected to Micron’s research and technology footprint across the U.S., Europe, Japan, India, Singapore and Taiwan, the lab will link Micron researchers with external experts and research partners to accelerate the path from scientific discovery to real-world impact.

Building on Micron’s 62,000 lifetime patents and its position as a global technology leader, Micron Research Labs will advance foundational research across memory, compute and semiconductor manufacturing. The institution will look beyond a 10-year horizon while helping build the next generation of memory researchers and technology leaders. Breakthroughs in advanced memory make AI more powerful, scalable, accessible and sustainable, extending the benefits of intelligent technology to agriculture, healthcare, education and industries around the world and advancing Micron’s vision to accelerate intelligence to enrich life for all.

This new investment builds on Micron's previously announced plans to invest more than $250 billion in manufacturing and research and development in the U.S. that will create more than 90,000 American jobs and will reinforce American leadership in memory and advanced manufacturing for years to come. This new investment draws on Micron's unique position as the only U.S.-based company developing and manufacturing leading-edge memory.

“For nearly 50 years, from four people in a Boise basement to America's memory leader, Micron has pushed the boundaries of what memory can do,” said Scott DeBoer, Executive Vice President and Chief Technology and Products Officer at Micron Technology. "Micron Research Labs gives that legacy a dedicated home for long-horizon innovation, the kind of research that sits upstream of every product we build.” 

Micron anticipates breaking ground in calendar 2027 on a state-of-the-art Micron Research Labs facility capable of hosting hundreds of researchers. The facility is expected to convene world-class research conferences, workshops, and innovation forums in Boise.

Secretary of Commerce Howard Lutnick:
"Memory is a core component of America's technological leadership, and under President Trump, the United States is advancing domestic semiconductor capabilities. Today, Micron announced the establishment of the first dedicated Memory Research Lab along with a $10 billion investment in memory research. This commitment will strengthen American innovation, create hundreds of jobs and ensure memory never limits innovation."

Director of the White House Office of Science and Technology Policy Michael Kratsios:
“Micron’s establishment of the first dedicated memory research lab in the United States advances the Trump Administration’s mission to secure our nation’s technological edge. Memory is fundamental to the AI era, and by uniting the entire innovation ecosystem here at home, we can help ensure the next generation of breakthroughs are invented, developed, and scaled in America. This investment strengthens our national competitiveness and accelerates the path to the AI-driven Golden Age of American Innovation.”

Jensen Huang, founder and CEO, NVIDIA:
"Micron is taking on one of the great challenges of the AI era — reinventing memory technologies and architectures to fuel the next generation of increasingly powerful AI systems. By bringing together advanced manufacturing and the broader technology ecosystem, Micron is helping drive the breakthroughs that will define the next era of AI and computing.”

Tim Cook, CEO, Apple: 
“For more than two decades, Micron has been an important partner, providing memory technologies for Apple's groundbreaking products that people love and use every day around the world. With the launch of Micron Research Labs, they are building on a legacy of leadership in semiconductor research to drive breakthroughs in memory and computing for decades to come. Apple believes deeply in American innovation, and we’re proud to support Micron as it expands leading-edge manufacturing and R&D in the United States.”

Gary Dickerson, President and CEO, Applied Materials:
“Sustained technology leadership requires innovation in both semiconductor research and manufacturing. As memory and computing architectures become increasingly complex, advances in new materials, equipment, process technology and chip packaging will play an essential role in turning breakthrough ideas into reality. Applied Materials has been partnering with Micron for decades, and we are excited to support the new Micron Research Labs in enabling innovations that will advance the future of AI and semiconductor technology in the United States.”

Tim Archer, President and CEO, Lam Research:
"At Lam, we've seen that breakthroughs in semiconductor performance require advances across the entire technology stack, from materials and process technologies to device architectures and system innovation. Micron Research Labs is a meaningful investment in the long-term research ecosystem that fuels these advances. By connecting leading researchers across industry, academia and government, Micron is helping to accelerate the discoveries that will keep America at the forefront of AI and computing." 

Tsu-Jae King Liu, President, National Academy of Engineering:
“Future intelligent systems will be shaped by engineers who advance the frontiers of semiconductor devices and advanced manufacturing, for more affordable and energy-efficient computing and innovative memory solutions. Micron Research Labs represents a powerful commitment to support collaborative, long-horizon research and to develop the engineering talent our nation needs. By connecting industry, universities and government, this new hub of discovery and innovation will strengthen the U.S. semiconductor ecosystem to keep America at the leading edge.”

Luc Van den hove, Chairman, Interuniversity Microelectronics Centre (imec):
"By bringing together expertise from industry, academia and government, Micron is strengthening the global innovation ecosystem that underpins semiconductor progress. The challenges facing the industry, from AI-driven computing to next-generation memory technologies, are too complex for any one organization to solve alone. At imec, we believe deeply in the power of precompetitive collaboration, and our long-standing partnership with Micron demonstrates how shared research can create impact across the broader semiconductor ecosystem. We look forward to building on that partnership and advancing the breakthroughs that will shape the future of computing.”

Jonathan Levin, President, Stanford University:
“Innovation is about turning bold ideas into discoveries that change the world. Micron Research Labs reflects the kind of long-term investment in fundamental research and innovation that is needed to keep America at the forefront. I look forward to the collaborations the Labs will enable with academic institutions to advance the science of memory and computing, and power the next era of discovery.”

Jim Davis, President, The University of Texas at Austin:
“Sustained investments in research will secure our future leadership in computing, semiconductors, and AI. As a founding member of the Texas Institute for Electronics, Micron is a strategic partner to UT Austin and a leading-edge US-based memory provider. Micron understands the power of both academic and industry research and is driving innovation in the national security sector. This investment is the kind of long-term commitment that will produce breakthroughs and unlock new opportunities for our students, researchers, and industry partners.”

About Micron Technology, Inc. 
Micron Technology, Inc. is a global leader in semiconductor memory and storage, powering AI and compute-intensive applications from cloud to edge. With a relentless focus on our customers, technology and product leadership, and manufacturing and operational excellence, Micron’s comprehensive portfolio of high-performance DRAM, NAND and NOR solutions deliver the speed, efficiency, and scale today’s workloads demand, accelerating intelligence to enrich life for all. To learn more about Micron Technology, Inc. (Nasdaq: MU), visit micron.com.

Forward-Looking Statements

This press release contains forward-looking statements, including statements regarding Micron’s manufacturing and research and development investments in U.S. and the outcome of such investments. These forward-looking statements are subject to a number of risks and uncertainties that could cause actual results to differ materially. Please refer to the documents Micron files with the Securities and Exchange Commission, specifically its most recent Form 10-K and Form 10-Q. These documents contain and identify important factors that could cause actual results to differ materially from those contained in these forward-looking statements. These certain factors can be found at https://investors.micron.com/risk-factor. Although Micron believes that the expectations reflected in the forward-looking statements are reasonable, Micron cannot guarantee future results, levels of activity, or achievements. Micron is under no duty to update any of the forward-looking statements after the date of this press release to conform these statements to actual results.