When AI handles 95% of your incident response, do you get worse at handling the 5% that actually matters?

There are two popular prophecies floating around tech circles these days.

The first says SRE is the future of all software engineering, that as AI writes more and more code, the humans who remain will be the ones keeping systems alive. The second says AI will devour every tech job alive, SREs included. Neither is particularly useful if you’re an SRE trying to figure out what your Tuesday will look like in 2027.

Let’s ask a more grounded question by looking at what’s already happening: When AI handles 95% of your incident response, do you get worse at handling the 5% that actually matters?

Most of us already use AI for our daily work (our brains a little fried!), and so do SREs. Today’s discussion agenda is not whether AI replaces SREs, but whether AI is quietly making SREs less capable and whether anyone will notice anything before the next novel outage hits. The foundational framework for this entire debate comes from a 1983 research paper that’s eerily prescient.

The Ironies of Automation: Part-I

Note from author: Below is a brief precursor to History of Automation, which you might enjoy if you are into History and Cultures (like me 😉).

In 1983, a cognitive psychologist named Lisanne Bainbridge published a paper called Ironies of Automation. It became one of the most cited papers in human factors research, and its core argument is almost uncomfortably relevant today.

Bainbridge studied what happened when factories and industrial systems automated the work of blue-collar operators. The findings were paradoxical and revealed that the more you automate a process, the more critical the human operator becomes during the rare moments automation fails and the less practice they get, and the worse they become at exactly those interventions. Automation, which was inherently designed to remove humans from the loop, left them with the worst possible job, i.e., long stretches of passive monitoring punctuated by rare, high-stakes crises they were increasingly unprepared for.

Ring any bells yet? 🙂

Basically, I’m drawing a parallel between the AI revolution and industrial automation. Industrial automation reshaped blue-collar work by taking over routine physical tasks, and the workers who remained had to handle exceptions they’d lost the muscle memory for. AI is doing the same thing to knowledge workers by taking over the routine cognitive tasks, the pattern matching, the triage, the known-issue resolution and leaving humans with the rare, complex, ambiguous problems.

The exact problems that require deep expertise, the exact expertise that atrophies when you stop practising.

Now we’re replaying this pattern with AI agents, and the stakes in software systems are only growing.

Current State of AI in SRE

Let’s take stock of where things stand today in the world of site reliability engineering.

What’s already automated or heavily AI-assisted?

Alert noise reduction and intelligent grouping, runbook execution for known issues, log pattern detection and anomaly flagging, and basic root-cause suggestions from historical incident data, and auto-remediation for well-understood failure modes like restarting a crashed pod or scaling up a service that’s running hot, are all fairly automated today.

What’s on the horizon?

Some immediate targets include multi-signal correlation across metrics, logs, and traces, autonomous root-cause analysis for partially understood failures, predictive incident detection before users are affected, AI-driven change risk assessment and automated rollbacks.

PagerDuty frames this as a tiered model.

• Tier 1 incidents: Known issues with known fixes get fully automated.
• Tier 2 incidents: Partially understood problems receive AI recommendations with human validation.
• Tier 3 incidents: Novel, complex, cascading failures stay human-led, with AI providing supporting context.

But here’s the catch.

If human SREs (okay, now we have to use adjectives like human 🥹) only engage with Tier 3 incidents, i.e. the novel, never-before-seen outages, where do they build the intuition to handle them? Intuition is usually developed from years of hands-on incident response, pattern recognition built through repetition, and the kind of gut-level understanding of a system that only develops from painfully waking up at the odd hour to solve the bug that brought the system down.

The Crisis of Deskilling

This is where the picture starts getting blurry. Let’s look at some emerging research on AI-induced deskilling across multiple fields, which paints a consistent and concerning picture.

In medicine, a recent study found that endoscopists who used AI assistance for polyp detection saw their unassisted detection rates drop from 28% to 22% after a period of AI use. They got worse at the thing they were supposed to be experts in, not because they forgot the theory, but because they stopped exercising the skill.

In aviation, research has shown that long-haul pilots who rely heavily on autopilot systems experience measurable degradation in situational awareness and manual flying ability. The problem got serious enough that the FAA now mandates more manual flying time to counteract the effect.

Somewhere over the past year, AI stopped being a tool I occasionally reached for and became the first thing I reach for, always. My instinct now is to offload as much as possible and apply my own thinking only where it’s absolutely unavoidable. The problem is that these moments are becoming the only exercises my brain gets, and I can feel the rust.

We can draw a pattern here. The more you let the system handle, the worse you get at handling things yourself and here’s the truly dangerous part, you don’t feel it happening. It gets masked as hyper-productivity. Cognitive research suggests that because AI tools make tasks feel easier and enhance visible performance, users are often unable to accurately judge the true status of their own skills. You feel competent, dashboards look green, and then on a Wednesday, a novel incident hits that doesn’t match any pattern the AI has seen, and you realise the muscle has atrophied.

For SREs, this manifests in specific ways, like we stop reading raw log streams because the AI summarises them, we stop forming hypotheses during incidents because the AI suggests root causes, we stop building mental models of system architecture because the AI maps dependencies for us, and each of these individually looks like a productivity win. Collectively, they hollow out the very expertise that makes an SRE effective when things go sideways in ways nobody anticipated.

But there’s something even more concerning than deskilling, and researchers have started calling it never-skilling. Deskilling means you once had a capability but have since lost it. Never-skilling means you never developed it in the first place. For junior SREs entering the field today in an environment where AI handles most of the incident response workflow, the opportunities to build foundational intuition and muscle through hands-on practice are vanishing.

The training pipeline itself is broken and not self-healing.

SREs realise their skills are degrading and lean more on AI to compensate, which further degrades their skills, creating a vicious cycle from which escape is difficult.

What Can We Do About It?

We are definitely not rejecting AI tooling; we are adopting it and integrating it stronger than ever before, because that’s the only way forward.

A few approaches worth considering:

Deliberate inefficiency. Just as the FAA mandates manual flying time even when the autopilot is perfectly capable, SRE teams can designate certain incidents, even the ones the AI could handle, as human-practice opportunities. This can be considered as a long-term investment to keep skills fresh, although it might come at the cost of a super-fast solution

Build for human-in-the-loop, not human-on-the-side. There’s a meaningful difference between a system where a human approves an AI’s recommendation and one where a human actively engages with the problem alongside AI. The former keeps humans in a supervisory role that Bainbridge (the lady who wrote that research paper about 40 years ago) showed leads to vigilance decay, and the latter keeps them cognitively engaged.

Let’s zoom out and take a look at the bigger picture.

The Bigger Picture

Everything we’ve discussed here, the ironies of automation, the deskilling risk, the never-skilling problem, collectively applies well beyond SRE. Software engineering as a whole is navigating the same tension. As AI writes more code, reviews more PRs, and handles more debugging, the same questions apply.

We’re talking about SREs specifically because that’s the world we live in at SigNoz. We build an open-source observability platform, the kind of tool that gives SREs the metrics, traces, and logs they need to understand their systems deeply. For us, this deskilling question is not a rhetorical fad; it directly shapes how we’re building AI into our product.

Our approach is to start with an AI assistant that helps SREs leverage the power of LLMs while keeping humans firmly in control. Eventually, we’ll enable more autonomy but within clear guardrails, and only as trust is earned.

One advantage we have in this space is that, as an observability platform, we sit on the data itself, the metrics, traces, and logs that SREs rely on. Most AI SRE products today integrate with observability tools through APIs, which means they’re working with a limited, second-hand view of your systems. Because we own the data layer, we can build much deeper, more context-aware AI capabilities that understand your system the way an experienced SRE would.

And to answer the burning question in your head, our goal isn’t AI that replaces SREs. It’s AI that supercharges SREs. Unlike ongoing lore, we believe humans will remain essential for the decisions that matter most, especially those that impact production infrastructure.

The future of SRE is human with AI intentionally designed to keep humans sharp, engaged, and ready for the 5% that really counts.

Here’s the LinkedIn post our founder posted a few days ago, which inspired me to write this.

Thanks for reading Observability Real Talk!

Multiple crypto-tracing firms say notorious North Korean hackers TraderTraitor may be behind the largest digital heist in history—with billions of crypto likely gone for good.

Photo-Illustration: Wired Staff; Getty Images

Cryptocurrency firms and investigators are racing to freeze and track down billions of dollars of stolen digital cash following what appears to be the largest crypto heist of all time. On Thursday, starting at around 4pm ET, hackers started quickly siphoning around $6.3 billion in cryptocurrencies, spread across multiple blockchains, from wallets belonging to crypto exchange Binance.

Following the theft, Binance almost immediately suspended all deposits and withdrawals from its services as part of its investigation into the hack and says it is working to identify who was behind the breach. The company, along with other crypto firms, says it has so far been able to freeze around half of the stolen funds—essentially stopping hackers moving the money further or trying to cash it out. Much of the remaining crypto may not be possible to freeze, however.

Three crypto tracing firms have been quick to link the attack potentially to North Korean hackers. “We think North Korea is likely responsible,” Tom Robinson, chief scientist and cofounder of Elliptic, tells WIRED. “If North Korea is behind it, this one theft would almost double everything the regime has stolen in crypto to date.”

