admin published in Technology September 18, 2026

How SpaceX streamlined the Raptor engine

How SpaceX Streamlined the Raptor Engine

Sep 17, 2026

If you’re reading this, there’s a very good chance you’ve seen this famous image of three iterations of SpaceX’s Raptor rocket engine. The Raptor engine was developed for SpaceX’s Starship spacecraft (the Falcon 9 and Falcon Heavy use the Merlin engine); it was first test-fired in 2016, first flew on Starhopper in 2019, and first flew on a Starship prototype in 2020 and on the full Starship stack in 2023. Since then, it’s continued to improve, going from the tangle of pipes and wires you can see on the Raptor 1 to the smooth, streamlined design of the Raptor 3, which first flew in May of this year.

The evolution is so dramatic that many folks initially believed that it wasn’t real; Tory Bruno, the then-CEO of space launch company United Launch Alliance, tweeted that there was “no need to exaggerate this by showing a partially assembled engine,” which was followed by SpaceX president Gwynne Shotwell tweeting a picture of the Raptor 3 firing successfully:

This streamlining has come alongside meaningful gains in performance, with the Raptor 3 providing about 35% more thrust than the Raptor 1.

I wanted to better understand how this evolution actually happened. What, specifically, did SpaceX change that allowed it to go from the tangle of wires and pipes to the svelte, streamlined engine on the right?

There turned out to be less detail available here than I hoped. SpaceX doesn’t publish any official Raptor schematics, and no one has done a teardown of a Raptor engine. But thanks to the occasional comment from Elon Musk, and the speculations of an army of SpaceX fans, we can get some idea of what the major changes have been.

How the Raptor engine works

The Raptor engine is a “full-flow staged combustion” (FFSC) engine. What exactly does that mean?

A rocket engine works by throwing mass (“propellant”) out of a rocket nozzle — due to Newton’s Third Law (“for every action there is an equal and opposite reaction”), this pushes the rocket in the other direction. The more mass you can throw out, and the faster you throw it, the more thrust your rocket engine will produce.

The simplest way to do this is to simply fill a tank full of pressurized gas, and vent some of the gas out. The venting gas propels the rocket, in the same way that letting the air out of a balloon pushes the balloon. This sort of rocket, called a “cold gas thruster,” is often used for making minor adjustments to a spacecraft’s position or orientation. Cold gas thrusters are found on, among other equipment, NASA’s Manned Maneuvering Unit, and the control thrusters for SpaceX’s Falcon 9 rocket.

Cold gas thruster diagram, via Wikipedia.

These engines are simple and reliable, but limited; there’s only so much thrust you can practically get from a cold gas thruster. So how can we get more thrust? One obvious way is instead of a single propellant, we can use two: take a fuel (like kerosene) and an oxidizer (like oxygen) and then burn them together in a combustion chamber, creating hot gas that escapes out the back of your rocket nozzle. Now instead of just using the energy stored in the pressurized propellants, we’re also using the energy stored in their chemical bonds, and converting that energy into thrust. An engine that uses the pressure of the propellant tanks to force fuel and oxidizer into the combustion chamber is called a pressure-fed engine. The engine used for the ascent stage of the Apollo Lunar Module was this type of engine: it used nitrogen tetroxide (N2O4) as an oxidizer and a fuel called Aerozine 50, both pressurized.

Apollo Lunar Module ascent engine, via Engine History.

But now you have a problem. To prevent the burning gases in the combustion chamber from flowing back into the fuel and oxidizer lines (starving the combustion chamber of incoming propellant), the pressure in the combustion chamber has to be lower than the pressure in the fuel and oxidizer tanks and lines. But for a compact, powerful rocket engine, we want to have very high pressures in the combustion chamber. We could deal with this by increasing the pressure in our propellant storage, but this quickly gets impractical: the higher the pressures, the thicker and heavier our storage tanks and propellant lines need to be in order to maintain them without rupture. A better solution is to store the propellants at low pressure, and then feed them through a pump that increases their pressure before they reach the combustion chamber. This is the standard way to build a powerful rocket engine, and virtually every engine used for putting a rocket into orbit uses a pump of some kind to pressurize the fuel and oxidizer.

F-1 engine used on the Saturn V rocket. The pumps for the fuel and oxidizer are on the upper right.

Now we have a new problem: because of the volume of fluid they must handle and the amount of pressure they must add, these pumps require an enormous amount of power to operate. The turbopump on the F-1 engine used on the Saturn V, for instance, required around 41 megawatts of power, slightly less than the power the S8G nuclear reactor delivers to the propeller shaft of an Ohio-class submarine. One way to provide this power is with a battery — Rocket Lab’s Electron rocket has an engine with a battery-powered electric pump — but the more common strategy, employed by virtually every large booster rocket, is to use the rocket’s own propellant as a power source, burning a small amount of fuel and oxidizer to drive a turbine that in turn drives the pump.

There are different ways that a system like this can be configured. The simplest is to route a small amount of fuel and oxidizer to a turbine, and then vent the resulting exhaust. This is known as a gas generator cycle, and it’s what’s used on the F-1 engine, as well as SpaceX’s Merlin engine.

Another option is to burn some of the fuel and oxidizer to drive the pump, but then route the burned propellant through the main combustion chamber along with the unburned fuel/oxidizer. This is known as “staged combustion,” and the smaller combustion chamber used to drive the pumps is called the “preburner.” This is a more complex arrangement than a gas generator cycle, but it’s also more efficient, since the hot exhaust that drives the turbopump isn’t just wastefully vented.

