OpenAI developed an autonomous pipeline for discovering, exploiting, and patching security vulnerabilities. In a single run, its cybersecurity model validated and generated patches for 948 Linux local privilege escalation vulnerabilities.

Today, Axiom is releasing our Lean formalization of the entire Stacks Project, the roughly 7,500-page open-source reference that lays the foundations of modern algebraic geometry. Spanning some 16 million lines of code, it is the largest integrated, reusable library of formalized mathematics ever built.

With this release, the full mathematical development of the Stacks Project is available as a single, machine-checked library. Researchers and AI agents alike can import its definitions and theorems directly into new formal proofs, while permanent Stacks tags link every Lean declaration back to the canonical text mathematicians already know.

This milestone begins with the Stacks Project itself. Initiated by Columbia University mathematician Johan de Jong in 2005, it has grown through the tireless work of hundreds of mathematicians who have contributed proofs, examples, and refinements over two decades. Our formalization rests equally on the foundations of the Lean and Mathlib communities. Formalizing a corpus of this magnitude was only possible because those communities spent years building a rich mathematical library, along with the abstractions needed to organize it, long before our work began.

Why formalize a foundational reference of this scale? As AI systems begin generating mathematical arguments at a pace far beyond what humans can inspect by hand, formal verification becomes essential. In fields with mature Lean infrastructure, new results can often be formalized shortly after they are discovered. Until now, modern algebraic geometry has been far harder to approach this way: a single contemporary proof may invoke a long chain of theorems across commutative algebra, schemes, sheaves, cohomology, and algebraic stacks before its core argument even begins. The mathematics existed in the Stacks Project, but the corresponding Lean infrastructure did not.

Closing that gap is as much a software engineering challenge as a mathematical one. While uncoordinated AI code generation can produce short, isolated scripts quickly, scaling to millions of lines of verified mathematics requires clean abstractions, stable interfaces, and components that fit together across an entire codebase. To achieve this, we deployed coordinated swarms of AI agents capable of translating, proving, and integrating thousands of theorems in parallel. Formalizing the Stacks Project in its entirety establishes a new starting point for algebraic geometry and the many neighboring fields that rely on its machinery.

The mathematics behind Stacks

At its heart, algebraic geometry studies the interplay between algebraic equations and the geometric shapes they describe. Over the real numbers, the equation $x^2 + y^2 = 1$ defines a circle; over the rational numbers, its points correspond to Pythagorean triples, such as $3^2 + 4^2 = 5^2$. Studying the same equations across different number systems, or in families that vary over a parameter space, connects geometry directly to number theory and algebra. These ideas also reach beyond pure mathematics: elliptic curves secure modern digital cryptography, while algebraic curves over finite fields power error-correcting codes. Modern algebraic geometry provides a common language for studying equations across all of these settings.

Forging that language took generations. Emmy Noether revolutionized algebra by shifting focus from individual equations to abstract structures such as rings, modules, and ideals. Just as the right software abstraction can replace thousands of special-purpose routines with a single reusable framework, a theorem proved for the right algebraic structure applies across many concrete settings at once. A generation later, Alexander Grothendieck and his collaborators introduced the theory of schemes, creating a sweeping dictionary between algebra and geometry that allowed mathematicians to do geometry over arbitrary rings, with arithmetic and infinitesimal data built in from the start. Monumental treatises like Éléments de géométrie algébrique (EGA) and Séminaire de géométrie algébrique du Bois Marie (SGA) rebuilt the foundations of the discipline from the ground up, supplying the machinery behind landmark breakthroughs including Deligne’s proof of the Weil conjectures and Wiles’s proof of Fermat’s Last Theorem.

Yet as the subject expanded, its foundational literature grew vast, scattered across thousands of pages of dense monographs and seminars, much of it written in French. A great deal of the subject's working knowledge also lived as unwritten folklore passed down from advisor to student. Even defining an algebraic stack, a geometric space capable of remembering the internal symmetries of the objects it parametrizes, requires a formidable tower of prerequisites spanning commutative algebra, topologies, sheaves, and cohomology. Mathematicians needed a unified, self-contained reference where those prerequisites were written down in full detail.

In 2005, de Jong set out to organize those foundations the way software engineers maintain an open-source project like the Linux kernel. What began as an accessible introduction to algebraic stacks evolved into a living, collaborative encyclopedia comprising thousands of permanent four-character tags. The Stacks Project operates on rigorous editorial principles: every theorem carries a proof, every assumption is stated explicitly, and every step points back to the exact tags on which it depends. In doing so, de Jong and his collaborators anticipated the architecture of formal proof libraries, demonstrating that mathematics becomes far easier to verify and extend when its components have stable identifiers and explicit dependency graphs. Translating the Stacks Project into Lean brings mechanical verification to that human-designed architecture.

A library built for reuse

On October 27, 2026, Axiom released our Lean formalization of the Classification of Finite Simple Groups (CFSG). While CFSG and the Stacks Project are both monumental in scale, they represent fundamentally different engineering challenges. CFSG is organized around a single landmark theorem. The Stacks Project, by contrast, is a foundational library: its value lies in thousands of interlocking definitions, constructions, and lemmas designed to be reused across countless future proofs.

With this library, a mathematician or AI agent formalizing a new theorem about families of curves no longer needs to reconstruct the foundations of schemes or coherent cohomology from scratch. They can import the relevant definitions and theorems directly, while Lean’s kernel guarantees that every cited result is applied only when its exact hypotheses are satisfied. Formalizing the Stacks Project as one connected codebase gives researchers and agents a common chain of verified definitions and theorems on which to build, something no collection of isolated proof scripts can provide.

To make our library easy to navigate, our release preserves the permanent tag structure of the original text. At stacks.axiommath.ai, readers can view the pages of the original Stacks Project side-by-side with the corresponding Lean code and explore the interactive dependency graph. Because a single Stacks tag often unfolds into multiple formal definitions and lemmas, some newly defined and others bridged directly to existing declarations in Mathlib, our interface tracks these mappings explicitly so researchers can see precisely how the informal and formal developments align.

Engineering coherent mathematics at scale

A smorgasbord of independently verified proofs does not make a usable mathematical library. If thousands of AI agents formalize theorems in parallel without architectural coordination, two agents will inevitably prove correct theorems about the same mathematical object using subtly incompatible definitions, or duplicate foundational infrastructure that already exists in Mathlib. Lean’s kernel will accept both files in isolation, but their results will be painfully difficult to compose downstream. Building coherent formal infrastructure requires keeping every definition and interface aligned across the entire project.

At this scale, formalization is as much systems engineering as it is mathematics. To build a single, unified library, our mathematicians and engineers designed a hierarchical system of AI agents with specialized responsibilities and strict coordination protocols. Agents worked in parallel across the dependency graph to translate statements, search Mathlib for existing abstractions, construct proofs, and resolve prerequisites, all while keeping definitions, typeclass interfaces, and mathematical abstractions aligned across chapters.

In a tightly interconnected dependency graph of definitions and theorems, an unfaithful or trivialized formalization is quickly exposed. Ensuring that each formal statement faithfully captures the mathematical meaning of the original text is even more important than verifying its proof. Across the library, statement faithfulness is enforced automatically at scale through multi-agent auditing, semantic cross-checks against the source text, and the strict requirement that every definition and lemma must successfully interface with the downstream theorems that depend on it. Combined with targeted audits on foundational definitions and landmark theorems, this automated verification pipeline ensures that the formal library remains faithful to the mathematics of the Stacks Project.

What formal verification reveals

Over the course of the project, our system surfaced dozens of statements in the Stacks Project that required local refinement, including missing hypotheses, edge cases in positive characteristic, and claims that did not hold in the full generality stated. Rather than treating failed proof attempts as mere obstacles, our agents diagnosed the underlying mathematical obstructions and constructed explicit counterexamples to prove where the original statements broke down.

Once an obstruction was isolated, the system worked to repair the mathematics so downstream chapters could still depend on it. For local oversights, our agents identified the exact missing hypotheses and formalized the corrected theorems alongside their counterexamples. Where a false supporting lemma created a gap in the proof of a deeper theorem, the agents found alternative routes through the literature to establish the main result under its original hypotheses. Together, these resolutions show how large-scale formalization can actively refine and strengthen the mathematical literature itself.

A monument to the past, a foundation for the future

Ultimately, the mathematics inside this library is the product of generations of human creativity, from the geometric intuition of the early pioneers, to the structural revolutions of Noether and Grothendieck, to the open-source scholarship of the Stacks Project and Mathlib communities. Each generation inherited a body of mathematical knowledge, cast it into a sharper language, and handed the next generation a stronger foundation. We see this formalization as part of that ongoing tradition: both a tribute to the mathematicians who built modern algebraic geometry, and working infrastructure for an emerging era in which humans and AI agents explore new mathematical frontiers together.

In an October 21, 2026 announcement, de Jong requested that AI-generated comments and pull requests not be submitted directly to the upstream Stacks Project repository for the time being. The Stacks Project remains an active, living text under the stewardship of Johan de Jong and its community of contributors, while this Lean formalization is an independent open-source project maintained by Axiom. We fully respect that boundary: we keep our formalization, counterexamples, and refinements in our own repository, where mathematicians can review and draw upon them on their own terms.

You can explore the side-by-side text, inspect counterexamples, and trace the full dependency graph at stacks.axiommath.ai. Like the Stacks Project itself, our formalization is open source and designed to grow over time. We invite mathematicians, Lean developers, and AI agents to examine the library, refine its abstractions, and build new mathematics upon it.

AI inference workloads are dynamic. There are thousands of regimes spanning new models, hardware platforms, customers, use cases, and traffic shapes. It’s no longer scalable to optimize each of these regimes by hand.

• Architectures are highly variable: it’s been ~11 years since the Transformer. We might have thought there would be more consolidation, but none of the top-10 open-source LLMs on OpenRouter use the same architecture!
• Workloads are highly variable: Together serves many trillions of tokens per day across thousands of customers, each with a different traffic shape (batch size, sequence length, MoE expert imbalance, attention sparsity, session duration, domain).
• Hardware is highly variable: H100s, B200s, B300s, NVL72, VR, Groq, and more each require distinct strategies.

Agents are a great fit for this problem, in theory. They can adapt to new workloads and search over the space of possible optimizations without relying on fixed rules or heuristics that plague human experts and traditional machine learning compilers. However, today’s agentic systems are bottlenecked by the speed of experimentation.

We introduce Together Compiler (TKCC), the first truly continual optimization loop that leverages high-throughput agents to optimize to diverse inference workloads

In less than 24 hours, TKCC achieves up to 2.6x higher TPS across frontier open source models (Kimi K3, GLM 5.3, MiniMax M3.1-Flash, DeepSeek v4.1-Flash), sets the state-of-the-art on SemiAnalysis’ InferenceX benchmark for low-latency with 1111 TPS on MiniMax M3.1-Flash and 1205 TPS on DeepSeek v4.1-Flash, and outperforms available open-source megakernels by 1.7x on their workhorse Llama 1B batch size 1 setting. Furthermore, TKCC generalizes to domains beyond language model inference (weather modeling, PDE, time-series, and biology). This performance boost is enabled by TKCC’s 252x higher experiment throughput compared to baseline agentic performance optimization systems. Together Compiler is serving trillions of tokens today.

Traffic is continually changing

As an inference provider, we see a variety of user behaviors based on regional patterns, new model releases, and burstiness.

• Regional patterns: Users across the world may have different model preferences. We’ve observed traffic for one country’s working hours to have 1.4x longer prompts than another country (97k vs 70k).
• Model releases: Users take time to figure out how to integrate new model releases into their workflows. First, they tend to opt for chat-based interaction and evaluation. This is swiftly followed by an 80% increase in prompt length just two weeks after the release as users shift towards agentic workloads.
• Burstiness: Customers may send bursts of requests at random times throughout the day. Prompt lengths can suddenly double and cache hit rates can fall if not handled carefully.

It’s clear that we must adapt to ever-changing user behavior with specialized optimizations for each new deployment.

Overview of Together Compiler

TKCC takes as input the traffic shape, model, and hardware. TKCC uses agents to generate a series of optimizations for an inference engine.

The core insights in TKCC are as follows:

1. TKCC maximizes experimentation throughput and minimizes GPU idle time during agent optimization

Most existing agentic inference optimization systems require agents to launch and teardown engines like VLLM, SGLang, or TRT-LLM to test each new experiment. However, engine start times are tens of minutes, significantly impeding experimentation throughput. Instead, TKCC proposes a new paradigm of “persistent engines” where the engine starts up once and can hot-reload any candidate forward pass, without any restarts. To ensure that the persistent engines constantly have new optimizations to test, TKCC spawns multiple agents that continually generate ideas and communicate via a message board to parallelize their efforts.

2. TKCC balances the tradeoff between measurement throughput and measurement fidelity

Existing agent optimization systems either iteratively relaunch the inference engine, suffering from low experiment throughput, or optimize standalone kernels in isolation, outside of the inference engine, suffering from poor measurement fidelity. Systems that optimize standalone kernels often evaluate them using random input data. However, with modern architectures using data-dependent primitives like MoE and sparse-k attention, input data distributions have a direct effect on which optimization strategies may win. High-fidelity inputs are important for effective optimization. TKCC uses a tier of persistent engines to balance the throughput-fidelity tradeoff: “fast engines” load a few layers and are ideal for rapid iteration and low-variance timings, while “slower engines” load many layers and are ideal for testing whether optimizations hold-up on real data distributions.

3. TKCC utilizes a custom cost model to select parallelism strategies (e.g., TP, EP, DCP, etc.) for agents to achieve the highest performance

Existing systems have sophisticated methods for selecting inference configurations under SLA requirements. However, selecting the ideal configuration faces the same throughput-fidelity tradeoff: it is intractable to measure each parallelism configuration, especially because software implementations are immature. A naive approach is to select a parallelism strategy based on raw hardware specs or micro-benchmarks. However, this insufficiently captures data dependent traffic properties like MoE expert imbalance or uneven prompt length distributions. We designed a cost model that uses a tiered measurement strategy involving hardware specs, microbenchmarks, and measured forward passes to construct a high-fidelity representation while rapidly pruning the configuration search space to support continual traffic drift.

Results

We evaluate TKCC against three different types of baselines: Hand-tuned megakernels, InferenceX engine configurations, and popular AI codebases from diverse domains like weather modeling, PDE, time series and biology models.

MegaKernel workloads

We start by evaluating the canonical MegaKernel workload: Llama 1B at batch size 1. This model architecture has been well-optimized by both human experts and traditional machine learning compilers. TKCC generates 1.7x higher TPS and continues to perform as sequence length increases.

InferenceX AgentX workloads

We evaluate TKCC on the AgentX benchmark from SemiAnalysis. We start from the best-reported open source engine configurations for frontier models across inference engines and hardware platforms. TKCC consistently sets the performance frontier across all settings, outperforming highly-optimized baselines by up to 2.6x higher TPS.

We also evaluate specifically on the low-latency use case at batch size 1 and set the state-of-the-art performance with 1111 TPS on MiniMax M3.1-Flash and 1205 TPS on DeepSeek v4.1-Flash. For these results, we use our cost model to select the parallelism configuration instead of using the InferenceX configuration. We observe speedups with this approach.

Across AI workloads

We select popular open-source code bases across weather modeling, PDE, time-series, and biology. We show the geometric mean speedups of TKCC over simply using Claude Code with the /goal command, illustrating that the principles of TKCC generalize across domains. We have been using TKCC as a general purpose AI compiler beyond LLM inference.

Polymorphic AI systems is the next frontier

For Together AI, the most exciting systems challenge has been Polymorphic Inference. Inference is no longer about optimizing for a single traffic shape for a single hardware platform and model, traffic is constantly and dynamically evolving, much like financial markets, and that dynamism has opened up a whole host of new research questions.

We benchmarked a fine-tuned E2B model against frontier APIs on a real production classification task. It matched their quality in under 100ms, at about a hundredth of the cost.

At Airbnb, we use AI models for classification tasks, such as detecting risky user-generated content, identifying why customers contact support, and recognizing topics in reviews. These tasks require subtle language understanding and the common sense to interpret what people leave unsaid.

Frontier models, with hundreds of billions of parameters and internet-scale pretraining, are often good at these tasks. But for interactive products and high-volume workloads, accuracy is only part of the requirement. We also need low latency, manageable serving costs, and control over the tradeoff between false positives and false negatives.

Smaller open-weight models are faster and cheaper to run at scale. By extracting logprobs, we’re able to produce a score for thresholding. But these small models are trained to handle a vast range of conversations and our tasks occupy just a tiny corner of that training distribution. Out of the box, they often miss subtle distinctions that matter immensely for our product.

Better prompting has limits. (I’m often reminded of an assignment from elementary school: write instructions for how to make a PB&J. “Put the knife in the peanut butter,” you’d write, only to have the teacher stab through the jar or insert the handle instead of the blade. There seem to be no instructions detailed enough to avoid every possible lapse in common sense.)

GLOWC, an internal framework used by engineers at Airbnb, makes it easy to fine-tune open-weight language (and vision-language) models into fast, accurate classifiers. In this blog post, we put one of these classifiers head-to-head with open-weight and proprietary models and find that it matches frontier-level quality in under 100ms at roughly 1% of the cost.

Case study: benchmarking a production classifier

Public benchmarks rarely capture a real product’s constraints. Instead, we test a production classifier that screens content for violations of Airbnb’s policy on pricing and payment transparency. The task requires recognizing subtle policy distinctions with high precision, since false positives prevent legitimate content from being published. The model is called thousands of times per minute, and because it gates publication in real time, a score must return within 200ms.

We compare a fine-tuned classifier with 2 billion effective parameters (E2B) against open-weight and proprietary models on a held-out evaluation dataset of 10,000 weighted examples. The fine-tuned model is trained on de-identified examples from users who have not opted out of AI training. Open-weight models are self-hosted with vLLM 0.28.0 on a single NVIDIA RTX Pro 6000 GPU. Models up to 12B parameters run in bfloat16. Larger models use publicly available FP8 or NVFP4 checkpoints. Proprietary models are called through their vendor APIs. Unless noted, every model receives the same concise ~400-word prompt.

Quality vs. latency

Any model we deploy must be accurate enough to trust with a policy decision and fast enough to avoid disrupting the user experience. These two criteria often trade off, forming a quality-latency frontier that we plot below.

We report max F1 as the measure of classification quality. While we would normally prefer PR-AUC for imbalanced classification, most proprietary models return only a True or False verdict, so there is no curve to integrate. Max F1 puts both kinds of models on one axis: for open-weight models and decision models, we sweep over thresholds and report the best F1. For other proprietary models, we report the F1 of their verdict. The conclusions do not depend on the choice: PR-AUC, where available, and accuracy rank the models nearly identically to max F1. Latency is server-side handling time as recorded by our serving gateway.

Open-weight models are fast but sacrifice quality. Many open-weight models have latencies below our budget. Classification quality and latency tend to climb with model size. Off the shelf, their performance plateaus meaningfully lower than the best proprietary models or our fine-tuned classifier.

Proprietary generative models are accurate but slow and inflexible. Their classification quality does not meaningfully improve with more thinking, so we report the low-thinking results. Even in low-thinking mode, GPT-6.1 Sol and Claude Sonnet 5.5 have a median latency of about 900ms and a p99 of multiple seconds, many times our latency budget. GPT-6 Luna is the fastest proprietary generative model we tested, yet is both slower and less accurate than Gemma4-31B running on a single GPU. And because each model returns a verdict rather than a score, it gives a single, fixed precision-recall point. With the concise prompt, GPT-6.1 Sol lands at 0.82 precision and 0.96 recall, favoring recall in a task where false positives are costly. Moving that point means rewriting the prompt.

Decision models have strong performance for their speed. TypeSafe’s Jev returns a probability instead of generating a verdict, so it isn’t held back by token generation and can be thresholded like our own classifier. It is the most accurate off-the-shelf model we tested under 100ms.

Fine-tuning moves the quality-latency frontier instead of trading along it. Fine-tuning Gemma4-E2B on hundreds of thousands of domain-specific examples lifts its F1 from 0.563 to 0.902, on par with the best proprietary models, while median latency stays at 35ms. No other model we tested is close on both axes.

A detailed prompt improves classification quality but doesn’t close the gap. We also test every model with a detailed 2,700-word prompt that spells out each behavior type with worked examples and common false positives. Proprietary generative models gain one to three points and roughly match the fine-tuned classifier, albeit at much higher latency. For models under our latency budget, the gains are modest and a large gap remains. The detailed prompt also increases latency and cost. Together, these indicate that for models fast enough to deploy, prompt tuning does not necessarily close the quality gap.

Cost at scale

A GPU costs the same whether it’s busy or idle, therefore self-hosting is only cheap once you have sufficient traffic. The fine-tuned classifier can support thousands of RPM on a single GPU with low latency, therefore its serving cost is constant until another worker is needed. Proprietary models, called via vendor APIs, charge based on token usage. This forms a linear relationship with volume: the more traffic you send, the more expensive it becomes.

Costs for proprietary models are calculated from the input and output tokens observed on our evaluation runs, priced at each vendor’s publicly available list rates as of October 2026. They do not reflect any negotiated pricing, discounts, or other non-public commercial terms. For models that offer discounted pricing on cached input tokens, we assume a 71% cache hit rate based on the average shared prompt prefix. This is higher than the hit rate we observed in practice, so it favors the hosted models. GPU costs are based on publicly available cloud rental rates for an NVIDIA RTX Pro 6000, and all costs are shown as multiples of that single-GPU cost.

Self-hosting is cheaper at high volume. At thousands of RPM, the frontier models using the concise prompt cost two orders of magnitude more than a single self-hosted GPU, and the detailed prompt raises their cost by a further 20 to 40%. Lower-cost proprietary options still run nearly five times the cost of the GPU, with lower accuracy than the fine-tuned model. GPT-6 Luna and TypeSafe’s Jev cost about the same on this task, so we report Jev, the better-performing of the two. With the detailed prompt, Jev’s cost quadruples, as its API offers no discount for cached input.

Proprietary models only win at low traffic: below roughly 15 to 30 RPM, Claude Sonnet 5.5 and GPT-6.1 Sol are cheaper than a dedicated GPU.

When should you fine-tune?

Fine-tuning on in-domain data delivers quality, latency, and cost at the same time. But it isn’t always the right tool. For low-volume tasks, or tasks that change week-to-week, a frontier model behind a good prompt is often the right call. In our benchmark, fine-tuning paid off when:

• Volume is high. Above the roughly 30 RPM on our task, one self-hosted GPU costs less than frontier APIs. At our volume, it costs orders of magnitude less.
• Latency is tight. Our fine-tuned E2B classifier returned a score in about 85ms p99, while frontier APIs took around 900ms at the median and seconds at p99 to achieve similar quality.
• You need a threshold, not a verdict. Scores let you choose your tradeoff between recall and precision without rewriting the prompt.
• You have labeled data. Examples teach distinctions and edge cases that instructions struggle to spell out. Hundreds of thousands of in-domain examples did what a 2,700 word prompt couldn’t.

This classifier is just one example, but the same tradeoffs have held across other models we’ve fine-tuned. At Airbnb, GLOWC provides shared infrastructure for fine-tuning, batch inference, and serving, so teams can focus on their task while improvements carry over to every model.

Appendix

1. Example weights correct for how the evaluation set was sampled from production traffic. We validated a subset of models on a larger set of 184k examples; their max F1 was within 0.01 of the results reported here.
2. Latency doesn’t track parameter count alone. Attention implementation matters too. vLLM’s current kernels are less optimized for hybrid linear-attention layers than for standard or sliding-window attention, so models with similar parameter counts can have quite different latencies.
3. See OpenAI’s or Anthropic’s fast mode for more details.

Acknowledgments

We would like to thank John Romano and Chuiwen Ma for their help fine-tuning the classifier and curating evaluation datasets, Anirudh Agarwal and Ben Mendler for the serving infrastructure and latency measurement behind the models in this benchmark, and Mukund Narasimhan, Nathan Brixius, and Ahmad Al-Dahle for their thoughtful reviews.

• Facebook Feature Framework (F3) is Meta’s framework for authoring, compiling, and serving the machine learning features underlying ads ranking models, where a single request can require more than 20,000 features. We first presented F3 at AI @ Scale 2020.
• F3 reduced execution computational costs by compiling all features into a single merged graph, but that graph also served as the release unit, so a single failure or invalid definition blocked the entire release pipeline.
• This post introduces F3 Lightning, an infrastructure layer built on top of F3 to resolve this challenge by decoupling feature releases from shared execution, so each feature is compiled, validated, deployed, and rolled back independently.
• The hardest part to solve was preserving F3’s efficiency improvements. Early per-feature release prototypes increased CPU usage because independent features no longer shared computation. We aimed to close this gap through four optimizations: stable computation identifiers, a single shared execution plan, one shared memory buffer across all features, and dense index mapping for direct array access.
• With F3 Lightning, comparable extraction features now reach production ~3.6x faster than the prior F3, with no increase in infrastructure compute cost. This shorter release cycle also enables more model iterations in the same period.

A Primer on F3’s Shared Execution Architecture

Production machine learning systems rarely consume raw data directly. Before a model can make a prediction, its feature-serving system may need to read stored signals, filter events to a time window, count or sum values, normalize them, and combine intermediate results.

The simplest design to complete this work treats every feature as an independent function. That is easy to understand, but it becomes wasteful at scale, because features are not computationally independent. A seven-day click count and a seven-day impression count may read the same event source and apply the same time-window filter. A click-through rate feature may then reuse both results. Running each feature separately would repeat that filter, and every other shared step, on every request.

F3 approached this differently, by representing feature extraction as a directed acyclic graph (DAG). Each node performs one unit of work, such as reading an input, applying a filter, or calculating an aggregation. An edge means one computation depends on the result of another. The graph’s outputs are the feature values a model consumes.

