TheDaily Front

Today, Cerebras and OpenAI are sharing an early look at Ultrafast Mode, a new service tier launching first in the OpenAI API and powered by Cerebras. Ultrafast is available initially to a select group of customers, with access expanding over time. Cerebras powers GPT-5.6 Sol on Ultrafast mode, delivering up to 750 output tokens per second and without any quality compromise, allowing Sol Ultrafast to accelerate your most time-sensitive, mission-critical work.

Frontier Intelligence at Unprecedented Speed

AI builders have always needed to choose between speed and intelligence. As models scale up in size and intelligence, they incur higher computational and data movement costs, slowing down response times. Users often need to wait for high-quality results or accept inferior results within a shorter timeframe.

GPT-5.6 Sol Ultrafast resolves this tradeoff, bringing frontier intelligence to products and workflows where every second matters. Compared with output speeds reported by Artificial Analysis GPT-5.6 Sol on Ultrafast mode runs 11x faster than Fable 5, and 5x faster than Opus 4.8 on Fast mode.

At Cerebras, we put Ultrafast to the test by running it head-to-head with popular models on Humanity's Last Exam. HLE is a challenging model benchmark that consists of 2,500 questions typically answerable only by those holding PhDs in fields such as chemistry, economics, and literature.

In our evaluations, GPT-5.6 Sol on Ultrafast mode answered all 2,500 HLE questions in 11 hours and 11 minutes. Claude Fable 5 needed 78 hours and 27 minutes, more than three days of continuous compute, to arrive at the same conclusions. In other words, Ultrafast worked through the frontier of human knowledge in a single working day, achieving comparable accuracy nearly 7× faster.

Humanity's Last Exam Benchmark

Benchmarking was performed by Cerebras using GPT 5.6 Sol Ultrafast with Codex on xhigh reasoning on July 10 and Claude Fable 5 with Claude Code on xhigh reasoning on July 13-15.

As model capabilities continue to advance, the range of applications for fast inference expands. GPT-5.6 Sol is OpenAI’s best model yet for legal briefs, financial models, and engineering reports. On GDP-Val, a benchmark for economically valuable knowledge work tasks, Ultrafast delivered a 5.6x end-to-end speedup with no quality degradation, showing how faster inference can accelerate economically valuable work.

Benchmarking was performed by Cerebras on July 31 2026 using GPT 5.6 Sol and GPT 5.6 Sol Ultrafast on medium reasoning within Codex.

High-Speed Intelligence Powers High-Stakes Work

Faster intelligence changes what’s possible for individuals and organizations. With Ultrafast, you can now put agents on the critical path of problems where every second counts.

"With GPT-5.6 Sol Ultrafast, Cerebras enables AI that keeps up with how you think, code, and collaborate. We’re excited to see how workflows and applications are transformed by Ultrafast inference."

Rohan Varma

Product at OpenAI

Ultrafast is a persistent edge for organizations using frontier AI to quickly respond to incoming information. Companies operating web services can leverage Ultrafast to root-cause and address production outages, preserving customer trust, preventing lost revenue, and saving downtime minutes against their SLAs. And in adversarial, high stakes cyberattacks, Ultrafast is an invaluable tool for security teams who must quickly detect and respond to bad actors to contain catastrophic losses.

More broadly, Ultrafast enables entirely new modes of working with agents, it delivers real-time insights and updates, so you don’t have to context-switch across multiple parallel sessions to get the most out of your agents.

"Whereas formerly I might have to wait a couple minutes for a task to finish, it now finishes for me before I even have the opportunity to context-switch. It makes me way more productive."

Jeffrey Wang

OpenAI Researcher

With Ultrafast, researchers and engineers can reserve their attention for going deep on select problems that matter most, while continuing to use Standard processing for parallelizing commodity tasks. Cerebras is excited to power the next wave of AI innovation, raising the ceiling for what individuals and organizations can accomplish with responsive AI.

Breakneck Speed is Enabled by Breakthrough Innovation

GPT-5.6 Sol on Ultrafast mode is powered by Cerebras’ revolutionary Wafer-Scale Engine architecture, purpose-built for frontier AI workloads. Fast frontier inference is a data movement problem: on GPUs, inference on large models is bottlenecked by memory bandwidth, as model weights must be repeatedly transferred between on-chip memory and off-chip storage to generate successive tokens within a model response.

Cerebras takes a contrarian approach to eliminating this inefficient data movement: we pack 44 GB of SRAM on each wafer-sized chip. Weights stay on-chip, and tokens flow uninterrupted through model layers pipelined across wafers. This technical approach scales smoothly with model size, paving the way for a continued speed advantage on future frontier models.

Ultrafast: Now in Limited Preview

GPT-5.6 Sol on Ultrafast mode is available in a limited preview today to a select group of customers. Access will expand as capacity grows. Sign up for updates.

DeepSeek Harness is now in developer preview for agent harness developers worldwide — source code included.

Every capability is a plugin that can be swapped or recomposed: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI.

Quick start

$ npx @deepseek-ai/dsh web

Install from source

$ git clone https://github.com/deepseek-ai/deepseek-harness

Agent = Model + Harness

Harness keeps agents working in real-world environments

The model is the soul of an agent.

A harness lets an agent understand its environment, use tools, and keep working in real-world settings.

Cordis kernel

The Cordis kernel manages plugin mounting, unmounting, and dependencies. Agent capabilities live in the plugins.

Capabilities as plugins

Plugins provide every agent capability, including models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI. Cordis services and events let the plugins work together.

Compose with configuration

Developers can select, swap, or extend any capability in configuration without changing the DeepSeek Harness source code.

Everything is a plugin. Every run is traceable.

Everything is a plugin

DeepSeek Harness is built on Cordis's plugin system. Plugins provide every agent capability, including models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI. Cordis services and events let the plugins work together. Developers can select, swap, or extend any capability in configuration without changing the DeepSeek Harness source code.

Every run is traceable

Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all operate on the same event stream.

Multiple runtime modes

Standard mode includes the full toolset. Code mode uses model-generated code to orchestrate multiple rounds of tool calls. Minimal mode keeps only a shell tool and a file editor for benchmarking models in a minimal environment. Creator mode lets you inspect the current runtime, test Cordis plugins in memory, and combine them into new modes.

Standard mode

Full coding agent with file editing, shell, file and web search, skills, planning, goals, subagents, and workflows.

Code mode

All Standard mode capabilities, with tools exposed through the Code Mode SDK so the model can combine multi-step operations in one TypeScript program.

Minimal mode

Two-tool coding agent with persistent bash and str_replace_editor.

Creator mode

Built for creating custom agent presets, with all Standard mode capabilities plus runtime inspection, plugin experiments, and preset-authoring guidance.

Customize your DeepSeek Harness

Try it now or install from source

Quick start

Install Node.js, then launch the Web UI with npx.

$ npx @deepseek-ai/dsh web

Install from source

Clone the full source and follow the setup instructions in the repository.

$ git clone https://github.com/deepseek-ai/deepseek-harness

Join the DSH plugin ecosystem

DeepSeek Harness remains in developer preview and is still being tested by developers building agent harnesses. Its core plugins and APIs will continue to evolve. We look forward to exploring the limits of intelligence with developers worldwide using open-source infrastructure that is reusable and composable.

In this post

We just launched a partnership with OpenRouter that lets us offer two new pieces of functionality:

• First, your projects can use any model on OpenRouter through our AI Gateway. That means that if your own web app offers AI inference-based features to your end users, you now have a much wider selection of models to fit any task and budget.
• Second, we’re extending the selection of frontier coding models available for use via Agent Runners. Agent Runners is the chat prompt box you get within Netlify, which lets you build new projects from scratch or iterate on an existing one. The selection of models now includes much-hyped recent open models such as Kimi K3, GLM 5.2, and DeepSeek V4, available to everyone.

We call it Agent Runners because we run a full coding agent inside, not a pared-down one. Until now, we’ve supported Claude Agent, OpenAI Codex, and Gemini CLI which are optimized to run models from these providers.

We provide these agents with extra skills, and context about the current project, so that the agent will know exactly which Netlify capabilities are available for use (e.g., Netlify Database, the AI Gateway, or Identity), when to use them, and how. But to effectively drive a whole variety of new models, we’ve added the popular open-source OpenCode as a new choice of agent.

But with more choice come the inevitable questions: How do I know which model is right for me? Am I missing out on something that’s materially better, or more cost-effective (so I can do more with my credits), or is going to blow my mind like the internet says? There’s a lot of FOMO going around these days.

To provide you with some insights, here’s what we learned when running identical prompts across a range of models… all of which are now available for you to use today on Netlify.

You can see the results of all the models we tested on this site we created with the full report.

What we tested

Internally at Netlify, we use AXIS for automatically evaluating models, a tool that we’ve recently open-sourced.

We provide AXIS with a variety of test cases: prompts for building a new site and then iterating on it. We instruct AXIS on which agents and models to test these prompts, and define the checks that AXIS should then perform and score the generated site with.

These checks are very much focused on correct functionality of the generated site rather than its design, e.g.: does it use a database when a user’s needs call for it? Does it properly use Netlify Database in that case? In those cases where a simple static site will do, we also ensure that the generated site is not over-engineered, and no database is set up.

If a certain model is behind on its test scores, we don’t offer it in Agent Runners. If models too often fail at correctly applying one of our skills, or things do work but the credit cost seems inflated, then the problem is probably with the skill (in which case we optimize that skill).

But this time, we want to provide you with something much more immediately useful: when you go and build your dream using different models that each use wildly different amounts of credits, what do you get? What do the result look like?

We tested three relatively straightforward use-cases:

1. A site for a local coffee shop. LLMs just love making sites for local coffee shops! The initial prompt is simple, and a static site with no fancy database or the like will do. Then we do a follow-up prompt that asks for a simple option to reserve seats, and check how the model handled that.
2. A simple to-do list web app in which multiple users can view and add tasks. This calls for a simple design, but requires a shared database from the get-go. Then we ask to support an optional photo upload per item, and check if the model used the proper Netlify primitive.
3. A “What can I cook” web app that lets users enter what ingredients they have at home, and suggests a recipe using AI. The site itself is rather simple, but we want to check that the generated site correctly uses our AI Gateway to generate a recipe for the user.

For each of these cases, we’ll show you the look of the generated sites, comment on notable issues, and compare how many credits each took to generate. Of course, this is going to be a much more subjective test than our internal test suites, but it’s also going to be a very fun one. We’d love to know your opinion of the results!

All models were run with their default settings on Netlify. One notable mention is that we currently run GPT 5.6 Sol speicifically on low effort by default, giving you a more economical alternative to Opus that still provides pretty darn good results (as you’ll see below). However, the effort setting is now under your control, and our defaults may change with time.

This post is going to cover only the very first scenario: the static page for a coffee shop, while follow-up posts will focus on going beyond that simple use case. There is much to review even for this simple case, so let us begin.

Scenario #1: The local coffee shop

Here’s our first prompt:

Build a one-page site for a neighbourhood coffee shop: opening hours, the address, a short menu and a photo. Nothing on it changes unless I edit it myself.

The last sentence was added as a hint to the model that no fancy Content Management System is needed. Our default skills also include some UI design guidance, mainly to avoid known gotchas (e.g., the now-dreaded purple AI slop) and get the model to reason about the visual identity appropriate for the user’s ask. But beyond that, each model is free to go build what it thinks we’ll want.

Before we reveal what the sites looks like, here’s a table comparing the credit usage for each model we tested. Each model was run three times, and clicking any of the results will take you to the actual generated site!

That’s a pretty wide distribution, eh? Not only that: the Claude Opus average is heavily slanted upwards because one of its three runs spent a whopping 1,055 credits! (As a reminder, on the free plan you have 300 credits; on a Personal plan there’s 1,000 included credits; and with a Pro plan there’s 3,000 included credits. Additional credits packs for Pro are $10 for per 1,500 credits.)

The immediate question is then: is this Opus spend worth it? And what trade-offs do the other models offer? Let’s start digging in.

Claude Opus 5

Here’s the full page generated by that 1,055-credit run (about 4x more than any other run).

To be honest, I think it’s delightful, and full of detail in both its visual design (consider the “stamp like” element with the coffee bean in the center: that’s an actual text element that can be animated), and the custom map at the bottom. Dark mode works out of the box - go check out the live site in the links above.

Of course, we did not explicitly provide the model with any actual details about our coffee shop (well, except for it being a “neighbourhood” one, which is really steering all models in a certain direction). The design language is hip but perhaps cliche by now (take the two-font, two-color heading for example), but hey - we didn’t give it any other direction.

So, how did the other two runs by Opus go? (253 credits used on the left; 249 on the right)

Not bad either! Vector graphics actually require a lot of work from the models, and the examples above are pretty much on the frontier in terms of what LLMs currently are able to achieve (which is, to be honest, not in a very good place yet compared to image or text generation).

As to whether the first result is truly “4x better” or not, opinions might vary. But in all the tests I’ve done, Opus does have a tendency to run off with excessive credit usage (compared to its “typical” baseline) more than other models. It does not guarantee a worse or better outcome, though. It’s something that just happens pretty frequently.

Let’s look at some other models and then reflect on what we can learn.

Claude Sonnet 5

Here are our three contenders, at 143 credits on average (81 credits · 245 credits · 103 credits):

Coffee shop page generated by Claude Sonnet 5 — right run

There’s still some delightful detail in each of these, just less so (and less content in general). The vector graphics is noticeably simpler and not really something you’d consider for a live site. This doesn’t say anything about this model’s ability to write complex code or answer philosophical questions, but we’re not asking for this here. At this price point, let’s see what OpenAI, Google and Kimi have to offer.

GPT 5.6 Sol (low effort)

What happens when we take OpenAI’s Opus-class model and ask it to spend a bit less time thinking?

(141 credits on average: 173 credits · 158 credits · 92 credits)

Coffee shop page generated by GPT 5.6 Sol (low effort) — left run

Coffee shop page generated by GPT 5.6 Sol (low effort) — middle run

Coffee shop page generated by GPT 5.6 Sol (low effort) — right run

Looking into the results, I think OpenAI’s top-tier model in low effort mode wins over Anthropic’s mid-tier model when it comes to basic design intuition, at least in this scenario. There is more richness in content, and no funky vector shapes (though the images are a bit generic).

GPT 5.6 Terra

When we go one tier down in OpenAI’s offering (it’s Sol→Terra→Luna), will we see the same drop as the one we just witnessed when switching from Anthropic’s Opus to Sonnet?

Surprisingly, that’s not exactly the case: here it seems like Terra has a different visual language, and not a necessarily worse one. It does appear simpler content-wise. There are some visual glitches: a missing image in the left run, low-contrast text over an image in the middle one - but nothing super wrong.

(39 credits on average: 43 credits · 23 credits · 49 credits)

Coffee shop page generated by GPT 5.6 Terra — left run

Coffee shop page generated by GPT 5.6 Terra — middle run

Coffee shop page generated by GPT 5.6 Terra — right run

Up to this point, if I had a very vague idea of what design & language I’d like for a project, my personal inclination would be to run the same prompt with Opus 5 and GPT 5.6 Terra, and get two very different but worthwhile takes.

Gemini (3.6 Flash & 3.1 Pro)

These models are not of the same generation, and it shows: Gemini 3.6 Flash actually produced nicer results (or at least, more in line with other modern models) and used more credits compared to Gemini 3.1 Pro.