For most staged combustion engines, only a portion of the propellant gets routed through the preburner: the rest gets routed around and goes directly to the combustion chamber. But SpaceX’s Raptor uses a particular type of staged combustion known as “full flow.” In a full-flow engine there are two preburners, one that drives the fuel pump and one that drives the oxygen pump. All the propellant gets routed through the preburners: in one of them, a small amount of oxidizer is burned in the presence of a large amount of fuel (leaving most of the fuel unburned), while in the other a small amount of fuel is burned in the presence of a large amount of oxidizer (leaving most of the oxidizer unburned). The fuel-rich and oxidizer-rich exhaust streams then both enter the main combustion chamber, where they’re burned together.

Full-flow staged combustion schematic, via Wikipedia.

A full-flow staged combustion engine is very complex, and prior to the Raptor only two had been built, neither of which successfully flew on a rocket. The Russians developed an FFSC engine in the 1960s, the RD-270, but it never flew, and the US built part of an FFSC engine called the Integrated Powerhead Demonstrator in the 1990s and 2000s, but it was never developed into a full engine. (When SpaceX began working on the Raptor in 2012, it obtained some of the equipment used on the Integrated Powerhead Demonstrator.) But an FFSC engine has several advantages, one of which is (theoretically) reliability: because so much mass flows through the turbines driving the pumps, the turbines can run cooler and at lower pressure, making them (in theory) more reliable. If you’re a company betting heavily on reusable rockets, a more reliable turbine is obviously attractive.

How the Raptor evolved

SpaceX is, understandably, tight-lipped about many of the specifics of its advanced rocket technology, and there’s less official information on the exact details of how the Raptor operates than you might hope. Nobody has opened up a Raptor engine to show what’s inside, and much of the information that exists comes from Elon Musk’s tweets or his comments in Everyday Astronaut interviews.

There are, however, a lot of SpaceX enthusiasts out there, many of whom do things like obsessively photograph every Raptor engine leaving the factory, and these folks have put a lot of effort into speculating about how the Raptor engine works. The most useful output of this speculation, for me, is the various fan-made schematics that show how the Raptor engine is thought to operate. These schematics aren’t official — they’re made by SpaceX enthusiasts piecing together information from various sources — so they must be taken with a large grain of salt. But they’re still a useful starting point for getting an idea of how people think various versions of the Raptor engine have worked.

To start, let’s look at some schematics of version 1 of the Raptor. The image below was created by Elisei Maslov, a Russian propulsion engineer, in 2019.

Another useful Raptor version 1 schematic is the one below, created by NASASpaceFlight forum member “hisdirt” in December 2019. This is particularly useful because it calls out the various engine components on an actual 3D model of the engine (modeled in Revit, of all things).

You can see in these schematics the basic components of a full-flow staged combustion engine: the oxygen pump, turbine, and preburner are on top of the engine, while the fuel pump, turbine, and preburner are the assembly on the side. You can also see how the fuel flows through the outside of the nozzle before going back into the preburner — this cools the nozzle so it doesn’t melt from the heat of the rocket exhaust, and is known as regenerative cooling.

The next schematic, made by NASASpaceFlight users “Livingjw” and “HVM” in February of 2022, is from Wikipedia, and it shows version 2 of the Raptor. This is less detailed than Maslov’s schematic — it basically just shows the flow of oxygen and methane — but it shows the same basic arrangement: oxygen pump assembly on the top, fuel pump assembly on the side.

And this schematic, posted by Twitter user “TheSpaceEngineer” in January 2025, shows version 3 of the Raptor.

Assuming that these schematics aren’t grossly misleading, we can see that the major architecture hasn’t changed between version 1 and version 3 of the engine. It’s still a full-flow staged combustion engine, and still has the basic arrangement of the oxygen pump, turbine, and preburner assembly on the top, with the fuel pump, turbine, and preburner mounted to the side, with fuel being used to regeneratively cool the nozzle. And you can see that a lot of the smaller lines are the same on versions 1 and 3. Both show nitrogen lines used for purging (clearing propellant out of the system), both show fuel and oxidizer lines going to the igniters, and both have fuel and oxidizer lines carrying gaseous propellant back to the tanks to keep them pressurized as they empty (this is known as autogenous pressurization).

So what changed? If we look closely at the version 1 and version 3 schematics (remembering again that these are unofficial and speculative), we can see a few differences. Version 3 shows the smaller lines bundled together in a “common umbilical,” and if we look at photos of the Raptor 3 connected to a rocket we can see this:

Raptor 3, via the Starship SpaceX wiki. The common umbilical appears to be above the fuel turbo assembly.

The version 1 schematic also shows helium being used to spin up the fuel and oxygen turbines initially, while in version 3 these lines have been eliminated, and nitrogen is used instead. (It’s not amazingly obvious to me if this evolution is correct — some Reddit commenters on the version 1 schematic stated that helium wasn’t used — but there’s some evidence that it is.) Per these schematics, the helium used to control some valves present on version 1 is also absent on version 3, and the version 3 schematic shows no helium lines whatsoever.

The version 3 schematic also notes that a heat exchanger has been eliminated, something echoed by various folks on the NASASpaceFlight forums — this appears to be a gaseous oxygen heat exchanger near the preburner. There’s also a fuel line going to the preburner that’s present on version 1 but is absent on the version 3 schematic.