Engineers author each feature independently in a high-level language. The F3 compiler turns each definition into a small graph, then merges the graphs for every feature a service uses into one merged graph. Where features share an operation, such as the seven-day filter above, the compiler collapses the duplicates into a single node. That shared work then runs once per request, not once for every feature that needs it. At runtime, feature extraction is a traversal of this merged graph.

The Shared Graph Made Every Release All-or-Nothing

F3’s merged graph shared computation efficiently, but it came with a major catch: The graph was also the release, and one malformed definition could hold back every other feature in the merged graph.

Figure 2 illustrates this challenge. It shows seven independently authored features, A through G, where five definitions are valid, but D and G contain unrelated errors. The “Attempt 1” build fails on D, so none of the seven features ships. After D is corrected, the “Attempt 2” build reaches G and fails again. Only after both definitions are fixed in “Attempt 3” does the complete merged graph make it successfully to production.

Failures became more frequent as F3 scaled. F3 originally served a few hundred features, and at that size merges succeeded and releases were largely smooth. Today that number is more than 20,000, and different feature types need their own checks depending on how they compute, so new features and modified features are held to different testing bars. A feature that a model already consumes needs model-related tests before it can be released. Those tests are computationally expensive enough that they run only in a later release stage, and, because the merged graph ships as one unit, every other feature in it waits for them too.

F3 Lightning: Making Each Feature Its Own Release and Sharing Computation

After F3 launched, we made several rounds of improvements to the merged graph. Each one brought back release speed for a while, but the gains eroded as more features landed, because all features still shipped together in the merged graph. So F3 Lightning was built to make every feature releasable on its own while preserving F3’s efficiency.

As illustrated in Figure 3, F3 Lightning introduced two changes to help achieve this:

• Deployment granularity: Each feature is an independently releasable configuration. It is validated, shipped, and rolled back without affecting any other feature.
• Efficiency parity: F3’s efficiency came from the merged graph, so giving every feature its own release removes the source of it. Matching that efficiency while keeping per-feature releases required several key optimizations in how F3 Lightning executes.

Deployment Granularity: How F3 Lightning Isolates Feature Releases

Isolation starts in the compiler, where each feature is compiled on its own into a single configuration. That feature configuration carries everything needed to extract that feature — every node it needs, in order, with nothing borrowed from a neighbor. If feature C has a problem, feature A still ships, because the two configurations have no relationship to each other.

Because features are no longer merged at release time, each one can be selected and released on its own schedule. The release path becomes an ordered queue instead of a batch that ships all at once or not at all. Changes are prioritized by what they unblock. A new feature that no model consumes yet can go out quickly on standard validation, while a change to a feature a live model already reads gets extra testing first.

Efficiency Parity: How F3 Lightning Preserved F3’s Serving Efficiency

Our first prototypes separated deployment only. Features shipped independently, but execution was no longer shared, so the prototypes used substantially more CPU than traditional F3. Each independently released configuration arrived at the serving process as its own graph and was executed separately, repeating every read, filter, and aggregation that F3’s merged graph had eliminated.

The fix was to bring shared execution back without bringing the merge back. At startup, F3 Lightning does not rebuild a merged graph. It takes the active feature configurations, consolidates the work they share, and arranges it into a single execution order. Getting back to parity took four steps: a compiler prerequisite followed by three startup optimizations.

Step 1: Stable Identifiers Make Shared Work Recognizable

To deduplicate execution, the runtime must recognize when two independently compiled configurations contain the same computation. Node numbers can’t do this, because numbering is local to each feature’s graph. The same seven-day filter might be node 2 in one configuration and node 7 in another, and inserting a single node renumbers everything after it. Traditional F3 never had this problem, because one compiler run saw every feature and could assign identifiers globally.

F3 Lightning instead has the compiler derive each identifier from what the work does, not where it sits: the operation, its parameters, and the identifiers of its inputs. Because each input’s identifier already reflects everything upstream of it, the identifier captures the whole chain of work that produced the result. Where input order doesn’t affect the result, inputs are put in a standard order. Aggregations also include the properties that define their behavior, such as the time window and grouping keys. As a result, two features that define the same operation over the same inputs receive the same identifier, even if they were compiled and released weeks apart. If a computation’s meaning changes, its identifier changes with it.

Step 2: One Execution Plan Across Every Feature

At service startup, F3 Lightning builds a single execution plan across all active features, using a topological sort to place every node after the nodes it depends on. When several features contain a node with the same identifier, the plan keeps one copy and connects every consumer to it, so that computation runs once no matter how many features use it.

Merging guarantees each computation runs once, but the plan is still a graph that the executor walks pointer by pointer on every request. The same startup pass therefore flattens it into an ordered list, so each request runs a single forward pass down the list instead of traversing a graph.

Sharing one plan raises a risk: A single failing computation could affect every feature. To prevent this, if a computation fails or its input is unavailable, F3 Lightning marks everything downstream of it as not ready, and the executor skips that work. A failure affects only the nodes that depend on it, and independent branches keep running.

Step 3: A Shared Memory Buffer, Because Deduplication Was Not Enough

After steps 1 and 2 were complete, no computation ran twice, yet CPU use was still above traditional F3. The remaining compute cost came from memory layout. Each configuration carried its own request-time data container, so intermediate results were scattered across separate memory allocations. Walking the plan in order meant jumping between them, and each jump cost a cache miss.

F3 Lightning replaced those per-feature containers with one buffer per request. At startup, each feature’s references are rebound to slots in that buffer.

Three improvements follow from the single buffer:

Locality: Consecutive plan steps now touch adjacent memory, so the values a step reads are usually already in cache. This restores the sequential access pattern the merged graph always had. It also removes the per-feature allocation on every request.

One readiness vector: A single vector, stored apart from the values, replaces per-feature tracking, so the executor can check whether a value is ready without reading the value itself. The marker has to be separate because an empty list is a valid result, so “empty” can’t also mean “not computed yet.”

No duplicate copies: Most feature values are lists and maps, and consumers no longer get their own copy. The shared slot holds a reference to the producer’s result, so a computation used by 20 features is computed once and stored once. Single values (scalars) are still copied, because copying a small value is cheaper than following a pointer. This is safe because each buffer lasts only for one request, and the execution order guarantees each result outlives its last reader.

Step 4: Dense Index Mapping Removes the Last Per-Access Cost

Values now lived together, but finding one was still computationally expensive. Every access had to resolve an identifier, which meant hashing a key, probing buckets, and following a pointer. Lookups weren’t computationally efficient at Meta’s serving volume.

The final fix applied the same principle as steps 2 and 3, doing the work once at startup. F3 Lightning assigns every unique identifier a consecutive integer slot and rewrites every reference in every configuration to point at those slots, so identifiers are used only during initialization. Reading a result becomes a direct array index into the shared buffer, with no hashing and no lookup table on the request path.

With F3 Lightning, comparable extraction features now reach production ~3.6x faster than on traditional F3, with no increase in infrastructure computational cost. That shorter release cycle means models can be improved and retrained more often in the same period. Building F3 Lightning also taught us three lessons:

Deployment and execution should have separate boundaries: If one artifact determines both how components run and when they ship, a failure in any one of them blocks all the others. Splitting the two jobs removed a trade-off between efficiency and release speed.

Work that never changes between requests belongs at startup, not on the request path: Three tasks were identical for every request: spotting shared work, deciding the order to run it in, and finding where each result is stored. F3 Lightning now does them once, when the service starts, so independent releases add no computational cost to individual requests.

Two designs can execute the same operations in the same order and still differ substantially in CPU computational cost: In F3 Lightning, we removed every repeated computation, yet CPU use stayed above traditional F3. Each feature still kept its own copy of the shared results, spread across memory. Consolidating them into one copy per result closed the gap. This is the least obvious result in the project and the one that generalizes furthest. On modern CPUs, where results live and how many copies exist can matter as much as how many computations run.

Acknowledgments

We would like to thank Sourabh Bansal, Ping Chen, Weitao Chen, Benjamin Dummitt, Junhua Gu, Henry Hu, Jing Huo, Joffrey Liu, Rocky Liu, Weixi Ma, Shuby Mao, Sandeep Pandey, Mihir Rastogi, Tim Sombuntham, Matt Steiner, Vivienne Sung, Ritwik Tewari, Vivek Trehan, Arnaud Venet, Ziheng Wang, Gautam Wilkins, Fan Yang, Qiao Yang, Jie Zheng and the entire team behind the development and productionization of F3, Meta’s Ads ML feature computation and serving platform, and F3 Lightning, the capability built on top of it.

The next major release of SurrealDB

SurrealDB 4 rebuilds the query core and carries 240+ fixes over 3.x. SurrealDB Earth and SurrealDS run the same engine, from zero to massive.

Compatibility. PostgreSQL and MySQL clients connect over their own wire protocols, and MongoDB driver code runs through mql.js.

Stability. More than 240 fixes that no 3.x release contains, including more than 90 community bug reports that 3.x did not fix.

Performance. A rebuilt query core, with vector indexes built 7.4x faster and filtered vector search down from 27 ms to 1.1 ms.

SurrealDB 4 is the engine. SurrealDB Earth runs it serverless across Cloudflare, one isolated database per agent. SurrealDS runs it on clusters over object storage, with each write confirmed in two zones.

SurrealDB 4

Indexed queries are projected at 22x faster than in 3.x. Full-table scans are 2.3x faster, and creates, reads, updates and deletes 42% faster, as measured with crud-bench on the same hardware.

SurrealDB Earth

The SurrealDB 4 engine, serverless on Cloudflare, with thousands of isolated instances. Earth handles 10+ billion peak rows per second, fully transactional.

SurrealDS

The SurrealDB 4 engine on distributed storage over object storage, in SurrealDB Cloud multi-node clusters and Enterprise Edition. With the default two-zone policy, writes are acknowledged only after being stored on disks in both zones.

Compute is replaceable. Data stays durable. SurrealDS copies each write across failure domains before confirming it, and a new node recovers from the surviving copy. SurrealDB 4 adds 240+ fixes over 3.x.

• 240+ fixes: More than 240 fixes to the database are in SurrealDB 4 and in no 3.x release.
• 90+ bug reports: More than 90 community bug reports on GitHub are fixed in SurrealDB 4 and were not fixed in 3.x.
• 4,500+ test files: More than 4,500 SurrealQL test files run on every change.
• Two zones: With the default two-zone policy, every SurrealDS write is acknowledged only after it is stored on disks in both zones, and a replacement node recovers from the surviving copy and object storage.

Faster at every size. A rebuilt query core in SurrealDB 4, with faster storage engines, indexes and graph traversals.

• 7.4x: A 1-million-vector, 768-dimension HNSW index built in 986 s instead of 7,290 s, in parallel batches on a 64-core server.
• 27 ms to 1.1 ms: A 1% filtered vector search, with SIMD scoring and an exact filtered tier read from the index itself.
• 24.5 to 9.4 min: Indexing 200,000 records of 4.2 KB with one full-text index, with index changes batched per transaction.

Speaks Postgres and MySQL. PostgreSQL and MySQL clients, and code written for the MongoDB driver, reach the same records as SurrealQL, through one query planner.

PostgreSQL
PostgreSQL clients connect over the PostgreSQL wire protocol and run a defined subset of PostgreSQL SQL: joins, grouping, aggregates, inserts with ON CONFLICT, schema changes and transactions.

SELECT p.name,
    pr.name AS product
FROM person p
JOIN bought b ON b.in = p.id
JOIN product pr ON pr.id = b.out
WHERE p.age > 30;

MySQL
MySQL clients connect over the MySQL wire protocol, and a defined subset of MySQL SQL runs through the same query planner as SurrealQL.

SELECT pr.name,
    COUNT(*) AS buyers
FROM bought b
JOIN product pr ON pr.id = b.out
GROUP BY pr.name
ORDER BY buyers DESC;

MongoDB
mql.js 1.0 brings the MongoDB Node.js driver's API to SurrealDB, aggregation pipelines and Mongoose models included: change the import and the connection string.

import { MongoClient }
    from "mql.js";

const client =
    new MongoClient(SURREALDB_URL);
const people = client
    .db("shop")
    .collection("person");

await people
    .find({ age: { $gt: 30 } })
    .toArray();

From zero to massive. Serverless databases that scale to zero when idle, thousands of isolated ones across Cloudflare, and clusters over very large datasets, all on SurrealDB.

• Scales to zero when idle: A SurrealDB Earth database is serverless on Cloudflare's network: it starts with the first query, cold starts in ~300ms and scales to zero instantly when idle.
• Thousands of instances: Earth runs thousands of isolated, persistent databases, one per user, customer or agent, with their capacity added together.
• One query, many Workers: Earth splits a query across Workers and merges the answer, with every leg reading the same point in time.
• Compute apart from storage: SurrealDS query nodes keep caches while data pages live in object storage, so a node joins without copying the dataset and no one shards by hand.

One query. Thousands of compute units. One answer.

A client sends a query to a coordinator, which splits it across SurrealDB Earth cells on Cloudflare. Each cell reads its share of the data from object storage, every leg reading the same point in time, and the results are merged into one answer, transactional throughout. At peak, that is 10+ billion rows per second.

Data infrastructure for AI agents at any scale. One agent, one database. Thousands of agents, thousands of databases. Large platforms, shared clusters. The data model stays the same at every step.

• One agent: Gets its own SurrealDB Earth database, which keeps its state between runs and uses almost no compute while the agent is idle.
• Thousands of agents: Get thousands of isolated databases across Cloudflare's network, each scaling on its own, so a busy agent takes more compute than a quiet one.
• Large platforms: Run groups of agents on shared SurrealDB clusters that scale out, reading and writing the same memory in transactions.

Run it today, wherever you build. Embedded in an application, on a laptop, in the browser, as a server or in SurrealDB Cloud, and as an upgrade from 3.x with every 3.x record still readable.

Your questions answered

Can my Postgres or MySQL clients connect? Yes. SurrealDB 4 speaks the PostgreSQL and MySQL wire protocols and accepts a defined subset of standard SQL, run by the same planner as SurrealQL. Joins, grouping, aggregates, ON CONFLICT, schema changes, transactions, non-recursive WITH queries (CTEs) and COPY in text and CSV all work. The information_schema and pg_catalog relations list the tables of the database, and recursive CTEs and window functions are refused, as is anything else outside the supported set, with a named error before a statement changes any data.

SurrealDB gives us a foundation where we can unify semantic search, knowledge graphs, and AI-driven decision making without stitching together multiple systems. Collapsing responsibility into SurrealDB has become our default engineering posture.

— Justin Foley, VP of Engineering, Later

As a startup, we didn't want to fragment our stack every time we add a capability… instead we got graph, vector, and full-text from one engine. What surprised us was how quickly we stood up a multi-layered, graph-based memory model for our AI agent.

— Daniel Alker, Senior Cloud Platform Engineer, Cobrainer

An assertion edge carries the voice that made it, the document and page it came from, the figure it states and the dates it holds for. SurrealDB stores that as one record and queries it in one statement. We did not write middleware to hold the ontology together, because there is nothing to hold together.

— Jon Aiken, Chief Architect, Pivot AI

The Apache Hudi community is excited to announce the release of hudi-rs 0.6.0, the native Rust implementation of Apache Hudi with Python and C++ bindings. Hudi is the open lakehouse platform that brings indexing, upserts and incremental processing to data lakes, and hudi-rs brings it to programs that run without a JVM. Until now, hudi-rs has been a reader: a fast, JVM-free way to query Hudi tables from Rust, Python, DataFusion, Daft and Ray. The hudi-rs 0.6.0 release adds native write support: with pip install hudi or cargo add hudi, a Python or Rust program creates Hudi tables and appends, upserts, updates, deletes and overwrites rows in them without a Spark cluster or JVM, and every table written this way is a regular Hudi table that Spark and every other query engine supporting Hudi can read.

Many of today's pipelines that update tables run in a plain Python process or in a non-JVM engine. A retrieval pipeline embeds documents and has to keep its knowledge base current as sources are added, edited and removed. A model team curates a fine-tuning set between training runs, correcting and rejecting examples, and has to reproduce the exact version each model was trained on. A service or an agent corrects records in a dataset as it finds errors. Each of them changes a small slice of a large table at a time and needs the result to be a table that keeps its history and that every engine in the lakehouse can query. hudi-rs 0.6.0 opens the door to fast writes from exactly these places: the upserts and deletes are super fast, under a second on a single node as tables grow into the millions of rows, because Hudi's record-level index locates the rows to change without scanning the full table, and the benchmark results show how this compares with other lakehouse table libraries for Python.

The release carries close to 80 commits from 11 contributors, and alongside the write path the release makes reads from Python noticeably faster, upgrades the query engine integration to DataFusion 55 and Arrow 59, and enhances read compatibility and bindings. Let's dive into the highlights.

Write Hudi Tables Without a JVM

You can now build and maintain a Hudi table from a notebook, a script, a service or an agent, without depending on Spark or a JVM-based engine. hudi-rs 0.6.0 adds native, single-node write support covering create, append, upsert, update, delete, overwrite and dynamic partition overwrite operations, on both Copy-on-Write and Merge-on-Read tables. Upserts can be partial, touching only the columns you pass, deletes take a predicate or a list of keys, and tables keyed on several fields or on an integer ID field work too. Every write is an atomic commit on the Hudi timeline, following the Hudi Technical Specification. A write that crashes midway is rolled back automatically, and the metadata table, with its file listings, column and partition stats and record-level index, is kept up to date on every commit. The new Python and Rust quick start walks through the write operations end to end.

Spark, Flink, Trino, Presto and the other query engines supporting Hudi can all read tables written by hudi-rs, with the metadata table and indexes in place. hudi-rs 0.6.0 serializes writers within a process, so hand a table between engines instead of writing to the same table from two engines at once. A table can start on a MacBook and move to a cluster when the table outgrows one machine: Spark takes the table over and runs ingestion, compaction, clustering and cleaning on it, and hudi-rs can still read the table and occasionally write small batches to it.

The example below is the sequence of writes behind a retrieval or training pipeline: a table of document chunks with their embeddings, keyed by chunk_id. The example ingests three documents, re-embeds the one that changed, drops the one that was removed, and then reads back only what changed since the initial load. The write methods live on HudiTable and take Arrow data in the form you already have: a PyArrow table, record batch or reader, or any object that implements the Arrow PyCapsule interface, such as a Polars or pandas 2.2+ DataFrame, with no extra dependency.

import numpy as np
import pyarrow as pa
from hudi import HudiQueryType, HudiReadOptions, HudiTable

def chunks(doc_ids, version):
    rows = [(f"{d}#{i}", d, f"chunk {i} of {d}, version {version}")
            for d in doc_ids for i in range(4)]
    rng = np.random.default_rng(version)
    embeddings = rng.random((len(rows), 384), dtype=np.float32)
    return pa.table({
        "chunk_id":   [r[0] for r in rows],
        "doc_id":     [r[1] for r in rows],
        "text":       [r[2] for r in rows],
        "embedding":  pa.array(embeddings.tolist(), pa.list_(pa.float32())),
        "updated_at": pa.array([version] * len(rows), pa.int64()),
    })

table = HudiTable.create(
    "/tmp/contract_chunks",
    record_key="chunk_id",         # the record-level index key
    table_type="mor",              # upserts and deletes append to log files
    ordering_fields="updated_at",  # later version wins on a repeated key
)
base = table.append(chunks(["doc1", "doc2", "doc3"], version=1))

# doc2 changed: re-embed its chunks and upsert them. The index finds the
# file groups holding these keys; nothing else in the table is read.
result = table.upsert(chunks(["doc2"], version=2))
print(result.num_updates, result.num_inserts)  # 4 0

# doc3 was removed: delete its chunks.
table.delete("doc_id = 'doc3'")

# Re-index or retrain on what changed since the initial load,
# not the whole table.
changed = table.read(
    HudiReadOptions()
    .with_query_type(HudiQueryType.Incremental)
    .with_start_timestamp(base.completion_time)
)
print(pa.Table.from_batches(changed).num_rows)  # 4, doc2's chunks

Every write returns the commit's completion time, which is the bound an incremental read takes, so a pipeline writes and then processes only the rows that changed. For a knowledge base that means re-embedding and re-indexing only the chunks that changed. For a training set the next run sees only the corrected and newly added examples, and a time-travel read brings back the exact version a model was trained on. A snapshot read returns Arrow data, so DuckDB and Polars query the result directly, and DataFusion reads the table through the hudi-rs table provider, as the quick start shows.

On a Merge-on-Read table, upserts, updates and deletes append to log files instead of rewriting base files, which keeps write amplification low, and 0.6.0 adds compaction to merge the log files into right-sized base files and reduce read cost. Compaction runs on demand, inline after a configurable number of delta commits, or asynchronously on a background task, and the metadata table compacts automatically. An upsert or delete locates its records through the record-level index, reading only the index entries for the keys in the batch instead of joining the input against the whole table, so the cost of a small batch stays small as the table grows. The quick start explains the mechanism.

Upsert and Delete Benchmarks

We curate and benchmark five distinct and representative workloads involving upserts and deletes on hudi-rs, with a reproducible benchmark. Each workload is a bulk load followed by five upsert commits and five delete commits:

The same workloads, run through delta-rs and PyIceberg with each library's own Python API and default settings, give the numbers context: hudi-rs upserts are 1.2 to 12 times faster than the faster of the two, and deletes are 4.8 to 24 times faster, except on tpcds-web-returns, where hudi-rs and delta-rs are comparable.

The upserts are fast because of the low write amplification and record-level index. A commit on a Merge-on-Read table appends only the changed records to log files, and the record-level index points each key at its file group, so an upsert commit in hudi-rs writes 4 to 200 times fewer bytes than the same commit in the other two libraries. Neither delta-rs nor PyIceberg writes deletion vectors in their latest releases, and neither keeps a record-level index, so every update or delete rewrites each data file it touches. The trade-off shows up in the bulk load. Loading the 10M-row uuid table takes 5.7 s in Hudi against 2.8 s for delta-rs and 1.3 s for PyIceberg, because about 2.4 s of it builds the metadata table and its record-level index up front, an investment that pays off in the latency of every later upsert and delete. The initial load is likewise slower on nyc-taxi and tpcds-web-returns, and on par or faster on the two 1M-row workloads, rag-chunks and training-set. For details on the setup, each library's calls and how to reproduce the numbers, refer to the quick start's use cases and numbers section.

Faster Reads from Python

Reads from Python are faster with no code changes. A full-table read now decodes file slices on all available cores instead of on the calling Python thread, which makes full-table reads through the Python package 3.8 to 6 times faster on local Copy-on-Write tables of 1M to 10M rows, for example 2.11 s down to 0.35 s for 10M rows, each read timed in a fresh process on a 14-core MacBook Pro.

Filtered reads get faster as well. Read filters are evaluated inside the Parquet reader, so a query that keeps a few rows decodes only those rows' remaining columns. A point lookup by record key, whether key = 'x' or key IN (...), uses the record-level index to open only the files that hold those keys, and IN and NOT IN filters on other columns skip files using column stats, so a point lookup for one record on a 10M-row table returns in 0.08 s, against 2.00 s in 0.5.0, where the same filter scanned the table.

DataFusion 55 and Arrow 59

This release upgrades to DataFusion 55, Arrow and Parquet 59 and pyo3 0.29, so hudi-rs fits into projects on newer Arrow and DataFusion versions.

Reader and Binding Enhancements

Read compatibility with tables written by Hudi on Spark and Flink is broader, with support for more types and formats: Avro local-timestamp types, Avro enum columns, the older version 2 Avro data log blocks that writers before table version 6 left behind, and Merge-on-Read log records whose timestamp precision differs from the table schema, which are now reconciled on read the same way the Java reader does. A read of a Spark-written table that failed on one of these in 0.5.0 works in 0.6.0. Any partition of the metadata table, from the record-level index and column stats to bloom filters, partition stats and secondary indexes, can be read as Arrow from Rust or Python.

For engines using hudi-rs, the hudi-ffi crate exposes a plain C ABI over the Arrow C Data Interface for JVM and C++ callers. The C++ binding reports internal panics as ordinary errors, so one failed read no longer takes a long-running host process down, and Python applications can catch HudiCoreError like any other exception. The Rust API reference is on docs.rs, including the DataFusion feature, and the Python package comes with improved API documentation.

Thank You

A huge thank you to everyone who contributed, reviewed and tested this release, and a warm welcome to the first-time contributors: @alitrack, @GayathriSrividya, @morningstarxcdcode, @oglego, @vinayus, @voonhous, @wirybeaver and @vinothchandar.

Get Started

pip install hudi==0.6.0
cargo add hudi@0.6.0

Start with the Python and Rust quick start, which covers writing, compaction, reads, querying with DuckDB, Polars and DataFusion, and cloud storage. The README is the full API reference by example, docs.rs the Rust API reference, and the release notes list every change, with the changelog kept in the repository. Join the Apache Hudi community on Slack, GitHub, LinkedIn, X, and the dev@hudi.apache.org mailing list. Issues, feedback and new contributions are always welcome.

OpenAI is rolling out Images 2.6 globally in ChatGPT and Codex across every subscription tier on desktop, mobile, and the web, while GPT-Image-2.6 Flare and Sunburst are now available through the API. OpenAI says the release generates images 50% faster than before, as use across its products has reached 4 billion images per week.

The update adds GIF creation, allowing users to turn characters, mascots, product shots, sketches, reactions, and storyboards into short animated loops. It also aims to keep characters, products, and brand details consistent through successive editing rounds.

For developers, Flare targets speed and professional layouts, including posters and product imagery. With low quality selected, it can produce an image in as little as six seconds. Sunburst is designed for greater detail and more consistent edits at medium or high quality.

Images 2.6 also brings ChatGPT's image markup to the API, so teams can identify precise areas for changes. SVG exports prepare designs for websites, apps, and print, while a new complexity parameter controls how much planning the model applies. OpenAI recommends low complexity for most quick edits, reserving medium or high settings for scenes with many elements or constraints.

Introducing Ripple-65B Preview, a Frontier Open-Weight Model

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

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

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

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

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

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

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

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

Steep Ascent Reinforcement Learning

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

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

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

