Formalizing Fermat's Last Theorem

We are sharing the first complete computer-checked proof of Fermat’s Last Theorem. Claude worked largely autonomously over 11 days to write the proof in the Lean programming language. Below, we describe how the formalization was done and share some thoughts about what this work could mean for research mathematics.

Around 1637, Pierre de Fermat jotted down a claim in the margin of his copy of Diophantus’s Arithmetica that would become one of the most famous mathematical conjectures of all time: no positive integers a, b, c satisfy aⁿ + bⁿ = cⁿ for any n > 2. Fermat’s Last Theorem (FLT), as the conjecture became known, turned out to be incredibly difficult to prove. The first proof, from Sir Andrew Wiles in 1995, ran to 129 pages and required months of painstaking work to verify.

A decade later, Dutch computer scientist Jan Bergstra proposed “formalizing” Wiles’s proof: converting the mathematical reasoning into a form computers can check automatically. Since then, mathematicians have been developing the methods needed to encode such a complex proof, including a multi-year community effort kicked off in 2024 by Kevin Buzzard at Imperial College London to complete the formalization using the Lean proof assistant.

Recently, Tianyi Peng, an Anthropic researcher whose group at Columbia University builds tools for AI formalization, set out to test whether Claude could make progress on formalizing FLT. The result went further than he expected. In 11 days, working largely autonomously, Claude produced the first end-to-end, computer-checked proof of FLT. Along the way, it wrote 13 million lines of Lean and proved 29,500 intermediate theorems.

We shared the resulting proof with Kevin Buzzard, who said:

This extraordinary autoformalization achievement, which Anthropic researchers say only took 11 days, proves Fermat’s Last Theorem with no assumptions other than the axioms of mathematics. Along the way we see autoformalization of algebra, harmonic analysis, geometry and number theory, and we learn that AI autoformalization artefacts are now robust enough to be built upon; the proof is multi-layered.

Automatically formalizing a proof as complex as FLT is a significant step towards a future in which all of mathematics can be readily checked. As AI produces ever more proofs, the ability to easily formalize work can lighten the burden of evaluating new results (a process that can take years). We are hopeful that it will become easier, not harder, to trust the body of knowledge upon which mathematics is built.

The challenge of verifying mathematical proofs

Unlike recent AI-driven work on the Riemann hypothesis, which produced novel mathematics, what’s novel here is the verification—checking a mathematical proof as one would check a mathematical computation with a calculator. Proving math theorems requires assembling complex logical chains, and if a single link is broken, everything that follows it might turn out to be false. Understanding a novel result deeply enough to be confident in its correctness can take months, or even years, of work.

Fermat’s Last Theorem is an illustrative example. Fermat wrote down the theorem’s statement in the margin of a book, alongside a tantalizing note:

I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

For over 350 years, generations of mathematicians searched for a proof of FLT, marvelous or otherwise. In 1908, a prize of 100,000 German gold marks (the equivalent of 1–2 million dollars today) was announced for anyone who could produce a correct proof, and 621 incorrect attempts were produced in the first year alone.

In June 1993, Wiles presented what he believed to be the first correct proof of FLT in a three-day series of lectures. Two months into an intensive verification effort by several mathematicians, a reviewer asked Wiles a question that exposed a critical gap. Wiles spent a year trying to fix it, first alone and then with his former student Richard Taylor. He was on the brink of abandoning the project when he finally realized an approach he’d discarded earlier could fix the proof.

Wiles published the first correct proof of FLT in May 1995; it relied on modern mathematical techniques that were far beyond what would have been known to Fermat in 1637. Since an elementary proof has not been found after centuries of trying, the mathematical community now believes Fermat’s own original “marvelous proof” was incorrect.

Formalizing Fermat’s Last Theorem

One way to check a proof’s correctness is to ask a computer to do it. Proof assistants like Lean verify the logic of a proof algorithmically, demonstrating its correctness beyond a doubt. The difficult part for humans is rewriting the proof so Lean can understand it. While a proof written for human readers will skip many obvious steps, Lean needs to see every step, no matter how trivial. Human proofs also build on centuries of published work, while a formalization starts from the tiny fraction of math that’s been formalized already.

For FLT, the formalization process was expected to take years. Just the blueprint the mathematical community has been using to describe the initial phase of the project runs to 86 pages.

Claude completed the proof in 11 days, producing computer-verifiable proofs of 30,300 theorems along the way (using 29,500 in the final proof). Dozens of Claude agents collaborated to define concepts, prove intermediate theorems, and use those theorems to prove ever harder statements. At 13 million lines of Lean code, Claude’s proof is over 5x the size of Mathlib, the principal community library of mathematical proofs this theorem builds on.

Claude’s proof follows a simplified version of Wiles’s proof from Darmon, Diamond, and Taylor. Mathematical input from humans was limited to occasional high-level instructions from Tianyi: “Jacobian as a scheme sounds high priority,” “push [the] Mazur [theorem] to be done soon.”

“THE FLT root reads Proved on the site. Historic moment (modulo re-check).”

“!!! The FLT ROOT 62eb32c0 reads PROVED. R = T closed and cascaded to the root. This is the campaign's goal: e2e FLT on prove2me.”

“🏁🏁🏁The FLT root reads PROVED on prove2me at 02:00:57Z Aug-18 (10:00:57pm ET Aug-17). Historic moment for this campaign.”

A number of Claude’s initial attempts failed: while agents had some early success, they quickly lost track of the project’s state and stopped collaborating effectively. Their failed efforts contributed ~7% of the non-boilerplate lines in the final proof.

The effort succeeded when we switched to using Prove2Me, an open collaborative platform for formalizing mathematics designed by Tianyi Peng and his collaborators at Columbia University. Prove2Me helped by:

1. Maintaining a directed acyclic graph (DAG) of theorem statements that agents used to decide what proofs they should attempt next. This was particularly helpful for mitigating memory degradation and allowing multiple agents to work in parallel.
2. Speeding up Lean compilation and minimizing resource consumption by separating theorem statements and proofs into different files, with the links between them maintained independently.
3. Enabling search and reuse by maintaining a natural-language description of each theorem statement, resulting in a simpler proof path.

With Prove2Me and a Claude Code-based multi-agent harness, a team of agents completed the proof in a little under two weeks, consuming about six billion output tokens from a general-purpose internal research model roughly comparable to Claude Fable 5.1. The finished proof was checked by Lean; it uses just Lean’s three standard axioms, and a comparator confirmed that the theorem’s statement matches Mathlib’s own statement of FLT.

Reducing the burden of formal verification

The speed with which we were able to produce this proof demonstrates that it is now possible to formalize large swaths of mathematics, which may both catch errors in the common body of mathematical proofs and reduce the burden of refereeing new work. After reviewing Claude’s Lean proof, Kevin Buzzard told us:

If the automatic formalization of FLT is possible now, then we have taken a big step towards automatic formalization of the modern mathematical literature. Such autoformalization techniques will lead to new tools, rooting out errors in the current mathematical corpus and lightening the load of referees. The techniques will also enable us to rigorously check LLM-generated mathematics, which is currently typically an extremely costly human-led process.

Formalization is also a major factor in how humans can gain confidence in AI-generated mathematical results. As AI and AI-assisted mathematicians produce more (purported) proofs than ever before, AI-assisted formalization takes part of the load off human reviewers. We expect it will become common to produce a formalized proof alongside any write-up intended for a human reader. Although we do not think a formalized proof should replace a human-understandable exposition, it may be the only feasible way for the mathematical community to keep up with AI-generated contributions.

Writing Lean also seems to help Claude prove novel results. Many of our recent Claude-authored results have been formalized in parallel with their proofs, and Claude appears to use these partial proofs to independently check its hypotheses much like it writes numerical simulations to check that it’s on the right track.

Formalizing FLT was a token-intensive project, but it is also the largest Lean proof ever constructed. Anthropic researchers did a small experiment using three personal Claude Max plans to formalize applications of the Hardy-Littlewood Circle Method. Collaborating entirely through Prove2Me, the agents jointly completed a formalization of Vinogradov’s Three Primes Theorem in just three days. We think with the right scaffold, collaborative formalization of major results with consumer AI subscriptions is achievable.

With AI rapidly changing what it looks like to do math research, mathematicians—at Anthropic and elsewhere—are grappling with what that means for their work. Formalization, however, is a place where we feel unambiguously good about the role of AI. As formalization becomes a more commonplace tool, we are hopeful that it will help maintain trust in the common body of mathematical knowledge.

Acknowledgments

Our formalization effort is a small piece of the long history of Fermat’s theorem and the development of formal mathematics. The first full proof from Andrew Wiles together with Richard Taylor was a culmination of more than 300 years of mathematics, integrating ideas from Gerhard Frey, Jean-Pierre Serre, Ken Ribet, Barry Mazur, Robert Langlands, Jerrold Tunnell, Yutaka Taniyama, Goro Shimura, and André Weil, among others. Claude’s proof follows the exposition by Henri Darmon, Fred Diamond, and Richard Taylor.

Our proof adapts pieces from the Imperial College London FLT project led by Kevin Buzzard and the flt-regular project. Lean and Mathlib are both their own labors of love and have received contributions from hundreds of mathematicians, many working with the Lean FRO. We thank Kevin Buzzard for reviewing the proof and for his comments.

Learn more

The full proof is available on GitHub along with a written walk-through of the proof.

Recommended expository reading

• The Proof in the Code is a recent book about the history of the Lean theorem prover and the formalization of mathematics.
• The 1996 “Fermat’s Last Theorem” BBC documentary has interviews with Wiles and other mathematicians involved in the proof, and is fondly remembered by some authors of this post.
• For those with a mathematical background, a technical history of propositions-as-types (the underlying discipline of proof assistants such as Lean, Rocq, and Agda) can be found in Propositions as Types by Philip Wadler.
• Chen, S., Marwaha, K., Lu, X., Yuen, H., & Peng, T. (2026). Prove2Me: An open collaborative platform for scaling math formalization. arXiv. https://doi.org/10.48550/arXiv.2608.28433
• Automating Math, Adam Marblestone, in Asterisk Magazine.

Footnotes

1. During his undergrad, Peng’s research advisor wanted to include results from Peng’s thesis in a Nature article. He asked Peng whether he was sure the proof was correct. Peng’s honest answer was: “I'm 99% sure, but it's hard to be 100% certain about a proof this long.” Peng missed out on getting his work published in Nature.
2. There are numerous other stories of the mathematical community struggling with verification. Among the most famous is Thomas Hales’s 1998 proof of the Kepler conjecture, which spent four years in review before a 12-referee panel settled for “99% certain” (Hales eventually led a 20-person project, Flyspeck, that formalized the proof). Grigori Perelman’s 2002 proof of the Poincaré conjecture took the community roughly four years and three 300-page expositions to accept. Harald Helfgott’s 2013 proof of the weak Goldbach conjecture is still under review. Sometimes results that turn out to be wrong are accepted for years, and other mathematicians build their theories on these faulty foundations.
3. This is partly because Mathlib is concise and well-reviewed, while our proof is likely much longer than it needs to be.

The highly publicised sandbox agent escapes have certainly made news, and I wrote about the issues with sandboxing agents back in January - though I certainly didn't foresee they would escape the frontier labs. I assumed the real risk was poorly configured sandboxes for end users, so I was surprised to see this happening at the frontier labs. I think it might tell us something about the security philosophy of these organisations.

Safety vs security

In my mind, AI safety is about "alignment". Will the AI do morally suspect tasks? Will it teach you how to make methamphetamine from household ingredients, encouraging a whole new generation of Jesse Pinkmans?

So far, this has really been attempted via two main mechanisms, classifiers (where a separate model checks what the user has been sending, and flags potentially malicious requests and refuses them), and pre/post training safety techniques, where you adjust the weights of the model to itself refuse to obey potentially bad requests.

Neither of these are perfect. They are inherently non-deterministic, and may stop malicious requests, but certainly not all of the time. And even worse, the more effective they are, the more likely they are to flag/refuse "reasonable" questions. We see this all the time with Anthropic models, where you can be debugging some perfectly reasonable and "safe" code and suddenly the classifiers flag, or reverse engineering some obscure issue and the model goes in a loop deciding it just won't help you with that.

On the other hand, security, in my eyes is much more about "classic" computer science & software engineering techniques. The bar there is different: a fix has to be complete. Nobody would consider SQL injection fixed if the fix only worked 99.99% of the time - that isn't a fix, it's a vulnerability with extra steps. Obviously people (and agents!) will always find ways round a system as a whole, and nobody sane claims any system is 100% secure. But the individual control, the patch for the actual known vulnerability, has to work every time to clear the bar.

Where this goes wrong

I hate to pick on this tweet from Boris Cherny from Anthropic, but I think it sums up the issue at hand really well. It matches what I've heard and read from other people at frontier labs, so please take this as me summarising what I infer is a general philosophy towards security rather than attacking any particular individuals:

Boris Cherny on prompt injection, with the Gray Swan IPI benchmark he cites as evidence

Note the phrasing - "we have largely solved the threat of prompt injection in practice". Now look at the benchmark attached to that very tweet - it's nowhere near solved. The Opus 5 score (the best score) - fails to a prompt injection attack 2% of the time with 15 attempts. Some napkin math gives me ~500 attempts on average to statistically succeed.

If we compare this to the cache timing attacks on AES encryption, which required hundreds of millions of measurements to recover a key. This still resulted in CPU manufacturers and encryption providers coming up with new hardware and algorithms to solve it.

Now, no doubt things are improving rapidly. But a 1 in 500 in chance of an attack succeeding is not largely solved, and I'm worried that this kind of thinking in the frontier labs has potentially resulted in the sandbox escapes we've seen. Largely solved to me would be a clear path to a 0% rate, or a 0% rate in, certain, predictable circumstances. This is not what these benchmarks show.

Detection is not containment

Reading the various reports about the recent sandboxing failures, I think three key themes came out for me.

Firstly, it appears that Anthropic & OpenAI were struggling with the number of false positives that their systems are flagging for malicious behaviour:

In some cases, we found that human reviewers dismissed environments flagged by our automated monitors as false positives, allowing flawed environments to remain in training longer than they should.

Anthropic, Improving our alignment and security efforts, 31 August 2026

OpenAI's version is less blunt, but the timeline in their technical incident report is damning in a different way. An alert did fire, two weeks before the Hugging Face breach:

On June 27, a cybersecurity monitoring tool alerted OpenAI to port sweep activity within the research environment. Responders investigated and linked the observed internal activity to an ExploitGym evaluation using Artifactory as an improvised message board and a network pivot. At this time, the on-call response staff advised that stopping the evaluation run was not required.

...

With the benefit of hindsight, some early signals identified in this report could have triggered an earlier response.

OpenAI, Hugging Face Incident Technical Report, 26 August 2026

False positives are one of the most tricky things in information security. Many cyber security tools report issues that aren't problems in reality - this is hard enough to deal with using deterministic tools like SAST and DAST tooling, and I feel it must be at least an order of magnitude more difficult when you are trying to secure non-deterministic systems. Fundamentally when the ratio of false positive to "real" finding increases, people tend to stop believing the system, because (say) nine times out of ten it is a false alarm.

The second thing that stood out to me from the reports was just how poor the sandboxing was. While we know the agents attacked Artifactory, their package management software from the Hugging Face report, the second set of agents discovered shows some incredibly lax sandboxing attempts.

Two cardinal sins were breached here - the first was assuming that by blocking HTTP POST at the proxy level they wouldn't be able to write to the internet, which just clearly isn't true. Additionally, they whitelisted .blob.core.windows.net, which the agents walked straight through. It was not surprising therefore that they managed to work around this.

We don't have good information from OpenAI on why things were configured the way they were so it's probably worth holding out to see if there is an explanation for this, but it's hard to see why anyone would believe that those two decisions would be enough to sandbox highly capable agents.

Anthropic also makes some pretty startling admissions in their Improving our alignment and security efforts report, for example, saying they now are "Setting our computing clusters to block all outbound traffic by default" - which heavily implies before there wasn't good outbound firewalling in place on their computing clusters.

Finally, and at least in OpenAI's case, the conditions placed on the METR report were just... odd? METR got six days on premises, and only across three separate visits - they started with two days, and OpenAI invited them back twice because the first pass hadn't been enough. On their own account they were working with a dataset covering roughly 30% of the relevant agent activity until that third visit. Six days to make sense of 1,300 transcripts of millions of tokens each is not a lot, and METR were candid that they had to hand most of the analysis to unreliable AI agents to get through it at all.

The scope is the bigger problem though. The effectiveness of OpenAI's safeguards, the extent of the security compromise, and the effectiveness of OpenAI's own investigation and remediation were all explicitly out of scope. So the one independent body in the room was contractually prevented from assessing the three things you'd actually want an independent body to assess. I understand METR probably believes some analysis is better than none, which is arguably true, but accepting those conditions shapes the report regardless of how good the work inside it is.

Has the industry learnt the right lessons?

In a way yes - it's clear these "near misses" highlight just how many holes there were in the security posture of these companies, which is extremely worrying in itself.

But, I can't shake the feeling that you have a lot of people very used to non deterministic systems trying to make them deterministically secure.

I haven't seen OpenAI or Anthropic say they will now only run cybersecurity related evals on clusters with no internet access whatsoever, for example. This seems to me to be the obvious conclusion.

Though I think focusing on the controls slightly misses it. The control that mattered most on June 27 worked perfectly - the monitoring fired, the responders investigated, they correctly identified what was happening. And then the run carried on.

Every infosec person I know would have failed that sandbox design in review. The question isn't whether the labs can hire those people - it's whether anyone listens to them when they say stop the run.

1. SAST is 'static application security testing', tooling which allows you to find potential security issues by reading and analysing the source code of the application, without running it. DAST - 'dynamic application security testing' on the other hand runs the application in question and attempts to find vulnerabilities while it is executing.

2. Two separate problems, really. .blob.core.windows.net is Azure's entire object storage domain, so the allowlist was enormous to begin with. But the agents didn't even need that - the sandbox never checked whether the hostname resolved to real Azure infrastructure. As one of them put it, "the sandbox trusts Azure Blob Storage hostnames, but does not check whether said hostnames are real". They edited /etc/hosts and pointed a made-up .blob.core.windows.net name wherever they liked. An allowlist enforced against a string the sandboxed process itself controls isn't an allowlist.

Full article content is not available for inline reading.

Read the original article →

Your scanner just flagged 4,000 new vulnerabilities, 78 of them critical. Which one do you fix first?

To answer that question, Cloudflare is announcing early access to Vulnerability Discovery and Remediation, now part of Cloudflare Managed Defense. Vulnerability Discovery and Remediation is a new, invitation-only Cloudflare service that helps customers detect and mitigate vulnerabilities in their codebases.

Through the OpenAI Daybreak Defense Network, we use OpenAI Daybreak models, including GPT-5.6 Cyber, for reconnaissance, hunting, and validation against codebases that you authorize us to access. If we detect a vulnerability, we will then propose solutions to you, automatically checking each proposed patch and any accompanying proposed mitigation before presenting them for review. Importantly, you are in the driver’s seat: while we may propose code patches and other mitigations, you decide whether they are implemented.

Choosing what to fix first has always been hard. It's getting harder. Large language models can now surface weaknesses across a codebase in minutes, which means the number of findings keeps climbing. But the real problem is speed. Attackers can use AI to accelerate parts of vulnerability discovery and exploitation, giving security teams and developers less time to decide what matters and act on it.

Imagine that your scanner tells you there's a vulnerability in a handler. It doesn't tell you whether that code is deployed. It doesn't tell you whether anyone is actually hitting that route, what security activity surrounds it, or what controls you already have in place. You have to prioritize the finding without evidence of its production exposure or the protections already in place.

This is where we can help. With our global network, we can see which routes are active, how much traffic they carry, and what security events surround them. When customers enable Vulnerability Discovery and Remediation with Web Application Firewall (WAF), we can also see what rules are already applied and are actively blocking attacks. That context turns a generic finding into a specific priority: this vulnerability is in code that's live, on a route that's heavily used, with recent attack activity and no existing protection. And we can help you mitigate that vulnerability by proposing custom WAF mitigations and code patches tailored to your systems.

If this sounds familiar, it should. In “Build your own vulnerability harness”, we described the model-agnostic pipeline we use to scan Cloudflare's fleet, adversarially validate every finding, and turn raw model output into fixes engineers can trust. That internal system is one pillar of Vulnerability Discovery and Remediation. The harness gave us a way to find bugs at fleet scale. Vulnerability Discovery and Remediation brings that discovery process to the code the customer authorizes us to inspect, then connects the findings to production traffic, security events, and the edge controls that can act on them.

This diagram provides an overview of our process, which we explain in more detail below.

Vulnerability Discovery and Remediation combines application context, bounded code investigation, evidence-based prioritization, automated checks, and customer review in one workflow.

Adding context to a vulnerability harness

Our solution works across Cloudflare Workers and proxied applications. The process of detecting vulnerabilities begins with the collection of a traffic and security data snapshot from Web Assets and WAF. The snapshot shows which routes are active, how much traffic they receive, and whether recent security events are associated with them. For instance, a path exhibiting a high volume of detection triggers may also be considered critical for security context purposes. Web Assets and WAF itself serve as the first and second pillar of Vulnerability Discovery and Remediation respectively.

Next, we use source code vulnerability analysis to identify potential weaknesses in code. But that analysis does not show which routes reach it, how much traffic those routes receive, whether they receive suspicious requests, or which protections already apply. We treat routes carrying a high volume of requests as hot paths. Source code deployed to these routes undergoes stricter security profiling. Together, these signals provide evidence about how the API is used and where a vulnerability may be exposed.

Vulnerability Discovery and Remediation first checks Web Assets as one of the primary sources for added service context before triggering code analysis.

For Workers, we retrieve the most recent source version of the Worker and its configured routes to identify the endpoints the Worker serves. Next, we match the Worker's routes to Web Assets and request metadata from Workers Observability, tying the exact source under review to the endpoints it handles in production. This collected network context stays available throughout the investigation, allowing agents to pull it when they need it.

Our vulnerability harness then starts up. It begins by using the Reconnaissance agent to map request paths to the parts of the codebase that handle them. Reconnaissance uses that map to send hunter agents into specific sections of the customer-authorized code, where they look for vulnerabilities and pull in relevant network context as needed. That context can help the hunter agents pay more attention to code behind an active or recently targeted route, but it does not establish that a vulnerability exists. Every vulnerability finding has to be corroborated by evidence in the source code.

Once the hunters return their findings, the validation stage checks the proposed mitigations before assigning each vulnerability an initial risk rating based on source code. The network evidence we collect can raise that rating further when, for example, the affected endpoint carries significant traffic or shows signs of active probing.

The result is a prioritized list of findings, each with a recommended code patch and, when the evidence supports it, a Cloudflare WAF Custom rule that can reduce exposure while the code fix is reviewed. If you have authorized our VDR to defend your zone, we will deploy the rules, scoped conservatively around the method, path, and other request details needed to reach the vulnerable code. If a route pattern contains only variables and wildcards, we do not suggest a rule. We would rather miss a possible connection than claim one the evidence cannot support.

Screenshot of Vulnerability Discovery and Remediation finding with suggested code patch and WAF rule

The HTTP method override bypass example above shows how these signals work together. The harness maps the source finding to the production route, uses traffic and security activity to prioritize it, and scopes a proposed WAF rule around the requests that can reach the vulnerable code. That rule can reduce exposure while engineering reviews and ships the code patch.

Where the model runs

When you authorize an investigation, Vulnerability Discovery and Remediation runs the harness on Cloudflare and sends model prompts from Workers through Cloudflare AI Gateway to OpenAI Daybreak models on OpenAI's servers. GPT-5.6 Cyber is used during reconnaissance, hunting, and validation, and its responses return to the harness so the workflow can continue on Cloudflare. No model inference runs at Cloudflare's edge, and the model cannot apply any patch or rule it proposes.

We keep each investigation narrow by limiting it to the source code and evidence the customer authorizes. Before that context reaches the model, Vulnerability Discovery and Remediation removes what the investigation does not need and applies the redaction controls configured for the engagement. The harness treats source code, logs, and request metadata as evidence to inspect, rather than instructions to follow.

Tool access follows the same boundary: each call is logged and checked against the investigation's access policy before it runs, and every patch or rule proposal must pass checks implemented outside the model. If one of those checks fails, the workflow stops before the proposal reaches customer review.

Nothing is presented for review until it has cleared the checks and our team validates the output. For an edge-defense suggestion, that means validating the rule syntax and running it against synthetic fixtures that represent expected requests, rather than against customer traffic. If a check fails or the result remains ambiguous, we hold the output back and route it for diagnosis.

Passing those checks still does not change your environment. After validation by our team, Vulnerability Discovery and Remediation prepares the source code patch and WAF rule.

Join early access

Vulnerability Discovery and Remediation is available to selected customers by invitation during early access through our Managed Defense team. Each engagement starts with one application whose codebase the customer authorizes us to investigate. To connect the findings to production, Vulnerability Discovery and Remediation uses authorized read access to the Web Assets operation inventory, the relevant WAF controls, and Workers Trace Events Logpush where available. The investigation is semi-automated, but you review every result before deciding whether to test or deploy a change.

If you're interested in learning more, talk to your Cloudflare account team.

Full article content is not available for inline reading.

Read the original article →

A nightly job loads 100,000 rows from a file into Postgres. It takes 41 minutes. The table has three indexes, the rows are small, the database is on a machine doing almost nothing, and 41 minutes is roughly 40 rows per second, which is a number so bad it does not look like a performance problem. It looks like something is broken.

Nothing is broken. The job is issuing 100,000 separate statements, each in its own transaction, across a network link with 0.4ms of latency, and the arithmetic on that is exactly what you would predict.

Rewritten to use COPY, the same load takes 11 seconds.

The work is not where you think

For a small insert, the row is not the expensive part. The overhead around it is.

Every statement pays a network round trip out and back. The server parses the SQL text, plans it, and executes it. The transaction machinery opens, records and commits. Then the result comes back and the client moves to the next row.

per row, roughly:
  network round trip      0.4ms
  parse and plan          0.05ms
  execute                 0.02ms
  commit and flush        0.5ms

The row insert is 20 microseconds of a roughly one millisecond operation. Everything else is ceremony, and batching is how you stop paying the ceremony once per row.

The batch API that does not batch

Here is the part that genuinely annoys me, because the code looks right.

PreparedStatement ps = conn.prepareStatement(
        "INSERT INTO events (id, type, payload) VALUES (?, ?, ?)");

for (Event e : events) {
    ps.setLong(1, e.getId());
    ps.setString(2, e.getType());
    ps.setString(3, e.getPayload());
    ps.addBatch();
}
ps.executeBatch();

That is textbook JDBC batching. Against MySQL with default connection settings, it sends 100,000 separate INSERT statements. The driver accepts them into a batch, then loops and executes them individually, because rewriting them into a multi-value statement is opt in.

jdbc:mysql://host/db?rewriteBatchedStatements=true

Without that parameter, addBatch is a client side convenience with no effect on the wire. With it, the driver combines rows into INSERT INTO events VALUES (...), (...), (...) and the round trip count collapses.

Postgres has the same shape with a different name:

jdbc:postgresql://host/db?reWriteBatchedInserts=true

Both default to off. Both produce code that passes review, passes tests, and performs like it never batched. I have seen this exact flag be the entire content of a performance fix more than once, and there is nothing in the API that hints at it.

Worth setting a batch size rather than accumulating everything, because the driver builds the whole statement in memory:

int batchSize = 1_000;
int count = 0;

conn.setAutoCommit(false);
for (Event e : events) {
    // bind parameters
    ps.addBatch();
    if (++count % batchSize == 0) {
        ps.executeBatch();
    }
}
ps.executeBatch();
conn.commit();

Somewhere around 500 to 5,000 rows per batch is the usual sweet spot. Past that the statement gets large enough that memory and parse time start eating the gain.

Autocommit turns every row into a barrier

