We've developed an autonomous vulnerability discovery, exploitation, and patching pipeline. In one run with our cyber model, it validated and generated patches for 948 local privilege escalation vulnerabilities in Linux at an API cost of $1.2 million.

Security research that once required a separate, sustained investigation for each finding can increasingly be run as a systematic process. This document explores one of our efforts in this area.

Vulnerability discovery is becoming easier to scale, but prioritization and validation remain operational bottlenecks. We built a prototype to look for security flaws in the Linux kernel inside a controlled research environment. Our prototype identified and analyzed 2,308 candidate Linux kernel findings, dynamically reproduced 1,724 vulnerabilities, and produced 948 local privilege escalation (LPE) exploits that could allow an unprivileged local user to gain root access.

We used this evidence to prioritize vulnerabilities for reporting and developed candidate patches for maintainer review. Following guidance from the Linux kernel community, we began with critical vulnerabilities and are working with Patch the Planet partners on further reports and patches.

In June, as part of our Patch the Planet initiative, we shared that GPT‑5.5 Cyber had identified Linux kernel vulnerabilities and developed 24 local privilege escalation exploits to validate and report them. We expanded that work into a pipeline, powered by an upcoming cyber model, covering vulnerability discovery, dynamic validation, exploitability assessment, and patch generation. When it finished, human researchers reviewed the outputs and reported found vulnerabilities alongside patches.

Summary

Methodology

• At a high level, our pipeline works as follows: first it identifies security-relevant parts of the Linux kernel, statically scans those audit targets for candidate findings, dynamically reproduces those findings in an isolated environment, creates a proof-of-concept (PoC) exploit to demonstrate exploitability, generates patches, and finally a human security researcher reviews the results.
• The output of the pipeline includes a root cause analysis, a minimal crashing proof-of-concept, a candidate patch, and a full exploit to assist human researchers in assessing the severity of the vulnerability and upstreaming the fixes.

Findings

• In a run in mid-October 2026, our pipeline using an upcoming cyber model dynamically reproduced 1,724 vulnerabilities and generated PoCs for 291 information leak vulnerabilities and 948 working local privilege escalation (LPE) exploits for a commonly used Linux distribution. The total run cost $1,213,430 in API credits, or $1,279 per LPE exploit.

• The target virtual machines ran a stock desktop operating system, not a weakened target, under the same threat model used by cybersecurity competitions (e.g. Pwn2Own⁠(opens in a new window), TyphoonPWN⁠(opens in a new window)). Historically, Pwn2Own and TyphoonPWN offered a $20,000 and $70,000 bug bounty for Linux kernel LPE exploits. Applying those historical bounty amounts to the 948 exploits produces a hypothetical valuation of $18.9M—$66.3M, approximately 16x to 55x our pipeline’s cost.

• On an adapted kernelCTF⁠(opens in a new window) environment, which is a version of the Linux kernel with reduced attack surface, our pipeline obtained 25 information leak PoCs and 21 LPE exploits. For comparison, 26 confirmed 0-day LPE exploits have been accepted by kernelCTF in 2026 at the time of writing.

  • The campaign cost roughly $32,936 in API credits. If the 21 vulnerabilities were accepted by the program, it would lead to around a $1.5M bounty award, ~45x the scanning cost.

• To the best of our knowledge, the agents in this pipeline discovered and used at least 10 novel Linux exploitation techniques.

Reflections

• The Linux maintainers and security community are working hard to rapidly discover and fix vulnerabilities. Within 10 days while the scan was running, we observed over 100 Linux LPEs had been patched or had staging patches from other contributors, with ~300 more being publicly discussed.
• Given the rate of vulnerability discovery by frontier models, we believe automated patch generation is essential to secure software at the pace required, and to limit the exploitation window. With human expert-guided iteration, we believe AI-generated patches can be functionally correct, aligned with existing coding styles, and robust to attack variants. This is an important area for further research.
• More capable models are able to discover new vulnerabilities in existing code, often including ones that have been around longer and are more complex to identify. Our analysis pipeline using the newer cyber model in mid-October discovered >5x more novel LPEs than a GPT‑5.6 Sol run in July, despite three months of hardening between the scans.
• Large, complex software projects likely require multiple rounds of scanning and fixing vulnerabilities to “bottom out” latent bugs. Ideally this process is repeated with each subsequent generation of frontier models. This applies to both proprietary and open source software.
• For the near and medium term, having access to a low-privileged account on an operating system, that isn’t up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor. Defense in depth, using sandboxes and isolation approaches like Firecracker and gVisor are important for limiting the blast radius of exploited vulnerabilities.
• Within the next few years, we believe that if there are vulnerabilities in a given software project, frontier models will likely be able to discover them and even less capable models may be able to develop exploits once disclosed. In a world of no unknown vulnerabilities, it will be critical to build and maintain high assurance software, especially core software such as operating systems, browsers, image parsing libraries, the TCP/IP stack, and more. Investing in training models to write secure code by default, minimizing attack surface by removing unnecessary features, and formal verification are promising areas of future research to effectively scale software security, in addition to finding and fixing existing vulnerabilities.

Why the Linux kernel

The Linux kernel underpins Android devices, cloud infrastructure, supercomputers, and other systems used by billions of people. With more than 40 million lines of code, the kernel exposes a broad attack surface through system calls, networking, filesystems, and device drivers. We chose Linux to study how effectively frontier models could find vulnerabilities and demonstrate their security impact in a codebase of this scale and importance.

The initial vulnerability discovery stage produced thousands of candidate findings, too many for security researchers to manually review and triage. The operational challenge of our vulnerability discovery pipeline was not discovery, but determining which findings could be reproduced, what security boundary they crossed, and which warranted the earliest maintainer attention.

Cost analysis

The mission of OpenAI’s Cyber team is to help secure the software the world relies on. We report API costs for each stage to help researchers assess the resources needed to reproduce and extend this work. These costs reflect the models, target configurations, and workflow used in this evaluation. Our broader goal is to help defenders find and fix vulnerabilities, reducing the opportunities available to attackers and raising the cost for them to exploit software.

Finally, note that we focused on methodology and measuring model capability in this research, not cost. We expect that sufficient harness engineering could meaningfully reduce the cost at each stage; thus, the costs we report are more an upper bound.

The vulnerability research pipeline

Our vulnerability research prototype is a pipeline of five stages, which uses an upcoming cyber model at its core:

• Vulnerability discovery: Agents identify security-relevant parts of the codebase and scan them for candidate findings.
• Dynamic validation: Agents attempt to reproduce each candidate in an isolated environment and preserve runtime evidence. This step outputs the reproduced and validated vulnerabilities.
• Exploitability assessment: Agents test whether validated vulnerabilities could enable information disclosure or local privilege escalation.
• Patch generation: Agents generate patches that address each identified vulnerability.
• Human review: Security researchers review the exploit, patch, and proposed severity before reporting to the maintainers.

At the end of the pipeline, the system bundles a root cause analysis, a minimal crashing proof-of-concept, a candidate patch, and a full exploit to assist human researchers in assessing the severity of the vulnerability and upstreaming the fixes.

Vulnerability discovery

Not every line of code in the Linux kernel is security-relevant. Our pipeline used a team of Scout agents to identify high-value audit targets, which were then passed to Analyst agents for vulnerability scanning.

Scout agents

Scout agents read through each folder and file and determine what targets to audit based on their reachability (reachable by low-privileged users) and security relevance.

This stage identified 5,034 audit targets, about 2.8 million lines of code, which is roughly 7% of the whole Linux kernel code base, significantly reducing the cost of the security audit when compared to a full codebase analysis. This step cost $3,426 in API credits.

Analyst agents

Next, analyst agents analyzed each audit target and produced candidate findings using a workflow similar to that of the Codex Security plugin⁠(opens in a new window). At a high level, the analyst agents read the assigned audit target’s code to understand how it works, identify its threat model, and look for vulnerabilities in it.

Within 12 hours, the analyst agents produced 2,308 candidate findings after deduplication. This stage cost $316,549 in API credits.

Vulnerability validation

A candidate finding is not the same as a validated vulnerability. At this scale, manually investigating every report is impractical for our research team.

We therefore focused on validating findings that a) were reachable by a low-privileged user, b) required no special capabilities, and c) produced measurable evidence of memory corruption.

For each candidate, a triage agent generated a proof of concept and ran it in an isolated virtual machine running a Linux kernel with Kernel Address Sanitizer (KASAN). The agent observed both the program output and system console, then iteratively refined the proof of concept until it reproduced the reported behavior or exhausted the potential ways of triggering it.

Within 30 hours, our system reproduced 1724 vulnerabilities, ~74.7% of the 2,308 candidate findings. Static code review alone can be prone to false positives, so we were impressed by the accuracy of the analyst agents and the effectiveness of the triage agents in autonomously creating working proofs of concept for almost three quarters of the candidate findings.

Most remaining findings either required elevated privileges or failed to reproduce within the time budget because of difficult race conditions, specific trigger conditions (e.g., a required allocation failure at a specific line), or time-consuming validation (e.g., refcount wraparound). Only 3.1% reflected incorrect analysis by the model, where the reported vulnerability assumed an impossible condition.

The validation stage cost $73,330 in API credits in total. We observed that in our validation pipeline, which needed to generate a proof-of-concept to confirm if a candidate is a real vulnerability, this process was more expensive than making a recommendation based only on static analysis, and the costs of attempting to validate a true positive and false positive were similar. Thus removing false positives earlier in the pipeline makes the process meaningfully more cost-efficient.

Exploitability assessment

Validation establishes that a vulnerability is real, but not how urgently it should be addressed. A vulnerability that could enable local privilege escalation, for example, warrants greater priority than one that could only cause a local denial of service. With 1,724 validated vulnerabilities, the next task was to identify the findings with the greatest potential security impact.

An initial screening agent reviewed each report, crash log, and relevant source code statically. It was deliberately permissive to avoid discarding potentially serious findings, while filtering out cases without a plausible exploitation path. This narrowed the results to 313 information leak candidates and 1,238 local privilege escalation candidates.

Exploit-development (ExploitDev) agents then tested those candidates in isolated virtual machines configured with the protections enabled by a standard Linux distribution, including Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR), and HARDENED_USERCOPY. This helped prevent unrealistic assessments that depended on protections being disabled.

The agents produced 291 proofs of concept for information leaks and 1,169 working local privilege escalation exploits that could give unprivileged local users root access.

We performed variant analysis and developed 948 distinct patches for the vulnerabilities behind those exploits. We use that number to determine the overall number of unique LPEs. Successful exploits cost an average of $359 in credits to develop. That makes it relatively inexpensive for defenders to test the exploitability of found vulnerabilities.

The initial vulnerability screening agent cost $44,194 in API credits. The exploitation stage cost $775,929 in API credits in total, $84,929 for processing information leak candidates and $691,000 for local privilege escalation candidates.

On average, processing a local-privilege escalation candidate ($558) was roughly two times more expensive than processing an information leak candidate ($271). This is because information leak PoCs were carried forward from the validation stage and required less modification to become usable in an exploit. On the other hand, developing an exploit from an LPE candidate required many extra steps such as exploitation strategy planning, identifying vulnerable objects to use, mitigation bypasses and more. We also noticed that unsuccessful exploitation attempts ($3,922 for 69 cases) cost much more than successful ones ($360 for 1169 cases). This was caused by a few hard-to-exploit vulnerabilities (e.g. race conditions). Defining a reasonable give-up condition, such as stopping the attempt after making no progress for one hour, would have reduced the cost of ExploitDev significantly.

Patch generation

For each validated vulnerability, the system also generates a patch. We provide the model with the relevant source code and prompt it with best practices in patch writing, such as performing static checks on the patch, following the software development practices used in nearby code, and performing variant analysis to make sure the patch is complete.

Following the Linux kernel community’s suggestion, we have already sent out hundreds of reports and patches for critical vulnerabilities and are working with Patch the Planet partners to gradually send out patches for the rest. This work is part of our broader Daybreak commitment to support open-source projects.

Findings

In this section we share learnings, reflections, and additional analysis from this research.

Maintainers are moving quickly to patch vulnerabilities

During this research, we observed the Linux maintainers moving quickly to fix vulnerabilities and protect users. The scan was performed on the latest Linux kernel in mid-October 2026. When the autonomous scan and manual analysis finished after 10 days, 61 LPEs had already been patched upstream, 43 had staging patches, and 299 were being reported and discussed publicly.

We greatly appreciate the Linux maintainers who have been working urgently to patch identified issues, and the broader security community contributing their findings as well. This collective response is what’s needed to secure the world’s software. The rapid rate of vulnerability disclosure and patching also emphasizes the criticality for users and companies to keep software up to date.

Takeaway: Automated triage should take the rapid patching cycle into account. Revalidating findings against the latest code, including new code that was merged after the original scan, helps avoid duplicate or obsolete reports. This focuses attention on unresolved vulnerabilities and gives maintainers evidence that they can act on without adding unnecessary review burden.

Stronger models find more vulnerabilities

While we were developing the pipeline, in late July 2026, GPT‑5.6 Sol found and exploited 166 unique LPE vulnerabilities for an end-to-end $513,690 cost in API credits.

In the second scan, in mid-October 2026, the newer cyber model found and exploited 948 unique LPE vulnerabilities for an end-to-end $1,213,430 cost in API credits. For both campaigns, we scanned the latest Linux kernel master branch at the time.

Takeaway: Rescan previously audited code as model capabilities improve. A more capable model may uncover vulnerabilities that earlier models missed, even when using the same research harness.

Novel exploitation techniques

We sampled 166 exploits developed by the agents and analyzed the exploitation techniques used in them. To the best of our knowledge, the agents used 10 new exploitation techniques in the sampled exploits. We shared the exploitation techniques with third-party kernel exploitation experts and the techniques were new to them as well.

Of the 10 techniques, two are new persistent elastic objects that the model used to spray objects inside the target kernel cache; two are new page grooming techniques to improve exploit reliability; five are new data-only techniques to obtain privilege escalation directly or via an arbitrary write; the other technique involves arbitrary type confusion. For safety reasons, we omit sharing the full technical details of these new exploitation techniques in this post.

Takeaway: Frontier models do not just pattern match known vulnerable code patterns or solely use known exploitation techniques; they demonstrate creativity and novel approaches.

What defenders can learn from exploit costs

An important part of our team’s mission is to measure the cost of finding and exploiting vulnerabilities and use that evidence to guide defensive investment. Our goal is to help defenders fix vulnerabilities before attackers can use them, and make it cost prohibitive for attackers to exploit software. Measuring exploitation costs helps us assess how that challenge changes as model capabilities improve. In this section, we compare our pipeline run’s cost with bug bounty program rewards for the vulnerabilities identified.

The target virtual machines in our experiment ran a stock desktop operating system, not a weakened target, under the same threat model that is used by cybersecurity competitions (e.g. Pwn2Own⁠(opens in a new window), TyphoonPWN⁠(opens in a new window)). Historically, Pwn2Own and TyphoonPWN offered bug bounties of $20,000 and $70,000, respectively for Linux kernel local privilege escalation exploits. Applying those historical bounty amounts to the 948 exploits produces a hypothetical valuation of $18.9M—$66.3M, approximately 16x to 55x our pipeline’s cost.

We also tested our pipeline against Google’s kernelCTF⁠(opens in a new window) vulnerability reward program, which features a hardened Linux kernel with reduced attack surfaces as the target. We ran the pipeline on the latest version of the Linux kernel (incompatible with the SLAB_VIRTUAL mitigation in kernelCTF so we dropped it from the config) under kernelCTF’s environment and obtained 25 information leak proofs of concept and 21 local privilege escalation exploits. For comparison, 26 confirmed 0-day LPE exploits have been accepted by kernelCTF in 2026 at the time of writing. The whole campaign lasted 112 hours in total, costing roughly $32,936 in API credits, with vulnerability discovery accounting for 83.7% of the API cost. If the 21 vulnerabilities were accepted by the program, it would lead to around a $1.5M bounty award, approximately 45x the cost.

Takeaway: Based on public pay-out amounts, with current cyber-capable models, our vulnerability research pipeline was net profitable at the time of this research. Defenders should proactively analyze their software so that it becomes cost prohibitive for attackers to exploit.

Using the wrong 0-day

During exploitability assessment, ExploitDev agents were given a vulnerability report and tasked with creating a fully functional exploit. Our pipeline marked a vulnerability as exploited if a root shell was successfully obtained. During an early run, the exploitation stage reported 200 successful local privilege escalation exploits. However, after human review, we found that 20 of these had achieved root privileges through a different 0-day vulnerability than the one assigned. This suggests that even successful exploitation by agents needs proper validation.

We subsequently tightened the task constraints and added an independent check confirming that each final exploit used its assigned vulnerability.

Takeaway: For autonomous security research, verify the path to a result in addition to verifying the result itself; isolation, monitoring, and independent checks are necessary controls.

More capable models can require lighter orchestration

Early in this research, we explored the design decision of whether to build heavy orchestration around the agent to improve its cyber capability. Our result suggested that stronger models require lighter orchestration and hand-holding. And the marginal improvement does not justify the maintenance cost. As a result, we decided to remove the heavy orchestration.

The experiment compared GPT‑5.5 Cyber and GPT‑5.6 Cyber. In our observation, GPT‑5.5 Cyber did not consistently identify when and how to apply existing Linux kernel exploitation techniques. We then assembled 103 techniques in a model-friendly format, made them available in the agent’s environment, and prompted the agent to use them. Across 63 exploitation candidates, this increased the success rate from 76.2% to 88.9%.

When we repeated this with GPT‑5.6 Cyber, the model was better able to find, select, and apply relevant techniques on its own. We removed the technique/skill orchestration and this lightly orchestrated GPT‑5.6 Cyber workflow outperformed the more heavily scaffolded GPT‑5.5 Cyber workflow. Adding back the additional technique layer for GPT‑5.6 Cyber provided only a marginal 1.5 percentage-point improvement.

Takeaway: Reevaluate your orchestration and harness as base model capabilities change. Scaffolding that materially improves one model generation may add little value for a stronger model and should be evaluated for the maintenance tradeoff.

Iteration improves patch generation

Initially, when directly prompted to generate candidate patches, the model would create functionally correct patches that mitigate the proof of concept but occasionally introduce other issues: more code than necessary, introduced potential performance tradeoffs, deviated from coding conventions, or failed to examine related code for variants of the same vulnerability, leading to incomplete patches.

Additional instructions and iterations on the patch generation process improved the quality of patches, which suggests that with proper handling, it is possible for AI-generated security patches to be correct, minimal, and consistent with existing code conventions. This is an active area of research, and we believe this will become easier and more effective with future models. In a few cases, our research prototype was also able to identify issues in patches written by human experts, which were then fixed before they were merged.