The more reliable source of changes, of course, is statements by Elon Musk and SpaceX. A 2022 NASASpaceFlight article about SpaceX’s update on the Starship progress noted that “everything from turbomachinery to chamber nozzle to electronics” was redesigned on Raptor 2, the turbopump had shrunk, and the preburner controllers “had been moved to boxes rather than being all over the engine.” An Everyday Astronaut article about the same update also notes that “many valves were combined into valve plates.” In a recent response to a September 5 tweet by Yishan Wong, the former CEO of Reddit, Musk ran down a short list of changes in the Raptor over time:

One big category here is sensors, and the various wires and cables they require. From what I understand, Raptor version 1 was in large part a development engine, and thus required a lot of extra sensors monitoring things like temperature and pressure in various parts of the engine to determine how it was behaving. As the engine got dialed in, a lot of these sensors could be eliminated (though some of them may have been moved internally).

Another thing Musk calls out is the main chamber spark igniters. Igniters, per their name, ignite the fuel and oxidizer in the main combustion chamber. These were present in version 1 of the Raptor, but by version 2 they had been eliminated. Musk doesn’t say what they were replaced with, but this change may have something to do with the fact that the hot fuel and oxidizer exhaust streams from the preburners probably need very little encouragement to combust. (A NASASpaceFlight comment from 2019 wonders if main chamber igniters are even necessary, given the high temperature of the preburner exhaust streams.)

Musk also notes that a lot of bolted flange connections were replaced by welded connections, reducing mass and joints that can leak at the expense of serviceability. This appears to be still taking place, as early Raptor 3 photos show a large bolted flange on the main body of the engine that in later photos has been eliminated:

Another substantial change on Raptor 3 is that much of the piping hasn’t been eliminated, but moved internally, by way of 3D printing many of the components (Musk has previously noted that SpaceX “has the most advanced 3D metal printing technology in the world,” and in 2024 the company licensed the 3D metal printing technology of Velo3D).

Close-up photos of the Raptor 3, in fact, appear to show 3D printing lines:

Photo by Ying Zhang, via catdlr on NASASpaceFlight.

The purpose of this internalization is the removal of more parts, in particular the heat shield and fire suppression systems. The huge mass of wire and pipes on version 1 and version 2 of the Raptor required a large, heavy heat shield to protect it from the heat of the rocket exhaust. Internalizing the various propellant lines and adding internal cooling systems allows this heat shield and fire protection system to be eliminated. In fact, the biggest mass change from version 1 to version 3 of the Raptor comes from mass removal of “vehicle side” engine hardware, which is almost certainly largely the heat shield.

Conclusion

SpaceX’s Raptor engine has undergone impressive evolution, going through several major versions, a dramatic increase in performance, and a dramatic decrease in mass and external components in a short amount of time. The fundamental architecture of the engine hasn’t changed — it’s still a full-flow staged combustion engine, using the same primary components — but the various ancillary elements and components supporting its operations have been modified significantly.

It’s worth noting that while this streamlining has made the Raptor engine simpler in the sense that various individual parts have been eliminated, it was still an (as Musk notes) enormously complex task to get it to work, and there’s a huge amount of internal complexity added to the Raptor 3 that these pictures don’t show. And the problems haven’t been completely ironed out: the first launch attempt of Starship’s flight test 13 was aborted automatically by the vehicle’s flight software at T-0 (right before liftoff) this past July when several Raptor 3 engines failed to start. So the picture of several versions of the Raptor is a snapshot of a piece of technology that’s continuing to evolve.

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Astra for Law

Comments

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

C++26: Trivial infinite loops are no longer undefined behaviour

Let’s start with a question! Is this program well-defined?






1
2
3
4



int main() {
    while (true)
        ;
}

If you said yes, you’d be wrong — at least before C++26. A while (true); loop with no side effects used to be undefined behaviour. Compilers were free to assume it terminates, and some — Clang in particular — would optimize it away entirely, with spectacular consequences:






1
2
3
4
5
6
7
8
9
10
11



// https://godbolt.org/z/WYMxxeW1T
#include <iostream>

int main() {
    while (true)
        ;
}

void unreachable() {
    std::cout << "Hello world!" << std::endl;
}

In Clang, this prints “Hello world!”. The compiler removes the infinite loop, main falls through, and the linker-placed unreachable() function executes. This is not a compiler bug — it’s just UB, still better than nasal demons.

Recently, I wrote about how C++26 reduces undefined behaviour, covering changes like erroneous behaviour for uninitialized reads and making incomplete-type deletes ill-formed. I completely forgot about this one. I only realized while preparing for an upcoming CppCon talk on C++26 features — so here it is now.

C++26 fixes this with P2809R3. Trivial infinite loops are now well-defined. The mentioned proposal was also accepted as a defect report, so implementations may apply the fix to earlier C++ modes as well. That is why you might not be able to reproduce the old behaviour on a recent compiler even in C++20 mode.

How did we get here?

The story starts with the forward progress guarantee, introduced in C++11 alongside threading support. The standard says ([intro.progress]) that the implementation may assume any thread will eventually do one of the following: terminate, call a library I/O function, access a volatile glvalue, or perform a synchronization or atomic operation.

A while (true); loop does none of those things. Under the pre-C++26 forward-progress rules, an execution that remains in such a loop forever has undefined behaviour. The optimizer can therefore assume that execution never gets stuck there, which enables transformations that remove the loop and mark the path as unreachable.

The funny bit is that C got this right. C++11 and C11 both introduced forward-progress rules, but C included one more rule: loops whose controlling expression is a constant expression may not be assumed to terminate. So while (1); is well-defined in C11 and ever since.