The majority of the stolen crypto was taken in a period of around 20 minutes on October 29, according to analysis by crypto tracing firm TRM Labs. Wallets belonging to Binance across at least ten blockchains—including Ethereum, Bitcoin, Tron and Solana—were drained and sent to multiple addresses controlled by a single attacker, according to TRM’s analysis. “Preparation began at least 36 hours before the theft,” TRM says in a blog post. The company says one of the attacker’s wallets received three small withdrawals during a test period, before later expanding the operations.

“Early on October 29, the operator deployed a first piece of code for the attack and tested it on two wallets,” TRM says. “Later that day, it rehearsed the final version on a third wallet, then routed the test funds back to itself. Four hours after that rehearsal, the same code was installed on a Binance hot wallet.” Hot wallets are cryptocurrency wallets that are internet connected and allow crypto exchanges to handle customer withdrawals. Analysts say the funds were drained from hot wallets across the impacted blockchains.

The tactics used in the hack appear to mimic previous methods used by an elite subset of North Korean hackers, known by the name TraderTraitor. Crypto tracing firms TRM Labs and Chainalysis both say they believe TraderTraitor may be behind the attack, while Robinson says Elliptic hasn’t specifically tied it to the group but sees overlaps in the activity.

Neither Binance nor law enforcement officials have named any suspected links between the attack and North Korean hackers. Over recent years, North Korean hackers have repeatedly targeted cryptocurrency firms and stolen hundreds of millions in crypto heists. Multiple North Korean hacking groups can target companies in the sector, but TraderTraitor have become specialists, pulling off infrequent but high profile attacks.

Within North Korea’s sprawling hacking operations—often designed to earn money for the highly sanctioned and repressive regime—TraderTraitor has stood out in recent years for its sophistication and targeting of crypto and decentralized finance companies. Last year, the FBI named TraderTraitor as being responsible for the $1.5 billion hack against crypto exchange Bybit.

Binance did not answer WIRED’s questions about whether it believes North Korean hackers are behind the colossal heist, pointing towards a statement saying it will cover all losses from the hack and is working with law enforcement officials to identify who is responsible.

“Our initial investigation suggested that the security incident may have involved a compromised laptop, however, our subsequent investigation has uncovered additional points of breach,” the company says in a statement. “This was a complex attack, and we are doing all we can in coordination with law enforcement to resolve it.”

“These folks in particular are somewhat artists in terms of getting into these distributed finance organizations,” Rafe Pilling, a senior director of threat intelligence at security company Sophos, tells WIRED. “TraderTraitor seems to focus on these larger operations. In the past, they’ve developed their own fake applications and tried to use those to get inside organizations.”

TRM and Chainalysis have initially linked the attack to TraderTraitor and say the determinations are based on their analysis of both on-chain and off-chain activity. “​​The strongest evidence emerged when Chainalysis investigators observed, in real time, funds stolen from Binance commingling with funds stolen in last month’s Bitget exploit, which had been attributed to North Korean actors,” a research blog from Chainalysis says.

“Binance says the attack began with a compromised engineer’s laptop. Targeting crypto company staff is a TraderTraitor hallmark,” Elliptic’s Robinson says. “The attacker funded their wallet through Tornado Cash and rehearsed the attack in advance, as in Bybit.”

While around $3 billion of cryptocurrency was initially frozen in the aftermath of the attack, it is likely those behind it could still potentially take away huge sums as not all of the stolen crypto can be frozen. Research from Chainalysis says the company is seeing money “laundering patterns we have not seen before” and that thousands of transactions being quickly processed indicates that they are using “automation to obscure the trail of funds.”

Elliptic’s Robinson says that around $2.8 billion, or around 44 percent of the total amount stolen, has been frozen by crypto companies and exchanges so far, with almost all of this being stablecoins. “The remaining $3.3 billion is mostly Bitcoin, Ether, and XRP, which no one can freeze,” Robinson says. “It can only be stopped when it reaches an exchange or other service. Some will be caught over the coming months, but I don’t expect the frozen share to rise much further.”

In my previous blog posts, Azure’s Weakest Link? and Azure’s Weakest Link - Full Cross-Tenant Compromise, I gave an overview of the severely insecure architecture behind API Connections in Azure, a part of Azure Logic Apps, and an instance of a full cross-tenant compromise using these inherent flaws. Now I am back with some more vulnerabilities in this system, each giving the same primitives to the attacker. In total, the vulnerabilities here netted me a cool $200,000.

I also held a talk detailing this at Blue Hat Asia 2026, and when the recordings are out, I will add a link here.

TL;DR

API Connections allow anyone to fully compromise any other connection worldwide, giving full access to the connected backend. This includes cross-tenant compromise of Key Vaults and Azure SQL databases, as well as any other externally connected service, such as Jira or Salesforce. The only thing stopping exploitation is really the layers of input validation bolted onto the various systems, but as you will see, it is really difficult to catch all the edge cases here.

Architecture

If you haven’t read the first parts of this series, Azure’s Weakest Link? - Part 1 and Azure’s Weakest Link - Full Cross-Tenant Compromise, but if you don’t care, I will go through the most important parts of the architecture first.

From Microsoft’s documentation, we see a quite intriguing diagram of how the API Connection architecture is built.

This basically spells out all that is needed to understand how the system operates, kudos to whoever made it!

It works like this

1. A logic app, the symbol on the bottom left, queries a shared Azure API Management instance
2. The API Management instance first checks the swagger (OpenAPI) definition of the connector type and checks that it is a valid action
3. A sort of key exchange happens where the input token, or key, is exchanged for the configured token for the backend service
4. The API Management instance finishes the call with this new token to the backend instance.

From this, we can surmise that if we are able to trick the API Management instance to operate on a different connection than the ones we own, we would be able to effectively use the configured token for a victim’s connection on their backend service.

This service can, in effect, be anything. As you can see here, the list of backend services is effectively unbounded and includes a number of Azure services.

However great the diagram is, there is one crucial omission, which we have already used to great effect in part 2 of this series. By using the ARM REST API DynamicInvoke or /extensions/proxy/ endpoints, we can directly query the APIM service through ARM. I have taken the liberty of updating the diagram to match this.

Considering this, and the fact that, as a resource manager, ARM basically has full access to everything, our exploitation pathway becomes clear. We must trick the calling service into querying a different connection than ours, and thus get full control of the backend service.

Caveat: It is, of course, possible for the people who set up these connections to scope their access tokens or keys so that the API Connection has minimal privileges in the backend. I would guess, however, that this is rarely done. In the case of OAuth connections, it will surely always be the token of the person who initially made the connection. And for the API key case, well, who cares enough to scope such things minimally? Microsoft doesn’t, at least.

Initial Exploitation

The first cross-tenant exploitation I achieved in API Connections, and in fact in Azure as a whole, has already been described in part 2. As a recap, here is an example payload using the DynamicInvoke endpoint of my own connection to read the Key Vault of a different tenant.

POST /subscriptions/8e3ce52f-d45b-4347-8705-65892507465e/resourceGroups/token-storer/providers/Microsoft.Web/connections/custom2/DynamicInvoke?api-version=2018-07-01-preview HTTP/2
Host: management.azure.com
Authorization: Bearer <token>
Content-Type: application/json
Content-Length: 147

{
    "request":{
        "method":"get",
        "path":"path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/fd8d0f4f4069495991ccb4974f96a1ed/secrets/victimsecret/value"
    },
}

HTTP/2 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 1329


{
    "response": {
        "statusCode": "OK",
        "body": {
            "value": "dontreadme",
            "name": "victimsecret",
            "version": "7914d45aa60342809fb8cc12dc68b10e",
            "contentType": null,
            "isEnabled": true,
            "createdTime": "2025-04-04T05:38:26Z",
            "lastUpdatedTime": "2025-04-04T05:38:26Z",
            "validityStartTime": null,
            "validityEndTime": null
        },
        "headers": {
            <Headers>
        }
    }
}

As you can see, it’s a pretty clear path traversal vulnerability. This implies what we already assumed: When the request fires from ARM to the APIM instance, it has rights to all connections, regardless of what it operates on.

Further exploitation

A couple of weeks after I reported this vulnerability, it got marked as fixed, and when I tried it again, the following error message greeted me:

Now, I considered whether or not this was a sufficient fix. It seemed to restrict the paths allowed, rather than the underlying token issue, so I guessed there would be ways around it.

An interesting little fact about the ARM API is that, in some cases, it might not be as much of a black box as you assume. The relevant code can sometimes be found within the resource types themselves. I do not know whether this code actually executes on these machines or is merely included as an artifact, but it is a gold mine of interesting information. So, I created a Standard Logic App, which provides a fully dedicated host, SSHed into it, and extracted the code. Lo and behold, look what I found:

Can you see the fix they implemented?

What was even more interesting here actually was something I found, and was not really even looking for. When searching for the actual DynamicInvoke code, what greeted me was not actually just this one public function, but four:

These functions are completely undocumented, and I could find no reference to them anywhere. However, they were reachable and located along the same path. So, for instance, to hit DynamicList here, simply change dynamicInvoke in your URI to DynamicList.

Knowing that the slap-dash blacklisting fix that they implemented only applied to DynamicInvoke, I assumed that these would all be vulnerable in the same way if they had the same functionality. Without boring you too much with the required arguments and return values here, the exploitation method is really quite the same, although the payload is a bit more involved. For DynamicList, you need to specify each path parameter on its own and do a bit of work to get a result, but the same logic applies. To achieve, for instance, a cross-tenant write on a victim’s SQL server through their connection, a payload like this works:

POST /subscriptions/162fc6db-03cd-4fe8-ab44-dc0a947e74af/resourceGroups/api-connection/providers/Microsoft.Web/connections/custom_validator/DynamicList?api-version=2018-07-01-preview&_=1765372176638 HTTP/2
Host: management.azure.com
Authorization: Bearer <token>
Content-Length: 524
Content-Type: application/json


{
    "dynamicInvocationDefinition": {
        "operationID": "nine",
        "parameters": {
            "one": {
                "value": ".."
            },
            "two": {
                "value": ".."
            },
            "three": {
                "value": "sql"
            },
            "four": {
                "value": "88d28f5ff7b642cfb91df184938d074c"
            },
            "five": {
                "value": "v2"
            },
            "six": {
                "value": "datasets"
            },
            "seven": {
                "value": "victimservice.database.windows.net,VictimDatabase"
            },
            "eigth": {
                "value": "query"
            },
            "nine": {
                "value": "sql"
            },
            "query": {
                "value": {
                    "query": "Insert INTO MySecrets VALUES ('NewEvilSecrets', 3)"
                }
            }
        },
        "ItemsPath": "ResultSets/Table1",
        "ItemValuePath": "secrets",
        "ItemTitlePath": "value"
    }
}

You can quite easily see that the first parameters here execute the path traversal and then perform an arbitrary SQL query on the database.

I reported only the DynamicList case first, in the hope that they would perform a similar fix to DynamicInvoke and I would get to report on the other two as well. Sadly, their fix involved simply blocking all these endpoints. No other mitigations seem to be in place, however, so if these endpoints ever become accessible again, I would assume they would be vulnerable.

Further exploitation

Messing around with paths in these dynamic calls seemed to have reached its conclusion: I couldn’t get past the path limitations on DynamicInvoke, and all the other endpoints were blocked. What I needed was a different way in. As I was trying to sleep one day, it occurred to me that I had overlooked using the Logic Apps themselves. I realized that there was, in fact, a significant difference between the Consumption and Standard Logic Apps connection-creation flows. The most glaring difference is that Consumption Logic Apps, where your workflow is co-located with a bunch of others, create a Version 1 connection, while the dedicated-host Standard Logic Apps create a Version 2 connection. The following diagrams make a more subtle difference between the flows clear:

The V1 Connection Creation Flow.

Do you see the difference? Obviously, when it’s spelled out like that, it’s pretty clear what the point is. Using a Standard Logic App, after we have created the resource and added whatever authentication to the backend server we need, we authorize that specific logic app to access it using its managed identity. However, when we have a Consumption Logic App, we don’t have any such identity to authorize because we don’t control it. This perhaps makes some sense: we can’t authorize it, so we don’t.

I realized that this must imply that every Consumption Logic App has implicit access to every Version 1 API Connection; the only thing stopping us from exploiting this must be some sort of input validation.

The classic view of a Logic App workflow is quite restrictive in its input, but there are both the API endpoints, and the Code view in the GUI that allow us to play around a bit more with the inputs.

The code view allows for more fine-grained control.

This allows us to see the inputs in more detail, edit them, and even add more. The obvious trick of changing the referenced connector to a victim’s connection fails, as the runtime performs extensive validation that you own the connection. We have the codebase, though, so we can try to find all the valid parameters. It did not take much searching for me to discover the host.api.RuntimeUrl parameter.

I can’t quite get my head around why this parameter is included, nor why it’s still accepted to this day, but it works in the way you would expect. After performing a series of validations on the connection referenced in host.connection, you can specify that it should use something completely different instead of the runtimeUrl baked into that connection. As long as the host ends with azure-apihub.net, it will also include the required Authorization header.

Instead of using the connection's runtimeUrl, use a different one.

What happens when this workflow is run then?

The victim's secret is returned.

The keen-eyed reader might notice that the runtimeUrl used in the exploit is not just the connectionId. This is because some extra elements get added to the URI, but it is of no consequence to us; the exploit works fine.

Manna from the heavens

I, of course, reported this to Microsoft again, and they spent some time working up a fix. When it finally came through, the exploit returned an error message:

The host API runtime URL is not valid for the API connection '/subscriptions/8e3ce52f-d45b-4347-8705-65892507465e/resourceGroups/token-storer/providers/Microsoft.Web/connections/keyvault-1'. The runtime URL path must match the expected API endpoint 'https://logic-apis-norwayeast.azure-apihub.net/apim/keyvault/cbfb0f4313144117a7440368902bb871?' for the referenced connection. Either omit the 'host.api' input property, or correct the runtime URL to match the API associated with the connection.

Except for the excessive length of this message, it seems like quite a suitable fix. The runtime URL must exactly match what is expected; otherwise, no dice. Apart from just removing the parameter altogether, it’s quite sane. Unless, of course, it checks that value at the wrong time:

Path traversal in RuntimeUrl.

This works again, with the same result. What’s going on here is that the validation happens before the path is normalized, so the runtime thinks the URI is pointing to my referenced connection, but the APIM instance sees it differently.

And just like that, I got another critical vulnerability.

The fun does not stop there. When Microsoft managed to scrape together a fix for this path traversal, a surprising thing happened. The original RuntimeUrl path was no longer validated, and as a result, you could perform that attack again. I would include some pictures, but they would be the same pictures as above, so you can just imagine them.

Reporting and rewards

Altogether, API Connections have netted me five critical elevation-of-privilege vulnerabilities in Azure, which is perhaps more than expected. All vulnerabilities reported here were fixed within a reasonable time after I submitted the reports, and while there were some disagreements with MSRC along the way, overall, I am quite happy with the results.

Mac OS 7.6 booting on the Wii

Mac OS 9.2.2 booted on the Wii

So today I reached a nice milestone in one of my projects: my work porting classic Mac OS to PowerPC systems with what I affectionately call ArtX chipsets (Nintendo GameCube, Wii, eventually Wii U; the GameCube’s Flipper integrated chipset was very much designed by ArtX as it was effectively finished when ATI acquired the company, and the Wii’s Vegas (and its later revision Bollywood) and Wii U’s Latte are effectively straight successors) reached the desktop for the first time, most likely the first time since the CHRP clone era that someone outside of Apple brought up classic Mac OS on a new system to the desktop. Despite still being nowhere near ready for a public release, I want to talk about the challenges I faced with this project so far.

But first, why port classic Mac OS to this hardware in the first place? I’d already ported NT of course, and during that work I acquired some PowerPC Mac laptops which I also ended up porting NT to, work on one port improved the others and so on. This got me acquainted with the classic Mac OS, and I fell in love with the jank as it were (hacks upon hacks upon hacks going back to the 1980s is something I’d definitely describe as “jank”). Not to mention the m68k part of the TBXI is called “SuperMario”, and was for the entire PowerPC era. I wonder if a developer was a fan in the early 1990s?

Also, for the record: I started this project on 2025-06-22 (when I forked upstream openbios), no kind of coding agent or LLM was used, all coding, reversing and debugging work done by myself. I do these projects for fun and to learn, if I used “AI” it wouldn’t be fun and I wouldn’t learn anything.

Let’s start with the initial boot. “New World” classic Mac OS starts out with a bootloader called the “Trampoline”, which runs on an Open Firmware environment. So I needed to port OpenBIOS. Luckily, around this time Goldfish64 had started his own port of Mac OS X to the Wii, and he’d made an OpenBIOS port that I could use some drivers from, although for various reasons I didn’t just want to use his port directly (which was only targeting Wii/Wii U, I wanted to target GameCube too). I also decided to reuse some existing code to make some driver development easier (specifically the display driver), and thus changed my existing NT ARC firmware loader to load a big endian ELF instead.

I needed some small number of disk drivers for initial bringup, so decided to port my two drivers for devices on the EXI bus (this is just Nintendo and Macronix’s name for SPI), the “SD Gecko” (which is just a straight through adapter for a GameCube memory card slot allowing for SD over SPI), and the “EXI-IDE” (my driver is actually not correct to real hardware, but to my inaccurate emulation in my Dolphin tree allowing for testing under emulator with the low level debugging support that implies).

I wasn’t sure what kind of on-disk format I wanted to use (these drivers on my earlier NT port ran entirely using disk images on a FAT filesystem, due to the requirement for compatibiltiy with existing homebrew loaders that load executables from FAT filesystems, but this would naturally be limited to 4GB images for FAT32, and later versions of classic Mac OS needed more), so for initial testing I just took the “Mac OS ROM” TBXI file and placed it directly on a FAT filesystem as \ppc\bootinfo.txt for OpenBIOS to load it on boot.

So with that I could get the Trampoline running. I decided that I should try and apply as many patches to the image as possible as close to run-time as possible, so mostly untouched existing CD images could be used eventually.

The first issue I had was that the Trampoline makes some assumptions of the physical address space layout that are not true for this system. The physical address of a buffer gets calculated as an invalid address, so I patched that to an address guaranteed to be valid, and also the corresponding code setting up the memory chunk list/page table entries for the kernel.

Additionally, the Trampoline expects that physical addresses from 0x8000_0000 onwards corresponds to memory mapped I/O (on existing systems this code ran on, this would correspond to PCI-bus address space). This is not the case here, and in fact on Wii U, this address would correspond to part of RAM. There was also another assumption that broke on these systems, with holes between areas of RAM in the physical address space, some of which were partially filled by memory-mapped I/O.