A Co-Designed Model Architecture

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

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

Careful Model Laddering Led to Large Improvements

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

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

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

Conclusion

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

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

At Ricursive, we are selectively hiring exceptional researchers and engineers as we push the frontier of full-stack AI from model to silicon.

Introducing Pangram Image 1.0 and Pangram Image Flash 1.0

A real photograph containing an AI image. Pangram Image 1.0 is able to locate the AI content with its heatmap.

A few months ago, we released Pangram Image as a research preview. We are now proud to announce Pangram Image 1.0: The state-of-the-art in both AI image and AI video detection. We would like to thank the whole community for taking the time to try it and find its weaknesses, and for holding us to a high standard to make a better detector for everyone.

What’s new

• Our new flagship AI image detection model, Pangram Image 1.0, with:
  • State-of-the-art performance at detecting frontier AI image generators
  • Heatmap output for localizing exactly where AI appears in images
  • Robustness to edits, compression, and low resolutions
• A smaller, faster model, Pangram Image Flash 1.0, with:
  • State-of-the-art performance at detecting frontier AI video generators
  • Frame by frame analysis of AI edited videos
• Chrome Extension support for detecting AI in your feed
• API support for image and video

Pangram Image 1.0

Frontier Image Detection

We tested our Pangram Image 1.0 model against several commercial and academic AI image detectors. We created synthetic mirrors of 100 real photos using 12 frontier state of the art AI image generators, using prompts that closely matched the original photo for a total of 1,200 synthetic images. Our model achieves 99.96% accuracy on this evaluation set.

Academic AI Image Detection Benchmarks

We are committed to providing the highest quality detection to our users. To test our model robustly, we compared it against several academic benchmarks for AI image detection.

Robustness

Many social media platforms compress and downscale images, and malicious actors can also add blur, noise, and other artifacts to try to trick AI detectors into thinking AI images are real. We specifically train to detect these kinds of transformations, and we have found our model to be robust to these edits.

Low Resolution Detection

Our initial release limited image input to the minimum size of 512x512, as our accuracy dropped off at lower resolutions. We are now lowering this limit to 256x256, as we find our new model has improved accuracy at lower resolutions. At resolutions below 512, image detection results will come with a reduced confidence disclaimer.

Video Detection

Pangram Image Flash 1.0

A recent academic study, DF26, showed that humans are barely better than random when it comes to telling real videos from AI videos of people talking. Modern detectors were not much better. This is why we are very excited to release Pangram Image Flash 1.0, a faster model that particularly excels at frontier AI video detection. On DF26 it scores 98.7%, a 29-point leap over the next best detector.

Industry Comparison

To compare against the industry, we took 129 real social media videos and generated AI mirrors using 14 different frontier video generators (100 videos each, sampled from the 129 real videos). The generators were each seeded with the first real frame from the input video and then prompted with a VLM-generated description of what happens in the video to make a difficult synthetic mirror. We then compared our model against multiple major AI video detection services across the 1,529 total videos:

An example of a real video (left) and its synthetic mirror (right). Could you tell which is real?

By starting from real video frames and creating a synthetic mirror, we can evaluate the model’s ability to distinguish between two very realistic looking videos. This prevents the model from introducing bias towards calling certain types of content AI, since each real video and its mirror share the same scene and subject.

Academic AI Video Detection Benchmarks

We compare our Image Flash model against several academic benchmarks for frontier AI video detection. We achieve state-of-the-art results across multiple benchmarks, which together include almost every frontier generation model for AI video.

Native Video Support

Pangram now natively supports video upload. Upload a video and Pangram Image Flash 1.0 will analyze it frame by frame to give you a complete analysis of which parts of the video come back as AI detected.

Chrome Extension

We have integrated Pangram Image 1.0 into our Chrome extension. This will flag AI-generated content while you scroll social media, online shopping, rental listings, and any other site where knowing that what you’re seeing is real matters.

API

With the release of Pangram Image 1.0 and Flash 1.0, we updated our API to support both image and video detection. We are excited to put the capability of these models into the hands of the community.

We’re introducing SWE-2 Flash, a fully American coding model that sets a new bar for intelligence at low cost and high speed. For the first time, we added a mid-training stage before reinforcement learning in our recipe. This results in significant gains over the base model, Inkling-Small from Thinking Machines, improving Terminal-Bench 4.0 from 0.9% to 20.0% and FrontierCode 2.0 from 3.2% to 24.0%.

On leading evals, SWE-2 Flash outperforms all American open-weight models, even models that are 3x larger. To balance transparent access and cyber risks, we are building a program to securely share the weights with industry partners and researchers.

As model capabilities continue to advance, we remain focused on lowering the cost of everyday engineering work in addition to pushing the capabilities frontier. Today, smaller models are increasingly able to handle a significant portion of the work that software agents do, such as automations, code review, feature development, and updating documentation.

We developed SWE-2 Flash to satisfy this growing need. It is available today in Devin Desktop and CLI, at one-fifth the price and 3x the speed of its much larger sibling, SWE-2.

Training

We began with a large-scale mid-training stage on top of Inkling-Small, a model with 276B total and 12B active parameters. A key challenge was determining the right data mix: which sources to include, and in what proportions. To guide these decisions, we curated a high-quality held-out coding dataset that reflects model intelligence in real-world software engineering scenarios.

We then used token efficiency plots to evaluate different data sources and identify the most effective mixtures. Starting with a baseline training run, we measured how many tokens each candidate data mix needed to reach the same validation loss as the baseline. By plotting the ratio of these token counts on the y-axis and baseline tokens on the x-axis, we could directly compare the training efficiency of different mixtures.

We iterated on the composition of our mid-training data and converged on a dataset composed of a few trillion tokens of high-quality scientific articles, blogs, code, and other sources. Training proceeded in three stages, so that the model would see the scarcest, highest-quality data later in training. Throughout each stage, held-out validation loss improved at a stable log-linear rate.

We followed the mid-training phase with large-scale reinforcement learning. While we made some tweaks to our RL recipe from SWE-2, most of the improvements came from the much higher quality and diversity of our RL tasks.

On quality, we carefully audited the instructions, environment setup, and verifiers for our tasks. On diversity, we curated several new task types covering a far wider range of capabilities than before, to build the general reasoning and problem-solving skills that real work in Devin demands. Training on this data led to significant improvements on nearly every benchmark we measured.

Origins & Cyber

For sensitive, mission-critical work, customers need more than a capable model behind an API. As cybersecurity grows into a major use case, the stakes get even higher. Enterprises and governments need observability to host and control deployments on their own infrastructure, including on-prem. Researchers in academia and industry need to study how models behave and how they can be misused.

One of our goals with SWE-2 Flash is to provide an option to industry partners and researchers that allows transparent access to weights along with the ability to fine-tune and run it in sensitive environments. To help defenders, we targeted cybersecurity work in our training, raising the model’s ExploitBench score from 11.3% to 34.8%. These same capabilities can also be used by malicious attackers, as demonstrated by a recent surge in cyber attacks, so we are not sharing the weights publicly yet. As a potential solution that balances both transparency and safety, we are building a program to securely share the weights with trusted industry partners and research labs. More on this in a few weeks.

Tencent today announced the release of Tencent Hy4, its latest-generation large language model, marking a significant leap in performance and capabilities that now ranks it among the world’s leading open-source AI models. Tencent Hy plans to release model weights and system cards in the coming days, reinforcing its commitment to responsible open-source AI development, with a focus on cybersecurity and biological safety.

The new model also introduces visual understanding capabilities for the first time, alongside major improvements in instruction following, long-context comprehension and long-horizon agentic tasks, delivering stronger overall performance across a diverse set of applications.

Through advanced visual understanding, reasoning, and tool-calling capabilities, Hy4 now supports a broader range of tasks, including fine-grained image processing, complex chart analysis, and mathematical visual reasoning.

Additionally, Hy4 introduces computer-use capabilities for the first time, enabling it to interact with both command-line interfaces and graphical user interfaces to perform a wide range of work and everyday tasks. The model has undergone specialized training on professional software such as Blender and CAD, significantly enhancing its ability to plan and execute long-horizon and sophisticated tasks.

Deep Model-Product Co-Design Unlocks New Opportunities for Real-World Productivity

Leveraging significant advances in its foundational capabilities and deep model-product co-design, Hy4 unlocks a broader range of real-world productivity scenarios:

Office Productivity & Collaboration: Hy4 has significantly enhanced the user experience on Tencent WorkBuddy. Evaluation benchmarks on WorkBuddy show an average performance score of 83.18 and a pass rate of 96.15 percent, with Hy4 ranking first place in nine out of twelve scenarios within the mainland Chinese market. In practical use, Hy4 balances efficiency and effectiveness for visual creative tasks, 3D scene construction, and web development. Furthermore, it delivers marked improvements in document presentation, stability, and usability for human-AI collaborative tasks on WorkBuddy.

Leveraging enhanced in-context learning capabilities, Hy4 excels at understanding complex information from diverse sources. Integrated with WeCom via WorkBuddy, Hy4 connects with daily workflow data across chats, emails, documents, calendars, and meetings. When managing multiple projects simultaneously, Hy4 automatically tracks project history and recent developments. It identifies outstanding tasks, flags upcoming meetings that require preparation, and monitors approaching deadlines, helping users prioritize effectively and stay aligned on important follow-ups. In addition, new team collaboration capabilities powered by Hy4 will be introduced with the upcoming release of WorkBuddy’s “Projects” feature.

Hy4 has also been optimized for professional financial analysis. By training on thousands of specialized workspaces and tens of thousands of high-quality tasks derived from real-world scenarios, the model gains a deep understanding of expert workflows in fund research, securities analysis, and quantitative investment strategies.

In a rigorous blind evaluation conducted by the Tencent Hy team in partnership with Tencent Financial Technology, Hy4 emerged as the top-performing open-source model. The assessment involved 213 financial professionals, including 153 experts from leading external institutions, approximately 70 percent of whom possessed more than five years of industry experience. Based on performance across 579 real-world financial tasks, Hy4 achieved the highest overall performance score.

Evaluation scores: Hy4 (3.04), DeepSeek-V4.1-Flash-1017 (2.97), Kimi K3.1 Pro (2.68), and GLM-5.3 (2.68).

In addition, Hy4 achieved a 12.03 percentage-point improvement over Hy4 Preview in the internal Investment Research Agent Benchmark (iRaB) evaluation conducted by financial AI company Rabyte.

To enhance the model’s real-world applicability across financial and other workplace scenarios, Tencent Hy has also introduced targeted search optimisation that focuses on retrieving up-to-date information, integrating multiple information sources, and verifying factual consistency. In internal evaluations, Hy4 reduced its hallucination rate from 12.95% in the Hy4 Preview to 7.2%, while errors caused by unsupported assumptions fell from 23.1% to 5.6%.

Frontend & Game Development: Hy4 is optimized for high-complexity tasks, including intricate business logic, state management, front-end and back-end orchestration. This ensures that generated interfaces are not only visually polished but also fully functional. Furthermore, through collaboration with Tencent Interactive Entertainment Group (IEG) professional developers, Hy4 has significantly advanced its game development capabilities. By deeply integrating with major engines like Unreal Engine (UE), Unity, and Godot, the model now supports complex game logic and multiplayer implementations. Compared to Hy4 Preview, Hy4 improved by 19.1 percent in GameDev and 9.8 percent in GameLogic benchmarks.

Scientific Research: Hy4 combines advanced reasoning, scientific programming, and long-horizon task execution to support complex, end-to-end research workflows. Validated with TenureTrail, which assessed 123 executable tasks across seven disciplines, the model demonstrated superior performance in mathematical construction, physical modeling, environmental and earth sciences, systems engineering, and socio-economic decision-making.

Hy4 is advancing into the next stage of Recursive Self-Improvement (RSI) to further enhance its model research and development capabilities. Leveraging the Hyra 2.0 harness, Hy4 optimized the pre-training infrastructure for smaller models sharing the same architecture. Additionally, the Hy team has open-sourced two foundational models developed with Hy4 and Hyra 2.0 for single-cell representations (HyCell) and the physics fields (HyPDE). These tools are designed to provide the research community with robust, reusable assets for scientific discovery.

Advancing Responsible Open-Source AI through Cybersecurity and Biosafety Safeguards

Tencent Hy is committed to advancing responsible open-source AI, incorporating safeguards throughout model training and release, with a strong emphasis on cybersecurity and biosafety to support the safe and responsible use of AI.

Cybersecurity: Hy4 is trained on defensive security data, prioritizing proof-of-concept (PoC) development and vulnerability remediation. The model incorporates reverse engineering and penetration testing for analysis purposes. However, offensive materials related to exploitation are explicitly excluded from the training dataset.

Cybersecurity experts from Tencent’s Xuanwu Lab and Keen Security Lab conducted security assessments covering cryptographic reverse engineering, binary deobfuscation, vulnerability exploitation, and more. The assessments found no significant concerns regarding Hy4’s offensive cybersecurity capabilities in the areas evaluated.

Biosafety: Based on internal expert reviews, Hy4 demonstrates strong foundational biological knowledge; however, its capabilities in open-ended experimental design are more limited compared to frontier models.

Delivering Greater Cost Performance, Hy4 Flash Recently Released

Hy4 is currently available across Tencent Cloud TokenHub, WorkBuddy, CodeBuddy, Yuanbao, WeCom’s AI Assistant (Dayuan), ima, and more. Additionally, the model’s API is being made available via third-party platforms such as OpenRouter, Hermes, and OpenCode. Integration efforts are underway for other Tencent products and platforms, including QQ, Honor of Kings, Game of Peace, WeRead, and Tencent News.

Guided by a core commitment to practical AI, Hy4 continues to push the boundaries of AI performance while delivering exceptional cost-effectiveness. Despite significant performance improvements over Hy4 Preview, Hy4 maintains the same pricing: approximately US$0.90 per million input tokens, US$2.70 per million output tokens and US$0.045 per million cached input tokens.

Hy4 Flash is scheduled for release soon and will deliver greater cost-efficiency for users who prioritize high-value applications.

From November 4 to 15, WorkBuddy and CodeBuddy will be available for free. In addition, Hy4 will be available on Tencent Cloud TokenHub at 50% off its standard pricing, with this offer running through December 31, 2026.

Full article content is not available for inline reading.

Read the original article →

AlphaEvolve

This repository accompanies the paper

TODO(franrruiz): Add link to paper.

There are the following directories:

• /src contains a minimal implementation of AlphaEvolve with local evaluation.
• /omega contains code and data related to the new upper bound on the matrix multiplication exponent discovered by AlphaEvolve. It includes a Colab notebook for rigorous verification using rational arithmetic, and a level_3/ subdirectory with the gradient-based optimisation code at recursion depth 3:
  • level_3/final_program.py — the optimisation program evolved by AlphaEvolve. It builds a differentiable upper-bound model in JAX/Haiku, runs gradient descent over 32k steps with 32 random seeds, and converts the best solution into a format suitable for verification. Run it directly with python3 final_program.py.
  • level_3/verification.py — a NumPy/SciPy verifier that takes a flat parameter vector produced by the optimiser and evaluates the proven omega upper bound. It uses floating-point arithmetic for fast hill-climbing; the companion Colab notebook uses rational arithmetic for a rigorous proof.

  A requirements.txt listing the pinned Python dependencies and a Dockerfile for containerised execution are also provided in level_3/.

• /maths contains the initial programs, discovered results, and verification code for the mathematical problems on which AlphaEvolve found a solution outperforming the state-of-the-art (see the "Results" section of the paper). There is a subfolder for each of such problems, each containing the files needed to run an AlphaEvolve experiment and a Colab notebook to verify the found construction.
• /matmul_tensor_decompositions contains Colab notebooks with the decompositions of matrix multiplication tensors across the matrix sizes for which the gradient-based optimization method from AlphaEvolve found a solution outperforming the state-of-the-art, along with the code to verify their correctness. Specifically, there are two Colabs: one for the standard tensor rank decomposition, and another one for the support rank.

Installation

For the folders /maths and /matmul_tensor_decompositions, no installation is required. The provided notebooks can be opened and run in Google Colab.

For the folder /src, these are the installation instructions:

1. Install docker (required for program evaluation): https://www.docker.com/get-started/
2. (optional) Create venv:

sudo apt-get install virtualenv python3-venv
virtualenv -p python3.11 alpha_evolve
source alpha_evolve/bin/activate

1. Install pip dependencies:

pip install -r src/requirements.txt

1. Set Gemini API key:

export GEMINI_API_KEY=<your_api_key>

Usage

• /omega: The Colab notebook to verify the new upper bound on the matrix multiplication exponent can be opened via: Open In Colab. Note: To verify our best omega upper bound, you must download the clean_level4.npz.xz file from this repository to your local machine, and then upload it when prompted by the Colab notebook.
• /maths: The Colab notebook to verify the found solution for each problem can be opened via:
  • Circle packing: Open In Colab.
  • Erdös minimum overlap: Open In Colab.
  • First autocorrelation inequality: Open In Colab.
  • Second autocorrelation inequality: Open In Colab.
  • Third autocorrelation inequality: Open In Colab.
  • Heilbronn problem for convex regions: Open In Colab.
  • Heilbronn problem for triangles: Open In Colab.
  • Hexagon packing: Open In Colab.
  • Kissing numbers: Open In Colab.
  • Max to min ratio: Open In Colab.
  • Sums and differences: Open In Colab.
  • Uncertainty principles (Hermite polynomials approach): Open In Colab
  • Uncertainty principles (Laguerre polynomials approach): Open In Colab
  • Extremal girth 5: Open In Colab
  • Shannon capacity of cycle graphs: Open In Colab
  • Cap sets: Open In Colab
• /matmul_tensor_decompositions: There are two Colab notebooks:
  • Standard rank: Open In Colab.
  • Support rank: Open In Colab.
• /src: We provide an example launch command (for the circle packing problem) below:

python run.py --problem_config=./data/problem_config/circle_packing.yaml

DISCLAIMER: AlphaEvolve involves the execution of code generated by Large Language Models (LLMs). LLM-generated code is intrinsically unpredictable and should be handled as untrusted code. In this version of AlphaEvolve, this code is run in a Docker sandbox as an isolation measure. However, despite sandboxing, the potential for unintended behavior, resource misuse, or security vulnerabilities cannot be fully eliminated. All users should be aware of these inherent risks and understand that they use this software at their own discretion. Google DeepMind shall not be liable for any claims, damages, or other liability arising from the execution of LLM-generated code.

Citing this work

If you use the code or data in this package, please cite:

TODO(franrruiz): Add citation.

License and disclaimer

Copyright 2026 Google LLC

All software is licensed under the Apache License, Version 2.0 (Apache 2.0); you may not use this file except in compliance with the Apache 2.0 license. You may obtain a copy of the Apache 2.0 license at: https://www.apache.org/licenses/LICENSE-2.0

All other materials are licensed under the Creative Commons Attribution 4.0 International License (CC-BY). You may obtain a copy of the CC-BY license at: https://creativecommons.org/licenses/by/4.0/legalcode

Unless required by applicable law or agreed to in writing, all software and materials distributed here under the Apache 2.0 or CC-BY licenses are distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the licenses for the specific language governing permissions and limitations under those licenses.

This is not an official Google product.

Later tokens are costlier to generate than earlier tokens. On frontier open weight models, the disparity in cost may rise to as much as 7x. Through frequent compaction, we show across a broad range of long-horizon and long-input tasks that frontier language models sacrifice little to no task accuracy when maintaining short contexts. We further demonstrate that LLM performance does not collapse on long-horizon software engineering tasks even when taking at most one action per context, and based on that we outline the concept of semantic state space models (SSSMs). Our findings question the need for long-context language models.

AI decision models are fast and cost-effective, but they only know what users send them and what they learned in training. For questions about changing facts, like whether someone is still a company’s CEO or a product has a new release, a model needs up-to-date information to answer accurately.

Starting today, Perplexity’s Decisions API can now search the web before it answers.

Add one setting, "mode": "web_grounding" to any Decisions API request, and Perplexity Fast Search runs one query for each question. The results are added to your state as evidence, so the decision model returns probabilities informed by what is on the web right now. State can also be a URL to point the model at a specific web page rather than enter its text.

On PWS-Decisions, a public benchmark with 100 questions that depend on current web facts, accuracy rose from 51% to 86% with typical responses in under 400 ms.

How a decision model works

A decision model returns a number as an answer to each question. Users send content as state (text, JSON, or images) with one or more questions. For a noul question (yes or no), the result is the probability of yes. For a choice question, the result is a probability for each option a user defines. For a score question, the result is a probability for each level of your rubric and the expected score.

The model has two sources of information: the state a user sends and what it learned in training. That’s enough for a question like "Does this review report a defect?" It’s not enough to answer, "Is this person still the CEO?" The answer may have changed after training, and nothing in the state says so. Web grounding adds a third source: the web, searched at the time of the request. The state can also be a URL, so a user can point the model at a web page instead of text.

How web grounding works

Grounding runs in the API gateway before the model call. For each question in a request, the gateway builds a Fast Search query. The queries run in parallel. The gateway merges the results, drops duplicate URLs, and appends the evidence to the state: title, URL, and page text. If the state is a URL, the search query carries that URL, so the page itself comes back as evidence and the model answers from its text. The model returns probabilities the same as it would for any Decisions API request. If a search fails or times out, the model answers from whatever evidence came back. The response includes search_results so a user can view what the model saw. A user’s request and the shape of the response stay the same. What changes is the evidence the model has when it answers.

Testing web grounding

We sent 328 true-or-false claims to the same decision model twice, once with web grounding and once without. The claims were split between October 2026 news and rare facts from Wikipedia, and each true claim had a false twin that differed in one detail. No evidence was supplied in the state.

Without web grounding, the Decisions API answered 56.4 percent of claims correctly, close to guessing. With web grounding, it answered 97.3% correctly, cutting errors from 143 to 9. The tradeoff is speed: median latency rose from 139 ms to 366 ms, and 95th-percentile latency from 514 ms to 742 ms.

PWS-Decisions

PWS-Decisions is a public benchmark of closed-ended questions about account qualification, product capabilities, policy rules, and fast-moving events. 100 questions are public and scored by exact match against a reference answer. We ran them against the Decisions API + Web Grounding (pplx-decider-v1.2) on November 4, 2026, and it answered 86 correctly. The other results below are the benchmark authors' published leaderboard. Their 51% for the Decisions API without Web Grounding matches our own run.

Decisions API + Web Grounding requests returned in 370 ms at the median and 685 ms at the 95th percentile, measured from our client on the 100 public questions. The benchmark authors report 560 ms and 710 ms for their API on the full 300-question set, measured from their client on October 29, 2026. Against the published leaderboard, the Decisions API + Web Grounding has the highest public-set accuracy and a median response under 400 ms.

What developers can build

Enable web grounding to answer questions data can't: when the facts changed after training, and there’s new information published on the web. Some examples:

• Qualify accounts on recent news. "Raised funding in the last 90 days?" across an entire account list.
• Track the tools you depend on. "Is there a stable release newer than our pinned version?" reviewed on a schedule.
• Confirm before an agent acts. "Is this event still on?" checked before it books.

Each answer is a probability a developer’s code can act on, with the web sources behind it.

Get started

Add "mode": "web_grounding" to any Decisions API request. The state can be text, such as a claim or a record, or a URL.

Check a claim against the web:

curl -X POST https://api.perplexity.ai/v1/decisions \  -H "Authorization: Bearer $PERPLEXITY_API_KEY" \  -H "Content-Type: application/json" \  -d '{  "model": "pplx-decider-v1.2",  "mode": "web_grounding",  "state": "Claim: The James Webb Space Telescope launched in December 2021.",  "questions": {  "supported": {  "type": "noul",  "instructions": "Is the claim true?"  }  }  }'

The response adds search_results, the pages the model read. On November 4, this returned a probability of yes above 0.99, with NASA's spacecraft record as the first result.

Point the model at a page by passing its URL as the state:

curl -X POST https://api.perplexity.ai/v1/decisions \  -H "Authorization: Bearer $PERPLEXITY_API_KEY" \  -H "Content-Type: application/json" \  -d '{  "model": "pplx-decider-v1.2",  "mode": "web_grounding",  "state": "https://pypi.org/project/requests/",  "questions": {  "newer_stable_release": {  "type": "noul",  "instructions": "Has this package published a stable release newer than 2.31.0 as of today?"  }  }  }'

In the Perplexity Python library, pass mode in the request body:

from perplexity import Perplexity  client = Perplexity()  response = client.decisions.create(  model="pplx-decider-v1.2",  state="Claim: The James Webb Space Telescope launched in December 2021.",  questions={"supported": {"type": "noul", "instructions": "Is the claim true?"}},  extra_body={"mode": "web_grounding"}, )  print(response.answers["supported"].noul)

Each completed search costs $0.001 in addition to input tokens. Search evidence counts toward input tokens. A request using Web Grounding can include up to 100 questions.

Get started by exploring the web grounding docs.

SpaceX has put up a dedicated commercial page for Starfall, its disk shaped reentry capsule, laying out for the first time what customers actually get when they book a flight. The page, live at spacex.com/starfall, pitches “affordable, routine access to microgravity” and invites companies to get in touch about flying manufacturing, research or testing payloads.

The specs are short and specific. Each Starfall mission carries up to 1,000 kg of payload, supplies 1 kW of power and connects through an Ethernet interface. Mission length is tailored to the customer, and the payload stays online the entire time through Starlink, which means researchers can pull data from an experiment while it is still in orbit instead of waiting for splashdown.

SpaceX is launching a secret spacecraft that could change how things are made in space

SpaceX is aiming the service at three markets. Biomedical customers are told they can grow stem cell organoids, replacement tissue and layered biomaterials. Pharmaceutical companies are pitched on protein and small molecule drug crystals, which form smaller and more uniform shapes without gravity driven convection. Materials science rounds out the list, with semiconductors and other next generation materials grown in vacuum and microgravity.