C++ never adopted that extra rule. The result was the unnecessary divergence just described, but let’s repeat it: while (1); was well-defined in C but undefined behaviour in C++.

But why would anyone write while (true); in the first place?

What I found is that this is common in embedded and kernel code as a halt-on-error pattern. When a fatal error occurs and there’s no operating system to exit to, you simply stop:






1
2
3
4
5



if (hardware_init_failed()) {
    log_error("fatal: hardware init failed");
    while (true)
        ;  // halt — there's nothing left to do
}

This is not simply a common pattern on bare metal — it was also undefined behaviour in C++. The consequences aren’t theoretical. When the optimizer removes the loop, execution falls through into whatever code the linker placed after it — as the “Hello world!” example at the top of this article demonstrates. In an embedded system, that means a fatal error handler doesn’t actually halt the device. The hardware keeps running in a corrupt state, executing whatever instructions happen to follow. In security-critical code, that’s a real vulnerability.

What C++26 changes

C++26 doesn’t simply copy C’s rule, though. That approach was considered and rejected. C protects a much broader set of loops — broadly, loops whose controlling expression is a constant expression — which could inhibit useful optimizations. Instead, P2809R3 defines a deliberately narrow category: the trivial infinite loop. It’s defined by two conditions:

The loop must be a trivially empty iteration statement — meaning its body is literally empty (; or {}). Any non-empty statement in the body, even a meaningless expression statement such as "a string";, disqualifies it.
The controlling expression must be a constant expression that evaluates to true. For a for loop with no condition, true is implicit.

When both conditions are met, the loop body is replaced with a call to std::this_thread::yield(). This gives execution of the loop the forward-progress semantics it previously lacked.

Here’s what qualifies and what doesn’t:

Code	Trivial infinite loop?
`while (true);`	Yes
`for (;;);`	Yes
`do {} while (true);`	Yes
`constexpr bool go = true; while (go);`	Yes — `go` is a constant expression
`while (true) { "a string"; }`	No — body contains a statement
`while (true) if (done) break;`	No — body is not empty
`while (true) if constexpr (false) break;`	No — doesn’t match the syntax of a trivially empty iteration statement
`bool done = false; while (!done);`	No — not a constant expression

The change also updates the forward progress guarantee itself: a thread may now “continue execution of a trivial infinite loop” as one of the things it’s assumed to eventually do. The optimizer can therefore no longer treat a trivial infinite loop as undefined behaviour and assume that execution continues past it.

The freestanding caveat

On freestanding implementations, it is implementation-defined whether the replacement with std::this_thread::yield() occurs at all. That’s important for bare-metal systems: turning a deliberate halt loop into a cooperative yield could introduce behaviour the programmer never intended.

Conclusion

while (true); being undefined behaviour was one of those C++ facts that surprised everyone who heard it. It was an unnecessary divergence from C, it broke real embedded code, and compilers genuinely exploited it. C++26 fixes it — trivial infinite loops are now well-defined, and the compiler can no longer optimize them away.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let’s connect on Twitter!
if you’re preparing for a C++ quant/trading interview, check out GetCracked

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Everybody's Lost Their Minds

Men. Some would rather vomit up a rambling blog post
wall of text that nobody's going to read than go to
therapy. So here we are.

I've seen my share of stupid over the years, but now
people with no engineering background have started
pitching "industry changing" solutions they cooked up
in their agent infested homelab; people's emails
read like bozotic LinkedIn-fluencer posts with punchy
"it's not this, it's that" single-sentence
paragraphs; online articles suffer a similar fate in
their own convergence on Meh; and half of the people
you interact with have turned into meat proxies.

Spending upwards of 75% of my time directly or
indirectly dealing with AI every day has absolutely
robbed me of most of my enjoyment of my work. Most
days feel like that Twilight Zone where you wake up
and you're the same, but everyone else is different.
(They were all
like that.)

The cyber hype train has been going "choo choo" for a
while, with the main AI companies trying to one-up
each other committing
crimes and somehow we let them; the conscious
choice of anthropomorphic language by the companies is
adapted unquestioned by the media, thereby absolving
AI companies of their incompetence to secure their
programs.

Built on unapologetic exploitation of intellectual
property and concentrating power in the hands of a
very small number of US companies and oligarchs, these
AI models not only lend themselves to generation
of Child Sexual Abuse Material—a product
feature for logged-in
users—1but our continued use of
them also directly supports their role in, e.g.,
military target selection, such as elementary
schools.

Meanwhile, every single company is happy to "ethics
aside…" all of that and spend unimaginable amounts
of "tokens"—a made-up currency following the
casino model2—while staring at you
blankly when you ask whether anybody has bothered to
check if that support chatbot you vibe coded and which
you fed all of your very mediocre at best
"documentation" has any ROI.3

"Frontier Models" and AI-assisted vulnerability
research is another topic with questionable results.
Anthropic and OpenAI tried to one-up each other with
how dangerous their models are and everybody who
considers themselves an industry leader is now part of
some mysteriously named "project" (like Glasswing
and Daybreak, or
Athena
and Akrites) or
co-signed various open letters (like this
or this)
to signal just how much they're totally not left out.

Every participant in these project has thrown
absolutely incredible amounts of engineering resources
at the FOMO-induced, time-limited, "the first one's
free" offer from Anthropic and OpenAI. Dozens of
highly-paid security engineers had all of their
priorities shifted and spent all of their
time on this; the cost of the engineering hours
spent on developing and adjusting AI vulnerability
discovery harnesses, building new processes and
pipelines to shoehorn thousands of findings into their
vulnerability management processes, and of course
working with the product owners on assessing and
fixing the findings… all that must run in the many,
many millions of dollars for each organization.