The way I fixed this was to patch the initialisation of this MMIO mapping in the kernel memory chunk list, to a map of physical address 0x0100_0000 (partway through one area of RAM) to virtual address 0xE000_0000, with length 0x1000_0000. This specifically maps the whole of the MMIO, plus the end of one RAM area and (for post-GameCube systems) the start of another. (I may change this in future, as on the Wii U, physical address range 0xD000_0000-0xEFFF_FFFF is mapped to a part of the Radeon R7xx GPU called “HDP”, which can be used to map a view of physical memory with specific swizzling and/or endianness swapping, such that a texture in some GPU-specific format can appear to be a linear framebuffer. It depends on whether I need to use this block ) The function used for initialising a mapping in the Trampoline changed at some point and I ended up detecting the older version and hooking the function so I could work around it (earlier versions used a 16-bit page count, later versions used 32-bit). Additionally, older versions of the Trampoline sets up unconditional 1:1 mappings for physical memory above 0x8000_0000, which needs to be removed as they conflict with the mappings set up earlier.

There follows various assorted patches that assume specific hardware. These include: patching out setting some bitflags which correspond to the presence of a microcontroller found on all PowerPC Macintosh hardware, attempting to recalculate the bus frequency using a specific hardware timer, and various register writes and fixups related to a specific interrupt controller device (it’s little endian because it’s on the PCI bus, and naturally, not present here).

Finally, the final call to jump into the loaded kernel initialisation code is hooked so additional patches can be made later after everything is loaded into memory.

Additionally, the device tree must be hacked up a bit to be in a shape the Trampoline will accept. The interrupt controller is faked to be one of the recognised ones (the little endian one from above, because at a register level it’s closest to the Flipper interrupt controller present on all the ArtX chipsets, albeit on Wii U it was changed somewhat to add support for the additional PowerPC cores). The address of the frame buffer in the device tree is changed to the uncached virtual address (in the 0xExxx_xxxx mapping), and finally a fake Mac99-compatible power management device is added to the device tree, so the Trampoline prepares a power management driver for it, that can be replaced later.

As mentioned above, the kernel initialisation is hooked so extra patches can be made. On the kernel side, there is only one patch to be made: the kernel contains several interrupt controller drivers, the one chosen is patched to match the Flipper interrupt controller, with one of the unused ones sacrificed to gain more space for this. The main difference here is that the expected interrupt controller (whose driver is patched) has a legacy mode where it raises a PowerPC interrupt whenever the interrupts change (not just when interrupts are raised) so this needs to be worked around by masking the raised interrupts in the kernel and then unmasking them later on in drivers’ interrupt handlers.

Additional patches are made in the “SuperMario” m68k code, and in PowerPC native executables. The m68k code has various codepaths that read and write directly to native interrupt controller registers, these need to be patched. The function pointers for enabling and disabling audio interrupts need to be stubbed out (there’s already an entry in that table that points to a stub, which is helpful). A function called early in the boot process to initialise the ADB and power management microcontroller does not check if the hardware actually exists, and if it doesn’t it clobbers parts of low memory. A function for initialising hardware interrupts has a bug due to a copy-paste blunder, the intent was to skip past the code for initialising the interrupt for serial port 2 if the hardware isn’t present, but the developers forgot to change the jump label when copy-pasting the code from serial port 1, which causes an infinite loop if serial port 2 doesn’t exist. As for native code, there’s more code that reads and writes to interrupt controller registers which needs to be correctly patched. The USBShimKeyboard driver initialisation code fails to handle the state where no USB controller exists and in that case will call a NULL pointer inside the m68k emulator. The power management driver mentioned above is also replaced entirely here (currently I use the stub driver from BlueBox but plan to write my own later to add proper support for shutting down and restarting).

All of this is enough to get the TBXI to boot to blinking floppy – after that I wrote a display driver (thanks to Elliott Nunn for his virtio driver, it was very helpful) so I could see it correctly, followed by a driver for the gamecube controller ports (porting from my NT driver for the same) so I could move the mouse cursor around without USB.

At this point I started to implement a block IO driver (for EXI devices), but ended up getting stuck thinking about how to deal with how the disk format should be laid out and how the driver should work. Then Mac OS for CHRP got dumped, and I got sidetracked with patching up the later TBXI images to boot it, thinking running 7.x would be useful on a GameCube which doesn’t even have enough RAM to support 8.0 at minimum requirements, and after that I got sidetracked with other projects. Almost a year later I came back to it, implemented my preferred disk format in OpenBIOS and decided to hack up a driver faking SCSI (some other drivers did this, most notably classic Mac OS drivers for various SATA controllers). There were a few issues I found when writing the fake-SCSI driver too: I had to add another patch to the m68k code to force loading the disk driver (and I mean this, a driver loaded from the disk itself, basically implementing the actual disk devices on top of some partitioned block device) as a newer type rather than the older type (the older type was effectively obsolete when the first PowerPC systems released anyway, and I don’t even support the old-style calls from my fake SCSI driver, which is probably why it crashed trying to load it as an older type driver), and also found an interesting quirk where the optical disc driver (loaded from the block device itself) emulates 512-byte sectors on 2048- or 2352-byte sector block devices by making a read call setting up 3 scatter-gather buffers, except it never checked if the underlying SCSI driver actually supports scatter-gather, so I had to implement support for that on reads.

I still saw a blinking floppy though, some debugging showed me what was being rejected, a PowerPC function StartLib!GetStartupDevice was being called to get the boot device, and it made some assumptions of both the device tree and that there was some kind of built in SCSI device that needed separate handling. The first one was simple enough (fix the device tree in my driver’s initialisation code), the second one was more interesting in that I had to grovel into internal structures to fix an index in 3 different places (including the device tree) to ensure it was non-zero and so the correct code path would be executed.

With this done I saw a happy Mac icon for the first time, but then got rejected by the HFS boot sector (something errored and it returned). This turned out to be a bug in my own driver: I was debugging in dolphin with a hacked up EXI-IDE device; reading and writing data in PIO mode for IDE devices deals in 16-bit words, and I didn’t expect my code to get passed a completely unaligned odd buffer address (low 4 bits equal to 1), so I had to modify my low level driver to not even attempt EXI DMA for such an address. The bug manifested as a byte effectively failing to be written out, with remaining data getting offset by one byte; at least this happened when reading the header of a resource fork, and what failed was the validity checks for this data, making it much easier to debug (I ended up dumping RAM and comparing with the expected data from the disk image I was using).

After this, Mac OS 9.2.2 started to boot in my hacked up Dolphin tree, very slowly. It took an hour before it finally crashed, and then I tried 7.6, which also crashed, but earlier. I realised that it was probably crashing trying to load MacsBug, removed it, and after about 20 minutes I was staring at the desktop.

Mac OS 7.6 booted in my hacked up Dolphin tree

The following morning I tested on real hardware (using SD over SPI). This basically booted 7.6 within 40 seconds, and this was supposed to be the slowest access mode for an SD card! My previous experience was writing an NT driver for SD over SPI though, and perhaps that is more of an outlier. See this video installing NT on a GameCube using such a block device, and note that the NT text setup file copy is sped up 64 times – it’s VERY slow. The difference here is that I get to hog the whole CPU when performing a transfer – in fact there’s no other option, if I return a value specifying the transfer is asynchronous, the caller proceeds to busy-wait for interrupts in a loop waiting for the transfer to complete (although the busy-wait does check for all controllers present on the system).

Later on I added some hacked up crash handler so I could try to debug what was going on with MacsBug… it turned out to be an emulation error, no such crash occured when loading MacsBug on real hardware. I then found out the reason Mac OS 9.2.2 was crashing on boot was because of Open Transport, removing it from the Extensions folder caused it to boot perfectly fine. My guess is that Open Transport can’t handle no serial or network device being present at all.

As I mentioned, my port is still nowhere near release. Next up will be bringing up the Wii’s SD controller, then the USB controller (I’ve already done some reversing work related to that, I know there’s a vibecoded EHCI driver now, that’ll probably only aid in reversing work really), then getting the port brought up on the Wii U. At some point I want to play around with patches for blowing through at least some of the RAM barriers too.

Patrick Stewart as Captain Jean-Luc Picard. GLOBE PHOTO/ELLIOTT MARKS

Patrick Stewart died yesterday, and for people of a certain age, a little bit of the future left with him.

For a certain, less-than-new generation of fans of Stewart’s 1990s television work on Star Trek: The Next Generation, there’s a sorrow that the man behind the larger-than-life Captain Jean-Luc Picard would be lost to a very real, very heartbreaking condition, Alzheimer’s and Lewy Body Dementia, according to his family.

Stewart, of course, was far more than Picard. He anchored the X-Men film franchise and was for decades a dynamo on stage. But there are reasons Captain Picard, commander of the Starship Enterprise, is the character he’s best known for. Over The Next Generation’s seven seasons, four movies, and a revival show —Star Trek: Picard — that ended just three years ago, he portrayed a model of what mature, responsible adulthood could look like for a generation of boys who were bookish, imaginitive, and maybe a little nerdy.

Two of the Globe’s dyed-in-the-wool Star Trek fans share what Captain Picard, and Patrick Stewart, meant to them.

John Hilliard: For a younger, and likely wiser generation, stanning a bald middle-aged English actor who played a French guy on a spaceship may be a questionable life choice. But here is the thing: What made Stewart resonate as Picard was how he rooted the character, as in the best of fairy tales, in emotional truth.