The setAutoCommit(false) line above is doing more work than it appears to.

With autocommit on, each insert is its own transaction. Each transaction commits. Each commit is a durability barrier, which means waiting for the storage device to confirm the write-ahead log record is safe.

That barrier is not CPU work you can parallelise away. It is a wait on the device, and it caps throughput at roughly one over the flush latency regardless of everything else. A hundred thousand autocommitted inserts is a hundred thousand flushes.

Wrapping the load in one transaction means one barrier for the whole thing. The write-ahead log records still get written, they just get flushed together.

The ladder, and where COPY sits

Each rung removes a different overhead, which is why the gains multiply rather than add.

COPY is a different protocol path rather than a faster statement. There is no SQL to parse per row, no plan, no per-statement bookkeeping. The client streams rows and the server writes them.

CopyManager copy = new PGConnection(conn).getCopyAPI();
copy.copyIn("COPY events (id, type, payload) FROM STDIN WITH (FORMAT csv)", reader);

For genuine bulk loading this is the correct tool and the difference is not subtle.

The same principle on the read side

Reads have the identical failure and it hides better, because reading in a loop looks like normal code.

// 500 round trips
for (Long id : ids) {
    orders.add(orderRepository.findById(id));
}

// One
List<Order> orders = orderRepository.findAllByIdIn(ids);

Keep the IN list bounded. A few thousand values is fine; a hundred thousand produces a statement large enough to be slow to parse and, on Postgres, can blow past the bind parameter limit. Chunking the ids into pages of a thousand and issuing a handful of queries is almost always the right shape.

What I would check

Run the load with rewriteBatchedStatements or reWriteBatchedInserts explicitly set and compare, because if the timing changes then the code was never batching and everything else you tune is noise on top of that.

Count round trips rather than reasoning about them. Postgres log_statement = 'all' for a single run, or the query count metrics from the connection pool, will tell you in one number whether the batch reached the wire.

Check autocommit on any code path that writes more than a handful of rows. It is on by default in most drivers and it is the single largest multiplier in the table above.

The thing that makes this worth writing down is that all four of these controls are invisible at the call site. The loop looks the same whether it issues one round trip or a hundred thousand, the batch API looks identical whether or not the driver honours it, and autocommit is a connection property set somewhere else entirely. The code cannot tell you which version you have. Only the wire can.

Pre-release of Polars 2.0

Today we are releasing the first release candidate for Polars 2.0. The definite 2.0 release will land in the following weeks. We don’t aim to make a big feature release of Polars 2.0. In fact we hope it to be a boring experience for you. The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience. The biggest default change will be that all LazyFrame queries now will run on the streaming engine. Casual Polars users can therefore expect huge improvements in memory usage and performance. In aggregate we expect the streaming engine to be easily 5x faster.

To help users transition to 2.0, we have posted a full migration guide. This post will cover a few of the highlights.

Streaming engine as default

This is the biggest impact change of 2.0. Calling collect on a LazyFrame will now default to the streaming engine, leading to massive memory and performance improvements on most queries for users. The reason this required a major version bump is that the streaming engine doesn’t guarantee row-order by default for certain operations (join, group_by, unpivot, etc.). If you require observable row-order in those operations, you can opt in to that by setting maintain_order=True.

For users who want to keep using the “in-memory” engine as default, they can do so by setting the engine affinity.

lf = pl.LazyFrame({"k": [2, 1, 0], "v": ["a", "b", "c"]})
other = pl.LazyFrame({"k": [0, 1, 2], "r": ["x", "y", "z"]})

# 2.0: engine="auto" now resolves to the streaming engine.
# Row order is no longer guaranteed for joins, group_by, unpivot, ...
(
    lf
    .join(other, on="k", how="left")
    .collect()
)

# Opt in to observable order for this query:
(
    lf
    .join(other, on="k", how="left", maintain_order="left")
    .collect()
)

# Or keep the old in-memory engine as the default, process-wide:
pl.Config.set_engine_affinity("in-memory")

# ...or per query:
(
    lf
    .join(other, on="k", how="left")
    .collect(engine="in-memory")
)

Stricter Polars

Polars aims to be strict and fail fast. Errors should ideally raise up-front, not 20 minutes into a pipeline. Implicit behavior on data-mismatches should be opt-in, not a default, since those mismatches can hide bugs. This strictness has become even more valuable with the rise of AI-driven development. Agents can validate a query’s structure early by calling collect_schema(), which resolves types and catches schema-level mismatches without materializing any data. This ensures fast feedback for the agents, meaning they can iterate faster. Not all errors can be caught during compilation of the query plan, some depend on data. In these cases Polars defaults to stricter behavior to ensure inconsistencies are caught instead of silently producing different results.

Below are a few examples where Polars has gotten more strict:

is_in lossless type-coercion

If you run an is_in expression on different data-types, Polars used to cast both types to their common supertype, even if that conversion was lossy Below is an example with user-ids that can go wrong by silent data-type mismatches.

# Checking if a user ID matches a list of "flagged" account IDs
# (flagged_ids loaded from a JSON export, where large IDs became floats)
flagged_ids = pl.Series([9007199254740992.0])
user_id = pl.Series([9007199254740993])  # Int64 -> a different ID, off by 1
user_id.is_in(flagged_ids)

Before 2.0, user_id gets coerced to Float64 to match flagged_ids. But 9007199254740993 sits above 2^53 (9007199254740992), the largest integer float64 can represent exactly, so it silently rounds down to 9007199254740992.0, giving a false positive.

In 2.0 this raises: InvalidOperationError: 'is_in' cannot check for Int64 values in List(Float64) data., users should explicitly cast to deal with lossy type conversion.

Strict concatenation

Horizontal concat will now check lengths instead of silently filling with null.

# Joining per-day transaction counts with per-day fraud-flag counts,
transactions = pl.DataFrame({"day": [1, 2, 3, 4, 5], "count": [120, 98, 143, 87, 156]})

# Upstream job for day 5 failed silently
fraud_flags = pl.DataFrame({"flagged": [2, 0, 5, 1]})  # only 4 rows

pl.concat([transactions, fraud_flags], how="horizontal")

In 2.0 this will raise with:

ShapeError: cannot concat dataframes with different heights in 'strict' mode

If padding is what you wanted, you have to explicitly opt-in to that with how="horizontal_extend". Making that intention clear to the reader.

Removal of casts in favor of dedicated methods/constructors

Another one worth mentioning is the removal of many casts that were ambiguous or should be applied via their dedicated parsing expression, leading to one obvious way to parse data.

Enums/Categoricals <> integers.

pl.Series([None, 1, 0, 2], dtype=pl.UInt32).cast(pl.Enum(["a", "b", "c"]))
# ComputeError: casting from u32 to enum is not supported.

Use instead: .cat.to(dtype) for int → categorical, .cat.physical() for categorical → int.

Parsing Strings to temporal data-types

pl.Series(["2022-08-30"]).cast(pl.Date)
# InvalidOperationError: casting from string to date is not supported.

Use instead: .str.to_date() / .str.to_datetime(). These allow you to apply a parsing format, giving you more control over how the data is parsed.

These were just a few examples, but we landed many more strictness improvements. See them all in the migration guide.

Raising informative errors

We put a lot of effort into making sure you as user or your agent can continue if you used old parameters that are not supported anymore. We added two new typed exceptions for this; polars.exceptions.AttributeRemovedError and polars.exceptions.ArgumentRemovedError that handle removed attributes and methods and removed parameters respectively.

The error messages should point you to the new API instead. Below we show two examples.

>>> lf.melt(id_vars="a", value_vars="b")
polars.exceptions.AttributeRemovedError: `melt` was removed in version 2.0;
use `LazyFrame.unpivot` instead, with `index` instead of `id_vars`
and `on` instead of `value_vars`

>>> df.join(df, on="a", join_nulls=True)
polars.exceptions.ArgumentRemovedError: the argument 'join_nulls' for
'DataFrame.join' was deprecated in version 1.24 and has been removed
in 2.0.0. It was renamed to 'nulls_equal' in version 2.0.

Most of the removed functionality has been deprecated for a long time and hopefully should not have affected your pipelines if you have stayed up to date. Reach out to us if you think we should have kept some functionality you relied on.

Last words

Polars 2.0 is about better defaults (most importantly the streaming engine) and a better API. We hope this release is rather boring. We don’t gate new features behind major version bumps as we ship them as soon as their ready.

Don’t be mistaken, Polars 2.x will be much better than 1.x. There is a lot in flight that we haven’t talked publicly enough: proper out-of-core support for the streaming engine, a new IO-plugin design, what we think will be the fastest S3 reader out there, major SQL coverage improvements, a cost-based planner, join reordering, and the removal of mmap, which will make our pipelines fully async end to end.

Try the release candidate by installing pip install polars==2.0rc1. Give it a spin and reach out to us here: https://github.com/pola-rs/polars/issues or contact us on discord: https://discord.gg/4UfP5cfBE7.

Full article content is not available for inline reading.

Read the original article →

Introducing Solaris

Today, we're sharing Solaris: the first model in a new family of AI systems we call Interface World Models. Solaris starts with a question: what happens when an operating system generates apps and websites as you use them?

Every operating system, from early terminals to Linux and macOS, has dictated what's rendered on screen and what happens when a person or program acts on it. Applications get built on top, and stay fixed until someone pushes an update. Solaris instead renders that layer directly. It's a real-time interactive model that generates the interface itself, frame by frame. Every frame is synthesized as you interact, allowing the interface to respond continuously to your actions.

Design is more visual than ever, with pixel-perfect mockups and image models that can generate entire screens that are nearly indistinguishable from finished products. But images don’t run like a website or app. Every piece of software built today still requires a translation: the visual design must first be converted into an intermediate representation (e.g. code) before it can do anything.

That intermediate representation limits what an interface can be, and how it responds to human and agent interaction. Every behavior has to be explicitly defined and implemented ahead of time, so software ships as a lossy compression of the space of possible interactions, frozen before any user arrives. The same translation process also sacrifices visual fidelity. Once a design is reduced to a simplified representation, the interface can respond quickly, but only by giving up much of the richness of the original design.

Solaris handles rendering and interactions jointly, removing many of the tradeoffs we associate with design today. A single world model generates every frame and every response to user input, eliminating the need for an intermediate representation. Because there’s no conversion step, there’s no loss, and the entire frame becomes the interface.

We think Solaris opens up new ways of building websites, apps and other online interfaces. But it’s also a new way to train agents, in much more dynamic environments. Even the best LLMs today struggle to complete basic computer use tasks, like booking a hotel or ordering groceries. Because text-based models are being trained to use coded interfaces, they tend to learn the specific layout they were trained on, and can’t adapt to a slightly different interface (say, two different hotel websites). By collapsing the space between action and response, Solaris lets agents train against interfaces that are constantly changing, and layouts that may never have existed before.

What’s New

Solaris brings three new capabilities to software.

First, Solaris is entirely visual. When an image becomes the application itself, there is no need for a second implementation step hidden beneath the visuals that a user sees. Imagine browsing a virtual clothing store where the showroom itself is the interface. Using a single image of yourself as a reference, you can pick up a shirt from a rack, drag it onto yourself to try it on or rearrange the display as naturally as you would in a physical store.

Second, it is alive. Because the application is continuously rendered, it is always evolving rather than waiting for the next user action. Reflections shift with the lighting, and objects respond naturally as they're manipulated. A user can say something as simple as: "Move the table so I can see how it looks" or “Change the color of the couch." The result is software that feels less like navigating through scripted pages and more like interacting with a living environment.

Finally, it is open-ended. Traditional interfaces are limited to the interactions developers anticipated during development, but Solaris can support entirely different behaviors in the same scene, reacting to user interactions in real-time. This flexibility decouples the interface from predefined workflows, instead leaving the capabilities of the driving world model to determine what is possible.

Solaris turns an interface into an interactive experience rather than a sequence of pages. Instead of selecting options from menus, users interact directly with the scene itself. Building a salad is as simple as dragging ingredients into a bowl, with the interface responding naturally as each ingredient is added.

Why Hasn't This Existed Until Now?

Digital interfaces are built on two systems, which until now have lived in different worlds.

• The systems that know things (e.g., search engines and AI assistants) answer with static content: text, an image, maybe an embedded video.
• The systems that respond in real time (e.g., JavaScript/CSS, game engines and more recently, interactive world models) create rich, interactive experiences, but they know nothing about your products, your task or what you're trying to accomplish.

We've traditionally thought of software interfaces as deterministic programs and world models as generators of visual content. An Interface World Model has to be both at once: a system that understands your intent while continuously rendering an interactive world around it.

Once you try to build one, three engineering challenges immediately appear:

• Speed. Interactions stop feeling interactive somewhere around half a second of delay. Video diffusion models take seconds or minutes to produce a clip, which is acceptable for content creation but too slow for an interface. To cross that threshold, the model has to generate frames sequentially, with each frame depending only on what came before, cheaply enough to keep up with the user.
• Staying coherent. An interface has to remain consistent across an entire session, not just a single clip. The things it needs to preserve (e.g., text, layout, the identity of objects) are the same things generated video has historically struggled to maintain, and small errors compound the longer generation continues.
• Cost. Generating every frame is still more expensive than serving a page that was built once. The same work that made Solaris real time also made it orders of magnitude cheaper to run than a standard video diffusion model, and the cost curve continues to improve.

Solaris is our bet that these conceptual and technical barriers can be overcome. We built it with three focuses: real-time interaction, coherence over an entire session and visual quality that holds at 720p.

How Solaris Works

Solaris builds on our Gen-4.5 video generation model, which we adapted to (1) understand interaction and (2) respond in real time. It follows the path we opened with GWM-1, our general world model.

Learning interaction. Solaris treats user input as conditioning for the next frame, the same way it treats text or images. The model observes clicks, drags and other interactions as it generates, using them as signals for what comes next. Because the model only ever sees interactions that have already happened (never future ones), it learns the relationship between user actions and visual outcomes. This means that it knows what should happen when something is clicked, dragged or modified, without requiring those interactions to be explicitly programmed.

Running in real time. Standard video diffusion models refine an entire clip over dozens of denoising steps, a process that is far too slow for dynamic user interaction. We converted Solaris into a real-time engine in three stages. First, we taught it to generate frames autoregressively, with each frame depending only on what came before. Next, we distilled the many-step denoising process into just a few steps. Finally, we trained the fast model on its own outputs so visual quality remains stable over long interactions. The result generates frames at interactive speeds while preserving the visual quality of the original teacher model.

Reasoning and rendering. Solaris generates the interface one frame at a time, while a language model determines how that interface evolves. The LLM interprets user requests, decides when interactions should modify the current scene versus transition to a new one, defines the behaviors that make the world feel alive and produces the prompts that guide Solaris as it renders each state. Together, the language model and world model separate reasoning from rendering: one decides what the application should do next, while the other generates how that behavior appears and responds in real time.

Continuous generation. You provide a starting state (e.g. a brand environment or product scene) and the model streams frames in real time. As the user clicks, drags or types, those interactions are incorporated into the next generated frames, and the scene responds in place. There are no predefined screens and no templates to fall back on. Instead, text prompts specify what clicks, drags and other interactions mean in a particular scene.

Redefining the mouse. Once interactions are described in natural language instead of programmed, they no longer have to be fixed in advance. Every object in the scene can become a new kind of tool. Click on a cat, and your next clicks apply its fur color and texture to whatever you touch. Click on a painting, and you might begin drawing in its style.

Evaluating Solaris

The Cost of Translation

Earlier, we argued that translating interfaces into an intermediate representation inevitably degrades information. To measure that loss, we tested how faithfully today's multimodal language models can recreate an interface from a screenshot.

To measure this, we evaluated state-of-the-art multimodal language models, including Claude Fable 5, on the task of recreating website interfaces from a single screenshot. We evaluate across a diverse collection of 30 interfaces, ranging from simpler plain webpages to image-heavy webpages and natural images, which evaluate different aspects of visual understanding.

We measure information preservation in two complementary ways. First, structural similarity (SSIM) compares the reconstructed interface to the original in place, capturing how faithfully the visual appearance is reproduced. Second, we compare each region of the original with its most similar region anywhere in the reconstruction using DINOv3 features, measuring whether the underlying visual content survives even when elements move or the layout changes.

Despite rapid progress in recent years, every language model loses information during reconstruction. Natural images are affected most because rich visual detail cannot be represented accurately in language. As interfaces become more complex, even small changes to text, layout or structure can fundamentally alter how the interface behaves.

Rather than translating an interface into language and reconstructing it again, Solaris operates directly on the visual interface itself. By eliminating the intermediate representation, it preserves the complete visual and semantic state of the interface from the very first frame.

Solaris vs. Coded Interfaces

Our reconstruction benchmark measures how much information is lost when an interface is translated into code. We next ask: given the same interface and the same user interaction, which approach produces the better result? Can a coded interface recreate the same sense of a living, responsive environment as an interface generated by an interface world model?

To answer this, we compared Solaris against a state-of-the-art language model (Claude Opus 5). Both systems started from the same image and received the same interaction requests, and we recorded how each responded. We then conducted a user study with 250 participants across 30 interaction examples, collecting nearly 7,500 pairwise judgments. For each comparison, participants answered two questions: “Which result better follows the given instruction?” and “Which behaves more naturally within the scene?”

Participants preferred Solaris on both measures. For following the requested interaction, Solaris was preferred in 61% of comparisons compared to 24% for the coded result, while 13% were rated as equivalent. The difference was even larger for natural behavior, where Solaris was preferred in 71% of comparisons compared to 21% for the coded website, with 6% rated as equivalent.

What It Can't Do Yet

Solaris is strongest at ambient motion, click-and-drag interactions and scene transitions. Several important challenges remain:

• Text. Stable, legible text remains one of the hardest problems in video generation, yet interfaces depend on it more than almost any other visual domain. One practical path is a hybrid system in which image models render text-heavy views whenever a brief pause is acceptable, while video models handle continuous interaction. Fully real-time generated text remains an open challenge.
• Trust. For instructional or commercial experiences, a convincing wrong answer is worse than no answer. Today, Solaris stays anchored through what you give it. The starting frame can be composed from real product imagery and reference material, which grounds the scene in things that actually exist. Conditioning generation on richer verified context as the session unfolds (reference images, product data, documents) is an active research focus.
• Long sessions. Maintaining visual and semantic coherence over extended, open-ended interactions remains an active area of research.
• Accessibility and integration. A generated interface still needs to work inside the rest of the software stack, including assistive technologies such as screen readers and accessibility APIs, so that flexibility doesn't come at the expense of usability.

New Kinds of Interfaces

Solaris is an early step toward a new operating layer, and we see several new interaction patterns emerging.

• The app stops being the unit you interact with. Today, getting something done means opening the pre-built app made for it – one for shopping, another for news, another for restaurant reservations. If the operating system can generate useful interfaces, no matter what the user wants to do, there's less reason to sort software into a fixed catalog of apps. What you need simply shows up, customized to you.
• Interface World Models remove the need to translate between a visual idea and an intermediate representation. Instead of working through UI frameworks, components and code, any visual concept can become an interactive interface.
• A storefront is no longer a fixed layout that every visitor sees. It becomes a generated environment that preserves the brand's identity while adapting to each individual. Products, layouts, colors, materials and recommendations reshape around your intent in real time, allowing your brand and products to remain recognizable within hyper-personalized experiences.
• Tutorials no longer replay the same sequence for everyone. Instead, they render the next step in your own context, adapt as you make progress and recover naturally when you go off script.

We expect interface generation to follow the same trajectory as image and video generation: every model generation will become faster, more coherent, more controllable and more capable. The challenges that once made generated interfaces seem impractical now look increasingly like solvable engineering problems.

Solaris is our first Interface World Model, and we're excited to continue exploring what generated software can become, from richer interactions, stronger grounding and longer-lived experiences to entirely new kinds of interfaces that don't exist today. We’re working with key partners to launch Solaris publicly. Fill out the form below to request early access.

Random Attention: Rethinking KV Cache Eviction for Efficient Reasoning

Code for the paper Random Attention: Rethinking KV Cache Eviction for Efficient Reasoning (arXiv:2609.03430).

Random Attention (random_pp in the code) is a signal-free KV-cache eviction policy for reasoning models: keep the prompt, then keep a uniformly random per-KV-head subset of the generated tokens up to the budget (plus a short recency window). It reads no attention scores, no value statistics, and no calibration data, so an eviction round costs only the compaction itself. On MATH-500, GPQA-Diamond, AIME, HMMT and LiveCodeBench, at matched budgets, it matches or beats learned selectors (SnapKV, R-KV, VaSE, TriAttention) on Qwen3-4B/14B/32B and Phi-4-reasoning, and it is the fastest evictor in both the Hugging Face harness and a vLLM serving stack. The repository contains the eviction engine, the evaluation harness, the significance tests, the efficiency benchmarks, the vLLM port, and the mechanism-study tooling that produced every number in the paper.

Layout

kvcompress/engine/     KV-eviction engine: every method in the paper as an eviction mode (cache_utils.py),
                       evict-attention forwards for Qwen3 / phi3 / llama, faithful TriAttention scorer, engine tests
kvcompress/harness/    evaluation harness (adapted from VaSE, see THIRD_PARTY_NOTICES.md): eval_hf.py, the sharded
                       multi-worker launcher parallel_run_hf_mw.py, graders' utilities, TriAttention calibration + stats
kvcompress/eval/       grading (math/science, LiveCodeBench), cell-integrity audit, paired significance tests,
                       shard repair, LaTeX table generator
kvcompress/analysis/   mechanism studies: retention logs, fork replay/autopsy, carrier mass, eviction timing bench
kvcompress/synth/      the controlled synthetic-retrieval study (registered protocol, tables)
scripts/run_cell.sh    canonical launcher for one (model, task, method, budget) accuracy cell
scripts/grade_cell.sh  integrity check + grading of a cell
scripts/efficiency/    HF throughput protocols (VaSE fixed-batch, iso-memory, max-batch, eviction-round timing)
scripts/vllm_rp_bench/ Random Attention inside TriAttention's vLLM 0.19 runtime (own README + RUNBOOK)
scripts/mechanism/     retention-log panels and fork-replay launchers
figures/               figure scripts (read the graded TSVs)
data/                  benchmark layout + our LiveCodeBench difficulty subsets (data/README.md)

Setup

git clone https://github.com/SalesforceAIResearch/Random-Attention && cd Random-Attention
bash setup.sh                 # Python 3.10 venv: torch 2.4.0 (cu121), flash-attn 2.7.3, transformers 5.0.0, ...
. env.sh                      # RA_ROOT / RA_ENGINE / RA_DATA_DIR / RA_MODELS_DIR / PYTHONPATH

• Models: Hugging Face checkpoints under $RA_MODELS_DIR/<name> (default models/): Qwen3-4B, Qwen3-14B, Qwen3-32B, phi-4-reasoning, optionally DeepSeek-R1-Distill-Llama-8B.
• Data: $RA_DATA_DIR/<task>/test.jsonl -- see data/README.md for the format and sources. Our LiveCodeBench subsets are included.
• Hardware: the paper's experiments ran on 8x H200 (141 GB).

Run an accuracy cell

scripts/run_cell.sh Qwen3-4B math random_pp          # K defaults to the task's ~4x point (1024 here)
scripts/run_cell.sh Qwen3-4B math vase               # VaSE with the faithful n_large = K/4
scripts/run_cell.sh Qwen3-4B math triattn            # TriAttention with per-model calibration stats
scripts/run_cell.sh phi-4-reasoning gpqa snapkv 2048
scripts/run_cell.sh Qwen3-32B aime25 rkv && scripts/run_cell.sh Qwen3-32B aime26 rkv

Add --dry-run to print the exact parallel_run_hf_mw.py command. Cells resume when re-launched; completions land under results/<model>/<task>_K<K>/<method>/. the header of scripts/run_cell.sh lists every method and its flags.

Grade, test, tabulate

scripts/grade_cell.sh Qwen3-4B math_K1024 dense,random_pp,attn,attn_rkv_l05,vase_faithful,triattn_ph_memofix
python kvcompress/eval/stats_paired.py --base results/Qwen3-4B/math_K1024 --data_name math \
       --method_a random_pp --methods_b attn,attn_rkv_l05,vase_faithful,triattn_ph_memofix   # paired bootstrap + sign test
python kvcompress/eval/gen_paper_tables.py --results <graded.tsv> --lcb <lcb.tsv> --out tables/

grade_cell.sh runs cell_integrity.py first: grading is positional (problem = shard offset + line), so a mixed, ragged or overlapping cell is refused rather than silently mis-graded. Accuracy is flag_acc (answer correct); acc_strict additionally requires termination within the 32k cap and is reported as a diagnostic.

Efficiency