And yet, despite having found literally
thousands of new vulnerabilities (only a
fraction of which were reported to Open Source
projects, by the way), I don't think that we're
any safer than before. That's because
finding vulnerabilities has never been the
bottleneck in information security. The bottleneck
isn't even verifying a vulnerability report
and validating its severity, as time consuming as that
is. The bottleneck isn't determining the fix,
creating the patch, or publishing a new release. The
bottleneck is still, as ever before, getting the
goddamn packages updated. Patching is still hard.

Now imagine that we had spent all these resources on
doing the basics: ensuring your organization has an
up-to-date and comprehensive asset inventory with
fine-grained package listings; building infrastructure
that supports regular, frequent, and automated OS and
applіcation updates; automatically rebooting systems
when they hit, say, 30 days of uptime to ensure these
updates are picked up; establishing comprehensive
attack surface enumeration across all your IP space
as well as all your cloud providers (what a
concept!); the list of basic, fundamental defenses
that nobody seems to actually do well goes on. Having
a few dozen senior engineers dedicated for 6 months to
overhauling all that, focusing on making
patching easier, would, in my book, have been
a much better investment, but that's just not very
cyber at all.

No matter what AI promises, human resources are still
a zero-sum game, and every individual feeling super
busy in their agentic silo doing a thousand things at
once does not, in the end, help solve the kinds of
projects that require cross-functional collaboration
and team work.

At the same time, AI companies are falling over
themselves once again facetiously calling for their
own regulation because, you know, they could
accidentally end all mankind.

If you actually thought your product will kill all
humans, then you could, you know, like, just stop
building the torment nexus. All by yourself, no
government regulations required. Nobody's forcing you
to play "Theaterwide Biotoxic and Chemical Warfare" or
"Global Thermonuclear War". I mean, except your
future shareholders and your greed. Alas, that
wouldn't cockblock your competition…

But you don't need to imagine AI destroying all
humankind within the next few years via some sort of
Skynet or Paperclip Maximizer scenario when in reality
AI has of course already been hard
at work here. The environmental impact of these
companies is staggering.
The AI race demands more and more water wasting, air
polluting, fossil fuel powered data centers that
absolutely nobody wants to live close to, and
governments lift any and all environmental regulations
for these companies who not too long ago at least
pretended to have even the feeblest
greenwashing commitments to carbon neutrality or
renewable energy sources.

But "the
world looks different now", to which I can only say
"No fucking shit, Sherlock. IT'S
ON FUCKING FIRE. Because of you."

You know there are two ways for AI to achieve
superhuman intelligence, right? One (theoretical) way
is the mystical "recursive self-improvement" by AI.
The other one is the path we're very clearly on: The
agentic brain worms have been spreading, and it looks
increasingly like everybody's lost their goddamn minds
already. AI is the tool that dulls its users; it
incrementally replaces understanding with a
new dependency and addiction as you actively de-skill
yourself.

AI helps people find more vulnerabilities in existing
code. To address those vulnerabilities, people use AI
to generate patches. The resulting pull requests are
then "reviewed" by AI. That is, the more AI is in the
loop, the less we understand the code base. The
mystical "human in the loop" often is nothing more
than a rubber
stamp.

So what happens when things go bump? Complex systems
fail in complex ways, and debugging code is an order
of magnitude harder
than writing code. Debugging somebody else's code
is harder still. Trying to debug large, complex,
distributed systems consisting of components that are
effectively opaque to your entire organization is
going to be impossible.

So no, I'm not going to set ethics aside and then
actively offer myself up as tribute to self-amputate
my brain. I'm sorry if everybody else can't get rid
of the brain slugs, but at this point I'm just looking
to get off this ride.

P.S.: And no, Claude is not
conscious. J-Space my ass.

[1] Damn straight I use an emdash. Fuck
you for devaluing it.
&larrhk;

[2] "Results showed that participants
gambled significantly more with chips than with real
cash." [citation provided]
&larrhk;

[3] It doesnt: LLMs are Garbage-In/Garbage-Out—if
you have shitty docs, the AI can at best polish that
turd and still only spit out nothing of use.
&larrhk;

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Show HN: Ax-check.com – Can agents use your product?

ax-check.com

by Gauge

How far can an agent get with your product?

We check your site, then three agents try to onboard end to end. We give you concrete guidance on what to fix in your docs, marketing site, CLI, MCP, or Skills.

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Canto: A speech model built for the real world

17.09.2026 • Research • 10 min

Canto: a speech model built for the real world

Wispr AI Lab

Speech recognition models have become remarkably good at transcribing clean audio recorded under controlled conditions. But real dictation rarely happens under those conditions. Millions of people use Wispr Flow to message friends, write emails, code, and work through ideas at their desks, between meetings, during commutes, and in busy offices. They speak through laptop microphones, earbuds, and headsets, often with other voices, music, or traffic in the background.

Today, the Wispr Advanced Interfaces Lab is introducing Canto, our latest speech model for real-time dictation. On an evaluation of real-world dictations, Canto achieved the lowest word error rate among all the models we tested. We compared Canto with models from Google, OpenAI, AssemblyAI, and Deepgram.