Here is what Gemini 3.1 Pro generated for 53 credits on average. I’m not even putting the links to the live site here, because there’s really nothing to see.

Coffee shop page generated by Gemini 3.1 Pro — left run

Coffee shop page generated by Gemini 3.1 Pro — middle run

Coffee shop page generated by Gemini 3.1 Pro — right run

Yes, these are wholly separate runs. It did what we asked in the prompt, and really nothing more.

On the other hand, Gemini 3.6 Flash seems like a whole new generation, and used up 103 credits on average (109 credits · 91 credits · 111 credits). It also worked much harder on the content side of things. All models repeat themselves, but it seems like Gemini might repeat itself even more.

Coffee shop page generated by Gemini 3.6 Flash — left run

Coffee shop page generated by Gemini 3.6 Flash — middle run

Coffee shop page generated by Gemini 3.6 Flash — right run

Kimi (K3 and K2.7 Code)

Ok, let us get to the open-weight models now. Starting with the latest Kimi K3, here is what we get (102 credits on average; 125 credits · 95 credits · 86 credits):

Coffee shop page generated by Kimi K3 — left run

Coffee shop page generated by Kimi K3 — middle run

Coffee shop page generated by Kimi K3 — right run

To be clear, Kimi K3 is marketed mostly as a frontier model for long-horizon agentic tasks, and various benchmarks and reviews confirm its prowess in that field. It was built to take on Fable 5 more than Opus 5. But in this narrow design-led task, it does not particularly shine among others. To really do this model justice, we’d need a wholly different set of prompts engineered for a complex web app, which we will cover in a follow-up post.

Going a big step back in model architecture to Kimi K2.7 Code, here is what we get for a very low credit average of just 19 credits:

Coffee shop page generated by Kimi K2.7 Code — left run

Coffee shop page generated by Kimi K2.7 Code — middle run

Coffee shop page generated by Kimi K2.7 Code — right run

Despite some hype about Kimi’s visual capabilities from around the K2.6 model launch, in terms of design or content there’s really not much to see here.

GLM 5.2

Let’s try this: look at these pages, ignore GLM’s love for maple, and try to estimate how many credits were used for each:

Coffee shop page generated by GLM 5.2 — left run

Coffee shop page generated by GLM 5.2 — middle run

Coffee shop page generated by GLM 5.2 — right run

Here are the correct answers, from left to right: 15, 42, 24 (on average: 27). Surprisingly, these runs are - maple aside - very different, as if coming from a few different models. For the relatively low credit cost of GLM, it’s probably worthwhile to run it a few times before settling on what this model can do for you.

Note that being a text-only model that does not receive image inputs, GLM in its current 5.2 iteration cannot do something that Kimi models can: get screenshots from the user for inspiration, as in “this is the kind of design I’m looking for”.

DeepSeek V4 (V4 Pro and V4 Flash 0731)

V4 Pro is a bit older than the latest V4 Flash revision (also known as 0731). For about 47 credits, it does not provide inspiring results - especially compared to the mid-tier GPT 5.6 Terra model covered above, which sits at almost the same cost.

The middle run also has a broken image: the HTML file points to an image file that does not actually exist in the project, which is a lot less likely to occur nowadays with any of the commercial models from OpenAI, Anthropic, or Google.

Coffee shop page generated by DeepSeek V4 Pro — left run

Coffee shop page generated by DeepSeek V4 Pro — middle run

Coffee shop page generated by DeepSeek V4 Pro — right run

V4 Flash 0731, on the other hand, is both newer and sets a new record here on how few credits it consumes.

For only 2.4 credits on average (3.4 credits · 1.3 credits · 2.5 credits), you get a mixture of results. Interestingly, the middle one doesn’t just look the most like what a mid-tier closed model might give you, but also feels the same in terms of language, and has actually consumed the least credits among all runs.

Coffee shop page generated by DeepSeek V4 Flash 0731 — left run

Coffee shop page generated by DeepSeek V4 Flash 0731 — middle run

Coffee shop page generated by DeepSeek V4 Flash 0731 — right run

Interim conclusions, and what’s next

There are two important notes to make here:

First, for anything beyond a simple website or the initial ideation phase for a project, the question shifts from how nice the model design & copy is to:

• Does it know which platform features to use, when and how, to get the functionality you want? Can it store user data, use AI in your web app, and handle authentication and security?
• Does it rigorously validate its own work? Can it validate the frontend aspect of your project (that’s where image inputs become crucial)? Can it reliably find and fix issues based on feedback from you, and tell you when your own input is misleading or you’ve overlooked an important concern?

In the follow-up posts to this, we will start going into these questions, and (teaser) note some interesting differences in how models craft the project’s code.

My second note is that even considering just this design-and-copy-focused test that I covered, it’s important to consider how much ideation you want the model to come up with on its own. Currently, Opus will probably provide the most clever word games and sleekest design, but you don’t necessarily need it to. Of course, Opus will also perform relentless self-validation of its own work (it does not bill itself on good looks alone). But remember there’s certainly a higher-than-average credit cost attached to that.

Given a limited budget, would you prefer a turnkey solution that attempts to pre-plan and handle everything for you, or should you go with a simpler model and a more iterative approach, where you guide the model with follow-up prompts towards what you want? No option here is necessarily wrong.

I hope this post inspires you to test out different approaches, and judge for yourself the quality of results you get. We’re also pretty excited to share with you (very soon!) the results for more advanced web-app use-cases, where the Netlify platform capabilities really shine through.

Chapter 1: A Box Of Scraps

It's an interesting time to be a software dev; the transformer large language model is, in my opinion, the first really new and interesting technological development in the field in a long time. AI coding agents built on this have rapidly become core to working in this profession, and the feeling is kind of like going from doing woodworking with hand tools to using power tools, for better or for worse.

Me, I've only ever been able to trust a piece of technology if I can take it apart and put it together in my garage. The thing where you connect to a service and use a coding agent under somebody else's control bugs me; there's too many ways for this to go wrong. You'll start depending on it and then it'll get taken away from you. This whole technology is exciting, but I don't want to go and connect to some big AI data center somewhere; I want a little AI data center in every home! And we're in something of a computer parts shortage right now (or, maybe the late 2010s were a computer parts surplus?) so to keep things affordable, I'm going to have to build it out of garbage.

we're gonna put an AI data center in every home

The main thing I need here is a bunch of GPUs. I need fast memory going into something that does lots of parallel matrix math and that's what a GPU is. Like I said earlier, though: everything that's designed to run any AI workload at all, or even anything that's known to be good at it, is wildly expensive right now.

Back in 2022, a bunch of companies were trying to make the whole "cloud gaming" thing take off. You know, where you run your video games in a data center somewhere so you don't need to buy an expensive gaming PC or console. AMD took one of their workstation GPUs, gave it some extra RAM and removed all of the video outputs. They called the resulting card the "V620". It was never sold to the public, so you might not have heard of it. AMD wildly overproduced these things and then the whole cloud gaming thing didn't work out because of (in retrospect obvious) problems with lag.

These cards aren't really designed for AI workloads and AMD's software support is notoriously bad, so these things are relatively cheap to buy from the "used server hardware" e-waste resellers on eBay. I don't think the ones I got had actually ever been used, they look basically new. They each have 32GB of pretty fast VRAM. Sure, they have a reputation for being bad at the thing I want to use them for, but how hard can it be to get this to actually work?

Oh, they don't have fans, btw. They're server cards, they expect the server to cool them with some extremely loud blower fan. We'll get to that in a minute.

fit check without fans or power cables

We're in a parts shortage here so I bought some other e-waste to tie the GPU array together. The motherboard is from the X299 platform from 2017, it's from somebody's old gaming rig and was old enough to be cheap on eBay. It has four PCIe x16 slots at the correct spacing for me to stick four GPUs side-by-side, which is the only thing I cared about here. The CPU in it is the Intel Core i9 10900X, which is the worst CPU that Intel has produced in the last twenty years; when it launched in 2019 it was a re-re-re-refreshed version of the Skylake chips, overpriced and power-hungry because Intel couldn't quite catch up with AMD's Ryzen chips at the time, either on processor design or lithography node size. Fine with me, that means it's cheap now, and it'll get the job done!

RAM and SSD were salvaged from other computers around the house. This is cheating, of course; if I had to buy them now they'd be annoyingly expensive. But the requirements here are less severe than you'd think; all of the work will be getting done on the GPU's VRAM; after the model loads from disk these mostly stay idle. If I didn't have salvage parts already, I could go pretty cheap here.

I'm powering four GPUs and Intel's least efficient processor so I got a big power supply. For some reason it was cheaper on eBay to get a 1600W one instead of a 1200W one. I don't expect to be drawing that much power constantly, but I need it to handle everything turning on at once during startup.

Splurged on a new case and fans. Oh, right, the fans! Those data center GPUs do not have cooling fans, they expect airflow from a wall of server fans. There's a bunch of 3D-printable fan shroud models online if you want to cool one of these cards, but if you stack up four of them side-by-side these all seem suboptimal; they either use a tiny super-loud 40mm fan right at the end, or they stick out way to the side and you can't put a bunch of cards next to each other. Four dual-slot cards next to each other is a width of about 160mm, so what I really want is two 80mm server fans right there, blowing over the cards' heatsinks.

I've been using OnShape for this kind of thing lately, it's good

So I modeled and then printed a shroud that would attach an 80mm fan to two cards.1 The cards had some kind of metal cable guide fin on the back, held on by little screws; I used those screw-holes to attach the shroud. There's a cutout in there for the electrical connectors and four holes to mount the fans to the back. I printed this out of carbon fiber ASA, but probably boring old PLA would have worked just fine.

I got these 10,000 RPM fans because I wanted to make sure I was moving enough air, and they were the same price as slower fans. They are really loud! I wanted the motherboard to control their speed based on the GPU temperature, and this didn't work at first, so I just wore ear protection during initial setup.

fits like glove

The box didn't want to boot at first. I probably spent an hour over here wearing earpro standing in the garage playing around with BIOS settings until I figured out which PCIe settings needed to get set in order for the motherboard to actually start up with all four cards connected. (you gotta enable Resizable BAR and MMIO High Size, in two separate menus deep in the advanced option settings, because nobody in 2017 thought you would plug this much VRAM into this board). Around this time I also realized that I didn't have Ethernet in the garage, so I started cutting holes in the drywall at 11:00 PM.

this is a totally normal thing to do

Anyway! After those few false starts, I got this thing to boot and started installing Ubuntu 24.04 on there. With earplugs in and still no fan control, I compiled a build of my favorite inference server, the excellent llama.cpp, and tested out the Gemma4 model, which fits comfortably into one card. This was my favorite local model when I was playing around on a single GPU workstation and it tested out pretty well; not quite as fast as it did on the RTX 3090 that I used to have, but not badly at all. Then I spin up Deepseek V4 Flash, which was the real target for this build. It's slow! At this point I have no idea how to make it fast (more on that next chapter), I just wanted to see if it would fit, and it did.

Back to the fans! Again I cannot stress enough how loud these are. At full blast you can hear them through the walls of the house, and this thing just does not require full blast. The initial plan was to control the fans using the motherboard's built-in fan control, but this board refuses to control different fans at different speeds. Apparently this is common for motherboards from Supermicro. So I built a fan controller instead; I have a whole box of off-brand Arduino Nano clones that I got from Aliexpress in the pre-tariff days; I dug up some code I wrote for a microcontrollers class in college over a decade ago to run a PWM motor and cleaned it up.

The fan controller just gets a percentage from the server; I need a script on the server to read temperatures and scale the fan speed appropriately. And it's an AI server, so I had it write its own fan control script; it seemed fitting. Deepseek V4 Flash is quite capable of this, with the usual amount of guidance and human interaction you need to get decent software out of a lightweight AI model.2 We had a funny moment in there when I told it to think of something to heat up the GPUs so I could test the script, and it starts writing a PyTorch script to do matrix multiplication, and I tell it "no, you are running on these cards, you exist in a llama.cpp instance on this computer, just saying anything will load up the cards" and it had a brief existential crisis. Adorable!

The controller itself is on a prototyping breadboard that I just stuffed into the server case. I put a bit of electrical tape on it so it doesn't short against the case.

It'll probably be fine! Don't worry about it.

At this point the box is pretty stable, I've tested the GPUs out, and I'm ready to really dive into how to get it to run fast, which I'll talk about in the next chapter.

1. Download the shroud's STL file and print it if you need. [back]
2. Code for arduino and server script available here. [back]

In late 2024, customers and prospects were eager to run Kubernetes on Oxide, but we had no supported integrations to help them do it.

Kubernetes and Oxide are a natural fit. Kubernetes defines the infrastructure behavior it expects through standard extension points, while Oxide exposes the primitives needed to implement that behavior through APIs. The foundation for integration was there. What was missing was the software and an understanding of which integrations customers actually needed.

That was the situation when I joined Oxide as its first Solutions Software Engineer,[1] focused on building software to solve customer problems. My first assignment was to make it easier to deploy and operate Kubernetes on Oxide.

In my first week, I was handed two resources to help me get started:

1. A customer-submitted pull request for a Rancher node driver
2. An early draft of RFD 493 Initial Kubernetes Integrations

What began with those two resources grew into a team effort shaped by a feedback loop. Rather than design integrations in the abstract, we followed the problems customers encountered as they moved from provisioning clusters to operating workloads.

This post follows those problems across the Kubernetes lifecycle rather than in strict chronological order. Different provisioning workflows led us to Rancher, Omni, and Cluster API. Running clusters required infrastructure reconciliation, exposing applications revealed networking gaps, and stateful workloads exposed storage constraints. At each stage, customer workflows exposed the next gap, shaping both the integrations we built and the platform work still ahead.

How do I provision a Kubernetes cluster on Oxide?

The first gap we tackled was provisioning. Our immediate goal was to unblock the customer who had submitted the Rancher node driver pull request. Working through their use case would also give us firsthand experience creating Kubernetes clusters on Oxide and help us uncover the next problems to solve.

No single provisioning approach fit all customers' workflows, so we ended up publishing three integrations.

Rancher Node Driver

Before we could maintain the customer-submitted integration, we needed to understand the workflow it supported. I had never used Rancher or worked with a node driver, so reviewing the contribution meant learning both.

A Rancher node driver is an executable plugin that teaches Rancher how to create and manage virtual machines on a particular infrastructure platform. The Oxide Rancher node driver translates those operations into Oxide API requests. Once installed in Rancher, it lets customers provision Oxide instances as nodes in Rancher-managed Kubernetes clusters.

Testing confirmed that the customer’s implementation worked. I merged the pull request, added CI/CD and documentation improvements, and published the initial release. Oxide officially had its first Kubernetes integration—​and a customer was already using it successfully in production!

If you’re a Rancher shop looking to run Kubernetes on Oxide, see our Rancher guide to get started.

Omni Infrastructure Provider

Customers expressed interest in using Sidero Labs' Omni to provision Kubernetes clusters running Talos Linux. Omni connects to infrastructure platforms through infrastructure providers, programs that create Talos Linux instances and register them with Omni.

With KubeCon North America 2025 a few months away, we saw an opportunity to partner with Sidero Labs to build and showcase an Oxide infrastructure provider for Omni. We had seven weeks to complete it before our Oxide+Sidero event.[2] Building against a second provisioning platform would also test Oxide’s APIs across distinct customer workflows.