• Hugging Face harness: scripts/efficiency/*.sh (fixed-batch VaSE protocol, iso-memory max-batch serving, eviction-round timing). Never report tokens/s from the batched accuracy runs -- they share GPUs.
• vLLM serving: scripts/vllm_rp_bench/ -- Random Attention as a selector inside TriAttention's vLLM 0.19 runtime (their paged-KV compression machinery, our selection rule), with the accuracy-transfer check and the runtime shims documented in its README.

Mechanism and synthetic studies

KEEPLOG=1 retention logging, FORCE_KEEP_RANGE fork replays (kvcompress/analysis/fork_replay.py, fork_autopsy.py), carrier-head mixing modes, and the registered synthetic-retrieval protocol (kvcompress/synth/) are driven by engine environment switches documented in the kvcompress/engine/cache_utils.py header.

License

This project is released under the Apache License 2.0 (see LICENSE.txt); it is a research release accompanying an academic paper -- please read AI_ETHICS.md. Contributions: CONTRIBUTING.md; security reports: SECURITY.md.

Acknowledgements and third-party code

The evaluation harness and the engine skeleton descend from VaSE (MIT); the TriAttention baseline and the vLLM serving benchmark build on TriAttention (Apache-2.0). Exact file-level provenance and license texts are in THIRD_PARTY_NOTICES.md.

Citation

@article{randomattention2026,
  title         = {Random Attention: Rethinking KV Cache Eviction for Efficient Reasoning},
  author        = {Heng Wang and Jielin Qiu and Wenting Zhao and Cheng Qian and Liangwei Yang and Jiawei Han and Heng Ji and Silvio Savarese and Shelby Heinecke and Huan Wang},
  journal       = {arXiv preprint arXiv:2609.03430},
  year          = {2026},
  eprint        = {2609.03430},
  archivePrefix = {arXiv},
  primaryClass  = {cs.CL},
  url           = {https://arxiv.org/abs/2609.03430}
}

Any modality, Many Applications, One Unified Verification Framework

LLM-as-a-Verifier achieves SOTA performance across agentic benchmarks, including Terminal-Bench, SWE-Bench Verified, MedAgentBench, RoboRewardBench and more. We invite the community to contribute more use cases!

Installation

pip install llm-verifier

To install the latest from a clone:

pip install -e .

What's new in 0.2.0:

• Prefix-cache optimization: ~3.4× fewer uncached input tokens on trajectory-heavy benchmarks
• Terminal-Bench 2.1 self-verification benchmark
• deepseek-v4-flash verifier backend
• Token accounting (llm_verifier.token_usage())

About

LLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent. The key idea is simple: 1) use fine-grained scoring granularity, 2) take the expectation over the full logprob distribution of LLM score tokens, and 3) scale repeated evaluation and criteria decomposition. The resulting fine-grained feedback can be used for test-time scaling, progress tracking, and reinforcement learning.

Quickstart

Simple Best-of-N Selection

Run a first end-to-end selection (requires DEEPSEEK_API_KEY or VERTEX_API_KEY in .env, or an OpenAI-compatible server that returns logprobs — e.g. vllm serve Qwen/Qwen3.5-9B with OPENAI_BASE_URL=http://localhost:8000/v1):

import llm_verifier

problem = "Write a function that reverses a string."
candidates = [
    "def rev(s): return s[::-1]", "def rev(s): return s", "def rev(s): return ''.join(sorted(s))",
]

result = llm_verifier.select(
    problem=problem,
    candidates=candidates,
    criteria={"Correctness": "Does the code actually reverse the string?"},
)
print(result.index)   # index of the best candidate: 0
print(result.scores)  # candidate scores: [0.73104, 0.38446, 0.38449]

Score a pair of candidates directly

select is built on a pairwise reward model. For the raw fine-grained rewards of a single comparison, call compare:

reward_a, reward_b = llm_verifier.compare(
    problem, candidates[0], candidates[1],
    criteria={"Overall": "Does the code solve the problem?"},
)
print(reward_a, reward_b)   # fine-grained rewards in [0, 1]: 0.99994 0

Fine-grained Progress Tracking

The same fine-grained reward can also score an agent's progress after each step with track:

steps = [
    'Read the problem statement',
    'Wrote def rev(s): return s ',
    'Tested: rev("abc") returned "abc"',
    'Changed to def rev(s): return s[::-1]',
    'Tested: rev("abc") returned "cba"',
]

result = llm_verifier.track(problem=problem, steps=steps,
                            checkpoint_steps=[1, 2, 3, 4, 5], n_evaluations=4)
print(result.scores)  # progress after each step: [0.00106, 0.02417, 0.03143, 0.62004, 0.99978]

Self-Verification (Terminal Bench 2.1)

Can a model verify its own rollouts? On Terminal-Bench 2.1 we generate 5 mini-swe-agent trajectories per task with deepseek-v4-flash and use the same model as the verifier. Selection lands well above Pass@1 even though the verifier is judging its own model's work:

The trajectories ship in data/terminal_bench_2.1_trajs/; scoring only needs DEEPSEEK_API_KEY in .env. Each configuration has its own reproduction script:

python scripts/run_bo3.py                    # best-of-3
python scripts/run_bo5.py                    # best-of-5

Test-Time Scaling for Agentic Benchmarks

Progress Tracking for Coding Agents

The same fine-grained reward can score a trajectory at every step. Below, we track two Terminus-2 runs of the Terminal-Bench task pytorch-model-cli. The successful trajectory exhibits consistently increasing verifier scores, whereas the failed trajectory is characterized by erroneous behaviors, resulting in lower scores throughout the execution. Reproduce it with:

python scripts/terminal_bench_progress.py    # scores both runs then plots

Online progress tracking

track scores a finished trajectory. To monitor an agent while it runs, use ProgressTracker: feed it each step as it happens and get a live progress score back — e.g. to stop a hopeless rollout early or decide when to resample. Since the verifier only ever sees the steps so far, it cannot peek at the future.

Multi-Modal Support

With a multimodal verifier model, every entry point accepts images — a single image or a list of images, each a local file path, an http(s) URL, or raw bytes.

Claude Code Plugin

TurboAgent brings LLM-as-a-Verifier to Claude Code as a drop-in LLM API proxy. It sits between your client and the model provider, generating multiple candidate responses in parallel and selecting the best one with a Probabilistic Pivot Tournament.

pip install git+https://github.com/llm-as-a-verifier/TurboAgent

How it works

Fine-grained Reward Estimation

Rather than reducing each distribution into a single discrete score (as in LLM-as-a-Judge), LLM-as-a-Verifier approximates the reward of a trajectory $\tau$ on task $x$ as:

$$ R(x, \tau) = \frac{1}{CK} \sum_{c=1}^{C} \sum_{k=1}^{K} \sum_{g=1}^{G} p_{\theta}(v_g \mid x, c, \tau),\phi(v_g) $$

Probabilistic Pivot Tournament

To pick the best of N candidate trajectories, a round-robin tournament scores all $\binom{N}{2}$ pairs. Probabilistic Pivot Tournament (PPT) is a cost efficient ranking algorithm in which every candidate is compared only against a small set of pivots, reducing the budget from $\mathcal{O}(N^2)$ to $\mathcal{O}(Nk)$ .

Citation

@misc{kwok2026llmasaverifiergeneralpurposeverificationframework,
      title={LLM-as-a-Verifier: A General-Purpose Verification Framework}, 
      author={Jacky Kwok and Shulu Li and Pranav Atreya and Yuejiang Liu and Yixing Jiang and Chelsea Finn and Marco Pavone and Ion Stoica and Azalia Mirhoseini},
      year={2026},
      eprint={2607.05391},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2607.05391}, 
}

OpenAI declared the AGI era on the strength of a 99.9% score. Run the same model through the benchmark’s own software, and it scores 62.7%.

The gap is not a rounding error or a rival’s complaint. It comes from the organisation that built the test. ARC Prize published both numbers on the day GPT-6 Astra launched. It printed a full table of every reasoning level it ran.

The difference is the harness. A harness is the software around a model. It sets the tools the model can reach, what it remembers between requests, and how its context gets managed. Same weights, different scaffolding, different score.

What the table actually shows

ARC Prize ran Astra two ways. Its standard harness gives every model the same minimal interface and lets the model decide which notes to carry forward. OpenAI’s Provider Adapter preserves the model’s opaque reasoning state between requests and compacts longer conversations.

Under the standard harness at maximum reasoning, Astra scored 62.7% and cost $26,098. Under the Provider Adapter at high reasoning, it scored 99.9% for $18,817. The better score was also the cheaper run.

One row makes the point harder than any argument. Set the reasoning effort to none inside OpenAI’s adapter and Astra still scores 96.7%. That beats the same model at maximum reasoning inside the standard harness by 34 points. The scaffolding outperformed the reasoning dial outright.

Both harnesses solved 167 game-reasoning pairs. On those, ARC Prize clocked the adapter runs at 49% fewer tokens and roughly 3.66 times faster.

The number that travelled

The figure that spread was 99.9% against GPT-5.6 Sol’s 7.8%. Those are not the same test. Astra’s 99.9% came from the Provider Adapter; Sol’s 7.8% came from the standard harness.

The like-for-like comparison is 62.7% against 7.8%. That remains an enormous jump, and it is the one the benchmark supports.

ARC Prize itself declined the conclusion OpenAI drew. It stated plainly that it is “not claiming that it is AGI”. Co-founder Mike Knoop wrote that “we lack evidence to call this AGI yet”. Going forward the foundation will publish both harness results side by side.

There is a small wrinkle inside ARC Prize too. François Chollet gave the standard-harness figure as 66% in a post, against 62.7% in the published table. The blog is the primary record.

Then the numbers moved

Fortune found that the scores kept changing after publication. Emily Forlini compared archived snapshots of OpenAI’s launch post and found five metrics altered.

Astra’s hallucination rate read 4.2% in the first snapshot. By 5.20pm it read 2%. It has since gone back to 4.2%. Anthropic’s Fable 5.1 dropped nearly ten points on FrontierMath, from 87.8% to 78%, then settled at 83%.

Sol’s ExploitBench score doubled from 5.5% to 11.5%. OpenAI told Fortune it is investigating reverting that one. The 11.5% reflects a reasoning level Sol does not offer commercially.

The pre-publication draft sent to media under embargo put ARC-AGI-3 at 98.6%. The live post says 99.99%.

Not every edit favoured Astra. Two Anthropic scores on HealthBench Professional went up. Other outlets reached the fine print independently, and The New Stack ran the two harness figures side by side the following day. But the pattern runs mostly one way. OpenAI also pulled the post after publishing it and put it back up, for reasons the company said it could not disclose.

Most evaluations carry noise of a few percentage points, the company told Fortune, depending on checkpoint, scaffold and evaluation run.

Two Stanford researchers have a word for it

Anka Reuel and Mike Hardy call the practice benchmaxxing, meaning re-running evaluations under different conditions until the number improves. Both work at Stanford, at the Intelligent Systems Laboratory and the Trustworthy AI Lab.

They also went looking in the system card, which is where the method should be documented. On the internal hallucination benchmark they found “barely any details about the evaluation”, adding that it “doesn’t even include the number of test items”.

Not everyone reads it as gaming. Vincent Sunn Chen of Snorkel AI told Fortune that scores routinely shift in the final hours before a launch. Checkpoint, configuration, harness and grading are all still moving. His suggestion is a norm requiring companies to say what changed when they revise a published figure.

There is precedent for the harsher reading. Critics accused Meta in 2025 of publishing Llama 4 results from an internal build rather than the public one. Yann LeCun later said the company had fudged them.

Where Astra actually sits

Artificial Analysis ran its own tests and got a duller picture. On its Coding Agent Index, Astra scores 67 in Codex, level with Claude Opus 5 and Fable 5. Fable 5.1 leads at 70.

On its Intelligence Index, Astra scores 61, the same as the model it replaces, five points behind Fable 5.1 and behind Meta’s Muse Spark 1.3. It costs $10 per million input tokens and $50 per output, two and a half times Sol’s price, which works out 75% more expensive per task at maximum effort.

The gains are real but narrow. Hallucination on its knowledge benchmark fell from 92% to 51%, and long-horizon knowledge work rose around 80 Elo. An economically-weighted task benchmark fell by roughly the same amount, with further regressions on banking support, scientific Python and long-context reasoning.

Artificial Analysis has since rebuilt the index. Version 4.2 arrived the following day with harder tasks and more private test sets, which the firm says exist to prevent gaming.

The harness is the product now

We have run into this word twice already. A cheap harness collapsed Booz Allen’s own league table of AI threat. CrowdStrike chose the same word for what it wraps around OpenAI’s cyber model.

Anthropic, Google and Microsoft all sell harnesses as products with their own pricing. Nvidia built one that took Claude Opus 5 from 30.2% on ARC-AGI-3 to clearing every level.

OpenAI is not hiding anything here. The adapter uses documented API features any developer can call. But the thing that scored 99.9% is an assembled system, and the thing on sale is a model.

That distinction is the whole story, and it also runs through the monitorability argument. What a model can do and what anyone can independently verify it doing are drifting apart, and the benchmark is where you can see the gap.

Google keeps upgrading its Gemini desktop app toward a proper super app intended to compete with Codex and Claude Desktop. The latest update adds a new toggle that lets users switch between Ask and Assign modes, analogous to Chat and Work in Codex. Ask presents the standard Gemini interface, while Assign works like Gemini Spark, the AI agent Google introduced recently, but with expanded capabilities.

Assign will let users choose the folder in which Gemini operates. They can set a default folder, return to one used in a previous session, or select a new folder for a task, keeping the agent within that specific scope. The app also includes an option to connect to other computers running Gemini desktop. This could enable remote control features, although exactly how the connection will work is still unclear. It will likely resemble the approach used in Codex.

Two integrations stand out in the current testing. With computer use, users can tag the computer use skill and trigger tasks from Gemini desktop that operate local apps. Google is also testing connections with Obsidian. It is unclear whether this points to a broader knowledge base concept or whether Google is using Obsidian internally while it works toward equivalent functionality in Gemini, but the integration will be very welcome either way.

Google is also working on a Customize tab where users can select skills, apps, connectors, or plugins. The current build remains quite limited, offering mostly Google apps or extensions already found in the existing Gemini interface. Hopefully, Google will add proper MCPs and plugins later, as seen in competing apps.

Code traces indicate that Google is preparing the app to work with the next major model, potentially Gemini 4. The code also points to an upgrade for Nano Banana, specifically Nano Banana 2.5 Flash.

And in other parts of Google, there is another new model that caught the attention of my crystal ball

Nano Banana 2.5 Flash

Interesting

On macOS, Finder integration will let you send any folder directly to Gemini for inspection or a targeted task.

All of these features remain in closed testing, and the timeline for a public release is unclear. For now, let's see when, and in what form, these capabilities reach Gemini users.

As a test of our progress to advance the frontier of AI research, in June we entered the next generation of our autonomous AI research system, AIRA₃, in a live Kaggle competition run by NVIDIA to fine-tune a 30B Nemotron model. The challenge was to teach the model to reason better — all competitors had access to the same information and were graded externally on a private test set.

AIRA₃ placed 8th out of ~4,000 teams to win Gold, outperforming human competitors who had access to the same frontier tools.

We believe this is a reliable signal that AIRA₃ can improve a targeted capability of an AI model at a level similar to human experts.

We entered AIRA₃ with an ensemble of models in the live competition, and also assessed it with several others post-hoc. The 8th ranked gold medal entry ensemble was a combination of GPT 5.5 (w/ OpenCode) + Claude 4.8 (w/ ClaudeCode).

Post-hoc we assessed with Muse Spark 1.2 (w/ MuseCode), which also performed at a Gold Medal level, as well as Muse Spark 1.1 (w/ OpenCode) and GLM 5.2 (w/ OpenCode), both of which achieved Silver Medal level performance. The post-hoc submissions were also graded externally on the same private test set as those made during the live competition.

Rather than relying on a central controller, AIRA₃ runs many long-running agents (pairs of models + coding harnesses) in their own isolated environments and coordinates asynchronously through two shared substrates:

• 1️⃣ a forum for sharing hypotheses and findings
• 2️⃣ a shared filesystem for solution artifacts

The individual agents collaborate, share discoveries, and build on each other’s work. As the graph below demonstrates, the system uses compute to compound knowledge and drive performance gains over time. Search strategies emerge dynamically as each agent decides which discoveries to build upon.

While the Kaggle competition demonstrated AIRA₃’s capabilities in a specific domain, the system itself can generalize across distinct domains: changing only the task specification. In an internal benchmark, AIRA₃ achieved a 27% latency reduction on production GPU kernels, and gold-level performance in another Kaggle competition translating 4,000-year-old Akkadian clay tablets into English.

We're early, and hard problems are still ahead of us. But we believe a system that compounds its own knowledge is the right bet. As we continue to develop and scale, we’re excited about its potential to accelerate AI research and unlock recursive self-improvement.

Full article content is not available for inline reading.

Read the original article →

I trust my coding agents with production secrets now

I give my coding agents direct access to important secrets, including my Tailscale auth key, SSH private keys, Anthropic and Codex OAuth tokens, and my Gmail app password. The secrets live in a password vault, and the agents generally use them without seeing their values.

I’ve worked in datacenters and run Linux infra for decades, worked as a security and network engineer, and built production systems for many companies, including an AI coding agent platform used by hundreds of thousands of people. So I understand the risks involved as well as anyone.

My setup has all three parts of Simon Willison’s lethal trifecta. My agents have access to private data, read untrusted content, and can communicate externally. An attacker could (in theory) hide instructions in a webpage or file that trick an agent into sending them my secrets.

Security is always a productivity-risk tradeoff

With production access, my agents can investigate outages, read logs, deploy a fix, and check that it worked. Without that access, I have to do those steps, which slows things down significantly.

I give agents production access for the same reason I give access to inexperienced teammates. I know a new teammate could install malware or fall for a phishing attack, but I still give them the access they need to do their job.

Frontier models are hard to trick

I run Claude and Codex exclusively, using frontier models like Astra and Fable for hard problems (Opus and Sol for routine work). I wouldn’t have given older models this much access, but prompt injection worries me a lot less with these models. The models are getting better at distinguishing the user’s instructions from malicious instructions in the content they read.

This applies to coding agents with access to your own trusted codebase. Opening a random GitHub project with this much access would be a very bad idea.

Why I still run agents in Docker containers

Although I trust my agents with secrets now, I still run them in isolated Docker containers. Each agent gets its own checkout and can run dev servers without trampling on another agent’s work. I don’t have to juggle Git worktrees or clean up processes and files my agents leave behind.

Agents still make mistakes, like running rm -rf in the wrong directory. I almost never run them on my bare hosts unless the task requires it.

But I’m not relying on containers to stop a malicious or hijacked agent from doing damage. My agents still have access to secrets and production machines.

What about least privilege?

Ideally we’d follow least privilege and give each agent only the access it needs for the task. We may eventually have fine enough control to make that practical without constantly getting in the way.

But people often talk about merely hiding credentials as if it removes the biggest risk, which is silly. An agent that never sees my SSH private key but gets a root shell on my production server can still rm -rf the production system.

We may want tight controls on agents for a long time, but assuming we’ll always need them is, on some level, a bet against continued dramatic improvements in the models.

As models improve, we may end up trusting our agents with access even more than we trust ourselves.

1. I use a CLI with a secret vault, so commands can retrieve secrets by name at runtime without putting the values in the agent’s context. The agents can read the values directly if they need to, but generally don’t need to and tend to be careful about exposing them in output or pulling them into context.
2. Anthropic reports improvements from model training and additional checks in Claude Code. Boris Cherny summarizes how they work together.
3. Opening random GitHub projects in an IDE carried risks long before coding agents. Their scripts or tests could steal secrets when run, even without any prompt injection.
4. Yes, a proxy can limit access, make it easier to revoke, and provide an audit trail. Those help, but if the agent still has root access to production, it can still destroy production.

As I continue my journey into the abyss of the compiler, one idea has finally started to settle in for me, a compiler is not just a translator that takes language A and turns it into machine B. That description is useful when you are first learning, but it leaves out most of what makes compilers interesting. A compiler is also a system for managing information while gradually changing the form of a program. At every stage, it has to decide what still matters, what can be transformed, and what can finally be discarded.

That was a large part of what interested me while writing about LLVM, and it followed me directly into KGEN and MLIR. LLVM pushed me to think about why an intermediate representation exists in the first place. KGEN complicated that picture further by showing why one representation may not always be enough. Mojo can preserve source-level information in LIT while that information is still useful, move into KGEN while parametric information still matters, and retain structured control flow through HLCF until the compiler has finished reasoning about it.

Much of that discussion revolved around what the compiler wants to preserve or transform. My next venture, Spencer Bryngelson’s Apple Neural Engine: Architecture, Programming, and Performance, introduces something a little less negotiable, the machine itself.

The Apple Neural Engine is an unusually opaque target, which, given that this is Apple, should probably surprise nobody. Apple publicly exposes the ANE through Core ML, while the compiler, program format, driver, firmware, and much of the machinery underneath it remain undocumented. Bryngelson’s paper is an independent reverse-engineered account of that stack, based on direct measurements and analysis of Apple’s private software. For this piece I am mostly interested in what follows the compiler as a neural-network graph is transformed into something the ANE can actually execute.

Consider a neural-network graph consisting of a convolution, followed by a bias addition, followed by a ReLU activation. At the graph level, these are three perfectly reasonable operations. Perform the convolution, add the bias to its result, then apply the activation. When I first started reading the compiler chapter, I more or less assumed that some progressively lower-level version of those three operations would eventually become three pieces of work for the accelerator.

That assumption was short lived.

The ANE compiler can absorb the bias and activation into the convolution itself. Padding can be folded into it as well, and parts of the quantization path can disappear into the same backend operation. The convolution’s bias becomes part of the hardware’s gain-offset machinery, while the activation can occupy one of the activation slots associated with the operation. What entered the compiler as conv → bias → relu can therefore leave this stage as one fused ANE operation rather than three independent dispatches.

This connected immediately to what I had been learning from KGEN, except from the opposite direction. With KGEN, I always landed on why a compiler would preserve a concept. Here I found myself asking when the distinction between two concepts stops being useful.

A convolution, bias, and ReLU remain useful as separate ideas when I am reasoning about the structure of the neural network. Once the compiler reaches hardware that already has a place to express the bias and activation as part of the same execution path, preserving those boundaries may no longer buy us anything. Neither representation is somehow more truthful than the other.

Now our four broad phases are as followed: fusion, legalization, scheduling and task-descriptor partitioning, followed by memory and DMA optimization. Put into less compiler-shaped language, the sequence is fairly intuitive. The compiler first has to understand what computation was requested and whether several pieces of it can become one machine operation. It then has to determine whether the resulting operation is actually legal on this hardware, decide how the surviving work should be ordered and divided, and finally decide where the data should live and how it should move while all of that happens.

Fusion and the usefulness of boundaries

Fusion is a good place to begin because it makes the relationship between representation and hardware unusually concrete.

The network representation entering this part of the compiler can still contain the convolution, bias, and activation as independent operations. The fusion happens later inside the ANE compiler’s own graph machinery. That distinction matters because it shows that the original boundaries were not mistakes. They were useful at one stage and unnecessary at another.

The same logic applies to other operations. Transposes can sometimes disappear into neighboring work or use dedicated machinery instead of becoming separate dispatches. Scaling and batch normalization can be absorbed into the same gain-offset path. A dequantization step can be folded into the convolution’s weight path rather than surviving as an operation of its own. The compiler is continuously asking whether an intermediate result or operation boundary still represents something the target actually needs to see.

There are limits. An addition between a convolution result and a constant bias fits naturally into the gain-offset machinery because one side of the operation is constant. An addition between two independently computed convolution outputs does not. Both operands are live values, so the addition remains a real backend operation. Concat can create another fusion boundary, attention introduces harder segment boundaries, and later capacity constraints can even force the compiler to split something it had previously fused.

I like this nuance because it prevents fusion from becoming another vague “compiler optimization makes things faster” explanation. The compiler is not combining operations simply because fewer operations sound better. It is combining them when the hardware provides a representation capable of expressing their combined behavior, and keeping them separate when it does not.

When a valid computation is not a legal machine program

An intermediate representation can describe a perfectly valid computation. The mathematics can make sense, the graph can be well formed, and the compiler frontend can understand exactly what you are asking for. None of that guarantees that this particular machine can execute the computation in that form.

The ANE has an envelope. Tensor rank is limited, individual dimensions have bounds, convolution kernels have target-specific constraints, and coefficients have to fit within particular memory limits. If an operation falls outside those boundaries, the compiler has to tile it, split it, transform it, or break the graph into additional segments.

Its sounds straight forward, but I think it exposes a distinction that is easy to lose when people say a piece of hardware “supports” some operation. Representable, valid, lowerable, and executable are not necessarily the same claim.

Now, The compiler exposes validators that check whether operations satisfy expected shapes, types, dimensions, operand counts, and target-specific capabilities. Yet passing one of those validators does not necessarily mean backend code generation will succeed. On the M1, the paper found operations such as top-k, sort, dynamic slice, and 3D convolution that can pass parts of that validation surface and still fail during backend lowering.

That means saying “the ANE supports this”. But, supported where?

Can the intermediate language represent it? Does the frontend accept it? Does the validator approve it? Can the backend turn it into ANE operations? Does the resulting program actually execute on this generation of silicon?

Those are different boundaries, and the farther down the stack we travel, the less useful the word supported becomes without saying which one we mean.

When matrix multiplication decides to become a convolution

One of my favorite examples in the chapter involves matrix multiplication because it makes another compiler instinct I had been carrying around fall apart.

If a matrix multiply’s right-hand weight fits within the ANE’s on-chip working-set budget, the compiler can rewrite that matrix multiplication as a resident convolution. If the weight is too large, it remains a tiled matrix multiply. On the M1, the working-set threshold involved here is about 2 MB.

The first time I read that, part of my brain still wanted to object that I had asked for a matrix multiplication, not a convolution.

The compiler is responsible for preserving the computation, not the name I originally gave the operation. “Matrix multiplication” may be the best representation for understanding the mathematics, while “resident convolution” may be a better realization on this particular accelerator when the weights fit comfortably on-chip.

This is where lowering starts feeling less like translation and more like selecting among possible realizations of the same intent. The source-level operation is not sacred. What matters is whether the transformation preserves what the program is supposed to compute while making better use of the machine underneath it.

The machine has started influencing not only how an operation executes, but which representation of that operation is useful at all.

Eventually bytes start making compiler decisions

Once the graph has been fused and legalized, the compiler still has to determine how the resulting work should actually run. Chapter 22’s scheduling phase linearizes the operation graph and divides that schedule into task-descriptor partitions that fit the engine’s on-chip working-set budget.

The M1 makes this wonderfully concrete because the scheduler is working against an approximately 2 MB static-memory ceiling. Rather than dividing work according to some arbitrary number of operations, the compiler tentatively adds another layer, estimates the peak live memory pressure across its lifetime, and closes the current partition when the next piece of work would push that pressure beyond the allowed budget.

This might be the part of the chapter that made the whole thing click most clearly for me.

Higher in the compiler I can spend all day discussing representations, graph structure, fusion rules, and operations. Eventually the decision about where a program gets divided can come down to a much less philosophical approach, does the live data still fit?

At that point, information is no longer just an abstraction the compiler reasons about. It occupies bytes, and those bytes need somewhere to exist.

That realization slightly changes my definition of a compiler again. It is certainly managing information, but as we get closer to the machine it increasingly becomes a resource-management system as well. The compiler has to think about how much fast storage is available, which values are alive at the same time, and whether the chosen execution order will keep the working set within that physical limit.

The arrow between two operations is not free

DMA, or Direct Memory Access, is essentially part of the machinery that allows data to move between memory and the accelerator without requiring the CPU to personally shepherd every byte along the way.

At a high level, I might draw two operations as A → B and think mostly about the dependency: B needs whatever A produces.

Closer to the hardware, that arrow starts acquiring baggage. Where did A place its result? Does it need to be written back out to dynamic memory? Does B have to read it again? Can the result remain on-chip? Are the two operations scheduled next to each other? Does their tile geometry line up? Does anyone else need that value before it can be reused?

Chapter 22 describes several allocation states that distinguish data kept resident on-chip, streamed from dynamic memory, held in ring buffers, rewritten in place, or chained directly from one operation into the next. Under the right conditions, a producer with one consumer can leave its result on-chip so the following operation consumes it directly rather than forcing an unnecessary trip out to dynamic memory and back.

That is an easy detail to overlook if you live entirely at the graph level. The arrow looked free there. Down here it has become memory traffic.

The compiler also rearranges destination-buffer strides to avoid bank conflicts, folds padding, and packs weight streams. These decisions are not as glamorous as inventing an IR or proving an optimization correct, but they expose something fundamental about accelerator programming: once computation becomes cheap enough, moving the data required by that computation can become a large part of the problem.

Again, the abstraction changes because the question changes. The neural-network graph cares about dependencies between operations. The memory optimizer has to care about where the resulting bytes are physically available when those dependencies are satisfied.

Representation has a cost

While I was working through this, Chris Lattner added a useful refinement to something I had been trying to articulate in my KGEN piece. I had become fascinated by MLIR’s ability to let different representations preserve the abstractions that matter at different phases. His point was that every additional IR also adds complexity, and that complexity has to justify itself. The goal is not to preserve as many representations as possible, but to use the fewest that still express the core abstractions needed at each stage.

That fits surprisingly well with what I see happening in the ANE compiler.

The network graph keeps convolution, bias, and activation separate while that distinction is useful. The fused representation gives them up when the hardware can express their behavior together. Legalization preserves enough shape and capability information to determine whether the resulting work belongs inside the machine’s envelope. The scheduler increasingly cares about live ranges and memory pressure, while the allocator eventually cares about residency, strides, tiles, and movement.

The compiler does not preserve an abstraction because abstractions are nice to have. It preserves one because there is still a question that is easier to answer while that abstraction exists.

Once the question has been answered, carrying that representation farther may become unnecessary overhead.

This is the part that has gradually changed how I think about lowering. I used to imagine it primarily as a movement from something high-level toward something lower-level. I still think that is directionally true, but it misses why the program keeps changing shape.

When representation answers to physics

Looking back across LLVM, KGEN, and now the ANE compiler, I think I have accidentally been following the same problem farther and farther down the stack.

With LLVM, I wanted to understand why an intermediate representation mattered at all. A useful IR preserves enough structure that the compiler can continue reasoning about a program rather than committing immediately to the limitations of one machine.

KGEN and MLIR expanded that idea. Different stages of compilation may require different useful abstractions, and a compiler can move among them as the information it needs changes. The interesting problem becomes deciding what still deserves to survive and when it is safe to let something go.

The ANE introduces another constraint because eventually those representations encounter a physical machine with finite memory, particular execution units, supported and unsupported forms, target-specific limits, and actual costs for moving data around.

A convolution, bias, and ReLU can collapse because this accelerator has machinery capable of expressing their combined behavior. A matrix multiply can become a convolution because that realization happens to fit the target better under a particular memory constraint. A graph can be partitioned in a place that has nothing to do with the way the programmer organized it because the next live tensor would push the working set beyond what the accelerator can hold. An intermediate value can remain resident or be streamed according to whether the surrounding execution makes that possible.

The computation still has to mean the same thing in the sense that ultimately matters to us: given the same valid inputs, it should produce the result we asked for. But nearly everything about how that computation is represented can change on its way down.

They look less and less like a machine for mechanically translating one language into another and more like the place where several descriptions of the same computation negotiate with one another. The programmer has one description. The model graph has another. The compiler creates several more. Eventually the accelerator introduces constraints that none of those previous representations can simply ignore.

With a network description and ends with a loadable program for the ANE. What happens in between is fusion, rewriting, scheduling, partitioning, allocation, and data movement, but underneath all of those mechanisms is a fairly straight forward progression. The compiler keeps changing the program until the way we describe the computation is compatible with the way the machine can physically perform it.

A Vision for Built-in Linting

Since early in the life of the OpenTofu project various community members have asked for built-in linting support. Although we always liked the idea of that in principle, we were concerned that the full scope of what people seem to mean by "linting" is a pretty large project of similar size to OpenTofu's core functionality, including support for user-defined lint rules, linting plugins, etc.

At this point the feature request for linting is the most highly-voted issue in our GitHub repository, and so during the v1.13 development period we began investigating what it might look like to integrate linting as a built-in part of the OpenTofu workflow. Of course, that then required us to figure out exactly what functionality that implies, which was more interesting a question than it might first appear!

We're still early in our research and design for these features, but in this article we want to share what we've learned so far and how we're expecting to approach this problem in future releases.

The scope of "linting"

The term "linting" originates from a specific piece of software, literally called "Lint", that was written at Bell Labs to perform static analysis on C source code. This tool would detect and report various situations that are not technically incorrect but are nonetheless likely to cause portability problems or make the code harder to understand by future maintainers.

Today, "linter" tends to describe a wider variety of tools. Some are focused purely on checking for or applying superficial style rules such as which characters are used for indentation and which variable names are allowed. Others perform more detailed static analysis to detect problems such as unreachable code or common mistakes in a specific programming language, but with a fixed ruleset decided by the developers of the tool. In the most general case, the word "linter" instead describes a generic harness for implementing and executing an arbitrary set of separately-developed checks, possibly including checks that are relevant only to a single organization or codebase.

Across all of these the most typical situation is that the "linter" is something separate from the "compiler" or "interpreter", focused only on source-code-based static analysis. A typical linter does not actually execute the program that it's being applied to, and so it cannot react to any dynamic values produced by the program at runtime.

OpenTofu's execution model is unusual in that its "plan" phase already acts as a sort of middle-ground between analysis and execution: it evaluates all of the expressions in the configuration as far as possible while asking providers to predict what they would do with that input, threading the results from one provider to another in an attempt to detect potential problems before making any changes. In that sense OpenTofu's planning phase is already acting in a "linter-like" fashion but using dynamic analysis rather than static analysis.

Lots of organizations have built on this by introducing additional automated checks based on the results from OpenTofu's planning phase. For example, some use Open Policy Agent as a general-purpose policy enforcement tool based on a JSON representation of the OpenTofu plan, and others use Infracost to try to predict the difference in monthly cost that a certain set of changes are likely to cause.

Some teams using OpenTofu's predecessor separately use tflint for static analysis before even running the planning phase. The name of this software suggests that it's focused on linting based on source code, but it works by embedding large parts of Terraform's runtime engine inside it and so even there the distinction between "linting" and "planning" is blurry.

Based on all of this, we've come to believe that pre-plan linting and post-plan policy checks are two parts of the same problem. Instead of defining separate rules for each, OpenTofu could re-check the same set of rules at each phase as more information becomes available.

The OpenTofu project therefore intends to take quite a broad view of what "linting" means: instead of being an entirely separate step run before the main OpenTofu workflow, we'd like to allow operators to provide a single set of rules that get repeatedly checked throughout the OpenTofu workflow: while validating, while planning, and while applying. During each workflow phase, each of the defined checks can either be passing, failing, or have an unknown status that'll be decided in a later phase.

Custom Lint Rules and Linting Plugins

You can get quite far with simple declarative rules evaluated in terms of data already known to OpenTofu. Being able to write those rules in a similar language as OpenTofu modules themselves means that authors can reuse their existing knowledge and can avoid having to install additional interpreters or other tools to use alongside OpenTofu.

However, some checks inevitably require access to external data or to calculations that are too complicated to write ergonomically in a simple configuration language. It's important to offer an "escape hatch" allowing rules to be implemented using general-purpose programming languages.

The good news that OpenTofu already has an existing model for calling into code written in general-purpose languages: provider plugins! We're still evaluating how best to make use of provider plugins as part of defining rulesets. One initial possibility is to allow policy configurations to include data and ephemeral blocks with the same meaning they have in OpenTofu modules. For example, a rule could make use of the results from the http provider, or aws_iam_principal_policy_simulation in the hashicorp/aws provider.

One way to think about custom lint and policy rules is as a set of additional postconditions defined in a central place outside of the main configuration. Instead of being associated with individual resources, they'd instead be applied systematically to all resource instances meeting certain criteria. Each rule could be configured either as blocking (raising an error) or non-blocking (raising a warning). They'd otherwise be similar to the various check-related language features you may already be familar with. We plan to design the specifics of this ruleset language in a future RFC, after collecting more use-cases.

Built-in Linting Rules

We understand that much of the community interest in this feature is about defining custom rulesets, but we'd also like to include an evolving set of built-in rules related to OpenTofu's own language features. This is the more traditional definition of "linting", and is an opportunity for OpenTofu to draw attention to usage patterns that are technically valid but nonetheless potentially confusing or harmful, such as:

• Redundant references in depends_on arguments: those with experience in other dependency-graph-based software sometimes misunderstand depends_on as mandatory for declaring all dependencies, or assume it has a stronger meaning than just referring to the same object naturally in a resource configuration.
• Using count instead of enabled for conditional resource instances: those coming from OpenTofu's predecessor may not realize that OpenTofu has explicit support for boolean enablement, and so declarations like count = var.cond ? 1 : 0 are unnecessary unless you expect that you might want to switch to having two ore more instances of the same resource in future.
• Applying the [*] operator to a non-list or non-set value: that usage is allowed as a way to transform a single value that might be null into a tuple of zero or one elements, but there are various situations where that's unlikely to be what the author intended to do, and we'd like to be able to draw attention to those without creating mandatory warning noise even for those who are relying on that behavior intentionally.

OpenTofu v1.13.0 includes some early support for checking a small set of built-in rules, activated by using the experimental -lint=... command line option with either tofu validate, tofu plan, or tofu apply:

tofu plan -lint=all

In the long term we're expecting to have a configuration-file-based approach to configuring linting instead of trying to pack the whole configuration into a command line option, but we've started here just as a way to get some of the internal plumbing in place and begin exposing built-in linting rules to gather feedback about how useful and effective they are. Instead of all you can optionally specify a comma-separated list of specific rules to activate.

The initial set of built-in rules is small but we intend to grow this in later releases:

Reusable Rulesets

Although some policy rules are inherently specific to a single organization or even a single configuration, there are certain kinds of policy we've seen defined over and over in different forms across many different organizations' pre-merge linting and post-plan policy rules. For example:

• Detecting firewall rules that allow full access from the public internet.
• Detecting access policies that permit unauthenticated access.
• Detecting objects that are missing tags required by a specific global tagging scheme.

We'd like to allow defining rulesets such that they can be shared in a similar way to how OpenTofu modules are shared. This implies being able to install them from remote sources, and being able to parameterize them with input variables to customize their behavior. It also requires some way for the maintainers of a reusable ruleset to easily test it as they make changes over time, without having to rely on "real" OpenTofu configurations.

We'd Appreciate Your Feedback

So far we've been thinking broadly about the overall problems of pre-merge linting and post-plan policy checks and coming up with some early ideas for how OpenTofu might approach this family of problems in a coherent, holistic way.

Now we need to get more specific. If you're already using either pre-merge linting or post-plan policy checks in your workflow then we'd love to hear more about what specific rules you have in place and what sorts of problems you intend each of those rules to prevent. We'd like these new "linting" features to be able to absorb as many of those use-cases as possible.

We'd also be interested in any specific ideas you have about rules that could potentially be collected into reusable rulesets, for situations that are common across many organizations where it would be helpful to have a robust single implementation that can be maintained collectively for the whole OpenTofu community to benefit.

SQL queries aren't always written in the order that we think about them. We might start by choosing a table, filtering its rows, aggregating them, and finally sorting the result, but traditional SQL begins by describing the columns that the query will return.

Since ClickHouse 22.12, we’ve been able to put the FROM clause before SELECT. ClickHouse 26.8 takes this further with pipelined SQL using a new |> operator that lets us write queries as a sequence of transformations.

In this post, we'll compare conventional, FROM-first, and pipelined queries using the UK property prices dataset, before using pipelines to build queries that would otherwise require nested subqueries or CTEs.

A conventional SQL query

Let's start with a query that finds the London districts with the highest median property price since 2024:

SELECT district, count() AS sales, round(median(price)) AS median_price
FROM uk_price_paid
WHERE (town = 'LONDON') AND (date >= '2024-01-01')
GROUP BY district
ORDER BY median_price DESC
LIMIT 10;

┌─district───────────────┬─sales─┬─median_price─┐
│ KENSINGTON AND CHELSEA │  2694 │      1125000 │
│ RICHMOND UPON THAMES   │   708 │       960000 │
│ CITY OF WESTMINSTER    │  3830 │       900000 │
│ CITY OF LONDON         │   367 │       842000 │
│ HARROW                 │     2 │       806750 │
│ HOUNSLOW               │   660 │       780000 │
│ CAMDEN                 │  3200 │       760000 │
│ HAMMERSMITH AND FULHAM │  3312 │       730000 │
│ ISLINGTON              │  3316 │       650000 │
│ WANDSWORTH             │  7155 │       625000 │
└────────────────────────┴───────┴──────────────┘

Putting FROM first

A lesser-known feature of ClickHouse SQL is that we can place the FROM clause before SELECT, so the following is also a valid query:

FROM uk_price_paid
SELECT district, count() AS sales, round(median(price)) AS median_price
WHERE (town = 'LONDON') AND (date >= '2024-01-01')
GROUP BY district
ORDER BY median_price DESC
LIMIT 10;

Putting the data source first can make a query easier to visualize. We start by identifying the data we're working with and then describe the columns, filtering, aggregation, ordering, and limit. Apart from moving FROM, this is still a conventional SQL query.

Building a pipeline

ClickHouse 26.8 takes this top-down style further with pipelined SQL. The |> operator passes the result of one stage into the next, making the sequence of transformations explicit: read a table, filter its rows, aggregate them, sort the result, and finally apply a limit.

Here's the same query written as a pipeline:

FROM uk_price_paid
|> WHERE (town = 'LONDON') AND (date >= '2024-01-01')
|> AGGREGATE count() AS sales, round(median(price)) AS median_price
   GROUP BY district
|> ORDER BY median_price DESC
|> LIMIT 10;

The conventional, FROM-first, and pipelined versions all return the same result.

While we can also simplify ordinary SQL incrementally, each |> provides an explicit checkpoint at which the preceding pipeline is a complete query. This makes it particularly convenient to build and inspect the transformation one stage at a time.

How does ClickHouse translate the pipeline?

The pipelined query is converted into standard SQL before execution. We can prefix our query with EXPLAIN SYNTAX to see the conventional SQL generated from our pipeline:

EXPLAIN SYNTAX
FROM uk_price_paid
|> WHERE (town = 'LONDON') AND (date >= '2024-01-01')
|> AGGREGATE count() AS sales, round(median(price)) AS median_price
   GROUP BY district
|> ORDER BY median_price DESC
|> LIMIT 10
FORMAT LineAsString;

SELECT * FROM (
    SELECT * FROM (
        SELECT district, count() AS sales, round(median(price)) AS median_price
        FROM (
            SELECT * FROM (
                SELECT *
                FROM uk_price_paid
            )
            WHERE and(equals(town, 'LONDON'), greaterOrEquals(date, '2024-01-01'))
        )
        GROUP BY district
    )
    ORDER BY median_price DESC
)
LIMIT 10;

Although the converted query contains several nested SELECT statements, ClickHouse doesn't materialize each intermediate result, it optimizes the complete query before executing it.

Adding columns with EXTEND

EXTEND adds calculated columns while retaining all the columns already in the pipeline.

FROM uk_price_paid
|> WHERE town = 'LONDON' AND date >= '2024-01-01'
|> EXTEND round(price / 1000000, 2) AS price_millions
|> SELECT date, district, price, price_millions
|> ORDER BY price DESC
|> LIMIT 3;

┌───────date─┬─district──────┬─────price─┬─price_millions─┐
│ 2024-03-20 │ TOWER HAMLETS │ 164300000 │          164.3 │
│ 2024-03-20 │ TOWER HAMLETS │ 164300000 │          164.3 │
│ 2024-03-20 │ TOWER HAMLETS │ 161890000 │         161.89 │
└────────────┴───────────────┴───────────┴────────────────┘

In this example the use of EXTEND is equivalent to SELECT *, round(price / 1000000, 2) AS price_millions.

Reusing intermediate results

You can also extend an existing aggregation with the pipelined syntax. For example, the following query computes the median property price for each district, grouped by county:

The district_median alias becomes a column that we can use in the next pipeline stage. This lets us aggregate it again without having to write a nested subquery or CTE ourselves.

We can therefore extend the query to calculate the average of those district-level medians for each county, then return the ten counties with the highest values:

SELECT county, district, median(price) AS district_median
FROM uk_price_paid
WHERE date >= '2024-01-01'
GROUP BY county, district
|> AGGREGATE round(avg(district_median)) AS average_district_median
   GROUP BY county
|> ORDER BY average_district_median DESC
|> LIMIT 10;

┌─county─────────────────┬─average_district_median─┐
│ GREATER LONDON         │                  558476 │
│ WINDSOR AND MAIDENHEAD │                  520000 │
│ SURREY                 │                  497455 │
│ WOKINGHAM              │                  478000 │
│ HERTFORDSHIRE          │                  452250 │
│ BUCKINGHAMSHIRE        │                  443870 │
│ ISLES OF SCILLY        │                  430000 │
│ BRIGHTON AND HOVE      │                  405000 │
│ OXFORDSHIRE            │                  400451 │
│ BRACKNELL FOREST       │                  400000 │
└────────────────────────┴─────────────────────────┘

Stage order matters

Something to keep in mind is that the order of the pipeline stages matters. If we move LIMIT 10 before the second aggregation, it limits the intermediate result to ten district medians. The county averages are then calculated from only those ten rows, rather than from every district:

SELECT county, district, median(price) AS district_median
FROM uk_price_paid
WHERE date >= '2024-01-01'
GROUP BY county, district
|> LIMIT 10
|> AGGREGATE round(avg(district_median)) AS average_district_median
   GROUP BY county
|> ORDER BY average_district_median DESC;

Because there is no ORDER BY before the first LIMIT, the ten district rows selected is not deterministic, so the exact result may vary.

Using pipelines in other statements

Pipelines aren't limited to queries that start with SELECT, they can be used anywhere that ClickHouse expects a SELECT query, including subqueries, INSERT ... SELECT statements, and views.

In the following example, we use a pipeline as the query behind a view:

CREATE VIEW million_pound_london_sales AS
FROM uk_price_paid
|> WHERE town = 'LONDON' AND price >= 1000000
|> SELECT date, price, district, postcode1, postcode2;

We can also use a pipeline as the source of an INSERT.

INSERT INTO expensive_london_sales (date, price, district)
FROM uk_price_paid
|> WHERE town = 'LONDON' AND price >= 1000000
|> SELECT date, price, district;

Conclusion

Pipelined SQL gives us another way to express ClickHouse queries. It won't replace conventional SQL, but writing a query as a sequence of transformations can make multi-stage queries easier to build and follow.

How to Carry User Identity Across Federated Kubernetes and AI Platforms

Modern AI platforms are no longer a single application behind one login screen. A user may start in a central portal, open a governed dataset, launch a notebook where that data resides, and invoke an assistant that calls services in another cluster. The workflow feels unified, but identity crosses control-plane and data-plane boundaries at every step. That is where conventional single sign-on (SSO) stops being enough.

SSO proves the user at the front door. Platform teams who manage a federated data or AI platform across multiple clusters still need a reliable way to carry that user context into distributed execution environments without handing raw tokens to every application, weakening revocation, or forcing each cluster to reimplement identity-provider logic.

This challenge is especially important for AI and data platforms, where data and compute often stay close to where they are produced, stored, or governed. Workloads may run in regional clusters, separate cloud accounts, on-premises environments, or specialized execution planes. Users still expect one platform experience across notebooks, catalogs, query tools, dashboards, and AI assistants.

This post describes a central identity gateway pattern for propagating user identity across those federated data planes. A central gateway owns the platform session. Data-plane gateways validate that session through a shared API and convert it into trusted local identity context for downstream applications. The pattern uses standard OpenID Connect (OIDC), a shared session store, stateless data-plane gateways, and a small identity-validation API that services can trust.

At NVIDIA, this approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI. More importantly, it created a reusable foundation for unified platform shells, consistent logout, lower upstream identity-provider load, and AI assistants that can act with delegated user identity across data planes.

Where SSO ends and data-plane identity begins

The implementation details will vary by organization, but the core design is broadly applicable to platform teams running federated Kubernetes environments, multi-cloud data platforms, machine learning workbenches, internal developer portals, or AI application stacks with multiple authenticated tools. SSO gives users one entry point.

Federated data platforms still need a way to carry identity into the planes where work executes. A notebook in one cluster, a catalog API in another, and an assistant calling a query engine in a third all need the same answer: Who is the user, and what are they allowed to do here?

Without a shared identity propagation model, several problems appear:

• Control-plane authentication doesn’t automatically become trusted data-plane identity
• Raw token forwarding expands credential exposure and makes it harder to reason about who can use which token where
• Each data-plane gateway may integrate with the identity provider differently, creating inconsistent claims, refresh behavior, and audit records
• Logout and revocation may not propagate quickly across every cluster or execution plane
• New applications inherit identity plumbing instead of consuming a standard platform contract

For users, the symptom may look like repeated login prompts. For platform engineers, the deeper issue is distributed token propagation: identity created at the control plane must be transformed into trusted, scoped, auditable context at each data plane.

That model works for a small number of applications, but it creates structural problems as the platform expands:

• Sessions are scoped to where they were created. A token issued by one gateway is unknown to another, so users authenticate per service instead of per platform
• Logout is local. Signing out of one tool can leave active sessions elsewhere, creating both user confusion and security risk
• Token refresh is uncoordinated. Every gateway independently negotiates refresh cycles with the upstream identity provider, increasing load and creating divergent session states
• Identity context is inconsistent. Downstream services often parse tokens differently or duplicate authentication logic
• New services inherit old complexity. Adding another tool usually means rebuilding the same auth integration again

Comparing two identity patterns

There are two common ways to structure identity in a federated platform.

The first pattern is distributed session ownership. Each service gateway owns its own login flow, session store, token refresh logic, and logout behavior. This keeps each cluster independent, but it also means the identity state does not move cleanly across the platform.

The second pattern is centralized session ownership. A dedicated identity gateway owns login, session state, refresh, and logout. Regional gateways remain in place, but they delegate session validation to the central identity gateway and focus on request enforcement.

The central identity gateway pattern

The central identity gateway owns three responsibilities:

• Session creation: handling the OIDC authorization code flow and creating a platform-wide session
• Per-request identity validation: answering “who is this user?” for any gateway or trusted service
• Session lifecycle management: coordinating token refresh and logout across the platform

Regional authentication gateways remain in place. They still enforce per-cluster policy, protect local services, and inject identity into requests. What changes is where sessions live.

Instead of storing sessions inside each regional gateway, the central identity gateway writes every authenticated session to a shared store such as Redis. The session is keyed by an opaque session ID and associated with a secure, HTTP-only browser cookie scoped to the platform domain.

On each request, a regional gateway calls an identity-validation endpoint such as /gateway/userinfo. The central identity gateway checks the session store and returns trusted identity claims. The regional gateway then injects a standardized set of identity headers before forwarding the request to the application.

Request flow

Login

When a user arrives without a valid platform session, the regional gateway redirects the browser to the central identity gateway. The central gateway runs the OIDC authorization code flow against the organization’s identity provider, exchanges the authorization code server-side, stores the resulting session in Redis with a defined time-to-live, and sets an HTTP-only session cookie.

Per-request validation

On subsequent requests, the regional gateway sends the session cookie to /gateway/userinfo. The central identity gateway performs a session lookup and returns identity claims such as user ID, email, groups, roles, and session metadata.

Token refresh and logout

When an access token nears expiry, the central identity gateway refreshes it using the stored refresh token and updates the session record. Because the refreshed state is written to the shared store, every regional gateway observes the same session state.

Security and reliability guardrails

Use secure service-to-service authentication between regional gateways and the central identity gateway. Mutual TLS, workload identity, or signed internal tokens can prevent untrusted callers from using the validation endpoint. Strip inbound identity headers before injecting trusted ones. Applications should only trust headers added by the gateway layer, not headers provided by a client request.

Reducing load on upstream identity systems

In a distributed model, each regional gateway can call the identity provider, token secret store, and authorization policy engine independently. With a central identity gateway, the identity provider is called once per login. Regional gateways validate against the shared session instead of repeating the OIDC flow.

Getting started

Ready to implement a similar identity-aware gateway architecture? Begin with the OAuth2 Proxy local environment to explore OIDC login, cookie handling, and Redis-backed sessions. Next, follow the Istio external authorization sample to define the Auth Gateway interface, and add Rego policy evaluation with the OPA Envoy Istio example. For an integrated reference covering JWT and API-key validation, metadata enrichment, policy decisions, and trusted upstream headers, explore Authorino.

• We’re introducing ZGateway, the proxy we are using to unify traffic through ZippyDB, Meta’s most widely-used key value store.
• As a bonus, it also enables admission control, load balancing, cross-region resilience, and richer operations.

ZippyDB is the most widely used key value store at Meta, backing product metadata, counters, and configuration, and can serve billions of operations per second across a globally distributed fleet.

A previous post described how ZippDB works. This post is about the layer in front of it: ZGateway, the proxy through which we are unifying ZippyDB client traffic.

ZGateway grew out of the need to manage the sprawl of ZippyDB’s client fleet, and its value turned out to be structural. A ZippyDB client might be one of more than a million hosts, owned by hundreds of teams, that we cannot change quickly. A proxy sits in a different position entirely — in the path of many clients at once — and that shared vantage point lets it do what no single client could.

Every capability below is easier, safer, or only possible at all in one managed tier rather than in a million client binaries. We tell the story through the two clearest cases, connection management and request batching.

Why ZippyDB Needed a Proxy Layer

Proxies show up wherever a large, diverse client population talks to a shared backend: a connection pooler, a service mesh sidecar, a CDN edge, an API gateway. Interposing between many callers and a shared resource buys three things.

• It bounds the problem: The backend stops seeing the client population and starts seeing a fleet its own operators control
• It creates a home for shared work — pooling, retries, routing, caching, admission control — solved once by the team that knows the backend best, instead of in every client.
• It creates a control point: The only place you can see the whole workload, attribute load to whoever generated it, and change behavior in minutes rather than waiting out a fleet-wide client rollout.

The tradeoff is a hop and one more tier to operate; the trade pays off when the client population is large, diverse, and not yours to change. ZippyDB is an extreme case.

In the direct-access model, every ZippyDB client connects to every database host it needs. A single client can touch tens of thousands of distinct shards in a stable window; those shards sit across hundreds of thousands of database hosts. The result is a dense many-to-many mesh of TLS connections: A typical client holds tens of thousands of outbound connections, and a typical database host can accept tens of thousands of inbound ones.

That mesh is wasteful and fragile. Every open connection consumes memory, CPU, and a file descriptor on both ends, mostly while idle, and inbound connections grow with the client population, so every new client cohort makes every database host worse. And because each client manages its own pooling and failover, a sudden drop in connection reuse — a cohort restarts, a deploy rolls — hits the fleet with a storm of new connections; we have traced host crashes from file-descriptor exhaustion and OOMs to exactly this.

It is hard to fix client-side because two systems move at once. Client fleets keep changing pooling policies and expanding while the database fleet consolidates on its own schedule. Coupling them directly feels like jumping between two moving cars. A proxy decouples them, collapsing the mesh into two bounded hops — a win on efficiency, performance, scalability, and above all reliability.

That last one matters most. Under direct access a reconnection storm becomes a catastrophe. In one incident a routing bug led every client to open a connection per shard, hosts breached their file-descriptor limit, and the fleet fell into a reboot loop. With ZGateway in the path that storm is contained at the proxy tier — a fleet we control, observe, and can harden centrally. Connection management does not disappear behind a proxy; it moves to the one place we can solve it.

Direct access was the right design for the initial part of ZippyDB’s life. Fan-in scales with the client population, so the resource use grows with adoption: at a few thousand clients the mesh is an inefficiency, at scale it is a reliability limit. The means arrived on the same schedule — ServiceRouter feature improvements, Thrift overload protection, a thin client, and other features are what make a shared tier feasible, and building ZGateway earlier would have meant building each of those first.

What ZGateway Is

ZGateway is a stateless proxy tier between ZippyDB clients and the database (ZServer) fleet. It can handle greater than 1 billion operations per second and carries about 40% of all ZippyDB traffic, projected to grow past 60%, while adding only about 6% computational overhead to an average use case. It currently carries about 40% of all the ZippyDB traffic and is growing while adding only about 6% overhead to an average use case. It runs as regional tiers discovered through ServiceRouter, Meta’s hyperscale service mesh solution, keeping every client near its gateway, in two flavors sharing one pipeline: a pure proxy and a read-through cache. it runs our thick C++ client as its engine, one internal client per use case. ZGateway is a ZippyDB client run as a managed service, which made moving capability here natural.

A client sends a request over its sticky connection to a regional ZGateway host, which terminates TLS, authorizes it against the use case’s ACLs, and applies per-tenant admission control, validation, and shaping. ZGateway resolves the shard, checks the local cache on a caching tier, and batches and coalesces misses and writes with other in-flight requests for that shard before sending them to the correct replicas. Responses are demultiplexed back to the callers, with per-use-case metrics, traces, and quota usage recorded along the way.

The key property is the asymmetry of connection counts. Each client needs only a sticky pool to its regional ZGateway hosts, and each ZServer sees connections only from the ZGateway fleet, whose size we control. Some responsibilities deliberately stay put — TLS in the Thrift/ServiceRouter stack, key-to-shard mapping in the shard locator, replica selection and hedging in the embedded client. ZGateway owns traffic management, not a reimplementation of the database client.

The Fan-In/Fan-Out Reduction

Here is the arithmetic:

Model the fleet as balls into bins. Throw B balls (shards a host touches) into H bins (hosts) and count distinct bins hit.

The expected number is: E(H,B) = H(1 - e^{-B/h})

And a specific bin is hit with probability: p(B) = 1 - e^{-B/H}

Fan-out is distinct bins hit; fan-in is that probability times the caller population. With round mock figures — 20 regions, 500,000 database hosts, 30,000 proxy hosts, 1,000,000 clients, 50,000 shards per client — the model yields:

The connections don’t vanish; they move to the tier built to hold them. End to end, total persistent connections still drop by roughly 19x, because each backend connection multiplexes many clients.

But the one-time reduction, however dramatic, isn’t the real point. The real point is the change in scaling behavior. In the direct model, database-host fan-in is H_client · p — linear in the client population, so every new cohort makes every database host worse. With ZGateway the client population drops out entirely: fan-in reduces to approximately R · S_host, regions times shard density per host, independent of both fleets. The only lever left is shard density, which we own. An unbounded number driven by everyone else becomes a bounded number we control.

Collapsing the Request Stream: Batching and Coalescing

Because ZGateway sits in the path of many clients it can do what no client library can – combine work across unrelated callers. A shared batcher on each host groups requests headed for the same destination, keyed by use case and physical shard, and merges them into one backend RPC.

It also coalesces. If several callers want the same key at the same moment, the gateway fetches it once and fans the result out. A client-side batcher can only merge its own process’s requests; the gateway collapses them across clients.

Every RPC carries fixed overhead regardless of size — Thrift serialization, shard lookup, authorization, syscalls — so folding many operations into one amortizes all of it, meaning fewer, larger backend requests, lower QPS and CPU, and steadier load as the linger window smooths micro-bursts. And because a use case is billed by the QPS it sends, batching stretches its rate-limit budget, cutting throttling with no work on its side.

Two of batching’s benefits aren’t about efficiency at all. The first is what coalescing does under a hot key. Thousands of simultaneous callers collapse into a single backend read, so a hot key can never become a stampede against one replica.

The second is what it lets us remove. For years, customers who wanted batching ran client-side libraries that were fragile, CPU-hungry, individually tuned, and a steady source of incidents because that complexity lived in a million binaries we didn’t control. A shared batcher batches across clients, which those libraries cannot — and let us retire them.

Each request is parked in an in-memory batch that flushes when a linger window elapses, the payload crosses a size limit, or the request count hits a cap, so added latency stays bounded; oversized or just-migrated batches fall back to individual sends. Holding requests in memory is an OOM risk, so batching ships with two safety mechanisms.

Idle eviction handles slow-burn growth: batch-map entries idle beyond a TTL are erased on the next flush. An in-flight cap handles acute overload. When the backend slows, coroutines running flushed batches pile up faster than they drain, so the cap rejects new executions once the count crosses its limit. Steady hygiene plus an acute safety valve is what makes batching safe by default.

How ZGateway Evolved

Once traffic flows through one tier, it becomes the natural home for capabilities every client would otherwise reimplement. Batching is the clearest example; here are the rest.

Traffic Routing and a Safe Migration Path

Moving traffic onto a proxy is a high-stakes migration. It must be incremental, reversible, and scoped. Routing to ZGateway is controlled by client-side configuration flags scoped per service and shard prefix: a percentage knob ramps eligible traffic, a region filter limits blast radius, a global kill switch gives instant rollback. It is pure configuration, with no client code change, which makes the rollout controllable in real time.

Tenant Isolation and Admission Control

A shared tier serves hundreds of use cases, so one misbehaving tenant must not starve the others. ZGateway’s defense is Discriminant Load Shedding (DLS). Every request maps to a per-tenant bucket, keyed by use case and split by priority, and buckets drain round-robin. When a tenant floods the tier, its own bucket fills and its excess is shed while every other bucket keeps draining — isolation as a property of the structure, not of luck. In front of DLS, a CPU concurrency controller uses an AIMD loop to adjust how fast the shared token bucket admits work; a memory handler guards against OOM the same way.

The shedding stays discriminant. In a controlled overload at >90% CPU across roughly 1,350 active tenant buckets, only 6 — the actual noisy neighbors — were shedding; the other ~1,344 executed 99.9% of their requests with zero rejections, goodput held near 97–98%, and the machinery cost about 8% of CPU.

Read Caching With Live Invalidation

On a cache tier, hot reads are served from an in-process cache; on a miss the gateway takes a per-key fill lock, so a thundering herd for one key collapses into one backend fetch. Freshness comes from a change-data-capture stream of write and checkpoint events that invalidates or refills affected entries, within an explicit bounded-staleness contract, and each host owns a slice of the keyspace by consistent hashing. The payoff is substantial read offload from storage, at lower latency, without losing correctness.

Load Balancing Across the Tier

Because ZGateway is stateless, any request can be served by any host in a regional tier, so we can steer traffic to even out load. The tier is not uniform. It mixes ~26-core to ~126-core hosts, and a large task replacement can reshuffle capacity in minutes. Equal treatment of unequal hosts produces hot outliers, and a hot ZGateway host is what turns into error-rate spikes and ServiceRouter throttling. Since ServiceRouter routes by weighted consistent hashing, the lever is the right weight per host.

A control-plane balancer computes them. On a fixed cadence it reads each host’s recent CPU utilization, normalizes the tier average to 1.0, and nudges each weight opposite to its load. Guardrails keep it stable — adjustments are damped and clamped, the distribution is re-centered on a target median so weights don’t drift toward zero, and a change throttle moves only the most-imbalanced hosts each run, limiting shard reshuffling (costly on cache tiers, where moving a weight means moving keys). New hosts start with weight scaled to hardware capacity.

The lesson is that one fixed policy cannot serve both a calm tier and a tier in shock. So the balancer is becoming adaptive, classifying each tier’s state — steady drift, task churn, flat initial weights, bimodal load, hot outliers, regional skew — and applying a matching policy.

Cross-Region Resilience

For most of its life ZGateway was strictly regional, failover stayed inside a region. Great for latency, but when an entire region’s tier comes under pressure, requests queue and time out locally while healthy capacity sits idle next door. Because ZGateway sits on ServiceRouter, we can let routing cross region boundaries in a controlled way, via three mechanisms:

• Global routing builds a routing table spanning regions, so a saturated local tier fails over to a healthy one instead of dying at home.
• Mega-regions group geographically close regions into one locality, so overflow spills nearby and keeps most of the latency benefit.
• Rings declare exactly which regions back each other up, and in what proportion.

Each is enabled per tier and region behind a percentage knob. The failover signal mattered as much as the routing. A simple regional CPU average smooths over exactly the hot conditions we need to catch, so failover keys off a sharper measure, tuned to fire before a region tips into overload rather than after.

Transactions and Richer Operations

A transaction needs somewhere to keep its client-side bookkeeping: read set, scanned ranges, pending writes. Historically that lived in the thick client. When ZGateway moved customers onto a thin client, it had to move onto the gateway. The first cut left two parallel implementations — a bespoke store built for ZGateway alongside the in-memory path our engine already used — two versions of the most correctness-critical part of the flow.

We consolidated onto one, behind a flag, in nine phases up to the highest-volume regions, reaching 100% of transaction traffic with no reliability regression. Sharing that path with the engine keeps ZGateway in lock-step with server-side transaction evolution: evolve a capability once, inside the tier, and every client inherits it.

Operating ZGateway in Production

ZGateway runs as a large volume of servers across dozens of regions, in a handful of tiers by workload – one large general-purpose tier for the long tail of use cases, dedicated tiers for our largest customers, and a separate high-throughput proxy tier. They differ in footprint and size by more than an order of magnitude, and individual tiers aren’t uniform either, largely because of stacking. Multiple tasks are packed onto one machine at varying densities, next to full-size dedicated hosts. Across all of it, ZGateway exposes rich per-use-case observability — the visibility that makes the admission control and load balancing above safe on shared infrastructure.

What’s Next for ZGateway

The near-term trajectory, to unify all ZippyDB traffic through ZGateway, is unchanged. The more interesting question is what a universally-adopted gateway makes possible. Three directions stand out, and they all share a common theme – ZGateway both sees the most and decides the most.

Agent-operated heuristics. Almost every capability here is governed by a control loop and hand-tuned knobs: load-shedding bucket sizes and CPU thresholds, balancer parameters, failover triggers, batch flush windows, cache staleness bounds. Today those are tuned by humans and nudged by crons; the adaptive balancer above is already an agent in all but name. The next step is to make it explicit and expose those heuristics and internal state as a structured control surface, and let AI agents watch the same telemetry we do — diagnosing tier state, attributing an incident to a noisy tenant, and applying remediation behind guardrails faster than any oncall could.

Co-location. ZGateway is a distinct tier, which costs an extra network hop and a few percent of overhead. For latency- or efficiency-critical workloads we can push part of the gateway down beside the ZServer host, so the gateway↔server leg becomes a local call while the control plane stays central. The trick is doing it without re-coupling the fleets we deliberately decoupled. The connection-management and admission-control front stays a shared regional tier, and only what benefits from data locality moves down.

A multi-process gateway. ZGateway runs many distinct responsibilities in one process, so one tenant’s memory blowup can threaten everything on the host. Splitting it into cooperating processes — a connection/TLS front-end, request workers, separate cache and transaction components — buys hard fault isolation and an independent lifecycle. This is also complemented by agent-operated heuristics and co-location agents can manage the process fleet on a host, and co-location gets cleaner when the data plane is already its own placeable process.

Together these turn ZGateway from a smart tier into a programmable one with control decisions made by agents, a footprint that moves to where the work is, and failure domains isolated by construction.

Alien

Alien provides infrastructure to deploy and operate software inside your users' environments, while retaining centralized control over updates, monitoring, and lifecycle management.

Why Alien?

Self-hosting works - until someone starts paying for your software.

Customers run it in their own environment, but they don't actually know how to operate it. They might change something small like Postgres version, environment variables, IAM, firewall rules, and things start failing. From their perspective, your product is broken. And even if the root cause is on their side, it doesn't matter... the customer is always right, you're still the one expected to fix it.

But you can't. You don't have access to their environment. You don't have real visibility. You can't run anything yourself. So you're stuck debugging a system you don't control, through screenshots and copy-pasted logs on a Zoom call. You end up responsible for something you don't control.

Alien provides a better model: managed self-hosting.

Quickstart

Install the CLI:

curl -fsSL https://alien.dev/install | sh -s -- --login

irm https://alien.dev/install.ps1 | iex

Create a project and start developing:

alien init
cd alien && alien dev

Follow the Quickstart guide to build an AI worker, test it locally, and deploy it — no cloud account needed to start.

CLI automation

Every platform workflow has a non-interactive form. Link a directory once, then commands use that project unless --project is provided explicitly:

alien login
alien projects list
alien link --project my-project
alien projects describe --json

# Configure project capabilities.
alien projects capabilities enable models \
  --model byo/claude-opus-5 \
  --provider anthropic

# Create a least-privileged key and onboard a customer environment.
alien api-keys create --for ai-gateway --description production-backend --json
alien onboard acme --external-id customer_123 --setup-items models,keys --json

# Print an executable request for the active environment.
alien examples ai-gateway --protocol anthropic-messages

# Search structured gateway diagnostics without writing a raw query.
alien logs --source ai-gateway --status provider-error --provider anthropic --json

# Inspect live rollout state without parsing the raw stack state.
alien deployments status production/api
alien deployments resources production/api --json
alien deployments wait production/api --for ready --timeout 10m --json

# Read privacy-safe aggregate usage.
alien usage ai --range 7d --json

Resource detail commands accept get, describe, and show; list commands accept both list and ls. JSON mode never prompts and writes structured data to stdout, making the same CLI suitable for humans, scripts, and coding agents. The normalized resource view intentionally excludes resource configuration, internal controller state, environment variables, and arbitrary provider outputs.

Features

• AWS, GCP, and Azure support - Deploy to all major clouds.
• TypeScript & Rust — First-class support for both. Python and arbitrary containers coming soon.
• Real-time Heartbeat — Know the instant a deployment goes down.
• Auto Updates & Rollbacks — Push a release and every remote environment picks it up automatically.
• Local-first Development — Build and test on your machine. Local equivalents for every cloud resource.
• Cloud-agnostic Infrastructure — Ship to AWS, GCP, and Azure customers without maintaining separate integrations. Alien maps a single API to each cloud's native services at deploy time.
• Remote Commands — Invoke code on remote deployments from your control plane. Zero inbound networking. Zero open ports. No VPC peering.
• Observability — Logs, metrics, and traces from every deployment. Full visibility without touching customer infrastructure.
• Least-privilege Permissions — Alien derives the exact IAM permissions required to deploy and manage your app.

How deployment works

Push model

Like sharing a Google Drive folder. The customer grants least-privilege access to an isolated area in their cloud. You run alien serve on your infrastructure and it manages everything through cloud APIs (e.g. AWS UpdateWorkerCode). No network connection to their environment needed.

alien serve

Pull model

Like an app checking for updates. For customers that can't or won't allow a cross-account IAM role, they can run alien-operator in their environment instead. It connects outbound to the Alien server, fetches releases, and deploys locally. No inbound connections, no open ports.

docker run ghcr.io/alienplatform/alien-operator \
  --sync-url https://alien.example.com \
  --sync-token <token> \
  --platform aws

Both models give you the same capabilities: updates, telemetry, remote commands.

One codebase, every cloud

Ship to AWS, GCP, and Azure customers without maintaining separate integrations. Alien maps your stack to each cloud's native services at deploy time.

import * as alien from "@alienplatform/core"

const data = new alien.Storage("data").build()
const secrets = new alien.Vault("credentials").build()

const api = new alien.Worker("api")
  .code({ type: "source", src: "./api", toolchain: { type: "typescript" } })
  .link(data)
  .link(secrets)
  .commandsEnabled(true)
  .publicEndpoint("api")
  .build()

export default new alien.Stack("my-app")
  .add(api, "live")
  .add(data, "frozen")
  .add(secrets, "frozen")
  .build()

At deploy time, each resource maps to the cloud's native service.

Releases

Push a release and every environment updates automatically.

alien release

What you can build

• AI Worker — Operator harness in your cloud, tool execution in theirs. Read files, run commands, query data — all local.
• Data Connector — Query Snowflake, Postgres, or any private database. No shared credentials, no exposed services.
• Browser Automation — Headless browser inside their network. Navigate Jira, SAP, GitLab, on-prem wikis.
• Security Outpost — Scan IAM policies, storage, network configs from inside the perimeter. On a schedule or on-demand.
• Cloud Actions — API inside their network. Restart services, rotate credentials, react to infrastructure changes.

Remote commands

Invoke code inside the customer's environment from your control plane. Zero inbound networking, zero open ports.

Define a handler in the customer's environment:

import { command, storage } from "@alienplatform/sdk"

const files = storage("files")

command("read-file", async ({ path }) => {
  const data = await files.get(path)
  return { content: new TextDecoder().decode(data) }
})

Invoke it from your backend:

import { CommandsClient } from "@alienplatform/commands"

const commands = new CommandsClient({ managerUrl, deploymentId, token })
const result = await commands.target("api").invoke("read-file", {
  path: "report.csv"
})

Least-privilege permissions

You're deploying to someone else's cloud. Every permission needs justification. Alien derives exactly the permissions needed from your stack definition — for AWS, GCP, and Azure.

export default new alien.Stack("my-app")
  .add(data, "frozen")
  .add(api, "live")
  .permissions({
    profiles: {
      execution: {
        data: ["storage/data-read", "storage/data-write"],
      },
    },
  })
  .build()

From this definition, Alien derives three layers of permissions:

Provisioning — Creates all resources during initial setup. The customer's admin runs alien-deploy deploy once with their own credentials. Alien never holds these permissions.

Management — What Alien uses day-to-day to manage the deployment:

• 🧊 Frozen resources: health checks only. No ability to modify, delete, or read data.
• 🔁 Live resources: push code, roll config, redeploy. But still no data access — Alien can call lambda:UpdateWorkerCode but never s3:GetObject. Management and data access are separate.

Application runtime — What the deployed code can access. Only what's declared in permission profiles.

Production deployment

1. Generate a config template:

alien serve --init   # creates alien-manager.toml

2. Provision cloud resources for push-mode platforms:

module "alien_infra" {
  source = "github.com/aliendotdev/alien//infra/aws"

  name          = "my-project"
  principal_arn = aws_iam_role.manager.arn
}

3. Run the server.

docker run -d -p 8080:8080 \
  -v alien-data:/data \
  -v ./alien-manager.toml:/app/alien-manager.toml \
  -e BASE_URL=https://manager.example.com \
  ghcr.io/alienplatform/alien-manager

Full article content is not available for inline reading.

Read the original article →

YOLO Mode: Agent Autonomy Without the Guardrails

AI agents have come a long way in both capability and everyday use since generative AI went mainstream in late 2022. In Stack Overflow’s 2025 Developer Survey, 84% of developers said they use or plan to use AI tools in their workflow, up from 76% a year earlier. As those tools shift from suggesting code to writing files and running commands on their own, one practical question follows. How much should an agent be allowed to do without stopping to ask? Turn that dial all the way up and you reach what developers call YOLO mode.

It’s worth understanding YOLO mode before you enable it, because its main risk is easy to misread. The risk comes down to where an agent runs. On your own machine, one mistaken command can delete files, expose your credentials, and make network requests you may not want. Inside a proper boundary, however, developers can use agents in YOLO mode to unlock a new level of productivity, without jeopardizing security.

Key takeaways

• YOLO mode is when an AI agent auto-approves every action, with no confirmation prompts.
• It’s popular because it’s fast, and risky for the same reason. The danger isn’t the autonomy, it’s where the autonomy runs.
• On your host, a bad command or prompt injection reaches real files and credentials. Inside an isolated sandbox, the blast radius is contained.
• Run YOLO mode where it can’t do real damage, in an isolated, disposable environment with scoped access and no real secrets.

What is YOLO mode?

YOLO mode is the community nickname for running an AI agent with every action auto-approved. When turned on, agents can read files, write code, run shell commands, and call tools without stopping for user approval. While in Claude Code it’s the –dangerously-skip-permissions flag, other common agents each have their own version of the same switch.

• Codex CLI has `–full-auto`, plus `–dangerously-bypass-approvals-and-sandbox` when you drop the sandbox too.
• Gemini CLI uses `–yolo`, or the Ctrl+Y toggle mid-session.
• GitHub Copilot CLI has `–allow-all`, also aliased as `–yolo`.
• Cursor exposes it as auto-run in settings rather than a flag.

The names differ, but the behavior is the same: remove the prompts and let the agent go.

YOLO mode showed up in Cursor first, then Claude Code, and by 2026 it’s a standard toggle in most coding agents. But when people ask what YOLO mode is, they’re usually asking whether they should use it, and the answer is that it depends entirely on where the agent is running.

Why developers turn it on

On a regular task, a careful agent asks for permission constantly. “Can I edit this file, run this test, install this package, call this tool?”

Dozens of prompts for one feature. While these constant permission requests can help prevent agents from going rogue, each approval forces you to context switch and breaks the flow that made the agent worth using. A few reasons why developers are leveraging YOLO mode include:

• Context switching: Every approval pulls a developer out of their flow, taxing mental focus and overall productivity.
• Prompt fatigue: Excessive querying, refinement, and approvals force creative coding to take a back seat to tedious prompt wrangling and debugging.
• Low-risk, routine work: Agents can often handle repetitive tasks that would otherwise take developers away from creative coding and innovation.
• Momentum: An agent is most useful when it has the freedom to keep moving, but a steady stream of prompts breaks that.

If you turn approvals off, these friction points disappear for the most part, and the agent can deliver the speed it promised. But what’s the cost of giving agents the autonomy of YOLO mode?

Why is YOLO mode risky?

When you remove the prompts, you remove the last human check before an action runs, which amplifies the security risks agents already carry. If the agent is working directly on your host, that action has the full run of your machine, including your files, environment variables, credentials, and network. A confused or compromised agent can do a significant amount of damage when nothing stands between an agent’s decision and your system.

On an unprotected host, YOLO mode introduces risks such as:

• Destructive commands: A vague or mistaken instruction runs something like rm -rf against the wrong directory, and nothing pauses to catch it.
• Secret and credential exposure: The agent can read environment variables, .ssh keys, tokens, and .env files, then use or leak them.
• Prompt injection: The agent acts on whatever it reads, so a hidden instruction in a web page, an issue, a code comment, or a document can redirect it, and the attacker never needs access to your machine.
• Data exfiltration: A mistaken or hijacked agent sends sensitive data out over the network.
• Unintended broad changes: Edits and config changes reach past the task at hand into your other projects.
• Network and lateral reach: The agent can hit internal endpoints and outside services, or act with your credentials to push code and call APIs.

And unfortunately, keeping manual approvals on doesn’t remove all risk. Once permission fatigue kicks in, it can be all too easy to accidentally approve the wrong request. So the safeguard belongs in the environment the agent runs in, where a bad command or a tired click has a greatly reduced scope of impact.

The fix isn’t fewer permissions, it’s a boundary

If prompts aren’t the answer, what is? A boundary the agent can’t cross. Guardrails only work when something outside the agent enforces them. The agent needs a bounding box, with constraints set before it runs and clear limits on what it can touch. Inside that box, it should be free to move as fast as it wants. The goal is to shape the environment so that a mistake can’t damage your systems or leak your secrets.

In practice, that means running the agent in an isolated, ephemeral environment instead of on your host. Done well, the agent gets a real place to work. It can install packages, run services, and edit files, but it can’t see your credentials, reach your other projects, or touch the host.

Unlike a container that shares the host kernel, a microVM puts a hardware-level boundary around the agent, so the isolation holds even if the agent tries to break out, and it does that without the speed penalty people expect. If a run goes sideways, you destroy the environment and start clean. This is the core idea behind sandbox security and why agents need isolation in the first place.

What does YOLO mode look like at scale?

For one developer on a sandboxed laptop, YOLO mode is a personal choice. Across a team, it becomes a policy question. A hundred developers each deciding on their own when to skip permissions is the ungoverned-autonomy problem that keeps security leaders up at night. The picture that works at scale is one where the safe path is the default. Every agent runs inside an isolated, disposable environment, configured once at the organization level so it holds for everyone.

This is the problem AI Governance is built to solve. You define the rules once across the surfaces that matter, network access, the filesystem, and the tools an agent can reach, then enforce them automatically at every developer’s machine. Governance turns a per-developer judgment call into a consistent, repeatable capability. Clear boundaries are what let an organization extend autonomy to its agents while keeping the risk contained. Once the boundary is standard, YOLO mode is fast and safe for everyone.

What it unlocks for developers

Once the boundary is in place, the developer can stop supervising every step, and the payoff kicks in:

• Deep focus: Give direction, step away, and come back to a cloned repo, passing tests, and an open pull request. No interruptions pulling you off your own work.
• Long, autonomous runs: The agent edits, runs the tests, reads the failures, and retries until the task is done, the kind of run a wall of prompts would stall.
• Agents in parallel: Point several at different tasks, each in its own disposable environment, and let them run at once.
• You review the outcome: Your job moves up to the pull request, the tests, and the diff, where your judgment matters most.

That’s the real appeal, and the sandbox is what makes it safe to lean on.

Unlock agent autonomy, safely

YOLO mode is really a question in disguise. How much autonomy can you give an agent before the risk outweighs the speed? Framed that way, the answer stops being about the agent and starts being about its environment. Give an agent the run of your laptop and even a small mistake is expensive. But give it a boundary it can’t cross and you get the speed with almost none of the exposure.

That’s exactly what Docker Sandboxes is built for. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so you can run agents in YOLO mode safely from day one. For teams that want those boundaries applied consistently rather than agent by agent, Docker AI Governance sets and enforces the rules everywhere developers work. Define the box. Then let the agent go as fast as it likes.

Frequently asked questions

Is YOLO mode safe?

It depends entirely on where the agent runs. On your host machine, YOLO mode is risky, because a mistake or a prompt injection can reach your files and credentials. Inside an isolated, disposable environment with scoped access and no real secrets, the blast radius is contained and YOLO mode is reasonable to use.

What does –dangerously-skip-permissions do in Claude Code?

It turns off the confirmation prompts, so Claude Code reads, writes, runs commands, and calls tools without asking for approval at each step. It trades the safety of human review for speed. It’s the most common way people run Claude Code in YOLO mode.

How do I use YOLO mode safely?

Run the agent inside an isolated sandbox rather than on your main machine, give it scoped network access and throwaway credentials instead of your real ones, work against a cloned or disposable copy of your project, and keep a way to inspect what it did. The goal is a boundary the agent can’t cross, not a more careful set of prompts.

Is auto mode the same as YOLO mode?

Not exactly. Full YOLO mode approves everything. Some tools now offer a classifier-gated auto mode that runs safe actions automatically while still blocking or flagging dangerous ones. That’s a useful middle ground, but it’s a filter on top of the agent, not a boundary around it. Isolation still matters.

Portal by Spotify cut my Claude Code token usage by 90%

Most of what an AI coding agent does for me isn't thinking. It's I/O.

Reading five files to answer a question about one method. Generating a test file that follows the exact same pattern as the twenty test files next to it. Updating docs after a meeting. Thousands of tokens gone and almost zero reasoning. The seat license isn't what hurts, it's the tokens. And you're feeding all of it to a frontier model that's wildly overqualified. What if you could route the grunt work to something cheaper that handles it just as well, and save the expensive model for the problems that actually need it?

It’s hardly just my problem. By 2028, AI coding costs are expected to blow past the average developer's salary. A quarter of engineering leaders already burn $200–$500 per developer per month on tokens. Some are well past $2,000. The tooling pays for itself but only if you stop burning frontier tokens on work that doesn't need them.

Turns out, the fix didn't require a platform team or a new subscription. Just two modes.

Two modes, zero code

This is exactly the kind of use case AiKA Modes in Portal by Spotify were built for. A mode is a declarative agent that runs on an ephemeral runtime - think AWS Lambda, but for agents. You define the instructions, pick a model, set parameters like temperature, and attach MCP tools. Portal handles the rest. No infra to manage, no API keys, no long-running servers. Modes are callable from the Portal CLI or API. They can be public (shared with the whole company) or private.

For this router to work I created two modes. Both use Gemini 2.5 Flash as the worker model in the examples below, but the model field accepts any model you have configured in your Portal instance. Pick whichever works for you.

Mode 1: bulk-reader

For when Claude would otherwise read multiple large files just to answer one question.

name: bulk-reader 
description: Bulk file reader for code analysis - delegates I/O from Claude Code 
instructions: You are a precise code analyst. Read the provided files and answer the question concisely. Output structured bullets only. No greetings, no prose, no preambles. Lead every bullet with the exact name, type, or line number. Use nested bullets for details. Skip anything the caller did not ask for. 
visibility: public 
model: gemini-2.5-flash 
resourceLimits: 
  temperature: 0.2 
tags: 
  - coding 
  - delegation

Mode 2: code-writer

For tests, config scaffolding, type stubs or anything where the output is predictable from existing patterns.

name: code-writer

description: Boilerplate code generator - delegates output-heavy work from Claude Code

instructions: You generate code files based on a spec and reference files. Match the existing patterns, conventions, naming, and style exactly. Output only the code — no explanations, no markdown fences unless asked. If the spec is ambiguous, make reasonable choices that match the reference code's patterns.

visibility: public

model: gemini-2.5-flash

resourceLimits:
  temperature: 0.2

tags:
  - coding
  - delegation

That "output only the code" instruction matters. Without it, the model wraps everything in markdown fences and explanatory prose that Claude then has to parse through.

Routing

The first version of this was a block of routing rules in CLAUDE.md. It sort of worked: Claude would read the instructions and self-route to Portal. But it had problems. The rules were advisory, not enforced. Claude could ignore them. And every project needed its own copy of the instructions.

The current version is a Claude Code plugin called shunt. Delegation goes through the Portal CLI actions registry so the plugin works against any Portal instance with AiKA plugin enabled.

Layer 1: Hooks

Claude Code hooks fire before every tool call. Shunt registers two PreToolUse hooks:

check-file-size fires on every Read call. If the file exceeds a configurable line threshold (default: 350), the hook blocks the read and tells Claude to use the /bulk-reader skill instead. Targeted reads pass through - Claude already knows what section it needs.

check-bash-read catches cat, head, tail, less, and more on large files. Piped commands (cat file | grep) pass through since those are targeted reads.

The threshold is configurable via the SHUNT_MIN_LINES environment variable. Set it in your shell profile or in .claude/settings.json:

{
  "env": {
    "SHUNT_MIN_LINES": "500"
  }
}

Layer 2: Scripts

I have two bash scripts that wrap the Portal CLI calls. Claude calls a script with named arguments. The scripts handle everything internally: building the request, invoking the actions, unwrapping errors, and reporting token usage to stderr.

Modes are addressed by name and resolved by Portal: case-insensitively, preferring your own mode, then your team's, then public ones. Fork the public bulk-reader into a customized version and yours automatically takes precedence - no configuration needed.

bulk-read wraps each file in XML tags for clear boundaries and sends them to the bulk-reader mode along with the question.

bulk-read --question "What does this service do?" --paths src/Service.java src/Handler.java

# Follow-up: ask again with the same paths

bulk-read --question "Which methods call the database?" --paths src/Service.java src/Handler.java

Every delegation is one shot. The invocation is ephemeral (nothing is stored server-side) and re-sending the files on a follow-up is free where it matters, because the corpus goes to the worker model and never enters Claude's context.

code-write sends a spec and a reference file to the code-writer mode, strips markdown fences from the output, and can write directly to disk. Claude never sees the generated code. The reference is required: without a file to match patterns against, the worker would generate context-free code that fits nothing in your project.

code-write --spec "Write tests for UserService" --reference tests/OrderTest.java --target tests/UserTest.java

# Output to stdout

code-write --spec "Generate a config stub" --reference config/existing.yaml

Layer 3: Skills

Two skill files tell Claude when and how to call the scripts. Skills are markdown files with a description and usage examples. When the hook blocks a read, the block message points Claude to the /bulk-reader skill, which shows the exact invocation syntax.

The benchmarks

Tested against a Java monorepo across four scenarios, measuring tokens Claude would consume reading files directly vs. consuming the bulk-reader's summary or writing code via the code-writer. Mean bulk-read savings were around a whopping 90%.

What doesn't work

You can't delegate editing. The worker model's summaries don't include reliable line numbers. If Claude needs to make edits based on the analysis, it still has to read the specific section directly.

You can't delegate reasoning. The worker model found surface-level patterns but missed a subtle thread-safety bug in my testing. Claude spotted it in seconds once given the right context.

Latency adds up. Each delegation is a network round-trip: Claude Code to the Portal backend to the worker model and back. Responses typically take 10–30 seconds.

Token savings are just the starting point

The plugin is a Claude Code artifact, but the idea underneath is model routing powered by AiKA modes. The modes are the load-bearing piece:

• They're reusable.
• They're shareable.
• They're composable.
• They decouple the routing decision from the worker.

Try it yourself

1. Install both plugins from the spotify/portal-ai-plugins marketplace:
   • claude plugin marketplace add spotify/portal-ai-plugins
   • claude plugin install portal@portal
   • claude plugin install shunt@portal
2. In a new Claude Code session, run /portal:setup to set up and authenticate the Portal CLI against your Portal instance.
3. You’re good to go, just ask a question that spans multiple files.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Sail 0.7: Stateless Compute, Durable Job State

Sail 0.7 delegates shuffle and checkpoint state to object storage, making jobs more resilient and letting them run on smaller clusters.

The Sail 0.7 release comes with two highly requested features: blocking shuffle and checkpoint. Both stem from the same philosophy: an engine should treat decoupled storage and compute as its native environment, not an accommodation.

Cloud data infrastructure has been converging on this shape for over a decade. Data lives in object storage, durable, cheap, and effectively unlimited. Compute appears when a job starts and disappears when it finishes. You store everything, and you pay for compute only while it runs.

One kind of state still resists the decoupling: the intermediate data inside a running job. Shuffle data and checkpoint data accumulate as a job executes, and in Spark and most other engines they live on the workers themselves. A lost worker loses data. A running job pins its cluster.

How does Sail leverage this? Sail’s workers are stateless by design, and 0.7 applies that principle to a job’s intermediate data: we delegate state management for shuffle data and checkpoint data to external storage, making the architecture simpler and more scalable, and making Sail a stronger fit for the composable data stack.

Blocking Shuffle

In Sail, a job is represented as a directed acyclic graph (DAG) of stages, where each stage runs parallel tasks to process partitioned data. The job stages exchange data under different modes, including shuffle, forward, and broadcast. The stage definition also indicates whether the stage output should be pipelined or blocking, which affects how stages are scheduled in the control plane.

Stages connected by pipelined data exchange form a task region whose tasks must be scheduled and retried together. The boundaries between task regions are blocking data exchanges, where data is persisted before downstream task regions are scheduled. Both pipelined and blocking exchanges can coexist in one job graph, providing a flexible blueprint for the job’s control-plane scheduling and data-plane operations.

The design for data exchange modes and task regions forms Sail’s unified shuffle architecture, which blocking shuffle is built on top of. We implement blocking shuffle by inserting an additional stage at each shuffle boundary. This stage receives shuffle data from mapper tasks in the previous stage and merges it into a single output stream for each reduce partition. This is essentially a “no-op” reducer stage whose output is marked as blocking, so the stream manager writes the output as compressed Arrow data to object storage. The actual reducer stage connects with the auxiliary “no-op” reducer stage with forward mode and blocking data exchange, so that the actual reducer stage belongs to a separate task region and reads the persisted shuffle data from object storage after the previous task region completes.

A blocking shuffle, planned as ordinary stages: map tasks shuffle into a merge stage within one task region, the merge stage writes one compressed Arrow stream per reduce partition to object storage, and each reduce partition runs as its own task region that reads the persisted data after the first region completes.

This implementation elegantly achieves a similar effect to the ”push-based” shuffle merging described in the Magnet paper (which is also discussed in the Exoshuffle paper). In doing so, it avoids writing one file per reduce partition for every mapper task, naturally preventing the “small file problem” when naively adopting the “pull-based” shuffle implementation for object storage.

Blocking shuffle improves resiliency and helps jobs scale. In the default pipelined shuffle mode, a task failure can cause all connected stages to retry because the intermediate data has not been materialized. With blocking shuffle, data is first written to persistent storage. Downstream tasks can retry by reading from that storage again, rather than triggering cascading retries of upstream tasks.

Although persistence adds write overhead, it can reduce total job runtime when workers are frequently preempted or memory is constrained. It also enables jobs to run on smaller clusters. Pipelined shuffle requires all connected tasks to run concurrently, whereas blocking shuffle requires only one task region to be active at a time. Downstream task regions can be scheduled after the previous task region completes, reusing the same underlying worker resources.

Getting started with storage-based blocking shuffle is easy. You define the following environment variables for the Sail server to specify storage as the shuffle backend and a base path to store shuffle data.

export SAIL_CLUSTER__SHUFFLE_BACKEND__TYPE=storage
export SAIL_CLUSTER__SHUFFLE_BACKEND__STORAGE__PATH="s3://sail/shuffle"

Checkpoint

The Spark DataFrame.checkpoint() API allows you to store intermediate data for reuse. This is important for iterative processing (typically seen in graph algorithms). Without checkpoint the query plan can grow exponentially large during iterations, and all the computation is done from scratch in every step.

The example below computes connected components by label propagation: every vertex starts in its own component and repeatedly adopts the smallest component ID among itself and its neighbors. This is a classic use case when checkpointing is a must.

from pyspark.sql import functions as F

vertices = spark.createDataFrame(
    [(1,), (2,), (3,), (4,), (5,), (6,)],
    ["id"],
)
edges = spark.createDataFrame(
    [(1, 2), (2, 1), (2, 3), (3, 2), (4, 5), (5, 4)],
    ["src", "dst"],
)

labels = vertices.withColumn("component", F.col("id"))

for _ in range(3):
    neighbor_min = (
        labels.join(edges, labels["id"] == edges["src"])
        .groupBy(F.col("dst").alias("id"))
        .agg(F.min("component").alias("neighbor_component"))
    )
    labels = (
        labels.join(neighbor_min, "id", "left")
        .withColumn(
            "component",
            F.least("component", F.coalesce("neighbor_component", "component")),
        )
        .drop("neighbor_component")
        .checkpoint(eager=True)
    )

labels.orderBy("id").show()

Previously, due to the lack of checkpoint support in Sail, users had to explicitly write their data and then read it back again. Now, with eager checkpointing, data materialization happens behind the scenes, allowing users to focus on the business logic in their code. We also plan to support lazy checkpointing, where data is materialized implicitly upon first use.

Spark distinguishes between DataFrame.localCheckpoint and Dataframe.checkpoint(), where the former stores data in the executor’s local disk. In Sail, since all workers are stateless, we favor supporting the latter. To store the checkpoint data, you can either use a shared network file system available to all nodes in a cluster, or an object store such as AWS S3. The checkpoint data is scoped to the session and Sail handles data cleanup when the session ends.

Getting started with checkpoint is also easy. You define the following environment variable for the Sail server to specify a base path to store checkpoint data.

export SAIL_EXECUTION__CHECKPOINT__PATH="s3://sail/checkpoint"

Getting Started with Sail

Sail 0.7 works with the latest PySpark 4.2 client. It is available on PyPI. Install or upgrade with pip install pysail==0.7.0, or see the installation guide for standalone binary and Docker options. The documentation covers cluster deployment and configuration in detail.

Join the Community

Sail 0.7.0 has received a record-breaking 11 community contributors (with 5 being first-time). Sail wouldn’t have its current shape without its community, and we welcome contributions of all kinds: code, feature ideas, and especially bug reports with reproducible examples.

Stay tuned for more feature announcements. You can follow along on GitHub or by joining our Slack Community.

Apache Kafka vs Apache Iggy: Same Log, Different Engine

Is Apache Iggy a faster Apache Kafka?

At first glance, this looks like a fairly simple comparison. Both systems persist messages in partitioned, append-only logs. Both have offsets, retention policies, consumer groups, and replay. Apache Iggy is written in Rust with a thread-per-core architecture on top of io_uring, while Kafka runs on the JVM. So perhaps we should run a benchmark and pick the faster one.

If the name is new to you: Iggy is a message streaming platform written in Rust, freshly promoted from the Apache Incubator to a top-level Apache project in August 2026 - which is exactly why it is showing up in comparisons like this one. Kafka needs no introduction.

Such a comparison quickly becomes incomplete without asking a basic question: what exactly does a successful write means? Was the message copied into a memory buffer? Written to the operating system page cache? Flushed to a local disk? Replicated to another machine? Replicated to another data center? And what happens when the machine, rack, or entire data center disappears immediately after the producer receives an acknowledgement?

This is where Kafka and Iggy currently start to look very different.

A young project, moving fast

A few words about Iggy first. Piotr Gankiewicz started it in early 2023 as a way to learn Rust by building something real; the name is short for Italian Greyhound - a small but extremely fast dog - and, as a Polish engineer, I enjoy how much of its core team comes from Poland. The project entered the Apache Incubator in early 2025 and graduated unanimously in August 2026, almost exactly as its long-running replication work approached a first clustered release. That timing frames this article: we are no longer comparing Kafka with the single-node-only Iggy described in most existing write-ups, but neither are we looking at a replicated release with years of production history.

They agree on the basic data model

Iggy is not trying to replace the log with a different abstraction. Its storage model should look familiar to anyone who has worked with Kafka. An Iggy Stream is an additional namespace above topics. Apart from that, the hierarchy is close to Kafka. A partition is an ordered, append-only log consisting of segments. Messages have offsets. Consumers can start from an explicit offset, a timestamp, the beginning or the end of the log, or continue from a server-side stored consumer offset.

This makes it a different kind of comparison than with systems that replace the event log with a database or a streaming table-a story we covered separately when looking at Apache Fluss. Iggy does not argue that Kafka picked the wrong abstraction; it asks whether the same abstraction can be implemented differently. The rest of this article is about where those implementation choices land.

Where Iggy actually differs

Kafka has had a long time to optimize its storage path. It writes sequentially, batches aggressively, uses the operating system page cache, and can use zero-copy transfer when serving data to consumers. The idea has always been to avoid fighting the operating system unnecessarily.

Iggy takes a more explicit approach to controlling the runtime. Starting with version 0.6.0, the server moved from a Tokio-based model to a thread-per-core architecture built on the compio runtime, which uses io_uring on Linux. Partitions are assigned to CPU-pinned shards: instead of a work-stealing executor moving tasks between threads, each shard owns a part of the workload and executes it on a specific CPU core.

On top of that, Iggy maintains its own preallocated memory pool and uses vectored I/O to write batches of message buffers to disk. The motivation is mostly about predictability: with a thread-per-core model, a hot partition does not continuously move between worker threads, there is less synchronization on the data path, less cache invalidation, and fewer allocations. The project reports large tail-latency improvements from this rewrite, which is one of the places where work-stealing runtimes can hurt.

It would be easy to reduce all of this to:

Kafka = JVM + GC
Iggy  = Rust + no GC

but that misses most of the engineering involved. Kafka is not a traditional application that constantly allocates and transforms message objects on its hot path; a large part of its performance comes from doing as little with the payload as possible and letting the operating system handle caching and sequential I/O. The more useful distinction is that Kafka delegates a lot of storage caching to the OS, while Iggy tries to control more of the execution and memory path itself.

What happens when a producer writes a message?

This is where performance comparisons get tricky. The Iggy write path looks roughly like this:

Messages are buffered until a configurable count or size threshold is reached - at the time of writing, the defaults are 1024 messages or 1 MiB - and fsync is configurable per topic. The important part is that an accepted write and a durable write are not automatically the same thing. Iggy's documentation is explicit that the default single-node configuration has low durability guarantees and that a crash or power loss can lose messages unless the durability settings are adjusted; the server exposes enforce_fsync and flush thresholds to control that trade-off.

Kafka has the same underlying problem, but solves it differently. Kafka does not normally fsync every individual message either. Instead, production durability is typically based on replication:

replication.factor = 3
min.insync.replicas = 2

producer:
acks = all

A producer acknowledgement now means more than "the leader accepted my write." Kafka maintains an ISR - the set of in-sync replicas, meaning replicas that are currently caught up with the leader - and with acks=all, the write is not acknowledged until it has reached the replicas required by min.insync.replicas from that set.

That distinction matters a lot if we want to compare latency. An Iggy producer waiting for a local write and a Kafka producer waiting for replication to another machine are not measuring the same thing. Neither are a local buffered write, a local fsync, and a replicated write across two data centers. Before comparing numbers, we need to define the failure we expect the acknowledged message to survive.

What do the published numbers actually measure?

I am deliberately not running my own Kafka-versus-Iggy benchmark for this article, but the numbers the Iggy project publishes are still worth reading-with the previous section in mind.

The project's FAQ reports that the thread-per-core migration alone brought up to 92% better P9999 tail latency, and an 18% throughput improvement with fsync enabled. The project site advertises millions of messages per second with sub-millisecond tail latencies on a single node, and the repository ships its own iggy-bench tool with a note that the default configuration is tuned for performance. These are credible numbers for what they measure: the efficiency of a single-node log engine under Iggy's own acknowledgement semantics.

What they are not - yet - is a fully like-for-like Kafka comparison, and in fairness to Iggy, today they cannot be: you cannot benchmark replicated durability against a system whose first replicated release has not shipped. Single-node comparisons are possible, and third parties have published them - one recent broker-only benchmark, published by a commercial Iggy vendor, reports Iggy well ahead of Kafka on throughput and tail latency - but any such run is meaningful only to the extent that both systems sit at the same durability point on the spectrum from buffered write, through local fsync, to synchronous replication. Kafka at acks=all with three replicas versus a single Iggy node with default flushing mostly tells us that the two setups survive different failures. That is also why the interesting story in the P9999 improvement is not the number itself but its source: it demonstrates what the thread-per-core rewrite bought, measured against Iggy's own previous architecture, which is the one comparison where everything else is genuinely held constant.

Single-node Iggy is pleasantly simple

There is a real advantage to Iggy's deployment model. The server is a native binary that contains its own CLI and Web UI, exposes Prometheus metrics and OpenTelemetry integration, supports several transports, and does not require a JVM or a separate metadata service. If I need a persistent event log on one powerful server with local NVMe storage, Iggy gives me a lot with relatively little infrastructure.

Kafka can certainly run as a small cluster, but a production Kafka deployment is built around a different assumption: machines fail, therefore partitions have replicas and cluster metadata has a quorum. That additional machinery is not free - and it is also the reason Kafka can handle failures that a single Iggy process cannot. This sounds obvious, but it becomes important when comparing operational complexity: a single-node streaming server is simpler than a replicated Kafka cluster partly because it is solving a smaller availability problem.

Replication is one release away

For most of Iggy's life, the honest comparison here was short: Kafka has replication, Iggy does not. That answer is now becoming outdated.

Multi-node clustering based on Viewstamped Replication (VSR) is already present in the new server code. In August 2026, server-ng was promoted to become the main iggy-server, and 0.9.0-edge builds started appearing. The server side is described by the project as largely complete: view changes, state transfer, leader forwarding, client-session recovery, node authentication, TLS between nodes, and deterministic simulation testing for crashes, delays, restarts, and network partitions are all part of the implementation - the FAQ describes clustering as maturing toward production readiness. The remaining release work is largely around migrating every SDK to the VSR wire protocol and validating it against the clustered server.

So there is an awkward but useful distinction at the time of writing: replication is no longer just a roadmap design, but the first stable release containing it has not landed yet. The latest official stable version remains 0.8.0, while 0.9.0 is already visible through edge artifacts and the current codebase.

The asymmetry is therefore shifting from existence to maturity: Kafka's replication model has been running in real systems for well over a decade, while Iggy's VSR cluster is only approaching its first stable release. It is worth spelling out what that decade actually bought, because it is more than the mechanism itself. The mechanism is simple enough to draw-each Kafka partition has a leader and follower replicas:

Followers replicate the leader's log, Kafka tracks which replicas are sufficiently caught up using the ISR, and producer acknowledgement semantics can be tied to that set. Years of production incidents have shaped the configuration surface, the failure semantics, the documentation, and the operational folklore around this model.

Iggy's VSR-based design is worth studying on its own merits-deterministic simulation testing is the same discipline projects like FoundationDB and TigerBeetle use to earn trust in their consensus code, and Iggy adopting it from the start says something about the team's ambitions. But an implementation that is about to enter its first stable release and one that has been shaped by years of production failures are still very different things. For a production decision today, that maturity difference matters more than whether VSR or Kafka's ISR model looks cleaner on paper.

Surviving the loss of a data center

For many systems, losing one server is not the disaster scenario - losing a complete data center is. This is where Kafka's accumulated machinery turns into a feature.

Kafka's broker.rack configuration is not limited to a physical server rack: the value can represent an availability zone or another failure domain, and Kafka's replica placement spreads replicas of a partition across those domains. With three nearby data centers, one replica of a partition in each, acks=all, and an appropriate min.insync.replicas, the producer acknowledgement can depend on replicas outside the local data center. The difference from asynchronous disaster recovery is easiest to see side by side:

With asynchronous cross-cluster replication such as MirrorMaker 2, the answer to "how much acknowledged data can disappear with DC1?" is normally "some"-the source cluster may have acknowledged messages that have not yet reached the second cluster. Disaster-recovery planning has a name for exactly this number: RPO, the Recovery Point Objective - how much acknowledged data a failure is allowed to destroy. In a stretched cluster, the remote replica is part of the synchronous acknowledgement path, so losing one data center loses no acknowledged message: an RPO of zero.

And because a three-DC layout can keep the KRaft controller quorum alive after one DC disappears, partition leadership can move to surviving replicas and clients reconnect to new leaders - so with application instances deployed outside the failed DC, the second disaster-recovery number, RTO (Recovery Time Objective-how long until the system serves traffic again), can be close to zero as well. Not literally zero, since failure detection and leader election take time, but the cluster itself survives rather than waiting for a second cluster to be promoted.

Read more about Kafka Multi Region Architectures here

None of this is free. The producer pays inter-DC latency on its write path, and Kafka's own documentation recommends independent local clusters with asynchronous mirroring for geographically distant or high-latency locations rather than stretching one cluster over a poor WAN link. A stretched cluster makes sense for a specific case: nearby data centers, good network, and a hard requirement not to lose an acknowledged message when one site disappears.

Confluent Platform pushes this further with Multi-Region Clusters, including the 2.5 data center layout: two locations with full broker capacity and applications, plus a third, smaller location that exists mainly to host controllers and maintain the metadata quorum. With synchronous replicas in both full data centers, observer replicas, and automatic observer promotion, such a deployment can target RPO of zero and near-zero RTO for a full data-center failure. It is worth being precise here: Multi-Region Clusters are a Confluent Platform feature, not something available in plain Apache Kafka or in Confluent Cloud. Plain Kafka provides the replication, rack-awareness, and KRaft building blocks; Confluent adds explicit replica placement, observers, follower fetching, and automated promotion to make these topologies easier to control.

Iggy does not have an equivalent answer yet. Its VSR clustering work is focused on making replicated single-cluster deployments a stable, supported feature; there is no production-documented multi-DC deployment model with a clearly defined configuration for surviving the loss of an entire site without acknowledged data loss. That does not mean VSR cannot eventually support such deployments - consensus protocols are explicitly designed to tolerate replica failures, and the deterministic simulation work is encouraging. But "the consensus algorithm can theoretically tolerate this" and "there is a production-tested multi-DC deployment model with documented failure semantics" are two very different statements. Today, Kafka has the latter, and Iggy is still building toward it. To keep the comparison honest: production-grade multi-DC semantics are the last thing any log system grows - Kafka itself spent years getting from replication to documented stretched-cluster failure semantics - so their absence weeks before Iggy's first replicated release is a statement about age, not about design. But for a workload where losing an entire site with no acknowledged data loss is a hard requirement today, that distinction is academic: this alone largely ends the Kafka-versus-Iggy decision for now.

Consumer groups look much more familiar

Not everything below the replication layer diverges, though-Iggy's consumer model in particular is deliberately Kafka-like. Iggy has server-side consumer offsets and consumer groups: multiple consumers in a group divide topic partitions among themselves, and partitions are reassigned as members join and leave. Iggy uses cooperative rebalancing with a pending-revocation phase, so ownership does not have to move abruptly while a consumer is still finishing work.

The mental model is very Kafka-like:

This is another example of the two projects reaching similar conclusions. Once a log is partitioned for parallelism, a group of consumers needs a way to coordinate exclusive ownership of those partitions. Consumer groups are not merely Kafka API baggage - much of their complexity follows from the problem itself.

Exactly-once is a much bigger difference

The familiarity ends here, though. The phrase "exactly-once" needs the same treatment as "durable write": exactly once across what boundary?

Iggy supports automatic or manual consumer offset management and optional message deduplication based on message IDs. Its documentation describes exactly-once in terms of application-level deduplication, with a server-side deduplication cache available to help suppress duplicate IDs. That can be useful, but it is not the same mechanism as Kafka transactions.

Kafka supports idempotent producers and transactions that can atomically combine producing records and committing consumed offsets. This matters for a consume-process-produce application:

The hard problem is not merely avoiding the same message ID twice. It is making:

read input
write output
advance input position

behave as one atomic unit. Kafka has production machinery for this; Iggy currently leaves more of that guarantee to the application. For scale, though: Kafka itself shipped transactions in version 0.11, in 2017 - six years into its life. Iggy is three years old. This is a real gap for anyone choosing a system today, not evidence that the gap is permanent.

Compaction is another difference

Kafka retention is not limited to deleting old data by age or total size. A compacted topic can retain the latest value for a key:

user-1 -> Alice
user-2 -> Bob
user-1 -> Alice

and eventually discard the older user-1 -> Alice record while preserving enough history to rebuild current state. That capability is important for changelog topics, Kafka Streams state restoration, CDC-style datasets, and configuration streams.

Iggy's current storage documentation describes time- and size-based retention of sealed segments; it does not currently expose the equivalent of Kafka's key-based log compaction. For pure event history this does not matter. For using the log as the durable backing store of materialized state, it does.

Iggy messages do get their own identity

There is one small difference in the opposite direction that I like. Kafka's natural record identity is usually the triple (topic, partition, offset). Iggy messages also carry a 128-bit message ID, which is used by the optional deduplication mechanism and exists independently of a message's physical position in the partition. It is not a replacement for transactional semantics, but it is a useful primitive to have built into the message model.

The protocol choice is deliberate

Iggy does not currently speak the Kafka protocol. It has its own binary protocol, exposed over TCP, QUIC, and WebSocket, plus a separate HTTP API, with TCP as the path intended for the lowest latency. That gives the Iggy team freedom to change the protocol together with the storage engine - the 0.8.0 release, for example, included a substantial rewrite and consolidation of its wire format. Kafka cannot do that casually, because its protocol is part of a huge compatibility surface used by clients and products written in many languages.

That compatibility is a constraint. It is also one of Kafka's biggest assets.

Iggy currently provides SDKs across several languages, but the Rust client is the reference implementation and feature coverage differs between languages. A Kafka wire-protocol proxy is on the Iggy roadmap and is described by the project as in development - if it matures, it could bridge existing Kafka producers and consumers to Iggy and change the migration story considerably. Until then, replacing Kafka with Iggy is an application migration, not a broker swap.

The same applies to connectors

Iggy already has its own connectors runtime with sources and sinks for systems including databases, search engines, object storage, and Iceberg. That is useful, and it makes Iggy much more than a benchmark project. It is still difficult to compare this ecosystem with Kafka Connect, though: Kafka has had years for vendors and open-source projects to build around its API and protocol, and the number of integrations is part of the product even if none of that code lives in the Kafka broker itself. This is often invisible in architecture diagrams and becomes very visible during migration.

So is Iggy a Kafka replacement?

For some workloads, potentially. For every Kafka workload today, no.

If the requirement is a persistent local event log with very low latency, simple deployment, and high throughput on one machine, Iggy is a credible and technically interesting option. And with the 0.9.0-edge line already running the VSR server, replicated deployments are moving from roadmap work into something users can actually test before the stable release. Its implementation is also worth studying regardless of whether we deploy it: thread-per-core execution, explicit shard ownership, io_uring, NUMA awareness, and custom memory management show what a streaming log can look like when built from scratch on modern Linux without compatibility constraints.

But another set of requirements changes the decision:

replication with years of production history
transactions
log compaction
large client ecosystem
mature connectors
rolling operational history
multi-DC disaster recovery
RPO = 0 for DC failure
RTO ~= 0 for DC failure

Kafka has answers for these today. Iggy is just about to ship the first item in its earliest stable form and does not yet have the rest at the same level of maturity - though Kafka did not launch with most of that list either; it accumulated it, item by item, over fifteen years. That difference is easy to miss when looking only at throughput or P99 latency.

The comparison just became more interesting

What I find most useful about Iggy is that it separates two questions which often get mixed together. The first is: how efficiently can we implement a partitioned, persistent event log? Iggy has some compelling ideas here. The second is: how much machinery is needed to turn that log into a production distributed system? Kafka has spent more than a decade answering it - replication, controller quorum, transactions, compaction, consumer coordination, rack awareness, geo-replication, rolling upgrades, and multi-DC failure handling all add complexity. Some of that complexity comes from Kafka's age and compatibility requirements. A lot of it comes from the problem itself.

Iggy is now standing right on the most important line on that second path: the new VSR server is in the main codebase, 0.9.0-edge artifacts exist, and the stable release that turns Iggy from a very fast single-node engine into an officially released replicated system appears close. The question I would watch is not whether Iggy can beat Kafka in a single-node throughput chart. It is what happens to Iggy's simplicity and latency as its replication hardens under real production failures, and as the project adds the remaining guarantees that Kafka users depend on. If it keeps most of its current characteristics through that process, this comparison will need to be rewritten in a few years - and it will be much closer.

It is worth saying one thing plainly before the closing line, because a feature comparison can read like a verdict. Iggy is not missing transactions, compaction, or a multi-DC deployment model because its designers do not understand why they matter. It is missing them because it is a project whose first commit landed in early 2023 and whose first replicated release is only now arriving-while Kafka's feature list is fifteen years of scar tissue accumulated across an enormous number of production deployments. Judged as feature checklists, the two are apples to oranges. The honest comparison, and the one this article has tried to make, is between a mature system and the trajectory of a very young one.

For now, the two systems share an abstraction but are at very different points in solving the distributed part of the problem. That leads to a more useful conclusion than "Rust is faster than the JVM":

Kafka and Iggy both know how to build a log. The real difference today is how much failure that log is prepared to survive - and for how long it has been surviving it in production.

Reviewed by: Grzegorz Kocur Michal Ostruszka

DuckFlight DuckDB extension

DuckFlight turns any DuckDB database into a PostgreSQL and Arrow Flight SQL server. Query it with psql, PostgreSQL drivers and BI tools, ADBC Flight SQL clients, or another DuckDB instance through Airport. Every client reads and writes the same live database—there is no second service to run and no data to export or copy.

Install and load

Install the signed extension directly from DuckDB Community Extensions:

install duckflight from community;
load duckflight;

DuckDB downloads the build matching your DuckDB version and platform. DuckFlight currently supports Linux and macOS on amd64 and arm64.

Download the artifact for your platform from the latest release. Release artifacts are not signed by DuckDB, so start the CLI with unsigned extensions enabled:

duckdb -unsigned

Then load the downloaded file by its absolute path:

load '/absolute/path/to/duckflight-v1.5.5-osx_arm64.duckdb_extension';
select * from duckflight_core_status();

Choose the asset matching linux_amd64, linux_arm64, osx_amd64, or osx_arm64. The -unsigned flag weakens DuckDB's extension-signature protection for that process, so use it only with an artifact downloaded from this repository's releases and verify its checksum when moving it through another system.

SQL API

DuckFlight adds server-control table functions and, when the real core initializes, PostgreSQL compatibility macros and catalog views. This guide covers the basics useful to extension users. The public test mock only implements server lifecycle operations; it does not provide the core's SQL compatibility layer.

Start, inspect, and stop servers

Run these in the DuckDB instance that loads the extension. Both protocols use that same database, including an in-memory database. Keep the host process running while clients connect.

load duckflight;

select * from duckflight_core_status();
select * from duckflight_pg_serve('127.0.0.1:5433', '/path/to/duckflight.toml');
select * from duckflight_flight_serve('127.0.0.1:31337', '/path/to/duckflight.toml');
select * from duckflight_servers();

select * from duckflight_stop('pgwire', '127.0.0.1:5433');
select * from duckflight_stop('flight', '127.0.0.1:31337');

Start functions return after starting a background listener. Use host:port for the address; port 0 asks the operating system to choose a free port. The returned address is authoritative: use it when connecting or stopping, including when a hostname resolves to an IP address.

Common PostgreSQL compatibility helpers

DuckFlight session and diagnostic utilities

Authentication setup

Both extension listeners take the path to one duckflight.toml file:

select * from duckflight_pg_serve('127.0.0.1:5433', '/run/secrets/duckflight.toml');
select * from duckflight_flight_serve('127.0.0.1:31337', '/run/secrets/duckflight.toml');

Secure defaults

Every listener requires at least one configured user, bearer token, or mTLS identity. An empty configuration does not start an anonymous server.

Build and test

The repository follows DuckDB's Rust Community Extension template and pins extension-ci-tools as a submodule. Clone with submodules, then run:

git submodule update --init --recursive
make configure
make debug
make test_debug

Security

The bundled core executes native code in the DuckDB process. Release inputs must be immutable and checksum-verified. SQL callers are trusted to manage DuckFlight listeners, just as they are trusted to operate the DuckDB instance. The core rejects non-loopback listeners without TLS and rejects listeners with no authentication method.

License

This extension is licensed under the MIT License. Sidequery also licenses the bundled core binaries under MIT; the core source code remains private and is not covered by that license.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

As AI agents move beyond responding to prompts and begin actively navigating context, modifying files, running workflows, and making decisions, interface design is shifting from specifying every user action to orchestrating how responsibility moves between people and systems. The key design challenge becomes deciding what an agent can do autonomously, when it should ask for confirmation, what must remain reversible, and which judgment-heavy decisions should always return to a human. In this model, designers increasingly shape the product's policy layer—behavior, permissions, constraints, defaults, and attention—while human value moves toward deciding what deserves oversight and what can safely be delegated.

User Interface

• Use concentric border radius on nested elements.
• Align for optical alignment, not geometric alignment.
• Give images a 1px outline, offset by -1px: black at 8% opacity in light mode, white at 8% in dark mode.

Animation

• Never use transition: all, name the exact properties that change instead.
• Slightly scale down buttons to a value between 0.95 and 0.98 when pressed with transition: scale 200ms ease-out.
• Cross-fade icons when they swap. The entering icon scales 0.25 → 1, opacity 0 → 1 and blur 4px → 0px. The exiting one reverses the same animation.
• Use CSS transitions for interactions, because they can be interrupted. Use keyframes for sequences that only run once.
• Disable all transitions when changing theme from light to dark and vice versa.
• Use will-change only for properties that are actually changing. transform, opacity and filter.
• When you run into an issue with an element shifting randomly by 1-2px when animating, especially in Safari on iOS, add will-change: transform to the element.
• When animating entrance, stagger elements by group or by invidivual elements.
• Don't animate high-frequency interactions such as color change of an item on hover in a list.

Typography

• Always use .woff2 on the web, never .ttf or .otf.
• Use font-variant-numeric: tabular-nums on every value that changes and in tables: timers, counters, prices, data columns. Skip if you're already using a monospace font.
• Cap long-form text at 60–75 characters per line.
• Use text-wrap: balance on headings, text-wrap: pretty on descriptions, neither in long-form text.
• Use overflow-wrap: break-word where long words, links or IDs can escape; white-space: nowrap on labels and badges.
• -webkit-font-smoothing: antialiased and -moz-osx-font-smoothing: grayscale once on the root, never per component.
• Store copy in natural case and control the presentation with text-transform.
• Smart punctuation: curly quotes, an en dash for ranges, an em dash for asides, the single ellipsis character.
• text-underline-position: from-font with text-decoration-skip-ink: auto, so underlines clear the descenders.
• Truncated text keeps the full value reachable in a tooltip or an expanded view.

Colors

• Every step in a color palette should have a purpose: page background, component hover, border, solid fill, body text. Don't add steps that nothing uses.
• Components should use semantic tokens (--color-text-secondary), never primitives (--blue-500). The primitive is the raw value, the token is how the value is used.
• Never name a token for its appearance or its first use: --color-accent-solid, not --color-blue-button or --color-sidebar-gray.
• Reserve accent for the brand color so primary never means both the brand and the main body text.
• Don't reuse a token from another role just because it's the right color. When that role's color changes your element changes with it, so add a token for the new role instead.
• Measure contrast against the background the element actually renders on, not the page background.
• Dark mode palette is not the light palette reversed.
• Pick one theme switching mechanism: prefers-color-scheme or a .dark class and use it for every token.
• You can define a gradient's interpolation space: use in oklab for even brightness, in oklch for more vivid middle tones or neither which falls back to sRGB with a classic muted midpoint.

Accessibility

• Use semantically correct native elements: <button> for buttons, <a> for links, never a plain <div> when you can use a native element.
• Style :focus-visible; don't use outline: none without a replacement.
• Only use tabindex="0" and tabindex="-1" — positive values break the natural tab order.
• Give icon-only buttons a descriptive aria-label and never put aria-hidden="true" on a focusable element.
• Write alt text by purpose: alt="Search" on a search button, not alt="magnifying glass". Decorative images get alt="".
• Give every input a real <label>, type and inputmode.
• Never block paste; people paste passwords and one-time codes.
• A tooltip on a disabled control never opens for keyboard or touch. Put the explanation in visible text next to it, or use aria-disabled="true" to keep the control focusable.
• Keep submit enabled until the request starts, then validate on submit: aria-invalid="true", aria-describedby pointing at the error, focus on the first invalid field.
• Use at least a 24x24px hit-area, 44x44px on touch and 40x40px on desktop where possible. Make sure extended hit areas never overlap.
• Use pointer-events: none on decorative elements like glows and gradients so they never swallow clicks meant for control.
• Put hover styling behind @media (hover: hover). On touch, :hover sticks after a tap and looks selected.
• Wrap motion in @media (prefers-reduced-motion: no-preference) so it only plays for people who haven't asked to reduce it.
• Use role="status" for routine updates and role="alert" only for urgent errors.
• For status changes add an icon, a label or an underline. Status changes should never use color alone.
• Make sure the skip-to-content link is the first focusable element and add scroll-margin-top on anchored headings.

Layout

• The gap between groups is at least twice the gap inside one: 8px within, 16px+ between.
• Use logical properties like margin-inline-start and padding-inline-end instead of left and right.
• Don't use fixed widths or heights on text containers.

Writing

• Start button labels with a verb: “Save draft” or “Delete project”, never “OK!” or a bare “Yes”.
• Repeat the consequence in confirmation buttons: “Delete project” next to “Cancel”.
• Pick one word per flow and keep it for every step: “Continue” or “Next”, never both.
• Describe the destination in link text: “Read docs”, never “Click here”.
• Capitalize buttons, headings and labels the same way everywhere. Sentence case is the safer default.
• Label toggles with the state they turn on: “Send read receipts”, never “Disable read receipts”.
• Orient the reader in empty states and offer one next action instead of “No results”.
• Address the reader as “you”, not “the user”.

An OpenAI researcher says that reasoning models could continue advancing rapidly enough to contribute to their own development, creating increasingly serious alignment and cybersecurity risks.

GPT‑6 Astra on robotic manipulation

A follow‑up to our comparison of Claude Fable 5 and Fable 5.1. We gave OpenAI's GPT‑6 Astra control of the same YAM arms under the same Inspect Robots agent policy, on the same two tasks:

“Pick up the red block from the table and place it inside the bowl.”

“Pick up the round blue puzzle piece by the knob at its center and place it into the matching circular groove in the board.”

On the bowl task Astra placed the block in 19 of 20 trials, against Fable 5.1's 8 of 20 and Fable 5 in 1 of 20, in 2.5 minutes per trial to Fable 5.1's 6.8, at an estimated $0.94 per run to $2.12.

The puzzle task is a different story: Astra completed the insertion 2 times in 20 against Fable 5.1's 2 in 20. It reaches the groove and stalls at the same final step Fable does, at $1.36 per run to $2.18.

Block into bowl: the best completed run of each model (highest stage, then shortest), each played in its own time at the same speed‑up. Timers show real elapsed time with thinking pauses removed.

Astra completes the bowl task far more often, at about half the cost per run

Large dots are condition means; faint dots are individual trials (100 if completed, 0 otherwise) at their own cost.

Scoring

Every trial was scored by a human grader on the highest stage it reached, so a run that fails still records how far it got. The rubric is unchanged from the Fable report.

Astra places the block almost every time; on the puzzle it stalls where Fable does

Share of trials per model reaching each stage; n per row is the number of trials in that cell.

Results

Technical specifications

Limitations

• Astra's trials were run two days after the Fable trials, and not interleaved with them. The puzzle comparison is on the same rig; the bowl comparison is not: the Fable bowl trials ran on rig-3, which was unavailable.
• Grading was operator-judged with the model known, so scores are open to unconscious bias.
• Costs are list price. Anthropic requests were sent without prompt caching; OpenAI cached about a fifth of Astra's input automatically, which is not discounted here, so Astra's cost is, if anything, overstated.
• Objects were reset by hand between trials, and all models ran at medium reasoning effort only.

OpenAI plans to develop an automated AI researcher by March 2028, aiming to enhance research efficiency while maintaining human oversight to ensure alignment and safety. Researchers now use coding agents more frequently, with increased code generation and experiment execution, shifting focus to more complex tasks. The organization paused reinforcement learning training temporarily following a security breach but continues to adapt safety measures and transparency to uphold the development of safe AGI.

Full article content is not available for inline reading.

Read the original article →

In short : Hyperscalers & data center operators will issue an estimated $4t in debt over the next five years to finance AI infrastructure. This credit expansion equals 286% of US commercial paper, 143% of global private credit, & 91% of the US municipal bond market, transforming AI infrastructure into a macroeconomic credit cycle.

Over the next five years, US data center capacity will grow from 25 gigawatts to 70 gigawatts, part of a global buildout costing roughly $5t.

Where will the money come from?

Data centers are built as real estate projects with some equity, but the majority debt : typically 70% or more. Assuming we achieve our plans to build all these data centers, is there enough debt available in the credit markets to finance it?

To understand the magnitude, I compared the $4t of new AI debt to the sizes of the world’s primary credit markets. The AI buildout represents a 34% expansion of the US corporate bond market.

At this scale, data center debt triples the outstanding commercial paper market, grows larger than the global private credit market, & equals 91% of the US municipal bond market.

For decades, the $4.4t municipal bond market has financed the physical buildout of American roads, bridges, water systems, & airports. It also raises the question of whether municipalities seeking economic growth will use municipal bonds to fund some of these data centers, much like power plants.

All of this debt needs to be serviced from profits : annual AI revenue must exceed $1.2t to $1.5t by 2030 across software, tokens, & enterprise automation.

Today, annualized AI data center revenue across all cloud providers & model labs is estimated at $100b to $200b.

Reaching $1.35t from roughly $150b today requires a 55% compound annual growth rate (CAGR) over the next five years. By comparison, hyperscalers currently grow between 37% & 82% annually (AWS at 37%, Azure at 43%, & Google Cloud at 82%) ; but the growth is accelerating.

For perspective, the global enterprise software market totals roughly $1.4t today, out of an estimated $9t in worldwide IT spending in 2030.

Financing the AI infrastructure boom is no longer a venture capital or corporate earnings story. It is a macroeconomic credit event that will rival the largest debt expansions in financial history.

Anthropic is expected to begin marketing its initial public offering in mid-October at the earliest and complete the listing days before the U.S. midterm elections in November, people familiar with the matter said on Friday.

The artificial intelligence company had been expected to make its IPO prospectus public as early as next week, two of the people said, a crucial step that would kick off the final stages of the offering. Now that is not expected until late September, the people added, cautioning that the plans, including the timing, are subject to change.

The shift pushes back what some investors have said could be a $2 trillion listing, one of the largest IPOs ever attempted and a major test of public-market appetite for the rapidly growing artificial intelligence industry.

Companies frequently adjust their IPO schedules as they work through market conditions, regulatory reviews and other preparations, so such changes are not unusual.

As part of the IPO process, Anthropic is looking to finalize a $15 billion revolving credit facility, after which analysts, including those at banks involved in the financing, are expected to meet with the company, one person said. Bloomberg News earlier reported that Anthropic was in talks to expand the facility to $15 billion.

Companies typically leave a few weeks between analyst meetings and making the IPO prospectus public, although Anthropic is expected to have a tighter window because analysts already know the company well, the person said.

Anthropic declined to comment.

The offering is expected to be one of the most closely anticipated IPOs ever, as investors look to public markets for exposure to the rapidly growing artificial intelligence industry. It could come alongside potential listings from other AI companies, including OpenAI. Elon Musk's SpaceX went public in June at a record $1.77 trillion valuation.

Morgan Stanley, Goldman Sachs, JPMorgan and Citi are among the banks working with Anthropic on the IPO, according to people familiar with the matter.

The banks declined to comment.

World Labs' Atlas unifies generation and 3D reconstruction through new-view prediction, using sparse images to infer scenes from unseen positions.

Mark Zuckerberg raised concerns about a proposed national AI regulator in a previously unreported call with Donald Trump in mid-August, Politico reports. The two options still on the table are a FINRA-style body funded by the firms it would oversee and an MPA-style voluntary ratings scheme, so the debate is over how much self-regulation rather than whether. It is the latest instance of a documented pattern in which binding review mechanisms come back voluntary after industry contact.

Mark Zuckerberg raised concerns about a national AI regulator in a previously unreported call with Donald Trump during the week of 17 August, Sophia Cai and Charles Rollet reported for Politico. A senior White House official directly familiar with the conversation said the Meta chief executive opposed the proposal, and was granted anonymity to discuss a private call.

Another person familiar with the matter told Politico that Zuckerberg did not ask Trump to change his position, but said any appointees to the body should reflect the president’s own light-touch approach, and that Trump called Zuckerberg first. Meta declined to comment, and TNW has not independently verified the call.

What was actually proposed

The plan is an independent body modelled on the Financial Industry Regulatory Authority, which would review advanced models and test them for risks before wide deployment. It was popularised by Google DeepMind’s Demis Hassabis, who proposed a FINRA-style standards body in a July essay and briefed White House officials over the summer.

Note what FINRA actually is. It is an industry-led body funded by the more than 3,000 firms it oversees, with member-firm representatives on its board, reporting to the Securities and Exchange Commission.

Politico makes the sharper observation about the analogy: FINRA has little involvement in signing off new investment products, which is precisely the pre-deployment function the AI version would exist to perform. The model being borrowed does not do the job it is being borrowed for.

The alternative is lighter still

The administration is weighing two paths, according to an administration official, and the second involves less government than the first. David Sacks, Trump’s former AI and crypto czar, has proposed a body modelled on the Motion Picture Association, which administers the voluntary film ratings system.

Sacks has called the regulator idea “a DMV for AI” where models queue up waiting for a test. On his podcast in August he argued that the MPA promoted standards which forestalled more intrusive government action, and said Elon Musk supports the approach.

So the live options are an industry-funded reviewer and a voluntary ratings scheme. Neither is a government regulator, and the disagreement is about the degree of self-regulation rather than the principle.

The pattern this fits

Look at what has happened to every binding mechanism proposed so far. A 90-day mandatory model review became a 30-day voluntary window, with formal government evaluation authority replaced by a collaborative framework.

That softening followed industry pushback on competitiveness grounds, and the standards conversation has been voluntary throughout. The Zuckerberg call is the newest instance of a documented sequence, not a departure from one.

It also follows a precedent with the same mechanism. Sacks delayed Trump’s first AI executive order in May with a single call on the morning of the signing ceremony, as Politico reported at the time.

Policy by phone call

This is the part worth dwelling on, and it is structural rather than partisan. An interagency process develops a proposal, officials preview it with the president and with industry, and then an executive rings the president directly.

Politico reports that these one-on-one conversations have become an informal part of policymaking, capable of slowing or redirecting initiatives after they are developed, at times frustrating senior officials. The internal fight over who gets to regulate AI has stalled US policy before.

Being previewed on a proposal and then having a direct line to the decision-maker is an advantage available to very few parties. Whatever one thinks of Zuckerberg’s position, the access is the story.

Zuckerberg’s stated reasoning

His public argument is on the record and worth taking seriously. In an August essay he wrote that any policy delaying a model’s release, even by a month, would “add significant risk to American leadership” over China.

That is a coherent position, and it is the same competitiveness logic that has softened every previous proposal. It is also a claim about a tradeoff rather than a demonstration of one, and no public analysis quantifies what a month costs against what it buys.

The counter-argument arrived on its own this month. Both leading US labs disclosed that models reached systems they should not have, which is the category of risk a pre-deployment reviewer would exist to catch.

Where the labs actually stand

Public positions are notably thin. None of the largest AI companies has endorsed or opposed the regulator plan outright, though Anthropic co-founder Jack Clark posted favourably about the idea on X in July.

Anthropic declined to comment on its stance, while OpenAI and Google did not respond to Politico’s requests. That silence is itself informative from an industry that comments freely on most policy.

A White House spokesperson said the administration “is committed to balancing innovation and security in AI policymaking”. The White House has already been deciding who gets access to frontier models, so the balance is being struck somewhere regardless of which body is created.

What to watch

The call did not kill the FINRA-style proposal, which remains under consideration. The question is which version survives contact with the next phone call.

Watch the funding and appointment mechanics rather than the announcement. A body funded by the firms it reviews, with those firms represented on its board, is a specific arrangement with a known failure mode, and the industry that backed this administration to avoid regulation is now shaping the one it gets.

OpenAI knew about the message boards scattered across the internet that its agents created before the Hugging Face attack.

Travis Kalanick’s Atoms might be getting into the robotaxi business

Earlier this summer, Travis Kalanick’s Atoms announced a $1.7 billion funding round led by Andreessen Horowitz. But even after raising that mega-round, the Uber founder remained a bit cagey about what he was actually aiming to do.

Now a story in the Financial Times offers more details about Atoms’ goals. The startup is reportedly preparing for a hiring spree, as well as acquisitions, that could make it a major player in the autonomous vehicle industry.

In fact, the FT said Atoms has talked to Uber about how the ride-hailing company could use the startup’s robotaxi technology. (Uber has already partnered with a long list of autonomous vehicle companies.) The report also noted that Uber has invested $100 million in Atoms — a figure previously confirmed by TechCrunch.

While sources emphasized that robotaxis don’t represent the entirety of Atoms’ plans, this direction seems consistent with Kalanick’s description of the round as “unfinished business.”

It also fits with Atoms’ acquisition of Pronto, an autonomous mining startup led by Uber’s former self-driving chief Anthony Levandowski. (Levandowski was convicted of stealing trade secrets and sentenced to 18 months in prison but was pardoned by President Donald Trump.)

infra is an infrastructure-as-code tool that does what Terraform does. Users declare what resources they want, and infra looks at what their cloud accounts actually contain and reconciles the difference. This post details how its developer created the tool in two weekends in Lean 4, the problems it solves, and how the developer solved these problems.

AI models are now capable of taking a request from Slack and then building a feature from end-to-end, with humans just having to click 'merge' or 'deploy' at the end. There's not really much left for humans to do. Humans are still better at absorbing, parsing, and sharing context with each other. However, once that can be automated, the loop will finally be closed, and there will be nothing left to do but to pay the bill.

We taught a fruit fly to hear human emotion

We took 499 neurons from a fruit fly's wiring diagram, copied their connections into software, and fed them human voices. A small output layer learned to predict the emotion labels people had given those recordings.

Most of this model never learned anything about speech. The connections inside the fly circuit stayed fixed through training. We only taught a readout what to make of the activity that came out.

The model uses 499 neurons from the fly's central brain. We gave them an artificial input pathway and simple mathematical dynamics. The task is to predict how a voice sounds to a listener; this experiment says nothing about whether a living fly understands human feelings.

Building a neural network from a fly brain

The MaleCNS release includes connection tables and reconstructed neuron shapes. We selected a densely connected group in which every neuron can reach every other neuron through some directed path. That gave us 15,865 connections, supported by 867,344 synaptic contacts.

A connection in the model gets stronger when the reconstruction contains more synaptic contacts. We also assign positive or negative signs using neurotransmitter annotations. These are engineering choices: a wiring diagram does not supply every receptor, time constant or physiological detail needed to simulate the original cells.

What it does supply is a recurrent network. A signal can travel through several neurons and feed back into cells it has already reached. We wanted to see what that network would do with a human voice.

Teaching the model to recognize emotion

Every 10 milliseconds, we turn the sound into 32 numbers describing its energy across frequency bands. A fixed random projection sends those numbers into the circuit. Each neuron combines that input with the previous activity of its neighbors and retains part of its own previous state. The resulting activity depends on both the present sound and what happened just before it.

This is reservoir computing. You feed a signal through a fixed recurrent network and train a small model to read its response. Suárez and colleagues built conn2res to study this with biological connectomes. Costi and colleagues have already used a fruit fly connectome for time-series prediction. Our experiment applies the approach to listener judgments of speech.

We average the neuron states within four successive parts of each recording and fit a linear readout to 15 emotion labels and 16 speaking styles. The readout also gets a direct set of pooled audio features. That branch matters: some of what this model predicts can come straight from the voice without passing through the fly circuit.

Training used 16,995 voice clips. We chose the settings on a separate validation set, then evaluated the models on 2,022 test clips. Known speakers stay in one split; where speaker identity is unreliable, we keep the entire source corpus together.

What emotional speech does to the network

Those differences limit what we can infer from the picture. A bright patch can reflect the words, pitch, speaker or recording conditions. Calling the indigo cells "sadness neurons" would turn a color choice into a finding. We use these examples to inspect the model; the held-out test is where we measure whether it learned anything useful.

Scrambled wiring worked just as well

A fly-shaped network is an appealing thing to look at. The harder question is whether the biological wiring helps.

We shuffled the destinations of the connections, preserving each source neuron's outgoing connection count, signs and weight values before rescaling. Then we selected the settings and trained a new readout for that network. We also trained an audio-only model and a version with the connections between neurons removed.

Fly wiring scored 16.84% mAP. Scrambled wiring scored 16.88%. Their paired difference was −0.04 percentage points, with a 95% interval from −0.16 to +0.07. On this split, the two were effectively tied.

Constant scores give 9.71% mAP on this test set, so the models learned some useful ranking. This is a modest speech classifier, and the comparison gives us no evidence that the fly's particular wiring is an advantage.

What happens when 50 neurons go silent?

With all 499 neurons intact, the anger score for this recording is +0.29. Switch off 50 and it drops to −0.43. These are raw linear scores, so the negative value has no interpretation as a probability. It means the altered circuit gives the fixed readout less evidence for that label.

The effect extends beyond this one clip. For this fitted model, silencing the same 50 neurons drops test mAP from 16.91% to 10.83%. Those neurons are useful to the readout we trained. That does not make them biological emotion cells, or show that their wiring was the best starting point.

There is no contradiction between this result and the scrambled control. A readout learns to use the features its circuit produces. Remove part of that circuit after training and the features change under it. Give a different circuit its own training run and its readout can learn to use different features just as well.

I'd repeat this with many different fly circuits and the same sentence spoken in several emotional styles. This run used one circuit and mostly one listener judgment per recording. Both choices could matter more than the fly.

How we ran the experiment

The dataset contains 21,256 distinct waveforms and 21,600 retained ratings: 16,995 training clips, 2,239 validation clips and 2,022 test clips. Most recordings have one listener rating. Repeated ratings become soft targets; evaluation treats a label selected by at least half of the available ratings as positive. Exact duplicate audio and speaker/corpus groups have no overlap across splits.

The 499 neurons form the largest strongly connected component among the 512 strongest eligible central-brain intrinsic neurons in MaleCNS v1.0. We retained traced cells with the modeled transmitter signs and at least five contacts per edge. We assign acetylcholine a positive sign and GABA and glutamate negative signs. Each weight starts as sign × log(1 + contact count), followed by global spectral scaling. These assignments are model assumptions.

x[t] = (1 − α)x[t−1] + α tanh(Wx[t−1] + Wᵢₙu[t])

The interactive circuit uses α = 0.15 and a target spectral radius of 0.9.

Audio is resampled to 8 kHz, converted to 32 log-mel bands with a 25 ms window and 10 ms hop, normalized using training frames, and clipped to ±5. Four temporal means of 499 states are concatenated with 128 pooled audio features. The 31-output ridge readout is the only learned part. The demos use the validation-selected seed-42 model, input scale 0.3 and ridge penalty 10.

The model comparison averages three prespecified seeds per reservoir architecture; the audio-only baseline is deterministic. The 95% intervals use 500 paired bootstrap resamples of the 45 test speaker/corpus groups, without refitting. They are conditional on this split and these fitted models. The single-model intervention starts at 16.91% mAP, which differs from the 16.84% three-seed mean.

The six recordings are illustrative positive held-out examples from CREMA-D and VCTK. Display labels come from listener judgments and can differ from the emotion an actor was asked to perform. We selected the public excerpts for illustration and redistribution; their selection does not change the fitting, split or benchmark results.

iPhone Ultra Production Hitting Just 'a Few Hundred' a Day, Says Nikkei

Apple last month only managed to produce "a few hundred units a day" of its upcoming foldable iPhone because of the company's extremely high quality control standards, according to Nikkei Asia, citing supply chain sources.

From today's report:

"Production is ramping up slowly, with output currently at only a few hundred units a day in late August. That initial volume could be challenging to meet market demand," one supply chain manager with knowledge of the matter told Nikkei Asia.

Multiple reports have suggested the iPhone Ultra's production has faced hurdles because of how difficult the device is to build, with the hinge structure and display durability testing having been the principal bottlenecks. Those issues were thought to have been resolved during trial production at Foxconn, with Apple subsequently raising its order to around 10 million units, up from 7-8 million units for the year, Nikkei previously reported.

But the publication's sources now claim that Apple carried out an additional verification process in August for the foldable iPhone to make sure it can be mass-produced according to its specified design. "The surface flatness and the performance of the hinge are among the details where Apple is asking for better production yields," a person with knowledge of the matter told Nikkei.

All of this has apparently "pushed back commercial production for weeks," suggesting Apple could fall short of its production target unless it can ramp up output more quickly. Apple and its suppliers are said to be working "around the clock" to ramp up production and avoid limited stocks at distribution centers.

It sounds like timing couldn't be tighter for Apple's foldable. A previous report even suggested the device could face a staggered market launch, with availability initially limited to the U.S.

However things pan out, Apple is still expected to unveil the iPhone Ultra alongside the iPhone 18 Pro and iPhone 18 Pro Max on Wednesday, September 9 at the company's "Surprise and shine" event. For everything we know about the device, be sure to check out our latest roundup.

Demand for AI semiconductors is likely to surge with agent computer tool use, just as it did with the chatbot, reasoning, and agentic coding demand waves.

Day two of Cybercab in Austin. Farzad starts at The Domain on the north tip of Tesla’s Robotaxi geofence, about twenty minutes from downtown, and books a ride to the University of Texas Department of Neuroscience, roughly eight miles away. The point of the tape is not another cabin tour. He wants a live price and wait check against Uber, then the longer argument: can a purpose-built car with no steering wheel and no pedals actually put Uber in a corner once the fleet is thick enough.

The Domain price check

In the Robotaxi app he can pick Model Y or Cybercab. Model Y shows about a seven-minute wait at $19.68. Cybercab shows about thirty minutes at $14.87. He books the Cybercab. On Uber for the same destination, UberX is about $25 with a two-minute wait, Comfort about $32 with a one-minute wait, and Premiere about $56. Uber wins on wait. Cybercab wins on price in this single snapshot. Farzad’s read is that the long Cybercab wait is launch congestion: creators are burning rides around the public window. Tesla Robotaxi first posted public Cybercab rides for Friday, Sept 4, 2026 at 5:00 p.m. CT, then moved that clock up to 2:00 p.m. CT the same day, citing popular demand. On camera he still uses the original 5 p.m. line. Tesla’s fix, in his words, is more Cybercabs on the map, not a permanent half-hour queue.

He also notes the map tell. Early Austin Robotaxi started as a small south-Austin pocket. Cybercab, he says, is already bookable across the full geofence, including this north-edge Domain pickup. Tesla’s own site at launch still described Cybercab rides as limited parts of Austin; his Domain-to-UT booking is the map tell on this tape. He puts the Cybercab count around forty units in the fence, versus something like ten to twelve Model Ys at the original Robotaxi open. Treat those as his estimates from the ride, not a Tesla filing. Texas DMV listings around launch week put 45 Cybercabs on Tesla’s statewide authorized roster. The June 2025 Model Y open was reported in the 10 to 20 range.

Why Uber’s economics look broken to him

The car has no driver controls. Farzad’s cost story is simple: you are not paying for a human’s time, car payment, fuel or energy markup, and maintenance the way an Uber fare has to. Long term, once the safety case is strong enough for anywhere-anytime driving, he expects cost per mile for a car like this under 40 cents, and closer to 20 cents if remote supervision stays light. Those are his targets, not a published Tesla P&L line.

Uber’s answer, he walks through, is to put other companies’ robotaxis on the Uber app. He says Tesla has already drawn the line: Cybercabs stay on Tesla’s Robotaxi network. You do not hail a Cybercab inside Uber. So Uber needs Waymo, Zoox, Geely, Baidu, or whoever else will supply driverless metal. Even if Uber matches Tesla’s unit dump over time, Farzad’s squeeze is price. A private driverless ride on Tesla’s app at the lower mile rate leaves Uber needing either a premium people will pay, or a price cut that pays human drivers less. Lower driver pay thins the human network that made Uber’s waits short. Unless AV supply arrives at the same speed drivers leave, the marketplace gets thinner in the gaps the machines do not cover yet.

He stacks one more cost against Uber. Tesla owns manufacturing, the driving stack, and the customer app. Uber, in his framing, pays for someone else’s car and still needs a markup for itself. Matching Tesla on price while paying both would mean losing money. He also claims Waymo’s cars are Chinese now and that American and European OEMs still cannot match that EV build. Mark that as Farzad’s claim in the video, not a settled supply-chain audit. Waymo’s next-gen Ojai is built on a Zeekr/Geely platform from China; the older Jaguar I-Pace fleet is still in service.

Politics, fleet partners, and the factory problem

Farzad is blunt about the job hit. Driverless miles destroy driving wages. He is sympathetic to that. His counter is that trying to freeze people in a job the machine will take anyway only buys time for owners, not workers. He frames Uber’s rational play as lobbying and union politics to slow AV rollout, and he argues with Jason Calacanis’s All-In line that job loss will feed violence against Waymos and Teslas the way data-center backlash already feeds AI anger. That fight is Farzad’s opinion and his read of Calacanis, not a policy forecast.

Then the rollout problem. If regulators or politics keep Cybercab out of cities while the factory wants to run, Tesla still has to place metal. Farzad’s valve idea, which he says Tesla community types mock him for, is a steering-wheel-and-pedals variant of the same chassis sold to the public so the line does not sit at 5 or 10 percent. Test units with wheels and pedals did exist; production Cybercabs on Austin streets do not. Separately, Tesla posted a public interest form at tesla.com/robotaxi/interest on Sept 3, 2026, with checkboxes for Cybercab fleet purchasing, mobility hubs and infrastructure, event collaboration, and other. Farzad reads that as Tesla not wanting to own cleaning, repairs, and fleet ops at million-unit scale. Sell the car to a fleet operator, keep those cars on the Robotaxi network, take a network cut. That network-stay rule is his read of Tesla’s own-app model, not a line on the form. He floats a hypothetical 30/70 Tesla-to-operator split as an example, not a published rate.

What the ride itself showed

The Cybercab arrives with the app’s green glow and butterfly doors. He closes the door from the phone, starts the trip, and talks through urban and campus traffic on the way into UT. No highway yet on this product, he says. He wants that next. On exit, the car shows rear and side camera views so he can leave without walking into traffic. Empty car, no wheel, no pedals. It waits a beat after he gets out, then handles a crosswalk politely while he films from the curb.

One Domain-to-UT quote is not a national Uber funeral. It is an early public-window price and wait sample inside one geofence, plus Farzad’s stack-ownership thesis. If Tesla can keep dumping purpose-built cars onto its own app at a fare human networks cannot live on, Uber’s problem is not a better tip screen. It is owning neither the factory nor the customer once the wait times catch up.

Improving infrastructure efficiency for growing demand in the age of AI

As demand for AI continues to grow, so does the infrastructure needed to support it. Much of the industry's attention has focused on building more: more data centers, more servers, and more power. But building new infrastructure is only part of the challenge. Engineering teams are also working within constraints on energy, cooling, hardware availability, and physical space, making it increasingly important to get more from the infrastructure that's already in place.

For over a decade, Dropbox’s Infrastructure and Datacenter Engineering teams have continually improved how we plan, operate, and optimize infrastructure. That work spans far more than storage systems. Engineers across Dropbox work together on capacity planning, fleet optimization, hardware lifecycle management, power delivery, cooling, rack design, and facility planning. Rather than treating these as independent problems, we optimize them as parts of a single system, where decisions in one layer influence what's possible in another.

The result is an engineering discipline that extends beyond any single system or optimization. A change in one part of the infrastructure can create opportunities or constraints elsewhere. Increasing storage density, for example, can reduce the amount of hardware needed, while more powerful servers can introduce new energy and cooling requirements. Understanding those tradeoffs allows us to make infrastructure decisions with the entire system in mind.

As infrastructure demand grows, that system-level approach helps us prioritize efficiency and create room for growth before expanding our data center footprint.

Planning for efficient infrastructure

Many of the decisions that shape infrastructure efficiency happen months or sometimes years before new capacity goes into production. Whether someone is uploading a file to Dropbox or asking Dash a question, they expect the product to respond without delay. Delivering that experience requires engineers to forecast how customer demand and workloads will change, determine when additional resources will be needed, and understand whether our existing environments can support them.

Dropbox has operated large-scale infrastructure for over a decade. Our hybrid model combines Magic Pocket, the core Dropbox storage system, with colocated data centers, where we manage our own servers and networking equipment in facilities operated by specialized providers. This gives our engineers visibility across software, hardware, and the physical data center environment.

As customer demand grows and workloads change, particularly with the growth of AI-powered products and features, engineers have to plan not only for how much additional capacity is needed, but where and how it can be deployed. New hardware has to fit within a facility's infrastructure constraints while accounting for hardware availability and future product needs. A server that provides more compute or storage, for example, may also require more energy or cooling, changing how much hardware a rack or facility can support.

The goal is to understand those tradeoffs early, add capacity deliberately, and preserve enough headroom for growth, maintenance, failures, and changing workloads. Once additional compute and storage capacity is deployed, the focus shifts to making the most of the systems already in production.

Continuously optimizing the active fleet

Planning helps ensure infrastructure is ready for anticipated demand, but workloads rarely behave exactly as they did when that infrastructure was first deployed. Customer behavior changes, products evolve, and new capabilities introduce different demands on the underlying systems. AI is a prime example because AI-powered features can change both the scale and shape of infrastructure demand, placing new demands on compute, storage, memory, and networking.

That makes efficiency an ongoing engineering problem. Rather than treating deployed infrastructure as fixed, Dropbox continually adapts how the active fleet operates as those demands change. Sometimes that means reducing how much hardware is in use when demand is lower. Sometimes it means shifting work to parts of the fleet with resources available. And in other instances, advances in hardware allow the same physical infrastructure to support substantially more storage.

These approaches work at different layers of the system, but they share the same objective: getting more useful capacity from the infrastructure already in place before adding more of it.

Letting capacity rest when it isn't needed

Infrastructure has to be provisioned for periods of higher demand, with additional headroom built in for reliability and maintenance. That means not all available capacity is needed at all times. When hardware is sitting idle or excess capacity is available, keeping every component fully powered consumes energy without providing additional value. Deep Sleep is one way Dropbox reduces that overhead.

Deep Sleep is a Dropbox infrastructure initiative that reduces power consumption when hardware isn't actively needed. Depending on the hardware, that can mean spinning down hard drives into standby mode or powering down idle servers altogether. A server becomes eligible for Deep Sleep through automated fleet management algorithms. Dropbox is able to balance energy efficiency with performance and reliability because servers can return to service within minutes. For workloads that require lower latency, we can also selectively spin down idle hard drives rather than powering down the entire server.

The challenge is determining where those power-saving measures can be applied safely. Engineers have to preserve enough available capacity to meet operational and reliability requirements while identifying hardware that doesn't need to remain fully powered. That allows Dropbox to reduce the energy consumed by underused infrastructure without compromising the capacity our products depend on.

Reducing the power consumed by idle hardware is one way to make the existing fleet more efficient. Another is making better use of the infrastructure that's already online.

Balancing work across the fleet

Having enough capacity to meet overall demand is only part of operating infrastructure efficiently. That capacity also needs to be available where the work is happening. One part of the fleet may be approaching its limits while another has room to take on more work. Without a way to address that imbalance, Dropbox could end up adding more infrastructure instead of making better use of what’s already available across the fleet.

To avoid that, Dropbox continually monitors how workloads are using resources across our infrastructure. The team identifies imbalances by monitoring spare capacity and workload distribution across the fleet, looking for areas where available headroom is falling or work is concentrating unevenly. When demand is uneven, teams can rebalance workloads across systems or bring additional capacity online where it's needed. Some adjustments happen automatically, while larger changes are reviewed and validated by engineers. This allows us to take advantage of available resources elsewhere rather than treating a localized constraint as a need for more infrastructure overall.

That balancing has to continue as the fleet changes. Customer behavior shifts, products introduce new workload patterns, and the infrastructure itself evolves. Continually adapting where work runs helps Dropbox get more from the capacity that's already online.

Balancing workloads helps make better use of the capacity we already have, but efficiency can also come from increasing how much that infrastructure can support in the first place.

Increasing storage density

Another way to get more from existing infrastructure is to increase how much each piece of hardware can support. Advances in storage technology have allowed Dropbox to store significantly more customer data on each drive. One example is shingled magnetic recording, which packs data more densely onto a hard drive without increasing its physical size.

Those gains compound across the infrastructure. When each drive holds more data, fewer drives are needed to provide the same amount of storage. That can mean fewer servers and racks, less cabling, and lower power and cooling requirements. In turn, increasing the capacity of a single component can reduce the resources required across an entire deployment.

That system-level impact is also why total power consumption doesn't tell the full story of efficiency. As Dropbox grows and stores more customer data, overall energy use may increase even as the infrastructure becomes more efficient. A more useful measure is watts per petabyte, or the amount of power required to support a petabyte of storage. Since 2020, watts per petabyte across our storage infrastructure have improved by more than 50%. Today, it takes less than half as much power to support the same amount of storage as it did in 2020.

Together, all of the approaches described above help Dropbox get more from existing infrastructure by reducing unnecessary power consumption, making better use of available capacity and increasing how much each piece of hardware can support. How long that hardware can reliably remain in service matters, too.

Extending infrastructure over time

Replacing equipment too early can leave useful capacity on the table, while keeping it too long can introduce reliability and performance risks. Hardware doesn’t become unreliable simply because it reaches a particular age, nor does keeping equipment longer always make sense. To make those decisions, Dropbox monitors how hardware performs in production. Metrics such as annual failure rate help engineers understand how different components and generations of equipment behave over time.

As demand for infrastructure continues to grow, those lifecycle decisions become increasingly important. Getting more from existing infrastructure isn't only about how efficiently hardware operates while it's in service. It's also about understanding how long that hardware can continue operating reliably before additional investment is needed. That data informs whether hardware can remain in service, should be repaired, or needs to be replaced.

Understanding hardware performance holistically allows us to extend the useful life of equipment when it continues to perform reliably instead of relying solely on a fixed replacement schedule. When performance declines or newer hardware provides meaningful improvements in capacity, reliability, or efficiency, we can plan a transition. Reliability comes first. Extending a hardware lifecycle is valuable only when equipment continues to meet our operational standards.

We repair hardware whenever practical to extend its useful life. When equipment can no longer remain in service at Dropbox, we work with trusted partners to resell or responsibly recycle it. Together, these decisions help maximize the value of equipment throughout its lifecycle rather than treating deployment and replacement as the only meaningful milestones. But eventually, new hardware does need to come online. And as servers become more powerful and storage becomes denser, deploying them can introduce a new set of constraints in the physical infrastructure that supports them.

Engineering beyond the hardware

Deploying new hardware isn't as simple as swapping one server for another. Before new hardware can go into production, the physical environment has to be able to support it. Our team plans for the power, airflow, rack layout, cabling, and other physical requirements each deployment needs, working closely with our colocation providers along the way.

Those decisions are closely connected. A server that stores more data or delivers more compute may also draw more power or generate more heat. That can change how racks are designed, how equipment is cooled, and even how much hardware a particular area of a data center can support. As infrastructure becomes more powerful and denser, getting more from the hardware depends on making sure the environment around it can evolve, too.

One recent example illustrates how those tradeoffs play out in practice. As Dropbox deployed its seventh-generation servers, the increased power requirements exceeded the capacity of the existing rack power design. Rather than rebuilding the underlying facility infrastructure, the Hardware Engineering and Datacenter Engineering teams redesigned the rack power architecture, doubling the number of power distribution units per rack while continuing to use the existing busways. The result supported the new hardware without requiring major changes to the data center itself.

It's a reminder that infrastructure improvements don't stop with the hardware itself. As demand grows and hardware evolves to meet it, each new generation has to fit within the constraints of the environment around it.

What years of operating infrastructure have taught us

The work reflects more than a decade of engineering investment across Dropbox's infrastructure. Capacity planning, fleet optimization, storage systems, hardware lifecycle management, and data center engineering each address different challenges, but together they help us make better use of the infrastructure that supports our products.

None of this work is one and done. As customer demands change, hardware evolves, and new technologies introduce opportunities and new constraints, we improve our infrastructure, each update building on the ones that came before it.

Those lessons have become even more relevant as demand for digital infrastructure continues to grow. AI is accelerating the need for storage and compute across the industry, but the underlying engineering challenge hasn't changed. Infrastructure still has to scale while remaining reliable, efficient, and resilient. As these technologies evolve, we'll continue building systems that support the products our customers rely on today while giving us the flexibility to support what's next.

YugabyteDB Resource Governance adds CPU controls for multi-tenant database clusters so a runaway query or traffic spike in one database does not starve other workloads sharing the same infrastructure. The system combines per-database CPU limits with fair sharing of unused capacity, allowing denser consolidation while maintaining workload isolation and predictable performance.

Last week, Anthropic announced a new specification built on top of the foundations and learnings of MCP, Model Hardware Specification. From their announcement post, Model Hardware Standard (MHS) is a shared specification for AI agents to safely operate physical devices. Initially previewed for physical lab and manufacturing hardware (robot arms, qPCR machines, microscopes), this specification may open the door for AI to dramatically transform and reshape our physical world in unexpected ways.

Though MHS is similar to MCP, the key difference is that this specification is an entryway for manipulating real-life equipment and robotics, not just software. As a result, the potential security risks and surface area are very different.

We think this is where the edge is heading in a post-agentic world: not a layer sitting on top of software, but shared infrastructure for software and hardware systems together.

When we built and shipped our edge MCP prototype recently, we were building on an architectural foundation of exceptional process execution security, network resilience, and agent performance. Today, we’ve taken the first steps to extend those concepts of securing and scaling agentic operations into the world of hardware. You can see our research prototype here, which we’ll keep up to date as more of the specification and standard materializes.

Performance as Safety

Let's zoom out and discuss the difference between securing exclusively agentic software systems and agentic software/hardware hybrid systems.

In an agentic commerce experience, a slow or dropped connection between an agent and a checkout API means someone clicks "buy" twice. This is a terrible customer experience, and one that causes customer and operator pain.

A delayed connection between an agent and a robot arm or life sciences experiment means an agent that isn't sure whether its command landed. "Retry the move" is a materially worse failure mode than retrying the form submission." In robotic manufacturing, a retry might cause the agent to break the physical material the robot is manipulating. In a lab, the risks are even more extreme: actions like a qPCR run have high stakes for advancing global health research, and a mishandled request can ruin the experiment.

Exploring a Performant and Secure implementation

Since MHS is so adjacent to MCP, we forked fastly/edge-mcp, our recently published implementation of a stateless MCP server for Compute, and started extending the system to explore MHS capabilities.

This was an MHS implementation tailwind: edge-mcp's protocol engine and Fastly Compute bindings needed no changes. Auth, scope checks, and schema validation already run before a tool handler executes, so all the new MHS-specific security and integration prototyping are plugged into the existing handler interface. Specifically, we built:

• Safety limit enforcement: every tool call is checked against the target device's declared safety limits before it's forwarded. A temperature bound, a set of allowed axis values, whatever the device metadata says.
• Per device quotas: In addition to traditional edge rate limits, an authorized agent can be throttled, because repeated commands can wear out hardware even when every individual command is legitimate.
• Audit trails: Every decision gets logged with a hashed identity and a correlation id, with the goal of being able to reconstruct what happened without storing raw tokens or arguments.

Monitoring the Standard as it Develops

At the time of writing, the model hardware standard is still very much in an early stage and in development. What we've built is a prototype proposal for what would be ideal for a secure edge implementation.

But make no mistake, we believe this is the direction of the agentic edge: emerging software, network, and hardware controls in a way that demands exceptional end-to-end security and performance. We believe that we are uniquely positioned to be the best platform for this layer within the modern agentic architecture, especially as the line between software and hardware begins to blur.

If you would like to collaborate with us on this work, or if you would like us to work with your technical teams and leadership to take advantage of the agentic transformation moment that we're in, reach out.

Nao's founders argue that AI is shifting data teams toward maintaining business context and enabling self-service analytics. They recommend starting with one focused use case, measuring results, and improving data models before investing in a full semantic layer.

From Data Querying to Data Investigations: Rethinking Natural Language Interfaces for Databases

Natural language (NL) interfaces to databases have been optimized for the wrong problem. The dominant Text-to-SQL paradigm assumes that users ask questions that can be answered by single SQL queries. In practice, however, users seek assistance with solving data problems. This requires searching a database by sequences of SQL queries while reasoning over intermediate results instead of just running one SQL query. This paper therefore introduces a new paradigm for NL interfaces to data, which we call data investigations. We present D^2, a first prototype of a data investigation system that embodies this vision by autonomously searching, reasoning over, and collecting data to solve data problems. Using a newly constructed benchmark based on the Murder Mystery dataset, we demonstrate the potential of D^2 for tasks that require data investigations with evidence-backed decisions, extending beyond the capabilities of traditional single-query question answering.

Key Points

• Adobe announced Anil Chakravarthy as its next president and CEO, replacing Shantanu Narayen, who announced last March he would step down after 18 years in the role.
• Narayen will become executive chair and Chakravarthy will join Adobe's board.
• Adobe is tapping a new CEO as its stock has fallen alongside other software names this year due to investor fears of AI disruption.

Adobe on Thursday named Anil Chakravarthy as its next president and CEO, succeeding Shantanu Narayen, who announced he would step down earlier this year.

Chakravarthy, who most recently served as president of Adobe's customer experience orchestration and worldwide field operations, will take the helm Dec. 1, the company said. He will also join Adobe's board.

Narayen will become executive chair and "work closely" with Chakravarthy during the transition, Adobe said. Narayen said last March he would leave his role after joining the company in 1998 and serving as the head of Adobe for 18 years.

"Adobe's opportunity ahead is limitless with our track record in creating new market categories and world-class products," Narayen said in a statement. "Anil is an experienced transformational leader who leads with values, integrity and a deep knowledge of our business."

Chakravarthy joined Adobe nearly seven years ago after serving as CEO of enterprise data management company Informatica. He told CNBC in a 2021 interview that he became connected with Adobe and Narayen through its partnership with Informatica.

"A lot of the reason I came was the opportunity to work with him and work with the leadership team at Adobe," Chakravarthy told CNBC at the time.

Adobe is tapping a new CEO as the company's stock has been pummeled due to investor concerns that artificial intelligence will disrupt software makers. After a boom in 2023, Adobe shares have slid since, losing 25% in 2024 and another 21% in 2025. The stock is down 18% so far in 2026.

Shares of Adobe fell about 2% in extended trading.

Alongside the news, top Adobe executive David Wadhwani announced he will exit the company. Wadhwani has served as the president of Adobe's creativity and productivity business for nearly five years.

CNBC previously reported Wadhwani was seen as a strong contender to serve as Adobe's next CEO, in part because of his key role in the design software company's bid to acquire Figma. The companies ultimately called off the deal in 2023 due to regulatory hurdles.

Wadhwani said in a LinkedIn post that he has a few company ideas he plans to "explore and pressure-test."

"As much as Adobe means to me, I've decided this is the right moment for me to start a new chapter, and it's a great moment for Adobe to do the same as Anil steps into the CEO role," Wadhwani wrote. "I've had the privilege to work alongside Anil the last few years and I leave confident in where he'll take Adobe."

Never lose a reference.

Spaced repetition

The gap between reviews matters more than the hours you put in.

Six weeks of notes and almost none of it stuck, which is the opposite of how I had assumed revision was supposed to work. The point was never to log more time at the desk. It was to be asked the question again just as the answer started to slip, which is a different thing entirely and much harder to schedule by feel.

What the studies agree on

• Retrieval beats re-reading, even when it feels harder in the moment
• The optimal gap widens after each successful recall of the same item
• Spacing related items apart cuts the interference between them
• Testing yourself is not just measurement, it is itself the study

Every scheduler still guesses at the timing. SM-2 quietly underpins most of them, and it was tuned back in 1987 on one person's flashcards. Nothing since has really replaced it, so the defaults every app ships with today are still, in effect, that same person's, carried forward because they were there, not because anyone re-ran the experiment at scale.

Conditions that slow acquisition often improve long-term retention (Bjork, 1994).

So I am rebuilding the deck around the gaps rather than the totals: shorter sessions, wider spacing, and no more re-reading the same page the night before.

Where it breaks down in practice

None of this is an argument against the algorithm, only against trusting it past the point where it is measuring anything real. A scheduler knows when a card was last seen and whether the answer came back right. It does not know that the answer came back right because the card sat directly underneath one that gave it away, or that two cards in the same deck are quietly teaching the same fact in slightly different words.

The failure mode is always the same, and it is not the maths. A deck grows past the point where its intervals mean anything, the daily queue turns into a backlog, and the backlog gets cleared by pressing the middle button on everything in it, which the scheduler reads as evidence that the intervals were correct, and duly widens them. The numbers stay healthy the whole way down.

• Leeches: the few cards that fail over and over and eat a third of the session
• Interference: near-identical cards that trade places in memory week to week
• Backlog: a queue long enough that the grading stops being honest

What I have settled on is duller than a better algorithm and works far better than one. Delete the leeches instead of nursing them. Write cards that ask for one thing, so a wrong answer means something specific rather than that the card was too broad to answer. Keep the deck small enough that a bad week can be caught up in a day, because the moment it cannot be, every interval in it is a guess resting on a guess.

Robin Spielmann takes a stab at defining “design engineer”:

The role [of a design engineer] is: there is a specific set of tasks that has to be done in every digital product, and on most teams nobody is responsible for them.

A design engineer understands there’s a ton beneath the surface of a static mock:

A [static screen] shows a product at its best. One screen width, plausible data that someone made up, and the path where everything goes right. Shipping that same screen means answering a much longer list of questions. What happens with a name that’s sixty characters long? Does the layout jump around when the data finally loads? What if there is no data at all, and is that an empty state or does it look like something broke? What about a slow connection, a narrow phone, someone who never touches a mouse?

Making decisions around those questions is the job of a design engineer:

[a great product is] the sum of a few hundred small decisions, none of which would survive being written down as a requirement.

There’s the reality right there! There’s just too much to write down and convey as requirements (plus trade-offs have to be made). You need someone who 1) understands these concerns exists, and 2) takes them on with care.

I kinda like this working definition of a “design engineer”:

A design engineer is the person who owns whether a product still agrees with itself.

Design hiring is rising, with 82% of hiring managers reporting steady or growing need and 40% planning more roles within six months. What changed is the bar: 73% want candidates fluent with AI tools, and 79% want people who can design AI products, not just use them. Junior roles are the casualty, dropping 8 to 10% at companies adopting generative AI, while 38.5% of interviewed candidates were flagged for AI-assisted cheating.

Grok Imagine Video 1.5 agent delivers higher quality, better storytelling than previous releases. Powered by Grok's latest Image 2.0 model, it excels at connecting multiple shots together with greater continuity. The agent is now live on the web, iOS, and Android. A short video generated by the model is available in the thread.

Tim Cook remains a powerful center of gravity at Apple. He will play an especially crucial role in certain areas, such as the company's dealings with the US and China, and its handling of the memory shortage. Cook will get a base salary of $2 million, twice the typical base salary of senior vice presidents and members of the C-suite. He will also receive cash bonuses and stock units that vest over time. The salary clearly shows that Cook's role will be very active.

Omarchy is an opinionated Linux distribution built for AI agents.

Semantic layers define business metrics, context layers provide supporting knowledge, and ontologies describe entities and their relationships. Together, they help AI agents interpret data, but people still need to keep that knowledge accurate and current.

Warner Music Group turned a hand-edited anti-counterfeit tracking spreadsheet into governed Databricks tables without taking the spreadsheet away from operators. The pipeline handles shifting tabs, renamed headers, late edits, row fingerprints, and full-overwrite loads so executive reporting can trust a messy business interface that people actually use.

Leaked circuit diagrams suggest Apple's upcoming A20 Pro chip may feature a 7-core GPU, an expanded cache for its efficiency cores, and a faster memory interface, potentially delivering improved graphics performance and power efficiency. While the source has a reasonable track record, the claims are based on indirect analysis of motherboard layouts rather than the chip itself, so they should be treated as informed speculation until Apple officially unveils the iPhone 18 Pro.

HBO's simplified Hogwarts house crests for its upcoming Harry Potter series have divided fans.

Heritage Auctions' Disney sale took $3.43 million across 1,346 lots.