Canto is the first model in a broader research and development program at Wispr Advanced Interfaces Lab. In this post, we share how it performs, how we trained it to handle challenging real-world conditions, and the research already shaping what comes next.

“Today, the Wispr Advanced Interfaces Lab is introducing Canto, our latest speech model for real-time dictation.”

Ariya Rastrow

CSO, Wispr Flow

Evaluating Canto in real-world conditions

To test Canto in real-world conditions, we created an evaluation set composed of 10 hours of English-language Wispr Flow dictations from more than 2,300 unique speakers, randomly sampled across applications and use cases. We were careful to enforce a strict separation between speakers represented in the train and test sets to avoid overfitting on speaker characteristics. Every sample came from a user who opted in to Wispr’s data-sharing setting, which allows their data to be used anonymously to evaluate and improve our models. More information about this setting is available in our data-controls documentation.

Canto achieved the lowest Word Error Rate (WER) of the models in our comparison. WER measures word substitutions, omissions, and insertions relative to a human-transcribed reference (lower is better).

Word Error Rates on 10 hours of Wispr Flow dictations, randomly sampled across applications and use cases.

Performance under the most challenging conditions

The model performed well on randomly sampled data, but we were also interested in studying its performance in the most challenging situations. We built a separate, 3-hour challenge evaluation set that featured those conditions most likely to cause dictation to fail.

The set includes audio affected by nearby speech, music, traffic, wind, low recording volume, and whispered or far-field speech. It also includes short dictations that give a model very little surrounding context and language to help resolve ambiguity. On the full challenge set, Canto ranked second behind Gemini 3.1 Pro, a much larger frontier-size multi-modal model that is not suitable for real-time low-latency applications. Among the real-time transcription models we evaluated, Canto achieved the lowest WER.

Word Error Rates on a 3-hour audio challenge dataset, assembled to stress-test transcription models under the most difficult real-world conditions.

We further examined this dataset to understand how the models behave differently. Gemini 3.1 Pro achieved the lowest WER on noisy audio. Canto tied for the lowest WER on low-volume speech and short dictations. Short dictations produced the highest error rates across the comparison. A single mistake has a larger effect on WER when an utterance contains only a few words, and the models also have less linguistic context available to resolve ambiguity.

Word Error Rates across three subsets of the audio challenge set. Noisy audio was defined by low SNR dictations where there was significant background noise (i.e. traffic, wind, competing background speech). Low volume samples were made up of whispered or far-field speech. Short dictations were 1-2 word samples where there was little surrounding context.

Comparing performance on public benchmarks

We also evaluated Canto on three public English datasets: LibriSpeech, FLEURS, and Common Voice. Canto tied for the lowest WER on LibriSpeech. It remained competitive on FLEURS and Common Voice, although it did not lead either evaluation.

Word Error Rates on the English subsets used in our evaluation: FLEURS, LibriSpeech, and Common Voice. Models were evaluated without contextual prompting.

These public datasets provide useful, reproducible comparisons, but they largely contain read speech. LibriSpeech is drawn from audiobooks, while FLEURS and Common Voice consist primarily of people reading prepared sentences. They capture a different distribution from everyday “in-the-wild” dictation, where people speak spontaneously, pause, revise their thoughts, and often provide very little linguistic context. The contrast helps explain why we evaluate Canto on both public datasets and real Wispr usage.

Post-training Canto with Supervised Fine-Tuning and Reinforcement Learning

Canto starts from a model pretrained on millions of hours of speech and text. We then train Canto in two stages. First, we show it audio paired with reference transcripts. The model learns to predict the words in each transcript, one step at a time. This stage, called supervised fine-tuning, teaches it how to perform the transcription task. Next, we train it to compare the quality of complete transcripts. For the same audio, the model generates several possible transcriptions. We score each one against a reference, then use those scores to make better transcriptions more likely in future training. This is known as reinforcement learning, or RL.

The distinction is in how the model receives feedback. Supervised fine-tuning provides the expected words at each step. Reinforcement learning evaluates the completed transcription (generated by the model). That lets us train around the outcomes we care about, such as reducing recognition errors under difficult recording conditions. Our approach uses Group Relative Policy Optimization, or GRPO. The central idea is simple: compare the candidate transcripts within each group and learn from their relative scores. For each audio example, we sample several candidate transcripts from the model being trained. We call these candidates rollouts. Each receives a reward: a numerical score measuring how well it satisfies the training objective.

GRPO compares each candidate’s reward with the rewards of the other candidates for the same audio. The resulting relative score, called an advantage, indicates whether that candidate performed better or worse than its group. These advantages guide the training update.

Sequence-level training has a long history in speech recognition. Researchers have previously optimized ASR systems using minimum word error rate training and policy-gradient methods. GRPO was introduced more recently in DeepSeekMath, and direct applications to autoregressive speech recognition have only begun to appear in recent work on GRPO for ASR and speech-domain adaptation.

“We built infrastructure that can generate and score speech rollouts at scale, allowing us to construct training environments around specific behaviors and failure modes.”

For Wispr, the value of RL is not just a lower aggregate error rate. We built infrastructure that can generate and score speech rollouts at scale, allowing us to construct training environments around specific behaviors and failure modes. That system now supports experiments in contextual speech recognition, personalization, diarization, and difficult audio conditions. The research described below extends beyond the training used for the released Canto model and is already informing the next generation of our models.

Learning from corrections

The usage of names and vocabulary changes faster than speech models can be retrained. A word such as “Claude” might once have been an uncommon alternative to “cloud.” As its usage changes, a practical dictation model needs a way to learn the distinction.