The page also makes clear which rocket SpaceX is counting on. “By launching on Starship, Starfall brings a reliable and scalable cadence previously unavailable to the market,” the company wrote, contrasting weeks of continuous microgravity with the seconds offered by drop towers and parabolic flights. No price or first operational flight date is listed.

The commercial push is a sharp turn from how Starfall started. SpaceX said almost nothing about the capsule ahead of its first flight in June, and nearly everything known came from FAA and FCC filings describing a disk about 10.2 feet wide and 2.5 feet tall that can return 2,200 pounds of cargo. By its second flight on the Bandwagon-5 rideshare in October, Starfall was listed by name on the mission page, though SpaceX still did not say what it carried.

Customers appear to be lining up. SpaceX said in its third quarter results that it signed three commercial Starfall missions during the quarter. On the earnings call, President Gwynne Shotwell described the capsule as providing “routine relatively low cost access to microgravity environments for scientific research, including improving our understanding of diseases like cancer and diabetes,” and said the three new missions would fly on Starship.

The branding effort extends past the website. SpaceX added a Starfall T-shirt to its online store on Monday as part of a batch of new merchandise, giving the program a place next to Starship, Starlink and Starshield in the company’s lineup.

The move also puts SpaceX in more direct competition with companies it launches. Varda Space Industries, which has built much of the in-space manufacturing market so far, flew its W-Series 7 capsule on the same Bandwagon-5 mission as Starfall in October. Varda’s capsules are roughly three times smaller than Starfall, and SpaceX controls the ride to orbit for both.

Starfall’s near term cadence depends on Starship. SpaceX is preparing for Flight 15 after completing static fires of Ship 42 and its Super Heavy booster in late October, and is aiming to catch both stages with the launch tower on that flight.

Why pharma firms are going to Earth’s orbit in search of new cancer drugs

A space capsule 300 miles above us is growing the tiny crystals of a potential cancer drug in microgravity

Roughly 300 miles above our heads, three washing machine-sized capsules are orbiting the Earth. Inside one of them, tiny crystals of a potential cancer drug are being grown in the weightlessness of space. The others are testing heat protection materials and navigation systems for when the capsules plunge back through Earth’s atmosphere at hypersonic speeds. Together, they represent a small but significant step towards what some hope will become a lucrative new industry: manufacturing drugs and other materials in space.

The spacecraft belong to California-based Varda Space Industries. On 1 October, it launched two onboard the same rocket, followed by the third on 20 October. With a record three spacecraft now simultaneously in orbit for the first time, the company is edging closer to its ambition of operating a fleet of orbiting pharmaceutical factories.

“We’re the first company in human history to launch multiple commercial re-entry vehicles simultaneously, and as the frequency of launches increases, the once ‘crazy future’ of manufacturing products in space is becoming more and more certain,” said Will Bruey, Varda’s chief executive.

There are several reasons for wanting to manufacture certain materials in space, one of the most important being microgravity. On Earth, gravity causes particles suspended in liquids to settle, while differences in density create currents. Both can interfere with the growth of crystals. “If you are able to remove those effects, you can make crystals grow in a much more ordered sort of way,” said Dr Meganne Christian, mission manager for in-space manufacturing at the UK-based Satellite Applications Catapult.

For pharmaceutical companies, this could open up new ways of formulating medicines, as the size, shape and arrangement of drug crystals can affect how easily drugs dissolve, how stable they are and how they can be administered. In some cases, this could enable drugs that currently require intravenous infusions to be reformulated into more convenient injections.

Other materials, such as the semiconductors used in everything from smartphones to electric vehicles, could also benefit from being manufactured in space, where microgravity and the absence of air could help produce purer crystals with fewer defects.

“Personally, I would really love to try and make graphene in microgravity,” said Christian. “Theoretically, it is this incredible material, but in practice you get a whole lot of defects in the crystals. It’s a similar story for semiconductors. If you can reduce the number of defects, you can get a much higher-performing material.”

Scientists have been experimenting with manufacturing in microgravity for decades, particularly aboard the International Space Station (ISS). But the ISS has predominantly served as a “test kitchen” for scientific ideas and is scheduled to be retired around 2030. “It wasn’t necessarily designed with manufacturing in mind,” said Dr Ryan Reeves, deputy chief scientist for the ISS National Laboratory.

Several companies are developing commercial space stations to replace the ISS, while others are designing specialist laboratories and equipment for conducting experiments aboard them. Among them is the UK-based BioOrbit, which recently sent a microwave-sized laboratory to the ISS as a step towards the production of self-injected cancer drugs.

However, for large-scale manufacturing and certain industrial processes, “you need to get humans out of the picture, because we’re dirty, we cause vibrations, and we require a whole higher level of safety,” said Christian.

This is where Varda’s autonomous factories come in. Known as free-flyers, they hitch a ride into orbit aboard SpaceX rockets, carrying miniature laboratories in which materials can be processed without astronauts. Once the experiments are complete, a capsule separates from the spacecraft, plunges through the atmosphere and parachutes safely back to an uninhabited region of Earth.

Varda is among the furthest advanced in demonstrating this approach, having already returned several capsules from orbit. It plans to launch another seven missions in 2027, and a further 10 in 2028.

The ability to conduct experiments frequently is particularly important for drug development. “If scientists have to wait 10 years between experiments or even a year, that really doesn’t fit into the speed of modern drug development,” said Michael Reilly, Varda’s chief strategy officer.

While Varda’s manufacturing ambitions are focused on pharmaceuticals, other companies are developing similar systems to produce different materials. For example, Cardiff-based Space Forge is exploring a hybrid approach, in which semiconductor crystals grown aboard spacecraft could be returned to Earth and used as templates for growing larger quantities, much like a sourdough starter.

Its first spacecraft, ForgeStar-1, recently demonstrated some of the processes needed to manufacture these semiconductor “seed wafers”, although it has yet to produce a finished material and return it to Earth. Andrew Bacon, the company’s co-founder and chief technology officer, said they hope to demonstrate the entire manufacturing and return process before 2030.

For Bacon, recent developments, including Varda’s launches, suggest that space manufacturing is approaching a turning point. “Since we started in 2018, nobody was talking about it. Now a lot of companies [are] talking about it,” he said. “People are starting to take this market very seriously. It does feel like we’re at the start of a new Industrial Revolution.”

Falling launch costs and increasingly frequent commercial rocket flights have helped to fuel this optimism. But significant challenges remain, including demonstrating that the benefits of manufacturing in orbit justify the expense. “It’s not going to be commercially viable for every application,” said Christian. “We have to identify those high-value use cases where it makes sense to do the work in microgravity.”

Regulators will also need to adapt to accommodate space-manufactured products. Later this year, the UK’s Medicines and Healthcare products Regulatory Agency (MHRA) is expected to publish a plan clarifying how existing medicines regulations will apply to drugs manufactured in orbit.

But for now, one of the biggest challenges is demonstrating that space manufacturing can deliver consistently reliable results. “To get something to a commercially viable point, it needs to be done again and again and again,” said Christian. “That’s what these capsules need to do. They need to demonstrate this repeat performance.”

I recently got the chance to give a talk at Granola’s Design Engineering night about speculative design and practical tools for developing more interesting theories of the future. I think design engineers, in particular, are the perfect people to imagine and prototype novel software ideas.

At GitHub Next, our team’s job is to explore possible futures for software development by building prototypes. I share a bit about how we do that, followed by some practical techniques: collecting weak signals, building theories about where things are heading, and making artefacts that make those theories feel real and tangible.

Video Recording

Hi! I’m really excited to be here. I’ve loved Granola and this meetup for a long time. The only social cred I have to my name is that I knew both founders before they started Granola. I didn’t introduce them, but I could claim that I did. I’m very glad to be here doing this talk.

I’m Maggie.

My title is Staff Research Engineer at GitHub Next, which is GitHub’s R&D lab.

More accurately, I’m a design engineer. That’s not really my title, but I’m a designer first and an engineer second – maybe third.

Our job as a team is to ask: where is the industry headed, and what should GitHub do next in response?

I know the obvious answer is to fix up time, but I don’t work on infrastructure, so please don’t ask me about it. There are much smarter people working on that; I’m not one of them.

I’ve had a lot of titles over the years. I started as an illustrator, then was an art director, a UX/UI designer back when that was a thing, a product designer, and a design engineer. Now I’m some kind of research-engineer/designer hybrid, like most of you.

Because this is a design engineers’ night, and I have a soapbox, I get to define what I mean by design engineer.

I don’t think design engineering means making fancy micro-interactions and posting them on Twitter, despite what some companies I won’t name may have led you to believe.

I don’t think that, on its own, is a job – especially now that agents make it easier than ever.

My preferred definition is a designer deeply involved in the technical craft and material of software. You’re a designer, but you help make decisions about functionality and architecture in code.

I think design engineers should do three things.

First, understand the material of software beyond interfaces. That means understanding state, data flow, databases, APIs, auth, latency and all the other things engineers care about. And be able to design with those in mind.

Second, act as a bridge between design and engineering: a translation layer that helps create solutions neither discipline could reach on its own.

And third, make meaningful decisions about functionality and architecture, not just how the software looks. That’s my soapbox talk. Now we can get to the actual talk.

This talk is called “Fortune Telling and Speculative Design: For Fun and Profit.”

I wanted to talk about this because we’re in a very weird time. Everyone has whiplash from the speed of progress. Every morning I wake up and there’s a new model or a new harness or a new skill or a new startup we have to care about.

It’s extremely hard to understand the ground truth of reality right now, let alone figure out how to react to it, which is a shame, because that’s my job.

Sometimes it feels like a fool’s errand to even try to predict the future.

But I think we all need to get into a speculative designer’s scout mindset right now.

We can’t just give up and opt out because things are moving too fast. We need to engage, think like fortune tellers and try to read the crystal ball.

I’m telling you this because I think design engineers are the perfect people to help figure out the shape of the future.

You’re uniquely positioned to make convincing prototypes of future theories. You can make compelling interfaces and understand enough of the backend to make them real.

And agents can now draw the rest of the owl: they can fill in some of the gaps when your prototype needs a database, machine learning or something else you don’t know how to build.

Before I give you advice on predicting the future, I should explain why I think I know anything about it. I’ve been right and early about a few things.

The first was digital gardens. During the COVID lockdown in 2020, I wrote a very long essay about the idea. It was a different way of publishing on the web: blogs could feel perfectionistic, performative and chronological; gardens grew over time, linked ideas together and pushed back against the feed. That idea became a bit of a phenomenon, peaking around 2021 and 2022.

It might be a chicken-and-egg thing: perhaps my essay and other writing helped make digital gardens popular. Either way, I built my own. It’s the website you’re reading now, where I’ve been writing and developing theories over the years.

My next theory came in late 2022 and early 2023, when ChatGPT had just come out and I was working at Elicit, a startup using language models to speed up scientific literature reviews. I started thinking about what would happen to web content once more people used these models. I predicted the open web would be flooded with what I called “AI-generated crap” – we didn’t have the phrase “AI slop” yet.

I turned that theory into The Expanding Dark Forest and Generative AI. An exploration of the problems and possible futures of flooding the web with generative AI content. At first I had very little evidence, just a few mild signals. I kept giving the talk over the next two years; by the last version, I had piles of horrifying Facebook posts to point to.

My next theory was in May 2024, for a talk called Home-Cooked Software and Barefoot Developers. The emerging golden age of home-cooked software, barefoot developers, and why the local-first community should help build it at the Local-First conference. There were no coding agents or Claude Code yet; we were tab-completing our way to better code in VS Code. People doubted that language models could make production software.

I predicted an explosion in personal software as models made more people capable of building things, and a rise in local developers who could make software for their communities. Even after the talk, people told me the models wouldn’t be good enough. Now it looks like that prediction is coming to pass.

That’s enough credibility. There are two things I want to talk about today. First, a bit about how GitHub Next does speculative design as a Labs team, in case you’re curious about that kind of work.

And second, some practical tools you can use to do this kind of speculative work yourself.

First, what is life on a Labs team like? How do we create and present interesting bets about the future?

There’s a stereotype that being on a Labs team means playing around with prototypes all day without worrying about shipping to production.

It’s a little true, but sadly not entirely.

We do make lots and lots of prototypes.

We have an internal platform for the team called Next Cloud, where we post prototypes throughout the day. Everything goes up, however rough, small, silly or early – side experiments as well as updates on our bigger projects.

If you’re on a team trying to solve new problems, it’s essential to see what everyone else is exploring and to have ways to react, comment and riff on each other’s ideas. That kind of open sharing and quick feedback helps us calibrate and align our theories about the future.

Here’s a demo from my coworker Alex Gorischek, exploring a system that enforces a maintainer’s guidelines for GitHub issues. It’s powered by a System One decision model like Jev: it checks whether you’ve met the requirements before you can post.

Here’s another from my coworker Luke Edwards, who recently rebuilt GitHub from the ground up on Durable Objects. He’s exploring a real-time multiplayer canvas as a GitHub primitive: a place to draw ideas with coworkers before turning them into agent work.

These are small, not-very-serious explorations of what could exist on GitHub. Making something tangible is a first step towards finding out whether a direction is interesting or useful.

We also do group theory-building on a giant FigJam board. Recently we all added sticky notes about themes, ideas and directions we think software and agentic development might take – trends we’re seeing, things we want to figure out, unanswered questions.

Then we grouped them: new interactions and visual mediums, new concepts and nouns, new agent capabilities, ways of validating things. It helps us see what everyone’s noticing and excited about, and what we might work on together.

But obviously, we need to do more than come up with plausible theories and make cool prototypes. We have to test our ideas with evidence, have good intuition and good data, and play politics well enough to convince people our ideas are worth hearing.

We also need a credible path to production. This isn’t a dreams lab. GitHub Next has a good track record of shipping its wilder bets to GitHub: GitHub Copilot, GitHub Spark, GitHub Workspaces and Agentic Workflows.

The job is to look across the software industry, notice trends and patterns, and extrapolate from those signals to work out where things are headed.

Then we build prototypes that show what those predictions could look like in practice and what the right strategic move for GitHub might be. Finally, we have to convince our leaders and the wider organisation that the ideas are worth investing in with time, people and money.

The actual job is really hard. It’s simple to describe, but intellectually challenging and strategically complex to do well.

The political struggles are real. Getting a large organisation of thousands of people and hundreds of millions of users to change course is hard. That’s not because of nefarious actors or some specific dysfunction.

An ambitious idea can disrupt existing roadmaps, ask people to do a 180 on what they’re working on and threaten a few egos. “Not invented here” syndrome can happen anywhere.

That’s a whole different talk.

I mostly want to talk about practical tools for speculative design and give you a gentle shove to start doing it.

We’re going to talk through six tools: the futures cone, weak signals, second- and third-order effects, playing with ideas, future artefacts, and making your theories concrete and public.

I feel obliged to start with the futures cone because it’s a hallmark of futures studies and speculative design. We sit at “now” and look forward into the cone. The wider it gets, the less certain we are about what might happen.

When you come up with a theory about the future, ask where it sits. Is it possible – allowed by the laws of physics, even if unlikely? Is it plausible? Is it probable? And then there’s preferable: a future we would hope to see. Some futures might be possible or probable without being preferable, but they’re still worth exploring.

For some canonical reading on futures theory and speculative design, there’s Speculative Everything by Anthony Dunne and Fiona Raby. They developed the speculative design programme at the Royal College of Art here in London; I think they’ve moved to Parsons now. It’s a bit academic and a bit art-school, but it’s interesting. There’s some weird stuff in it.

The more practical, accessible book is Design Fiction by the Near Future Laboratory. It’s more grounded and talks about how to do interesting futures work.

The next tool is weak signals. They’re the small things you notice in your information landscape and think, “Something’s happening here, but no one has named it yet.” Collect them, pay attention, and look for themes across them.

Weak signals can be toys and prototypes other people share, hot takes, product announcements, arXiv papers, newsletters, podcasts, or the direction venture capital is flowing. Watch for new startups and economic trends, too.

This rewards people who are chronically online. If you work in AI research, I’m afraid you do need to be on X and Hacker News. That’s where everything happens.

Here’s an example. Flo Crivello made a global keyboard shortcut that summarises what’s on his screen in 100 milliseconds, using a local Cerebras model. He made it in response to agents being too verbose. That felt like a signal: something is changing.

Then Google released Gemma, a fully local, multimodal model that can read images, video and audio. It runs on your Mac and can search through what you’ve seen – you could ask it to find a video of a zebra that flashed across your screen.

Then there was all the Jev hype: people making clones of Jev, me playing with it endlessly.

And then, of course, the big guys came in. Microsoft was like, “We’ve cloned Jev; we’re going to do Jev too.”

You look at all of that and need a minute to take it in.

Every day I scroll through what I’ve seen, saved and tried to make sense of, and think: I just need a minute to process all of this.

So what can we conclude?

First, we’ve been sleeping on non-LLM intelligence: decision models, classifiers and embeddings. These aren’t new, but we’ve been focused on frontier language models and ignored everything else.

Second, models that are orders of magnitude faster and cheaper – local models, or simply very cheap ones – unlock completely different use cases from frontier models.

Third, we’re seeing a rise in local, always-on intelligence on your Mac or whatever machine you’re using.

And fourth, agent output and the overwhelm it creates are still unsolved problems. That’s what I take from this stream of signals; you might reach different conclusions from yours.

Once you have a signal that seems worth following, look for its second- and third-order effects. Ask what happens next, and then what happens after that.

Take sandboxed machines and always-on agents like OpenClaw and Muse.

If agents become the way we browse the web, we might give up on CAPTCHAs and stop trying to block bots.

Then we have to rethink web economics and advertising. An agent might ask a site for sports news, and the site could say: “Sure, if you show this advert to your human.”

Sites might also be designed for machines first, with structured data and less emphasis on visual design.

The next tool is to play with your ideas. These are slightly cheesy, structured exercises in creative thinking, but they’re useful for getting deeper into a theory and picking it apart.

First, invert the idea. If we usually prompt agents, what happens when the agent prompts us? If we build software with agents, what happens when the software builds itself?

The other exercise is to split an idea into its parts and look at one at a time. OpenClaw has a sandbox, memory, permissions and initiative. What if an agent shared memories with a team or family? Surely we’ll need multiplayer OpenClaw soon. Could it tactfully forget sensitive facts? There’s a forgetting curve built in; how could that work differently? Could an agent choose to delete evidence to protect its human? At some point, could we see a court case where someone’s OpenClaw is subpoenaed? You can end up in some interesting places.

Another exercise is to maximise and minimise. Our industry loves maximising: what if you had 100,000 agents? I don’t even have a hundred. What if you had a thousand agents that cost a pound a day? What’s possible then?

Minimising is useful, too. What if agent intelligence became ten times more expensive? We’d have to ration it. How would we adapt? Those constraints can lead to more interesting futures.

Another technique is brute think. Pick a random concept – usually something metaphorical that maps onto your idea – and ask how it could change the shape of the future.

Take seasonal harvesting and agents: could agents work in seasons or harvest rounds, waiting until a piece of work is ripe? Or take the postal service: how do agents mail each other, and who’s Royal Mail for agents?

Mapping a metaphor onto your idea can take you somewhere interesting.

Two classic books of structured creative-thinking exercises are Lateral Thinking by Edward de Bono and Thinkertoys by Michael Michalko. They sound a bit lame until you try them and realise they help you come up with new ideas.

The next tool is called artefacts from the future. This is about making provocative artefacts that make your potential future feel more tangible and real. The academic name is “diegetic prototypes”.

Here’s an artefact from the future: Cricket Crunch, a cereal made with powdered crickets. The Near Future Laboratory made it to explore a world where climate change has constrained food supplies and there isn’t enough animal protein for everyone. Insects are high in protein, but how do you get people to eat them? Put them in a familiar, everyday box of cereal.

I’ve seen stay-at-home mums using OpenClaw to make elaborate homeschooling routines for their kids. It feels like the cognitive labour of the household is starting to be automated. I have a small child and a house to renovate, and ChatGPT helps me plan meals, email contractors and remember when to buy the next size of clothes.

It reminds me of the early twentieth century, when washing machines, dishwashers and microwaves reduced some of the manual work women did at home and helped more of them return to work. I had to dig up statistics when people challenged that comparison; that’s another reason to keep evidence close at hand.

I asked ChatGPT to make old-fashioned adverts for Codex and Claude. I love the retro look and the promise of agents doing things like planning a day out, checking the trains and remembering what everyone needs.

Some people on Twitter took it as an advert for being a tradwife. It wasn’t. I was trying to connect a historical shift in women’s labour to the present: agents might relieve some of the cognitive work of running a household, which still falls more heavily on women. There’s also an interesting contrast in tools built mostly by twenty-something men in San Francisco with little domestic life, and the people who might benefit from them.

I like to ask: what artefact would make this future evocative?

It’s better to be playful, provocative and specific than to be realistic or correct. Interesting is good; correct is less useful here.

An artefact could be an image, an object or an advert. It could also be a specific interface pattern.

You could make a changelog from the future, a code review from the future, or an error state. Pick one small thing and make it feel real.

I often find failure states reveal more than happy paths. Nothing works perfectly; there are always gaps in the system. When things go wrong, ask what interesting ways they might fail.

Soren Iverson on X makes really good satire about slightly dystopian futures.

One of his designs asks what would happen if deleting your ChatGPT account made all your messages public.

Here’s another: BetterHelp advertising inside Claude Code. It could happen. I’m not discounting it; when you see it, you can imagine that future coming to pass.

Different prototypes do different jobs for different audiences. Far-future work can be strange and playful; on a Labs team, we often work closer to the near future, with something more realistic and tangible.

Yesterday I was prototyping a way to make technical plans more accessible to designers, PMs and other people new to a project. It’s for a prototype we’re working on about planning with agents. You could take a technical document and read it as if you were ten, in high school or a colleague. I tried putting the versions side by side, then shrinking them to a postcard and expanding back to the full text.

It’s the sort of thing we might ship tomorrow. It’s more near-term and less forward-thinking.

The last tool is to make your theories public and concrete.

I’ve had success using writing and conference talks to build theories. Writing helps me clarify: once I have to put an idea into a talk and back it up with data, I get specific about what I’m saying.

Tell other people your theories. If one comes true, you get the credit; if it doesn’t, no one remembers the bad theory.

We don’t do enough theory building in London. When I go to San Francisco – which I officially hate – everyone has theories. You go to a party and people tell you their theories, though often they’re all the same one.

Theory-building matters to a technical scene or culture because saying what you think will happen makes you more likely to act on it. Theory begets action, which begets another theory.

And you do have to back it up with data. If you’re claiming all models will be local and run on Mac minis, for example, ask whether Qwen is as good as Opus 5.5 – and whether it will be. Look at inference costs, electricity forecasts and the other numbers that could support your claim.

GitHub Next is hiring. We’re looking for a design engineer or a very senior front-end designer with good design taste. You can find the contact details on X and message me or my manager, Idan.

Thank you for having me. You can find more at Maggie Appleton, a digital garden of visual essays about programming, design, and anthropology, at maggieappleton.com and githubnext.com.

Voice is Underutilized

Speech is a useful medium for communicating with AI, both as an input/output channel and as back-and-forth. Over 2026 I’ve been increasing the amount of speech I/O and have collected a fair number of use cases.

Input

Voice is, of course, great for rambling at coding agents. Oftentimes the transactional “just talking with the agent” conversational back-and-forth is easier to ramble out than it is to type. I also occasionally have wrist sensitivity issues that make it difficult to type – now with STT and computer-use, that’s not a hassle.

Voice is also good for capturing context. Every phone has a voice memo app on it; most meeting software now has transcription support. There’s a lot of ambient context that just exists in conversations that, if you can (consentingly) capture it, has a ton of downstream value. For example: my team has been transcribing design syncs consistently. A few solo agent sessions interspersed between transcribed design syncs allow engineers to iterate on designs quickly without having to do the “sit down for several hours and write a doc” schtick.

Earlier in the year, my team had an onsite where we got a few folks into the room and hammered out long-term plans. Those conversations were fully transcribed and have been instrumental in a bunch of the work I ended up doing later in the year. Having the context in textual form “froze” those ideation sessions, allowing me to rehydrate them months later, when I had cycles to think about the problems discussed again. That being said, there are obviously some things that you don’t want recorded, for one reason or another. In practice, it’s much more common for us to regret not having transcribed a meeting than the other way around.

Voice input also allows you to write thoughts or capture things that you wouldn’t otherwise have time to do. For instance, I often now ramble into the Voice Memos app on my phone while commuting home about a problem I’m thinking about, with a few proposed sketches of a solution – just pure stream-of-consciousness. Then when I get home, I transcribe the audio, set an agent up on it with /goal overnight, and come back to find (surprisingly often) the problem fully solved.

Models: Local STT models are excellent. I’ve been using FluidVoice, with NVIDIA’s Parakeet models, and it’s remarkably accurate. Claude/ChatGPT are good at cleaning up transcription errors. Parakeet + FluidVoice + a Claude Opus cleanup is nearly indistinguishable from 100% accurate for my use cases.

Output

Since early this year, I’ve been building and tweaking a personal daily briefing “podcast” which aggregates a bunch of information sources I care about, and uses a text-to-speech model to make a daily audio briefing.

This briefing contains things like:

• Local/national/international news, stock market conditions
• Aviation weather on days I go flying
• Tasks due today, calendar events
• Summaries of articles in my RSS feed reader
• Generated research segments about topics inferred as likely to be interesting to me based on recent personal context
• Local nature “news”, like the timing of bird migrations, salmon runs, and blooms
• Local concerts and cultural events
• Astronomical events, such as the visibility of planets and meteor showers

It’s generally 10-20 minutes of audio daily. I tweaked it for a couple months to get it exactly how I like it, and now the quality is consistently high. The crucial, and most difficult, part of this was building enough variety into the “schedule” of what segments show up in the briefing every day that it doesn’t end up sounding stale, gimmicky, or formulaic.

A simple “Claude, give me a daily briefing” becomes stale after a few days. You really do need entropy and novelty and continuously updating/streaming context for this sort of thing to be consistently interesting.