Jason Laughlin: I agree. Picard seemed as real as the complex characters that would start to populate prestige TV a decade later. But unlike anti-heroes such as Tony Soprano and Walter White, Stewart gave us a nuanced character we actually admired. He loved his job. He had passions like archaeology, Shakespeare, and music. He held to his ideals even when it meant terrible personal sacrifice.

In the mess of American politics over the past 20 years, there have been so many times I’ve longed for a Picard-style speech that makes right and wrong crystal clear.

“You know, there are some words I’ve known since I was a schoolboy,” Picard said when a Joe McCarthy-esque admiral began witch hunting on the Enterprise. “With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.”

His character’s moral clarity, and Stewart’s conviction in delivering it, put an end to the admiral’s reign of terror. If only real world oppression could be dispelled so easily.

For decades, Patrick Stewart was a star of stage and screen, but no role defined him quite like the noble space captain Jean-Luc Picard of Star Trek: The Next Generation.STEVE FORREST/NYT

JH: Full disclosure: Star Trek is a show, which Youtube will prove, that leaned hard on latex foreheads and sometimes-flimsy production to tell stories of intergalactic scallywags known as Klingons and Borg, Romulans and Cardassians. Like free office coffee, it’s an acquired taste.

JL: One of my friends has a theory that if you didn’t get into Star Trek before you’re 18 years old, you’re never really going to get it.

To me, what’s so accessible, and radical, about Stewart, though, was his ability to convincingly portray vulnerability while still maintaining Picard as a credible leader.

One episode saw Picard return to his home village in France to heal from a traumatic assault.

At the conclusion, Stewart surrenders the control that was his character’s hallmark and falls into the mud, sobbing, over his failure to fight off his assailants. It’s a raw, real, depiction of a broken man. Stewart shifts from total collapse into slow recovery by reconciling with his brother. Grief is replaced by warmth, and Stewart sells it perfectly.

JH: Totally. He knew how to make that show work for him.

That’s despite an episode where he faces off against a giant, talking tar pit. Or the one where he sells eating a sandwich in the sci-fi version of the family station wagon. Or when he chugs Ecto Cooler (remember Ecto Cooler?) with a depressed Scotty, from the original Star Trek, and shares stories about first jobs and first girlfriends. He even shows up in tights, as discount Errol Flynn Robin Hood.

As a kid raised on television before there was an Internet, Stewart plugged into a world where figures like Mr. Rogers and Bob Ross presented a model for manhood that was gentle, patient, and a teacher. Stewart played Picard in a similar vein, basically everyone’s Space Dad.

Even as recently as last month, Captain Jean-Luc Picard appeared on Star Trek Day in the London Underground.Tim P. Whitby/Getty Images for Paramount+

JL: This is embarrassing, but the first TV episode that moved me to tears was from The Next Generation.

“The Inner Light” has Picard experience an entire lifetime as a different person on an alien planet. Again, the actor found his character’s humanity through slow revelation that perhaps a life with a wife and children is just as big an adventure as exploring space.

“Seize the time,” Picard says to his daughter in this other life. “Live now! Make now always the most precious time. Now will never come again.”

At the end of the episode, it’s revealed the decades he spent in that other life were an illusion he experienced in less than an hour. The only tangible thing he has from that world is a flute he learned to play in that other life. In the final moments, Picard plays it again, and without saying a word Stewart plays absolute heartbreak.

Seeing a strong, confident leader who was able to express regrets, sadness, and heartache left a lasting impression.

Well into his 80s, Patrick Stewart was playing the character he became best known for.Richard Shotwell/AP Photo/Richard Shotwell

JH: Imagine you’re a kid watching TV, and you feel kind of alone, unsure of yourself. And then there’s Stewart, in full reassuring teaching mode. It’s the episode where Wil Wheaton’s character is struggling with tremendous guilt as he tries to hide his complicity in the death of a friend. Stewart, as Picard, is on to him.

Wheaton’s character, Wesley Crusher, is as close to a son as Picard will likely ever have, and Stewart leans into Picard’s grief, grief from knowing that doing the right thing will likely destroy the younger man’s future.

“A lie of omission is still a lie,” Picard tells Wheaton. Stewart’s voice cracks as Picard remembers meeting Wheaton’s character for the first time. He sat in Picard’s chair. He knew every button on the ship, every function. He was annoyed, Picard growls.

Stewart pulls back. Picard never had any doubt that Crusher would grow up into an outstanding officer. Until that moment.

“The first duty of every Starfleet officer is to the truth, whether it’s scientific truth, or historical truth, or personal truth,” says Picard, who then delivers the gut punch. “If you can’t find it within yourself to stand up and tell the truth about what happened, you don’t deserve to wear that uniform.”

It doesn’t matter if you know what a Starfleet is, or if someone can be an officer of one. Stewart always finds a way to connect his audience to the emotional truth.

When you’re a kid, you’re looking for lessons, even if you don’t want to admit it. Stewart, as a master of navigating the human heart, understood the moment and his character. Ultimately, Picard was a teacher, and a guide, not just for the characters with whom he shared a scene, but for the audience as well.

JL: Stewart was 47 when he began playing Picard. I’m just a year older than him now, and the very best of his episodes have taken on new resonance. Family tensions are real and devastating. Professional choices have lasting consequences. The melancholy of middle age lingers on the periphery of every happy moment.

Patrick Stewart’s Picard still serves as a role model. He showed how to face those moments with dignity, optimism, and a belief in the enduring capacity to be our best selves.

The move came after 404 Media published an investigation into how Proton CEO Andy Yen was aggressively pushing AI across Proton despite security concerns and the culture of fear he has created.

Photo by Sam Barnes/Web Summit via Sportsfile via Wikimedia Commons / Collage via 404 Media.

On Friday, Andy Yen, the CEO of Proton, cancelled a series of nearly company-wide ‘re-interviews’ that would have forced employees to explain how they are using AI, with the clear intention that they may be fired if not using it enough in the eyes of Proton leadership, according to six current Proton employees and audio of an around two hour all-hands meeting obtained by 404 Media.

The move came after 404 Media published an investigation on Thursday, which showed how Yen was aggressively pushing AI across Proton, in some cases despite security concerns from employees. In one exchange, an employee in the company’s security Slack channel urged Proton to at least take a few days to pentest newly written code before pushing it live. “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure,” Yen wrote in the channel at the end of August. “Stop thinking always of how to be slower, and focus more on how to be faster.” Yen added, “stop lovingly handcrafting all our code and use AI more.”

The re-interview cancellations likely don’t address the concerns of many Proton users, who are more focused on Proton’s deprioritization of security; many Proton users have blasted the company’s leadership on social media over the last 24 hours and explicitly called for Yen to resign.

The investigation was based on conversations with eight current and one former Proton employees, Slack chats, meeting audio, and an AI manifesto written by the company’s CTO Bart Butler. It painted a picture of Proton that is very different to the public’s perception of a company carefully protecting privacy. Instead, Proton is barreling ahead with AI in large part to achieve more annual revenue. The investigation also found a culture of fear across Proton, where employees have genuine concerns about security or being asked to develop security-focused products with AI, but feel unable to voice them because Yen mocks or insults employees in front of everyone else.

“I don’t think he will change anything, and I think the only reason we had this meeting is because he has a rebellion on his hands,” one employee told 404 Media after the all-hands meeting on Friday.

Near the start of the meeting, Yen said, “I want to acknowledge myself, personally, that there was a communication failure on my part and there are many things that probably could and should have been communicated differently, and this is something that I’ll have to reflect on and improve over time. So I will do that.”

“So what does that mean going forward? Going forward, I'm still going to push,” he added.

Yen said leadership gathered in the last couple of days to talk about the re-interviews, and spoke to the Proton board too. “They’re closely monitoring the situation,” Yen said. (Proton is owned by the Proton Foundation, whose board of trustees includes Yen, Sir Tim Berners Lee, Prof. Carissa Veliz, Dingchao Lu, and Antonio Gambardella.) 

After those discussions with leadership and the board, “We’ve decided to actually cancel the re-interviews,” Yen said. “Why? Well, I think actually in a, let’s say, unintentional way, they have actually already served their purpose.” As in, employees are now talking and learning about AI.

💡

Do you know anything else about Proton? I would love to hear from you. Using a non-work device, you can message me securely on Signal at joseph.404 or send me an email at joseph@404media.co.

Yen also mentioned “org changes,” and said that part of this is “redistributing talent across teams.” He said that the reorganization will happen next month, “but there will be no loss of jobs from AI.” 

Later in the call, Butler said Yen “needs to, and he has committed to, doing better” regarding how he communicates with his employees. “Using AI effectively and pragmatically does not mean that we’ve given up on security, or good architecture, or sound software engineering principles,” he added.

“We fucked up, we know we fucked up,” Butler later said in response to an employee’s comments in the meeting.

“Your old job is gone,” Butler’s AI manifesto, posted to Slack, told engineers, 404 Media reported on Thursday. He wrote that not embracing AI posed an “existential threat to the success of the mission itself.”

Reactions to the re-interview cancellations were split across the Proton employees 404 Media spoke to. One said, “Some are happy as it’s progress. Others believe that this won’t change anything because there isn’t any consequence for Andy [Yen].” The employee added they “would have preferred real accountability from the leadership team.” They said they felt not much could have happened due to Yen having the majority of Proton’s shares.

Another employee said, after Proton canceled the re-interviews, “They said in the next breath they want to continue pushing AI and that the things that were to be measured in the re-interviews would become a component of the performance reviews.”