For users who have opted into data sharing, corrections can provide a valuable signal for improving recognition. But not every edit points to a transcription error. People also change formatting, rewrite sentences, or simply change their minds.

A hypothetical example below illustrates this problem. The model transcribed “Claude” as “cloud,” which the person corrected. They also changed their mind and rewrote the end of the sentence. Only the first change represents a recognition error.

A hypothetical example. The local correction from “cloud” to “Claude” is retained, while the unrelated rewrite is discarded. We can selectively graft the ASR error into the training target for RL.

We use signals from the audio and the edit itself to identify corrections that are most likely to represent recognition errors. These include forced-alignment confidence, which measures how well candidate words match the audio, and the location and shape of the edit. We then graft only the likely correction into the original transcript, leaving the rest unchanged.

The resulting transcript becomes the reference used to score GRPO rollouts. A hypothesis receives a higher reward when it makes the intended correction. Because GRPO centers the advantages within each group, words shared by higher-reward and lower-reward hypotheses receive offsetting signals. This does not provide perfect token-level credit assignment, but it makes the strongest contrast more local to the decision we care about. Grafting turns a noisy document-level edit into a more focused sequence-level training signal while preserving the on-policy nature of GRPO.

Illustrative group of six model-generated transcripts. Each rollout receives a reward of 1-WER against the grafted reference. Rewards are then standardized within the group to compute advantages.

Learning to use context selectively

At runtime, Canto is provided with specialized vocabulary from a person’s dictionary. This helps the model recover names and rare terms that may be difficult to identify from audio alone. Providing phrases to guide recognition is a longstanding area of contextual ASR research. The difficult part is deciding how strongly the model should trust that context.

Suppose “Barry” appears in someone’s dictionary and they dictate, “I want to make a berry salad.” In poor recording conditions, both words may be acoustically plausible. An overeager model might choose “Barry” because it appears in the dictionary, even though “berry” is what the person said.

To measure this behavior, we started from an SFT checkpoint and trained the model using RL while providing truthful context on 10% of training examples. We then tested the model with synthetic distractors that varied in phonetic similarity to the correct word. A distractor flip occurs when adding one of these false suggestions causes the model to adopt it.

Context adoption before and after RL training. Providing the model with the true context during training leads to better truth adoption compared to the SFT checkpoint (left panel). Training simultaneously leads to a tendency to use overeager context. Phonetically similar distractors are more likely to be chosen during transcription.

After RL training, the model became more responsive to context, including when that context was wrong. Among the most phonetically similar terms, it adopted the distractor nearly five times as often as the initial SFT model. The training had made the context more useful, but the model sometimes trusted it too readily.

To separate context adoption from context discrimination, we trained three runs from the same SFT checkpoint. In always true, the supplied context contained only the correct term. In distractors + true, the correct term appeared alongside phonetically similar alternatives. In distractors only, selected examples contained plausible near-misses instead of the correct term, while the reward continued to favor the transcript supported by the audio.

At every checkpoint, we ran two probes. The vertical axis measures adoption of correct context, while the horizontal axis measures how often false context changes the transcript. The ideal trajectory moves upward without moving to the right.

Context adoption and false-context following over the course of RL training. Each run begins from the same SFT checkpoint. When training with context, the model will learn to both adopt correct context while also being susceptible to phonetically similar distractors. Providing phonetically similar distractors during training (red) helps to reduce distractor adoption.

The trajectories suggest that each mixture teaches a different relationship to context. With always true, the model can learn a simple shortcut: when a supplied term resembles the audio, use it. This improves adoption of correct terms, but also increases false-context following. With distractors + true, context becomes a selection problem. The correct answer is present, but it must be distinguished from plausible alternatives. The model is rewarded for choosing the candidate best supported by the audio, not merely for copying from the list. With distractors only, context becomes adversarial. Blindly adopting any supplied term now loses reward, so success requires resolving the conflict in favor of the audio. This pushed false-context following further left while preserving a similar level of correct-context adoption.

These experiments do not yet define a final context policy, but they show that the tradeoff itself is trainable. The goal is not simply to make the model follow context, but to also teach the model when context deserves to be followed.

What comes next

Canto is the first model in a larger family. We are already training its successor at more than ten times Canto’s scale, with the goal of improving recognition under difficult audio conditions, improving multi-speaker recognition (for our recently launched notetaker product), making better use of contextual vocabulary, and reaching the same standard across more languages. The post-training approach described here will also let us introduce more specialized rewards and harder training environments as the models grow.

One focus is a unified architecture for transcription and diarization. Meeting-transcription systems often recognize words and identify speakers in separate stages, allowing errors in one stage to compound errors in the other. A joint model can reason about what was said, who said it, and when the speaker changed at the same time. Speaker structure can also provide useful evidence in noisy settings, helping distinguish the conversation being transcribed from unrelated speech in the background.

Over time, our speech models will need to do more than recognize words. They will need to use context selectively, understand the application in which someone is speaking, and connect what was said with what the person is trying to accomplish. Canto gives us the speech model, training approach, and evaluation framework from which to pursue that broader interface.

These remain open research problems. If you work on speech recognition, reinforcement learning, diarization, multilingual modeling, or multimodal interfaces, the Wispr Advanced Interfaces Lab is hiring.

Check out our latest articles

Advancing HCI

Wispr is rethinking human-computer interaction — reducing cognitive friction so technology finally feels effortless, intuitive, and built around how you think.

06.05.2026 • Insights