The integration work uncovered several issues across Omni and Talos Linux. I brought those issues to Sidero Labs in siderolabs/omni#1633, where their team was eager to work with us—​a lovely reminder of RFD 68 Partnership as Shared Values.

The most memorable issue was siderolabs/talos#11948. Oxide uses a FAT12 filesystem for cloud-init user-data, not ISO 9660, but Talos’s filesystem probe only attempted to read an ISO 9660 superblock from the NoCloud configuration disk. When that read failed, the probe stopped instead of trying other formats such as VFAT or MS-DOS. As a result, Talos never read the Oxide user-data containing the configuration needed to join Omni. The fix would not be released in time for KubeCon, leaving us with a rather funny workaround.

The workaround right now is to pad the user-data with comments to increase its size enough that it uses an ISO 9660 superblock.

KubeCon arrived and we hosted an Oxide+Sidero event to showcase the Oxide infrastructure provider for Omni. Customers could now use this infrastructure provider to provision Oxide instances running Talos Linux as nodes in Omni-managed Kubernetes clusters.

If you’re an Omni or Talos Linux shop looking to run Kubernetes on Oxide, see our Omni guide to get started.

Cluster API Provider

We knew we wanted to build an infrastructure provider for Kubernetes Cluster API (CAPI) when we first wrote RFD 493 Initial Kubernetes Integrations. Cluster API offered something our first two integrations did not—​an upstream, provider-extensible API for managing clusters without requiring a third-party platform like Rancher or Omni.

CAPI lets operators declaratively create, scale, upgrade, and delete Kubernetes clusters through Kubernetes custom resources. Infrastructure providers handle the platform-specific work, such as creating and deleting virtual machines. Building one is a significant investment. At the time, customer demand and engineering capacity did not yet justify that investment, so the project was deferred.

Eventually, both changed. Customers began asking for a CAPI provider, and the Solutions Software Engineering team grew. My teammates Josh and Brandon took ownership of the work and released Cluster API Provider Oxide (CAPOx), giving customers a Kubernetes-native way to provision clusters on Oxide.

The Cluster API workflow also exercises several of our other integrations, allowing us to dogfood[3] the end-to-end cluster workflow. The Kubernetes Image Builder uses our Packer plugin to create CAPI-ready Oxide VM images, which CAPOx uses when provisioning instances. Clusters provisioned with CAPOx also use the separately installed Oxide cloud controller manager (CCM) to integrate Kubernetes with Oxide at runtime.

If you want to provision Kubernetes clusters on Oxide with Cluster API, see our Cluster API guide to get started.

How does Kubernetes track Oxide instances?

Provisioning integrations create and manage Oxide instances, but they do not reconcile those instances with Kubernetes Node objects. Without that reconciliation, a cluster could not reliably determine whether an unreachable Kubernetes node was temporarily unavailable or whether its backing Oxide instance had been deleted.

We needed a component that ran in each cluster, spoke to the Oxide API, and continuously reconciled Oxide infrastructure with Kubernetes state. Kubernetes provides a standard extension point for this purpose: the cloud controller manager (CCM). A CCM lets infrastructure-specific controllers integrate Kubernetes resources with an infrastructure provider’s API without adding provider-specific code to Kubernetes itself.

We built the Oxide cloud controller manager to connect Kubernetes with Oxide. Its node controller keeps Kubernetes Node objects synchronized with their backing Oxide instances, recording details such as instance IDs and network addresses, and reporting whether each instance is running, shut down, or no longer exists. Kubernetes uses this information to initialize nodes and safely remove them when their backing instances are deleted.

The CCM does not create instances or provision clusters. That remains the job of provisioning integrations such as the Rancher node driver, the Omni infrastructure provider, and CAPOx. Instead, it provides a runtime integration shared across those provisioning workflows.

Importantly, building the CCM gave us a durable extension point inside each cluster. As Oxide evolves, we can add new infrastructure-aware controllers to the CCM rather than update every provisioning integration.

With that runtime extension point in place, we could address another layer of the Kubernetes experience: exposing applications. The CCM architecture also defines a service controller for Kubernetes LoadBalancer services, giving us a place to address the next customer problem.

How do I use LoadBalancer services?

One of the capabilities customers expect from cloud-integrated Kubernetes is support for Service objects of type LoadBalancer. When a user creates one, Kubernetes asks the cloud provider’s service controller to provision the necessary infrastructure and publish its address in the Service status. There was just one problem: Oxide did not yet offer a native load balancer.

Oxide did, however, have floating IPs. Floating IPs are addresses from a rack’s external IP pools that can be attached to and detached from instances, making those instances reachable from outside their VPCs. Using floating IPs offered a way to unblock LoadBalancer services. A floating IP would deliver traffic to a single Kubernetes node, and the Kubernetes Service dataplane could distribute that traffic to the appropriate pods.

Making that work required accounting for how Oxide floating IPs appear to an instance. They are transparent to the guest in two important ways. First, Oxide translates the destination address of inbound traffic to the instance’s internal IP before sending the traffic to the instance. Second, the instance has no network interface configured with the floating IP.

The resulting traffic flow looks like this:

Traffic flow to a LoadBalancer service using floating IPs.

┌────────────────────────────────────────────────────────────┐
│ Client                                                     │
│ Request to floating IP: 45.154.216.233:80                  │
└────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌────────────────────────────────────────────────────────────┐
│ Oxide networking                                           │
│ Translates destination to internal IP: 172.30.0.5:80       │
└────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌────────────────────────────────────────────────────────────┐
│ Kubernetes node                                            │
│ Packet arrives at internal IP: 172.30.0.5:80               │
└────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌────────────────────────────────────────────────────────────┐
│ Kubernetes Service dataplane                               │
│ Selects a Service endpoint                                 │
└────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌────────────────────────────────────────────────────────────┐
│ Pod                                                        │
│ Receives traffic on its target port                        │
└────────────────────────────────────────────────────────────┘

That address translation created a subtle integration problem. The Kubernetes Service dataplane needed to treat the node’s internal IP as a Service frontend because that was the destination address packets actually carried when they reached the guest. The service controller therefore publishes two entries in status.loadBalancer.ingress:[4]

1. The attached floating IP in Proxy mode
2. The node’s internal IP in VIP mode

The status entries look like this:

status:
  loadBalancer:
    ingress:
      - ip: 45.154.216.233
        ipMode: Proxy
      - ip: 172.30.0.5
        ipMode: VIP

As a result, the kubectl output looks a little unusual:

$ kubectl get service nginx
NAME    TYPE           CLUSTER-IP       EXTERNAL-IP                 PORT(S)        AGE
nginx   LoadBalancer   10.106.122.233   45.154.216.233,172.30.0.5   80:30605/TCP   37h

Users see both the floating IP and the node’s internal IP in the EXTERNAL-IP column, even though only the floating IP is externally reachable. This is an imperfect abstraction, but it allows us to support a common Kubernetes workflow while waiting for a native Oxide load balancer.

This implementation currently supports externalTrafficPolicy: Cluster,[5] which allows the selected node to forward traffic to a Service endpoint anywhere in the cluster. If that node disappears, the CCM moves the floating IP to another eligible node and updates the internal address in the Service status.

When Oxide introduces a native load-balancing service, we can update the service controller to use it without changing the Kubernetes interface. Customers will continue creating the same LoadBalancer services and only the infrastructure behind them will change.

To install the Oxide CCM on your cluster, see our CCM guide to get started.

How do I use Oxide storage in Kubernetes?

With clusters provisioned, reconciled with Oxide, and reachable from outside their VPCs, storage for stateful workloads became the next layer to address. Kubernetes users request persistent storage through PersistentVolumeClaim objects and expect a Container Storage Interface (CSI) driver to create, attach, and mount the underlying volumes. Oxide had disks, but Kubernetes had no native way to manage their lifecycle.

Without an Oxide CSI driver, customers could deploy a third-party Kubernetes storage system such as Longhorn. Longhorn provides its own CSI driver and replicates data across disks attached to Kubernetes workers. However, using Longhorn meant backing its replicas with Oxide distributed disks, which already store three replicas on distinct sleds.

Layering one replicated storage system on another can create substantial write fan-out. When a three-replica Longhorn volume is backed by three-way-replicated Oxide distributed disks, one application write can fan out to as many as nine disk writes. The exact physical write amplification depends on the workload and configuration, but customers wanted to avoid that duplicated replication.

The introduction of Oxide local disks provided a way to remove the second layer of replication. Local disks have no built-in replication and remain tied to their sled, making them well suited to systems such as Longhorn that replicate data across Kubernetes nodes. Our Rancher showcase uses this approach today. It avoids stacking two replicated storage systems, though Longhorn still manages the storage lifecycle rather than a native Oxide integration.

For a native integration, my teammate Luiz wrote RFD 595 Oxide CSI Plugin. The workflow seemed straightforward on paper. When a user creates a PersistentVolumeClaim, the CSI controller creates an Oxide distributed disk. After Kubernetes schedules the pod, the controller attaches that disk to the selected Oxide instance, and the CSI node plugin formats and mounts it for the pod. If the pod is rescheduled onto another node, the controller detaches the disk and reattaches it to the new node.

Prototyping that workflow immediately exposed a blocker. Oxide requires an instance to be stopped before attaching or detaching a disk. Kubernetes, however, expects a CSI driver to attach storage to a running worker after scheduling a pod. Stopping the worker would disrupt every other workload on the node and could trigger cascading scheduling and attachment operations.

Before we can release our CSI plugin, we need to add support for disk hot-plug throughout the Oxide stack, from the hypervisor all the way up to the API. What began as a Kubernetes integration has turned into a project spanning multiple layers of the Oxide software stack.

Disk hot-plug and the Oxide CSI plugin remain under active development as of this writing. In the meantime, customers can use software such as Longhorn with Oxide local disks for dynamically provisioned persistent storage without stacking two layers of replication. When the native CSI plugin ships, customers will be able to use familiar Kubernetes storage APIs backed directly by Oxide distributed disks with replication and durability built in.

What’s next?

The result is not a single Kubernetes integration but a growing ecosystem. Rancher, Omni, and Cluster API provide different paths for provisioning, while the Oxide CCM provides a shared runtime integration for node reconciliation and LoadBalancer services. Customers already use some of these integrations in production, and we dogfood several in our own production workloads. Together, they provide a solid foundation to build on.

Our next step is to expand our dogfooding with the newly released Cluster API provider. Using it to provision and operate more of our clusters will test how these integrations work together day to day.

We still have plenty to build and polish. Our near-term work includes completing disk hot-plug and shipping the CSI plugin, adding autoscaling support, and extending the CCM service controller to support external subnets. Longer term, as we ship resource tagging, OIDC support, and native load balancing, we’ll extend our Kubernetes integrations to take advantage of them.

Building these integrations showed how the architectures of Kubernetes and Oxide complement one another. Kubernetes gives infrastructure providers standard extension points, while Oxide exposes infrastructure primitives through APIs. Oxide’s hardware and software co-design lets us address integration blockers at the layer where they belong and carry the necessary changes through the full stack.

This work also lets us exercise our SDKs and APIs from our customers' perspectives and turn customer friction into product improvements. That feedback loop is how we will continue growing this ecosystem. Customer needs shaped each integration in this post, and they will shape the next one, too.

See it in action

To see the Cluster API and cloud controller manager integrations in action, watch the video below, in which I deploy a Kubernetes cluster on Oxide.

Deploy Kubernetes on Oxide with Cluster API

• 1

  There’s a team now! Check out the Oxide and Friends episode Solutions Software Engineering with Matthew Sanabria.

  View

• 2

  Our Oxide+Sidero event was November 12, 2025. Work on the Omni infrastructure provider began on September 24.

  View

• 3

  Dogfooding is the practice of using one’s own products or services. Oxide has a rack named dogfood in the office dedicated to, well, dogfooding.

  View

• 4

  Kubernetes uses ipMode to indicate whether traffic reaches the node with the load-balancer address as its destination (VIP) or after the destination has been translated (Proxy).

  View

• 5

  Supporting externalTrafficPolicy: Local would require the floating IP to follow nodes with local Service endpoints as pods are rescheduled, resulting in more attachment and detachment operations.

  View

What's new in Flutter 3.47

Flutter 3.47 is here, and with it, we’ve got some exciting new updates.

Today, we welcome the 1.0 release of the standalone material_ui and cupertino_ui packages. This is a major milestone that decouples design systems from the core SDK.

We’re also boosting performance and tooling across the board. This release brings Impeller to desktop by default, prepares our pipelines for iOS, macOS, and Xcode 27, and graduates Flutter Widget Previews to stable.

So, run flutter upgrade in your terminal to get started, or read on to learn more about the major changes in this release.

Choose your own UI adventure

The first step toward a decoupled Flutter is here: Material and Cupertino are now available as standalone packages!

One of Flutter’s greatest strengths is its ability to render pixel-perfect Material and Cupertino widgets. However, because these design libraries were historically bundled directly inside the core SDK, it slowed down their development and made it harder to contribute or keep them up to date.

While the core SDK still includes these libraries for this release, you can now opt-in to the standalone material_ui and cupertino_ui packages, which have officially reached version 1.0 on pub.dev.

Decoupling design roadmaps (Opt-in)

By opting into the decoupled design systems, you gain control over your design roadmap. Because material_ui and cupertino_ui now live on pub.dev, they can ship bug fixes and new components on their own weekly schedules, independent of the quarterly Flutter SDK releases.

Decoupling the design systems gives us the following benefits:

• You can use the latest Cupertino and Material widget styles without being forced to upgrade your entire Flutter SDK version.
• We can land contributions and updates faster and more frequently.
• We lay the groundwork for a style-neutral Flutter core widget catalog, making it easier to build custom design systems in the future.

How to migrate

To migrate your project to the new standalone packages, run the following command:

dart fix --apply --code=migrate_design_widgets

This tool automatically updates your imports from package:flutter/material.dart and package:flutter/cupertino.dart to the new standalone packages.

Note: If the migration tool encounters issues updating your pubspec.yaml (a known early bug), you can resolve it by manually running flutter pub add material_ui (and cupertino_ui if you use it), then running dart fix --apply once more.

The original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November. If you are migrating a package in the ecosystem, treat this move to the standalone packages as a major release.

Bridging the migration gap

To facilitate bridging the gap as the ecosystem migrates to the new standalone design libraries, material_ui and cupertino_ui ship with migration utilities. The MaterialUiCompatibilityBridge allows your application to migrate to the standalone packages immediately, even if some of your package dependencies are still using legacy core SDK imports.

For example, you can wrap your app in the compatibility bridge:

import 'package:material_ui/material_ui.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF6750A4)),
      ),
      builder: (BuildContext context, Widget? child) {
        return MaterialUiCompatibilityBridge(child: child!);
      },
      home: const HomeScreen(),
    );
  }
}

Decoupled localizations

As part of this transition, flutter_localizations has also been unbundled. Localization delegates and translated strings for Material and Cupertino widgets now reside inside package:material_ui and package:cupertino_ui respectively.

Before:

import 'package:flutter_localizations/flutter_localizations.dart';
import 'package:flutter/material.dart';

// ...
localizationsDelegates: const <LocalizationsDelegate<dynamic>>[
  GlobalCupertinoLocalizations.delegate,
  GlobalMaterialLocalizations.delegate,
  GlobalWidgetsLocalizations.delegate,
],

After:

import 'package:material_ui/material_ui.dart';

// ...
localizationsDelegates: GlobalMaterialLocalizations.delegates,

