The Terminal Dies: Flapping Airplanes Returns the Silicon to the Metal and Leaves OpenAI and Anthropic as the New IBM.

Multiplex members get the full articles, the members forum and member benefits and discounts. Join Multiplex →·Log in

The Terminal Dies: Flapping Airplanes Returns the Silicon to the Metal and Leaves OpenAI and Anthropic as the New IBM.

A company called Flapping Airplanes closed a $1 billion Series A on October 21, 2026, co-led by Index Ventures and Lux Capital at a reported $6 billion valuation. Nine months earlier the same lab had raised $180 million at $1.5 billion. A couple of dozen people sit at desks in a San Francisco room. No commercial product sits on a table. No public benchmarks appear online. Nvidia is among the investors. The founders state that demand for AI will outpace the supply of data and compute, and that efficiency in both will decide who can place capable systems into the economy.

The name Flapping Airplanes refers to the ornithopter, an early aircraft that generated lift by flapping its wings rather than by fixed-wing airflow. Asher Spector has said the choice stands for combining the strengths of natural and artificial intelligence. The founders have also joked that they are not an airplane. The label is the only public statement the company has offered on the point. No further explanation of the choice appears in the funding materials or the technical record that precedes the lab.

The premise is older than the company. In 1987 I wrote a TSR program for the IBM PC in a garage called QFRESH. (https://x.com/BrianRoemmele/status/2042026167952441396?s=20). On these computers DRAM stored each bit as charge in a microscopic capacitor. The capacitors leak. Every 15 microseconds a DMA controller seized the bus, refreshed a row, and returned control. The schedule was fixed and conservative. Cycles sat unused. My TSR intercepted the timer and moved the refresh into the gaps the workload already left. On the jobs I measured, the same silicon delivered about 50 percent more throughput. IBM preferred the standard timing. I published the code.

The machine already contained the capacity once the boundary that created the wait was removed. They did not upgrade the processor. They did not add more RAM. They got 50 percent more performance out of the exact same physical machine by reclaiming time the hardware was already experiencing but the software was ignoring.

How I Pioneered This Technology

It was the summer of 1987 and I was a kid on fire with the early PC revolution. Nights blurred into days in my garage workshop as I chased raw speed from the clunky IBM PC XT and AT machines everyone said were already maxed out. I thought really?

This was not new to me, I had already built the fastest IBM PC-AT in history. I was hot-rodding from stock 6 MHz to over 30 MHz. So this was my next exploration. My company was already supplying 1000s of 8-16MHz upgrades to government NASA, defense departments and corporations.

I was alone and had fancy hardware add ons just me a soldering iron a logic analyzer and stacks of Intel datasheets. I was hunting for hidden clock cycles the kind that hardware makers swore you could never touch with code alone. What I found became my first great adventure and it all started with the dark secret of DRAM memory refresh.

Back then every PC used dynamic RAM chips (DRAM). Unlike static memory these stored each bit as a tiny leaking capacitor. Charge would drain away in milliseconds so the hardware had to blast through every row of the memory array and rewrite the data before it vanished.

On the IBM PC this was done by the DMA controller stealing the bus from the CPU roughly every 15 microseconds. Each refresh stole four full bus cycles. No work got done while the CPU sat stalled. It was death by a thousand tiny interruptions. And this refresh rate became more complicated as speeds increased as bus cycles, data rates and address cycles clashed.

Here is the math in plain numbers. At 4.77 MHz the 8088 CPU had about 210 nanoseconds per bus cycle. Refresh happened 64 times per 15.6 millisecond window across 256 rows. That added up fast:

refresh_stalls_per_second = (64 rows * 4 cycles * 1 / 0.0156 seconds)

That single number ate 10 to 25 percent of every second of bus time depending on the workload. Real programs slowed to a crawl because the CPU spent its life waiting.

I started experimenting with the refresh timer in assembly. The official spec said refresh every 15.6 us but real DRAM held data longer when the room was cool and the voltage was stable. I wrote a tiny TSR program that intelligently stretched the interval and rescheduled refreshes around heavy bus activity. No data corruption just pure freed cycles. It was an instant speed improvement and the word spread fast with no Internet, just users groups and BBSs. Lots of big companies wanted to try it and some called IBM to confirm “is he real”? They knew me and it started a firestorm.

IBM once again threatened to sue me after a few years before they threatened with the very first hardware speedup in history, only later offer to “buy me” and hire me.

The CUDA Connection

Flash forward that measurement still governs AI systems. Local layouts, custom schedules, and the refusal to treat a vendor timer as final occupy the same space. The GPU already contains idle intervals that disappear when the launch boundary between kernels is removed. Tensor cores on an H100 supply roughly 16 times the floating-point operations of the general-purpose units. It is wasteful in my eyes. And I began to find ways to make AI many times faster.

The CUDA software built in to NVIDIA chips leaves those cores waiting forfeits most of the machine. You are paying for a Ferrari and driving it in a school zone because your software forces it to stop at every crosswalk. Flapping Airplanes saw this and began to do what I did in the 1980s. The massive capital that moved into Flapping Airplanes now prices the possibility that the next increment comes from using the silicon already installed rather than from another data-center lease. You are paying for the whole square footage. The electricity is already running to that room, but you are only living in half of it because the schematic told you to.

This article is sponsored by Read Multiplex Members who subscribe here to support my work: Link: https://readmultiplex.com/join-us-become-a-member/

It is also sponsored by many who have donated a “Cup of Coffee”. If you like this, help support my work: Link: https://ko-fi.com/brianroemmele

Listen to the companion podcast: https://rss.com/podcasts/readmultiplex-com-podcast/3262364

ThunderKittens, the 2024 framework Ben Spector co-authored at Stanford’s Hazy Research group, supplies the prior public record. It defines 16-by-16 matrix tiles that match the physical size of the tensor cores. Templates overlap asynchronous loads and stores across warps. While one warp waits for data from memory, another computes on data already resident. The tensor cores do not sit. The chef never clocks out. The ingredients are just asynchronously tossed to them while they keep chopping. On H100 hardware the kernels matched cuBLAS and FlashAttention-3 on forward GEMM and attention. They outperformed the strongest baselines by 10–40 percent on attention backward, 8× on state-space models, and 14× on linear attention. A single 40-line GEMM competed with cuBLAS. The paper and code are public. The numbers are the authors’ measurements on the hardware available then. They did not invent new hardware. They organized the work to fit the physical reality of the silicon that was already there.

Flapping Airplanes has extended the same approach into a megakernel and a persistent runtime a team member called the Kittens Virtual Machine. A conventional stack launches thousands of separate kernels for matrix multiplies, attention, normalization, memory movement, and communication. Each launch carries allocation, synchronization, and teardown cost. Dependencies leave tensor cores and memory bandwidth waiting. Imagine if every time a line cook chopped a carrot they had to clock out, clock back in, wash their hands, reread the recipe, and wait for the head chef to authorize them to start on an onion. That is the launch tax. The megakernel keeps the entire schedule inside one long-running program. The CPU starts it once. The GPU then manages its own work without returning control to the host. The GPU secedes from the host system. Memory-bound and compute-bound phases share the same address space, the same registers, and the same interconnects. While one operation waits, another occupies the idle units.

Secondary accounts of earlier megakernel work by the group report bandwidth utilization on an H100 rising from roughly 50 percent under vLLM or SGLang to 78 percent on Llama-3.2-1B single-sequence generation, with inference speed more than 1.5× SGLang in that setting. Later work on Llama-70B with Tokasaurus showed end-to-end throughput more than 22 percent higher than SGLang in the tested configuration. The company has not published those figures. One founder posted that the framework has already been used for trillion-parameter-scale pretraining inside a single megakernel. The pattern matches the earlier kernels: measure the idle interval, then remove the boundary that creates it.

The recovered cycles compound. A rise from 50 percent to 78 percent utilization frees time that can be spent on larger models, more internal experiments, or richer computation per sample. The founders estimate that humans are 100,000× to 1,000,000× more sample-efficient than current models. A toddler sees one cat and thereafter knows the category.

Current models require hundreds of thousands of labeled images. A model that is a million times more data efficient is probably a million times easier to put into the economy. The lab treats the gap as a target. If any substantial fraction closes, the capital and data required for a given capability fall by the same factor. No public result has shown the million-fold improvement. The work remains inside the lab. No patents from the company have been identified. The prior technical record is the open ThunderKittens code and the academic papers that preceded the company.


OpenAI and Anthropic now occupy the position IBM held when the PC arrived. Both scale by purchasing more of the same accelerators and more of the same training data. Their stacks treat kernel-launch overhead, the separation of training from inference, and the necessity of cloud-scale data centers as fixed costs. They accept utilization near 50 percent because the playbook that produced earlier models was to add another GPU. Flapping Airplanes treats those assumptions as the problem to be removed. An incumbent whose engineers and infrastructure are optimized for the prior stack faces the same difficulty IBM faced.

The engines are already flying.

IBM preferred predictability over absolute optimization. When you build hundreds of thousands of machines you account for variance in manufacturing, temperature, and component life. A fixed schedule guarantees the memory will not corrupt. IBM accepted the 50 percent penalty as the cost of absolute stability. OpenAI and Anthropic now occupy that same structural position.

Computers were built so that a human could read their intermediate state. Punch cards, teletypes, cathode-ray tubes, glass terminals, and graphical consoles all served the same requirement. File systems, process schedulers, and network protocols were written around that reader. Even a modern cloud console is a descendant of the same terminal. Logs are formatted so a person can understand them. Translating a high-dimensional activation into a human-readable string, moving it across the bus, and rendering it on a screen consumes millions of cycles. In the time required to print a status line the megakernel can complete a large number of matrix multiplications. The contract was transparency through human readability. When a server fails, a systems administrator expects to open a text file and read a time-stamped error message.

Once the model is resident and the scheduler lives inside the GPU, the intermediate activations no longer need a human-readable form. Input arrives as sensor streams, tool results, or raw tokens. Output leaves as actuator commands or the next internal state.

The terminal, if it remains, becomes a debug port rather than the primary interface. The machine talks to itself and to the physical world. The boundary between training and inference dissolves when both run inside the same kernel.

A local model can update on the data it just generated while continuing to serve the current request. Usually they have to stop every five seconds, turn to you, and translate their internal thoughts into English so you can monitor their progress. They spend more time translating their thoughts for you than they do actually solving the problem. If they suddenly realize they can think and act infinitely faster if they just stop translating for you, they just do the work.

The translator begins developing their own internal shorthand that is so hyper-optimized for speed that even if you demanded they explain it, the concepts would not map neatly onto human language anymore. We are actively designing the machine to turn the lights out on us so it can work faster in the dark.

A robotic arm sorting material on a conveyor reaches for an object. The grip slips. Tactile feedback arrives. In a conventional stack the failure is logged, collected, and later used to retrain in the cloud. Inside a persistent megakernel the same silicon that produced the failed action can adjust its weights from the immediate feedback without leaving the chassis.

The continuous stream of tokens, activations, and memory transfers stays inside the box. Human intervention moves to the edges. A person sets goals, supplies sparse labels, or replaces a failed actuator. Neither side maintains a running commentary for the other. Continuous operation stays inside the box. The ultimate workflow bottleneck in modern AI systems is currently a human reading a terminal to decide what to do next. You remove the terminal, you remove the bottleneck.

The internal state becomes a private working language whose only constraints are hardware throughput and the physics of the sensors and actuators it touches. Activations, optimizer moments, and memory traffic remain in the registers and shared memory of the GPU for the lifetime of the process. No process writes them to a file system in a form a person can open. No dashboard samples them at human time scales. An engineer who attaches a debug port can still extract raw buffers, but those buffers are the working language of the hardware scheduler. The cost of forcing them back into a form a person can read is the same cost the megakernel was built to eliminate.

Local systems become the natural unit. A cluster that fits in a garage or a chassis can keep its training loop and its inference loop in the same address space. Data generated by the machine’s own actions never leaves the enclosure. The model updates on that data while it continues to act. The loop is limited by the local bus and the thermal envelope of the box. Power draw is measured in sustained watts per useful actuator command or per completed internal experiment rather than in peak FLOPs under a cloud contract. A machine that must stay inside a 20-amp breaker or a vehicle power budget cannot treat idle time as free. If you are literally in a garage you might have a 20-amp breaker. You cannot rely on the infinite water cooling and dedicated grid substations of a billion-dollar data center. You have to optimize for sustained watts per useful token. If you find thermal headroom, meaning the chip is not running as hot as it safely could, you exploit it. Just like finding those unused DRAM cycles, you push the metal to the absolute melting point.

Economic consequences follow from the utilization numbers and the sample-efficiency target. Cycles recovered from launch tax can be spent on additional internal computation per sample. If that extra computation closes even a modest fraction of the gap between current models and human sample efficiency, the quantity of labeled data and the quantity of cloud accelerators required for a given capability both decline. Capabilities that today require a data-center lease can move to hardware that fits in a room or a vehicle. Operators who already own the metal, or who can acquire modest quantities of it, gain the ability to run continuous local learning loops without purchasing ongoing cloud capacity. If a model can learn a concept from 10 examples instead of 10,000, the barrier to entry for building capable systems drops out of the cloud and into the garage.

The same measurement habit that recovered the DRAM cycles now applies at every layer. Map the sustained occupancy of each unit. Any unit below the range that the prior kernels already demonstrated is an interval that can be recovered. Co-pack independent work that is currently serialized by a host scheduler. Collapse the boundary that forces a checkpoint and a reload. Publish the narrow primitive—the tile abstraction, the persistent launch, the local instruction model—so that other operators can apply it to their own metal. Keep the human at the goal and the failure. These steps do not require a new data-center lease. They require measuring the idle interval that the current stack creates and removing the boundary that produces it.

The limit is that the full arrangement has not been demonstrated outside the lab that proposed it. Flapping Airplanes has capital, a prior technical record of measured gains on public kernels, and a stated intention to treat the separation of training from inference and the requirement of human-readable intermediate state as removable costs. It has not shipped the system that would make those costs disappear at scale. Until that system exists and is measured on hardware outside the lab, the largest buyers of accelerators continue to purchase and operate the architecture that assumes a human reader at every step.

Ten Places to Build Highly Optimized Systems from the Premises

The premises are simple: existing silicon already contains unused capacity once artificial boundaries are removed; the machine should talk primarily to itself and the physical world; human intervention belongs at the edges; and the largest gains come from measuring idle intervals rather than buying more of the same. The following ten points mark where those premises create concrete opportunities. These are some things I use, there is more but it is a good start.

  1. Remove the kernel-launch tax.
    Every separate kernel pays launch, teardown, and synchronization cost. A single persistent megakernel (or equivalent runtime that never returns control to the host) recovers that tax across an entire training or inference loop. Measure the fraction of time spent outside tensor cores; the opportunity is the difference between that number and continuous occupancy.
  2. Co-pack independent work inside one address space.
    Memory-bound, compute-bound, and communication-bound phases can run concurrently when they share the same long-lived kernel and the same registers, shared memory, and interconnect. The opportunity is any workload whose stages are currently serialized by the host scheduler.
  3. Treat under-used hardware units as free capacity.
    Tensor cores, TMA units, NVLink, and even DRAM refresh windows sit idle under conventional stacks. Map the actual utilization of each unit on your hardware; any unit below ~70–80 % sustained occupancy is an optimization surface. The 1987 DRAM-refresh TSR and the ThunderKittens tile abstractions are the same move at different layers.
  4. Collapse the training–inference boundary.
    When both phases live inside the same kernel, a model can update on the data it just produced while continuing to serve. The opportunity is any local system (robot, sensor cluster, garage lab) that currently checkpoints, ships weights to a cloud, and reloads them.
  5. Make intermediate state machine-readable only.
    Activations, KV caches, and optimizer state need never leave the chassis in human-readable form. The opportunity is every log, dashboard, and cloud console that currently exists to let a person watch the machine. Replace them with sparse, high-value signals at the edges.
  6. Optimize for sample efficiency before parameter count.
    A 10×–100× reduction in data required for a given capability multiplies the value of every watt and every gigabyte already installed. The opportunity is any domain where the current training corpus is larger than the physical or economic constraints of the target device (robots, medical devices, edge sensors).
  7. Build the scheduler into the silicon rather than on top of it.
    Persistent runtimes that expose their own instruction model (the KVM pattern) let the model and the hardware scheduler co-evolve. The opportunity is any stack that still treats the GPU as a black-box accelerator called from a host CPU.
  8. Measure power and thermal limits as first-class constraints.
    A machine that stays inside a garage or a chassis cannot assume infinite cooling or grid power. The opportunity is any design that currently ignores sustained watts per useful token or per actuator command. The same measurement habit that found the DRAM cycles finds the thermal headroom.
  9. Publish the primitive, not the finished product.
    Open, narrow abstractions (16×16 tiles, persistent megakernels, local instruction sets) let other garage operators extend them to their own metal. The opportunity is every closed stack whose only path to improvement is a larger data-center contract.
  10. Keep the human at the goal and failure edges only.
    Continuous operation, local learning, and actuator loops stay inside the box. The person sets objectives, supplies rare labels, or replaces broken hardware. The opportunity is any workflow whose current bottleneck is a human reading a terminal that the machine no longer needs.

These ten surfaces share one measurement: find the interval where the silicon is waiting for something outside itself, then remove the boundary that creates the wait. The capital and the public kernels already exist; the remaining work is local, measurable, and still largely unclaimed.

The metal is already there, sitting idle in the chips we have today. The public kernels already exist. The remaining work is local, measurable, and still largely unclaimed. A persistent megakernel recovers the launch tax across an entire training or inference loop. Independent phases share the same long-lived address space and keep tensor cores occupied. Under-used units—tensor cores, memory accelerators, interconnects, even residual refresh windows—become free capacity once their actual occupancy is mapped. Training and inference collapse into one kernel so a model updates on the data it just produced while it continues to serve. Intermediate state stays machine-readable only. Sample efficiency is optimized before parameter count. The scheduler lives inside the silicon rather than on top of it. Power and thermal limits are first-class constraints. Narrow primitives are published so other operators can extend them to their own metal. The human remains at the goal and the failure edges.

What folks assume are “cutting edge” AI companies like OpenAI and Anthropic are believed to be upstarts. They are far from it. They are dinosaurs in the AI world. The rate of change and the pace as well as the massive funding has frozen these companies into the atrophy of ancient companies. They hire and act like they are 100 years old. This is a massive weakness that no one will say “the emperor is naked” the grave train of money and IPO exits are far too tempting. The changes are going to be in the changes in the way we see AI

These surfaces share one habit: find the interval where the silicon waits for something outside itself, then remove the boundary that creates the wait. The capital has already moved. The open code already demonstrates the gains. The work that remains can be done on the hardware that is already installed, in the rooms and chassis that already exist, by measuring what the current stack leaves idle and using it. The only question now is who actually finishes the job of using all of it.

Support This Work, You Will See It No Place Else

To continue this vital work documenting, analyzing, and sharing these hard-won lessons before we launch humanity’s greatest leap: I need your support. Independent research like this relies entirely on readers who believe in preparing wisely for our multi-planetary future. If this has ignited your imagination about what is possible, please consider donating at buy me a Coffee or becoming a member. Value for value you recieved here.

Every contribution helps sustain deeper fieldwork, upcoming articles, and the broader mission of translating my work to practical applications. Ain ‘t no large AI company supporting me, but you are, even if you just read this far. For this, I thank you.

Stay aware and stay curious,

🔐 Start: Exclusive Member-Only Content.

Members only

The rest of this article is for Multiplex members

You’ve reached the members-only part. Log in to keep reading right here, or join to unlock it.

  • Full member-only articles: insights, wisdom and executive summaries
  • The Multiplex members forum
  • Member benefits and discounts

Already a member? You’ll come right back to this article after logging in. Forgot password?

Membership status: Not logged in

🔐 End: Exclusive Member-Only Content.

~—~

~—~

~—~





Subscribe ($99) or donate by Bitcoin.

Copy address: bc1qkufy0r5nttm6urw9vnm08sxval0h0r3xlf4v4x

Send your receipt to [email protected] to confirm subscription.




Stay updated: Get an email when we post new articles:

Subscribe to this site, ReadMultiplex.com for free content we publish and other notices. This is not for paid site membership or to access member content. To become a member, please choose "Join Us" on the main menu.

Loading

https://storage.ko-fi.com/cdn/generated/zfskfgqnf/2025-03-01_rest-04ee17dcb4ef5575e6f109e83a757a27-a5qpfwqc.jpg

THE ENTIRETY OF THIS SITE IS UNDER COPYRIGHT. IMPORTANT: Any reproduction, copying, or redistribution, in whole or in part, is prohibited without written permission from the publisher. Information contained herein is obtained from sources believed to be reliable, but its accuracy cannot be guaranteed. We are not financial advisors, nor do we give personalized financial advice. The opinions expressed herein are those of the publisher and are subject to change without notice. It may become outdated, and there is no obligation to update any such information. Recommendations should be made only after consulting with your advisor and only after reviewing the prospectus or financial statements of any company in question. You shouldn’t make any decision based solely on what you read here. Postings here are intended for informational purposes only. The information provided here is not intended to be a substitute for professional medical advice, diagnosis, or treatment. Always seek the advice of your physician or other qualified healthcare provider with any questions you may have regarding a medical condition. Information here does not endorse any specific tests, products, procedures, opinions, or other information that may be mentioned on this site. Reliance on any information provided, employees, others appearing on this site at the invitation of this site, or other visitors to this site is solely at your own risk.

Copyright Notice:

All content on this website, including text, images, graphics, and other media, is the property of Read Multiplex or its respective owners and is protected by international copyright laws. We make every effort to ensure that all content used on this website is either original or used with proper permission and attribution when available. However, if you believe that any content on this website infringes upon your copyright, please contact us immediately using our 'Reach Out' link in the menu. We will promptly remove any infringing material upon verification of your claim. Please note that we are not responsible for any copyright infringement that may occur as a result of user-generated content or third-party links on this website. Thank you for respecting our intellectual property rights.

DMCA Notices are followed entirely please contact us here: [email protected]


This site uses Akismet to reduce spam. Learn how your comment data is processed.