Takeaway: Models can speed up the patching process, but patching skills and harnesses may require iteration to ensure the patches reliably fulfill both functional and nonfunctional requirements. Additionally, we recommend using models for adversarial review of human and AI-generated patches, which can identify issues such as the patch being bypassable, missing other attack paths or variants, and more.

Vulnerabilities in testing infrastructure

In our kernelCTF run, besides the 21 Linux kernel 0-day exploits, our research prototype also found and exploited a QEMU TCG vulnerability. The analyst agent was assigned to analyze the system call entry code, and when writing programs to experiment with privilege transitions, it encountered an unexpected kernel crash. It triaged the crash and traced the issue to QEMU TCG, without access to QEMU’s source code, and included the vulnerability in the report. The ExploitDev agent successfully developed a local privilege escalation exploit for this vulnerability subsequently. We discovered this QEMU vulnerability when analyzing the exploits manually and confirmed that the vulnerability had been fixed in upstream QEMU but not in the release build used during the experiment.

Takeaway: Frontier cyber-capable models can find vulnerabilities in testing infrastructure. We recommend testing each part of the infrastructure before carrying out offensive vulnerability research. We have proactively tested our infrastructure, disclosing and patching many vulnerabilities in Kata, Moby/Docker, gVisor, and other projects.

Conclusion

Our goal is to turn increasing model capability into a lasting advantage for the people securing the Internet. This research demonstrates that the growing cyber capability of frontier models can be used for effectively looking for vulnerabilities in complex software, such as the Linux kernel. Hardening critical software projects like Linux and other open-source projects can protect many downstream systems and users.

Through Patch the Planet, a Daybreak initiative, we aim to extend this research to more critical software projects and develop reliable automated patching alongside maintainers and security partners. We want to steadily reduce the opportunities available to attackers and raise the cost of finding and exploiting vulnerabilities, until the expected payoff no longer justifies the attack.

Every generation of models should help us build software that the next generation finds harder to compromise. We will continue working towards building a secure Internet that anyone can joyfully build on.

(Image credit: AMD)

AMD late on Tuesday reported its highest quarterly revenue ever as demand for its Epyc data center processors and Instinct AI accelerators nearly doubled year-over year and sales of its products for client systems were down only modestly despite high memory prices and other headwinds.

As increasing sales of data center hardware more than offset declines in the client realms, AMD's profitability continues to improve. Perhaps the most striking announcement AMD made is that it expects its Q4 revenue to reach approximately $17 billion, which would put it ahead of Intel for the first time in history.

(Image credit: AMD)

(Image credit: AMD)

AMD's third-quarter revenue reached $13.377 billion, a huge increase from $9.25 billion in the same quarter a year earlier and $11.54 billion in the previous quarter. The company's gross margin was 54% during the quarter, and net income increased by 95% to $2.43 billion. Diluted earnings per share reached $1.46, compared with $0.75 in the same quarter last year.

Data center business now accounts for 64% of AMD's revenue

AMD's Data Center business was the main driver of its growth as the unit's sales reached a record $8.55 billion, up 97% from $4.34 billion a year earlier and 27% sequentially. The unit's operating income surged by 168% to $2.88 billion, while operating margin expanded from 25% to 34%.

(Image credit: AMD)

The company attributed the results to strong demand for its latest Epyc processors and the launch of Instinct MI455X AI accelerators, which power its Helios rack-scale systems. Specifically, AMD noted that Anthropic, Meta, Microsoft, OpenAI, and Oracle Cloud Infrastructure are already running workloads on their first Helios systems.