“They have said clearly the direction had not changed. As a Proton user that doesn’t reassure me,” the employee said. “As an employee, the re-interviews weren’t cancelled until this became public despite concerns raised by many of us. I think it goes beyond communication issues and growing pains.”

“Right now, everything seems consistent with it being damage control,” they said. 

Another employee said they were “mostly happy with how this was addressed including by Andy [Yen].”

Proton did not respond to a request for comment.

After 404 Media published the investigation on Thursday, Yen took to Reddit. Users downvoted his response more than 1,200 times. Many Proton users on social media said they were cancelling their paid Proton plans.

An NES CPU compiled into the weights of a stock Qwen3.5 model.

The NES's 6502 CPU (the core of its 2A03 chip), its 2 KB of work RAM, and a cartridge's program ROM run inside a standard Qwen3_5ForCausalLM checkpoint. Nobody trained these weights; a compiler computed every one. When you play a game, the model predicts the CPU's execution log one token at a time. A small host program plays the rest of the console around it: it draws the picture, reads the controller, and fires the vblank interrupt.

nesformer builds on Qwenputer by Divyansh Agrawal, which compiled a CHIP-8 and then a RISC-V CPU into Qwen3.5-4B. It reuses Qwenputer's compiler and its central trick: the model's Gated DeltaNet state is the machine's memory.

Super Mario Bros. (World 1-1) Full Game by Doug Fraker (title screen and first level)

Every CPU token in these runs came from the model. For the bundled test games, every frame also matches a conventional 6502 emulator's output exactly (see How it was checked).

Quick start

1. Folder layout

Unzip nesformer.zip and nesformer-weights.zip into the same folder. The weights go next to the nesformer/ package, not inside it:

nesformer/              <- run commands from here
├── nesformer/          <- the Python package
├── chipformer/         <- Qwenputer's compiler
├── roms/               <- test ROMs (put your own here too)
├── examples/           <- sample GIFs and frame sheets
├── tests/
├── LICENSE
├── LICENSE.chipformer
├── README.md
├── pyproject.toml
└── weights/            <- from nesformer-weights.zip
    ├── config.json
    ├── generation_config.json
    ├── model.safetensors
    ├── nesformer.json
    └── SHA256SUMS

The CLI looks for weights/ beside the nesformer/ package. To keep the weights elsewhere, pass --weights /path/to/weights to run, check or trace, or give the path to info.

To confirm the weights unzipped correctly, run shasum -a 256 -c weights/SHA256SUMS from the top folder.

2. Install

You need Python 3.11 or newer.

python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install numpy scipy numba pillow

3. Play a game

python -m nesformer run roms/thwaite.nes --frames 600 --show \
  --buttons "start@90-95+200-205,a@230-233+250-253+270-273+290-293+310-313+330-333+350-353+370-373+390-393+410-413+430-433+450-453+470-473+490-493+510-513+530-533+550-553+570-573+590-593"

--show draws each frame in your terminal as the model generates it. When the run ends, the CLI saves an animated GIF named after the ROM (here thwaite.gif) in the current folder.

Expect it to be slow. The first run spends about 20 seconds compiling the engine with numba. After that, a frame takes 1–6 seconds, so 600 frames (10 seconds of NES time) take around 25 minutes.

Playing your own ROMs

Point run at any .nes file that uses the NROM board (iNES mapper 0), such as Super Mario Bros., Donkey Kong or Excitebike. You supply the ROM; nesformer only ships the three freely licensed test ROMs in roms/.

python -m nesformer run roms/smb.nes --frames 600 --show \
  --buttons "start@60-65,right@200-600,a@250-265+300-315+360-375+420-435+480-495+540-555"

That script starts the game, then walks Mario right and jumps about once a second. The CLI loads the ROM into the model's state at startup, so the same weights run any NROM game without a rebuild. Games on other boards stop with a message: see Limitations.

Controller scripts

--buttons takes a comma-separated list of entries. Each entry names one or more buttons joined by +, then @, then one or more frame ranges joined by +:

start@60-65                 press Start during frames 60 to 65
right@200-600               hold Right from frame 200 to frame 600
a@250-265+300-315           press A twice
right+b@200-600             hold Right and B together (run, in Super Mario Bros.)

The buttons are a, b, select, start, up, down, left and right. Frames count from power-on at 60 per second, so frame 600 is 10 seconds in. Games ignore input on screens where you can't move, so holding a button a little early does no harm. In Super Mario Bros., a longer A press makes a higher jump.

Commands

Options for run:

run, check and trace all accept --weights, --engine, --buttons and --no-skip. check --tokens N sets how far to compare (default 50,000). trace --tokens N sets how many tokens to print (default 40). build --out DIR writes the checkpoint somewhere other than weights/.

How it works

What's in the weights, and what isn't

This split follows Qwenputer's CHIP-8 build, whose host injects timer ticks and draws the display from the trace. The host never sees the CPU's registers or RAM except through the trace.

The memory trick works like this. Each DeltaNet head keeps a 128 × 128 state matrix that the delta rule updates at every token. With the gate held open and a one-hot key, an update overwrites exactly one row of that matrix, and a one-hot query reads it back. So every row is a memory cell, and the cartridge, RAM and registers all live in rows.

The checkpoint

weights/ is an ordinary Hugging Face folder. It loads with Qwen3_5ForCausalLM.from_pretrained and needs no custom code.

nesformer.json records which layer and head holds each part of the machine. A run writes the cartridge, registers and RAM into those DeltaNet states, then decodes greedily.

Layer plan

The trace

Each instruction becomes a record, and the record's last token commits it. As in Qwenputer's RISC-V core, the PC is implied rather than written: each final token carries its instruction's length, three DeltaNet counters tally the instructions of each length since the last jump, and the PC is the jump target plus that offset. Excerpts from Full Game:

SEI            P(000100 px0 L1)
LDX #$40       X($40 c0 v0 px0 L2)
STX $4017      IOW($4017=$40 L3)
TXS            S($FF L1)
BIT $2002      IOR($2002) IN($00) P(000110 px0 L3)       <- the host injects IN
BPL $8017      J($8017)
JSR $8279      PSH($FE) PSH($FD) J($8279)                 <- the return address is pushed in-circuit
RTS            PUL($FC) LO($7B) PUL($FD) J($827C)
STA ($72),Y    LO($08) HI($03) ST($00 a7=0 L2)            <- pointer bytes latched, then the store
STA $4014      IOW($4014=$02 L0) DM(0:$FF) … DM(255:$00) NT(L3)   <- OAM DMA

Most instructions take a single token; real game code averages 1.1–1.3 tokens per instruction. nesformer/spec.py documents every token family.

How it was checked

• The reference CPU (nesformer/cpu.py) matches nestest's golden log for 3,348 instructions, and the py65 emulator on 5.7 million instructions of game code.
• The exact circuit, run in Qwenputer's evaluator with its bf16 exactness checks, predicts every reference token: all of nestest plus 283,610 positions of two games' boot sequences.
• The checkpoint in stock transformers (bf16, CPU) predicts 2,651 positions of nestest and Full Game with no mismatches.
• The weights, free-running, generate traces identical to the reference CPU's:

• The idle-loop skip changes nothing visible: frames and I/O writes, cycle timestamps included, match a run without it.

Speed

The default engine computes Qwen3.5's forward pass from model.safetensors, compiled with numba and skipping the all-zero blocks. It ran at about 1,650 tokens/s on one CPU core of the machine it was built on. The plain numpy engine does about 210, and stock transformers about 10. A real NES would need about 700,000 tokens per second.

Games spend most of each frame in a loop that waits for vblank. When the host sees a loop body repeat exactly, with no RAM or I/O writes, it advances the clock to just before the next PPU event, and the remaining iterations still run. That cuts the token count by 2.6× to 4.2×. Overall, nesformer runs 150–290× slower than the real console.

Limitations

• NROM cartridges only (iNES mapper 0). The CPU can address only 32 KB of program ROM at a time. Bigger games carry a bank-switching chip (a mapper, such as MMC1 or MMC3) that swaps which part of the ROM the CPU sees. nesformer's ROM reads happen inside the model, from a fixed 32 KB table, so it can't follow a bank switch yet. Supporting a mapper means storing the whole ROM in the state, keeping the bank registers there too, and adding one stage that turns each CPU address into a ROM address.
• Official opcodes only. An unofficial opcode emits HALT.
• Code must run from the cartridge ROM. A jump into RAM emits HALT.
• No IRQs (APU frame IRQ, DMC). BRK and NMI work.
• Read-modify-write instructions on I/O registers don't produce an I/O write, and $4020–$7FFF reads as 0 (no PRG-RAM).
• The PPU and APU aren't in the weights. The PPU renders one scanline at a time, so mid-scanline effects aren't reproduced. Sprite-0 hit and sprite overflow are approximate, and there's no sound.

Tests

pip install pytest py65
python -m pytest -q tests

The tests take a few minutes. They check the reference CPU against nestest's log, the circuit against the reference, the weights free-running against the reference, and the idle-loop skip.

Running the checkpoint in stock transformers

pip install "torch>=2.6" "transformers>=5.22"
python -m nesformer run roms/thwaite.nes --frames 3 --engine hf

nesformer/hfcheck.py shows the whole procedure: load the checkpoint, decode one padding token, write the machine's state into the cache's DeltaNet states, then feed tokens one at a time.