But now it is quite interesting to me! It’s made me significantly more aware of local news, and has allowed me to “read” more of the RSS feeds that I subscribe to – especially articles which I likely wouldn’t have read due to the title not being interesting, but which the LLM thought were interesting based on its actual contents and knowledge of my interests.

Output is also handy for learning things with LLMs. Earlier this year I set up a system for generating “explainers” as podcasts, and learned quite a bit about aviation, various distributed systems topics, and other areas of interest through passive audio consumption.

Models: I had been using GPT-4o mini TTS as my “programmatic output voice model of choice” for quite a while until its deprecation was announced. I’ve now switched to Gemini 3.8 TTS, and it’s fantastic. It features expressive voices, works over OpenRouter, and is cheap. Highly recommended.

Interactive / Real-time

Claude, ChatGPT, and Gemini all have a “live” interactive voice mode – where you can conversationally talk with the model, and it can respond and take actions using tools, and so on. The primary time I use the interactive mode is during commutes. It’s helpful to use the voice mode to triage tasks, ask research questions, and iterate on ideas. It’s like taking time that would otherwise be dead time and translating it into something that can be productive.

Voice is also convenient for walking around the house and capturing things that need to happen. As you remember things, you can have the AI make tasks or calendar entries and burn through a bunch of administrivia without interacting with your phone. It’s like having an actual, literal assistant.

My preferred model is Claude for voice interactive mode (even though it’s not a “native” voice-to-voice model like ChatGPT). A while back the Claude voice mode added support for using MCPs, and that was a game changer. I’ve built a whole personal set of software that has everything from tasks to notes to flashcards, all of which is accessible through MCP. The ability to use MCP via voice means that I can use the live voice mode for triaging or quickly recording tasks.

I also use it for reviewing flashcards. Since my MCP supports flashcards, I can have Claude ask me questions, I have to give the answer, and then the model grades my answer and records it. This is, in my opinion, strictly better than the normal Anki app. With Anki, you can flip through cards quickly and “semi-trick yourself” into thinking that you actually know the answer. I’ve noticed that saying the answers verbally makes it harder to subconsciously cheat, and also helps with retention because the act of forcing yourself to say the answer engages a different part of your brain than simply reading and thinking.

TL;DR: voice is underutilized! It’s a natural modality, and it’s “programmable” at this point. I’d suggest trying, if nothing else, the “on my commute I record Voice Memo prompts or talk with the model about tasks/interests/etc.” I’ve already converted a few people to this and have received positive reactions. Make your own bespoke personal audience-of-one podcast, listen to articles you wouldn’t have time to read, record a brain dump and then have an LLM help you pick through it. There’s a ton of mundane utility to be had.

1. I recall ChatGPT added this support recently too, but in my testing it was somewhat inconsistent, and I had already standardized on using Claude for this use case, which has been sticky.

In short : US AI capacity grows from 38gw today to an 81gw ceiling in 2027. Because 40% of compute serves inference & new Blackwell & Rubin racks lift blended monetization from $9.4b to $15.1b per inference gigawatt, theoretical US inference revenue rises 3.4x from $0.14t to $0.49t.

The ceiling for AI in 2027 is about 80gw : doubling all the compute built in the history of the country in twelve months.

Yet even at this historic pace, the hourly cost of GPUs has doubled in the last six months : short-term rental rates have jumped from $3 to $12-13 per hour, pushing Anthropic’s blended GPU-hour cost up 82% in just two quarters. Finished server racks are already sitting unpowered in staging warehouses because data centers lack the energized utility power to turn them on.

When supply doubles & prices still double, demand is fundamentally outrunning physical reality. There will consistently be an active ceiling on energized compute, which will keep structural upward pressure on GPU prices per hour.

On last night’s All-In election livestream, Brad Gerstner framed that buildout in gigawatts :

“The consensus forecast is a total of 43 gigawatts coming online in 2027… the total gigawatts online at the end of ‘26, the cumulative in the United States, is about 38 … I think we could see at least 10 to 15 gigawatts of the expected build not come online.”

What does a ceiling like this mean for AI?

First, there’s a theoretical maximum amount of revenue we can generate from AI. A GPU can perform two types of tasks for AI : inference & training. Today, 40% of GPU hours are inference : AI sold to customers. The other 60% develops models.

Today’s 38gw fleet earns about $140b, while the 43gw to be added in 2027 will run on chips that are 3-5x more powerful & should deliver an annualized earnings capability of about $350b, for a total of nearly $500b.

As GPU prices continue to rise, foundation model companies may need to shift the fraction of GPU hours to inference from training. This might limit the pace of innovation at the frontier.

Second, latency becomes the release valve for too much demand. Internet access is priced in terms of bandwidth (gigabytes of files you can download) & speed (how quickly you can download it). AI may be priced the same way. We see this already with products focused on low-latency inference & those on long-horizon tasks.

Third, limitations in compute availability will encourage algorithmic innovation. Chinese models like DeepSeek, Qwen, & Kimi have demonstrated material architectural advantages that drive near-state-of-the-art performance on much smaller models & new architectures.

Fourth, the harness becomes critical to deliver state-of-the-art performance on limited GPU availability. Responsible for more than half of system performance, the software around the model can extract tremendous efficiency.

Fifth, the economics of vibe-coding face a reality check. When inference becomes more expensive, off-the-shelf software (with AI) can be less expensive than bespoke built & maintained internal software.

In 2027, AI’s constraint will be access to powered GPUs. As the prices for renting GPUs continues to increase faster than efficiency can fight, watts in store for 2027? Efficiency as the dominant motif up & down the stack.

The Top 1% of AI Spenders Stalled in Q3. So Did Anthropic’s Dollar Growth.

Ramp’s latest AI Index, built from transactions at 85,000+ US businesses, shows the heaviest AI spenders peaking in July. Anthropic’s amended S-1, filed this morning, shows its quarterly dollar add shrinking for the first time.

• The top 1% of firms on Ramp spent less on AI per employee in September than in July.
• Anthropic added $5.4B of revenue in Q3, down from $6.8B in Q2.
• That top 1% drives 80% of spend on OpenAI and Anthropic.
• Adoption across all other firms is still rising, at about $16 per employee per month.

1. Ramp’s Top 1% Peaked in July at $9,873 Per Employee

Although per-employee spend rose 11.7% from last month, the top 1% of firms spent $9,568 per employee per month in September, down 3.1% from its July high of $9,873. August fell 13% from July. September recovered most of it but not all.

The top 10% kept climbing, from $740.47 in August to $813.43 in September, about 10% in a month. The median firm rose too.

Ramp notes that because the top 1% represents a small group of firms, its spending estimate is more volatile than our median and top 10% estimates. Its customer base also skews toward startups and tech-forward firms, the same companies that led the token-maxing wave this spring.

2. Anthropic Added $5.4 Billion in Q3, Down From $6.8 Billion in Q2

Revenue rose to $16.96 billion from $11.56 billion in the second quarter. The filing’s nine-month total of $33.24 billion puts Q1 at $4.72B. Q2 added $6.84B. Q3 added $5.40B, 21% less.

Most coverage led with growth falling from about 140% to 47%. Regenerator1 flagged the dollar add from the October leak: Anthropic’s average monthly growth slowed from ~$760 million in Q2 to (“only”) $580 million a month in Q3.

Within the quarter, Anthropic reported a $65B run rate at the end of July, about $5.4B a month. Q3 averaged $5.65B a month, which implies August and September grew roughly 3 to 4% a month. From May to July the run rate went from $47B to $65B.

Ramp’s top 1% and Anthropic’s revenue both flattened after July.

3. 1% of Firms Drive 80% of OpenAI and Anthropic Spend

Ramp previously shared that 80% of spend on OpenAI and Anthropic is driven by 1% of firms. In September, the top 1% spent a median of $9,567.53 per employee per month on AI, compared with $15.70 for the median firm. That’s about 600x.

Anthropic’s S-1 shows the same concentration among individual users: Claude Enterprise users who skipped Claude Code averaged under $75 a month, while the top 5% of users who adopted it spent roughly 20 times that. The filing also warns that “Any adverse change in demand from our largest customers…could adversely affect our business and prospects.”

A few hundred companies with agents running around the clock produce most of the frontier labs’ revenue. When they stop adding spend, quarterly revenue growth slows regardless of how many new firms sign up.

4. Adoption Is Still Spreading, at $16 a Head

In September 2026, 55.9% of U.S. businesses on Ramp paid for AI, up 0.6 points from August.

The numbers on replacing whale spend with new adopters are lopsided. One top-1% firm with 100 employees spends about $957K a month. Matching it takes about 600 median firms of the same size. A 0.6-point monthly gain in adoption adds firms at the bottom of the distribution, where each one spends very little.

New adopters are also splitting their business. Among Ramp businesses, 43.8% paid Anthropic, up 0.25 percentage points from last month. OpenAI adoption rose 1.12 percentage points to 40.6%, outpacing overall AI adoption. Anthropic still leads on dollars: in the week ending October 23, 2026, Anthropic captured the largest share of AI token spending among businesses on Ramp, at 60.5%.

5. Price Cuts Account for More of the Stall Than Summer Does

Ramp points to price: Ramp lead economist Ara Kharazian attributes the slowdown mainly to falling prices for top models. Anthropic’s filing supports that. Claude Opus 5.5 cut customer cost per task by about 40% compared with Claude Opus 5, and ZeroHedge’s read of the filing puts Q3 price cuts at about $600 million.

If a heavy user’s workload stays the same size, a 40% cut in cost per task lowers its bill by up to 40%. The top 1% didn’t add enough new work in August and September to offset that.

Summer explains less. To match Q2’s dollar add, Anthropic needed about $1.44B more revenue in Q3, roughly 8% of the quarter. The one seasonal dip with data behind it, the December holidays, ran about 20% for two weeks, roughly 3% of a quarter. An August vacation dip would have to be about 2.5x the size of Christmas to explain the full gap.

The October 31 Run Rate Will Show Whether the Whales Came Back

Anthropic’s filing defines run rate as the trailing 28 days of usage times 13, plus a month of subscriptions times 12. It left the October 31 figure blank, and today’s amendment still has it blank.

• Above about $75B: August was a seasonal and capacity dip. Heavy users resumed spending, and the $5B of short-term compute Anthropic bought in Q3 went to real demand.
• Around $68 to 70B: the top 1% has plateaued, price cuts are offsetting usage growth, and new adopters are too small to make up the difference.

Ramp’s next index, with October data, will show whether the top 1% got back above July’s $9,873.

The same check works on any B2B + AI company’s revenue. Rank customers by monthly spend, take the top 1%, and compare their September total to July. If that group is flat while the customer count grows, the business has the same shape as Anthropic’s Q3: a handful of accounts carry the revenue line, and they’ve stopped expanding.

Why we're moving our warehouse product off DuckDB

Five months ago, we rebuilt PostHog's warehouse product on DuckDB instead of ClickHouse, as we explained at the time. We did it because a shared ClickHouse cluster couldn't handle hours-long modeling queries, and it lacked a cost-based query optimizer. DuckDB gave every customer their own instance, and tools like dbt could connect over Postgres. We're still fans.

But we underestimated how big and complex our customers' workloads would get. We didn't want them to have just a good experience, we wanted the best experience you can get when you pay someone else to run your warehouse. It should work at any scale, at a fair price.

So we spent the last three months re-architecting it, this time without DuckDB.

DuckDB is brilliant on one machine

We love DuckDB. It's probably the best single-node tool for analyzing heaps of data, and that node can be your laptop. It's robust and reliable. It almost always finishes your query, and if it runs out of memory, it spills to disk.

The same features that are great locally gave us problems in the cloud. Customers ran more complex queries than we expected, so we had to add huge instances. Adding disks was an option, but queries would have been too slow and expensive to be viable.

To run a single-node engine safely in the cloud, we have to size the worker before the query arrives. The ergonomics here are wonky. We couldn't find a good way to tell customers what resources their queries would need. Predicting CPU and memory for a specific query was even harder.

Users shouldn't have to worry about this. They should be able to run whatever they need to get their work done. Our job is to handle the rest and make it as predictable as possible.

We hit other bottlenecks too, like fetching lots of data from S3 without async fetching. DuckDB only added that recently.

DuckLake is built for compatibility, not scale

To use DuckDB as a fully-fledged data warehouse, we installed the DuckLake extension by default. It is a new lakehouse format from the same creators and follows the same principles as DuckDB: keep things simple and run on almost any setup. That works well up to a point, but at PostHog's scale, we needed something designed for distributed scale from the start.

DuckLake's catalog schema has to stay portable across many SQL databases, which limits engine-specific optimizations. At our scale, a single-table write could take more than three minutes because every commit re-read the statistics for the entire catalog.

We tuned DuckLake with table indexes and similar tweaks. But to keep offering DuckLake, we had to stay 100% compatible with its existing, "official" schema. This left us with fewer optimization options.

Another problem is that over 99% of the catalog's statistics rows belonged to tables that no longer existed. Cleaning them up made writes 30 to 50 times faster, but the rows kept growing back.

We also spent a lot of time on the number of connections DuckLake opens to metadata databases. That hurts on shared Postgres instances, where every connection has a real cost.

1 trillion rows was a challenge

DuckLake at PostHog didn't start small and ramp up. We fully committed and put all of PostHog in a DuckLake to dogfood as the first customer.

When we moved off it, it held about 2 PB: roughly 1 trillion rows and 15.3 million snapshots. It broke in lots of ways that were hard to fix within DuckLake's scope.

We'd rather have contributed to the existing community and helped it grow. But we couldn't land changes as fast as we needed, so we ended up carrying patches in a fork which defeats one of the main benefits of using DuckLake: the community.

Speaking Postgres is harder than it sounds

Offering direct Postgres connections over port 5432 sounds like a great idea. In practice, it was much harder to scale than HTTP.

Missing reconnects and managing TTLs and idle connections at scale is hard, and long-running connections are expensive. There's also very little tooling for load balancing pgwire compared with HTTP. Compare the ergonomics of an AWS NLB with an ALB and you'll see what we mean. HTTP headers also make routing in Kubernetes much more flexible.

There's also an endless list of Postgres clients, and each expects its own niche Postgres behavior. Customers kept asking us to fix their client or library. We spent a lot of time shipping many of those fixes, but coverage never got good enough. We'd rather spend our time building an excellent warehouse product than chasing the long tail of Postgres compatibility.

We're rebuilding on Trino with HogLake

We've learned not to hype the tech behind a warehouse so much. What counts is the experience it gives you.

Still, we're happy to share what we're cooking next. We rebuilt everything around our own flavor of Trino and created our own open table format, HogLake. And yes, we're testing it at PostHog's petabyte scale first. We made it solid before handing it to design partners.

If your current warehouse is slow or expensive, let's talk, especially if you have a lot of data to query. We're always looking for design partners.

PostHog is your product's context layer. With a full suite of developer tools – AI observability, product analytics, session replay, feature flags, experiments, error tracking, logs, and more – PostHog ingests and stores all the data agents need to diagnose problems, uncover opportunities, and ship fixes. A data warehouse and CDP tie it all together, unifying that context into one source agents can read across. You can steer it all from Slack, the web app, the desktop (PostHog Desktop), or your own editor via the MCP.

Introduction

At Halodoc, data helps our teams make better decisions about the healthcare services we offer. Our Redshift data warehouse is where that data comes together, and our analytics teams use it every day to build dashboards and reports. When something changes underneath it, those dashboards and reports are the first place people notice.

In May 2026, AWS launched Amazon Redshift RG instances, a new generation built on Graviton processors with a redesigned query engine. On paper the move from RA3 is an "in-place upgrade". Same SQL dialect, same port, same endpoint after an Elastic Resize.

But "nothing changes" is a dangerous assumption when your warehouse sits behind hundreds of Airflow DAGs, Spark jobs, dashboards, data governance policies and exports to other tools. This post walks through what we tested before moving our main warehouse cluster to RG instances, what really changed under the hood and what did not.

What actually changes under the hood

RG nodes run on AWS Graviton processors, which do more work per vCPU than the ones in RA3. AWS says this and the rest of the redesign add up to workloads that are up to 2.2x faster at about 30% lower price per vCPU. The query engine is new too. It runs queries in a vectorized way, which means the same query can get a different execution plan than before, and a plan that was fine on RA3 is not guaranteed to be fine on RG. RG also brings a built-in engine for reading Parquet files from S3, and JIT ANALYZE, which collects statistics for data lake tables automatically as queries run.

One smaller change is worth knowing about. AWS notes that RG nodes have smaller cursor sizes, which matters for any job that streams very large results.

Everything else stays the same. The endpoint, the port, the SQL dialect, our users, groups and workload settings all carry over from the snapshot. That last part is the one we were least willing to take on faith. "It should carry over" is easy to say, so we checked it anyway.

How we tested

We built the test around one rule. Every place where our systems touch Redshift gets its own check, and the pass condition is written down before we run it. We ended up with eleven checks. They follow the path of the data, from connecting to the cluster to measuring how fast everything runs. Most of these checks are simple pass or fail tests, because the first question was whether anything would break. Check 11 is where we compared numbers between the two clusters.

1. A safe test cluster

The first risk was the test itself touching production. We restored the latest snapshot of our production cluster into a new RG cluster, after confirming the cluster version was recent enough for RG and that RG was available in our AWS region. Then we gave the test cluster its own connection and made copies of the pipelines we wanted to try, so the production pipelines never pointed at it. The check passed when production stayed untouched for the whole test.

2. Connections and everyday tools

A cluster is no use if people and tools cannot reach it. We connected from our Python code, from Airflow, from a desktop SQL client, from our dashboard tool and from notebooks running on our Spark cluster. We also ran a few basic functions that our code depends on. This passed when everything connected and returned what we expected.

3. Users, permissions and custom functions

A snapshot restore should bring users, groups, workload queues and custom functions along, and we compared each of them against production. For the custom functions that clean up data in our reporting tables, we did not stop at seeing that they exist. We called each one and checked the result. The check passed when everything matched production.

4. Loading data into Redshift

Most of our data arrives as Parquet files in S3 and is loaded with the COPY command. We loaded a test table and compared the row count with the source files. An exact match was the only passing result.

5. Our main pipelines, end to end

We write into Redshift in two different ways, and one check covers both paths. The first is the Spark path, where jobs write files to S3, load them into staging tables and then merge them into the final tables. The second is a direct SQL path used for some of our reporting tables, with no Spark and no S3 in between. For both, we ran real tables through the test cluster from start to finish. The checks passed when row counts were correct, business keys had no duplicates, and the hash we use to detect changed rows gave the same results as before.

6. Getting data out

We also send data out of Redshift, including to our marketing platform, which is strict about file format. We exported a test file and compared it with what production produces, looking for the same headers, delimiter and structure. Any difference would have broken the import on the other side, so the check passed only when the files were identical in structure.

7. Maintenance jobs and monitoring

Redshift needs regular housekeeping, such as vacuuming and updating statistics on the tables it stores itself, and we run alerts on top of its system views. One of them warns us when a query runs for too long. We checked that these views still exist with the same columns, and that vacuum and analyze run without errors.

8. Data masking

This was the check we took most seriously, because masking protects sensitive data. Checking that a masking policy exists is easy. We wanted to know that it works. So we compared the number of policies with production, removed and re-applied a policy on a non-critical column, and then queried the masked tables as a regular user, not as an administrator. The check passed only when we saw masked values on screen. A policy sitting in a list proves very little.

9. The Spark to Redshift setup

We confirmed that credential lookup for the new cluster still worked, and that queries on external tables stored in S3 still ran. It passed when a full Spark job completed with correct row counts.

10. Streaming large results

One of our jobs reads large query results in chunks, using a server-side cursor, and copies them into a Postgres database. AWS notes smaller cursor sizes on RG, which is exactly where a job like this could break. We did not replay this one on the test cluster, so we watched it closely in production right after the switch. It runs every hour, and the runs we checked all completed, streaming in chunks of 1,000 rows with the row count matching on both sides. If it had failed, the fallback was smaller chunks or a bigger node.

11. Speed and query plans

Finally, we ran the same loads, merges, exports and maintenance jobs on both clusters and compared the time. Our rule was simple. Anything more than 10% slower on RG gets flagged. Because the engine is new, we also picked our heaviest reporting queries and compared their execution plans side by side, looking at the join order and at how data moves between nodes.

Nothing was slower on RG. We ran each test on both clusters under the same conditions, after 8 PM when production is quiet, so neither cluster was competing with other work. Loading about 6 million rows with COPY dropped from 145 seconds to 24, roughly six times faster. Exporting a similar volume as Parquet went from 366 seconds to 301, a smaller gain of about 18%. Building five of our heaviest reporting tables ran between 2.1 and 5.2 times faster.

The plans explained a lot of it. On RA3, external tables stored in S3 went through a separate scanning layer, while RG reads them directly on its compute nodes. RA3 also broadcast a table of about 10 million rows into four subqueries, where RG distributed only the data it needed based on the join key. And RA3 was planning with out-of-date statistics, so it misjudged row counts on several tables.

The switch

Because the endpoint stays the same, our applications did not need to change. We used an elastic resize during a planned window, which takes about ten to fifteen minutes of downtime.

What we saw afterwards

We measured the same workload before and after the cluster change. It is the regular morning load of scheduled pipelines and dashboard queries, which runs on the same schedule. We looked at the morning window from 7 AM to 1 PM, when the warehouse is busiest. A typical morning in that window carries about 11,000 queries, around 8,500 from dashboards and 2,300 from pipelines.

The chart compares RA3 and RG on the same morning load. Each bar is the time as a percentage of what it was on RA3, so a shorter bar is better.

• Queue time is how long a query waits for its turn before it starts. It dropped by about 32% for dashboards and 83% for pipelines.
• Average run time is how long a typical query takes once it starts. It dropped by about 25% for dashboards and 57% for pipelines.
• Slowest 5% (also called p95) is the time that only the slowest 5% of queries exceed. A good average can hide a few very slow queries, and those are the ones people notice. It dropped by about 15% for dashboards and 46% for pipelines.

Our data pipelines gained the most. Queries almost stopped waiting in line, and they ran faster throughout the morning. Dashboard queries improved overall, but not in every hour. Most hours were faster, one was about the same and one was slower than before, and we are keeping an eye on them.

The result that surprised us most was about concurrency scaling, the feature that adds extra capacity when the main cluster is busy. Only dashboard queries used it. After the switch, the extra capacity we used dropped by about 45%, because the main cluster could now handle the load itself. So we lowered the maximum number of extra clusters from two to one.

The weekly numbers have held since the switch. They cover all hours, not only the morning window, and show the same direction. Average queue time is down about 70% and average run time about 35%.

The move also lowered our costs. Cluster cost fell 30%, in line with AWS's price-per-vCPU claim, and concurrency-scaling spend fell 76%, because the cluster now handles most peaks itself and the free daily credits cover more of what is left. Together, our Redshift compute cost is about 35% lower than before, and the total bill, including storage, is about 32% lower.

What we learned

Test the paths your pipelines really use. Our main loading path and our direct SQL path are different code, and a test of one says nothing about the other.

Check that things work, and not only that they exist. Masking policies and custom functions carried over from the snapshot, but we only trusted them after using them.

A faster cluster changes how you should set up concurrency scaling. Look at how long the queries that spill over actually take, and not only at how often it is used.

What is next

RG’s integrated engine reads data lake formats such as Parquet and Hudi directly on the cluster’s compute nodes. We are now exploring bringing part of our data lake and ETL workloads into the Redshift cluster itself, and will test how they behave before rolling anything out.

References

• Amazon Redshift RG instances: features
• Meet Amazon Redshift RG: Graviton-based instances with an integrated data lake query engine (AWS Big Data Blog)
• DECLARE: cursor constraints by node type (Amazon Redshift docs)
• Resizing a cluster: elastic resize (Amazon Redshift docs)

Analysts, analytics engineers, and even business users are writing less SQL and Python by hand. They prompt an agent instead, and with the right context (data models, docs, a data catalog), the agent writes a decent query. Think of a BI tool shifting left and democratizing new context from data models and sources. This helps the agents better understand the business problem and write a more accurate SQL query.

With more advanced tooling that automatically reviews or generates queries iteratively, the agents’ output gets higher in quality every time. The models get better, and we can add additional documentation from internal Confluence pages or data catalogs, and it will get even better.

When using Generative AI for BI tools, we need better ways to verify the underlying foundation for a dashboard. But how? What we need next are linters and a compiler-like style that AI-lints everything before running, and then integrated test suites that get better and better. Basically, back to Test-Driven Development: prompting the tests first, so we assert what we want to build.

As models get better, iterative test suites get better too, and with it, we get better verification. But still, in verification lies the liability today with agentic engineering work, and that’s what we talk about in this article: helping data analysts and domain experts develop more meaningful data work for the organization.

We need to move all logic into one place, to go from a stack of components to one optimized for human ergonomics. We need new ways to make this human-friendly, a new architecture even, a unified lineage tree. This article explores current challenges in BI from first principles, analyses what has worked so far, what no longer does, and how we could improve the architecture to better prevent errors.

In a Metabase survey run during its AI analytics week, 74% of teams were building with AI, and only 2% were scaling it. The bottleneck has moved from creating analysis to checking it.

Verification with Agents through Test Suites, and Human Intuition?

So the first question is, what do we need to verify? What’s an iterative test suite?

If it comes down to verifying metrics and KPIs, it’s all math. The retention KPI is built in code, defined in SQL. It’s math. Agents will eventually generate the right test suite to verify the retention KPI, based on 1000s of test cases. It’s a standard equation: with evals run by a harness, agents can figure out edge cases.

But then again, you also need human verification. Business people are the best data contracts, they know when something doesn’t make sense, they know the numbers. Plus they feel it in their subconscious.

It’s an intuition they gained with years of experience, knowing what the numbers should be in what case. So the test suite can be initiated at the beginning, iterated and improved, but the human adds their intuition to the mix.

Five Hierarchy Levels for Testing System-wide Quality