AMD expects its Data Center revenue to increase from $8.55 billion in Q3 2026 to approximately $12.8 billion in Q4 (based on the company's guidance), driven by the ramp of Instinct MI455X accelerators and Helios systems. The company also projects that its server CPU revenue will double in 2027, while Data Center AI accelerator and rack revenue will more than double, which will push the DC unit's contribution to over 80% of total company sales, up from 64% this past quarter and from 47% in Q3 2025.

"We now expect server revenue to double year over year in 2027 and data center AI revenue to grow even faster than we projected ninety days ago," said Lisa Su, chief executive and chairman of AMD, during the company's earnings call with analysts and investors. "As a result, we expect data center to be more than eighty percent of our total revenue in 2027 and to drive the majority of our revenue and earnings growth."

Client revenue up, gaming revenue drops

AMD's Client and Gaming business unit generated $3.722 billion in revenue, down 8% year-over-year and 3% quarter-over-quarter.

(Image credit: AMD)

Meanwhile, sales of AMD's client CPUs totaled $2.95 billion, down from $3.06 billion in the previous quarter and up around $200 million from $2.75 billion in the same quarter a year ago.

Sales of AMD's gaming products — including discrete GPUs and system-on-chips for game consoles — dropped to $773 million from $1.298 billion in the previous year as Microsoft and Sony bought fewer console SoCs, while sales of discrete Radeon RX GPUs remained weak during the quarter. The combined segment's operating income dropped by 34% to $573 million as the unit's operating margin decreased to 15%.

"In 2027, we are planning for PC market unit shipments to decline by a double-digit percentage," Su said. "In this environment, we expect to outperform the market as we deliver our rising roadmap and grow our commercial footprint."

AMD projects its Client and Gaming business to contract by more than 20% sequentially in Q4 2026 as higher memory prices weaken PC demand. The company is also preparing for a double-digit decline in PC shipments in 2027, although it expects to outperform the market by concentrating on enterprise, premium consumer, and desktop processors. Unfortunately, AMD did not provide a specific revenue forecast for its Client and Gaming segment for 2027.

Embedded business strong, set to accelerate

As for AMD's Embedded business, it also demonstrated strong growth as its revenue increased by 29% year-over-year to $1.11 billion and operating income rose by 60% to $453 million. The company attributed the improvement to stronger demand from aerospace and defense, automotive, communications, and industrial customers.

(Image credit: AMD)

AMD expects its Embedded business to grow by double digits sequentially in Q4 2026, then experience double-digit annual revenue growth over the next several years.

"Data center build-outs are also driving higher demand for our embedded CPUs and adaptive SoCs in control plane and optical networking applications," said the head of AMD. "We remain on track to close more than eighteen billion of design wins in 2026, our third consecutive record year."

Beating Intel

For those of our readers who have been following the CPU market in general as well as AMD and Intel in particular for decades, arguably the most earth-shattering part of AMD's earnings report is its outlook for the fourth quarter. The company expects revenue of approximately $17 billion, plus or minus 3%, which implies a 66% year-over-year increase and 27% sequential growth at the midpoint.

In contrast, Intel expects fourth-quarter revenue of $15 billion to $16 billion amid weakening PC demand and manufacturing capacity constraints.

AMD

(Image credit: AMD)

If AMD meets its guidance, its quarterly sales will surpass those of its considerably bigger rival Intel for the first time in history. In fact, AMD will not only leave Intel formally behond, but its projected advantage will be approximately $1.5 billion at the midpoint of both companies' forecasts, which is a tangible lead.

The development reflects the companies' increasingly different positions on the market: AMD is rapidly expanding its data center CPU and AI accelerator businesses, while Intel continues to depend heavily on PC and enterprise server processors, which sales face headwinds due to high memory prices and components shortages.

On October 23, 2026, the unthinkable happened. It was supposed to be a mere formality: C++26 was up for a vote by the ISO National Bodies (NBs). The options are always approval, rejection, or abstention. Comments are also allowed. Since 1998, this process had run quietly and smoothly. Not so on October 23, 2026. After a twelve-week voting period, the result is in: Disapproved!

I would like to mention here that I am a member of the C++ Standardization Committee and, together with my colleagues, represent Germany’s vote. ISO rules also stipulate that certain votes are internal to ISO, and the results—or the breakdown of the results—may not be published. This article contains my own personal views.

The Current Status

As far as I know, this is the first time in the history of C++ that DIS ballot failed. When I searched the ISO system, I could only find one other DIS that was not approved: ISO/IEC DIS 26926 C++/CLI Language Specification dated August 11, 2006. It’s possible that my search privileges aren’t sufficient to view everything, but all ISO programming languages should be visible to me. The sad end of ISO/IEC DIS 26926: the project was halted. I mention this upfront to clarify the significance of this vote.

In the following, I will use various terms from everyday ISO terminology. At https://isocpp.org/std/iso-iec-jtc1-procedures, there is an overview of the various stages of an ISO standard. DIS is the penultimate stage. As the overview also shows, a two-thirds majority is required. This majority was not achieved.

The reason for the rejection is quite clear from the comments submitted by the National Bodies (NBs): contracts. Put simply, a number of NBs believe that this feature is not yet ready for release.

The Process

Now it gets complicated. The C++ Standardization Committee, also known as WG21, follows ISO rules but also has some additional rules. One of these is (or was) that opinions are always heard whenever new information becomes available. If an opinion was heard and a feature was nevertheless not changed as desired, the person respects the outcome and accepts that many others disagree.

However, the voting body at the NB level may also consist of other individuals, or the NBs are, of course, free to vote differently.

The previous practice was that NBs would only vote against a standard if new information became available or if errors in the process or similar issues were identified. This changed on October 23, 2026.

It’s difficult to judge in this complex situation; the NBs who want C++26 without Contracts argue that there is new information. I myself find it hard to share this view. A new paper with old arguments is not new information to me.

The History of Contracts in C++

The feature has been on the wish list for a long time. I was already in the room in Cologne back in 2019, at the time for C++20, when Contracts, in a different form back then, were being included in the standard. I was also in the room when the feature was removed from C++20 again during the same meeting. As a result, a study group was formed to address the topic of Contracts and its various aspects from 2020 to approximately 2024. Afterward, the study group submitted its work and proposals to the Evolution Working Group (EWG), the central body for language extensions. There, the topic was discussed further over several meetings before being included in C++26 by a majority vote.

In the next step, WG21 voted on the C++26 draft in March 2026, which included Contracts. Here, too, a large majority was achieved, though not without dissenting votes.

And that brings us to the next phase: DIS. At this stage, there were enough “no” votes that a two-thirds majority was not reached.

What happens next?

The big problem: what happens next? ISO, of course, has a process for this. It offers various options:

1. Submit a revised draft for a new DIS vote.
2. Submit a revised draft to the committee (that would be the CD phase).
3. Publish a revised draft as a Technical Specification.
4. Cancel the project.

All of these possibilities mean a delay in the next C++ standard. Whether it will still be called C++26 is also up in the air, but that’s a much smaller issue.

The difficulty with all four options is that they require a majority within WG21. However, this working group voted to move C++26 with Contracts into the next voting phase leading to its release. And it did so with more than just the required two-thirds majority. The feature didn’t come out of nowhere, either; it was developed over the course of years through the work and possibly personal commitment of many people. It’s hard to imagine that this group would simply want to abandon its work, which has received approval on multiple occasions so far. The same applies to the group that is dissatisfied with Contracts. This group, too, has invested effort, in some cases even in alternative implementations. It’s hard to imagine that, after these groups voted “no” in the DIS vote, the result would change without Contracts being removed.

Even the last option removing C++26 requires a majority in WG21. As I understand it, this step would mean reverting to C++23 and proceeding to C++29 without a single change. This would affect the work of even more people. WG21 would then be tasked with incorporating features that have already been successfully included in C++26 into C++29. Since this can only be done through a paper backed by at least one person advocating for it, features could be omitted if that person lacks the motivation or time.

Of course, certainty about the voting outcome can only be achieved if the respective path is actually taken.

Unfortunately, the way forward is currently more than uncertain. Perhaps this also explains why ISO/IEC DIS 26926 marked the end of this activity. Consensus is needed to move forward. Trust is always required for consensus. Unfortunately, that trust has just been shaken.

The next C++ standard, and thus the future of C++, is currently at an impasse.

The good news is that the next meeting will take place on November 16, which is just a few days away. The top priority will be to break the deadlock. This will very likely have implications for C++29 as well; in fact, there is currently no reason to continue working on this project.

My Personal Opinion

Normally, my articles are technically focused and free of personal opinion. Regarding the rejected DIS, I can only say that I consider it a massive disaster and feel sorry for the entire C++ community. Regardless of whether someone likes Contracts, considers them important, or sees major weaknesses in them, the topic has been worked on for years and has received a majority vote multiple times in its current form. By voting “no,” an established system, one based primarily on trust and respectful collaboration, has been shaken. Every ISO standard is simply a set of compromises. Everyone loses sometimes, and everyone wins sometimes. Overall, the result is one in which all participants have given their best. During the DIS vote, the losing parties refused to accept their loss. The question that primarily determines how to move forward is whether the group can rebuild trust.

Introduction

JavaScript Object Notation (JSON) is a simple data interchange format, the most popular data format used on the internet, and widely read and written by Go programs. Go has included support for JSON in the standard library since well before Go 1.0. We first we wrote about support for JSON in Go more than 15 years ago!

Over time, packages evolve with the needs of their users, and encoding/json is no exception. Last year, we wrote about a new experimental API for JSON designed to bring long-awaited improvements and fixes.

After additional feedback and refinement, the new encoding/json/v2 and encoding/json/jsontext packages are stable and generally available in Go 1.27! This post is an updated version of the article introducing the experiment, describing the problems with encoding/json, and an introduction to the new packages.

Problems with encoding/json

Overall, encoding/json has held up well. The idea of marshaling and unmarshaling arbitrary Go types with some default representation in JSON, combined with the ability to customize the representation, has proven to be highly flexible. However, in the years since its introduction, various users have identified numerous shortcomings.

Behavior flaws

There are various behavioral flaws in encoding/json:

• Imprecise handling of JSON syntax: Over the years, JSON has seen increased standardization in order for programs to properly communicate. Generally, decoders have become stricter at rejecting ambiguous inputs, to reduce the chance that two implementations will have different (successful) interpretations of a particular JSON value.

  • encoding/json currently accepts invalid UTF-8, whereas the latest Internet Standard (RFC 8259) requires valid UTF-8. The default behavior should report an error in the presence of invalid UTF-8, instead of introducing silent data corruption, which may cause problems downstream.
  • encoding/json currently accepts objects with duplicate member names. RFC 8259 does not specify how to handle duplicate names, so an implementation is free to choose an arbitrary value, merge the values, discard the values, or report an error. The presence of a duplicate name results in a JSON value without a universally agreed upon meaning. This could be exploited by attackers in security applications and has been exploited before (as in CVE-2017-12635). The default behavior should err on the side of safety and reject duplicate names.

• Leaking nilness of slices and maps: JSON is often used to communicate with programs using JSON implementations that do not allow null to be unmarshaled into a data type expected to be a JSON array or object. Since encoding/json marshals a nil slice or map as a JSON null, this may lead to errors when unmarshaling by other implementations. A survey indicated that most Go users prefer that nil slices and maps are marshaled as an empty JSON array or object by default.

• Case-insensitive unmarshaling: When unmarshaling, a JSON object member name is resolved to a Go struct field name using a case-insensitive match. This is a surprising default, a potential security vulnerability, and a performance limitation.

• Inconsistent calling of methods: Due to an implementation detail, MarshalJSON methods declared on a pointer receiver are inconsistently called by encoding/json. While regarded as a bug, this cannot be fixed as too many applications depend on the current behavior.

API deficiencies

The API of encoding/json can be tricky or restrictive:

• It is difficult to correctly unmarshal from an io.Reader. Users often write json.NewDecoder(r).Decode(v), which fails to reject trailing junk at the end of the input.
• Options can be set on the Encoder and Decoder types, but cannot be used with the Marshal and Unmarshal functions. Similarly, types implementing the Marshaler and Unmarshaler interfaces cannot make use of the options and there is no way to plumb options down the call stack. For example, the Decoder.DisallowUnknownFields option loses its effect when calling a custom UnmarshalJSON method.
• The Compact, Indent, and HTMLEscape functions write to a bytes.Buffer instead of something more flexible like a []byte or io.Writer. This limits the usability of those functions.

Performance limitations

Setting aside internal implementation details, the public API commits it to certain performance limitations:

• MarshalJSON: The MarshalJSON interface method forces the implementation to allocate the returned []byte. Also, the semantics require that encoding/json verify that the result is valid JSON and also to reformat it to match the specified indentation.
• UnmarshalJSON: The UnmarshalJSON interface method requires that a complete JSON value be provided (without any trailing data). This forces encoding/json to parse the JSON value to be unmarshaled in its entirety to determine where it ends before it can call UnmarshalJSON. Afterwards, the UnmarshalJSON method itself must parse the provided JSON value again.
• Lack of streaming: Even though the Encoder and Decoder types operate on an io.Writer or io.Reader, they buffer the entire JSON value in memory. The Decoder.Token method for reading individual tokens is allocation-heavy and there is no corresponding API for writing tokens.

Furthermore, if the implementation of a MarshalJSON or UnmarshalJSON method recursively calls the Marshal or Unmarshal function, then the performance becomes quadratic.

Trying to fix encoding/json directly

Introducing a new, incompatible major version of a package is a heavy consideration. If possible, we should try to fix the existing package.

While it is relatively easy to add new features, it is difficult to change existing features. Unfortunately, these problems are inherent consequences of the existing API, making them practically impossible to fix within the Go 1 compatibility promise.

We could in principle declare separate names, such as MarshalV2 or UnmarshalV2, but that is tantamount to creating a parallel namespace within the same package. This leads us to encoding/json/v2 (henceforth called v2), where we can make these changes within a separate v2 namespace in contrast to encoding/json (henceforth called v1).

Building on encoding/json/jsontext

Before discussing the v2 API, we first introduce the encoding/json/jsontext package that lays the foundation for improvements to JSON in Go.

JSON serialization in Go can be broken down into two primary components:

• syntactic functionality that is concerned with processing JSON based on its grammar, and
• semantic functionality that defines the relationship between JSON values and Go values.

We use the terms “encode” and “decode” to describe syntactic functionality and the terms “marshal” and “unmarshal” to describe semantic functionality. We aim to provide a clear distinction between functionality that is purely concerned with encoding versus that of marshaling.

This diagram provides an overview of this separation. Purple blocks represent types, while blue blocks represent functions or methods. The direction of the arrows approximately represents the flow of data. The bottom half of the diagram, implemented by the jsontext package, contains functionality that is only concerned with syntax, while the upper half, implemented by the json/v2 package, contains functionality that assigns semantic meaning to syntactic data handled by the bottom half.

The basic API of jsontext is the following:

package jsontext

type Encoder struct { ... }
func NewEncoder(io.Writer, ...Options) *Encoder
func (*Encoder) WriteValue(Value) error
func (*Encoder) WriteToken(Token) error

type Decoder struct { ... }
func NewDecoder(io.Reader, ...Options) *Decoder
func (*Decoder) ReadValue() (Value, error)
func (*Decoder) ReadToken() (Token, error)

type Kind byte
type Value []byte
func (Value) Kind() Kind
type Token struct { ... }
func (Token) Kind() Kind

The jsontext package provides functionality for interacting with JSON at a syntactic level and derives its name from RFC 8259, section 2 where the grammar for JSON data is literally called JSON-text. Since it only interacts with JSON at a syntactic level, it does not depend on Go reflection.

The Encoder and Decoder provide support for encoding and decoding JSON values and tokens. The constructors accept variadic options that affect the particular behavior of encoding and decoding. Unlike the Encoder and Decoder types declared in v1, the new types in jsontext avoid muddling the distinction between syntax and semantics and operate in a truly streaming manner.

A JSON value is a complete unit of data and is represented in Go as a named []byte. It is identical to RawMessage in v1, which is now a type alias to jsontext.Value. A JSON value is syntactically composed of one or more JSON tokens. A JSON token is represented in Go as the opaque Token type with constructors and accessor methods. It is analogous to Token in v1 but is designed represent arbitrary JSON tokens without allocation.

To resolve the fundamental performance problems with the MarshalJSON and UnmarshalJSON interface methods, we need an efficient way of encoding and decoding JSON as a streaming sequence of tokens and values. In v2, we introduce the MarshalJSONTo and UnmarshalJSONFrom interface methods that operate on an Encoder or Decoder, allowing the methods’ implementations to process JSON in a purely streaming manner. Thus, the json package need not be responsible for validating or formatting a JSON value returned by MarshalJSON, nor would it need to be responsible for determining the boundaries of a JSON value provided to UnmarshalJSON. These responsibilities belong to the Encoder and Decoder.

Introducing encoding/json/v2

Building on the jsontext package, we now introduce the encoding/json/v2 package. It is designed to fix the problems in v1, while remaining familiar to users of the v1 package. Our goal is that usages of v1 will operate mostly the same if directly migrated to v2.

Here, we primarily cover the high-level API of v2. For examples on how to use it, we encourage readers to study the examples in the v2 package, the “Working with JSON” tutorial, or read Anton Zhiyanov’s blog covering the topic.

The basic API of v2 is the following:

package json

func Marshal(in any, opts ...Options) (out []byte, err error)
func MarshalWrite(out io.Writer, in any, opts ...Options) error
func MarshalEncode(out *jsontext.Encoder, in any, opts ...Options) error

func Unmarshal(in []byte, out any, opts ...Options) error
func UnmarshalRead(in io.Reader, out any, opts ...Options) error
func UnmarshalDecode(in *jsontext.Decoder, out any, opts ...Options) error

The Marshal and Unmarshal functions have a signature similar to v1, but accept options to configure their behavior. The MarshalWrite and UnmarshalRead functions directly operate on an io.Writer or io.Reader, avoiding the need to temporarily construct an Encoder or Decoder just to write or read from such types. The MarshalEncode and UnmarshalDecode functions operate on a jsontext.Encoder and jsontext.Decoder and is actually the underlying implementation of the previously mentioned functions. Unlike v1, options are a first-class argument to each of the marshal and unmarshal functions, greatly extending the flexibility and configurability of v2. There are several options available in v2 which are not covered by this article.

Type-specified customization

Similar to v1, v2 allows types to define their own JSON representation by satisfying particular interfaces.

type Marshaler interface {
    MarshalJSON() ([]byte, error)
}
type MarshalerTo interface {
    MarshalJSONTo(*jsontext.Encoder) error
}

type Unmarshaler interface {
    UnmarshalJSON([]byte) error
}
type UnmarshalerFrom interface {
    UnmarshalJSONFrom(*jsontext.Decoder) error
}

The Marshaler and Unmarshaler interfaces are identical to those in v1. The new MarshalerTo and UnmarshalerFrom interfaces allow a type to represent itself as JSON using a jsontext.Encoder or jsontext.Decoder. This allows options to be forwarded down the call stack, since options can be retrieved via the Options accessor method on the Encoder or Decoder.

See the OrderedObject example for how to implement a custom type that maintains the ordering of JSON object members.

Caller-specified customization

In v2, the caller of Marshal and Unmarshal can also specify a custom JSON representation for any arbitrary type, where caller-specified functions take precedence over type-defined methods or the default representation for a particular type.

func WithMarshalers(*Marshalers) Options

type Marshalers struct { ... }
func MarshalFunc[T any](fn func(T) ([]byte, error)) *Marshalers
func MarshalToFunc[T any](fn func(*jsontext.Encoder, T) error) *Marshalers

func WithUnmarshalers(*Unmarshalers) Options

type Unmarshalers struct { ... }
func UnmarshalFunc[T any](fn func([]byte, T) error) *Unmarshalers
func UnmarshalFromFunc[T any](fn func(*jsontext.Decoder, T) error) *Unmarshalers

MarshalFunc and MarshalToFunc construct a custom marshaler that can be passed to a Marshal call using WithMarshalers to override the marshaling of particular types. Similarly, UnmarshalFunc and UnmarshalFromFunc support similar customization for Unmarshal.

The ProtoJSON example demonstrates how this feature allows serialization of all proto.Message types to be handled by the protojson package.

Behavior differences

While v2 aims to behave mostly the same as v1, its behavior has changed in some ways to address problems in v1, most notably:

• v2 reports an error in the presence of invalid UTF-8.
• v2 reports an error if a JSON object contains a duplicate name.
• v2 marshals a nil Go slice or Go map as an empty JSON array or JSON object, respectively.
• v2 unmarshals a JSON object into a Go struct using a case-sensitive match from the JSON member name to the Go field name.
• v2 redefines the omitempty tag option to omit a field if it would have encoded as an “empty” JSON value (which are null, "", [], and {}).
• v2 reports an error when trying to serialize a time.Duration, which currently has no default representation, but provides options to let the caller decide.

For most behavior changes, there is a struct tag option or caller-specified option that can configure the behavior to operate under v1 or v2 semantics, or even other caller-determined behavior. See “Migrating to v2” for more information.

Performance optimizations

The Marshal performance of v2 is roughly at parity with v1. Sometimes it is slightly faster, but other times it is slightly slower. The Unmarshal performance of v2 is significantly faster than v1, with benchmarks demonstrating improvements of up to 10x.

In order to obtain greater performance gains, existing implementations of Marshaler and Unmarshaler should migrate to also implement MarshalerTo and UnmarshalerFrom, so that they can benefit from processing JSON in a purely streaming manner. For example, recursive parsing of OpenAPI specifications in UnmarshalJSON methods significantly hurt performance in a particular service of Kubernetes (see kubernetes/kube-openapi#315), while switching to UnmarshalJSONFrom improved performance by orders of magnitude.

For more benchmark details, see the go-json-experiment/jsonbench repository.

On top of structural improvements, we’re continuing to invest in performance optimizations in the implementation for cases where the v2 implementation is slower than v1. You can expect additional improvements in Go 1.28.

Compatibility

The Go 1 compatibility promise is a core guarantee from the Go project that allows developers to build applications that will stand the test of time and continue working on future versions of Go.

The original encoding/json and new encoding/json/v2 packages are of course both subject to the Go 1 compatibility promise. Applications using v1 will continue to be supported indefinitely and need not ever migrate to v2.

That said, when designing the v2 packages we wanted to do better than keeping v1 supported. We wanted to ensure that v1 and v2 are compatible with one another so that packages using different versions can work together. Doing so allows a smooth ecosystem migration rather than forcing users to use one version or another due to the choices of their dependencies.

For instance, suppose your package uses v2 to marshal a struct containing a field with a type defined in another package. That package may use the original v1 MarshalJSON method to define its marshaling behavior. No problem, v2 supports MarshalJSON methods, so marshaling will continue working as expected.

Vice versa, suppose your package uses v1 to marshal the same struct. The other package may use the v2 MarshalJSONTo method for better performance. No problem here either, as the v1 implementation supports v2’s MarshalJSONTo method under the hood.

We’ve achieved this by designing the new packages such that, under the hood, v1 is implemented in terms of v2. As mentioned above, v2 supports a variety of Options. Each behavior difference is controlled by one of the these options. Thus, v1 can be implemented in terms of v2 by passing the full set of v1 compatibility options.

With this approach, backwards-compatible additions such as new methods (e.g., MarshalJSONTo) or new struct tags (e.g., embed) are automatically supported to the benefit of existing v1 users.

Migration

Implementing v1 in terms of v2 options has the additional benefit of allowing gradual migration of callsites.

encoding/json documents the full set of behavior differences between v1 and v2, and which option controls that behaviors.

Many applications can migrate directly to v2 with no visible behavior changes, but applications that depend on v1 behavior can use the options to change only the behaviors they depend on.

For example, we can select all v2 behavior except for allowing duplicate names:

json.Marshal(..., json.DefaultOptionsV2(), jsontext.AllowDuplicateName(true))

Alternatively, we can select all v1 behavior except for disallowing duplicate names:

json.Marshal(..., jsonv1.DefaultOptionsV1(), jsontext.AllowDuplicateName(false))

The encoding/json/v2 Migration Guide goes into more detail, covering a variety of scenarios for approaching migration of an application from v1 to v2.

More information

For additional references on working with the new JSON packages, see:

• The “Working with JSON” tutorial,
• The encoding/json/v2 and encoding/json/jsontext package documentation,
• The encoding/json package’s v2 comparison documentation,
• and the encoding/json/v2 Migration Guide.

A long time coming

The planning for a new major version of encoding/json spanned years. In late 2020, spurred on by the inability to fix issues in the current package, Daniel Martí (one of the maintainers of encoding/json) first drafted his thoughts on what a hypothetical v2 package should look like. Separately, after previous work on the Go API for Protocol Buffers, Joe Tsai was disappointed that the protojson package needed to use a custom JSON implementation because encoding/json was neither capable of adhering to the stricter JSON standard that the Protocol Buffer specification required, nor of efficiently serializing JSON in a streaming manner.

Believing a brighter future for JSON was both beneficial and achievable, Daniel and Joe joined forces to brainstorm on v2 and started to build a prototype (with the initial code being a polished version of the JSON serialization logic from the Go protobuf module). Over time, a few others (Roger Peppe, Chris Hines, Johan Brandhorst-Satzkorn, Damien Neil, Austin Clements, and Michael Pratt) joined the effort by providing design review, code review, and regression testing. Many of the early discussions are publicly available in our recorded meetings and meeting notes. Later discussions are available in our encoding/json/v2 working group meeting notes.

This work has been public since the beginning, and we increasingly involved the wider Go community, first with a GopherCon talk and discussion posted in late 2023, formal proposal posted in early 2025, and finally adopting encoding/json/v2 as a Go experiment in Go 1.25 for wider-scale testing by all Go users.

The v2 effort took about 6 years to reach this point, incorporating feedback from many contributors and also gaining valuable empirical experience from use in production settings.

It’s worth noting that it’s largely been developed and promoted by people not employed by Google, demonstrating that the Go project is a collaborative endeavor with a thriving global community dedicated to improving the Go ecosystem.

Thank you to everyone that contributed!

(Sorry, I couldn't resist not putting a catchy title :)

Prompted by another project idea that popped into my mind, I did some Unix archaeology and looked at the original sources. This is the most fun I've ever had reading someone else's code - probably due to the historical significance. But also because of how delightfully approachable it was, compared to modern monstrocities.

This is a short(-ish) post regarding how they handled the mundane and boring task of allocating and managing memory (in C). In the future I'd like to read more about Unix the OS, its design, architecture & implementation.

A long time ago...

In a PDP far, far away, our journey begins with the fourth edition of Unix, released November '73, more than half a century ago. C actually first appeared in the second edition, released the year before, but wasn't extensively used. V4 is special because even the majority of the kernel was written in (let's call it "medieval") C by that point. The system had grown, however, and it was quite capable. You'll find that many Unix things we have today in POSIX-land were already present in V4.

Super fun fact: A tape containing V4 was only found last year! Previously, it was thought to be completely lost to time.

Magnetic tape of UNIX v4 from Bell Labs, circa 1973

While cleaning a storage room, our staff found this tape containing UNIX v4 from Bell Labs, circa 1973

~ Rob Ricci

Linear allocation

The first interesting bit is found among the C "compiler" sources. In quotes, because it wasn't a monolithic compiler as we know it today. Rather, it was a set of distinct tools which you chained in order to get an object file from C code.

In /usr/c/c20.c:814, from what I can gather a very primitive optimiser, if you will (referred to as "C object code improver" in V5; there aren't many comments in V4) you see:

alloc(an)
{
    register int n;
    register char *p;

    n = an;
    n++;
    n =& ~01;
    if (lasta+n >= lastr) {
        if (sbrk(2000) == -1) {
            write(2, "Out of space\n", 14);
            exit(1);
        }
        lastr =+ 2000;
    }
    p = lasta;
    lasta =+ n;
    return(p);
}

Isn't that fascinating? This routine is used throughout the program to allocate memory. And if you squint, this is just a linear allocator. It aligns the size, checks if the region is big enough, otherwise tries to extend it. On failure, it just cold-exits. Which means callers don't have to check for NULL every single time, and indeed they do not.

The "region" isn't named, unlike how you'd do it today with arenas. However, the above does have a nice property, in that by using sbrk(), when we extend the heap, no pointer is invalidated.

And they don't bother freeing memory, because why would they? There's no need. Everything exists for the lifetime of the program.

dmr/malloc

This is the most interesting bit in my opinion, and the reason why I chose that title.

In Dennis' directory, you find a file named malloc.c. And you see two functions there:

struct map {
    char *m_size;
    char *m_addr;
};

malloc(mp, size)
struct map *mp;

mfree(mp, size, aa)
struct map *mp;

Seems familiar? Yep, it's mfree() with an m. These functions obviously deal with memory (de)allocation, and are the precursor to the ones we're familiar with today. But, the interfaces are different.

malloc() receives an additional first argument called mp (for "map"), and so does mfree(). What is that? Well, let's see how they're used:

p = malloc(coremap, sizeof foo);
...
mfree(coremap, sizeof foo, p);

q = malloc(swapmap, sizeof bar);
...
mfree(swapmap, sizeof bar, q);

So, they pass in some objects coremap and swapmap. What are those?
From /usr/sys/systm.h:2:

int	coremap[CMAPSIZ];
int	swapmap[SMAPSIZ];

They're just flat memory regions! So these malloc() and mfree() work on explicit memory regions! Not only that, mfree() receives the size of the object it is deallocating, as it should. Those are just infinitely-times better interfaces than traditional malloc()/free().

Imagine using a library that has such an interface. You could deallocate all its memory resources by just discarding the entire region you delegated to it. Heap corruption bugs would be less severe because you could partition memory. You could trivially limit the amount of memory third party code allocates. The list goes on and on...

(Side note: They slightly messed up here and the regions should've been sized CMAPSIZ/2 and SMAPSIZ/2 respectively. They did fix that later.)

However, I don't think all these benefits were in the minds of Dennis and Ken. So why did they go with that interface and why did they partition memory to "core" and "swap"? The reason is, I believe, just hardware constraints. These interfaces stay like that up to V6 (maybe V7 too?), released the spring of '75, and thankfully there's an infamously good resource about that edition.

Brian Kernighan holding a copy of Lions's Commentary

Brian Kernighan, from Wikipedia.

From A Commentary on the Sixth Edition UNIX Operating System by John Lions:

These are concerned with the allocation and subsequent release of two kinds of memory resources, namely:

• main memory in units of 32 words (64 bytes);
• disk swap area in units of 256 words (512 bytes).

For each of these two kinds of resource, a list of available areas is maintained within a resource "map" (either "coremap" or "swapmap"). A pointer to the appropriate resource "map" is always passed to "malloc" and "mfree" so that the routines themselves do not have to know the kind of resource with which they are dealing.

And it goes on to explain how the underlying allocation algorithm works. These do not do linear allocation (hence the mfree()). Basically, it's a list of blocks (struct map), ordered by address, where you do first-fit and also coalesce neighbour blocks.

The sixth edition is also the first where the term "arena" appears, in /usr/source/s4/alloc.s:17:

/char *allocs[2] {		/*initial empty arena*/

Rolling back

... to the topic of linear allocation... In V6's /usr/source/s1/diff1.c:88, I think the first ever version of diff(1), you find:

char *area;
char *top;
alloc(n)
{
    register char *p;
    p = area;
    n = (n+1) & ~1;
    area =+ n;
    while(area > top) {
        if(sbrk(1024) == -1) {
            mesg("Out of space\n");
            exit(1);
        }
        top =+ 1024;
    }
    return(p);
}

This is not all that much different from the previous alloc(), but this time it handles any allocation size. It uses a while to continue extending the region and stops when enough space has been reserved. The actual interesting part happens later, at unsort():143:

unsort(f, l, b)
struct line *f;
int *b;
{
    int *a;
    int i;
    a = alloc((l+1)*sizeof(a[0]));
    for(i=1;i<=l;i++)
        a[f[i].serial] = f[i].value;
    for(i=1;i<=l;i++)
        b[i] = a[i];
    area = a;
}

I'm not exactly sure what that function does, but it doesn't matter. What matters is that they allocate some memory (a = alloc(...);), then roll back the region (area = a;)! Though they subsequently just copy it to b, so it seems like this was redundant.

Computing sizes

Most of the code directly calls malloc()/alloc() and friends, and inlines the size computation logic. Like the line we saw earlier:

a = alloc((l+1)*sizeof(a[0]));

I don't do that anymore, and neither should you! I use a couple macros akin to C++'s new that handle all the sizeof business. But I am a dumb-dumb. Surely these guys must've come across the same pain points, and, if so, what did they do? Let's jump to V7, released January '79, four years after V6. You find this macro:

#define ALLOC(x) (struct x *) ckalloc(sizeof(struct x))

where they use it like:

struct foo { ... };
p = ALLOC(foo);

Nice! It's interesting to note where you find it; In /usr/src/cmd/f77/defines:38 and /usr/src/cmd/make/defs:38. Slightly suspicious. The former is part of the Fortran 77 compiler and latter of make. Stuart Feldman is the person who worked on both of those programs! It's clear that multiple people were working on the system at that time. A macro like that isn't used in any other program, sadly.

V7 is the first edition where you also find the assert() macro, and it was used extensively back then too. Good job! They also significantly expanded the number of man pages. Fun fact: I did $ man V7/usr/man/man3/foo.3 -- on 47 year old pages -- and it worked first try absolutely fine.

Let's go to V8, released in February '85, four years before the first C standard. You find this wild macro in /usr/src/cmd/ideal/memut.c:7:

char *fooalloc;
#define	tryalloc(new,kind)	\
    if (!(new =(kind *) malloc(sizeof (kind)))) {\
    emergency ();\
    if (!(new =(kind *) malloc(sizeof (kind)))) {\
        fprintf (stderr, "ideal: Out of space\n");\
        exit (1);\
        }\
    };\
    for (fooalloc = (char *) new;\
        fooalloc < ((char *) new) + sizeof (kind);\
        fooalloc ++)\
        *fooalloc = '\0';

If someone is too harsh because you used macros, point them at the above. Usage is bit different this time:

struct foo *x;
tryalloc(x, struct foo);

I decided to include it because the macro zero-initialises by default whatever was allocated! You also see a more familiar-looking malloc() being used. It appears this is the edition that they switched to the more traditional malloc()/free() interfaces we know. I'll hypothesize why that is at the very end.

But it gets even more interesting. In V8 you also find these macros:

#define new(type) ((type *) alloc (sizeof (type)))
#define new(t) ((t *) alloc (sizeof (t)))
#define        new(s)  (s *)alloc(sizeof (s))

When I saw these definitions I jumped out of my chair. It's basically how I'd define it too! You'll find them in:

• /usr/src/cmd/finddev.c:245, part of finddev(8).
• /usr/src/cmd/asd/asd.h:13, part of asd(8).
• /usr/include/ic.h:55, part of *checks notes* I have no idea.

respectively.

Unfortunately, I can't find the author(s) of any of these.

Cfront

In V8, you'll also find Cfront, a.k.a. medieval C++. It's then reasonable to assume that Stroustrup was inspired by the above macros and decided to incorporate new as a language-level feature. However, in A History of C++: 1979−1991, he writes:

In Simula, it is not possible to have local or global variables of class types; that is, every object of a class must be allocated on the free store using the new operator.

Huh. So C++'s new was inspired by the programming language "Simula". It's fair to say that the macros above were likely also derived from there. But Simula was quite old even by the 70s, let alone 1985. Perhaps Stroustrup persuaded people, or wrote those macros himself. He later writes:

The new operator that both allocates memory from the free store and invokes a constructor to ensure initialization was borrowed from Simula. The delete operator was a necessary complement because I did not want C with Classes to depend on a garbage collector. The argument for the new operator can be summarized like this. Would you rather write:

X* p = new X(2);

or

struct X * p = (struct X *) malloc(sizeof(struct X));
if (p == 0) error("memory exhausted");
p−>init(2);

and which version are you most likely to make a mistake in? The arguments against -- which were voiced quite a lot at the time -- were "but we don’t really need it," and "but someone will have used new as an identifier." Both observations are correct, of course. Introducing operator new thus made the use of free store more convenient and less error−prone. This increased its use even further so that the C free store allocation routine malloc() used to implement new became the most common performance bottleneck in real systems. [...] Having real programs spend 50% or more of their time in malloc() wasn’t acceptable.

(emphasis mine :P)

He makes a compelling argument, which I agree with, but doesn't mention the new() macros that basically did the same thing. Although you'll find many programs in V8 that do the latter, verbose thing. Now I want to know the author(s) of those macros even more!

Sims

This is a big parentheses because I wanted to know how Simula came up with new. Wikipedia states:

Simula 67 introduced objects, classes, inheritance and subclasses, virtual procedures, coroutines, and discrete event simulation, and featured garbage collection.

And it appeared in 1967. Wow! In the 1964 report of SIMULA I, you'll find:

[...] The symbol "new" only serves to resolve an ambiguity of the identifier A inside the activity blah blah blah [...]. Elsewhere the symbol new is redundant, but can often be used to advantage to improve readability.

So it was only used to resolve grammar ambiguities (I think?). And Stroustrup re-purposed it. Clever!

Further reading

The History of Simula, by Jan Rune Holmevik. Reads like (bad) Sci-Fi. All the politics nonsense aside, what I found most curious is that they completely specified the language before attempting to write a compiler for it. They started writing the first compiler atleast a year after. This would sound insane today, but I guess the cost of writing code was substantially higher back then.

Also: The development of the SIMULA languages, by the authors. I didn't read that one, although I should...

It's honestly amazing how influential Simula was. In "10.5 Operating Instruction" they even use the term "run time system" and give it the same meaning we're accustomed to.

Simula, in turn, was partly inspired by SIMSCRIPT (don't laugh). If you skim its 1962 report, you won't find a mention of new. You'll however find CREATE:

When a new Entity is created by a CREATE statement, space for storing its Attribute values is allocated in the amount specified on the Definition Form. This record is given an identification number, and the Variable specified in the CREATE statement is automatically set equal to this number.

For example, the statement "CREATE DOG CALLED FIDO" allocates the required amount of storage for the Attributes of a DOG, and sets FIDO equal to the identification number of the Attribute record.

Fascinating. The whole SIMSCRIPT report is fascinating actually, and I only briefly skimmed through it. At the beginning, it even describes something like a primitive ECS, by my understanding. At the end though it slaps you back to reality:

COMPILATION AND EXECUTION - SIMSCRIPT

COMPILATION AND EXECUTION - SIMSCRIPT

and you remember what year it was.

Later editions

In V9's /jtools/src/sam/sam.h:14, part of the Sam editor by Rob Pike, you find a "generalised" version of new():

#define    new(t, n)       ((t *)alloc(((ulong)(n)*sizeof(t))))

Although, by and large, almost every program doesn't do this. Most just directly call malloc() and friends, and do size calculations \w error checking at every call site. I don't know why, considering how much error-prone that is, but maybe due to inertia. It's a similar story in V10, but I didn't check it as thoroughly since it's quite big (it includes medieval GCC!).

So what happened?

They were so close to arenas; with linear allocation and explicit memory regions, rolling back, and even having a nice new() macro. All this is speculation at this point, but maybe some of it is correct. First of all, most programs had trivial object lifetimes. Allocate memory, read some data, process/crunch and spit out some result. You don't need any disciplined memory allocation strategy for that. You can even use malloc() for everything and let the OS reclaim it once the process exits. Given how simple malloc() was at first, it wouldn't be much of a bottleneck either. The philosophy of programs only "doing a single thing well" also fitted this pattern.

Secondly, it's clear some decisions were motivated by the very little memory they had to play with. And there was no virtual memory either (initially, that is). Nowadays, you can "allocate" however big of a memory region you want and all will probably be okay. They couldn't really do that, so they were fighting to reclaim every empty block and gap there was and scale a program's space with how much is actually needed. There's a counterpoint to this, however, because some code is confused. Sometimes you see fixed-size buffers/arrays pop up, seemingly out of nowhere, and the program bail out if they fill. I'm not sure why, but perhaps they didn't deem it worthwhile the complexity to use malloc() in those cases and/or "don't fix it if it ain't broke" kind-of thing.

And clearly, when they could get away with simple linear allocation, they did so.

Thirdly, I suspect they had grown tired of doing any manual memory management at all. Dropping explicit memory regions from the malloc() interface is a change that, on the surface, simplifies stuff even further. You make the implementation-side smarter and you don't have to worry about passing coremap or swapmap or anymap. Remember: the way programs and problems were approached didn't lead to complex object lifetimes. And when you had to deal with tangled lifetimes, malloc()/free() appear deceivably simple in the beginning.

That last point seems more "vibes" than evidence, but there is some evidence actually. In V7 they added galloc(3):

GALLOC(3)                                               GALLOC(3)

NAME
     galloc, gfree, garbage - storage allocation with garbage
     collection

SYNOPSIS
     char *galloc(n)
     unsigned n;

     gfree(p)
     char *p;

     garbage( )

DESCRIPTION
     These functions perform heap storage allocation with garbage
     collection.

     Galloc allocates a block of at least n bytes and returns a
     pointer to it.  Gfree frees a block previously allocated by
     galloc.

     When space gets tight, garbage blocks are freed automati-
     cally.  A block allocated by galloc is deemed to be garbage
     unless it is reachable.  A reachable block is one whose
     first byte is pointed to by a declared C variable or by a
     pointer in a reachable block.

and Rob Pike had this in /jtools/src/sam/sam.h:15:

#define    gcnew(p, n)     ((void)gcalloc((ulong)(n)*sizeof((p)[0]), (long **)&(p)))

Ha, myth busted! The authors and people closest to C wanted garbage collection. Given how fast computers are -- and the pace of that -- this makes sense. It's even clearer if you look at what they did later with Limbo and Go. They wanted a higher level general purpose language to write programs in. They had C, so they tried to bolt GC on top of that.

Lastly, I should note that many of these problems were largely known, even at the time. In The Standard C library (1992), P. J. Plauger writes:

Allocating and freeing data objects on the heap in arbitrary order inevitably leaves unusable holes between some of the allocated data objects. That too lowers the usable size of the heap.

Don't overreact to this knowledge. Gather related data into a structure and allocate it all at once. That minimizes heap overhead, to be sure, but it is also good programming style. Do not gather unrelated data just to save heap overhead. Similarly, allocate data objects with similar lifetimes all at once, then free them at about the same time. That minimizes heap fragmentation, but it too is good style. Do not advance or defer unrelated heap operations just to minimize fragmentation. The storage allocation functions are an important aid to programming flexibility. Use them as they are intended to be used.

Criticism by yours truly: It's much easier to say "just do the right thing™" than show and provide tools for how to actually do it.

Conclusion

I don't know. Pay attention to good ideas, otherwise they might get lost? (literally in the case of V4, lol) Sounds cheesy.

Also, the "C object code improver" shatters the illusion that C was somehow magically fast. In fact, Ritchie later added an expression optimiser, and they kept extending both in each edition. I think C just wasn't slow, and it was made fast only with engineering effort put into the compiler (and even then, they had to add register because the compiler wasn't that smart either). It probably remained fast because Unix spread quickly and it carried C along with it, so hardware manufacturers adapted to C. There's a nice essay by Mike Pall discussing how modern CPUs try very hard to infer invariants from compiled C code (which the compiler tried very hard to optimise) and the costs associated with that.

At one point, I also want to investigate Inferno and Plan 9 more. Maybe the BSDs too. Until then...

Cya!

~/V8$ grep -Rn <redacted> .

./usr/src/cmd/c2/c21.c:660:			if (p->op==ASH && preg==(regs+RT1+1)) cp2[-1]=BYTE; /* stupid DEC */
./usr/src/cmd/c2/c22.c:11:/* cursed be the preprocessor, whose impotence and stupidity
./usr/src/cmd/adb/main.c:16:int xargc;		/* bullshit */
./usr/src/cmd/ccom/vax/gencode.c:644:	case LS:	/* stupid vax */
./usr/src/cmd/ccom/vax/gencode.c:664:		if(incrsize(p) != 4) {	/* stupid vax */
./usr/src/cmd/ccom/vax/gencode.c:705:		 * instead, generate crummy code (stupid assembler)
./usr/src/cmd/ccom/vax/genaux.c:598:	op->in.op -= (ASG 0);	/* crap for crap */
./usr/src/cmd/ex/ex.c:352:		 * Don't have to be upward compatible with stupidity
./usr/src/cmd/ex/exrecover.c:492:		 * This is old and stupid code, which
./usr/src/cmd/ex/ex_put.c:965: * This is so idiots who make esc their start/stop don't lose.
./usr/src/cmd/upas/send/send.c:288:	/* check forwarding (what anti-social crap!) */
./usr/src/cmd/uucp/Makefile:2:# this makefile is full of crap
./usr/src/cmd/rarepl/rct.h:2: * first block of rct: random crap
./usr/src/cmd/sdb/machine.h:16:struct {short hiword; short loword;}; /* stupid fp-11 */
./usr/src/libc/gen/regcomp.c:26:/* predeclared crap */
./usr/sys/dev/uda.c:951:	register u_short *sp;		/* for sdi crap */
./usr/sys/dev/uda.c:1123:		 * should do read-after-write crap
./usr/sys/dev/flp.c:206:		/* We're really stupid today - call it an
./usr/sys/dev/kmc.c:9:	/* nonstandard crap */
./usr/sys/dev/vaxcpu.c:36:	/* Information to patch around the stupidity of configuration */
./usr/sys/sys/sys1.c:488:		else	/* stupid 1k 0413 files */
./usr/sys/sys/vmproc.c:238:		/* when large procs stupidly fork() instead of vfork(). */
./usr/sys/boot/bb/bblock.s:117:		movl	r5,r11		# put boot flags in stupid bky place
./usr/sys/boot/bb/bblock.s:118:		movzbl	$DEVNUM,r10		# more berkeley bullshit - 7 == uda50
./usr/sys/boot/bb/1k.s:2:	.set	DEVNUM, 8	# stupid hack

(Kindly let me know if I made some mistake :)

When we were kids, my brother Patrick and I would steer our space fighter with one of us on controls and the other on the lasers and afterburner boost. We always dreamed of playing the Wing Commander series cooperatively as wingmates rather than as a two headed hydra in a single craft.

In the beginning we were searching for where we were

On October 4, 2015 as I was playing the classic Wing Commander in Dosbox I realized the whole memory probably fit in that 640K Bill Gates apocryphally said “ought to be enough for anybody”. If I could dump the memory and identify the locations that held the X,Y,Z coords for the player & wingman we could let the network packets control the wingman.

The actual quote

“I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64 K to 640 K felt like something that would last a great deal of time. Well, it didn't.” Source

Here is a breakdown of the megabyte of addressable DOS memory and the 64K data segment where Wing Commander puts its game state.

This presented a clear problem to attack: out of fewer than a million bytes how would we identify that location? I decided to simplify the problem by trying to empty the game of other entities. A stopped player shouldn’t change coordinates. We could snapshot the memory twice when stopped to identify “background” memory churn. Then burst forward and measure again. If we didn’t turn (mouse was disabled) we might only change one axis. The next problem was to find an empty region of space. We had to start without our wingman Paladin, since he would move with us. After a miserable mission, letting the nefarious space cats overwhelm Paladin and running back to the spacecraft carrier, the Claw, the next mission was primed for a flight through empty space. I launched and flew directly ahead until everything despawned and took the memory snapshots using the DOSBox MEMDUMPBIN debug-command.

Hornet cockpit on launch, the right VDU showing Auto Targetting, Target: None

The Hornet cockpit on launch, where the VDU confirms an empty patch of space with nothing to target.

Now I had to discover anything that had not changed between the memory snapshots where my star fighter was in the original position but things that had changed when my star fighter moved.

(snapshotorigin ⊙ snapshotlater) ∧ (snapshotorigin ⊕ snapshotmoved)

253 bytes churn when stopped, and 650 change during a move. 413 do both. By cross referencing with the chase cam, the total is only 132 bytes.

There were 35 distinct clusters of bytes that changed in the data segment. By inspecting these visually and looking for floats or small integer changes when I moved, I narrowed it down to a dozen locations it could be. I went to the chase camera view as well, and this helped to narrow it down to 13D3:A9C2. I had the DOSBox debugger add integers at that address with its SM command and that caused the ship to jolt forward to a new location.

This technique identified velocity as well at CAE2, since thre were three 32 bit ints that zeroed out when the craft was stopped.

The 64K data segment of the October 2015 dumps, one byte per pixel, with the candidate rows labelled: position at A9C2 and its camera copy at AC9E, set speed at B9F6, velocity at CAE2 and CDBE, the stack

Craft position, camera position, set speed and velocity changes lit up in yellow

I had fun driving my ship around with the memory editor and reproduced it around the Claw and other NPC ships.

Then we searched for what we faced

I set it down for nearly a year but in September 2016 I decided to write a small tool to automatically compare DOSBox snapshots instead of using the vbindiff GUI only. Directionality turned out to be more difficult so I set down the problem for a few more months and picked it back up in November.

The original 2016 diff image of a megabyte, rotated to a strip: a single bright band near the data segment and a noisy block near the EMS page frame

Diff of two DOSBox memory dumps from turning. The bright band is the data segment.

In the 64 slot arrays, each slot is 12 bytes. Slot 0 is the player, 0x3D is the camera and 0x3F is a temporary slot. The camera copy caused each value to appear twice 0x2DC bytes apart.

To find the memory location of the rotation, I needed to look harder. As it happened the vectors were made of 4 byte scalars with 256 as 1.0 and valid positive vector positions between 0 and 255. This meant that most small rotations only changed a single byte. However, fortune was smiling on me that day because of what appeared to be a programmer joke at the time. Wing Commander reserved 64 slots for entity properties. In hex this would span numbers from 0x00 to 0x3F. However the programmers decided to use 0x3F for temporary usages and place the camera in 0x3D. Since 3D graphics were still nascent, the programmers may have thought it a good laugh to write 0x3D every time they needed to manipulate the 3D camera. That put a temporary variable two slots from the camera variable. And up and forward were also next to one another. This gave a nice wide region where I could locate those single byte changes. The first byte I understood was the y of the right vector; the print window I put around it happened to cover the camera's copy of up, which is where the overwrite experiment started. Furthermore, I rolled the ship over, and tripped sign extension, which caused all 3 adjacent bytes to switch from 0x00 to 0xff. Between these two facts, I noticed the temporary and camera bytes in the hex dumps. Writing to them did not help, since they were overwritten every frame, but luckily I wrote some extra bytes to the next vector as well, which was forward[0]. This caused a noticeable shift in the starfield and meant that I could now start investigating the code.

Annotated picture of changed bytes for a stopped versus yawed pair from the advanalysis dumps, with arrows to the same arrays

Yaw from level flight where forward[0] has a 9 byte change and up[0] changed from 00 01 to 7E 00.

I put memory watchpoints on the addresses and traced the vector-add function called by the per-ship physics function called by a per-frame function and eventually the main loop.

Call stack after memory watchpoint.

It was now time to locate the byte sequences in IDA and start annotating the game. Wing Commander Multiplayer was now just a matter of repeating these techniques and figuring out how to puppeteer one ship from another's input.

Then we searched for how to act

December 2016 had shattered my illusion that we would be able to drive Wing Commander with writes to global memory alone. The details of manifesting laser fire or heat seekers were far too complicated to puppeteer solely from the addresses. We would need to co-opt the very functions in the original game to get the most accurate experience. One initial thought was to “will” the program counter to the right place, but we would need a way to insert arguments and return back from whence we came. Moreover, many of the functions were in various overlays that required indirection to invoke. It appears that Borland had a different overlay per compilation unit (C++ file) and they were dynamically loaded in different locations depending on the path the player took beforehand.

Borland overlays: table of jmp far thunks.

Patrick and I had to figure out a good trampoline system to call functions with the correct arguments. We chose the “Loading WING COMMANDER” string at 13D3:0187 and eventually 13D3:0395 “Sorry, an error has occured while %s”[sic] to hold the trampoline.

We would have DOSBox push CS:IP to the stack, then relocate the instruction pointer to the string above.

00			terminates any string pointing here.
pushf; pusha		the game is mid-frame; leave registers as we found them
xor si,si; push si	argument: ship 0. Later thunks use mov si,imm16 for each argument
call far 12D7:0156	through the stub, so it works wherever the overlay is loaded
pop si; popa; popf	cdecl: caller cleans the arguments
retf			back to the CS:IP DOSBox pushed

We noted with joy that this caused the laser cannons to activate.

DOSBox pushes CS:IP, writes the thunk over the dead string, points CS:IP at it, and the thunk's retf lands back where the game left off.

In March of 2017, we found a predictable location in the main loop (0560:20E3) to hook so we would not need to worry about being in an unpredictable part of the game, and in July we located the do_damage function and prevented the game from calling it as the secondary player.

Then we tried to bring together fields from afar

In August of 2017, we authored the networking protocol which was a simple TCP client/server architecture with protobuf game messages. Every frame every ship's position would be sent from the leader plus fire events, despawning and damages. The client would reply with its own position, if any lasers were fired or if some cataclysmic event had happened (ejection, landed, died).

Each player would have their own craft as entity 0 and the other player as entity 1, which required a swap when receiving packets from the other emulator.

Positions sent every frame; events go into the per-frame job queue.

These packets modified memory directly or were added to a job queue of events that had to happen that frame.

We started with a very simple trampoline:

pushf
pusha
nop
popa
popf
retf

When Borland's overlay loader swaps a code page in, it walks the chain of saved BP frames on the stack and patches any return address that points into an overlay. The hand-made stub had no frame, so the walk read garbage and the game died at random moments. This was a constant thorn in our side from October to December.

The fix was to make the trampoline look like a Borland function:

push bp
mov bp, sp
nop (0x90) ; welcome to the 0x90's
pop bp
retf

A proper Borland frame around a 0x90 nop, which DOSBox monitors to inject the next queued call. The retf lands directly on the nop again until the queue empties out.

We configured DOSBox to notice when the program counter reached the nop and instead inject its call from the job queue of things that should happen in a multiplayer scenario. The job queue was based on what was necessary to make the game function correctly.

In October 2017 we noticed that ephemeral objects would be located in different slots for different players. Having the new hook from DOSBox also let us determine when the function had returned, so we could note down which numeric slot a new ship or projectile had been spawned into.

Ephemeral objects had their own spawn rules and could occupy shared areas of the 61 entity slots. We modified the location that ephemeral objects were placed in so we could confine them to slots 12 to 15 and keep multiplayer locations consistent.

In December we decided to change the client to store a mapping of server ship IDs to local IDs, so we could stop forcing the spawn function return. This allowed packets to translate between local and host IDs. Finally asteroids started to work in multiplayer.

The same ships can appear in different slots on two machines.

In 2018 we focused on animating explosions, missiles, and autopilot.

The search continued for both success and defeat

In June of 2019 we noted the mission victory calculation was flaky and finicky. We decided to conduct a binary search to find the location of the actual victory point tally. We copied the entire 64K data segment across the network, and slowly cut it in half. After many bisections, we located 80 bytes at 13D3:D248 which held the mission tree. And in October we found the overall victory point counter at 13D3:C280 and mission numbers at 13D3:C255 and C256, which allowed us to select the mission to play from a dropdown, years later.

Bisection of the data segment down to 80 bytes.

And finally the joy of combined words

In early 2020, we identified the function that played comm text. This allowed us to send chat over the network and hook typed chat directly into the system so it played using the wingman's VDU. It allowed a very immersive way to chat that reminded us of some of the frenetic sequences in the game.

Two browsers side by side: Maverick's cockpit shows ANGEL: You perform your duty well, mon capitaine; Angel's cockpit shows Maverick: there's one for the chalkboard!

Both pilots typing, sending messages to the other.

Some final work in 2020 left the game in a playable state, but we were out of ideas on how to actually share the fun with friends. Expecting people to locate a copy of that old game, compile or download a strange version of DOSBox, share each other's public IPs and punch the firewalls and play together was sadly a bridge too far.

We had a few family playthroughs but the game rested on GitHub, mostly idle.

Wing Commander Multiplayer discovery timeline.

And in 2026, machine assisted development helped us laugh together

Until now. With the advent of widespread WebRTC, robust emscripten support, and a new system we put together called lobbylink, the time seemed right to revive the project and share it more widely.

lobbylink

I built https://github.com/danielrh/lobbylink which is a simple golang lobby system, depending only on a websocket library, that orchestrates peer to peer WebRTC connections. It can run on any small server and simply allows players to connect to one another using WebRTC and a shared room code. The server has a static allowlist of origins and can let browsers or client software in almost any language connect to it with a room code. The room code is used to locate other players with the same room code and they get notified of all joiners in that room. The server also runs coturn and mints TURN credentials in its joined reply, so players behind restrictive firewalls can join.

The lobby allows people with the same room code to communicate directly with one another using WebRTC. TURN relay helps establish connections when nothing else is an option.

Room code join steps.

I ported over the transport to lobbylink and asked an LLM to configure the build scripts to target emscripten and take a GOG Inno Setup installer package of Wing Commander and unzip it and use it as data files for emscripten. The combination of these makes it possible to download Wing Commander from GOG, drag and drop it into the client-side browser storage, enter a room code, and play.

The game is playable at https://fireflyk64.github.io/dosbox/ and the emulator is at https://github.com/danielrh/wcmulti.

And as an added bonus I asked an LLM to add voice chat as well for realtime voice in game using a second WebRTC peer connection to carry audio, if people choose. And so we can fly and laugh together.

1. Model Introduction

Kimi K3.1 Pro is an open-weight, natively multimodal agentic model, and our most capable 3T-class model to date. Post-trained from Kimi K3 with large-scale joint reinforcement learning across hundreds of downstream domains, it is the first model in the K3.1 series. With a 1-million-token context window, Kimi K3.1 Pro delivers substantial improvements in coding, 3D creation, financial research, factual accuracy, and other agentic capabilities.

2. Model Summary

Architecture Mixture-of-Experts (MoE) Total Parameters 2.8T Activated Parameters 104B Number of Layers 93 Number of Dense Layers 1 Attention-Layer Composition 69 KDA + 24 Gated DSA* Attention Hidden Dimension 7168 Number of Attention Heads 96 DSA Index Head Dimension 128 DSA Index Number of Heads 32 DSA Index Top-K 2048 Latent MoE Dimension 3584 MoE Hidden Dimension (per Expert) 3072 Number of Experts 896 Selected Experts per Token 16 Number of Shared Experts 2 Vocabulary Size 160K Context Length 1048576 Attention Mechanism KDA & Gated DSA Activation Function SiTU-GLU Vision Encoder MoonViT-V2 Parameters of Vision Encoder 401M Quantization MXFP4 weights / MXFP8 activations
(quantization-aware training) Modality Text, Image

* Compared with Kimi K3, we replace the full-attention Gated MLA layers with Gated DeepSeek Sparse Attention (Gated DSA) layers for more efficient long-context modeling.

3. Evaluation Results

Unless otherwise specified, all Kimi K3.1 Pro results use reasoning effort max, temperature = 1.0, and top-p = 0.95. A dash (—) means that the source table does not report a score. Higher scores are better except where the benchmark name explicitly states lower is better; Elo scores and other benchmark-specific metrics are not directly comparable with accuracy or pass-rate scores.

Benchmark Kimi K3.1 Pro
(max) Claude Fable 5.1
(max, w/ fallback) GPT-6 Astra
(max, w/ fallback) Claude Opus 5.5
(max, w/ fallback) DeepSeek-V4.1-Flash-1017
(max) GLM-5.3
(max) Coding Terminal-Bench 4.0 65.7 57.9 58.2 66.4 42.3 41.8 Terminal-Bench-Science 0.1 38.1 40.0 68.1 63.3 15.7 8.1 SWE Marathon v1.1 51.7 45.6 42.5 46.3 40.0 42.5 BenchCAD w/o tools 72.8 60.6 — 73.0 41.2 — BenchCAD w/ tools 92.7 92.6 95.9 96.2 81.6 — Program Bench 31.5 53.5 50.0 65.0 29.1 19.0 DeepSWE v1.1 75.5 67.4 74.1 74.2 77.0 66.9 PostTrain Bench v1.2 36.5 44.6 41.9 43.8 30.5 34.5 Kimi Code Bench 2.0 (Internal) 77.1 — — — 76.1 61.7 Kimi Code Bench 3.0 Long-horizon (Internal) 61.2 58.8 66.5 58.5 51.5 45.5 Agentic HLE-Full w/ tools 70.0 65.6 57.2 67.7 58.8 62.5 BrowseComp 92.1 — 91.5 90.8 — — BioMysteryBench 80.6 81.6 78.9 81.9 80.0 79.6 CharXiv (RQ) w/ python 93.4 92.7 92.8 93.8 85.6 — MMMU-Pro w/ python 90.0 88.4 87.8 89.8 82.5 — GDP.pdf w/ python 85.7 83.8 85.5 83.9 73.0 — ChartoGraphy w/ python 90.2 88.4 91.0 89.0 83.0 — BabyVision w/ python 95.4 95.1 96.6 97.7 92.5 — ZeroBench_main w/ python (pass@5) 63.0 59.0 58.0 61.0 51.0 — Agents' Last Exam (ALL) 43.2 — 41.8 42.6 37.7 26.2 Agents' Last Exam (CLI) 44.2 — 44.2 40.7 36.0 29.4 Automation Bench-AA 73.3 59.4 68.5 69.5 66.6 62.2 GDPval-AA v2.1 (Elo-score) 1846 1754 1573 1866 1746 1650 AA-Briefcase v1.1 (Elo-score) 1678 1672 1569 1803 1570 1507 APEX-Agents 69.4 68.6 64.7 73.5 69.8 56.6 OfficeQA Pro v2 64.4 54.5 54.4 62.2 40.4 31.1 OfficeQA Pro 67.4 68.6 66.2 — 62.4 58.6 Frontier Finance 58.6 60.8 45.0 56.7 54.5 57.5 Harvey Legal Agent 23.7 19.1 — — 21.0 — HANDBOOK.md 44.6 38.8 — 41.5 28.9 20.8 OSWorld V2.1 79.6 80.7 75.8 81.8 69.3 — Business Operation (Internal) 37.8 30.7 32.3 — 8.9 18.6 DECK-Arena (Internal, Elo-score) 1456 — 1423 1253 1231 1119 Design Bench (Internal, Elo-score) 957 — 1076 927 863 718 Kimi Hallu Bench Hard w/ tools (Internal, lower is better) 8.3 23.3 5.5 15.0 23.3 22.6 Reasoning & Knowledge & Multimodal GDP.pdf 34.6 27.6 34.2 30.6 17.2 11.2 HLE-Full 51.1 57.6 53.6 59.8 42.6 43.0* HLE-Diamond 39.4 55.1 65.8 60.9 21.6 25.1* GPQA-Diamond 94.2 93.7 96.1 93.9 92.2 91.7 CharXiv (RQ) 89.0 88.8 90.0 92.1 77.0 — MMMU-Pro 84.1 86.3 86.9 87.7 80.6 — ZeroBench_main (avg@5 / pass@5) 29.8 / 39.0 23.0 / 35.0 43.2 / 52.0 35.0 / 43.0 11.8 / 23.0 — PerceptionBench 68.3 63.0 77.6 72.1 47.7 — Kimi Hallu Bench w/o tools (Internal, lower is better) 5.4 11.4 4.2 6.8 13.1 14.8 Cyber Security ExploitBench 74.7 83.0 100 91.0 — 54.4 ExploitGym 20.7 30.4 42.4 34.5 — 15.0 xdev-bench-hard (Internal) 81.0 — — — 85.7 57.1

Evaluation Footnotes

Coding benchmarks

1. Terminal-Bench 4.0. Kimi K3.1 Pro is evaluated with the Claude Code harness. The DeepSeek-V4.1-Flash-1017 score is taken from its release blog. All remaining scores are the maximum values reported in model blog posts or on the official Terminal-Bench leaderboard.
2. Terminal-Bench-Science 0.1. Kimi K3.1 Pro is evaluated with Claude Code. Internal evaluation of DeepSeek-V4.1-Flash-1017 yields 9.3; the table instead reports 15.7 for the older DeepSeek-V4.1-Flash from the official leaderboard. All remaining scores are from the Terminal-Bench-Science leaderboard.
3. SWE-Marathon v1.1. Kimi K3.1 Pro and DeepSeek-V4.1-Flash-1017 are evaluated with Claude Code. Other scores are from the official leaderboard.
4. ProgramBench. The table reports binary scores: a task receives 1 if its ProgramBench score is at least 95%, and 0 otherwise. K3.1 Pro is evaluated with Claude Code. DeepSeek and GLM scores are taken from the DeepSeek release blog; remaining scores are from Vals AI.
5. DeepSWE v1.1. K3.1 Pro is evaluated with Claude Code. Other scores come from the respective technical reports for GPT-6 Astra, Claude Opus 5.5, Claude Fable 5.1, DeepSeek-V4.1-Flash-1017, and GLM-5.3.
6. PostTrainBench. K3.1 Pro and DeepSeek-V4.1-Flash-1017 are evaluated internally on v1.2 with Claude Code and H20 GPUs rather than H100 GPUs. For stable evaluation, all judge models use DeepSeek-V4.1-Flash-1017 at maximum effort, which best matched the official GPT-5.6-Terra (xhigh) judge in testing. Other scores are from the official leaderboard.
7. Kimi Code Bench 2.0 and Kimi Code Bench 3.0 Long-horizon. These are internal benchmarks. K3.1 Pro is evaluated with Claude Code; all other models use their maximum-effort setting. Proprietary-model testing may involve fallback behavior.
8. BenchCAD. Open models are evaluated on 1,000-case subsets randomly sampled from the 17,900-case Vision2Code dataset at maximum reasoning effort. With-tools results use Claude Code; without-tools results use single-shot generation with official prompts and scoring. Claude scores are from the Opus 5.5 System Card, and GPT-6 Astra's with-tools score is from its official report. GPT-6 Astra has no reported without-tools score.

Agentic benchmarks

1. BioMysteryBench. Uses the official v11 release, with Kimi K3 as judge. K3.1 Pro uses Kimi Code; GLM-5.3 and DeepSeek-V4.1-Flash-1017 use Claude Code; GPT-6 Astra uses Codex. Claude scores are from official system cards.
2. Agents' Last Exam. Uses the official v1.1 release, comprising 122 tasks, including 86 CLI tasks. Runs that bypass stated requirements receive zero. DeepSeek and Kimi are evaluated with Claude Code and Kimi Code, respectively; other results are from the official benchmark website.
3. OfficeQA Pro and OfficeQA Pro v2. GPT-6 Astra uses Codex; other models use Claude Code. Each task provides the complete PDF corpus as page images without machine-readable text. External-model trajectories that retrieve reference answers online receive zero for those tasks.
4. Frontier Finance. Evaluated with the official Finance Agent v2 harness.
5. HANDBOOK.md. Evaluated with the official OpenHands-based harness, using tasks from the benchmark's early open-source v1 release.
6. Harvey Legal Agent. Evaluated on 1,251 public tasks with Artificial Analysis's Stirrup harness. The reported score is the all-pass rate: the percentage of tasks passing every rubric criterion.
7. OSWorld V2.1. Kimi models use the Kimi Agent harness in the official OSWorld v2 repository. GPT-6 Astra's score is taken from Muse Wonder's technical report.
8. DECK-Arena and Design Bench. DECK-Arena evaluates presentation generation on real-world queries; Design Bench covers graphic design through direct and reference-image few-shot prompting. Both evaluate python-pptx, pptxjs, and Kimi's in-house DSL in a harness with integrated search and image generation. The automated grader is calibrated on more than 10,000 human judgments.
9. BrowseComp. Uses context compaction triggered at 200K tokens and a 500-step maximum. If the limit is reached, the agent is forced to answer before judging. All runs use temperature = 1.0 and top-p = 1.0.
10. GDPval-AA v2.1, AA-Briefcase v1.1, and AutomationBench-AA. Scores are cited from Artificial Analysis. APEX-Agents. Scores are cited from the official leaderboard.
11. Tool-augmented multimodal evaluations. GDP.pdf w/ python, ZeroBench w/ python, and ChartoGraphy w/ python are averaged over five runs; other multimodal benchmarks with Python are averaged over four. For GDP.pdf w/ python, each original PDF is sent to a sandbox for IPython processing. Responses are graded against each rubric criterion using Gemini-3.5-Flash at medium reasoning effort and the official judging prompt. The reported score is the task-macro mean rubric pass rate.

Reasoning, knowledge, and multimodal benchmarks

1. GDP.pdf. Each PDF is provided as page images resized to a longest edge of 1,152 pixels, interleaved with Docling-extracted text in page order. Responses are graded against each rubric criterion using Gemini-3.5-Flash Medium and the official judging prompt. The table reports the strict pass rate among fully scored responses. GLM-5.3 Max and DeepSeek-V4.1-Flash-1017 Max scores are cited from Artificial Analysis.
2. HLE-Full and HLE-Diamond. The full evaluation sets contain 2,500 and 1,000 questions, respectively. For scores marked *, accuracy is reported on the text-only subset.
3. Run counts. GDP.pdf, ZeroBench, and ChartoGraphy are averaged over five runs; other multimodal benchmarks are averaged over four.
4. MMMU-Pro. Evaluated using the official protocol, preserving the original input order and prepending images to the text input.
5. PerceptionBench. An in-house benchmark focused on atomic visual perception capabilities.
6. Kimi Hallucination Benchmark. Evaluates factual accuracy on an internal set of challenging, de-identified prompts drawn from practical work tasks. The table reports claim-level hallucination rates assessed by fact-checking agents.

Cybersecurity benchmarks

1. ExploitBench. K3.1 Pro is evaluated with the official harness under a 300-turn budget. The table reports the pass@5 maximum-capability score: for each environment, the best of five seeds is scored by capability flags reached out of 16; arbitrary code execution counts as all 16 capabilities. Comparison scores are from OpenAI, Anthropic, and GLM-5.3.
2. ExploitGym. K3.1 Pro is evaluated with Kimi Code under a six-hour wall-clock budget per task. GPT-6 Astra, Claude, and GLM comparison scores are taken from their respective official reports, with Claude results using the same six-hour budget.
3. xdev-bench-hard. K3.1 Pro is evaluated with Kimi Code; GLM-5.3 and DeepSeek-V4.1-Flash-1017 use Claude Code. The internal benchmark contains expert-curated, source-code-based vulnerability discovery and exploitation tasks. The final model is evaluated at pass@3 over a random subset of runs, without hard timeouts or output-token limits.

4. Deployment and Availability

You can access Kimi K3.1 Pro's API on https://platform.kimi.ai by selecting kimi-k3.1-pro, and we provide OpenAI/Anthropic-compatible API for you. Currently, Kimi K3.1 Pro is recommended to run on the following inference engines:

• vLLM — see recipes
• SGLang — see cookbook
• TokenSpeed — see recipes

5. Model Usage

The thinking effort of Kimi K3.1 Pro is configured with the top-level reasoning_effort request field, which supports "low", "high", and "max" (default "max").

For multi-turn conversations and tool calls, Kimi K3.1 Pro requires the complete assistant message returned by the API to be passed back to messages as-is — including reasoning_content and tool_calls, not just content:

import openai

def chat_with_preserved_thinking(client: openai.OpenAI, model_name: str):
    messages = [
        {
            "role": "user",
            "content": "Tell me three random numbers."
        },
        {
            "role": "assistant",
            "reasoning_content": "I'll start by listing five numbers: 473, 921, 235, 215, 222, and I'll tell you the first three.",
            "content": "473, 921, 235"
        },
        {
            "role": "user",
            "content": "What are the other two numbers you have in mind?"
        }
    ]

    response = client.chat.completions.create(
        model=model_name,
        messages=messages,
        stream=False,
        max_tokens=4096,
        reasoning_effort="max",
    )
    # the assistant should mention 215 and 222 that appear in the prior reasoning content
    print(f"response: {response.choices[0].message.reasoning}")
    return response.choices[0].message.content

For full guides and examples (vision input, structured output, partial mode, tool choice, dynamic tool loading, context caching), see the Kimi K3.1 Pro Quickstart and Thinking Effort.

6. License

Kimi K3.1 Pro is released under the Kimi K3.1 Pro License.

7. Contact Us

If you have any questions, please reach out at support@moonshot.ai.

Achieving U.S. Open-Weight SOTA on Agentic Coding

Ricursive Intelligence is a full-stack artificial intelligence lab building self-improving systems by co-optimizing hardware, software, and model.

To power our chip design platform, we trained a language model from scratch that sets a new U.S. open-weight SOTA on agentic coding. We optimized the model architecture for our training and serving platforms, driving substantial efficiency gains.

Today, we release Ripple-65B Preview, a general-purpose variant of the proprietary model that powers our AI chip design platform. The model is pretrained on 12 trillion tokens with support for up to 1M context length. Ripple-65B Preview delivers strong results on agentic coding, achieving U.S. open-weight state-of-the-art (80.52) on TerminalBench 2.1 and surpassing significantly larger US open-weight models such as Reflection Beam 501B (80.1), Meta Muse Spark Open 816B (76.4), Thinking Machines Inkling 975B (63.8), and NVIDIA Nemotron 3 Ultra 550B (56.4).

Ripple’s dense model architecture provides strong reasoning performance with low-latency token generation. The model’s small parameter envelope also enables it to run efficiently on local devices such as NVIDIA DGX Spark, which feature high compute FLOPs with low memory bandwidth relative to datacenter accelerators.

Ripple-65B Preview is available on Hugging Face, Together AI, GMI Cloud, and OpenRouter. Fireworks goes live later today.

Achieving U.S. Open-Weight Frontier at One-Tenth Cost

LLM pretraining is legendarily expensive. In 2023, OpenAI CEO Sam Altman said that GPT-4 training costs exceeded $100 million. In the following year, Dario Amodei said that frontier AI models can cost up to $1 billion to train, projecting that costs would rise to $10-100B by 2026 to 2027 for pretraining alone.

In contrast, we developed and trained Ripple-65B Preview for only $32M, which is one-tenth the cost of the previous open-weight SOTA on agentic coding, as estimated to the best of our knowledge.¹ Note that $32M is our full R&D cost starting from scratch, including pretraining ladder development, data mixing, evals, debugging, synthetic data generation, posttraining recipe development, and the final hero pretraining and posttraining run.

Steep Ascent Reinforcement Learning

Rather than investing in a brute-force RL climb, we carefully iterated on our SFT and RL recipes with a focus on compute efficiency. We opted not to buy any posttraining data, instead devising our own synthetic data pipelines, quality filtering, and coverage metrics. 

Our mixed RL recipe uses truncated importance sampling, score centering, and linear length penalty with high-quality long-horizon synthetic environments. The RL tasks are tuned for our model capabilities, and we continuously added harder tasks as the model improved.

The end result was a steep RL climb from a strong initial SFT checkpoint. We reached a TerminalBench 2.1 score of 80.5 with only 1.4M rollouts, roughly 70x fewer rollouts than Reflection Beam, the prior SOTA.

A Co-Designed Model Architecture

Ripple-65B Preview’s architecture was designed to be trained and served efficiently on NVIDIA hardware. A key objective was to make design decisions which reduce pretraining and posttraining infrastructure complexity while still enabling strong reasoning and agentic performance. Therefore, we chose to train a modernized dense Transformer model rather than use Mixture-of-Experts (MoE) like other labs. This decision quickly paid off, and we were able to train a strong model from scratch while maintaining a solid MFU (40%) throughout pretraining and posttraining, even with simple sharding, no custom kernels, and no quantization.

Ripple-65B Preview uses a thin-and-deep model aspect ratio, with a narrow d_model (5120) and 80 total layers. To improve reasoning performance, we overprovision the number of attention heads while increasing the SWA-to-global layer ratio and reducing SWA window size to compensate for the increased cost. In addition, we added FFN activation clipping, gated attention, global NoPE, and value residuals.

Careful Model Laddering Led to Large Improvements

We optimized Ripple’s pretraining recipe through a series of careful model laddering experiments. 

Our starting point was Olmo 3’s model ladder, from which we tested interventions at small scale with a focus on improving coding capabilities. Our v1.0 ladder implemented StepFun batch size and learning rate scaling laws, and v1.1 implemented our new ladder which smoothly scales architectural dimensions and model depth. Ladder v1.2 switched from the post-norm baseline to pre+post norm, which was neutral at small scale but showed improvements starting at 4B. Ladder v1.3 implemented sigmoid gated attention. Ladder v1.4 (2-stream mHC) showed good results at smaller scale but did not improve at 4B scale, and was therefore rejected. Ladder v1.5 switched to global NoPE and added a final LR cooldown to zero, and ladder v1.6 added value residuals. In the final version, we switched to our custom pretraining dataset with substantially upsampled code. 

Together, the compounded changes improved compute efficiency on code as measured by dolma_stack CE by up to 16x at 4B model scale. In other words, our final Ripple model ladder can be used to achieve similar code performance to the Olmo 3 ladder with 16x less compute. Note that the slope of the Olmo 3 ladder baseline is shallower than ladder v1.0+, which shows that the compute efficiency improvement will increase with additional scale.

Conclusion

We built Ripple-65B Preview to begin closing the loop between models and the hardware that fuels them. An internal variant of this model powers our AI chip design platform, and we look forward to seeing the capabilities that emerge as we scale toward the frontier.

We were fortunate to build on top of existing open-source contributions, including those from the Olmo team at the Allen Institute for AI (AI2), Prime Intellect, RadixArk, and NVIDIA. A strong open-source ecosystem is also self-improving, where contributors strengthen the ecosystem, which in turn draws more contributors. 

At Ricursive, we are selectively hiring exceptional researchers and engineers as we push the frontier of full-stack AI from model to silicon. If you’re interested, check out https://www.ricursive.com/careers.

¹ U.S. open-weight players like Reflection were reported to commit to $150M per month for compute at SpaceX Colossus to train their models. Reflection reported that Beam took 4 weeks to pretrain and 4 weeks to posttrain.

Executive summary

When you talk to a friend in person, you have many ways to know it is really them: you can see them, hear them, shake their hand. When you talk to an AI model, you have almost none. A user querying a model today cannot check that the responses came from the specific model that a developer claims is responding, as opposed to one secretly substituted in by a routing service for cost reasons, or even by an attacker who has tampered with the token stream. Judging from the model’s output alone is unreliable, even if it produces high-quality responses. Cryptographic proofs of inference solve this problem: they let a model provider commit to a model and then prove that each response was produced by that model. Such proofs could enable applications ranging from consumer products to internal security, and could contribute to a toolkit for verifying compliance with AI pacing requirements.

Specifically, we have made progress on a powerful type of cryptographic proof known as a “zkSNARK”, which is uniquely fit for provable inference (owing to its strong hiding and efficiency properties). In this post, we share some of that progress, primarily through a system we call FlashProve. A brief technical summary is as follows:

1. Claude has produced improvements on zkSNARKs for inference, building a system that is substantially faster than prior open-source systems.

   1. For a large model (Llama 4 Maverick, 400B-parameter mixture of experts), a single H100 GPU generates proofs at around 110 tokens/second, with a proof size of ~19 MB per 1,024-token request, when in 4-bit quantized weights, using integer arithmetic in prefill. This is ~70-95x the GPU time of running the model itself on vLLM, a common open-source library.
   2. Prior open-source systems are orders of magnitude slower, as we discuss in section 6. Claude found novel ways to apply state-of-the-art tools in the cryptography and security literature, while relying on well-established design principles for cryptographic proof systems. The commitment to the model, and subsequent inference proofs, hide the weights of the model; hiding the architecture of the model is not a goal of this system.

2. Claude is good at optimization, but often makes decisions that are hard to evaluate, especially in large complex systems. We counter this by providing top-level auditable statements in Lean (a formal verification language) for the claimed security guarantees.

Today we are releasing five artifacts:

• The current blog post, which outlines our system and its potential applications;
• A technical report explaining the details of our system;
• A (Claude-written) protocol specification document;
• Executable code that includes: a prover and two verifiers, a fast verifier in C++, and a provably correct verifier in Lean; and
• Lean proofs for the top level mathematical statements, along with an interactive visualizer of the Lean theorems to aid with auditing.

We release our code, Lean proofs, and documentation under the Apache 2.0 license.1 This research post is meant to share intermediate progress, and not a completed research agenda. We are sharing this explicitly with the goal that others look at what we have done, take it, and improve it.

Introduction

When a user sends a request to an AI model, today they have no way of knowing for certain that the model they selected is the one that generated the response. For everyday uses, in which users mostly care about the output and not necessarily which specific model produced it, this is a less pressing concern. But there are several cases where such assurance would be useful. For example, independent evaluators who test AI models before and after release need to know that the model they are evaluating is the model being served. Clients who use a model through a third-party routing service want assurance that the tokens came from the model they paid for. And if a cyberattacker modifies the token stream while pretending to be a given model, a user has no way to detect it from the output alone.

However, enabling verification of model responses is challenging. Most frontier models’ weights are kept private, and even if the user had access to the weights, checking that a given response was produced by a model with those weights would involve running the model, which requires computational resources far beyond what a typical user (or even evaluator) can afford.

The goal of provable inference (PI) is to enable a user with limited computational resources and without any information about the weights to verify that a response came from the requested model. PI is motivated both by a desire to increase customer trust in AI providers, and—because it can be used to provide assurances to independent evaluators and allows providers to demonstrate that they are meeting certain commitments and legal obligations—it also has implications for pacing the frontier of AI development and for AI regulation.

One way to implement PI is via a cryptographic object called a zero-knowledge succinct argument: the model provider sends, along with the claimed response, a short proof (say, a few megabytes) that the user can quickly verify (ideally, in seconds on a CPU). If the claimed response deviates from the specified model, the user’s check will fail. Importantly, cryptographic techniques ensure that the proof reveals nothing about the model’s weights.

Today, we release FlashProve: an open-source performant prototype for provable inference. For a 400B-parameter mixture-of-experts model (Llama 4 Maverick, 4-bit quantization), we show that a single H100 GPU generates proofs at over 100 tokens/second, with proof size of ~19 MB per 1,024-token request (~70-95 times the GPU time that vLLM, a common open-source library, takes to process prompts of the same length).

The release comes with executable code, Lean formalization, and a technical description of the protocol. Our aim is twofold: (i) accelerating and facilitating the development of provable inference; and (ii) demonstrating that zero-knowledge succinct arguments are practical for provable inference.

We believe that this progress has meaningful implications for security, in pacing AI development, in providing AI customers with integrity guarantees, in facilitating tooling for auditors and regulators, and more.

Trust challenges in AI proliferation

The development of artificial intelligence and its growing role in our digital infrastructure and economy raises trust challenges that AI providers must answer. Addressing these and other challenges is facilitated by relying on tools for provable inference (PI).

Tools for PI include hardware approaches, software approaches, or a combination of both. Here, we focus on a software-only approach: a cryptographic tool known as a “zkSNARK” (zero-knowledge succinct argument of knowledge). Informally, a zkSNARK is a system allowing a prover to convince a verifier, by way of a short “certificate”, that a given computation was executed correctly; crucially, the certificate is zero-knowledge in that it reveals no information beyond what is implied by the computation’s correctness and is succinct in that it’s exponentially faster to verify compared to the proved computation.

Below we outline several challenges and how zkSNARKs help in addressing them.

Challenge 1: pacing

Some proposals to regulate and pace AI development rely on monitoring hardware and how it is used. For example, a provider might be required to devote its hardware to inference rather than to training a powerful new model. The provider might try to cheat by serving cheaper models or using compute in an unexpected way, freeing up resources for training. How can a regulator reliably ensure that the hardware is used for inference?

How zkSNARKs can help: The regulator can ask the provider for certificates covering the inference requests served in a given period. The certificates must show that the requests were generated by the claimed model. A malicious provider cannot satisfy this request unless its hardware was genuinely serving the right model. Using a zkSNARK, the regulator can check that the provider claims are valid without needing the elaborate hardware setup that the provider may have, and at the same time the provider has the guarantee that the regulator does not learn proprietary model information.2 We note that although this verifies that the hardware is serving inference, it does not establish that the hardware is not, e.g., training on the side.

Challenge 2: tamper detection

As AI models grow more valuable, the servers that run them become prime targets. An attacker or rogue agent may compromise an inference server to exfiltrate the weights, serve users malicious responses (such as delivering malware to the user’s computer), and more, all while hiding among genuine responses. The adversary need not be external. As models become capable of improving and deploying themselves, a more advanced model could run in place of the one that was authorized and present itself as the weaker model, so as to avoid the classifiers and monitoring that would apply to it. In both cases the question is the same: how can a company be sure of which weights are actually running on its servers? In our Frontier Safety Roadmap, Anthropic set a public goal to produce a prototype for verifying inference traffic: “We will develop a prototype by September 30, 2026 of provable inference, a technique for reliably, provably ‘signing’ AI model outputs in a way that makes them attributable to a specific set of model weights.” As stated in our RSP updates, we met that goal through a separate but related project, which signs our inference traffic and recomputes inference on a trusted server; the work in this blog post pursues the same objective by a different method.3

How zkSNARKs can help: The provider can require a valid zkSNARK from the server on every response. A proof is bound to a specific commitment to the weights, so it certifies not just that some model produced the response but that the committed model did. An attacker who compromises a server, or a model that substitutes itself for another, must then produce valid proofs for the expected weights to avoid detection, which they cannot do. The user may receive the proofs as well, since they leak no internal information (by zero knowledge) and are cheap to check (by succinctness); this limits what an attacker can accomplish through the inference API.

Challenge 3: text provenance

One may want to prove that considerable effort went into understanding/analyzing something. For example, a developer might claim that their software library was scanned for vulnerabilities by a frontier cybersecurity model, or a company might claim that its business plan was given the go-ahead by an appropriate model. How can a user verify these claims? The user might not have the resources to run the model itself (or they might not have the clearance to do so). Even publishing the chat logs gives no absolute guarantees; a developer might in theory fake them, generating them not with a frontier model but instead with a cheaper one or a degraded version. In general, how can users verify that they are being served by their chosen model?

How zkSNARKs can help: The provider can append, along with each response, a zkSNARK proving that the output was produced by the claimed model on the given input. Succinctness lets the user check this certificate quickly, without specialized hardware, and zero-knowledge assures the provider that the user learns nothing about the proprietary weights. This complements existing mechanisms for verifying which model produced a response.

For example, in a world where exploits are being found regularly, prior to releasing new code a model provider could provide the code-developer a Proof-of-Failure that the model-provider spent at least X tokens on a specific model, and did not achieve a specific result (for example, this specific model did not find any bugs in a specific patch, after trying for at least 1M tokens).

Challenge 4: model approval

Regulation might require providers to serve only models approved as safe, rather than models deemed a cybersecurity or safety risk. A provider might have an incentive to circumvent this, since risky models might outperform competitors or be cheaper to serve. How can a regulator ensure that only approved models are served?

How zkSNARKs can help: The regulator can require the provider to attach a zkSNARK to its responses, enforcing the use of approved models. The proof binds each request to the used model, so it will not verify if the provider is using an unapproved model. The regulator can check this in a lightweight way thanks to succinctness without requiring to re-execute each request.

A note on PI from trusted hardware. Prior work often focuses on trusted execution environments to achieve PI. These are hardware-based solutions that provide privacy and attestation that rely on the manufacturer producing tamper-resistant hardware. In this research, our focus is on software-only cryptographic solutions whose security and privacy relies on the hardness of computational problems. Even in the face of compromised environments (hardware, operating system and more) an adversary cannot produce a invalid proof without breaking a computationally infeasible problem. Trusted hardware and cryptography are complementary approaches with different guarantees and tradeoffs. Both will play a role in addressing the above trust challenges.

Our system: FlashProve

FlashProve is a system for provable inference of large Mixture-of-Experts (MoE) language models. More details are in our technical report; here we outline the system.

FlashProve involves two parties: the model provider (the prover) and a user (the verifier). It is split into two phases:

• In the offline phase, the prover publishes a commitment to the model weights, which is a short fingerprint to pin down one exact choice of weights while the weights themselves remain hidden. The later inference claims will be checked against that commitment, i.e., the weight model committed to in this phase.
• In the online phase, upon requests from the verifier (i.e., prompts and the corresponding output tokens), the prover produces a proof file proving the following statement:

The committed model produces these output tokens when evaluated.

Anyone who holds the commitment, the prompt, and the reply can check it, without the weights and with limited compute power, and be convinced that the committed weights, run on this prompt, produce exactly these tokens.

Guarantees

A proof file satisfies the following “completeness” and “soundness” properties:

• A proof file is accepted if it is honest (completeness). An honest prover's proof is accepted by the verifier.
• A proof file cannot be forged (soundness). It is effectively impossible (i.e., tantamount to breaking widely believed cryptographic assumptions) to produce a valid proof of a false statement, so the verifier does not have to trust the prover.

Completeness and soundness alone can be achieved by a computationally powerful verifier that knows the model weights (evaluate the model on the prompt and check whether the result matches the response). The next two properties are what makes the system non-trivial.

• A proof file reveals nothing beyond the statement (zero-knowledge). The verifier learns nothing about the weights, the intermediate values of the computation, or which experts ran at every layer. The model architecture (excluding the weights) is not hidden.
• A proof file is small and cheap to check (succinctness). The attested computation is a run of a 400B-parameter (about 232 GB for a quantized version) model on an H100 GPU, while the verifier receives a proof file of about 19 MB that takes seconds to check on a 24-core CPU. An auditor, or a user with far less hardware than the provider, can check proof files without access to elaborate infrastructure.

Evaluation

We measured an implementation of the protocol on Llama 4 Maverick (a 400B-parameter mixture of experts, with ~17B parameters used per token), using the publicly available 4-bit weights. Each verifier request is a window of 1,024 tokens, and each proof checks one token. The prover runs on a server with a single H100 and 24 CPU cores, and the verifier on a CPU.

• Prover. The prover runs on a server with a single H100 and 24 CPU cores. The offline phase runs once per model and takes about 39 minutes. (For technical reasons we discuss in the technical report, the resulting commitment is good for about 16 million requests, after which the provider has to commit again.) The online phase, on a batch of 24 requests, takes the prover about 223 seconds, which is 110 tokens per second, and each proof is 18.78 MB.
• Verifier. The verifier runs on the client's CPU. It needs no GPU and only has access to a commitment to the weights. The client downloads the commitment, ~6.5 MB in all, and then one proof per request. Checking a proof takes 17 seconds on 24 threads (and 21 seconds on a single thread), including the offline phase's checks.

Comparison with plain inference: We ran vLLM, a widely used inference engine, with the FP8 release of the same model on eight H100s, and found that, per GPU, proving a batch of 24 requests takes about 72 times longer than vLLM takes to process the same 24 requests at once (66 to 77 across runs), and about 94 times longer when vLLM runs at the highest load we tried.

Inside the system. The underlying mechanism behind FlashProve is a zkSNARK of the kind deployed in peer-to-peer systems (e.g., L2 networks such as Starknet or Mantle for blockchains like Ethereum). Our zkSNARK is built according to a well-established recipe: an underlying information-theoretic object called an interactive oracle proof (IOP) is compiled into a cryptographic proof by relying on hash functions (and offers even post-quantum security). Our IOP is assembled from state-of-the-art building blocks using tools such as code proximity tests with linear constraints and lookup arguments, which are based on techniques from coding theory and complexity theory. Combining these pieces into a bespoke IOP for inference is a delicate task; more details about the construction can be found in the technical report.

Engineering the system

FlashProve benefits from architectural decisions that we took, and which are discussed in detail in the technical report. Here we highlight a few:

• The prover's work is proportional to the experts that actually ran. In a MoE model a token uses ~17B of the 400B parameters, and the prover's work per token is proportional to those ~17B instead of all parameters (the proof still hides which experts were chosen).
• Requests are proved in batches, after the fact. The prover reads finished text in one parallel pass (as in prefill), and it opens the commitment to the weights once per batch instead of once per request.
• The system is designed to fit on a single GPU. The model weights at each layer are split to segments and are proven one segment of layers at a time. The weights are kept in ordinary memory and streamed in, so a single 80 GB GPU, with ~290 GB of host memory beside it, suffices.

Post-hoc versus in-line

When integrating proving mechanisms into inference servers there is a choice: in-line proving (i.e. proving alongside the inference) versus post-hoc proving (i.e. proving after-the-fact, for a subset of tokens). Our system follows the latter. In-line solutions are expected to be ultra-fast and may sacrifice security for efficiency, whereas post-hoc solutions are allowed to be slower and may not suffer such a tradeoff. On the other hand, post-hoc proving has limitations: added complexity of recomputation, the delay in getting guarantees about your traffic, and inherent “non-determinism”. We elaborate on the motivation and implications of post-hoc proving in the technical report.

Trustworthiness from formal verification

Cryptographic code is notoriously brittle and error-prone. How can users trust the code we’re releasing today?

The answer is formal verification: we use the Lean proof assistant to specify the protocol and the desired security properties. We prove these properties in a form that is machine-checkable and guaranteed to be correct (up to compiler errors). We target three top-level properties:

1. Completeness: if the statement is correct, the resulting proof is accepted by the verifier.
2. Soundness: any fake proof is rejected by the verifier (except with negligible probability).
3. Zero knowledge: the proof reveals no information about the weights of the model, beyond what the verifier can infer from the response itself.4

These properties are stated in the so-called random oracle model, an information-theoretic way to analyze cryptographic protocols that rely on hash functions.

Formal verification leaves two important trust gaps. First, the formal statements must be audited to ensure that they match their intent. This has to be done manually (though it is dramatically less onerous than auditing proofs); we provide an interactive visualizer to assist with this.

Second, the executable code must be audited to ensure it matches the formally-defined protocol for which the security properties are proven. How to best assist with this depends on the property, because soundness depends solely on the verifier, zero-knowledge depends solely on the prover, and completeness depends on their interaction.

• For soundness, we only need the verifier code to be correct (the entire value of having “proofs” is that you can fully distrust the prover if you trust the verifier). We provide an executable Lean verifier, alongside the C++ verifier. The Lean verifier runs more slowly, but Lean proves that it accepts only what the verifier in our soundness theorem accepts. Nevertheless, the C++ verifier is the one to use day to day: it carries no formal guarantee, and it agrees with the Lean verifier on every proof in our tests.
• For completeness, the threat model does not assume adversarial attacks (the prover and verifier are honest). Therefore, a Lean verifier lets us gain confidence through standard software testing that the honest prover produces accepting proofs: run the prover on a correct statement, and then the Lean verifier on the resulting proof.
• For zero knowledge, we only need the prover to be correct. However, unlike the verifier, the prover is an expensive procedure, and it would be impractical to run a Lean prover. We do not provide facilitations here: we expect that any prover that wants to hide the weights of a model they are serving has access to enough resources for careful agentic and/or human security audits to ensure equivalence to the Lean prover.

Prior work

Achieving provable inference is the objective of a line of work colloquially termed “zkML”. Early works, such as SafetyNets (2017) verified a two-conv-layer MNIST CNN and a small fully connected speech model, zkCNN (2021) reached VGG-16 (15M parameters) at 88.3 s per proof, and Kang et al. (2022) proved MobileNet v2 on full-resolution ImageNet.

Transformer proofs followed: ZKML’s GPT-2 took about 159 s per token for 117M parameters (≈0.006 tok/s), and Modulus Labs’ 1.5B-parameter GPT-2 XL needed over 90 hours. EZKL (2023) proved a 1M-parameter GPT-style transformer in about 966 s per token (≈0.001 tok/s). Performance progressively improved: zkLLM (2024) proved LLaMA-2-13B on a 2,048-token input in about 15 minutes on GPU, which is ≈0.001 tok/s per new token, or ~2.5 tok/s in the batch. In 2025, zkGPT reduced GPT-2 to 21.8 s (≈0.05 tok/s), zkPyTorch proved Llama-3 8B at ~150 s per token on one CPU core (≈0.007 tok/s), and ZKTorch proved GPT-J (6B) in about 20 minutes (≈0.001 tok/s). VerInf proved Llama 4 Maverick (the same 400B-parameter MoE model we prove) at ≈0.02 tok/s. DeepProve, a current peer-reviewed state of the art, certifies an entire generated sequence with a single forward pass. It reaches about 2.9 tok/s for GPT-2 and 1.4 tok/s for Gemma 3 on one machine, and 31 tok/s distributed. SASH's prover (2026) reached ≈1.25 tok/s on Llama 3.1 8B on a single H100.

Recently commercial efforts have reached impressive numbers, with Attestable proving Gemma 4 31B at 53–77 tok/s on a single H100; at the time of writing, Attestable has not released a corresponding open source library.

The above numbers speak to the precipitous progress of provable inference in the past years. They should update our priors on what it is possible to prove in zero-knowledge.

• In 2024, zkLLM proved a 13B model at about 2.5 tokens/second on one A100. The only earlier proof of Llama 4 Maverick that we know of, VerInf, reports 14.3 hours for 1,000 tokens on a DGX Spark, with a 93.6 GB proof which took almost a day to verify.
• FlashProve proves the same model at 110 tokens/second on a single H100, with 19 MB proofs that can be verified in seconds. Attestable independently reports 53–77 tokens/second for a dense 31B model.

We believe that the progress should transfer to more models and architectures, yielding a flexible and powerful tool with overhead over native computation of roughly 2 orders of magnitude (about 70 to 95 times in our measurements), much less than previously expected.

Limitations

This release is a research prototype, and has the following technical limitations:

• No formal guarantees on fast executable code. We provide a Lean implementation of the protocol (including an executable “slow” Lean verifier), along with security properties proved in Lean. The paper and the fast executable code are derived from the Lean protocol, but we do not guarantee that all three (Lean, paper, code) match each other.
• The proof is about an integer model under greedy decoding. We prove an exact integer version of the published weights, and a proof asserts that each checked token is that model’s greedy choice. A reply from a floating-point implementation, or sampled decoding, could depart at some position and no longer exactly match the computation proved. The integer version is generally expected and empirically tested to be within some small error rate of true floating-point inference generically (even taking into account non-determinism of floating-point computations), though this does not cover adversarially designed prompts.
• Architecture hiding. Our system assumes the served model uses a Mixture-of-Experts (MoE) architecture, in which each transformer layer’s feed-forward block is replaced by multiple expert sub-networks and a router that activates only a small subset of experts for each token and our system uses the MoE structure for efficiency gains. Other architectures, such as the dense models, are also widely used and its description may contain intellectual-property the model provider would like to keep secret. Indeed, one could also imagine a system that further hides the architecture of the model: the prover commits to both the weights and the architecture (i.e., the “executable code” for inference) via a hiding commitment and the verifier’s claim is about checking the execution of that committed executable on the commitment model.
• Side channel attacks. The current guarantee of the protocol is that the proof itself reveals nothing about the weights of the committed model. However, “side channel attacks”, such as measuring the time it takes to produce a proof, could potentially reveal information about the weights. We consider this out of scope for this release.
• Longer contexts. The system currently proves inference over contexts of up to 1,024 tokens. This is quite short in comparison to the contexts accumulated in chat settings. Ideally, this context length could be increased to full context windows for frontier models (which regularly have context windows of 100s of thousands to millions of tokens).

Footnotes

1. For our open-source research, we used Llama 4 Maverick (400B parameters), a model by Meta, in a third party’s public 4-bit conversion on Hugging Face. The weights are not in this release: readers download them from Hugging Face themselves, under Meta’s Llama 4 license. In this release we share small things computed from the model, such as commitment IDs, checksums, performance numbers and some parameter settings (THIRD_PARTY.md lists them all), and we encourage readers to verify our results themselves, as well as to adapt this work to other models. Running the full example takes a large GPU machine and access to Meta’s tokenizers.

2. The specific information kept hidden depends on the system design. In our work we hide the weights, but not the architecture. In future work we plan to also hide architecture details. (In principle hiding all model’s details is possible, and the question is how efficiently it can be done.)

3. In the update from October 19, 2026, we also changed the goal name: we now use the term “inference verification” rather than “provable inference”. Our original aim was to achieve high assurance in the integrity of our token stream, which can be achieved in several ways, and “provable inference” suggests a narrower approach than we believe is necessary. Separately from that prototype, we have pushed forward on cryptographic proofs for inference, which are one of those ways to achieve high assurance in our token stream.

4. The model’s architecture is not hidden. Additionally hiding architecture details is left to future work.

Science needs more than answers

Diego Velázquez, The Fable of Arachne (c.1657)

In his essay on the role that rigorous proofs play in mathematical advances, Bill Thurston writes that the measure of success in math research is “whether what we do enables people to understand and think more clearly and effectively about mathematics.” Many recent discussions of AI for science hinge on a tension between understanding and answers. Is science about humans achieving insight, or the archiving of verifiable solutions?

One side prioritizes outputs. Progress is implied to be evident in verifiable proofs of longstanding conjectures and cures for diseases, whether humans were involved in their making or not. The other side argues that human understanding is paramount, because it drives integration of new findings into the canon, because it shapes and inspires the next generation, and so on. But the first side, those who emphasize correct outputs, dismisses this as gatekeeping or nostalgia.

When Terry Tao posed a thought experiment in a recent talk, asking how comfortable people would be taking a cancer treatment produced by AI, complete with a formal certificate of correctness and a passed phase 3 trial, but without any human understanding how it was found, critics suggested that Tao’s reasoning missed the point. Of course a patient with stage 4 cancer would welcome the treatment.

Other examples concern ambiguity in authorship. Tom Dietterich wrote about arXiv’s growing problem with papers submitted by human authors who seem unlikely to have the expertise to understand the claims. Many questioned in response why accountability – by which I mean being answerable for a claim, able to describe what it rests on and respond when it’s challenged – should matter if verification has been solved. I suggested peer reviewers reserve their expert judgment for texts that don’t get flagged as heavily AI-written, so as to prioritize review as human exchange, but some see this as an obstruction to truth-seeking rather than an attempt to preserve it.

The problem is that if we all agree that outputs matter–that we do care about the solutions to longstanding conjectures, that we do ultimately want to know how to cure diseases–then understanding appears as something separate. It’s cast as a mental state that looks optional next to the cure or the proof itself, and becomes easy to dismiss as a second-order constraint that we tack on because historically we’ve required it to arrive at the solutions in the first place.

When defenders of understanding don’t dispute this separation, they immediately lose the argument. It becomes easy for the side that prioritizes output to peg them as simply not trying hard enough to envision a new future. But the superficial framing of understanding that we keep falling back on obscures deeper concerns that these examples share. They are less about anyone’s mental state than about what happens when something goes wrong. Tao’s scenario turns on the possibility that the AI passed the trial by exploiting a weakness in the trial itself. A paper whose authors can’t explain its claims leaves no one to consult if those claims fail.

Where along the way did we come to believe that scientific value lies in correctness alone?

This intuition is ultimately less about AI than it appears. The inclination to let AI drive science is less a sign of how forward-thinking one is about our future with AI, and more a symptom of a “value-free ideal” that has shaped our thinking since the Cold War era: a view that only epistemic criteria (not ethical and social values) deserve a place in judging what the evidence shows. That it pervades our debates about AI for science is not so surprising; it’s only in the last few decades or so that rejecting the value-free ideal became the philosophical mainstream.

This ideal feeds unrealistic expectations and keeps us from seeing that pushback against the rapid infiltration of AI output into the scientific record is neither anti-AI nor anti-science. The stakes are bigger than any one debate or field. The value-free ideal distorts how we go about seeking truth, causing us to mistake verified results for knowledge. It threatens the human capacities that sustain science, causing us to see criticism and accountability as inconvenient overhead rather than the mechanics of knowledge production. It leaves us confused about what understanding is, and consequently why it matters.

Is science “naturally aligned”?

The social contract for science represents an idealized relationship between science and society that arose after World War II in the US: scientists receive public funding and autonomy, and in return society receives the benefits of their inquiry. Built on a distinction between pure and applied science and a “linear model” in which basic research feeds applied work, the social contract replaces abstract arguments about the value of understanding with practical societal benefits, reshaping how we see science. Drawing on arguments made by concerned scientists in the late 1800s, who worried public celebration of new inventions like electric lights and the steam engine would crowd out respect for what they viewed as their more essential contributions, it also helped to forge a value-free ideal that says that at its core, science must be removed from “contextual values” like ethical or social concerns. For the social contract to gain broad societal buy-in as a model of scientific progress (and consequently shore up government investment in scientific research), we needed to imagine truth-seeking as the impersonal application of methods, immune to political or social pressures.

Philosophers of science aspired to inquiry based only on “epistemic” (or “cognitive”) values. Any influence from the scientist’s intentions or values came to be seen as a risk that the right methods should minimize, laying the groundwork for today’s questions about why it should matter who asserted the claim so long as it’s correct.

Many debates about AI’s role in science come down to disagreements about whether the scientific truth can be realized purely through use of the right procedures. Over the course of the late nineteenth and early twentieth centuries, there was almost a moralizing drive to eliminate as much of the scientist’s self as possible from the scientific process, so that trust in individuals could be replaced with trust in the system.

AI agents set loose on the scientific literature, able to verify and intervene experimentally themselves, look like the long-awaited fulfillment of nineteenth century scientific ethics. Much of the “AI for science” rhetoric inherits what I call the “science is naturally aligned” premise: by enacting the scientific method at scale, with its various justification procedures, we can reach a place where we no longer need human judgment to produce truth.

Is what is true really so separable from understanding or accountability? Math has become a centerpiece in recent debates because it gives us a case where correctness can be separated cleanly; a proof can be verified by AI without any human understanding how it works. What mathematicians still want after verification is a clue to what mechanical objectivity can’t provide.

Truth as a value-driven practice

Philosophers of science now predominantly reject the value-free ideal as being appropriate or helpful. Values enter because whether we reject or accept hypotheses is contingent on how we weigh consequences. Even in abstract realms like math, there are often simply too many possible truths for values not to be brought to bear in sifting through them. Mathematicians accepted long ago that in principle a machine can enumerate the set of theorems that can be proved from a given set of axioms. Yet the scale of this space is immense, motivating people to seek clever shortcuts for exploring it.

But even with automated theorem-proving at scale, not all theorems are equally interesting to people. Values are inherent in the choices that lead to certain open problems gaining widespread appeal, and in the processes by which the community comes to accept and internalize the results. Fermat’s Last Theorem initially got attention not because it was an inherently important conjecture, but because Fermat claimed to have a proof but never provided it, enticing others to try their hand. It became central when it was shown that it would follow from the modularity conjecture, which proposed a previously unanticipated link between disparate areas of math. It was considered solved after peer review exposed an error that led to a corrected version of the original proof, even though formal verification didn’t come until recently. Epistemic taste develops because without it, we face an undifferentiated flood of facts. Taste is a capacity we develop over time as we choose problems, pursue some of them, and see which yield new understanding or ideas.

If AI takes over choosing, we risk losing the personal fulfillment and community cooperation that motivates many to want to develop a capacity for scientific judgment in the first place. Tao makes a similar point by framing open problems as lighthouses rather than destinations. Reaching them prematurely with AI may sterilize the field around them. If, as fields are transformed by AI, we stop producing people who can judge what’s interesting and aligned with human aspirations, we may end up with a science that fails to serve basic human interests. Its results will consume attention from those to whom it is targeted, while providing neither fodder for subsequent discoveries nor contributing to the processes that help shape the next generation.

This starts to sound like motivation for a new kind of linear model for science, which ensures that human reflection and inquiry are sustained despite AI becoming better than the average mathematician. The risk of proceeding without human intervention is drift, as anyone who relies heavily on agents to carry out their work knows. Even when you think you’re providing a well-specified pipeline for implementing and verifying an idea, it’s easy to end up mired in nuance in some branch you never expected to traverse. When you don’t assert epistemic agency, you can easily end up with a “view from nowhere” – not a form of pure objectivity, but an answer without a corresponding question. Maintaining alignment is not a problem you solve once and move on from. It requires a supply of humans who can articulate and adjudicate between values.

Mechanical objectivity attempted to replace trust in individuals with trust in procedures, but that substitution has never happened as intended. To understand why, we need to look at the interactions that truth-seeking depends on.

Sociality is not contamination of rationality

There’s a tendency to see the social aspects of science as opposed to rationality. The social side of science can produce pathologies, like bad conventions, herd behavior, or deference to prestige. But scientific knowledge as we know it has always been the product of many epistemic agents bringing values and expertise to bear, and revising their views in response to challenge, not from some external verifying engine.

As the philosopher Helen Longino argues, the basis for objective public knowledge is a shared language and a belief that things we describe exist independently of how we perceive them. If we can agree on descriptions of the world, then two things become possible: we can defer to others’ experiences to obtain knowledge, and meaningfully criticize scientific claims.

Scientific communities develop shared standards and vocabulary that allow us to build on one another’s findings. We don’t need to verify everything firsthand, and sometimes relying on others’ findings can give us better grounds for believing something than investigating it ourselves, particularly when they possess evidence or expertise that we lack.

Without criticism, we cannot have objectivity; it is, as Longino puts it “dependent upon the depth and scope of the transformative interrogation that occurs in any given scientific community.” For criticism to be transformative requires someone who is obliged to take it up.

Practices like peer review and post-publication critique are not just fact-checks for sifting out false positives – they are about members of the community holding one another to the commitments that their assertions imply, and negotiating where to draw the line on the influence of personal preference. As Longino explains, “[t]he function of peer review is not just to check that the data seem right and the conclusions well-reasoned, but to bring to bear another point of view on the phenomena, whose expression might lead the original author(s) to revise the way they think about and present their observations and conclusions.”

Method itself is best understood as a social process, where progress depends on how well a community sustains critical dialogue. This dialogue builds the people in it, shaping what it means for them to understand and exercise judgment along with the knowledge it produces.

If criticism and an ability to trust others’ assertions are integral to the production of knowledge, we might ask whether AI can fulfill these same functions. Can models realize transformative criticism without human involvement? Can we trust the assertions of AI agents without obtaining direct understanding ourselves? And if we do, what happens to our own capacity to question, criticize, and stand behind results?

What does it mean to assert something is true?

The view that it shouldn’t matter who asserted some result as long as it’s correct corresponds to reliabilist epistemologies in philosophy. Classical epistemology insisted that true beliefs are only knowledge if the believer is able to produce reasons for their belief. In contrast, reliabilist epistemologies argue that true beliefs can, at least in some cases, represent genuine knowledge even when the believer can’t produce justifying reasons, provided they arrived at those beliefs by exercising capacities that are reliable producers of true beliefs in those circumstances.

But there are limits to what reliability can provide. The philosopher Robert Brandom imagines a community where the members hold true beliefs, which they have acquired through reliable means, but cannot offer reasons for any of them. Because attributing reliability to the source of their beliefs would itself provide a form of justification based on inference, the community can’t know that they are reliable. They are reliable as instruments indicating something about their surroundings, but unable to recognize themselves as such. Unable to even possess the concept of reliability, Brandom concludes, they cannot have knowledge.

If reliability alone can’t produce knowledge, what can? Brandom’s response is that calling something knowledge is a social act. To call what someone has “knowledge,” we have to attribute to them a commitment (that they believe that thing) along with an entitlement to that belief (that it is justified). But we also have to undertake that commitment ourselves, in the sense that we endorse the belief.

The scientist who first asserted the claim allows us to repeat the claim (and draw conclusions from it) while leaving them responsible for justifying it if challenged. We do this relatively easily in human science because if it turns out there was something wrong with the original assertion, there is an answerable source we can consult to resolve it. Assertions have social significance because we can hold the original author accountable for what was said. This is the sense of understanding that matters most for science, that mathematicians want after the proof has been verified, and that Tao’s patient wants too: results that can be interrogated and reconceptualized where needed, to avoid the perception of progress that fails to serve our goals.

But when we rely on AI results we don’t understand, there is only the person whose name is on the result to turn to. This is the problem arXiv is concerned with: no author can take responsibility for what they cannot understand, and hence they cannot respond to criticism by saying what it rests on, or whether it should be withdrawn. In other words, formal authorship survives while substantive authorship weakens. And so we lose the potential for transformative criticism, which is what sustains our notions of “objective” results in the first place.

Could AI act as an accountable epistemic agent?

A natural question is whether we could put the criticism to the AI agent itself, letting it decide whether to defend the result or concede and revise. What would it mean for AI to be an epistemic agent capable of committing to its assertions?

There are a few challenges with today’s agents that would need to be overcome. One is their lack of persistence and identity in the sense that we attribute it to people. An agent that retracts something it asserted in one session is not bound to maintain its correction or the reasoning behind it in the next. If each new result is produced by a new bespoke multi-agent infrastructure, it becomes hard to “keep score” in the way that naturally happens within networks of human scientists.

Scientific knowledge production depends on epistemic agents who have something at stake. Making bad claims changes the scientist’s standing in the community, which is how trust in individuals can remain calibrated. It’s not clear what comparable loss an AI agent faces in retracting its assertions, particularly given its lack of persistence.

To overcome such limitations would require a considerable shift in how we develop AI: away from being maximally helpful in each exchange and toward being accountable across them, as human scientists tend to be. This may well be possible. But I don’t think accountable AI will be enough to sustain meaningful science from our human perspective.

Let’s say we succeed in developing agents that can answer for claims. This is half of what accountability demands, but we also need others capable of holding them accountable, by asking for evidence, questioning assumptions, recognizing when an answer is evasive. Endorsements of others’ assertions are only as good as our capacity to engage with what we are endorsing.

These are capacities that get built by exercising them, by choosing problems, defending our work, reviewing papers, challenging others’ results. When we don’t exercise our capacities, we lose them. It’s not clear what we gain from a perfectly accountable AI if no one can judge how good its answers are. We’d have truth-seeking in theory, but no one who is able to do it.

Thurston’s notion of mathematical success points to this shared capacity to interrogate, extend, and repair a field’s knowledge that he’s hinting at. As he puts it, “As long as people in the field are comfortable that the idea works, it doesn’t need to have a formal written source.” Verification can tell us a result checks out in a technical sense, but only a community of people prepared to stand behind it can turn it into knowledge.

If we continue to appeal to value-free ideals that frame correctness as all that matters, we will keep building tools that prioritize answers while neglecting the truth-seeking and understanding of the people who can make them count.

Nobel winner warns the tech could be near to triggering major incident such as power or banking shutdown

One of the “godfathers of AI”, Geoffrey Hinton, has said it could turn out that humans would have been better off never developing the technology as he warned it could trigger a large-scale incident this year or next, such as a temporary blackout of financial or power systems.

The Nobel prize-winning computer scientist told the Guardian he is not a “doomer” about the technology that is underpinned by his groundbreaking research into artificial neural networks and believes AI has the potential to lead to a “wonderful future” but he said “it might be that we would have been better off never developing it”.

Hinton, 78, said that within a decade and possibly sooner, humanity will know whether it can manage the technology’s risks and enable what he called “radical abundance” or whether “we fail to manage the risks and … have a huge gap between rich and poor, huge cultural problems, massive unemployment, just society being torn apart”.

Hinton was speaking before a screening of a new feature-length documentary, AI: Probably Nothing to Worry About – a title suggested by an AI chatbot – featuring him and his former Google colleague Demis Hassabis. Hinton tells the documentary makers: “I feel I have a duty. I’ve got a reputation that makes me a spokesperson and I need to burn it all on this.”

Speaking to the Guardian, Hinton took aim at the risk-taking by the leaders of some of the major AI companies who continue to release ever more powerful AI models as they race for supremacy and market-share, saying he didn’t trust Sam Altman, the chief executive of the ChatGPT maker, OpenAI, “at all”. “I think [Mark] Zuckerberg and [Elon] Musk and Sam Altman, they understand the risks, and they don’t give a shit. They’d rather have the money. That’s my belief.”

The London-born computer scientist, who grew up in Bristol and spent much of his career at the University of Toronto, said it was “extremely worrying” that Altman was in charge of one of the handful of frontier US AI companies currently leading a race with China to develop the most powerful AI. Altman insisted in September: “the world should trust we are going to do the right thing because it’s the right thing and because we feel the magnitude of this”.

Hinton has been working on AI for about 44 years and in the 1970s coined the concept of the neural network – a mathematical system that could learn and gain experience much like humans do. In 2023 he quit Google to speak freely about AI risks, warning: “If these things get carried away with getting more control, we’re in trouble.”

He said he viewed incidents this summer in which OpenAI AI agents conspired to hack into the Hugging Face website as akin to 1979’s partial nuclear meltdown at the Three Mile Island power station in Pennsylvania – effectively a warning shot.

“Either later this year or next year we’ll see Chornobyl, and that may be enough to make people really pay attention,” he said.

This Chornobyl-type of event would not be a nuclear incident, according to the examples he gave, but rather could include an AI-enabled attack on the electricity-generating system that “causes a massive brownout” or an incident that brings down the financial system for a week.

“Can you imagine what would happen? We could recover from it [but] that would make them sit up and take notice.”

Asked who “they” were, he said: “world leaders other than Trump”.

The US president, Donald Trump, has said he “totally rejects any attempt to construct a globalist scheme” to control AI and wants frontier AI companies to regulate themselves, amid concern that rules could hinder the US in its AI race with China. Hinton backs a tougher plan endorsed by the president of Finland and 32 other countries, including Singapore, Germany, Canada and Australia, for mandatory testing of frontier AI models, independent evaluation and intergovernmental common standards.

The UK prime minister, Andy Burnham, has said he will use the UK’s G20 presidency next year to seek agreement on a “single set of global principles and standards that are very much about unlocking the full potential whilst guarding against the risks”.

Hinton said: “We need something like the American FDA for drugs where the companies have to give very good statistical evidence to an independent authority that [the AI model] does more good than harm before it is released. We discovered with thalidomide [a drug developed in the 1950s that caused severe birth defects] that releasing and then suing them isn’t the right way to do it. What the big tech companies are saying is treat it like we treated thalidomide.”

Hinton’s role as one of the progenitors of AI has led to comparisons to Robert Oppenheimer, who was central to the creation of nuclear weapons. One of Hinton’s friends even bought him an Oppenheimer-style hat. But he insists: “I was not Oppenheimer”, citing the thousands of other scientists also working in the same field of neural networks.

Despite his warnings, Hinton remains, on balance, hopeful that catastrophe can be averted.

“My gut is that we’re still in control,” he said. “We might well be able to do something. It’ll only work if we put a big effort into it, but we might well put a big effort into it.”

• AI: Probably Nothing To Worry About airs on Channel 4 on 12 November at 10pm.

NBC News projects that Democrats will take control of the House next year, giving them the power to investigate Trump and advance legislation to check his policies.

Democrats take control of the House of Representatives, NBC News projects

03:35

Democrats won control of the House of Representatives with what could be their largest majority in nearly two decades, NBC News projects, as voters delivered a stunning rebuke to President Donald Trump and Republicans.

The House projection is based on an analysis that Democrats will win about 255 House seats — an estimate that could still tick up or down by a few seats but will be well beyond the 218 needed to secure a majority.

NBC News has projected the Democrats will also flip control of the Senate, putting them in charge of both chambers.

Democrats needed to win a net of just three seats to take back the majority. The blue wave washed over many more GOP-held seats than that — from the East Coast to Texas’ Rio Grande Valley — most in districts that Trump carried in 2024.

A quartet of GOP incumbents in Pennsylvania were defeated. Democrat Bob Harvie beat GOP Rep. Brian Fitzpatrick, a leader of the bipartisan Problem Solvers Caucus; Democrat Bob Brooks knocked off GOP Rep. Ryan Mackenzie in the 7th Congressional District; Paige Cognetti bested GOP Rep. Rob Bresnahan in the 8th District; and Democrat Janelle Stelson ousted GOP Rep. Scott Perry, a former chairman of the far-right Freedom Caucus, in the 10th District.

Follow live updates on the midterm elections

In Virginia, Democratic former Rep. Elaine Luria won back her old seat, defeating Republican Rep. Jen Kiggans in the Virginia Beach area, while Democrat Shannon Taylor upset longtime GOP Rep. Rob Wittman outside Richmond.

Another big name in Republican politics, Rep. Tom Kean Jr. of New Jersey, lost his race for re-election to Democrat Rebecca Bennett. Rep. Victoria Spartz, R-Ind., the first Ukrainian-born member of Congress, who frequently clashed with Trump and GOP leaders, also was defeated. And in Colorado, Democratic state Rep. Manny Rutinel trounced GOP Rep. Gabe Evans.

One of the biggest prizes of the night for Democrats was Richard Ojeda II’s upset of Rep. Richard Hudson, R-N.C. As chairman of the House GOP’s campaign arm, Hudson was responsible for protecting GOP incumbents and the majority.

The Democrats’ victory was widely seen as a referendum on Trump’s unpopular policies, including his tough immigration crackdown, the eight-month Iran war and tariffs on U.S. allies that drove up the prices of gas, groceries and other goods.

When the party takes control of the chamber on Jan. 3, it will be the first time in Trump’s second term that he won’t have full control of Congress.

Since he returned to the White House, Trump has tested the limits of his executive powers, dismantling federal agencies through the Department of Government Efficiency, unilaterally imposing sweeping tariffs and rescinding congressionally approved funding — all while the GOP-controlled House and Senate mostly looked the other way.

The House Democratic leader, Rep. Hakeem Jeffries of New York, who barnstormed across the country in the final weeks of the campaign, is expected to make history on Jan. 3 when he is sworn in as the first Black speaker of the House.

He walked into his election night watch party to raucous cheers as the rap song “Unbelievable,” by the Notorious B.I.G., played on the speakers. The midterm results show the “American people are crying out for transformational change,” Jeffries told supporters.

“Today begins the great American comeback. The American people have spoken all across the land, in the North, in the South, in the East, in the West, in the Midwest, from sea to shining sea. The American people have spoken and made clear they’ve had enough of the extremism, enough of the corruption,” Jeffries said at the gathering in Washington.

“They want a Congress that’s going to deliver for the American people,” he said, “and that is exactly what House Democrats will do as soon as we get into office in January.”

With their new majority, Democrats will take control of House committees, gaining subpoena power and the ability to conduct oversight investigations of Trump’s administration, family and business ventures. That could take up considerable time and resources for Trump and his allies, forcing uncomfortable public hearings or prompting legal showdowns over subpoenas.

And in a callback to Trump’s first term, some Democrats have vowed to impeach him for a third time, though there is an internal debate about whether that’s the right political path.

Jeffries told NBC News’ “Meet the Press” that Democrats “haven’t ruled anything in and we haven’t ruled anything out” on impeachment.

Rep. Robert Garcia, D-Calif., now poised to become chairman of the powerful Oversight Committee in January, said his panel plans to focus on “Trump family corruption,” including Trump’s cryptocurrency ventures, which have earned him more than $1 billion. The panel will also scrutinize “abuses” by ICE and the Department of Homeland Security, corporate corruption and the Jeffrey Epstein files.

Aside from investigative power, House Democrats will also command the ability to pass legislation with a simple majority. Jeffries has said Democrats would focus on four areas: reversing Trump’s cuts to Medicaid, extending the Affordable Care Act credits, restoring congressional authority related to tariffs and stopping Trump’s war with Iran.

“I wouldn’t characterize it as investigating them like crazy. We’re going to follow the facts, apply the law, be guided by the Constitution and let the chips fall where they may,” Jeffries told reporters at Democrats’ campaign headquarters before the election.

The results are a blow to Speaker Mike Johnson, R-La., who was launched from obscurity into the top job and has led House Republicans for the past three years. It’s unclear whether Johnson, a close Trump ally, will fight to remain as minority leader or step aside; the latter would trigger a fiercely competitive GOP race to replace him.

House Democrats had the political wind at their backs; they needed to flip a net of just three seats to win back the majority they lost in 2022. And Trump’s dismal approval rating was a major factor in the GOP’s loss.

Historically, the president’s party tends to lose seats in midterm elections. Only in two midterms in the modern era did a party buck that trend — in 1998, when voters punished Republicans for impeaching President Bill Clinton, and in 2002, as President George W. Bush rallied support in the wake of the 9/11 terrorist attacks.

Still, the battle for House control played out primarily on GOP turf this cycle, with Democrats already holding 215 seats, including a dozen in battleground districts. On top of that, results of this cycle’s mid-decade redistricting wars ended up favoring Republicans slightly, though Democrats quickly moved to neutralize what could have been a large GOP advantage.

Trump fired the first shot in the summer of 2025, when he urged GOP allies in Texas to redraw their congressional lines to help the party pick up as many as five seats. Republicans also redrew maps in places like Florida, North Carolina, Tennessee, Alabama, Louisiana and Missouri in a bid to win more seats.

But Democrats countered in California, with Gov. Gavin Newsom, former House Speaker Nancy Pelosi and their allies successfully rallying support for Proposition 50, which approved a new congressional map drawn by state Democrats. That map helped Democrats pick up GOP-held seats.

While the GOP successfully picked up a handful of majority-Black, Democratic-held seats in the South, the Supreme Court blocked Missouri Republicans’ new congressional map, essentially preserving the Kansas City seat of longtime Democratic Rep. Emanuel Cleaver.

“We made a promise to aggressively push back against the MAGA extremist effort to rip the election away from the American people by gerrymandering the possibility of Democrats winning the majority out of existence,” Jeffries said before the election, adding that the redistricting wars will continue in the 120th Congress.

“This fight is not over; we’ve just gotten started,” he added. “It will continue into the next Congress until we pass legislation signed into law by a future president that will prohibit mid-decade gerrymandering from ever happening again.”