Files

Credits

• Qwenputer and its chipformer compiler: MIT, © 2026 Divyansh Agrawal (LICENSE.chipformer). That license also covers the code adapted from Qwenputer in nesformer/core.py and nesformer/weights.py. Its last paragraph refers to Qwenputer's CHIP-8 ROMs, which this repository does not include.
• Test ROMs: nestest by Kevin Horton; Full Game by Doug Fraker (MIT); Thwaite by Damian Yerrick (GPL-3.0, source at pinobatch/thwaite-nes).

License

nesformer is released under the MIT License (see LICENSE). The ROMs in roms/ keep their own licenses, listed in roms/SOURCES.md.

We receive takedown notices regularly. They come from individuals, lawyers, companies, and governments. This post is part of a series where we document how we handle them, both the routine cases and those that reveal something worth discussing publicly.

This request, to take down icepi.cx (now online again at http://icepicx.is/ ) arrived from a company we have no relationship with, acting for a government agency in a country where we do not operate.

We declined the request.

What happened

The notice describes a doxxing campaign. That is not what the site is.

Doxxing publishes private details about private people so that others can find them at home. Icepick publishes work identities of government employees. Who they work for. What their role is. How they can be reached in that role. The information describes people in the exercise of public authority, not in their private lives. Federal officers carrying out an enforcement programme are not private individuals while they are carrying it out. The public has a legitimate interest in knowing who is doing that work, under whose authority, and in which office. Journalists cannot report on an agency whose personnel are structurally unknowable.

We are not pretending the origin of the data is comfortable. It came from a breach, and nobody in the dataset chose to be in it. The question we had to answer was narrower: does publishing it serve a purpose that a hosting provider should protect? We concluded that it does. The site functions as a reference tool for accountability reporting by journalists and citizens, and that is a use we exist to keep online. This is why we declined the take-down request.

Why this matters

An automated takedown notice does not remove the work of checking whether an accusation is true. It moves that work to the recipient. We made that point about a false accusation from a German police authority, and it holds here with a different agency, a different country, and a different kind of claim.

ZeroFox finds candidate material through AI-driven detection. Whether a given site is accountability journalism or a harassment campaign is exactly the judgment that detection cannot make. Someone has to read the site, look at the dataset, and weigh public interest against personal risk and this morning that someone was us.

This case adds something to that. The party accusing us and the party contacting us are no longer the same. We cannot see who inside ICE decided this site should go, whether anyone did, or what they were shown before deciding. We are being asked to validate a claim whose author we cannot identify.

As a business model, none of this is new. Copyright has worked this way for decades. A private company sells monitoring to rights holders, scrapes for matches, sends demand letters automatically, and takes a share of whatever recipients pay to make the letters stop. Volume is the product. Checking is a cost against it. Plenty has been written about what that does to legitimate speech, and most of it transfers to what arrived in our inbox this morning.

What has changed is the client. In this case its a governmental institution, not a private company. DHS signed a $15 million contract with ZeroFox in July 2026 covering ICE and Homeland Security Investigations, and the company can file on the department’s behalf until 2028. The Intercept reported on a leaked memo describing the programme internally as a “Doxing Mitigation Initiative,” and quoted an ICE official who worried it could be turned on whistleblowers and critics inside the agency rather than on threats from outside it. ZeroFox also has form. In 2015 it classified peaceful Black Lives Matter organisers in Baltimore as “threat actors” warranting continuous monitoring, partly on the strength of their follower counts. The FBI hired the company anyway in 2021.

Validation by the recipient is no longer a side effect of a badly built process. It is part of what the service sells. Finding politically and journalistically relevant information is the product, removing it is the deliverable, and the number of notices filed is the measure of success.

What happened to the site?

By mid-morning, icepi.cx no longer resolved. Its registrar, CentralNic, had placed the domain on serverHold.

Our refusal kept nothing online. The request that decided the outcome to take the site down was not the one sent to us. A registrar reached the opposite conclusion the same morning, published nothing, and a global audience lost access to the site. In the meantime the site is online again under a domain from a different registrar (http://icepicx.is/)

What should be done about this

As we describe in our previous article, legislation like the DSA loads obligations onto hosting providers and asks nothing of the people who file notices.
This case demonstrates what can happen once filing becomes a commercial service available to governmental organisations.

Anyone filing a takedown notice on another party’s behalf should have to state who they act for, under what legal basis, and who is accountable if the claim is wrong. Where a notice was produced by automated detection, that should be declared on its face. A provider cannot weigh a claim properly without knowing whether a human ever looked at it.

Removals at the registry and registrar level need the the same scrutiny.
Enforcement against genuinely harmful content is a legitimate goal, and protecting individuals from harassment is a real one. But a system where an agency can buy removals through a contractor, where the contractor is possibly paid by volume, and where the quickest route runs through infrastructure nobody is watching, like the registrar in this case is not a system for stopping harassment. It is a system for making inconvenient information disappear.

Meet Paddy, the 27-year-old Cisco’s president calls an “energizer bunny.” The Gen Z ex-founder has been given unlimited AI tokens and told to “go nuts.”Getty Images

Gen Z can’t catch a break. Entry-level jobs are vanishing; some 40% of bosses say they plan to hire fewer grads because AI can do the job cheaper, and young workers are routinely slammed for showing up late and refusing to put in overtime for free. Cisco’s president and chief product officer Jeetu Patel isn’t buying it—he’s just handed one of the company’s biggest jobs to a 27-year-old he found hidden in the org chart “five levels” below him.

“I’ve given him unlimited tokens because he’s going to refactor code,” Patel told Fortune at a small roundtable dinner. “So I’m like, you can go, you can go nuts.”

The “him” is Padmanabhan Krishnamurthy, or “Paddy,” as Patel affectionately calls him. He joined Cisco in 2025 after the $429 billion tech giant acquired EzDubs, the real-time translation startup Krishnamurthy cofounded in 2023. And despite coming in as a former founder with CEO experience, he was, in Patel’s words, “buried away in the organization doing something unstrategic.”

That changed when Patel dropped into Cisco’s San Francisco office, and the pair got talking. Krishnamurthy reckoned he could rewrite Cisco’s legacy code with a two-person team. Patel says even the most AI-forward people on his own team weren’t thinking that way.

So he has given himself four weeks to prove it, with the final goal of refactoring 98% of Cisco’s legacy code within 24 months.

Now, he’s on the hunt for more Paddys: young hires who will “challenge the system and the status quo,” or, as he puts it, be “an energizer bunny that just goes out and kind of revs everyone up.”

Cisco’s president says Gen Z should be teaching his veterans, not doing data entry—and he’s fine with the tension that causes

At most companies, only someone with decades of experience under their belt would be trusted with a project this size. Patel thinks that’s a problem.

“If you don’t hire the early-in-career [workers], and you just let your workforce continue the way that they were, where do fresh ideas get injected? How do you challenge the status quo?” he said.

Seasoned staff can still come up with new ideas, Patel added. What they can’t do is ask the questions that only someone with no experience would think to ask.

And getting the two to get along isn’t always smooth. Patel admits that putting a Gen Zer in a room with people who’ve been at Cisco for decades can create friction—but he says that’s the point.

“Tension is good,” he said. “I actually try to create tension in the teams because you want to have enough friction on the ideas. You don’t want to have friction with people and personalities.”

“What you have to do is establish enough trust with people to say you are going to be expected to create unreasonable goals for yourself,” he added. “And so, in order to go out and achieve those unreasonable goals, think outside of the box.”

And he’s not just pushing senior staff to take notes from twentysomethings. He said that he treats every intern as “kind of a reverse mentor,” and even does talks at colleges to find students who are “hungry.”

His latest Gen Z bet came out of one of those talks, to 17- and 18-year-old Stanford scholarship students. While a line of students fired questions at him, one, Baya, stood off to the side, just listening. She waited until everyone else had finished before she opened up.

He told her to email him every month with what she’d learned about AI. It was a test of follow-through: “Everyone can go out and have one good conversation. But are they going to stick with their commitments?”

She never missed one, landed an internship at Cisco, and redesigned “something” that experienced staff hadn’t been able to crack.

“I didn’t bring her in so that she can do grunt work and do data entry,” he said. “We brought her in so that she could actually teach our people how to think completely differently.” Now he wants to recruit her.

Patel isn’t the only one betting on Gen Z—OpenAI investor Josh Kushner and Will.i.am are hunting for young, hungry talent

Patel isn’t the only boss who sees Gen Z’s lack of experience as an asset.

Thrive Capital’s founder Josh Kushner told Fortune he specifically likes to hire people with less than four years of industry experience.

When he launched the venture capital firm at just 26, he faced pressure to bring in older, more seasoned hires. But, as he put it, “anyone who has experience that is talented will never want to work with a 26-year-old.” So, instead, he recruited the “smartest people that we knew who were our ages.”

And that bet paid off: His firm made early investments in startups worth billions, including OpenAI, which is currently raising up to $30 billion at a $1.25 trillion valuation.

These days, Kushner could easily hire industry veterans with glowing résumés—but he’d still rather “find that young, hungry person.”

Alon Chen, founder and CEO of Tastewise—a generative AI platform trusted by PepsiCo, Nestlé, and Mars—is also actively looking for Gen Zers with zero experience.

“I’m hiring entry-level because they have no boundaries or limitations in how they think about the world,” Chen told Fortune. “They’re almost like AI natives themselves, having been born and raised in this new realm of opportunities. And I see some of the best ideas coming from the younger generation that have not yet been in the job market.”

And Will.i.am has reached a similar conclusion. The Grammy-winning Black Eyed Peas frontman might be best known for his chart-topping hits, but behind the scenes, he’s a serious investor too. He backed Tesla, OpenAI, and Pinterest before they became household names—and now, he’s betting on Gen Z for his next investment.

Why? He believes the next big tech breakthroughs will come from young innovators at MIT and Stanford. “They’re young kids, and they’re native to this,” Will.i.am told Fortune. “So you want to hunt for that. That’s the only thing I’m focused on.”

And Patel told Fortune that the trend toward hiring Gen Z will only continue, thanks to AI.

“The only way for us to keep accelerating is to make sure we’re surrounded by people with a broad range of experience,” he said. “Roughly one-third of my team is experienced, scaled operators who understand how the Cisco engine works. The second third are systems thinkers from the market who bring the outside-in perspective. And the final third is made of entrepreneurial founders, CEOs, and engineers who are AI-native who operate in founder mode.”

“Either of these groups by themselves aren’t nearly as potent as when all three work together. It’s what creates magic.”

tl;dr: You can now run many BeOS versions in the browser at Infinite Mac, my site where you can experience the Macintosh Cinematic Universe from 1984 to 2005. The installs are full peers to their Mac cousins: you can boot them instantly (large disks are streamed in), play around with pre-installed software from Infinite HD, insert CD-ROMs from the Internet Archive, and save your work on the “Saved HD” drive.

BeOS was a multimedia-focused, multi-tasking and multi-threaded OS that was eventually ported to the Power Macintoshes of the mid-90s. It impressed many in the Mac community, including Apple itself, who considered acquiring Be, the company that had created it. If you’ve been following the saga of Apple’s search for a next-generation operating system, this lets you see what the road not taken was like.

Getting BeOS Running

After the last somewhat involved (though still satisfying) project on Infinite Mac, I was looking for a quicker win. BeOS had been on my radar for a while, and (unlike A/UX) I had a personal connection to it: I remember spotting a BeBox in Akihabara, making my Mac cosplay as it with BeView, and eventually dual-booting BeOS on my Power Macintosh 8500. DingusPPC, an emulator I had already integrated, was making good progress on running BeOS, so it seemed like adding it to the site would be mostly a matter of preparing some additional disk images.

Initially it appeared to be as straightforward as I had hoped; I added a Power Macintosh 7300 configuration (one of the Power Macs that was officially supported), found an install CD, made a disk image, and was up and running. But as I used it more and started to install additional versions, I began to find a lot of small bugs and edge cases:

• The BeOS boot loader thought that all modifier keys were being held down due to a bug in the ADB emulation; this made it present the (ugly, PC BIOS-like) partition choice screen every time.
• When changing the screen depth, there are two hardware components that need to be notified: the video controller and the digital-to-analog converter. DingusPPC had been accidentally relying on the order that Mac OS sent these notifications in; BeOS happened to make the opposite choice and would end up with a corrupted display.
• Early versions of BeOS did video memory updates in little-endian mode1; DingusPPC was missing support for that hardware capability.
• Later versions of BeOS could mount HFS partitions, but they were having trouble with the volumes that I generated via the machfs Python library. It turned out that BeOS was (correctly) stricter than Mac OS about how some data structures should be populated.
• And so on – most of the commits that I upstreamed to DingusPPC over the past month were in a quest for better BeOS compatibility.

The best of both worlds?

SheepShaver, a Power Macintosh emulator that is still around today (and that Infinite Mac also embeds), originated on BeOS. Mostly for the fun of another layer of inception/emulation, I wanted to make sure that it worked too. As it turned out, it also required a compatibility fix – it relied on an edge case of how the ROM is mapped to physical memory addresses that DingusPPC did not accurately model.

There is a pattern to most of these bug fixes: DingusPPC (and Infinite Mac) have been mostly focused on running Mac OS, and thus accidentally became dependent on its quirks or implementation choices. Adding an independently developed operating system to the mix exercised new paths, and ended up improving the accuracy of the emulated hardware. To be clear, DingusPPC was pretty close out of the box; kudos to its maintainers. I believe that, with this work, it’s the only emulator2 that can run PowerPC versions of BeOS. I’m also hopeful that this will help with bringing up alternate operating systems like MkLinux (which I also have memories of) and Rhapsody.

On the Infinite Mac side, there were obvious changes like a “BeOS” appearance for my custom controls and collecting software for the library. I also needed to overlay some dynamically generated content on the disk to get the OS to preselect a screen resolution that matches the browser window’s (similar to what was done for A/UX). An AI agent (still Codex for me) was once again helpful for this type of fiddly reverse-engineering task: it’s one thing to observe that the OS stores a file on disk with the screen size; it’s another to be able to reproduce all its nuances, especially as the format changed with later releases.

Developer Release 8.2, the initial BeOS version for Power Macs, had a time bomb that kept it from booting after April 1, 1997. This was not just to create a sense of urgency; it shipped with a licensed font renderer that Be could not distribute indefinitely. DR8.3 addressed this, but to make that notable first version bootable, I did end up relying on the custom date support to hardcode a working date when choosing that disk.

BeOS Impressions

Though I did kick the tires of BeOS back when it was current, I don’t recall using it enough to form any opinions beyond “this is fast; I miss all my third-party software.” About This Particular Macintosh does have contemporary coverage, including Be’s first and second appearances at Macworld Expo Boston, and reviews of R3 and R4.5; they make for interesting reading. This video released by Be itself also has a walkthrough of what they considered its strengths.

Looking at it with 2026 eyes, I am still struck by its speed – it’s fast to boot and to use, especially when compared with its contemporary Mac OS releases that do so much less (e.g. live window dragging did not appear until Mac OS X). The POSIX subsystem and the Unix-like shell also feel modern (unlike A/UX’s) – I had no trouble using the terminal to poke around. There’s also plenty of innovation, though some of it (BFS with its attributes and live queries) is more interesting than the rest (replicants are a precursor to widgets, but I couldn’t think of a use for them).

It also feels like a developer-focused and under-construction system: many of the included apps are technology demos (though who doesn’t love a Utah teapot), while a contemporary Be homepage links directly to the developer release notes and discusses CodeWarrior releases and access to the bug tracker. The unfinished nature extends to third-party software too – I stumbled across some BeOS software on this Amiga magazine CD, and most of it had a “version 0.1” feel, either literally or figuratively. To be fair, I did find some more fleshed-out software, for example, Gobe Productive from the former ClarisWorks team. This and other software is on Infinite HD if you’d like to try it out (preferably in later OS versions).

The interface seemed novel at the time, though I wonder how it would have held up3. The distinctive tabbed window titles look neat, but they have a reduced draggable area, so I’d have to think harder every time I wanted to move a window. And using a hand as the default cursor makes clicking feel less precise than a traditional arrow (just which of the pixels on the “finger” is the hotspot?). Other parts of the UI feel like a not-fully-coherent Windows/Mac hybrid, with a Deskbar that can emulate a Start menu4, Alt key accelerators on menu items, but also spring-loaded folders and a spatial Finder Tracker.

Speaking of the Tracker, I had not realized that Be had open-sourced it (and even incorporated changes from the open-source version). This was around the time that Be pivoted away to internet appliances – there’s no need to invest engineering resources in a file manager if all that’s exposed is one full-screen browser app. This interview with the Tracker developer has more of the backstory.

Do your own bake-off: NeXT vs. Be

NeXTStep, by comparison, feels more mature. It had gone through some similar churn (proprietary hardware to off-the-shelf PCs, company strategy shifts), but, perhaps because it had more time, it handled things a bit more gracefully. For example, NeXT supported “fat” binaries that could run on 68K, Intel, PA-RISC and other architectures. On BeOS they had to be separate executables, making the user choose which to run and complicating distribution (this made it harder for me to find software to include in Infinite HD). Worse yet, you also had to have parallel disk partitions on CD-ROMs: BFS used the host endianness, so disks written by a PowerPC install could not be read by an Intel one, or vice versa. But my pro-NeXT bias may be due to knowing which OS Apple ended up picking.

Other Site Improvements

It’s only been a short while since the last update, but I did squeeze in a couple of quality-of-life improvements. You can now take screenshots and record videos (with sound) of the emulated machine’s screen. This gives you a high-fidelity way to capture image content, since it’s a direct dump of what would have been shown on the screen.

I also expanded the collection of operating system CD-ROMs with items like the Rhapsody and Mac OS X developer previews. While they’re aspirational for now (DingusPPC can’t run them yet), they do satisfy my completionist tendencies. These CDs are mirrored to and served from my own Cloudflare R2 bucket – the Internet Archive is an incredible resource (you can donate to them), but streaming from it has been increasingly flaky. I don’t want to add to the problem, and thanks to my sponsors, I can afford to serve a few gigabytes.

As for what’s next, with this alternate Mac timeline covered, it may be time to explore a prequel.

1. TIL that this was possible – Apple generally ran the PowerPC and did everything on its machines in big-endian mode. There’s even a patent about this controller capability. ↩
2. Though while I was working on this, BeBox was vibed into existence. ↩
3. Then again it looks like Haiku has preserved it almost verbatim, so it definitely has a long-lasting appeal to some. ↩
4. If you can find the 3-pixel-wide draggable area to move it to the bottom. ↩