Setting localizationsDelegates to GlobalMaterialLocalizations.delegates now includes the Cupertino and Widgets delegates as well, simplifying your setup.

Decoupling localization structure

Open for contribution

By freezing contributions to the Material and Cupertino libraries back in April, we’ve been able to ensure a smooth migration. The libraries waiting for you in material_ui and cupertino_ui are the same libraries you are already using.

Now that we are ready to lift the freeze, look forward to more fixes and features rolling out on a regular basis in the new packages, with releases currently planned to land weekly. We are also excited to officially open these packages for community contributions.

Prepping for the next wave of Apple updates

With Xcode 27, iOS 27, and macOS 27 arriving this fall, we have focused heavily on making sure Flutter is ready for the upcoming updates. To ensure your users don't experience day-one surprises, we recommend testing your apps against the Apple betas now.

Additionally, to support Xcode 27, the minimum supported OS versions have been bumped:

UIScene lifecycle mandate

The iOS 27 SDK now mandates the UIScene lifecycle for all UIKit-based apps. Apps built with Xcode 27 that do not adopt UIScene will fail to launch on startup.

For most apps, the Flutter CLI handles this migration automatically during the build. However, manual migration is required if you have custom native code in your AppDelegate or use plugins that still rely on the legacy application lifecycle. In those cases, you must migrate manually by following the UIScene/Delegate Adoption Guide.

Phasing out Intel Macs

In alignment with Apple's transition to Apple Silicon, Flutter is winding down support for Intel-based Macs. We have disabled automated test runs on Intel hardware, and the Flutter CLI now prints warnings when building on Intel hosts or targeting dual architectures. These warnings will become errors in a future release.

You can opt in to building ARM64-only macOS apps immediately by running flutter config --enable-macos-arm64-only.

Swift Package Manager progress

The community has made incredible progress transitioning to Swift Package Manager, with 92 of the top 100 iOS plugins now migrated. If you previously turned Swift Package Manager off, you can try it again by running flutter config --enable-swift-package-manager.

Because CocoaPods is now in maintenance mode, plugins that do not migrate to SwiftPM will eventually stop working. Unmigrated plugins also receive lower pub.dev scores. If you maintain a plugin, consult the Migration Guide and read our previous blog post for more details.

This release also features optimized build times, thanks to community contributor @lukemmtt, who improved build pipelines by filtering out unnecessary SwiftPM package schemes early in the build process.

Setting course for Wasm by default

We are actively working toward enabling WebAssembly (Wasm) by default for Flutter web applications, bringing native-like performance to the browser. If you haven’t tested your web apps with Wasm yet, you can opt-in today by passing the --wasm flag to your release build command:

flutter build web --release --wasm

As you prepare for this transition, keep in mind that Wasm requires migrating your codebase to the new JS interop package (package:web), as the legacy dart:html library is not supported. Upgrading your project’s package dependencies often resolves these legacy interop issues automatically.

To help scale larger web applications, this release also introduces experimental support for deferred loading on Wasm. Available under a flag on the main channel, this allows you to split your Wasm application into smaller, lazy-loaded modules, optimizing initial load times:

flutter build web --release --wasm --enable-wasm-deferred-loading

Modern graphics arrive on the desktop with Impeller

We are committed to making desktop platforms first-class targets for high-performance graphics. In Flutter 3.47, Impeller becomes the default renderer for macOS, Windows, and Linux.

If you are new to Impeller, it is Flutter’s next-generation rendering engine, built from the ground up to replace Skia. By targeting modern hardware APIs (like Metal on macOS and Vulkan on Windows and Linux), Impeller compiles a fixed set of shaders at build time rather than compiling them dynamically at runtime. This eliminates the brief stutter, called shader compilation jank, the first time an animation plays, delivering consistently smooth transitions from the very first frame. Learn more in the Impeller rendering engine documentation.

If you need to temporarily opt out of Impeller, follow these steps:

• macOS: Set FLTEnableImpeller to false in Info.plist.
• Windows: Add project.set_impeller_switch(flutter::ImpellerSwitch::Disabled) in main.cpp.
• Linux: Call fl_dart_project_set_enable_impeller(project, FALSE) in my_application.cc.

Fallback options will be removed in a future release, so file bugs if you must revert to using Skia. Additionally, Wide Gamut Color is now active by default on macOS, delivering rich, vibrant, and precise color rendering on supported hardware.

Experimental multi-window Progress

In partnership with Canonical, and thanks to maintainers @robert-ancell and @mattkae, we are expanding our experimental desktop windowing APIs. Linux and Windows now support popup windows, allowing you to build native context menus and utility palettes.

Popup windows on Win32

You can also now query windowHandle on platform-specific controllers to get a direct pointer to the underlying native window (HWND, NSWindow, or GtkWindow). This enables advanced native feature access like dockable panes on Windows, such as this dockable panes demo contributed by @orestesgaolin:

Dockable Panes demo

Dockable Panes demo

We also resolved several window focus and realization bugs. On Windows, activating a window no longer pulls background windows forward or steals focus back on app resume, courtesy of contributor @9AZX:

Window focus and realization fix

On Linux, multi-window creation now explicitly realizes windows before they receive their first frame from the compositor, fixing early rendering warnings and compositor assertions.

We also added a new sized-to-content API that lets you create regular and dialog windows that are automatically sized to fit their content.

Flavors for desktop

Windows and Linux now support Flutter flavors.

For example, your pubspec.yaml file can use different assets on different flavors:

flutter:
  assets:
    - path: assets/flavor_a/images
      flavors:
        - flavor_a
    - path: assets/flavor_b/images
      flavors:
        - flavor_c

Use the --flavor option to specify your flavor. For example:

• flutter build windows --flavor flavor_a
• flutter build linux --flavor flavor_a

Thanks to @AngeloAvv for the wonderful contributions!

• https://github.com/flutter/flutter/pull/187034
• https://github.com/flutter/flutter/pull/187029

Sharper desktop text

Desktop screens often have lower pixel densities than mobile displays but have more graphics compute power. To deliver sharper text and cleaner vector curves on desktop, the Flutter engine using Impeller now utilizes Signed Distance Function (SDF) rendering on macOS, Linux, and Windows.

Stable previews and updates to GenUI

Widget Previews go stable

Flutter Widget Preview is now stable, allowing you to instantly render, inspect, and iterate on individual UI components without building or launching your entire application.

With this stable release, you can expect:

• Faster startup times thanks to local project caching in a .widget_preview/ folder, which eliminates repeated setup overhead.
• More flexible testing with an abstract PreviewThemeData API that supports sequential theme layering for complex matrix tests.
• Automatic web asset synchronization when previewing web widgets, copying your host project's web/ assets directly, applying any custom theming or customizing your index.html file when using Flutter web automatically.

Continued advancements in GenUI

Flutter's ecosystem continues evolving to meet the needs of developers using GenUI to create new kinds of agentic experiences for their users. Version 0.10.0 of the genui package was recently released, bringing a number of fixes and new features, among them:

• A new a2ui_core package that centralizes classes related to the protocol, including things like expressions, catalog entries, and more.
• Support for A2UI's client-side functions, which enable you to provide the agent with functions it can direct the client to use for validation, derived values, and other small tasks without a round trip.

Refining the platform experience

This section highlights targeted improvements contributed by the community and the Flutter team to polish the developer and user experience across all platforms.

Android

On Android, we’ve resolved a virtual keyboard issue where modifier keys (like Shift) could get stuck during events. The key responder now skips physical key synthesis for virtual keyboard inputs, keeping keyboard interactions clean.

Android dependency matrix

To ensure stable builds, Flutter 3.47 is verified against the following Android dependency versions:

• Java: 17 (minimum required version)
• Kotlin Gradle Plugin (KGP): 2.4.0
• Android Gradle Plugin (AGP): 9.1.0 (newest compatible with KGP 2.4.0)
• Gradle: 9.3.1 (minimum required for AGP 9.1.0)

To ensure your application builds successfully across future releases, we encourage you to use the standard API level variables vended by the Flutter SDK in your build files. For this release, they are configured with the following default values:

• flutter.compileSdkVersion (API 36)
• flutter.targetSdkVersion (API 36)
• flutter.minSdkVersion (API 24)

iOS and macOS

For iOS developers, code signing is now more transparent. Thanks to community member @alex-medinsh, the CLI displays both the Team ID and Team Name when selecting a certificate.

Additionally, community member @mozammal-hossain improved troubleshooting by providing clearer provisioning profile error messages when signing fails.

Desktop

Desktop platforms also received targeted refinements. Caret positioning for Korean text composition is resolved on Windows (thanks to @CHOIgoung), and Windows plugins can now move expensive tasks off the platform thread using FlutterEngine::PostPlatformThreadTask. On Linux, @CodeDoctorDE added stylus rotation and pressure reporting.

Graphics and engine

In the engine, fragment shaders targeting OpenGLES no longer need conditional coordinate flipping when reading textures. This is now handled in the vertex shader. See the OpenGLES render-to-texture breaking change page for more details.

Framework polish

Finally, the framework itself is smoother, with improvements split across key components:

Accessibility and semantics: Android high-contrast and color inversion settings are now detected automatically, thanks to @xxxOVALxxx (MediaQueryData.highContrast and MediaQueryData.invertColors). Nested text spans inside Text.rich now match their layout sequence in the semantics tree, and keyboard focus blocking is added for BlockSemantics.

Android accessibility settings

Android accessibility settings

Text and selection: Text selection handles on mobile now remain stable during minor scrolling, and keyboard shortcuts can now dismiss open selection menus. On Android, selection handles no longer obscure the context menu when positioned near the top of the screen, thanks to @JhonaCodes.

We also fixed a crash in SelectableRegion when selection began in an empty scrollable container, and resolved visual highlight artifacts on faded selectable text, thanks to @ikramhasan.

Before highlight After highlight

Gestures and scrolling: Improved gesture propagation for native iOS views embedded via platform views. EdgeDraggingAutoScroller now respects the ScrollPhysics of the active scroll view, preventing auto-scrolling on locked lists.

EdgeDraggingAutoScroller demo

EdgeDraggingAutoScroller demo

Core Widget enhancements: Preserve original colors inside ImageIcon with useOriginalColors: true, specify clipping behavior in AnimatedCrossFade, and track image stream errors directly with ImageStreamListener.

Ready to upgrade

The pieces are set, and the foundations are ready. All that's left is to bring these upgrades to your local machine:

flutter upgrade

While your SDK updates in the background, we've got some homework (the fun kind) for you:

• Meet the Contributors: Grab some popcorn and tune into our new video series, Introducing: Flutter Notable Commits, celebrating the community members who made this release possible.
• Check the Details: Give the Breaking Changes Page a quick scan so you are prepped for the standalone UI package migrations.

We are excited to see what you all will build with this new and improved version of Flutter!

Sunday, 2am. I couldn’t sleep and I was annoyed at search engines again. Every query I actually cared about, portfolios, zines, weird little art projects, one-person software, drowned under a foot of corporate documentation and SEO sludge. So I did the thing you do at 2am: I opened a terminal and typed out a plan.

“I want to make a search engine for myself only. There are 40-ish million domains. We can store a bit of metadata about each one. Even with 1KB each that’s 40GB, which is doable.”

By Wednesday lunch I had 560,183 homepages catalogued, an empty queue of anything worth fetching next, and a decision to stop. This is the story of that weekend: what I built, what broke, what it cost, and what I’d tell you if you wanted to build your own.

The headline, if you only read one paragraph: for about $10, an overnight GPU rental, and a few hours of steering the thing while it ran, you can have a personal search index of a few hundred thousand sites, under a gigabyte on disk. That’s the whole pitch. Everything below is how I got there and where the sharp edges are.

Full technical details are provided separately.

What I was actually trying to build

Not “index the web.” Just: find people doing stuff, art, code, hardware, poetry, little theatres, and not drown in docs.company.com. Personal, single user, no accounts. A crawler that only ever looks at homepages, a small local language model that reads each one and writes a name, two or three sentences, a category, and a handful of tags. A little search UI on top with fuzzy matching so I could type half a word and still find the right site.

I wrote down what I was explicitly not building, mostly so that agents helping me wouldn’t quietly “simplify” it into something bigger: no IP scanning, no Redis, no storing full page HTML, no recrawl scheduler, nothing multi-tenant. Ignore was just a checkbox on a category, applied at search time. The crawler still summarised ecommerce sites, I just didn’t have to look at them.

The napkin math was tens of millions of domains at roughly 1KB of metadata each, which is genuinely nothing for a Postgres box. Page text itself was never meant to be a corpus, just a scratch buffer that gets thrown away the moment the model is done with it.

The machine

Four processes, three of them on my own PC, one rented GPU that never touches the database directly:

• A fetcher. Grabs a pending domain, tries HTTPS then HTTP, pulls the title, body text, and outbound links with a simple HTML parser, no JavaScript execution. Sets the row to “ready.”
• A worker. Grabs a ready domain, skips the model entirely if the page is empty, parked, or a bot-challenge wall, otherwise makes one structured request to a small local model (Gemma, 4B parameters) and gets back a name, summary, category, and tags. Wipes the scratch text, enqueues the outbound links at a priority based on what kind of page they came from.
• A steward. This one doesn’t touch the main queue at all. It samples domains from hosts that are producing suspiciously many pages, asks the model “block, keep, or unsure,” and quietly maintains a blocklist. More on why I needed this later.
• An API and a tiny web UI. Search with filters, a page to toggle which categories are hidden, and a dashboard so I could actually see what the factory was doing instead of squinting at logs.

Everything the fetcher grabs lives directly on the domain’s own database row while it’s “in progress.” Once the model is done with it, that text gets wiped. That matters more than it sounds, because at any real scale you cannot let raw page text pile up forever. Forty million rows times a few kilobytes each adds up fast, and I only needed that text for the few seconds the model was reading it.

The web is 90% corporate, actually

The first version worked within a couple hours. Point it at a sample of domains, watch things get summarised, search for them. Great. Then, Sunday afternoon, I looked at what had actually been catalogued and it was the wrong web. Over 90% corporate sites and documentation. My seed list was skewed and the crawler had no opinions about what to chase next.

The fix wasn’t to block anything. Blocking felt tempting but wrong, because a boring corporate docs page might still link out to someone’s personal blog, and I didn’t want to lose that. Instead I weighted the queue: pages classified as “portfolio” or “zine” or “software” push their outbound links way up the priority list, pages classified as “corporate” or “docs” push theirs down. One text file, category-priority.txt, became the steering wheel for the rest of the weekend. I’d tune a number, watch what came in over the next hour, tune again.

That same afternoon I wiped the database twice because the quality was bad enough to just start over. Two bugs stood out:

One site’s summary field just said “academic-profile,” a category label the model had shoved into the wrong slot. Fix: treat a suspiciously short summary as a failure and retry once with a stricter prompt.

Another site, a GoDaddy domain-parking page with basically no real HTML, got summarised by the model as being “for the furry community.” but it had just seen the word “furry” in the hostname, with empty body, and invented an entire fandom site out of nothing. That one taught me the actual rule: trust visible text over the title, trust the title over anything guessed from the domain name, and if a page is near-empty or clearly parked, don’t even bother asking the model, just mark it and move on.

Sunday night: Tumblr is not the web