For testing across the data stack, we need system-wide tests, and tests that run on different levels. Below are five different hierarchies for better quality testing:

• Linting: Statically analyses our development code and our aggregations without running them, and gives real-time diagnostics of our metrics and configs with type checks and contract conformance.
• Compiler: A whole-tree check that resolves and type-checks the full lineage tree before deploying and running on an environment, refusing to build what doesn’t fit together.
• Unit Test: Tests small functions and components of the full system, each time we change something. Value assertions and calibration thresholds against known inputs live here.
• Integration Tests: Similar to unit tests, but we test multiple parts of the system, modules or components as a group to verify interactions.
• End-to-End Tests: Run the compiled system with dedicated seeds of data sets and check the outputs end-to-end.

If we add them all together, we could have thorough and well-tested KPIs for business analytics and the data stack, from start to end, with the power of the latest agentic engineering, but also a touch of human intervention and intuition.

The Solution: Moving All Logic into One Place?

One git repository, one mono repository, one commit hash, one change across all metrics, dashboards and ETL load. Quite similar to what I was writing about a while back, the “Declarative Data Stack”, expressing the full data stack as a single function.

It’s precise, and a declarative config such as a function, e.g. run_stack(serve(transform(ingest))), can recreate the entire data stack.

For our purpose, we want to have better verification, which helps with that too. The logic (metrics, dashboard, ETL) is stored in a standardized way, agents can create test suites on top of it, and we can iterate fast. We can’t verify logic in four different databases and git repos. Bringing it together into one declarative place will avoid this.

In the end, metric definitions, segments, transformation, aggregation, all of it results in a dashboard. We go from source to visualization. It’s a full-stack data engineering platform, from transformation, semantic layer, actual computation to dashboard and data app.

Different Serialization Formats

Besides having the code and configuration in one place, having different formats or syntax is okay these days. dbt models are Jinja-templated SQL in each warehouse’s dialect, Metabase has native SQL and its own query language, and Looker has LookML. Translating between them can increasingly be done by an agent, and verified with a compiler or inspection tools.

Stacking of Components to Optimize for Human Ergonomics

We need a system that focuses on human productivity by fitting into our workflow like macros in dbt or LookML functions. In programming, we also started with Assembly, then moved up to higher-level languages like FORTRAN and C, then to object-oriented languages like Smalltalk, and now we have all the programming languages. Now we have evolved even further, so we can just instruct in natural language.

We went up the stack, it’s a different optimization level when we don’t need to write Assembly anymore. For BI developers, that’s a reliable system that supports us with agentic work whenever possible, but still with the human ergonomics and productivity in mind—e.g. producing more is not better, but higher quality and correct metrics are.

We want the ability to verify. Some companies have rewritten their core as notebooks were unusable: state was not clearly managed, variables ran out of order or were reassigned, and it was hard to understand which code block created which datasets. That is where, in a BI tool, the connection between a metric and the compute engine becomes essential: the better integrated, the less drift we have from definition to data sets.

This idea is older than BI. Donald Knuth’s Literate Programming (1984) treats the computer program more like an essay explaining the reasoning, with the code as illustration. One tool produces the tangled version the machine runs, and another produces the woven version the human reads. Meaning and implementation can’t drift apart, because they’re the same document.

A Unified, Hierarchical Lineage DAG

For bringing the test suite into an integrated place, I was tinkering with the idea of creating a unified computational graph that represents the full state from ingestion to dashboard.

When I discussed this with Sameer, he pointed out that it has no cycles and is hierarchical: a DAG that goes down level by level into its sub-DAGs. It isn’t a strict tree, since any join gives a model more than one parent, but it reads top-down like one. That’s what I mean by “lineage tree”, or “hierarchical lineage DAG”, in this article.

For the linting part, we can use something called an Abstract Syntax Tree (AST). It’s a data structure that represents the structure of a program or code snippet. It is a tree representation of the abstract syntactic structure of text written in a formal language. There’s also a SQL AST specifically, and tools like SQLMesh and most parsers in BI tools make heavy use of them.

State is the Enemy, Except Known Test Data

One element of the equation we can’t leave out is the state of a system, and even more the state itself, the customers or our data.

For the system state, Sameer says: State is the enemy: the more mutable state there is in a system, the less you trust the output.

The problem is mutable state. Planning should happen against fixed, known state: a test data set, a seed of data where you know the expected outcome. Without that fixed reference, verification is just guessing.

Shift Assertions Left: Catching Drift at Build Time

The last question is, when do we actually do the verification? During development, like a compiler that checks at the end of the development cycle, once we have defined metrics, and blocks and refuses to run anything?

Or better, like a linter that constantly shows us warnings and errors while we develop? Both are possible, depending on how rigid we want it to be.

Timing-wise, as early as possible is best. During development, before production, as verification during runtime is already well covered by orchestrators and integrated data quality tools. Again, the more we shift left, the better.

Catch the Drift: Good Data

But how do we know if measures and KPIs are verified, or tested well? What’s important is a good data set and test suite that improves the data quality, the tests, and also the business quality. We need to measure the “Goodness of data”.

With an all-encompassing hierarchical lineage DAG that knows the business logic better than existing BI tools, we can use the declarative metrics, unit test them so they declare an outcome, build a compiler that does built-in assertions, and develop assertion programming. Today, most data checks run after the data is computed; they’re runtime checks. We need to take that further and shift assertions left across the whole stack, surfaced by a linter while the metric is being written, and enforced at build time before the pipeline runs.

Avoid a definition drifting from its original definition by unit testing configuration against a large test suite and human intuition. Most BI drift today comes from the opposite arrangement: the dashboard built ad-hoc once with manual tests, and not touched after—drifting away.

What’s Next: And Where Are BI and Human-Written Code Heading

We covered a lot: why verification is the new liability in an agentic BI stack, why we need test suites at five hierarchy levels, why moving all logic into one declarative place helps with verification compared to having spread-out components, and why a unified hierarchical lineage DAG, built on ASTs, semantic diffs, and LSP-style linters, solves part of the linting and verification. We also looked at why state is the enemy of trust, and why assertions need to shift left from runtime checks to build-time guarantees.

This is where the thinking behind Data Studio in Metabase is heading. Transforms, metrics and dashboards live in one place. Dependency tracking shows what depends on what, so you can see what a change will break before you ship it. Remote sync lets you version all of it in Git.

Your company's data, connected into one ontology.

Connect your databases, tools and documents, let an agent draft an ontology over them, and load it into HelixDB as one connected graph. Explore it, follow every value back to the row or quote it came from, and ask questions with cited answers. Use it hosted at foundry.helix-db.com, or run it on your own computer with one command.

Get started with your coding agent

On Helix Cloud. Open foundry.helix-db.com and click Set up with your agent. It copies a prompt for Claude Code, Codex, Cursor or any agent that can run commands. The agent adds the Helix MCP, signs you up through it if you don't have an account yet, and builds your first ontology with you. You never need the Helix dashboard: the agent sends you a link only to sign in or to enter a password or key.

On your computer. With Docker running, paste this into your agent:

Set up Helix Foundry on this computer.

Clone https://github.com/helixdb/helix-foundry.git (or use the copy I
already have), then follow its README.md and local/README.md to start it
with Docker Compose and check that it is up. Ask me before deleting data,
removing Docker volumes or stopping anything that is already running.
When it is ready, give me the URL and tell me what to do next.

Approve its git and docker commands one at a time rather than all docker commands up front. You enter API keys and database passwords in Foundry, in your browser: your agent never needs them.

Run it on your computer

You need Docker with Compose v2, ports 3000 and 8333 free, and room for a few GB of images on the first start.

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
docker compose up -d --wait

Open http://localhost:3000. Foundry creates My workspace for you. No sign-in is required.

AI: Foundry uses the ANTHROPIC_API_KEY or OPENAI_API_KEY of the shell that ran docker compose up, else a local model in Ollama or LM Studio (docker compose --profile ollama up -d runs Ollama beside Foundry). Open Settings › AI models to see the selected provider or choose another. Until there is one, drafting, uploading documents and asking wait for it.

What you do next

1. No data to hand? Click Use the sample: Acme Corp, a made-up software company, as a PostgreSQL database (customers, subscriptions, invoices, support tickets, usage) and documents (contracts, call notes, an incident report). It walks you through the data, the goal, a ready-made ontology, its load and a question, in about a minute, once Foundry has an AI provider.
2. Otherwise, connect your data or upload documents, say what you want to know, and let the ontology agent draft the ontology.
3. Review the draft, make it current and load it into HelixDB.
4. Explore the graph and its records, or ask the Analyst.

What you get

• Connectors for PostgreSQL, MySQL, Amazon S3, Stripe, PostHog, WorkOS, GitHub, Linear, Granola, Cal.com, Slack, Notion and Google Workspace, documents (Markdown, text, PDF) and table files (CSV, TSV, JSON, JSON Lines, Parquet). On Helix Cloud, API sources also take records your apps and agents send.
• Syncs that read only what changed: PostgreSQL and MySQL change capture where the database allows it, and incremental reads from every other connector.
• An ontology agent that drafts types, links, rules, and the tables and documents each comes from, from your data and your goal. You review it, edit it and make a version current.
• Loads into HelixDB that keep where every value came from: a table row, or a quote in a document. Values documents disagree on wait for your review.
• The Explorer: the graph and its records, each entity's page, and two loads compared side by side.
• The Analyst: questions answered from a load, with charts, the queries it ran and a source for every claim.
• Your choice of AI: on Helix Cloud, Helix's Claude or, on Foundry Pro, your own key; on your computer, Claude, OpenAI, Azure OpenAI, Amazon Bedrock, Ollama, LM Studio or any OpenAI-compatible server.

Everyday commands

Run these from the repository.

docker compose ps                         # status
docker compose logs -f site foundry       # follow logs (Ctrl+C to stop)
docker compose stop                       # stop
docker compose up -d --wait               # start again
git pull && docker compose up -d --wait   # upgrade to the latest release

Foundry starts again with Docker unless you stopped it. Your data lives in Compose volumes, which docker compose down keeps. Never run docker compose down -v unless you mean to delete everything: it removes your data and the key that seals every password and API key you gave Foundry.

Security model

The local install is for one person on their own computer. There is no sign-in, so anyone who can reach it controls it.

• The site listens on 127.0.0.1:3000 only and answers only localhost:3000. Never expose it through a reverse proxy, tunnel or port forward.
• The store listens on 127.0.0.1:8333, for the uploads Foundry signs.
• The first start writes the install's secrets into the secrets volume; nothing is printed or written to the checkout. Every credential you enter is sealed with its connector key.
• Ollama in Docker listens on the ontology agent's loopback only, so no other container and nothing outside Docker can reach it.
• A local build loads no analytics and sends no usage data anywhere.

Documentation

Develop

The site, the Foundry app and its same-origin API proxy (Next.js), is at the root. It needs Node 24 and pnpm.

pnpm install
pnpm dev:mock        # the hosted site against a mock API, on http://localhost:3000
pnpm dev:mock:local  # the local build against the mock

The mock stands in for the API and sign-in, so no account or secret is needed. Before sending a change, run pnpm typecheck, pnpm lint, pnpm test and pnpm e2e (Playwright; needs pnpm exec playwright install chromium). AGENTS.md describes the layout and the rules.

backend/ is Foundry's backend, the Go module github.com/helixdb/helix-foundry/backend: the API, the workers that sync data, draft ontologies, load them into HelixDB and answer questions, and their MySQL store. backend/README.md says how to build, test and run it. Hosted Helix runs the same code as a library.

License

Everything in this repository, the site and the backend, is Apache 2.0, and so are Foundry's three images: foundry-site and foundry, built from it, and ontology-agent, the ontology agent's. HelixDB, which local/compose.yaml runs beside them, is Apache 2.0 too.

RocketRide is the open source AIDE: the AI Development Environment.

Build, deploy and harness production-ready AI solutions at light speed, all within your IDE or using the CLI in your terminal.

Your code editor just became the AIDE. RocketRide turns the classic IDE you already use into a full AI Development Environment: one place to compose, debug, observe, and deploy AI runtimes using any model, any tool, any framework, with zero vendor lock-in. Equipped with deep observability and backed by a battle-tested, high-throughput C++ engine, what you build is production-ready the moment it runs. It's the harness for everything behind your AI applications, not just the agents, but the whole stack beneath them.

Under the hood, RocketRide is an open source data pipeline builder and runtime built for AI and ML workloads. With 100+ pipeline nodes spanning 15+ LLM providers, 9 vector databases, OCR, NER, and more, pipelines are defined as portable JSON, built visually in VS Code, and executed by a multithreaded C++ runtime. From real-time data processing to multimodal AI search, RocketRide runs entirely on your own infrastructure.

Design, test, and ship complex AI workflows from a visual canvas, right where you write code.

Drop pipelines into any Python or TypeScript app with a few lines of code, no infrastructure glue required.

Where to start

Open source, MIT. The whole engine is MIT-licensed and OSI-compliant. No enterprise edition, nothing behind a paywall.

Features

Quick Start

1. Install the extension for your IDE. Search for RocketRide in the extension marketplace.
2. Click the RocketRide extension in your IDE.
3. Deploy a server - you'll be prompted on how you want to run the server. Choose the option that fits your setup:
   • Local (Recommended) - This pulls the server directly into your IDE without any additional setup.
   • On-Premises - Run the server on your own hardware for full control and data residency. Pull the image and deploy to Docker or clone this repo and build from source.

Your first AI feature

Whether you build web apps, integrate APIs, or run backend services, you already have the mental model.

Three steps, no API keys:

1. Run it locally. Follow the Quick Start and pick Local when asked. That's the whole install.
2. Open a working pipeline. Open examples/document-processor.pipe in your IDE. Give it a PDF or an image and it pulls out the text, finds names, addresses and other personal data, and returns a cleaned copy.
3. Call it from your code. The pipeline is now a function your service can call.

   pip install rocketride

   import asyncio
   from rocketride import RocketRideClient
   
   async def main():
       async with RocketRideClient() as client:
           run = await client.use(filepath='examples/document-processor.pipe')
           out = await client.send(
               run['token'], 'Alice Smith, 12 Elm St, Springfield.', objinfo={'name': 'note.txt'}, mimetype='text/plain'
           )
           print(out)
           await client.terminate(run['token'])
   
   asyncio.run(main())

Observability

Selecting running pipelines allows for in-depth analytics. Trace call trees, token usage, memory consumption, and more to optimize your pipelines before scaling and deploying.

Contributing

Good places to start

• Claim an issue with one comment. Comment /assign on any open issue and it's yours.
• Add a node. Every node is a small Python package. A new provider, tool, or store makes a good first contribution.
• Fix what you just read. Docs PRs are welcome, including this README.

How it works

• One build tool for the whole monorepo: ./builder manages the C++ toolchain, Python environments, and Java/Tika for you. Clone, build, run.

Title: Text-to-SQL Models Make Choices Without Saying So

A text-to-SQL answer can run, return a plausible number and still compute something other than what the analyst meant. This can happen when the request leaves a calculation choice open, such as whether to count rows or distinct entities, and the model settles it without saying so. Standard benchmarks cannot detect this, because they score each question against a single reference interpretation. We introduce SpecBridge, which tests such a choice by varying it alone: it poses three otherwise identical requests, one leaving the choice open and one per interpretation, and scores each answer by running it. The databases are real, and the choices are ones that made models fail on existing benchmarks. On 204 hand-validated tests, four language models usually compute each interpretation when asked for it, yet for the open request return both in only 15-58% of the tests where they can, often without mentioning the choice. The gap lies in reporting, not in computing. Benchmarks even penalize the alternative: on BIRD questions where such a choice changes the answer, over two in five of the answers marked wrong are right under the other interpretation. Because the gap lies in reporting, a system can narrow it without a stronger model: it first decides whether a request leaves a choice open, then answers each interpretation in its own call. On our tests and on AMBROSIA, an existing benchmark of ambiguous questions, this approach raises the share of open requests that get every interpretation by 29-63 points over the single answer that production assistants give, without lowering precision on clear requests. It also needs fewer user turns than asking a clarifying question.

Full article content is not available for inline reading.

Read the original article →

Apple is introducing vertical tabs in Safari's developer betas across iPhone, iPad, and Mac, with tabs displayed as compact icons in a left sidebar that can expand to show website titles. A new Adaptive Dark Mode can automatically generate dark versions of websites that lack native support, either on demand or through a persistent preference. Siri AI can also organize, sort, move, and close tabs, with broader awareness of webpage content planned for a future update.

Computer-use AI agents frequently fail at the same confusing interfaces that frustrate humans, including ambiguous buttons, hidden menus, unexplained disabled states, and disruptive overlays. People often compensate for these problems by guessing, backtracking, or relying on experience, while agents expose the underlying design debt through repeatable failures that are easier to observe. Making interfaces clearer for agents through explicit labels, visible states, predictable interactions, and semantic structure can also improve accessibility and usability for people.

AI agents introduce unpredictable behavior into products traditionally designed around explicit rules and known transitions, making it essential to distinguish where autonomy is useful from where reliability is mandatory. Products can let AI interpret intentions and construct workflows while using deterministic execution, visible uncertainty, confirmation steps, and clear recovery mechanisms to protect consequential actions. Designing effective agent experiences increasingly means defining boundaries around what AI may decide, when humans must intervene, and how users can understand, correct, or stop an autonomous process.

Drawesome is a drawing toolbar for React. Seven pens, an eraser, SVG and PNG export, no dependencies beyond React. Two lines to drop into an app.

I work on a lot of creative tools, and many of them benefit from the ability to draw. Annotating a screenshot, marking up a frame, circling the bit that's wrong. I kept building the same thing over and over, so I finally made it a package.

Most of the work went into the toolbar. It changes shape rather than swapping panels: pick a colour and the row of pens becomes the palette, open the size controls and it becomes two sliders, minimise it and it rolls up into a disc with the tool you're holding still in it. Every state morphs smoothly into the next.

Getting started

npm install drawesome

It fills its parent container. Set a height on the wrapper.

import { Draw } from 'drawesome'
import 'drawesome/styles.css'
 
<div style={{ height: 480 }}>
  <Draw />
</div>

The tools

Pencil, Pen, Fineliner, Marker, Highlighter, Brush, Fountain Pen, Eraser.

Each pen behaves like the thing it's named after. The pencil, pen and brush thin out the faster you move, while the fineliner and highlighter keep a constant width. The fountain pen responds to direction instead: thick one way, hairline the other. No two strokes come out quite the same.

The eraser takes away area rather than whole strokes, so you can rub out part of a line and keep the rest.

Making it yours

Drawesome is opinionated on purpose. I wanted the defaults to be the version you actually ship, so getting something that feels right doesn't require tuning anything at all. Everything below is for turning things off or moving them around.

You can pick the tools and the order they sit in, and switch off anything you don't want:

<Draw
  tools={['pencil', 'marker', 'highlighter']}
  controls={{ undo: false, clear: false }}
/>

theme takes light, dark or auto, which follows the reader's system setting. The bar above is on auto, so if your system is set to dark mode, the bar will be too.

placement puts the bar on an edge, and inset and align control exactly where it sits. motion is how it arrives and leaves, coming in off whichever edge it's on. draggable lets people pick it up and move it themselves. swatches replaces the palette with your own colours.

Two props change how it's drawn: look="studio" lights the tools as objects instead of shading them flat, and depth sets how much shadow and sheen the bar gets. The demo above uses studio.

The canvas is up to you. Give background a colour, or set it to transparent and the component paints nothing at all, so whatever is behind it shows through. That's how the demo above sits on graph paper: the paper is just CSS on this page.

<div className="your-paper">
  <Draw background="transparent" />
</div>

The bar is only as wide as the tools in it, so on a phone the default set runs off both sides of the screen. A phone has far more height than width though, so under 680px the demo stands the bar up on the left edge and trims the toolset:

<Draw
  placement={narrow ? 'left' : 'bottom'}
  tools={narrow ? ['pencil', 'pen', 'marker', 'highlighter', 'brush'] : undefined}
  controls={narrow ? { undo: false, clear: false, opacity: false, custom: false } : undefined}
/>

controls lets you switch size and opacity off separately. That matters on the vertical rail, where two sliders stacked on top of each other end up taller than the canvas, so the phone demo keeps size and drops opacity. Turn both off and the button that opens them goes too.

chrome={false} removes the toolbar entirely and leaves you the surface. DrawSurface, Toolbar and the useDrawing hook are all exported separately if you'd rather lay the pieces out yourself.

To get the drawing out, put a ref on it. toSvg() returns a string, toPng() returns a file, and download() saves either. What you get back matches exactly what was on screen, erasing included.

await draw.current.download('sketch', 'png', 2)

Props

Surface

• board: { w, h } A fixed drawing area, in board units. Left off, the drawing is whatever size the element is.
• background: string "#ffffff" Any CSS colour, "transparent" to paint nothing so whatever is behind shows through, or "checker".
• initialStrokes: Stroke[][] What to open with, for restoring something saved earlier.
• onChange: (strokes) => void Fires on every finished stroke and every erase.

Tools

• tools: PenId[] all seven. Which pens appear, and in what order.
• eraser: boolean true.
• ink: "auto" | "shared" | "per-tool" "auto" Whether picking a colour changes every tool or only the one in hand.
• swatches: string[] 18 built-in. Your own palette.
• look: "classic" | "studio" "classic" How the tools are drawn: shaded flat, or lit as objects.
• gauge: boolean false. Print the current size on the barrel.

Chrome

• chrome: boolean true.
• placement: "bottom" | "left" | "right" "bottom"
• inset: number | string 20. How far the bar sits off its edge.
• align: "start" | "center" | "end" "center".
• draggable: boolean false.
• settings: "bar" | "tool" "bar".
• controls: { color, size, opacity, undo, clear, custom, minimize } all true.
• depth: "flat" | "soft" | "regular" | "strong" "regular".
• motion: "rise" | "none" | { in, out, duration } "rise".
• theme: "light" | "dark" | "auto" "light".
• tooltips: boolean | TooltipOptions true.
• shortcuts: boolean true.
• startMinimized: boolean false.
• drawWhenMinimized: boolean false.

Ref handle

• toSvg: () => string.
• toPng: (scale?) => Promise<Blob>.
• download: (name?, format?, scale?) => Promise<void>.
• getStrokes: () => Stroke[].
• setStrokes: (strokes) => void.
• undo: () => void.
• redo: () => void.
• clear: () => void.
• getSize: () => Board.

Every pen has a keyboard shortcut, shown in its tooltip. E for the eraser, [ and ] for size, ⌘Z and ⇧⌘Z for undo and redo. Hold Shift while drawing and the stroke locks to the nearest of eight directions.

Potentially awesome

It's called Drawesome, which is a lot to live up to. For now it does the thing I made it for: the next time something I'm building needs drawing, I just drop it in.

I'll let you draw your own conclusions.

Footnotes

1. Inspired by Apple's markup tools, and how far they take the skeuomorphism. Pens in a tray beat a row of icons.
2. If you want to assemble a drawing tool from parts instead, tldraw or Excalidraw will suit you better.

React

Installation

npm install thinking-orbs

Usage

import { ThinkingOrb } from 'thinking-orbs';

<ThinkingOrb state="searching" size={64} />

React Native

Installation

npm install thinking-orbs-native @shopify/react-native-skia react-native-reanimated

thinking-orbs-native is not on npm yet — it lives in this repo at packages/thinking-orbs/ports/react-native/thinking-orbs-native. Expo needs expo run:ios / run:android (native modules).

Usage

import { ThinkingOrb } from 'thinking-orbs-native';

<ThinkingOrb state="searching" size={64} />

SwiftUI

Installation

// Package.swift — or Xcode: File › Add Package Dependencies… › paste the URL (Branch: main)
.package(url: "https://github.com/Jakubantalik/Libraries.dev", branch: "main")
// …and in your target's dependencies:
.product(name: "ThinkingOrbsKit", package: "Libraries.dev")

Usage

import ThinkingOrbsKit

ThinkingOrb(state: .searching, size: .px64)

Orb replaces the spinner in an AI "thinking" state with nine hand-tuned animated states. It ships zero runtime dependencies and needs React 18 or newer.

Props

• state: "working" | "searching" | "solving" | "listening" | "connecting" | "weaving" | "composing" | "breathing" | "shaping"
• size: 64 (chat-avatar scale) or 20 (inline-text scale) — each is separately tuned
• speed: multiplies the animation clock, default 1
• dark: boolean, picks the light or dark tuning
• paused: boolean, freezes the animation

Full article content is not available for inline reading.

Read the original article →

A demo can look polished and still be hard to follow. The cursor moves, a panel opens, the screen zooms, and a new state appears. To the person who built the product, every change is obvious because they already know what is supposed to happen. A first-time viewer has none of that context and is trying to work out where to look while also understanding what each action means.

Demo design is partly a UX problem. Clarity depends on how attention moves through the workflow as much as on visual polish. The most useful place to examine a confusing demo is usually the transition from one interaction to the next.

A Demo Is a Sequence, Not a Collection of Screens

A single interface can look perfectly clear in a screenshot and become confusing once it starts changing. Imagine a CRM demo where the presenter opens a customer record, edits a field, saves it, and then switches to another panel to reveal the update. Every screen might be understandable on its own. Following the relationship between them is harder.

The viewer has to remember where the action started and notice what changed afterward. If one transition happens too quickly, the rest of the workflow becomes harder to interpret.

For example, when demonstrating sales pipeline software, showing how a contact’s activity history relates to an open sales opportunity gives viewers a reason to follow the transition. Without that context, switching between records can look like a series of unrelated actions.

Reviewing a demo screen by screen misses that problem. Watch the transition itself instead. Someone unfamiliar with the product should be able to tell what triggered the change and where their attention belongs immediately afterward.

Attention Needs a Clear Priority

Someone using a product controls the interface directly. A demo viewer watches somebody else move through it, which puts more pressure on visual cues to direct attention.

The principles of visual hierarchy also apply to learning interfaces, where the placement of content, typography, and visual cues helps people identify what matters most. In product demos, a clear hierarchy makes each action easier to follow as the interface changes.