Introducing Wispr Advanced Interfaces Lab

Wispr CSO Ariya Rastrow introduces the new Wispr Advanced Interfaces Lab. Learn how we’re solving the AI interface problem by moving beyond voice-to-voice systems toward intent-driven, context-aware outcomes.

24.07.2026 • Product

Why supporting 100 languages is hard

At Wispr Flow, we’re building toward that goal: natural, accurate voice-to-text in 100+ languages. It may sound simple, but it’s one of the hardest technical challenges in AI.

19.01.2026 • Insights

Help build the interface between humans and intelligence.

See open roles

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

From Geometry to Algebra and Back Again: 4000 Years of Papers (2023) [video]

Comments

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

T. Rex Had a Body Temperature of 97 Degrees

Comments

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Zettascale (YC S24) Is Hiring ASIC/FPGA Engineers to Build Chips for ASI

← Home

Careers

Open roles

Don’t see your role?

We’re always looking for exceptional people. Send a demo of something you’ve built that you’re proud of to careers@zscc.ai and we’ll talk if it’s relevant.

Source: Hacker News

0 Share

admin published in Technology September 18, 2026

Meta ordered to remove UK deepfakes as oversight board criticises ‘inadequate’ safeguards

Meta has had policy changes recommended to it, including demoting ‘high risk’ content, making it less likely to appear in users’ feeds. Photograph: Daniel Cole/Reuters

Meta ordered to remove UK deepfakes as oversight board criticises ‘inadequate’ safeguards

Facebook told it was wrong in leaving up AI-generated videos of a Labour councillor and Muslim campaigner, amid calls to curb fakes

Meta’s “supreme court” has ordered the tech company to take down deepfake videos of a UK politician and a young Muslim woman from Facebook and do more to tackle AI-generated fake imagery.

A fake video showing a Labour party councillor in Scotland making inflammatory comments about refugees should not have been left up by Facebook, the board said. It also ruled that an AI-generated video of a Muslim campaign volunteer should have been removed after it falsely depicted her offering health advice while carrying out absurd exercises or eating junk food.

The board said Meta’s safeguards were “consistently and fundamentally inadequate” to address the rapid rise of AI deepfakes.

“From politicians to private citizens, AI-generated deepfakes are increasingly being used to harass and silence women from engaging in public discourse,” said Pamela San Martin, an oversight board co-chair.

“These cases demonstrate a broader, troubling pattern in which women who engage publicly on issues are disproportionately subjected to harassment and misinformation. Meta and other social media platforms need more robust policies to address the proliferation of deepfakes.”

In the Scotland clip, the councillor is falsely represented as saying: “Refugees are welcome here, even if they rape our women, because white people do that too.”

The oversight board, a quasi-independent body whose decisions are binding, said the video of the councillor appeared to be AI-generated, as indicated by the audio not being fully synchronised to the unnamed councillor’s facial movements.

Even when raised directly with the company by the board, Meta decided the video did not violate its content policies and did not merit an AI label.

In a blogpost published on Thursday, the board said the post should have been removed because it violated Meta’s rules on hateful conduct by alleging criminal and predatory sexual behaviour by refugees as an entire group and not as individuals. The video should also have received a “high risk AI” label, said the board, as it called for tougher measures on deepfakes.

“The majority [of the board] finds that Meta needs more robust policies on deepfakes, including expanding the situations when ‘high risk’ labels can be applied, more measures to reduce the spread of deceptive AI content, increasing the penalties for accounts that repeatedly share it, and more transparency on data around when AI labels are applied,” it said.

The board recommended nine policy changes at Meta, including ensuring algorithms demote content labelled “high risk”, making such posts less likely to appear in users’ feeds. It also recommended that Meta makes it more difficult for users to view AI-generated content by, for instance, introducing a warning screen that requires a click-through before viewing the content.

In a separate ruling, the board also ordered Meta to take down from Facebook an AI-generated video mocking a young Muslim woman in Europe taking part in a campaign to improve menstrual health education and reduce stigma around health conditions for women and girls from ethnic minority backgrounds. AI-manipulated videos and images mocking the woman had tens of millions of views online, including on Meta platforms.

The board singled out one of the videos – showing the woman exercising absurdly and eating junk food – as a breach of the company’s bullying and harassment policy. It recommended the post be removed and made three policy recommendations, including changing its definition of “unwanted manipulated imagery” to cover deepfakes of a private individual saying or doing things they did not say or do.

The board was set up by Meta in 2020 to serve as a referee for content on its platforms. Meta has been approached for comment.

Explore more on these topics

Reuse this content

Source: Technology

0 Share

Community Chit Chat

Technology

How SpaceX Streamlined the Raptor Engine

How the Raptor engine works

How the Raptor evolved

Conclusion

How did we get here?

What C++26 changes

The freestanding caveat

Conclusion

Connect deeper

How far can an agent get with your product?

Canto: a speech model built for the real world

Evaluating Canto in real-world conditions

Performance under the most challenging conditions

Comparing performance on public benchmarks

Post-training Canto with Supervised Fine-Tuning and Reinforcement Learning

Learning from corrections

Learning to use context selectively

What comes next

Check out our latest articles

Advancing HCI

Introducing Wispr Advanced Interfaces Lab

Why supporting 100 languages is hard

Help build the interface between humans and intelligence.

Open roles

Don’t see your role?

Meta ordered to remove UK deepfakes as oversight board criticises ‘inadequate’ safeguards

Olympus

Main links

Your Profile

Olympus

Blog