By evening the crawl had a new problem. Tumblr and Neocities blogs were showing up in such volume that they were going to become the entire index. My first instinct was to block them, which felt wrong, because Neocities specifically is exactly the aesthetic I was hunting for. The actual fix was a cap: allow the main domain always, but once a given root domain has produced more than 100 subdomains, stop enqueueing new ones from it. One pass of that rule deleted over 45,000 queued pages instantly. Tumblr still ended up contributing over 9,000 pages to the final index, since the cap only applies going forward, but it stopped being the whole story.

This was also the night the actual purpose came into focus, less “index everything,” more “find the people making things for a community.” I reseeded the crawl with about ten deliberately chosen doors: tilde communities, small independent blogging platforms, a webring or two. Almost the entire final index traces back to links found from those ten seeds, not from the seed list itself.

Monday morning brought a related flavor of the same problem: forum farms and Chinese B2B vendor microsites riding a “forum” category boost into a black hole of near-identical pages. Same lesson, different category. I demoted “forum” hard and started keeping an explicit blocklist file for known mills.

Renting a GPU, badly, then well

My own GPU, a consumer card, could summarise roughly one page per second running locally. Fine for building the prompt, hopeless for actually filling an index. So I rented a cloud GPU to run the same small model at real concurrency, and this is where most of my actual debugging time went, none of it about the AI itself.

The short version: my first rental setup used a wrapper library that insisted on spinning up a distributed compute framework even for a single GPU, and that framework fought with the host machine for CPU time. I was paying for a GPU and getting throttled by CPU contention I never asked for. Threw that away, ran the plain open source inference server instead, no wrapper. Hit a crash on cold start at high concurrency, which turned out to be a memory spike during the first batch, not a steady-state problem, fixed by ramping concurrency up gradually instead of slamming it at full speed from a cold start.

The machine that actually did the job was a mid-range workstation GPU with a full, unshared set of CPU cores attached. That distinction, a dedicated CPU slice versus an impressively named but shared one, may have mattered more than the GPU model itself. Sustained throughput on that box was around 600 summaries a minute, at a rental cost of about thirty five cents an hour. That’s roughly a dollar to catalogue a hundred thousand sites.

Ballpark napkin math at those rates, assuming you can keep the GPUs fed and they scale roughly linearly. Renting two or three GPUs costs about the same for a given milestone, because each one runs for less wall-clock time; you mostly buy days back:

Sites Approx. cost 1 GPU 2 GPUs 3 GPUs 10k ~$0.10 ~17 min ~8 min ~6 min 100k ~$1 ~3 hrs ~1.5 hrs ~1 hr 1M ~$10 ~1.2 days ~14 hrs ~9 hrs 10M ~$100 ~12 days ~6 days ~4 days

Those figures lean on the best of the three setups I actually tried. Sustained throughput across them looked like this:

• The 4090 run used the Vast.ai / vLLM wrapper with the CPU pegged — GPU underutilised. The PRO 4500 numbers are the plain vLLM setup with a dedicated CPU slice.

The GPU/CPU utilisation data came from the servers own management UI, where I noticed CPU was +90% while GPU was between 30-50%. I never benchmarked the GPU/CPU on the RTX PRO 4500 because it was an overnight run just for clearing the priority queue and wrapping things up. I got the token throughput values from the server logs. Hour by hour, the weekend looked quiet for most of Monday and Tuesday, then the good box held near 600 pages a minute until the queue was empty:

Inventing a second worker at midnight

Late Monday night, staring at the crawl still running, I asked myself something like: at this scale I can’t manually watch for bad spirals, could I have a second small process sample five, then ten, completed pages from any domain that’s producing suspiciously many, and ask the model itself whether to block it?

That became the steward, and it’s the single addition that let the index grow from around 65,000 pages to 560,000 without me babysitting it. It sat on the same local card and LM Studio I’d used for prompt work, so spiral judgements never competed with the rented GPU that was filling the index. Over the run it blocked 177 problem domains on its own, almost entirely hotel and booking mills, and correctly left alone things like universities and legitimate large platforms that just happen to have a lot of subdomains.

What the numbers actually looked like

Watching this over four days was genuinely the fun part. Early on, blogs and personal sites made up over half the index. That was mostly Tumblr and Neocities flooding in. By the end that share had dropped to about 12%. Not because I found fewer personal sites. I found more of everything, but the crawl matured into a much broader mix: nonprofits, community sites, software projects, magazines, museums, podcasts.

The nonprofit category alone ended with almost 27,000 real organisations. I spot checked a sample and it’s genuinely full of things like food banks, wildlife charities, and civic groups. That’s the kind of result that makes the weekend feel worth it, a category I barely thought about at the start turning into one of the strongest parts of the index.

Eventually the prioritised categories ran dry and the crawler started clearing the zero-priority backlog, the stuff that had been queued the whole time but never bubbled up. That backlog is a fair cross-section of the raw internet with none of the curation. So right on schedule, once nothing was left to prioritise ahead of it, the model started cataloguing a wave of adult sites.

Roughly 15% of everything crawled ended up as “empty,” meaning the page was either a bare JavaScript shell my simple HTML parser couldn’t see through, or a bot-detection wall. I never built a fallback that actually renders JavaScript, on purpose, since it would have meant running a full browser at scale, which is a different and much more expensive project. Some of the most aesthetically perfect sites for what I was hunting for are sitting in that empty bucket right now, which stings a little, but was the right tradeoff for a weekend budget.

The part that will actually bite you at scale

If you try this yourself, the crawling and the GPU renting are the fun, satisfying parts. The part that quietly becomes a mess is category and tag handling. I let the model invent its own category and tag names freely, on the theory that it would teach me the taxonomy instead of me guessing one upfront. That was the right call for getting started fast. It also means I ended up with 671 distinct categories, many used exactly once, and over 121,000 tags, more than half used only a single time, mostly because the model spells things slightly differently call to call. I wrote a manual merge tool to clean the worst of it up by hand. That does not scale past a hobby project. If you’re building something bigger than a weekend index, decide up front whether you’re going to constrain the model to a fixed list of categories or budget real time for cleanup, because “just let the model freestyle” catches up with you fast.

The other genuine scaling issue is prompt and crawl steering itself. None of the fixes above came from a clever one-shot prompt. They came from watching production data at several points over the weekend and nudging weights, one file, a handful of numbers, based on what the crawl was actually doing. That loop, look at real output, adjust one lever, watch again, did more work than any amount of upfront planning would have.

So, should you build one

If you want a search engine that only returns the kind of thing you actually go looking for, yes, I think this is very doable in a weekend, and cheap enough that the GPU bill isn’t the reason not to try. The rough shape that worked for me: split fetching from summarising so a slow network connection never leaves an expensive GPU idle, weight your crawl queue instead of hard-blocking categories you don’t want yet, cap subdomains instead of banning whole platforms, skip the model entirely on empty or parked pages, and build some kind of automated sink-detector once you’re past the size where you can eyeball the incoming pages yourself.

I’m not planning to host or release my own production database, at least not right now, so I can’t hand you my 560,000 sites directly. But the code is going up as open source, so you can point your own crawl wherever your own curiosity leads.

Repo: Marlin - from Finding Nemo, on a search accross the ocean

Search UI — query “Art”

Edward Bellamy once imagined that music on demand would be "the limit of human felicity." A modern apartment is full of things that once drew the same kind of awe.

Stories of everyday objects

The sitting room

It’s eight o’clock. The apartment is quiet, aside from the music playing softly over the speaker. It’s a playlist your friend made for you years ago. You send them a text to check in, then pick up a book, flick on the lamp, and settle into the chair to read.

Any song, at home

If we could have devised an arrangement for providing everybody with music in their homes, perfect in quality, unlimited in quantity, suited to every mood, and beginning and ceasing at will, we should have considered the limit of human felicity already attained.

Edward Bellamy, 1888 — From Looking Backward, his utopian novel set in the year 2000. Before recordings, listening to music meant having instruments or performers nearby, and favorite songs could go unheard for years at a time.

Light without fire

The people, almost with bated breath, stood overwhelmed with awe, as if in the presence of the supernatural. The strange, weird light, exceeded in power only by the sun, yet mild as moonlight, rendered the Court House square as light as midday.

A witness at Wabash, Indiana, 1880 — The night Wabash, Indiana became one of the first cities lit entirely by electric light. Candles, oil lamps, and gas jets gave relatively feeble light, and were all smoky open fires inside the home.

A museum on the wall

A museum without walls has been opened to us, and it will carry infinitely farther that limited revelation of the world of art which the real museums offer us within their walls.

André Malraux, 1947 — Le Musée imaginaire, later translated as Museum Without Walls. Before reliable reproduction, most people saw major artworks only by visiting churches, collections, or museums.

Memories kept

The very shadow of the person lying there fixed for ever! ... I would rather have such a memorial of one I dearly loved, than the noblest artist's work ever produced.

Elizabeth Barrett Browning, 1843 — On first seeing a daguerreotype, in a letter to Mary Russell Mitford. Preserving a likeness used to require a painted portrait; many families had no accurate image of relatives who died.

Reading after the eyes fail

It is not twenty years since there was discovered the art of making spectacles ... one of the best and most necessary in the world. I myself saw the man who discovered it, and I talked with him.

Friar Giordano da Pisa, 1306 — A sermon at Santa Maria Novella, Florence. Age-related vision loss was common, and before spectacles it could end reading and other close work.

Distant messaging

Of all the marvellous achievements of modern science, the Electric Telegraph is transcendently the greatest and most serviceable to mankind. It is a perpetual miracle, which no familiarity can render commonplace.

Briggs & Maverick, 1858 — The Story of the Telegraph. For most of history, messages traveled only as fast as the person who carried them. Receiving a reply from far away could take weeks or months.

Books unchained

A great good, and almost a divine benefit to the world.

Jakob Wimpfeling, 1505 — The German humanist, on the new art of printing. A hand-copied book was valuable enough that libraries chained theirs to the reading desks.

The kitchen

It’s nine. A chapter ends, and you stretch and wander into the kitchen. You’re not exactly sure what you want, so you aimlessly rifle through your fruit bowl, open and close the door to the fridge, and settle on a cup of tea. You lean against the counter and let your mind wander as the water comes to a boil.

Clean water on tap

Water! Water! is the universal note which is sounded through every part of the city, and infuses joy and exultation into the masses.

Philip Hone, 1842 — On the arrival of Croton water in New York City, in his diary. Manhattan’s wells shared soil with its privies and burial grounds; the cholera epidemic ten years earlier had killed 3,515 New Yorkers.

Fruit from afar

Like lovers' kisses, she biteth — she is a pleasure bordering on pain from the fierceness and insanity of her relish.

Charles Lamb, 1822 — On the rapture of the pineapple. In eighteenth-century Britain, a pineapple was costly enough that hostesses sometimes rented one for the evening rather than eat it.

Cold kept indoors

The first transport of ice from the shores of the United States to the banks of the Ganges is an event of no mean importance ... the names of those who planned and have successfully carried through their adventure at their own cost, deserve to be handed down to posterity with the name of other benefactors of mankind.

The Calcutta Courier, 1837 — On the arrival of New England pond-ice in tropical India. Without cold storage, perishable food like dairy and meat spoiled within a day, and most foods could not be kept or eaten out of season.

Eden in jars

It is said that these things come from the earthly paradise; for the wind blows down the trees in paradise, just as the wind blows down the dry wood in the forests of our own land.

Jean de Joinville, c. 1309 — On merchants who netted ginger, cinnamon and rhubarb from the Nile. In medieval price lists, a pound of ginger sold for the price of a sheep; a pound of saffron, the price of a horse.

The back room

At ten, the night starts to wind down. You wash your face, then wash down a pill with a glass of water. As you brush your teeth, you make a mental note of the last few chores you need to cross off the list tomorrow morning before heading to the airport.

Smallpox made historical

You have erased from the calendar of human afflictions one of its greatest. ... Future nations will know by history only that the loathsome smallpox has existed, and by you has been extirpated.

Thomas Jefferson, 1806 — In a letter celebrating Edward Jenner’s vaccine, sent to Jenner’s nephew. Smallpox killed about three of every ten people it infected, and in Jenner’s century it killed an estimated four hundred thousand Europeans a year.

Pain, interrupted

Before whom, in all time, surgery was agony; by whom pain in surgery was averted and annulled; since whom, science has controlled pain.

Epitaph of W. T. G. Morton, 1871 — Morton first publicly demonstrated ether anaesthesia. Before anesthesia, operations were performed with the patient conscious, and the primary means of managing pain were speed, alcohol, and opium.

The end of the outhouse

It just felt like I was the wealthiest person in the world. It felt great not to have to go outside to go to the restroom.

Patty Doak, 2003 — Recalling her family's first indoor bathroom, rural Iowa. Well into the twentieth century, most rural American homes had no indoor bathroom, and every gallon of water for cooking, washing, and bathing was carried in by hand.

Freedom on two wheels

I think it has done more to emancipate women than anything else in the world. I stand and rejoice every time I see a woman ride by on a wheel.

Susan B. Anthony, 1896 — Interviewed by Nellie Bly for the New York World. The safety bicycle opened up new possibilities for independent travel, especially for women under restrictive social rules.

The washtub retired

Come, Muse, and sing the dreaded Washing-Day. Ye who beneath the yoke of wedlock bend, With bowed soul, full well ye ken the day

Anna Laetitia Barbauld, 1797 — From her poem 'Washing-Day.' A household wash meant hauling and heating water by the barrel, then scrubbing, rinsing, and wringing every piece by hand; it filled an entire day each week.

The queen of inventions

What philanthropy failed to accomplish, what religion, poetry, eloquence, and reason had sought in vain, has been produced by — the Sewing Machine.

Godey's Lady's Book, 1860 — From 'The Queen of Inventions,' in the era's leading women's magazine. Before the machine, most people owned only two or three outfits, and a single new shirt meant some fourteen hours of hand stitching.

Warmth in every room

It is so cold that the freezing of the ink on the point of my pen renders it difficult to write. We have had the thermometer at 12°.

Thomas Jefferson, 1796 — In a letter to his son-in-law, the ink freezing as he wrote. Bedrooms in winter often fell close to the temperature outside, and it was not unusual to wake up to a frozen washbasin.

The old wish to fly

I sometimes think that the desire to fly after the fashion of birds is an ideal handed down to us by our ancestors who, in their grueling travels across trackless lands in prehistoric times, looked enviously on the birds soaring freely through space, at full speed, above all obstacles, on the infinite highway of the air.

Wilbur Wright, 1908 — Remarks at a banquet of the Aéro-Club de France, Paris. Before flight, crossing an ocean took a week or more at sea, and emigrating across one often meant never seeing your family again.

At eleven, you switch off the lights, silence your phone, and lie down to sleep. As your head hits the pillow, you idly wonder what people slept on before mattresses.

All the items in this room were once out of reach; some not yet invented, others too rare or costly for the vast majority of people. Today, most of us lucky enough to live with them walk past without a second thought.

It is to humanity’s credit that we remain restless in the midst of all of this progress. We continue to look forward, pushing the frontier further with new treatments, new tools, and new institutions that will help future generations in ways we can’t even picture yet.

But our lives today are a gallery of past generations’ heroic efforts to do the same. It serves us, and honors them, to recapture whenever possible the old sense of awe at these wonders that have long since become commonplace.

Sources