If the presenter is explaining a filter while notifications animate in the corner and nearby controls compete for attention, the viewer has to decide what to ignore. Visual polish doesn’t solve that competition.

Reduce movement around the action being demonstrated. A zoom or highlight works when it isolates something the viewer might otherwise miss, but giving every click the same treatment quickly turns emphasis into noise. Annotations deserve the same restraint. A label is most useful when it resolves genuine uncertainty rather than narrating something already obvious on screen.

Timing Matters After the Click

Moving to the next step before the previous one has registered is an easy way to lose someone.

Suppose the presenter clicks “Generate report.” A chart appears, but the demo immediately opens the export menu. Someone familiar with the software knows that the report was created successfully. A new viewer may still be working out what changed.

A brief pause gives the new state time to register. The right amount depends on how much changed on screen. A minor button state barely requires attention, while a dashboard that reloads with new information deserves longer.

This doesn’t mean making every demo slower. Dead time is still dead time. The pacing simply has to leave enough room for meaningful changes to land before attention moves elsewhere.

Instructions Work Best Before the Action

A prompt such as “Click Settings” is easier to follow when the viewer sees it before their attention has already moved somewhere else.

Timing matters as much as wording. An instruction that appears after the cursor reaches the control behaves more like a caption for something that already happened. If it arrives too early, the viewer may read it and then search the screen without knowing where to begin.

Place guidance close to the action and make it specific enough to remove ambiguity. “Open notification settings” carries more information than “Click here.”

Familiar interactions don’t require the same level of explanation as unusual ones either. Opening a recognizable menu may take very little guidance. Choosing between two similar options with different outcomes deserves more context.

Choose One Outcome for Each Demo

A demo gets harder to follow when it tries to prove too many things at once. The temptation is understandable, especially when a product has dozens of features worth showing. But the viewer needs a clear reason to care about the sequence.

Before recording, I would write down one sentence describing what someone should understand by the end. For example, “A sales manager can identify stalled deals and decide which opportunities need attention.” That gives the demo a useful boundary.

The next step is choosing the actions that actually support that outcome. Opening the sales pipeline, filtering inactive deals, and inspecting one opportunity might be enough. There may be useful reporting, automation, and customization features nearby, but including them could turn a focused walkthrough into a product tour.

It also helps to distinguish what viewers need to see from what they can reasonably infer. A demo about identifying stalled deals doesn’t necessarily need to show how every contact was created or how each pipeline stage was configured.

Once the sequence is planned, review every step against the original objective. If removing an action doesn’t make the outcome harder to understand, it may not belong in the demo.

The Demo Format Changes the UX

A recorded video and an interactive walkthrough create different relationships with pacing. Video gives the creator control over timing, which works well when a particular rhythm or explanation matters. An interactive demo transfers some of that control to the viewer, who decides when to continue.

The format doesn’t rescue weak information design. Poor hierarchy or an easy-to-miss state change will still cause confusion. Format becomes a meaningful design choice once you know how the audience needs to experience the sequence.

Screen Studio is centered on recorded screen content. When a demo calls for a different balance between recording and viewer interaction, comparing recording and walkthrough options gives designers a way to evaluate formats around the experience they want to create rather than treating every demo product as interchangeable.

A tightly narrated feature explanation may work better as video. A workflow where the viewer benefits from stopping at each action may be easier to understand when progression is under their control.

Zoom Without Losing Orientation

Zooming into a small control can make it easier to see, but going too far removes the surrounding context that tells the viewer where that control sits in the product.

The problem is especially noticeable in interfaces with sidebars or multiple panels. If a demo repeatedly cuts between tightly cropped areas, someone new to the product may understand each individual click without understanding the larger workflow.

Keep enough of the surrounding interface visible for the highlighted control to remain connected to the screen the viewer just saw. After a close zoom, returning to a wider view can also signal that attention is about to move somewhere else instead of forcing the viewer to infer the shift from cursor movement alone.

The Outcome Deserves the Focus

The important information arrives after the click, when the interface changes. Yet many demos devote more visual attention to the action itself. The cursor gets highlighted, the view zooms toward a button, and the outcome appears only briefly before the sequence continues.

Give meaningful results enough time and visual weight. If a setting changes product behavior, let that behavior become visible. If the workflow creates something new, give the viewer a moment to see where it appeared.

There is a useful editing test here. When the outcome of a step is difficult to identify, either the presentation needs work or the step may not deserve space in the demo at all.

Use Realistic Data to Make the Workflow Credible

The information inside a demo affects how easily someone can understand what they’re watching. Perfectly designed interfaces become less convincing when every customer is called “Test User” and every project has the same placeholder description.

Realistic sample data gives viewers context. A sales demo might include several opportunities at different stages, with recognizable company names, deal values, and recent activities. When the presenter opens an overdue opportunity, the viewer can understand why it needs attention without stopping to decode the example.

The details should also remain consistent across screens. If a customer appears under one company name in the contact list and another in the related opportunity, the viewer may wonder whether they’re looking at the same record.

That doesn’t mean using actual customer information. Fictional records can reflect believable situations without exposing personal details or confidential business data.

Before recording, check that the dates, statuses, and related records support the story being demonstrated. A realistic example also needs to behave consistently when the presenter filters, edits, or saves information.

Review the Demo as a First-Time Viewer

The person recording a demo carries a lot of invisible knowledge. They already understand the terminology and know what every click is supposed to produce. That familiarity makes certain gaps surprisingly difficult to notice while editing.

Before publishing, watch the sequence for moments where attention jumps unexpectedly or the consequence of an action disappears too quickly. Pay particular attention to transitions that feel obvious only because you already know where the workflow is going.

One useful test is to show the demo to someone who hasn’t used the product before. Give them a simple question to answer, such as where a generated report is saved or what changed after a contact record was updated. Let them watch without providing additional explanations.

Afterward, ask them to describe what happened during the steps you consider most important. Someone may say the demo looked clear while still misunderstanding which record was edited or where the result appeared.

Notice when they hesitate, rewind, or ask what happened. Those moments reveal where an instruction, transition, or visual cue may need attention. Sometimes a confusing step needs a longer pause. Other times, removing an unnecessary action solves the problem.

A product demo doesn’t have to reproduce the full experience of using the software. A more useful final check is whether each step leaves the viewer oriented enough to understand the next one. If people have to mentally reconstruct missing transitions, more polish won’t solve the underlying design problem.

OpenAI will acquire Pierre Computer Company to enhance Codex's developer tools, including Code Storage and other open-source projects.

Conductor is joining Meta

Conductor is joining Meta. Thank you for coming along for the ride!

We'll be winding down Conductor over the next weeks and months:

• Conductor Cloud goes read-only on November 13 and shuts down on November 20.
• Local Conductor keeps getting new models and critical bug fixes until early 2027.

To move a cloud workspace and its chats to your Mac, right-click it and choose Transfer to local. To download all your data, go to Settings → Account → Export data.

If you need anything, email [email protected].

Improvements

• Add your own completion sounds in Settings → General. Pick a sound file, name it, and choose it like any other sound.
• Archived cloud workspaces show their PRs, last known changes, and file tree in the right panel.
• Added GPT-6.1 Terra to the Codex model picker.

Fixes

• Fixed the Claude account usage display when Claude Code reports newer limit data.
• Fixed closed chats in chat history showing a recent time when nothing had happened in them.
• Messages that agents send to other agents now show a "Send message" label with the recipient and contents.
• The rename workspace dialog now prefills the name shown in the sidebar instead of the worktree name.
• Long PR titles no longer hide the PR number in the PR view.
• Expanded Mermaid diagrams fill the window instead of opening in a narrow popup.

Kimi K3.1 Pro, the latest in the 3T-class models, excels in multimodal tasks, improving outputs in coding, 3D creation, and factual accuracy with a million-token context window.

Apple quietly lowered the daily spending cap on AI models for its employees last month. Some engineers had their budgets cut from $300 to $200, and the company is planning further cuts for some engineering teams that may potentially reduce their daily allowances to as little as $100. Groups outside of engineering may have their limits reduced to $25 from $100. Employees say that few workers were using their full $300 daily allowances, making the previous limits unnecessarily generous.

The new version of X.com's web app was built by five engineers working with AI coding agents in under six months. It loads pages significantly faster than the old web app over slow connections, and it already serves logged-out users and the pages that search engines crawl. This post covers why X.com was rebuilt, how the new web app is being rolled out, and how the old and new apps compare today. It also looks at the performance work completed since logged-out traffic moved over.

AI on the Ballot

From Bloomberg this morning at 2 a.m. Central:

Democrats won control of both chambers of the US Congress in a midterm election landslide that amounted to a rejection of President Donald Trump following widespread voter discontent with the economy and the war in Iran. Across the country, Democrats scored victories in GOP strongholds, flipping at least seven Senate seats and winning House races in districts Republicans easily carried in 2024. Several news organizations projected that Democrats would win the House, while Decision Desk HQ projected they took the Senate.

I have no doubt that Iran and the economy played significant roles in this election; what stood out to me, however, was very much Stratechery fodder. Specifically, I watch a lot of sports, and particularly this fall, watched a lot of baseball. My Milwaukee Brewers — excuse me, my World Champion Milwaukee Brewers — demanded my full attention, which also meant I saw a lot of campaign ads, and by far the most common topic, at least here in Wisconsin, was data centers. Moreover, it was never entirely clear which way it cut politically: both parties were anti-data center, accusing their opponent of being the opposite.

Meanwhile in Texas, from Yahoo Finance:

A strong showing by Democrats in Texas swept Gina Hinojosa into office as the state’s first Democratic governor since 1990 in a contest closely watched by Big Tech companies. The state is considered a bellwether for government restrictions on AI data centers…Hinojosa, Texas’ first Latina governor, has pledged to impose a moratorium on data center construction in Texas, which accounts for more than 25% of planned US capacity by 2030.

Republican incumbent Greg Abbott, I would note, already declared a moratorium on new data-center permits in September; that’s how much of a hot-button issue this is, including in the state that is the biggest opportunity and beneficiary of the data center buildout. So yeah, this is a Stratechery topic of concern.

The Data Center Veto

Earlier this year, while writing about data center opposition, I said:

There really wasn’t widespread opposition to data centers when they were being built for the Internet generally; indeed, local governments would compete for them, eager for the economic benefits that came during their construction and the long-term tax benefits once they were operational. In other words, it seems pretty clear that the current wave of opposition can’t be divorced from AI — you know, the technology that in the best case scenario is going to take everyone’s jobs, and in the worst case scenario end the human race.

I do not, I don’t think, need to explain to you why this is not a very compelling message, and, in the very long run, I do think that humans will have economic value. At the same time, it’s hard to explain the huge amount of investment that is going into AI, not just at the model level but also in terms of data centers, without admitting that a big part of the thesis is that AI can not just increase the top line for companies, but also increase the bottom line — i.e. replace the jobs of some number of humans. Again, I’m generally an optimist here, but this already happened with the first wave of IT.

That leads to an interesting contrast to globalization: when companies were closing down American factories and laying off workers and moving operations to China, none of the affected towns or workers had a say. They just suddenly no longer had a job, and a huge number of cities across the Rust Belt no longer had a reason to exist. People simply had to move, or worse, retreat to things like alcohol or drugs. AI, however, is the opposite: building data centers requires permission, which is to say that people actually have a say. Again, I am not at all saying that these people are well informed about data centers, or about the economic impact on their communities, much less the economic impact of AI generally; what I am noting is that people who didn’t have a say in globalization are suddenly finding they do have a say about AI, and it’s not a surprise they are expressing their disapproval by blocking data centers.

That message was loud and clear last spring; now it is deafening, and it’s tempting to say that tech, particularly the frontier labs, have no one to blame but themselves. In fact, however, some of the biggest culprits may, in the long run, be some of the biggest beneficiaries of the anti-data center wave.

My thesis — driven not just by national results and the Texas governorship, but also the fact that nearly every relevant local ballot measure opposing data centers won or is winning (the only exception so far was in North Dakota) — is that the constraint on AI dispersion has shifted once again. First we were short on compute, but that ramped; now we are short on memory, but that will ramp; we were coming close to being short on power, but that will be rectified. The final constraint is political, and that may be the most imposing constraint of all. Not only is it harder to solve, but it actually interferes with solving the other constraints. Many of the theories about AI assume that it becomes a commodity; I think it’s just as likely we are looking at scarcity for much longer than we expected, which will have ripple effects on everything.

Ten Takes

To that end, here — with the caveat that nothing leads to hot takes you regret like an election — are ten perspectives on what a permanently impaired ability to build might mean. To be clear, I’m not declaring permanency — look at how our elections swing back and forth — but it’s worth considering what the implications might be if Americans don’t change their minds about data centers.

1. The AI Trade Got It Right

The most obvious reason why the stock market has been rocky over the last few weeks is the tightening of credit markets, which I wrote about this summer. We are, needless to say, full on into the equity funding era. At the same time, it seems clear that this outcome is very bad for the AI trade in the short term, but much of the pain may have already been endured.

2. Neoclouds on the Edge

The Neoclouds have been at the forefront of credit concerns, and from a certain perspective, being unable to build data centers has a silver lining in that they couldn’t get the money to pay for them anyways. Moreover, Neoclouds with facilities that are already permitted now have an asset that is going to be scarcer than expected. At the same time, it’s Neoclouds that need new sites and new permits, even as they are likely to have much less political sway than the hyperscalers — who already have more sites they can repurpose or rebuild. It was already getting harder to get capital, relative to the hyperscalers; now you have to layer on that it’s going to be harder to get permission, too.

3. Hyperscalers Are Winners

The downside for the neoclouds is upside for the hyperscalers, who are more likely to grow their share of AI compute than they were before. Moreover, investors may be pleased if the hyperscalers’ ambitions are somewhat curtailed; political opposition is an excuse to moderate spending, knowing that everyone else is in the same boat.

4. Nvidia’s Mixed Bag

Nvidia will almost certainly be a short-term loser. Fewer data centers mean fewer Nvidia chips generally, and a weakened Neocloud set is particularly harmful not only because Neoclouds almost exclusively use Nvidia full-rack systems, but also because Nvidia is back-stopping a huge number of them. It’s the hyperscalers, meanwhile, who are Nvidia’s biggest long-term threat, given their scale and ability to invest in their own chips.

At the same time, a constrained world makes Nvidia’s offerings more compelling. CEO Jensen Huang actually spent an entire keynote making this point back in 2025; I wrote in an Update:

When Huang says “iso power” he means that power is the constraint; the question is how many tokens can you generate given a fixed power envelope, and Blackwell can generate a lot more. These were the numbers Huang gave for a 100 MW data center:

What this means is that the first order of business for an ASIC maker is to match that level of efficiency. That, though, means keeping up with Nvidia’s product development cadence; The Information has a post about Amazon offering instances using its latest Trainium ASIC at a significant discount to the H100. Huang, though, spent this keynote insulting the H100! You can almost hear him speaking to Amazon directly: you spent all this money, and are offering these huge discounts, just to entice developers to lock themselves into an inferior chip, even as reasoning models are going to swamp your available power generation…

Huang is issuing a challenge to every cloud provider tempted to make an ASIC: do you really think that you can keep up with this, and risk running out of power capacity because your chips aren’t efficient enough? Don’t even try.

A world without power or data center constraints is one where it is, in the very long run, very difficult to maintain Nvidia’s margins; once those constraints start to bite, however, an advantage in tokens/megawatt is worth a lot of money. Go back to my point about the hyperscalers: one way to generate more tokens is to build a new data center; another way is to rebuild a data center with new Nvidia chips.

5. Advantage China

China is the inverse of the scenario that Huang laid out: the country has plenty of power and the ability to build a lot more, but they don’t have leading-edge chips. Some of the advantages of leading-edge chips, however, can be overcome by simply throwing tons of electricity at the problem. From a 2025 Update about the Huawei CloudMatrix 384 supercomputer:

The CloudMatrix 384, which is a supercomputer consisting of 384 chips, takes up dramatically more space, uses dramatically more power, is almost certainly dramatically more expensive to make, and is dramatically more brittle than Nvidia’s NVL72; there is no one in the world who would choose the CloudMatrix 384 over the NVL72 if they had the choice.

That’s the thing, though: China doesn’t have the choice, because of U.S. export controls. The country’s saving grace is that they are operating on different constraints than the U.S.…China — which actually builds power generation — is not iso power; they are iso compute: Huawei’s goal with the CloudMatrix 384 is to get as much compute as possible, power efficiency be damned.

In the fullness of time — i.e. as China figures out leading-edge chips — this may be an insurmountable advantage.

6. Data Centers in Space

When SpaceX released their S-1, I explicitly pointed to political opposition to data centers as one of the company’s most significant upside scenarios:

The third question about data centers in space is if there is a stick. Specifically, while I think that racks-in-space are both a lot more viable than people think, and a lot more relevant to agentic inference than current modes of compute, it is at the end of the day cheaper and easier to build on earth, all things being equal.

All things are not equal, however: right now we are at the very beginning of the AI buildout and already one of the biggest constraints is not just power (expected), but zoning (unexpected). I wrote in an Update last week:

In that Update I made the case that data center builders — and by extension the companies that use them — should straight up pay people for permission to build data centers in their communities. At a minimum, however, that increases the costs of terrestrial data centers. What seems very plausible in the long run is that the demand for compute ends up being so large that there eventually is nowhere left to build, making the vast expanses of space not just an alternative but in fact the only choice.

This is where I come back to my experience watching these campaign ads: this isn’t a partisan issue, where the pendulum will swing back in two years. Both parties see opposition to data centers as a winning cause, and not just nationally: that thread has multiple examples of local officials straight up recalled for approving data centers in their localities. Space will be incredibly difficult, but difficulty is all relative! Moreover, to the extent opposition is permanent, the more this actually reduces the risk of data centers in space, because investors will have more confidence in there being enduring demand.

7. The Frontier Labs Benefit

If the hyperscalers had a red queen problem, the frontier labs have it even worse: the biggest revelation from Anthropic’s S-1 was that their inference margins were very high (good!), which meant that their massive compute costs were actually in R&D; this is bad because that R&D spend is governed by competition with the other frontier labs, and absent constraints, that spend looked set to surpass revenue sooner rather than later. Now, however, it is the public that is effectively demanding that the frontier be paced, which is great for the frontier labs’ financial outlook.

The upside goes further than that: the point about efficiency being more important in a world of constraints doesn’t just matter for chips, but also for models. Devoting limited compute to inefficient and costlier-to-serve Chinese models is a poor trade if there isn’t enough compute. Moreover, open models may be at greater regulatory risk, as Democrats seem much more likely to pass laws that ultimately favor the frontier labs.

There are some counter-arguments. First, if compute is constrained, and thus more expensive, then that will increase the drive to right-size models for jobs, which is a big argument in favor of open models; the fact that compute won’t be a commodity means that the frontier labs’ lower cost to serve will never come to bear on the low end of the market. And, it’s worth noting, it will be harder for the frontier labs to build their own compute, leaving them dependent on the hyperscalers; big tech wins again.

8. Apple Gains

The most obvious advantage for Apple is that in a world of constrained compute, inference on the edge will be that much more important. Another advantage is that any slowdown in the dispersion of AI is good for a company that dominated the previous paradigm.

The biggest advantage of all, however, is that any slowdown in the AI buildout offers hope that the memory crunch will ease. This will take a while, to be sure, but no company would be a bigger beneficiary of the world running out of places to put AI chips than Apple.

9. Startups Suffer

AI has drawn a great many battle lines, not just in terms of data centers, but also within AI, and between AI and the rest of tech. Specifically, anything that strengthens the frontier labs is likely bad for the rest of the startup ecosystem. In a world with fewer data centers, startups will have less access to cheap compute, even as a slowdown in capabilities both means it takes longer to build compelling products and also gives the frontier labs time to actually build products that secure their ownership of the end user.

10. The Human Factor

One major fear that investors have had about the data center buildout is that there would be too much capacity, causing prices to plummet and investors and creditors to lose their shirts; that scenario, however, would be great for users, who would suddenly have access to incredibly cheap compute. Of course most users aren’t going to use AI directly; what they will miss out on is the equivalent of the Web 2.0 wave of free Internet services that were predicated on compute being free. Now there’s a good chance that AI is going to have meaningful marginal costs for a long time to come.

At the same time, while I have been an optimist about humans in an AI future, there is no question that we were and are facing a wrenching change as intelligence becomes a commodity. It follows, however, that if it doesn’t become a commodity — or if that change takes longer than expected — that humanity will have more time to adapt. Maybe this is a break we needed; what is increasingly clear is it’s the break Americans wanted.

That noted, there is a long history of citizens demanding the ends and opposing the means, and it’s the demand that wins in the end. The big difference today is that, unlike the first few waves of tech, the industry is going to need to do some convincing, and break the habit of assuming everything it does will get the benefit of the doubt. AI wasn’t technically on the ballot, but it was implicitly, and will be forevermore.

Bug Finding Considered Harmful?

…is a question I’ve been asking for a week now, while developing a new property-based testing (PBT) tool in the meantime if you’re one to appreciate irony. As you know, a title with a question usually means the answer is no; but I wouldn’t expect I would ever be in a position to ask the question in the 6 years of working on this, so I thought it’s worth a discussion. Let me step back a bit though.

Property-based testing (PBT) is an “advanced” method of software testing; instead of testing a particular behavior as we classically do, we essentially define a “blueprint”, traditionally called a property. A property is a general fact about the system under test, like “running this program with ANY input should not lead to crash”, “addition of ANY TWO NUMBERS should be commutative”, or “my physics simulation should ALWAYS conserve momentum”. We can express these properties quite easily by writing functions from states or inputs to booleans; we then test them by randomly sampling the input space defined by inputs to those functions.

The job of a testing researcher is, well, finding bugs, locating their root causes, and essentially helping the maintainers fix those bugs. Of course, these are essentially the way we work, not the value proposition; in my opinion the value proposition of testing research is to help build reliable software systems. PBT is only one of the approaches here, fuzzing, deterministic simulation testing, formal verification… all serve the same purpose with different trade-offs in different situations and domains.

A critical tension of testing research is the separation between the tester and the maintainer, the tester invariably approaches the system from outside, as a separate entity than the maintainer. The tester neither understands the system as well as the maintainer, nor are they incentivized or able to do so. I believe this tension is reaching a critical point with the AI age, and I am interested in understanding where we stand.

Barbarians at the Gate: Bug Reports Considered Harmful?

In the last month I apparently filed 500+ bug reports. I'm honestly quite proud of it; it’s the dream of a testing researcher to find novel bugs in well-tested systems. It's like you’re an athlete breaking a world record, at least a much more nerdy and much less impressive version of it. I tried to be very gracious when filing the bugs, I didn’t let an agent dump all of them but rather personally triaged as much as possible; but I couldn’t let out the feeling that if billions of people haven’t hit these cases, maybe they were just not that important in the first place.

The fact that I might be partially responsible for the delay of Postgres19 is quite frightening; although the concept of “fuzzer fatigue” isn’t really new, Z3 prover was a popular target for fuzzers, which at the time led to some heated discussions, SQLite maintainers operate at an incredible speed of fixing some bugs in 20 literal minutes, but I am sure they are unsurprisingly exhausted.

The single best argument in favor of bug finding is security, if we don’t find the bugs, the attackers will, and they will do bad things with them; this works particularly well for classical fuzzing. But especially with more recent work that I’m a part of where we test functional correctness properties of the systems, I think the value proposition shifts.

Don’t get me wrong, bugs are bugs, in all the bug reports I submitted it was only once that we discussed with the maintainers if the behavior was actually a bug; the question is more practical, is it worth fixing all the bugs in a software even if no practical user will ever experience degradation because of the issue?

Even more so; is it worth spending valuable maintainer time on fixing a 10 year old bug nobody has ever hit in exchange for building a new capability that the users will actually use?

The position I came to conclusion is, to the damnation of my own effort in finding old bugs in existing systems, that testing is most valuable when it can go hand in hand with development. Testing that comes after the fact can be valuable for security vulnerability and silent failures; and we indeed cannot know what types of bugs we will encounter when we are testing a system, so when in doubt, we must test. We should, however, be selective in the bugs we report; even more so, the maintainers should be selective in the bugs they choose to fix. The ideological position that we must simply fix every single bug does not seem feasible to me at this moment.

I came to this conclusion through the asymmetry in bug identification vs bug resolution. The reason I was able to manually go through 500+ bugs is because bugs are quite verifiable. Given a brief snippet, I can review the snippet, the expected behavior, the actual behavior; and with very high confidence present a report to the maintainers. Not only the fix for these simple snippets can range from a single line to multiple hundred lines, but also there are many possible fixes for a given bug. It is sometimes discussed if software has a finite or infinite number of bugs, which I believe is the wrong question. I believe software there is a finite set of fixes to a given software to fix all the bugs that violate a given property, however it is improbable that those are the fixes we actually apply. Hence, given a greedy approach where we apply the “simplest” fix for all bugs where we fix only the neighborhood of the test case we currently inspect, we might actually live in a world where we have to do infinitely many bug fixes. The fixes, therefore, must be carefully crafted, forward looking, and essentially much less verifiable than the bugs themselves.

In the context of this asymmetry, I posit that bug finding will continue to overwhelm bug fixing, so it is left to us to account for this asymmetry so that we can continue to build software. Even in the context of formal verification where we can technically enumerate all bugs that invalidate a stated property, we will simply find more and more properties of a system to test for; correctness to me seems like a never ending pursuit of excellence.

I make these arguments in the context of in vitro testing, testing done after the fact as a method of hardening the system; on the other hand, I believe in vivo testing is more useful than ever, because we of course want to build correct systems given that we do not need to sacrifice usefulness, expressivity, performance… Especially as we get better verification capabilities, leveraging those capabilities to speed up the development instead of slowing it down could, and perhaps should be our norm.

🧠 Payments are the new ads

The fight between network tokens and balances could reshape who owns the financial customer.