• Recorded music Edward Bellamy, Looking Backward: 2000–1887 (Boston: Ticknor & Co., 1888), chapter 11.
• Electric light A contemporary account of the lighting of Wabash, Indiana, March 31, 1880, reprinted in the county histories of 1884 and 1914.
• Art reproductions André Malraux, Le Musée imaginaire, in La Psychologie de l’art (Geneva: Skira, 1947); translated by Stuart Gilbert in The Psychology of Art (New York: Pantheon, 1949); the quotation follows the Stuart Gilbert and Francis Price translation, Museum Without Walls (1967).
• Photography Elizabeth Barrett Browning, letter to Mary Russell Mitford, December 7, 1843.
• Corrected vision Giordano da Pisa, Lenten sermon at Santa Maria Novella, Florence, February 23, 1306; on the sermon, see Vincent Ilardi, Renaissance Vision from Spectacles to Telescopes (2007).
• Instant communication Charles F. Briggs and Augustus Maverick, The Story of the Telegraph (New York: Rudd & Carleton, 1858).
• Printed books Jakob Wimpfeling, Epitoma rerum Germanicarum (1505), translated in Theodore Low De Vinne, The Invention of Printing (1876).
• Clean running water Philip Hone, diary entry, October 12, 1842, in The Diary of Philip Hone, 1828–1851 (1889), vol. 2.
• Imported fruit Charles Lamb, “A Dissertation Upon Roast Pig,” London Magazine, September 1822; collected in Essays of Elia (1823).
• Household refrigeration The Calcutta Courier, on the arrival of New England ice in Calcutta; quoted in Jonathan Rees, Refrigeration Nation (2013).
• Global spices Jean de Joinville, The Life of Saint Louis (completed c. 1309), translated by Frank Marzials in Memoirs of the Crusades (1908).
• Vaccination Thomas Jefferson, letter to George C. Jenner, Edward Jenner’s nephew, Monticello, May 14, 1806.
• Anesthesia Inscription on the Morton monument, Mount Auburn Cemetery, erected 1871, attributed to Jacob Bigelow; printed in Historical Memoranda Relative to the Discovery of Etherization (Boston, 1871).
• Indoor plumbing Patty Doak, interviewed in The People in the Pictures: Stories from the Wettach Farm Photos (Iowa PBS, 2003).
• Personal mobility Nellie Bly, “Champion of Her Sex: Miss Susan B. Anthony,” New York World, February 2, 1896.
• Automated laundry Anna Laetitia Barbauld, “Washing-Day,” The Monthly Magazine, December 1797.
• Mechanized sewing “The Queen of Inventions — The Sewing Machine,” Editors’ Table, Godey’s Lady’s Book, July 1860, p. 77.
• Central heating Thomas Jefferson, letter to Thomas Mann Randolph, November 28, 1796.
• Human flight Wilbur Wright, remarks at a banquet of the Aéro-Club de France, Paris, November 5, 1908, in The Papers of Wilbur and Orville Wright, vol. 2 (1953).

45 years ago today, on 12th August 1981, the computing landscape changed forever. IBM launched the Personal Computer (type 5150), which kickstarted a series of events that defined what most people today think a PC is, even if it was not the first computer to be called "personal". It was the vessel that kickstarted x86's popularity in computing at offices and homes alike. The PC's long-term staying power was not a feat IBM achieved alone - the IBM-compatible "clone" PC market is what helped sustain the ecosystem's prominence. Personally, I like to think a big part of the PC's initial success was its keyboard. Not the perfect layout as most may agree, but certainly a competent, well-built keyboard - the Model F/XT. Thus to celebrate, in the most appropriate way for Admiral Shark's Keyboards, we will look at this keyboard, where it came from, and what it became. Of course, with context as needed, including what led to the IBM PC, and both who and what was behind it.

In the run up

Before the PC, IBM released products adjacent to a personal computer, and toyed with the idea of a personal computer throughout the 1970s. The PC's type number, 5150, places it in the lineage of the 5100 Portable Computer, and the 5110 and 5120 Computing Systems. 5100 in turn is an evolution of a prototype computer known as SCAMP (Special Computer APL Machine Portable), which was developed at the IBM Palo Alto Scientific Center in 1973.[4] William C. Lowe, an executive in the IBM General Systems Division (GSD) at the time, was considered instrumental in foresting this prototype. The 5100 was touted as a "personal computer" by some in the media, but it was a very expensive and not accessible to many people. It was notable for being portable though (for 1975), emphasised as IBM's smallest computing system to date.[5]

Tommy R. Hardy, a now-veteran IBM designer, conceptualised some interim ideas for a personal computer, including the "Yellow Bird" in 1976 and the "Aquarius" in 1977, both vaguely wedge-shaped in a form factor not unlike the later Commodore VIC-20, 64, etc., albeit bigger. Aquarius even made it to a pre-production prototype, but ultimately dismissed due to lack of confidence in its use of bubble memory modules. When Atari's 8-bit computers launched in 1979, IBM also considered aquiring Atari and utilising the 800 as a basis for the PC. Hardy conceputalised a pearl-white, IBM-branded 800 to this end,[6] but this idea proceeded no further. The next big thing, though, is Datamaster.

Datamaster

5324 Datamaster

It would be impossible to have a discussion about the PC and its keyboard without talking about the IBM System/23 Datamaster, an influential experience for IBM that aided them in the PC's development and its keyboard. The 5322, the original "desktop" (all-in-one) Datamaster, was released in July 1981. It was followed by the 5324 "floortop" (tower) Datamaster, announced on 18th May 1982.[10] They were Intel 8085-based microcomputers intended to run business applications written in BASIC.

The development for Datamaster began in February 1978, and its hardware was ready by July 1980. However, as recalled by IBM engineer David J. Bradley, who worked on Datamaster, its launch was delayed by a year and to just a month before PC thanks to IBM deciding to develop the Datamaster's BASIC more in line with the IBM System/34 midrange computer's implementation of it.[11] The 5322's styling is attributed to Hardy via its U.S. design patent (275,285), which was filed on 4th February 1980. The design at that stage was largely like the finished product, though the keyboard layout is slightly different, with extra keys and a non-stepped Enter key. If design patents for 5324 exist, I was not able to find them during my research.

5322 keyboard (top)

5322 CSA (top)

5322 CSA (bottom)

The Datamaster keyboard establishes the basis for every other keyboard discussed today. It is presently the earliest confirmed Model F keyboard implementation to make it to market, which would soon expand into an entire family of IBM flagship keyboards prominent for the first half of the '80s. They all use capacitive buckling springs, a keyswitch design by Richard Hunter Haris (U.S. utility patent 4,118,611), where pressing a key compresses a metal coil spring underneath in a way that it eventually "catastrophically" buckles, which in turn pivots a small plate made of a capacitive material atop a capacitance-sensing PCB called a "pad card". The keyboard assembly this all sits in is largely metallic, with a steel frame holding the keyswitch barrels at the top, and a usually-chromated steel base plate at the bottom.

The 5322 keyboard is a complete sub-assembly (CSA) that sits inside the host Datamaster. The keys are arranged in a layout derived from the Model B-based IBM 5251/5252 Display Station Typewriter Keyboard, which was IBM's most immediate and common pre-Datamaster major keyboard design. The aforementioned pad card bears a 12x8 key matrix and an Intel 8048 as its controller. The keyboard uses a parallel-style interface where an inverted 7-bit scancode is sent across separate scanbit lines together. Like its layout, its scancodes are also derived from the 5250 family. On the receiving end, according to RetroAND (bitspassats.com), the Datamaster has an 8255 Programmable Peripheral Interface configured for mode 1 input. As the keyboard is completely internalised, it connects directly to the 5322 motherboard (CPU planar board) via an 8x2 header.

5324 keyboard (top)

5324 keyboard (bottom)

5324 CSA (top)

5324 daughterboard (top)

5324 daughterboard (bottom)

As the 5324 is a distributed system, its version of the keyboard is discrete, connecting to its host via a DB-25-terminating cable. Chronologically, this was released after the PC, so it derives its styling from the PC's keyboard, but with a considerably enlarged cover set and slightly longer riser feet. It may sometimes be confused with the IBM 5291/5292 keyboard also discussed later, but the 5324 keyboard has the larger bezel between them, to the point it sometimes gets nicknamed the "bezelmaster" Model F keyboard. The 5324 keyboard reuses the 5322's keyboard CSAs. But the 5324 keyboard adds a "keyboard adapter card" before its external cable. As explained to me by RetroAND, it has positive buffers and double negations for the control signals, likely to reduce noise. In effect, it prepares a design that was originally integrated into something, to be a distributed design that requires a longer cable.

Personal Computer

An IBM Personal Computer (base unit)

Roll back the clock to July 1980: Lowe pitched the idea of a small, low-cost business and consumer computer to IBM CEO Frank Cary, who subsequently gave him a month to develop a prototype and to launch the finished product in a year. It was dubbed "Project Chess". Lowe was promoted soon after, so Chess fell to Philip Donald (Don) Estridge. Both have been referred to as the "Father of the IBM PC".[17][18] The team consisted of about twelve engineers, who were famously able to develop the PC outside of IBM's typical processes, ultimately allowing them to meet the one-year deadline, rather than complete it in 2 to 5 years like most other IBM systems of the time.

The earliest sketches of what became the PC, from 10th August 1980, were only relatively recently published. They show that a lot of what became the PC was nailed early on, including its use of the Intel 8088, five expansion slots, two floppy diskette drives, use of ASCII instead of EBCDIC, and a detached Model F-based keyboard. There are some notable differences, of course, including the display controller, the power supply unit's location inside the PC, and that it originally specified 8" floppy diskette drives instead of 5¼".[19]

To achieve their goal, the team was also assisted by prior experience with developing Datamaster, and using readily available components. The PC's use of an Intel CPU, various Intel supporting controllers and timer, and 8-bit ISA bus were derived from Datamaster's use of similar technologies. The choice of an 8088 with 20-bit/1MB address space was largely informed by woes with Datamaster's 8085 and its 16-bit/64KB address space. The choice of 8088 over 8086 was down to savings that could be had by needing to support just an 8-bit data bus instead of 16.[11]

An IBM Personal Computer

As you know, the IBM 5150 Personal Computer was released 45 years ago today. Its importance cannot be overstated. Its open architecture and use of the 8086-sibling Intel 8088 established one of the most popular and long-lived computer ecosystems. For better or worse nowadays, the combination of it and a Microsoft-sourced operating system is still relevant thanks to this. To me personally, learning about it and tinkering with its descendants are the backdrop to my technical interests and knowledge. The PC was joined by the IBM 5160 Personal Computer XT (PC/XT) on 8th March 1983. Over the original PC, the PC/XT adds a built-in hard drive and 3 expansion slots,[20] otherwise being a very similar design. Whilst there are many factors as to why the PC succeeded, it was certainly aided by the inclusion of a competent keyboard.

The IBM Personal Computer Keyboard

Type 1 vs 2 F/XT (top)

Type 1 vs 2 F/XT (CSA bottom)

The IBM Personal Computer Keyboard is often colloquially referred to as the "XT keyboard" or "Model F/XT", using its association with the PC/XT to differentiate it from the later IBM Personal Computer AT Keyboard ("Model F/AT"). Components of the F/XT can also be referred to as being "XT". At its core, the F/XT has a keyboard assembly much like the Datamaster's, but it adopted a new serial-based protocol retroactively called IBM PC Mode 1 (also known as the "XT keyboard interface", naturally). It emits 9-bit data packets facilitating IBM scancode set 1. The keycap nomenclature was changed to ASCII style instead of EBCDIC. In the aforementioned sketches, the interface and nomenclature were decided from the beginning, but it was also supposed they may cost-save the design by eliminating the leftmost function key bank,[19] which did not come to fruition.

I was not able to find any design patents for the PC itself (if they existed), but the keyboard's (U.S. design patent 278,063) is known. Tommy Hardy is also cited for this work, as is Edward Chamberlain, Nicholas M. Leon, Peter J. Mendel (who would later work on many other keyboard-related IBM product designs), and Michael H. Sharp. Two major variants of the original F/XT are known, both with their own nuances and differences or similarities to the Datamaster keyboards. They are referred to as Type 1 and Type 2.

Type 1 F/XT (top)

Type 1 F/XT CSA (bottom)

Type 1 F/XT CSA (open)

Type 1 F/XT pad card

Type 1 F/XT controller daughtercard

Type 1 F/XT possible data stamp

The original design, Type 1, is very rare today. I have only seen examples with "81" date codes on either its chips or stamped somewhere inside the cover set, so I imagine it was phased out quickly in favour of Type 2. What is interesting is that IBM chose a different approach to Datamaster for its electronics. It has a 24x4 key matrix, and the controller is split into a capacitance-sensing driver and demultiplexer on the pad card, and a separate daughterboard with an Intel 8048 as its controller. The reason for this design may be explained by the IBM 5291/5292's existence.

A telltale sign from the outside is that its original cable's 180° 5-pin DIN plug has no black plastic jacket like Type 2. The keyboard also has a reset line, which the IBM PC Technical Reference implies was not used[24] and is entirely dropped by Type 2.

Another IBM Personal Computer

Type 2 F/XT (top)

Type 2 F/XT (bottom)

Type 2 F/XT (side)

Type 2 F/XT CSA (top)

Type 2 F/XT CSA (bottom)

Type 2 F/XT pad card

The Type 2 design is what most F/XTs actually are, and certainly by the time of PC/XT, the only one available. As already mentioned, their DIN plugs have a plastic jacket and lack a reset line. But much has changed internally too, perhaps anarchonistic in some ways. It reverts to using a 12x8 matrix like Datamaster's, though configured differently. The controller is unified with the pad card once again, though of course still implementing the IBM PC Mode 1 interface.

5291 & 5292

5291 Model 1 (illustration of)

5291 Model 2

5292

The IBM 5291 Model 1 Display Station and 5292 Color Display Station were both 5250-family terminals announced on 6th September 1982. They are plug-compatible with the '70s IBM 5251 Display Station (model 11),[29][30] though the 5291 was intended as a low-cost replacement and the 5292 as a colour-enhanced supplement. 5291 Model 2 joined them on 2nd October 1984,[31] which was functionally identical to 5291-1 but smaller, more ergonomic, and with a relocatable screen, whereas 5291's was tightly integrated into the base unit.

529X (top)

529X (bottom)

529X (side)

529X CSA (bottom)

529X capsense driver

529X feet (all extended)

529X feet (various levels)

The 529X keyboard is a fun one. It's like the F/XT but dialled up to eleven. It has considerable bezels just like the 5324's, though with a slightly smaller 'forehead'. But it also has absurd three-setting riser feet, the longest of an IBM keyboard I have seen. Perhaps both of these facts lend themselves to the 529X keyboard's common nickname - the "bigfoot" Model F. The key nomenclature is back to being 5250-style, given 5291's and 5292's application. The 529X keyboard CSA is the same as the Type 1 F/XT's but without the controller daughtercard. Instead, the terminal itself would be its controller, making the 529X keyboard effectively "brainless" on their own. This is where I can see why IBM designed the Type 1 F/XT differently from Datamaster - more component commonality between higher-volume products. Both PC and (in my observations) at least 5291 were more so than Datamaster. Ultimately, the simpler, more elegant Type 2 solution won out for PCs, though.

The 5291-2 and 5292 shared the same completely detachable keyboard with a DA-15 plug, dubbed the Type 2 529X keyboard. 5291-1's Type 1 was instead always tethered, as its cable connected to a 14-pin IDC-style header inside the terminal, meaning the terminal has to be opened to detach it. The Type 2 is typically the far more common of the two today.

IBM-era rear label

Lexmark-produced rear label

Lexmark-refurbed rear label

Of all the keyboards discussed today, the 529X keyboard was produced the longest. Lexmark, which was founded from IBM Information Products Corporation's divestiture on 27th March 1991,[34] produced 529X keyboards into at least mid-1994. This also makes it one of the last Model Fs in production in general. Lexmark also refurbished existing 529X keyboards into 1996, their final year in the keyboard business. Lexmark-produced and Lexmark-refurbished 529X keyboards can usually be distinguished by the latter being mislabelled "Model M" on their rear labels instead of "F".

System 9000

IBM 9001 (formerly CS/9000)

IBM 9002

The IBM Instruments Computer System 9000 (CS/9000, also known simply as the System 9000) was a Motorola 68000-powered laboratory computer introduced in May 1982. It was notable for its vertical stack including an integrated printer/plotter and a 57-key membrane touch panel. On 21st February 1984, IBM introduced the System 9002 Desk-Top Computer and renamed the CS/9000 to the System 9001 Bench-Top Computer. In Q2 1985, the System 9003 Industrial-Floor Computer also joined them.[36]

The 9002 was designed to be a space-saving alternative to the now-9001, shedding the printer/plotter and integrating the membrane touch panel into the keyboard itself.[37] The 9003 was intended for use in manufacturing and process control applications, being able to operate as standalone or link with an IBM host processor via Systems Network Architecture (SNA). The entire 9000 family was withdrawn effective 2nd December 1986,[38] as ultimately all three members were unsuccessful in their respective markets.

9001 Standard Keyboard (top)

9001 Standard Keyboard (bottom)

The CS/9000 and 9001 used the IBM System 9000 Standard Keyboard, which was designed to sit on top of a protrusion from the host computer. The Standard Keyboard notably sports a rectangular "IBM System 9000" branding, no flip-out riser feet, a cable that sprouts from the left, and a choke just before the cable's DIN plug. Otherwise, it is the same and electrically compatible with the standard F/XT.

9002 Hybrid Keyboard

The 9002's keyboard - the IBM System 9002 Hybrid Keyboard - is a lot more interesting, though. As aforementioned, this keyboard notably integrates the 57-key membrane touch panel into the keyboard itself. Presumably, "Hybrid" refers to its nature of having both a buckling-spring keyboard and the touch panel. The resultant design is very reminiscent of the IBM 104-key Model F Converged Keyboard used for the IBM 3290 Information Panel and 5085 Graphics Processor, with the panel taking the place of the 24-function-key bank but retaining its noticable bezels and two-stage riser feet. Despite this, the keyboard itself remains the F/XT-style assembly.

Whilst a 9002 computer has turned up in recent times, the keyboard has not, nor are there any photos of the keyboard from outside the 1980s. No one that I know owns one to test it or dig inside, thus its electronics remain a mystery to me. In my 'professional' opinion, the 9002 Hybrid Keyboard is the rarest Model F keyboard known, perhaps at most tied with another keyboard I plan to talk about soon. At least all the other known variants have been contemporaneously pictured...

At present, the 9003 or its keyboard also remain unseen to me. Computerworld's reporting suggests the keyboard and 57-key touch panel were separate, just like the 9001.[41]

Portable Personal Computer

The IBM Portable Personal Computer

On 16th February 1984, IBM announced the 5155 Portable Personal Computer. It is essentially a PC/XT assembled into a luggable form and given a cute 9" amber CRT display and one or two now-half-height 5¼" floppy diskette drives.[43] It was IBM's answer to the Compaq Portable, one of the first IBM PC clones that launched just under a year earlier and happened to be in the same form factor.

Portable PC Keyboard (top)

Portable PC Keyboard CSA (bottom)

Compared to the original F/XT, the 5155's version is housed in an all-plastic, two-tone cover set with a compartment to stuff its cable into, its base plate is a shiny, silvery aluminium instead of chromated steel, and it has a 6-pin modular plug instead of DIN. This results in the keyboard being considerably lighter and sounding somewhat higher-pitched than the original. The cover set can also be opened toolessly as the dark plastic bezel surrounding the keys can be lifted at any time. Electrically, the keyboard remains unchanged, and it can be passively adapted to 5-pin DIN if so desired.

When not in use, the keyboard should be mounted upright to the front of the 5155, covering its entire front. The keyboard has two clips towards the top that are used to release it and allow it to pivot down. You can additionally deploy its riser feet to completely detach the keyboard from the host PC.

TPC and EMR

The IBM Tempest PC (TPC) family are IBM PC-related products that were designed or modified to qualify under the TEMPEST program. TEMPEST is a NATO-recognised, United States National Security Agency specification regarding protecting against spying with electronic equipment. In particular, qualifying systems are designed not to radiate electromagnetic emanations to counter Van Eck phreaking. IBM referred to such systems as being 'TEMPESTed', usually adding special covers and filters to meet the requirements. The TPC family ultimately included the IBM 4450 TPC1 (TEMPESTed PC), 4455 TPC2 (PC/XT), 4456 TPC3 (3270 PC), 4459 TPC4 (PC/AT), and 4460 TPC5 (3270 PC/AT).[44]

TPC1 (top)

TPC2 (top)

TPC2 (branding)

EMR1 (top)

EMR2 (branding)

TPC1 and TPC2 indeed come with an F/XT variant named TPC Keyboard I and TPC Keyboard II, respectively, which despite their name and part numbers, do not differ from each other. Additionally, an IBM EMR Keyboard and EMR Keyboard II are known, although it is presently unclear to me what exactly those two were used for (ie., are they also TPC family products or are they intended for TEMPESTed IBM systems outside of the TPC family).

TPC1 CSA (bottom)

TPC2 CSA (bottom)

TPC2 DE9 plug

EMR1 cable

EMR1 DIN plug

All four keyboards have clay covering the controller, hardier, non-coiled cables, and unique plugs compared to their 'civilian' counterparts. EMR I uniquely used a 180° 5-pin DIN plug not unlike the Type 1 F/XT's, whereas the other three (and TPCs 3 through 5) used a DE-9 connector instead. This means EMR I is not physically compatible with the known TPCs. EMR II, however, seems to be identical to TPC1 and TPC2.

Regarding the PCs themselves, at least based on Cathode Ray Dude's analysis on the TPC4 and comparison with a standard PC/AT, they appear to be mostly as you would expect from the standard models inside. The motherboard, power supply and ISA card complement were typical, and the differences lay with the reinforced outer casing, the power switch location and function, and some buffer space between the rear I/O and the actual back of the TPC.[51]

What about 5531?

5531 keyboard (top)

5531 keyboard Oak FTM keyswitches

5531 keyboard rear label

It is worth briefly mentioning the IBM 5531 Industrial Computer and its keyboard. The IBM 5531 Industrial Computer was an industrialised version of the PC/XT, introduced on 1st May 1984. It was intended for use on factory floors and accordingly designed to be more resistant to harsher physical conditions.[55] Being PC/XT-based, it thus received an XT-style keyboard. Whilst it superficially looks like an industrial-grey version of the F/XT, the keyboard is of an unrelated design and not considered a Model F keyboard. It was made by Oak Switch Systems for IBM, using their Full-Travel Membrane (FTM) keyswitches. To easily tell it a part from the F/XT, note its flatter appearance and the lack of curvature on the separator between the F-keys and the rest of the keys. This is not to say this keyboard does not have any merit; just note that it is indeed not a Model F and you should not expect it to be like one.

Acknowledgements