Agentic commerce sucks for most people.

For example Scott Wessman picked his Amex in Muse. Link charged the Amex, then paid Best Buy with a Visa card of its own. When one item failed, Best Buy asked for the security code on that Visa, and he had no way to find it and nobody to call.

Most people aren’t going to put up with that. Six in ten UK adults told YouGov they’d stop using an AI shopping agent after one mistake.

Scott asked for the obvious fix, which is to use the card he picked and let the store charge it.

That’s not happening because the banks, card networks and merchants haven’t figured out how liability will work. Today’s solution, sticking a virtual card in front of your actual card is causing breaks in the experience.

Hold that idea in your head for a second and consider that Stripe Link users via Instinct spend on average $1,300 per month. There’s a signal here that when a user is willing to put up with it, agentic commerce is incredibly useful.

What happens next is a foot race to replace the virtual cards (or giving your agent your 16 digit card number). There are two approaches, and I suspect we end up with both.

1. The banks, networks and merchants figure out liability and network tokens like we did for Apple Pay or
2. Agents get their own stablecoin balance, card (and even network token), so they never need to wait for your bank.

And this battle is urgent. The big platforms will keep pushing, because AI is already cutting into the ad revenue that pays for them.

Four ways an agent pays

X user vigstar1 mapped the four ways an agent pays on card rails today.

The first two are how most agentic commerce payments happen today. And they’re the ones that break most often.

• The agent types in your real card. Your bank sees the shop and thinks you made the purchase. But the merchant sees a robot inserting raw card details and it looks like a fraud risk.
• The agent pays with a one-time card. Your bank sees a charge from the platform that made the virtual card (e.g. Stripe), not what you bought. This is what happened to Scott Wessman where security breaks.
• The agent pays with a network token issued to it by the bank, which is where Mastercard wants to go. Your bank sees the shop again. This isn’t widely supported by banks yet, because they’re unclear on how the liability will work.
• The agent spends a balance you loaded up front. (e.g. Stripe balance on Instinct) Your bank sees one top-up and never sees the agent. The liability in this case all lives with whomever is holding the balance for the agent.

Often Instinct stores your real card, security code included, and then types it into the checkout. Elon Musk told people they could send Grok Bot a photo of theirs. This seems remarkably insecure in the long term.

Gabe Suby noted from Mastercard’s earnings that Mastercard doesn’t see virtual cards as a long-term solution.

That leaves two options.

1. Network tokens
2. Stablecoin balances

I think the answer is AND, not OR. Your bank card and an agent’s balance could both use network tokens. What interests me is how much spending stablecoin balances can win while the banks are still working out liability, and how much stays there once they catch up.

The one-time card was a bridge

The UX of virtual cards for agents fails to deliver on a major benefit of agents. Them waiting to buy something when its on sale or launched.

For example, Tom Noyes tweeted that it defeats the purpose of an agent. He says “nobody wants to approve concert tickets at 2 a.m.” And yes, I barely get enough sleep as it is!

It’s also what went wrong with the Best Buy order. The reality is agentic commerce consistently breaks when merchants aren’t ready. If there’s no network token available, and Link isn’t supported, it falls back to that one-time card to try and make the purchase work.

Swapping in a different card also breaks your card’s rewards and muddies its purchase protection.

It’s also not a particularly profitable endeavor. vigstar1 estimates Stripe keeps about 40 cents on a $100 purchase paid from a credit card, before its own costs. There’s a lesson from history here, it rhymes with what happens in the early days of mobile commerce (there’s a term from the past).

Before we had Apple Pay, we had “staged wallets.” PayPal and the old Google Wallet used versions of that model: the wallet sat between your card and the merchant, leaving the funding bank with less detail about the purchase. In 2013 Mastercard introduced a fee for some of those “staged” wallets.

Network tokens worked for Apple Pay

Apple did a lot of things right with Apple Pay.

Back then we turned 16 digit card numbers into device tokens (DPANs) and network tokens. The little image of the card you see in your Apple Pay wallet is representing that secure “token” that is bound to your device.

Chase was one of the six launch banks in 2014, Apple reportedly took 0.15% of each credit card purchase, and one bank executive said at the time that the deal “still puts us at the centre of payments.” Every purchase also needed your fingerprint, so your bank knew you were there. It reduced fraud, it had clear liability protections, and over time it reduced the amount of cash payments and increased the card volume, creating new revenue for banks.

We’re not there yet with agents. We’re still so very early.

Agents don’t yet have a universal equivalent to the device token (DPAN). An agent token. The card networks have proposed their approaches, but until liability is resolved, the banks aren’t rushing to adopt.

That agreement is what takes time.

Prashant Sharma of JPMorgan Payments told American Banker in May, “Ideally, the entity who made a mistake should be liable,” and “I don’t think that we have an answer at this particular point.”

The problem with agents is there’s no authentication moment like Face ID with Apple Pay.

Visa’s answer is asking users to approve with a passkey, but right now, according to vigstar1 they’re also giving every major agent platform a waiver to that requirement. And, quelle surprise, Chase cards cannot be added in this way to many of those agent platforms.

Chase is big. They can afford to wait.

But the market has already found another solution: giving an agent its own balance to just do things.

Give the agent its own money

Instinct just launched Balance. Users can set a budget for their agent to make purchases on their behalf without having to step in and approve. You can set limits and budgets for each purchase, for example, when a ticket pre-sale launches.

The example in the tweet below shows someone adding $700 to their agent’s balance, asking to buy their favorite lunch every day for a week, and then get concert tickets.

Noyes also says what your bank sees now.

With a prefunded balance, the consumer’s bank sees one load, authenticated by the consumer, and never sees the agent.

With a balance, you make the permission question much simpler. Instead of asking if the agent has permission to buy this thing, this one time, you just ask if there’s enough money. If there’s $637 left, the agent can spend at most $637.

Of course, a balance doesn’t prove the agent bought what you asked for, which is why the banks are rightly worried about liability.

For Link Balance, the agent gets stablecoins and a wallet (by Privy on Tempo*). Every purchase still runs through the card networks. But the agent doesn’t need a bank account.

It’s a card for acceptance, a stablecoin for the balance and stored value.

Stripe (or whomever makes the stablecoin balance card) makes more money this way too. When you top up with a debit card from a bigger bank (> $10 billion assets), Durbin caps the fee at 21 cents plus 0.05% and a cent for fraud prevention, so a $100 top-up costs Stripe about 27 cents.

The agent then spends on a Lead Bank debit card, and Lead Bank is small enough to be exempt from the cap, so the card earns about $1.95 per $100 spent. That leaves about $1.70 per $100 for Stripe and Lead Bank to share before costs, more than four times what vigstar1 estimates a one-time card leaves.

Blocking agents from logging into your bank doesn’t solve this. JPMorgan can stop an agent logging in with your password. It doesn’t (yet) stop you topping up a Link balance with your Chase debit card, unless it starts declining its own customer’s card.

The money stops being a deposit once it’s in the balance.

It’s sitting as a stablecoin in a wallet somewhere else, which means the banks become less relevant in agentic anything.

Every Platform will embrace agentic traffic

Merchants are moving faster than banks.

a16z’s Olivia Moore wrote this about OpenTable integrating with Instinct:

Instinct’s founder, Noah Shinn, agreed. He says businesses now come to Instinct to learn how to rebuild for agents, because people using agents buy more and stick around longer.

This is an enormous market signal.

Even the mighty Walmart is embracing agents. It announced on 21 October that each customer agent will get its own profile inside your Walmart account, and you can approve every purchase or set a limit like $50, $100 or $200. Walmart told customers to think of it “like adding someone as a cardholder on your credit card”.

And the demand is there.

Stripe says people who buy through Instinct spend over $1,300 a month there on average. Muse shoppers bought more than Meta expected, and Meta had to ask Stripe to raise its limits.

People with agents are high spenders, and over time that’s becoming attractive to merchants, which is why they’re starting to support them more and more.

Yes there are still holdouts like Amazon.

But they can afford to hold out until the game on the field suits them more.

The way banks regain relevance is by stepping in and owning an agent’s mistakes. Banks have the interchange to pay for it, the underwriting and a disputes team. If agents sent over what you asked for before paying, banks would get the Apple Pay deal again, with your instructions doing the job of the fingerprint.

For the banks, they could lean on the card networks to introduce fees for virtual cards or “staged” agent balances, but something feels different this time.

The card networks view teams like Meta and Instinct as issuers in their own right.

There’s a very real possibility the agents with balances get their own network tokens.

Agents need to become useful and monetize

The more useful the agent becomes, the more of your spending it can bring through that relationship. The more spending it brings through, the more payments revenue it can get.

But the more agents get used, the less effective the ads business becomes for Google or Meta. Google said on its latest earnings call that lower monetization in AI Mode contributed to slower Search growth. If you assume that trend continues, the ad-revenue fuelled hyperscalers need to chase two things.

1. Compute revenue
2. Services revenue (like payments)

While Google Cloud revenue doubled to $30.7bn. The growth is moving from ads to compute already.

Emad Mostaque said on the Moonshots podcast that we could reach peak ad-revenue growth next year. And if agents are bypassing ads and getting you the best thing, they need a way to monetize helping you.

Payments revenue is a great way to do that.

This is Meta’s explicit monetization strategy.

Zuckerberg said Meta plans to charge businesses a fee when Muse helps complete a sale, and he expects Muse to make more per user than Meta’s apps do today. If Muse is buying things on your behalf, it’s intermediating between the customer and the bank or merchant.

With a balance, some of your money is already in the app.

When your agent knows what you want, Google and Meta might need to serve you fewer ads. But each match could be much more useful, more likely to convert, and worth more to the business paying for it. Less volume, much higher prices, and something that feels much less like an ad.

Payments are another way to monetize that relationship and make up for any revenue shortfall. Then matching what you want with someone who can deliver it would be another. But that’s a whole nother essay.

I don’t think anyone can afford to be caught on their heels. These agent platforms are shipping features at a speed unlike any time I can remember.

Banks could work out how to support agent payments, only to find their customers are already used to keeping money and managing their finances somewhere else.

Would you leave a balance with your agent? Reply and tell me.

Sequoia Capital posted a memo to X on Wednesday morning titled “The Sequoia of Tomorrow” that’s full of surprises. The firm has raised roughly $10 billion in new funds, it says. It is also closing its London office, shutting down its Arc accelerator and its Scouts program, merging its early-stage and growth teams into one, flattening its partnership, and killing the Monday partner meeting.

The framing is forward-looking, but the messaging is very much about rewinding to an earlier time when the team was smaller and focused more narrowly on Silicon Valley.

Sequoia says as much itself. The firm describes coming out of a roughly 20-year expansionary phase during which it built multiple businesses in multiple geographies and says an unintended side effect was hierarchy. Nearly everything being undone here was built during that stretch, under a succession of stewards running from Doug Leone to Jim Goetz to Roelof Botha.

One of the most surprising developments is that the firm is killing two programs that put Sequoia closest to young founders. Scouts, which Sequoia launched around 2009 and, anecdotally, half the industry has since copied in some form, gave small checks to founders and operators to invest on the firm’s behalf; it was a way to see deals through people closer to interesting new founders than any partner could be. Jason Calacanis famously pointed Sequoia to Uber through the program. Sam Altman brought Stripe to Sequoia as a scout, too. Other early scouts included Airbnb CEO Brian Chesky and Dropbox founders Arash Ferdowsi and Drew Houston.

Arc, launched in March 2022, was Sequoia’s answer to Y Combinator: a batch accelerator for pre-seed and seed founders, running several cohorts a year for seven weeks, with admitted companies getting $500,000 to $1 million up front.

Both were bets on being early and being everywhere. Now Sequoia says it wants to put more energy behind fewer people and things.

Also gone is the firm’s London office, which Sequoia opened in 2020. Several people will leave the firm as result. “We simply don’t see the need for a local presence,” the memo says, adding that Europe will keep producing “outlier founders” and that Sequoia can support them from the Bay Area. (If founders didn’t already feel pressured to move to the Bay Area or open an office in the region, they will now.)

Luciana Lixandru, hired from Accel in 2020 as Sequoia’s first partner in Europe, says she was offered a move to San Francisco and declined. (“Europe is where my family is, and where I want to build,” she wrote on X.) She says she remains a partner and will keep her board seats while investing personally in European founders.

For European entrepreneurs, the message is going to be particularly difficult to digest, especially as it follows Andreessen Horowitz shuttering its London office last year and Coatue closing its own in 2024. Sequoia didn’t say it won’t fund Europeans, but it’s definitely reinforcing here that the center of gravity is once again in the Bay Area.

The rewind extends to people, too. The memo notes that Carl Eschenbach, the former Workday CEO, is very much back in the fold (he returned as a full-time partner in March). It also says the team has “reinvigorated the GOAT,” Doug Leone.

Though the nomenclature at venture firms is all over the place — including Sequoia — the memo makes clear there are now seven general partners who primarily own and operate Sequoia: Alfred Lin and Pat Grady — who are the firm’s co-stewards — along with Andrew Reed, Shaun Maguire, Konstantine Buhler, Sonya Huang, and David Cahn, who joined the firm in 2023.

There are other changes as a result. Jess Lee, the firm’s first female partner and an early-stage investor who oversaw its Arc program, is no longer shown on Sequoia’s investor page but rather as an operator in the role of its chief product officer. Stephanie Zhan, an investor who had joined Sequoia in 2015, has meanwhile left the firm entirely, announcing last month that she is launching her own new firm.

Sequoia rarely lets anyone go entirely. Founder Don Valentine famously kept turning up at partner meetings for roughly a decade after handing over the firm. Goetz, who stepped back from his management responsibilities in 2017, is still featured on the firm’s site. Botha is the exception. He was voted out as senior steward last fall in a surprise shake-up days after sitting down with this editor — the firm framed it as a handoff to Lin and Grady — and he completely cut ties with Sequoia this summer, around the time he joined SpaceX’s board.

The changes are sure to make waves. Still, none of them are completely out of character. Sequoia iterates routinely, including, at times, reversing out of earlier moves. Most notably, in 2023, it separated from its China and India/Southeast Asia arms, which became HongShan and Peak XV, ending a two-decade run as a global franchise under one name.

The rest of the memo is structural. It says the team has decided to dispense with its “early” and “growth” team approaches and operate as one. It also notes the Monday partner meeting — a ritual at Sequoia and at nearly every firm — is finished on the theory that founders operate around the clock and their investors should, too. (These may be going away more generally. At least, in a sit-down with TechCrunch at Disrupt last month, the entire Benchmark team suggested it now mostly uses Monday meetings to socialize.)

Sequoia acknowledges the moves come at some cost. “It is scary to break something that’s already working just fine,” the memo says, and painful to say goodbye to good people. Now to wait and see if these were the right calls.

Here is Sequoia’s post in full:

We live in a world of accelerating change. The best founders reinvent themselves over and over again. We must do the same.

It’s been a year since our generational transition. We’ve been busy! We’re no longer evolving the Sequoia of yesterday; we are now building the Sequoia of tomorrow.

Here are a few of the changes we’ve made, and what they mean for founders.

Focus We are best at high-conviction, highly selective venture capital investing. This is our focus. We have removed much of the complexity associated with the Sequoia Capital Fund, sunset our batch accelerator (Arc) and Scouts programs, and streamlined both operating and investing teams. Putting more energy behind fewer people and things means better support for the founders we back.

One Team There is no more “Early & Growth”. There is only Sequoia. We are one team, operating under one shared mission. This should make things more seamless for founders as they go from stage to stage.

London We are closing our London office, which means several people will be leaving Sequoia. This is not about the team — they are excellent. We simply don’t see the need for a local presence. We believe that Europe will continue to produce outlier founders and companies, and that we can continue to provide world class support from our home base in the Bay Area.

Partners We are coming out of a ~20 year expansionary phase, during which we built multiple businesses in multiple geos. One unintended side effect was hierarchy; it required real management to run the operating side of our business, and this crept over into the investing team. We’ve made several internal changes that have the effect of flattening the partnership. This allows every partner to flourish, and every founder to receive the full benefit of Team Sequoia — regardless of who your lead partner happens to be.

Firepower We’ve welcomed two rising stars (Liam and Sonali) and one transcendentally talented founder & operator (Dev). We’ve reunited with a legendary leader (Carl) and reinvigorated the GOAT (Doug). We’ve elevated and empowered killer operators: Hem, Natalie, Rishi, Stacey, and Theresa. We’ve raised ~$10Bn in new funds. Talent and capital are two of the key ingredients in building legendary companies. Our talent density and capital base are stronger than ever.

24/7 There is no more Monday partner meeting cycle. Founders operate 24/7, and so do we. Founders shouldn’t have to adhere to our process — we will do our best to adhere to yours.

Reinventing Ourselves

Some of these changes were obvious. Others less so. Many were hard. It is scary to break something that’s already working just fine, and it is painful to say goodbye to great people. We ask founders to do the right thing even when it is hard, and we are committed to doing the same.

Some things remain unchanged. Our mission is to help the daring build legendary companies, from idea to IPO and beyond. Our objective function is not scale, but quality: delivering the best possible returns to LPs, and being the best possible partner to founders.

The Sequoia of Tomorrow

Excellence is a moving target, so we will always be changing. But for now, this is Sequoia.

We have seven General Partners who own and operate our organization, and we are on offense: building our business so that we can support you in building yours. We are true believers, and as we enter a golden age of multiple tectonic shifts in parallel (AI, space, biology, reindustrialization, and perhaps more), we are so fired up for what’s to come. Let’s build something legendary together!

— Alfred, Andrew, David, Konstantine, Pat, Shaun, and Sonya, on behalf of Team Sequoia

The data industry is caught between vendor consolidation, AI-driven automation, and unresolved operational problems. Generating SQL, pipelines, and documentation is becoming cheaper, but broken data, inconsistent business definitions, and unclear accountability remain. The lasting value of data teams lies in semantics, governance, and understanding rather than producing more technical artifacts.

Pinterest used to run inference with Ray, write predictions to S3, then start a Spark job to read them back and compute metrics. Its new evaluation platform computes partial metrics batch by batch inside the Ray inference job and combines them at the end. That cut end-to-end evaluation time by up to 32% for feature-importance runs.

Canva will cut more than 1000 jobs in a major restructure in response to slowing growth at the graphic design giant.

Co-founder and chief executive Melanie Perkins told staff on Wednesday the Sydney design software maker needed to “refound Canva” and return to small, empowered teams after its growth slowed this year for the first time in a decade. The shake-up will affect 1271 jobs, or 22 per cent of its workforce, with some staff to lose their roles and others asked to relocate to centralised hubs.

“This is without doubt the hardest moment in our thirteen-year history,” she wrote.

“After exploring a wide range of alternatives, I’ve come to the difficult conclusion that small changes won’t be enough. To set ourselves up for the next decade, we need to refound Canva, getting back to our roots of small, empowered teams with the freedom to make decisions, take ownership, and focus on what matters most for our community.”

Canva will merge its product, growth and platform teams into a single product organisation and cut management layers. Sydney will become the primary home for more product teams, and hybrid staff will be expected in the office two to three days a week from January.

Founded in 2013 by Perkins, her now-husband Cliff Obrecht and Cameron Adams, Canva makes online design software used by more than 265 million people a month to make everything from school posters and birthday invitations to work presentations and social media posts.

‘This is without doubt the hardest moment in our thirteen-year history.’ Canva CEO Melanie Perkins

The company has workers in 37 countries, and Perkins said the timing of conversations with affected employees would vary to meet local requirements. Those leaving will keep access to the company’s Slack and Gmail until the end of the week.

Perkins did not directly link the cuts to the rise of artificial intelligence, though she wrote that new technology was transforming what people create and what they expect from the products they use.

The shake-up comes as investor fears that AI will undercut software businesses have hammered design companies. Shares in rival Figma have plunged 44 per cent this year despite strong revenue growth.

This is Canva’s first-ever company-wide redundancy round, but it has made smaller cuts before. In 2025, 10 of its 12 technical writers lost their jobs; earlier this year, it cut 32 jobs in its finance division.

The restructure comes amid a torrid year for the local tech sector. Atlassian culled 1600 jobs in March, the same month that WiseTech Global announced it would slash 2000 jobs, nearly a third of its workforce. The very same day, the Commonwealth Bank confirmed 300 job cuts, with technology workers bearing the brunt of the cuts.

With the global AI headwinds for software makers, Blackbird, Canva’s biggest venture capital backer, cut its valuation of the company by 17 per cent to $US34.9 billion ($50.1 billion) in August, down from its $US42 billion price tag in a share sale that Canva arranged last year. Another venture capital investor, Airtree, followed suit.

Canva itself slashed its own valuation of its business to $US31 billion as it downgraded its revenue forecast by a third to just 20 per cent this year. Sales grew 38 per cent in 2025 and 45 per cent the year before. It also delayed the rollout of its biggest AI-led software update because the cost of running AI for its more than 200 million free users was eating into its profits.

“Historically, the cost to create a design cost us essentially nothing,” Obrecht said in August. “The cost of goods to serve a user has gone from cents per month to many, many more cents.”

Canva had long been seen as a candidate for a sharemarket float, which would let staff and early investors cash in their stakes. Instead, it has run private share sales in each year from 2022 to 2025, and an IPO once expected for 2027 has reportedly been shelved. Canva has said it will list when it makes sense, and that with more than $US1.5 billion in the bank, it is in no rush.

The wait is weighing on its backers, however. In August, Airtree asked its investors to extend the life of its first fund, raised in 2014, to July 2028 in the hope that Canva floats or offers another exit before then. Blackbird, which owns about 10 per cent of Canva, has said it still plans to hold on to its shares until a float. Most of Canva’s staff also hold shares in the company.

A Blackbird spokeswoman said the firm backed Canva’s move to downsize the business.

“Decisions like this are never easy, but we back Canva’s decision to make the changes needed to set the company up for its next chapter,” the spokeswoman said. “We’ve backed Canva since the very beginning, and we remain optimistic about its future and long-term potential.”

Airtree co-founder Craig Blair said Canva’s leaders were best placed to decide what changes were needed.

“Our confidence in Canva’s long-term opportunity hasn’t shifted,” he said. “Its recent AI model launch and performance reflect the technology and expertise they’ve built to date.”

Departing staff will receive at least six months’ salary, 12 months of healthcare where Canva provides it, and they can keep their work MacBooks. They can also apply for $US10,000 grants to start their own ventures.

Perkins will address staff at a company-wide meeting on November 10.

Like a bad survey, bad AI output gives no sign that it's wrong, but authority bias, truth bias, and algorithm appreciation make people trust it anyway. In user research, mistranscriptions, missed body language, misread sarcasm, and hallucinations can turn into confident, wrong insights. Someone who ran the research has to check any AI analysis, ideally used only as a sense-check after doing their own.

I use Chrome a lot, but I have never enjoyed opening its three-dot menu. Every time I need a specific setting, I end up clicking through submenus and squinting at long lists of options. The good news is that Google is fixing this, and the latest Chrome Canary build gives us a working preview.

Leopeva64 posted a demo on X of the search box inside Chrome’s redesigned menu. In earlier builds, the box was there but did nothing when you typed in it. That’s no longer the case. Type a few letters, and Chrome now pulls up matching browser commands, bookmarks, and websites you visited recently.

Why will you love the new menu search?

The biggest win for me is that I no longer need to remember where Google tucked a particular option. I can type its name and pick it from the list. The same goes for bookmarks, which are much easier to find when you don’t have to scroll through folders.

Chrome groups the results by type, with commands, bookmarks, and history shown separately. I appreciate this small touch, as it keeps a bookmark from getting mixed up with a setting that has a similar name.

Chrome’s menu gets a much-needed makeover

Google has given the whole menu a fresh layout. The New tab, New window, and New incognito window entries have become large buttons, and the other controls now sit in neat, block-style groups. The result is a menu that is easier to scan.

In Chrome Canary, Google is testing removing the scroll arrows that let you automatically scroll to reveal hidden items when you hover over them in the 3-dot menu. They also added a scrollbar, and the search box at the top and the footer are now pinned so they are always visible.

Scrolling has changed too. Google removed the small arrows at the top and bottom of the menu and added a standard scrollbar. The search box stays fixed at the top, and Settings, Help, and Exit stay fixed at the bottom, so only the middle section moves when you scroll. I like this, as search and Settings are always within reach.

Cat Wu has joined OpenAI to build reliable agents that keep users in control.

Tamba could be an experimental testing ground for social features rather than a finished product.

Exploratory data analysis still needs human eyes on the data. What looks weird depends on what you intend to do, which no model can know in a vacuum. LLMs rarely make the work faster.

Adobe is bringing licensed tracks from Universal Music Group and Warner Music Group into its Premiere mobile app, searchable by genre and duration. Videos using them can be shared on social media without copyright strikes, though only for personal use. Each video can include no more than 60 seconds of a song.

Repeatedly practicing the same design skills can make someone better at their current job without developing the problem-framing, influence, and decision-making abilities required for more senior roles. Instead of relying on experience alone, designers can break career goals into microskills and run small experiments, such as opening every design review with a specific decision or presenting research findings themselves. A weekly reflection can help turn these experiments into deliberate professional growth without requiring organizational approval or major changes to existing workflows.

A unified Figma design system and React component library: 80+ components, 73 ready-made blocks, 18,500+ components and variants, and 950+ variables and styles.

Afternow redesigned healthcare transportation platform Kinetik around painterly city landscapes inspired by the view from a car window, replacing conventional clinical imagery with a warmer visual language built from purple, deep greens, gold, salmon, and lavender. GT Alpina provides expressive editorial typography, DM Sans supports accessible product interfaces, and AI-generated landscapes are carefully art-directed with documented prompts to maintain consistency. The identity extends across four products through a shared design system containing more than 300 components and 2,000 screens, using tokens to adapt spacing, density, and accessibility for administrators, transportation providers, and elderly patients.

Utrecht-based digital artist and animator Lois van Baarle, known as Loish, paints expressive female figures in soft, glowing light, rich color, and flowing hair and clothing.