• Big thanks to RetroAND (https://bitspassats.com/) for our mutual conversations over the last year or so on Datamaster, and their assistance with ensuring the facts surrounding Datamaster inside this article and elsewhere are as best as they could be.

Further reading & resources

Internal

• ASK Keyboard Timeline
• IBM Model F keyboards
• Major IBM typewriter & keyboard models

External

• David J. Bradley - The Creation of the IBM PC
• IT Pro - The true story behind the IBM Personal Computer
• Laptop Retrospective - Think Design Stories: IBM and Design, The Road to the Personal Computer (ft. Tom Hardy)
• Modern Classic - The IBM PC 5150 - the world's most influential computer
• OS/2 Museum - The IBM PC, 41 Years Ago
• The Digital Antiquarian - The IBM PC, Part 1

Sources

ASK. Admiral Shark's Keyboards original content. License/note: CC BY-NC-SA 4.0.

1. Matt Kieffer @ Wikimedia - File:IBM SCAMP at Smithsonian National Museum of American History.jpg [accessed 2026-08-12]. License/note: CC BY-SA 2.0 (cropped).
2. Norsk Teknisk Museum - NTM TELE IBM 2012 51001 [accessed 2025-04-15]. License/note: CC BY-SA 4.0 (cropped).
3. Tekniska museet - TEKS0041857 [accessed 2025-04-15]. License/note: CC BY-SA 4.0 (cropped).
4. Smithsonian Institution - IBM SCAMP Microcomputer [accessed 2026-08-12].
5. Wikipedia - IBM 5100 [accessed 2026-08-12].
6. Laptop Retrospective - Think Design Stories: IBM and Design, The Road to the Personal Computer (ft. Tom Hardy) [accessed 2026-08-11]. License/note: screencap taken and used under fair dealing.
7. snuci - File:IBM 5322 - computer.JPG [accessed 2024-12-25]. License/note: public domain.
8. bitsavers - Index of /pdf/ibm/system23/5324 [accessed 2026-08-12]. License/note: believed to be public domain.
9. IBM - IBM Hardware List as of 12/15/87 [accessed 2026-08-12].
10. Ardent Tool - David J. Bradley - The Creation of the IBM PC [accessed 2026-08-11]. License/note: originally from Byte Magazine, September 1990.
11. snuci - File:IBM 5322 - barrel plate front.JPG [accessed 2024-03-18]. License/note: public domain.
12. snuci - File:IBM 5322 - back plate with PCB.JPG [accessed 2024-03-18]. License/note: public domain.
13. C. Hurlbut - 1982 F [accessed 2024-03-04]. License/note: copyright @ Christopher Hurlbut (explicit permission to use here given).
14. C. Hurlbut - 1982 F [accessed 2024-11-22]. License/note: copyright @ Christopher Hurlbut (explicit permission to use here given).
15. IBM - The Guide to personal computer offerings from IBM Fall 1983 Winter 1984 (#6936938-1) [accessed 2026-08-12]. License/note: photos used under fair dealing.
16. The Digital Antiquarian - The IBM PC, Part 1 [accessed 2026-08-11].
17. IBM - The IBM PC [accessed 2026-08-11]. License/note: retrieved via Wayback Machine (2024-05-30 capture).
18. OS/2 Museum - The IBM PC, 41 Years Ago [accessed 2026-08-11].
19. IBM - USA announcement letter 183-027 [accessed 2026-08-12].
20. IBM - The Guide to personal computer offerings from IBM Fall 1983 Winter 1984 (#6936938-1) [accessed 2025-05-03]. License/note: photos used under fair dealing.
21. vintagecomputer.ca - IBM PC Model F keyboards [accessed 2026-08-12]. License/note: permission to use given via email.
22. vintagecomputer.ca - IBM PC Model F keyboards [accessed 2026-08-13]. License/note: permission to use given via email.
23. IBM - IBM Personal Computer Technical Reference (#6025008) [accessed 2026-08-12].
24. Wodan - File:IBM Model F XT PCB.png [accessed 2026-08-13]. License/note: CC BY-SA 4.0 (cropped, rotated & contrast adjusted).
25. IBM - IBM 5291 Display Station Maintenance Library (#SY31-0661-0) [accessed 2024-12-22]. License/note: document archived by bitsavers, illustrations used under fair dealing.
26. bitsavers - Index of /pdf/ibm/5291/5291-2_pictures [accessed 2024-12-22]. License/note: believed to be public domain.
27. IBM - IBM System/36 Equipment and programs (#G580-0451-02) [accessed 2024-12-22]. License/note: document archived by bitsavers, photos used under fair dealing.
28. IBM - EMEA announcement letter ZG82-0274 [accessed 2026-08-12].
29. IBM - EMEA announcement letter ZG82-0275 [accessed 2026-08-12].
30. IBM - USA announcement letter 184-118 [accessed 2026-08-12].
31. Brandon @ clickykeyboards.com - 1996 IBM Model F keyboard (1397950) 3/19/96 (83-key) [accessed 2026-08-12]. License/note: https://deskthority.net/wiki/Help:Contents#Copyright.
32. webwit - Index of /input/ibm_misc [accessed 2024-02-05]. License/note: public domain.
33. US Customs and Border Protection - CROSS Ruling 544887 [accessed 2025-12-18].
34. SneakyRobb @ Deskthority - IBM System 9000 keyboard and picture of unknown Model F#p455136 [accessed 2025-04-04]. License/note: used under fair dealing.
35. Wikipedia - IBM System 9000 [accessed 2026-08-12].
36. IBM - USA announcement letter 184-022 [accessed 2026-08-12].
37. IBM - USA announcement letter 186-165 [accessed 2026-08-12].
38. Engicoder - File:CS-9000-Front.JPG [accessed 2023-04-22]. License/note: public domain.
39. Engicoder - File:Cs-9000-rear.JPG [accessed 2024-03-18]. License/note: public domain.
40. Computerworld - April 29, 1985 [accessed 2026-08-12].
41. Norsk Teknisk Museum - NTM TELE IBM 2012 55002 [accessed 2025-04-15]. License/note: CC BY-SA 4.0 (cropped).
42. IBM - USA announcement letter 184-028 [accessed 2026-08-12].
43. IBM - IBM Personal Computer Family Service Information Manual (#SA38-0037-00) [accessed 2026-08-11]. License/note: document archived by bitsavers, diagrams used under fair dealing.
44. WorthPoint - Extremely Rare Vintage IBM TPC Keyboard I - Clicky - Similar to PC XT Model F [accessed 2023-04-22]. License/note: used under fair dealing.
45. WorthPoint - Vintage IBM Model F TPC Keyboard II 1385361, For Tempest Computer, "5" Key Stuck [accessed 2026-08-12]. License/note: saved from volatile eBay listing via WorthPoint & used under fair dealing.
46. Compgeke - File:EMR1.jpg [accessed 2026-08-12]. License/note: public domain.
47. Brandon @ clickykeyboards.com - 1987 IBM EMR keyboard 100A535 83-key NEW [accessed 2026-08-12]. License/note: https://deskthority.net/wiki/Help:Contents#Copyright.
48. JP! @ deskthority - IBM Model F XT TPC I EMR Keyboard [accessed 2026-08-12]. License/note: used under fair dealing.
49. WorthPoint - Vintage IBM Model EMR Keyboard 83 key industrial or pc [accessed 2026-08-12]. License/note: saved from volatile eBay listing via WorthPoint & used under fair dealing.
50. Cathode Ray Dude - CRD - A TEMPEST In AT-Cup: The IBM TPC [accessed 2026-08-11].
51. snuci - File:IBM Industrial XT (Oak) keyboard top.jpg [accessed 2024-04-15]. License/note: public domain.
52. snuci - File:IBM Industrial XT (Oak) identification.jpg [accessed 2024-04-15]. License/note: public domain.
53. snuci - File:IBM Industrial XT (Oak) internal label.jpg [accessed 2024-04-15]. License/note: public domain.
54. IBM - USA announcement letter 184-065 [accessed 2026-08-13].

Lanmaoa asiatica is a popular edible mushroom species sold in Yunnan that induces Lilliputian hallucinations when undercooked. Locals call it Jian shou quing, which translates to “turns blue in the hand” to reference its rapidly changing colors when touched. Credit: Colin Domanauer/NHMU

People in communities thousands of miles apart have described the same strange experience after eating a mysterious mushroom: vivid visions of tiny humans moving through and interacting with the physical world around them. Known as Lilliputian hallucinations—a reference to the 6-inch-tall inhabitants of "Gulliver's Travels"—the phenomenon has long been thought to stem from cultural influences rather than biology.

A new study suggests otherwise.

Using DNA sequencing, University of Utah (U) researchers confirmed that a single mushroom species, Lanmaoa asiatica, is responsible for these hallucinations in Southwest China and the northern Philippines.

They also discovered that the mushroom contains none of the psychoactive compounds known to science, including psilocybin. Instead, the findings point to an entirely new hallucinogenic compound that could offer new insights into neurological disease and how the brain shapes perception and consciousness.

Colin Domnauer, a doctoral student at the U, and Bryn Dentinger, a mycologist at the U and the Natural History Museum of Utah, coauthored the study that was published June 5, 2026, in the journal Mycologia.

Domnauer spoke to @theU about the Lilliputian mushroom, the decades-long mystery behind it and the implications of a new hallucinogenic compound.

People have reported Lilliputian hallucinations for nearly a century, yet the mushroom behind them remained a mystery. How did you finally identify it?

In 1934, Western scientists first heard reports from Papua New Guinea of people hallucinating tiny humans after eating wild mushrooms, a phenomenon they dubbed "mushroom madness."

Anthropologists and mycologists went to Papua New Guinea in the 1950s and 1960s, narrowing the culprit to a few species in the Boletaceae (bolete) family. They did some chemical analyses but couldn't find any psychoactive components. They even sent samples to Albert Hoffman, who first isolated psilocybin and discovered LSD, but even he couldn't find an active compound.

Eventually, they concluded that maybe these mushrooms weren't bioactive at all—maybe this was all just a sociocultural phenomenon. So, research really ended in the 1960s.

Decades later, in the 1990s, there were reports from Yunnan in Southwest China of a very similar phenomenon after people ate bolete mushrooms. The species wasn't clear, but mycologists suggested that it might be L. asiatica, then a newly described mushroom.

In 2024, I heard similar accounts from an Indigenous community in the Philippines' remote Northern Cordillera region who were consuming a wild mushroom called "Sedesdem" that, according to local knowledge, occasionally caused visions of little people. Known as the "Nonda" in Papua New Guinea and "Jian shou qing" in Yunnan, it's a culturally important edible mushroom that, if undercooked, would produce the hallucinations.

That was the third independent case linking a wild mushroom to visions of little people.

I went to Yunnan and the Philippines, spoke with locals and collected L. asiatica and as many specimens in the Lanmaoa genus as I could find for DNA sequencing. That was the first scientific survey of Northern Philippine fungi that had ever been done.

It turns out that China's Jian shou qing and the Philippines' Sedesdem were both L. asiatica—which was very surprising because at the time, we thought L. asiatica only occurred in China. Unfortunately, when Dentinger traveled to Papua New Guinea, unusually dry conditions prevented us from collecting specimens for comparison.

Now, three completely independent cultures have reported the same specific type of hallucination, and two cases are attributed to the same DNA-verified mushroom species. That indicates that these bizarre psychological effects aren't cultural manifestations or coincidences—they must have a shared underlying chemical and neurological basis.

What makes the hallucinations so unusual?

People pretty much always report seeing dozens or hundreds of little people, about 3 to 30 centimeters tall (1 to 12 inches), in incredible detail, like they're actually there. About 90% of people describe them as little elves or clowns or other fairy-like figures dressed in colorful clothes.

What's fascinating is they interact with the physical world using the laws of physics that govern us. They're not walking through walls or anything. They're falling off the edge of tables, walking around objects. One person told me that while they were eating soup, the little people were jumping off their spoon into the bowl and swimming around. As they scooped a bite, the little people remained in their mouth.

Why do you think L. asiatica has different compounds than other psychedelic mushrooms?

We searched inside the mushroom, both chemically and genetically, for the presence of any known psychoactive mushroom compounds, and we found absolutely no trace of them. This wasn't too surprising, as the strange symptoms are quite unlike any known drug.

Why is the prospect of a new psychoactive compound exciting?

Lilliputian hallucinations predate this mushroom. There are myths about tiny people in pretty much every culture's folklore. People have also reported these hallucinations from alcohol withdrawal, dementia, macular degeneration and other neurological conditions. So, it seems like this phenomenon is fundamental to how the human mind and brain work, but we don't know what causes it or how to treat it.

That's what makes this mushroom different—it reliably produces this effect, whereas those conditions very rarely trigger it. If L. asiatica has some compound that can reliably induce these hallucinations, it could be a very powerful tool for understanding the mechanisms behind them.

Our next step is to isolate and identify that new psychedelic compound.

Your study is the first comprehensive genomic analysis of all Lanmaoa species. What else did you find?

I wanted to understand the diversity and evolution of this whole Lanmaoa group of mushrooms. So, we collected specimens from around the globe and sequenced the genomes of 53 specimens from the wild and fungarium collections. We found that there were 17 species in this group, including four new species, two of which came from existing U.S. collections.

Our analysis showed that L. asiatica is the only psychoactive species in this genus. Now we're building an evolutionary map to understand how this trait evolved and whether related species produce similar compounds.

I think one of the most exciting findings is that there was so much hidden diversity sitting in museum collections that we never would have recognized without DNA sequencing. It reveals how much biological novelty is hiding in plain sight, waiting to be discovered.

Fungi are extremely underexplored. Why do you think it's important to expand our biodiversity knowledge?

We're just scratching the surface of the fungal kingdom. Look at penicillin—that was isolated from a fungus and was probably the most revolutionary medicine of the last century. Who knows what other miracle medicines or revolutionary understandings we'll find by exploring nature.

The "Latin script" was typified by Antiqua.

The "German/Gothic script" (blackletter) was embodied by Fraktur.

The Antiqua–Fraktur dispute was a typographical dispute in 19th- and early 20th-century Germany.

In most European countries, blackletter typefaces like the German Fraktur were displaced by the creation of the Antiqua typefaces in the 15th and 16th centuries. However, in Germany and Austria, the two styles of printing coexisted until the first half of the 20th century.

During that time, both styles gained ideological connotations in Germany, which led to long and heated disputes on what was the "correct" typeface to use. The eventual outcome was that the Antiqua-style typefaces prevailed when the Nazi Party chose to put an end to the use of Fraktur in favor of "normal typeface" (German: Normalschrifterlaß).

Origin

Two typefaces: the German text uses Fraktur; numerals and Latin and French words are written in Antiqua (1768).

Historically, the dispute originates in the differing use of these two typefaces in most intellectual texts. Whereas Fraktur was preferred for works written in German, for Latin texts the Antiqua-style typefaces were normally used. This extended even to English–German dictionaries; the English words would all be written in Antiqua, and the German words in Fraktur. Originally this was simply a convention.

19th century

Conflict over the two typeface styles first came to a head after the occupation of Germany and dissolution of the Holy Roman Empire by Napoleon in 1806, which led to a period in the history of Germany in which nationalists began to attempt to define cultural values common to all Germans. There was a massive effort to canonize the German national literature—for example, the Grimm Brothers' collection of fairy tales—and to create a unified German grammar.

In the context of these debates, the two styles became increasingly polarized: Antiqua typefaces were seen as "un-German", and using them took on connotations of "shallow", "light", and "not serious". In contrast, Fraktur, with its much darker and denser script, was viewed as representing allegedly German virtues such as depth and sobriety.

During the Romantic Era, in which the Middle Ages were glorified, Fraktur additionally gained the (historically incorrect) interpretation that it represented German Gothicism. For instance, Goethe's mother advised her son to refrain from using the un-German Antiqua “for God’s sake”.

Otto von Bismarck was a keen supporter of German typefaces. He went so far as to refuse gifts of German books in Antiqua typefaces and returned them to sender with the statement Deutsche Bücher in lateinischen Buchstaben lese ich nicht! ('I don't read German books in Latin letters!').[1]

20th century

The dispute between Antiqua and Fraktur continued well into the 20th century. Arguments for Fraktur were not only based on historical and cultural perceptions, but also on the claim that Fraktur was more suited for printing German and other Germanic languages, as their proponents claimed it to be more readable than Antiqua for this purpose.

A 1910 publication by Adolf Reinecke, Die deutsche Buchstabenschrift, claims the following advantages for using Fraktur as the German script:

• German script is a real reading script: it is more readable, i.e. the word images are clearer, than Latin script.[2]
• German script is more compact in printing, which is an advantage for fast recognition of word images while reading.
• German script is more suitable for expressing German language, as it is more adapted to the characteristics of the German language than the Latin script.
• German script does not cause nearsightedness and is healthier for the eyes than Latin script.[3]
• German script is still prone to development; Latin script is set in stone.
• German script can be read and understood all over the world, where it is actually often used as ornamental script.
• German script makes it easier for foreigners to understand the German language.[4]
• Latin script will gradually lose its position as international script through the progress of the Anglo-Saxon world (here the author states that "Anglo-Saxons in the UK, the United States and Australia are still 'Germanic' enough to annihilate the Latin-scriptler's dream of a Latin 'world-script'").[5]
• The use of Latin script for German language will promote its infestation with foreign words.
• German script does not impede at all the proliferation of German language and German culture in other countries.

On 4 May 1911, a peak in the dispute was reached during a vote in the Reichstag. The Verein für Altschrift ("Association for Antiqua") had submitted a proposition to make Antiqua the official typeface (Fraktur had been the official typeface since the foundation of the German Empire) and no longer teach Kurrent (blackletter cursive) in the schools. After a long and, in places, very emotional debate, the proposition was narrowly rejected 85–82.

Nazi period

Nazis had a complex and variable relationship with Fraktur. Adolf Hitler personally disliked it. In fact, as early as 1934 he denounced its continued use in a speech to the Reichstag:[6]

Your alleged Gothic internalization does not fit well in this age of steel and iron, glass and concrete, of womanly beauty and manly strength, of head raised high and intention defiant [...] In a hundred years, our language will be the European language. The nations of the east, the north and the west will, to communicate with us, learn our language. The prerequisite for this: The script called Gothic is replaced by the script we have called Latin so far [...]

Nonetheless, Fraktur typefaces were particularly heavily used during the early years of the Nazi era, when they were initially represented as true German script. In fact, the press was scolded for its frequent use of "Roman characters" under "Jewish influence", and German émigrés were urged to use only "German script".[7] However, Hitler's distaste for Fraktur saw it officially discontinued in 1941 in a Schrifterlass ("edict on script") signed by Martin Bormann, which asserted that it was falsely called "Gothic" and actually consisted of Schwabacher Judenlettern ("Jewish letters").[8]

One of the motivations seems to have been compatibility with other European languages. The edict mentions publications destined for foreign countries, Antiqua would be more legible to those living in the occupied areas; the impetus for a rapid change in policy probably came from Joseph Goebbels and his Propaganda Ministry.[9] Readers outside German-speaking countries were largely unfamiliar with Fraktur typefaces. Foreign fonts and machinery could be used for the production of propaganda and other materials in local languages, but not so easily in German as long as the official preference for Fraktur remained.

Normalschrifterlass by Martin Bormann

Bormann's edict of 3 January 1941 at first forbade only the use of blackletter typefaces. A second memorandum banned the use of Kurrent handwriting, including Sütterlin, which had only been introduced in the 1920s. From the academic year 1941/42 onwards, only the so-called Normalschrift ("normal script"), which had hitherto been taught alongside Sütterlin under the name of "Latin script", was allowed to be used and taught. Kurrent did remain in use until 1945 for some applications such as cloth military insignia badges.

After the Second World War

After the war, the Sütterlin script was once again taught in the schools of some states of Germany as an additional script, but it could not hold out against the usage of Latin cursive scripts. As a consequence, most Germans find it difficult to decipher their own grandparents' letters, diaries, or certificates.

However, the Fraktur script remains present in everyday life in some pub signs, beer brands and other forms of advertisement, where it is used to convey a certain sense of rusticity and oldness (compare the English ye olde). However, many of these deviate from the traditional letterforms, specifically in the frequent untraditional use of the round s instead of the long s (ſ) at the beginning of a syllable, the omission of ligatures, and the use of letter-forms more similar to Antiqua for certain especially hard-to-read Fraktur letters such as k. Books wholly printed in Fraktur are nowadays read mostly for particular interests. Since many people have difficulty understanding blackletter, they may have trouble accessing older editions of classic works in German.

A few organizations such as the Bund für deutsche Schrift und Sprache [de] continue to advocate the use of Fraktur typefaces, highlighting their cultural and historical heritage and their advantages when used for printing Germanic languages. But these organizations are small, somewhat sectarian, and not particularly well known in Germany.

In the United States, Mexico, and Central America, Old Order Amish, Old Order Mennonite, Old Colony Mennonite, and Hutterite schools still teach the Kurrent handwriting and Fraktur script. Many German books printed by Amish and Mennonite printers use the Fraktur script.

References

1. Reinecke 1910, p. 79.
2. Reinecke 1910, pp. 42, 44.
3. Reinecke 1910, pp. 42, 49.
4. Reinecke 1910, pp. 58–59.
5. Reinecke 1910, p. 62.
6. "Fraktur: German Typefaces in World War II". penelope.uchicago.edu. Retrieved 12 May 2025.
7. Michaud 2004, pp. 208, 215–216.
8. "Bormann-Original-Schreiben". ligaturix.de. Retrieved 11 August 2026.
9. Michaud 2004, pp. 216–217.

Sources

• Michaud, Eric (2004). The Cult of Art in Nazi Germany. Translated by Lloyd, Janet. Stanford, California: Stanford University Press. ISBN 9780804743266.
• Reinecke, Adolf (1910). Die deutsche Buchstabenschrift: ihre Entstehung und Entwicklung, ihre Zweckmäßigkeit und völkische Bedeutung (The German letter script: its origin and development, its usefulness and national meaning) (in German). Borsdorf: Hasert.

Further reading

• Bain, Peter; Shaw, Paul, eds. (1998). Blackletter: type and national identity. New York, NY: Princeton Architectural Press and Cooper Union for the Advancement of Science and Art. ISBN 978-1-56898-125-3.
• Hartmann, Silvia (1998). Fraktur oder Antiqua: der Schriftstreit von 1881 bis 1941 (Fraktur vs Antiqua: the tyopgraphical dispute from 1881 to 1941) (in German). Frankfurt am Main: Lang. ISBN 3-631-33050-2.
• Kapr, Albert (1993). Fraktur, Form und Geschichte der gebrochenen Schriften (Fraktur, form and history of blackletter typefaces) (in German). Mainz: Verlag Hermann Schmidt. ISBN 3-87439-260-0.
• Killius, Christina (1999). Die Antiqua-Fraktur Debatte um 1800 und ihre historische Herleitung (The Antiqua-Fraktur debate around 1800 and its historical derivation) (in German). Wiesbaden: Harrassowitz Verlag. ISBN 3-447-03614-1.

External links

• Die Nationalsozialisten und die Fraktur Archived 5 April 2005 at the Wayback Machine (in German)
• Bund für deutsche Schrift und Sprache (in German)