PagedAttention

Here's a thing I think about a lot: very occasionally, an idea from one subfield of computer science walks across the room, taps another subfield on the shoulder, and changes everything. PagedAttention is one of those moments. The idea is just virtual memory, the thing operating systems have been doing since the 1960s, transplanted onto the KV cache of a language model. That's it. That single observation is why a modern inference engine can serve two to four times more users per GPU than the naive approach.

This post is about that crossover. I want to build the intuition for why the KV cache wastes so much memory by default, why virtual memory is exactly the right analogy, and how PagedAttention implements the idea in a way that attention kernels can still work with.

A quick refresher: the KV cache is the per-request store of attention keys and values. It lets the model avoid recomputing them at every decoding step. It grows linearly with sequence length and at long contexts it eats more GPU memory than the model weights themselves. So it's the scarce resource. Every serving-system innovation in this arc is, in one way or another, about managing this one resource better.

Fragmented memory, wasted GPU

When you serve an LLM, you don't know in advance how long each request will be. User A might generate 25 tokens. User B might keep going for 2,000. Your service promises to support, say, 2,048 tokens per request, and you have no idea which user will use all of it. So a naive serving system does the obvious thing: reserve max_context slots of KV cache for each active request. If the model is 70B and the context is 32k tokens, that's gigabytes of GPU memory per request, reserved up front, most of it unused.

Two things go wrong here, and they compound.

The first is internal fragmentation. A request that only generates 47 tokens still holds onto 2,048 slots of cache. 2,001 slots sit empty the entire time. Multiply by 30 concurrent requests and you've reserved 60k token slots for what, in aggregate, is maybe 1–2k filled. That's unused memory you can't hand to another request, because it's already spoken for.

The second is external fragmentation. Requests show up and leave at different times. When request A finishes, its contiguous 2,048-slot chunk becomes available. But if you have a new request that also wants 2,048 slots, and the only free regions are a 1,500-slot hole from A and an 800-slot hole from someone else, you can't use them together. The free memory is the right size in total but the wrong shape. Either you defragment (copy stuff around, which is expensive and disruptive) or you sit on unusable memory.

Kwon et al.'s original vLLM paper puts real numbers on the waste. On production workloads they measured KV-cache utilization around 20–40%, which means 60–80% of the most expensive memory on the most expensive GPU in the cluster was sitting there doing nothing. That's the problem PagedAttention set out to fix.

This is just virtual memory

The moment the vLLM paper clicked for me was when I realized the problem it's solving is exactly the same problem operating systems solved decades ago.

In the early days of multiprogramming, every process asked for a contiguous chunk of RAM. The OS had to decide where to put it. Processes of different sizes came and went. Over time the free memory turned into a jigsaw of unusable fragments. Programs couldn't fit even when there was plenty of free RAM in total. The solution, pioneered on the Atlas at Manchester and refined by the 1970s, was virtual memory.

Here's how virtual memory works, boiled down: each process sees a contiguous virtual address space, but the operating system chops it into fixed-size pages (typically 4 KB) and stores them wherever it likes in physical memory. A per-process page table maps virtual page numbers to physical frame numbers. When the process reads virtual address 0x1000, the CPU (with help from the MMU) looks up the translation in the page table and fetches the data from whatever scattered physical frame is actually holding it. The process never knows the pages aren't contiguous. The OS gets to pack physical memory however it likes.

Now read that paragraph again and replace "process" with "request", "page" with "KV block", "physical frame" with "physical block in the GPU KV-cache pool", and "page table" with "block table". That's PagedAttention. The whole thing is a one-to-one correspondence.

OS virtual memory        →   PagedAttention
------------------------------   -----------------------------
process                  →   request (one prompt + generation)
page (4 KB)              →   KV block (e.g. 16 tokens)
page table               →   block table (logical → physical block idx)
physical frame           →   physical KV block in the shared pool
page fault / alloc       →   allocate a new block on demand
copy-on-write            →   copy-on-write for shared prefixes

I think this is the most useful mental model for the entire post. If you remember "it's virtual memory for the KV cache", you can reconstruct most of the mechanics on a napkin.

PagedAttention in one picture

Here's the machinery. The KV cache is no longer one big contiguous array per request. Instead:

• GPU memory holds a shared pool of fixed-size physical blocks. A typical block is 16 tokens. Each block can hold the K and V vectors for 16 consecutive positions of one request. Blocks are allocated from the pool as requests need them and freed back to the pool when they're done.
• Each request has a logical sequence of blocks: L0, L1, L2, ... arranged in order. The first 16 tokens go in L0, the next 16 in L1, and so on.
• Each request has a small block table that maps logical block index → physical block index. table[0] = 7 means "logical block 0 of this request lives at physical block 7 in the pool".

When attention runs, the kernel doesn't assume keys and values are contiguous. It walks the block table: "logical block 0 is physical block 7, logical block 1 is physical block 3, ..." and gathers the K and V vectors from wherever they actually live. There's a little indirection cost per block, but because blocks are substantial (16 tokens × hidden dimension), the fixed cost of the lookup is amortized across many arithmetic operations. The overhead ends up in the single-digit percent range.

The payoff is that you only ever allocate what you use, rounded up to block size. A request of 47 tokens takes three blocks (48 slots). Waste per request is bounded by BLOCK_SIZE - 1 tokens, so total waste across the system is small and constant instead of growing with max_context. Kwon et al. measured the resulting cache utilization at ~96% on production-like workloads, up from 20–40%.

Copy-on-write: when two requests share a prefix

Here is where the analogy pays off twice. Operating systems have a lovely trick called copy-on-write (COW): when a process forks, instead of duplicating its entire memory, the kernel shares the parent's pages with the child and marks them read-only. The child only gets its own copy of a page the instant it writes to one. Memory stays shared as long as nobody actually modifies it, which is most of the time.

This trick transfers directly. In LLM serving, many requests share a prefix. A chat app might prepend the same 800-token system prompt to every user message. Parallel sampling (the same prompt, multiple sampled continuations) shares every token up to the first sample token. Beam search is the same, at a finer grain: beams share everything except their most recent divergent token. If every one of those shared prefixes gets its own copy of the KV cache, you're paying for the same work many times over.

With PagedAttention, the scheduler can point multiple block tables at the same physical block. Each physical block maintains a reference count. As long as the count is greater than 1, nobody is allowed to write into the block in place. The moment one request needs to write (say, because it's about to generate a new token in a block still shared with another request), the engine clones that one block, decrements the refcount on the original, and updates the writing request's table to point at the clone. Everybody else keeps pointing at the original.

Why the attention kernel works at all

One thing that bothered me when I first read the paper was: attention is a dense matrix operation. How can it possibly work on non-contiguous memory without falling apart?

The answer is that attention, at the kernel level, is already a loop that walks over keys and values one chunk at a time. FlashAttention, for example, tiles the K and V matrices into blocks that fit in SRAM and processes them iteratively. PagedAttention aligns its block size with the tile size the kernel uses anyway. Inside each block, memory is contiguous. Across blocks, you just look up the next physical block address from the block table and continue. The kernel does a little more pointer arithmetic. It doesn't rewrite attention from scratch.

Misconceptions

"PagedAttention changes the model output." No. It doesn't touch the math at all. Attention produces the exact same logits regardless of whether the K and V tensors are laid out contiguously or scattered through a pool. The only change is in how the kernel fetches memory.

"Smaller blocks are always better because they reduce waste." It's more of a tradeoff. Smaller blocks reduce internal fragmentation (less padding in the last block per request) but inflate the block-table size and add per-block overhead inside the attention kernel. They also spread memory accesses more randomly, which can hurt cache performance. Kwon et al. found 16 tokens to be a strong default.

"Copy-on-write is mostly a beam-search optimization." The paper emphasizes beam search, but in production the dominant source of shared prefixes is system prompts. One prompt, many users, many concurrent requests all starting with the same 500–2000 tokens. COW there means the cached prefix lives exactly once in GPU memory across all of them.

Full article content is not available for inline reading.

Read the original article →

Poolside AI, the artificial intelligence model-building startup, has struck a non-exclusive licensing deal with Nvidia for $6 billion, plus a $1 billion investment in Poolside at a $12 billion pre-money valuation, according to a letter to investors obtained by Newcomer. As part of the deal 109 Poolside employees are getting offers to leave the startup to join Nvidia.

The deal echoes the acquihires that other AI startups have struck in the last few years with tech giants — though this one has a major twist: Unlike Scale-Meta, Nvidia-Groq and Character AI-Google where the founders jumped ship, Poolside’s founders will be staying with the startup. “This is not an acquisition and it is not an acquihire,” the founders wrote in the note obtained by Newcomer.

On 6 August, GitHub Actions was degraded for nine hours. At peak, 71% of workflow runs failed outright on infrastructure errors, and three quarters of the ones that survived were delayed by more than five minutes. On 11 August, the GraphQL API spent two hours timing out. On 17 August, the whole thing went down worldwide: roughly 20% error rates across the web interface and the API, roughly 50% on archive and raw content downloads, with Actions, Webhooks, Issues, Pull Requests and Copilot all failing together.

In between those dates, SpaceX closed its $60 billion acquisition of Cursor, the largest startup acquisition on record. And on the 19th, Cursor published a long, genuinely excellent piece about how they store git at scale.

I wrote in April that GitHub’s problem is that it became the thing everything else assumes. I still think the diagnosis was right. I want to revise the conclusion.

First, the part that deserves saying again

GitHub lowered the barrier to collaboration for an entire industry. It standardised how we work: the fork, the pull request, the review, the merge. It ran critical infrastructure for over a decade, quietly expanded from git hosting into CI, compute, package distribution and security scanning, and gave most of it away for free to anyone who asked.

Nothing below is “GitHub is bad at this”. The problem I want to talk about is genuinely hard, and the people working on it are good at it.

What actually broke

Two things, and only one of them is about scale.

The first is coupling. Look at what fails together on a bad day: Actions, Webhooks, Issues, Pull Requests, the API, Copilot. That is not six independent products having a coincidence. That is one system with shared fate, and it is the direct cost of the ecosystem being as rich as it is. The same deep integration that makes Actions worth using is what makes Actions fail when the API does. You cannot have the first without buying some of the second.

You can watch this happen in public. Between 1 and 18 August, GitHub’s own status history records seventeen separate incidents, two of them rated critical. Not one bad week. A cadence.

The second is that the workload changed shape. GitHub’s own Octoverse numbers: 630 million repositories, 230 new ones created every minute, 43.2 million pull requests merged per month and rising 23% a year, close to a billion commits pushed in 2025, up 25%. Not growth in the abstract. Growth of a quarter, every year, on a system where a bad deploy takes out a fifth of the developers on earth.

And the composition changed too, not just the volume. GitHub described the flood of high-volume, low-quality AI-generated contributions as “a denial-of-service attack on human attention”. Those are their words, in their own report. When the platform’s own analysis of its ecosystem reaches for that metaphor, something has moved.

So: a very hard problem, growing 25% a year, run by people who are good at it, in an architecture where the parts share fate because that is what made them valuable. That is the honest description. It is not a story about incompetence, and I do not think the fix is a better-run GitHub.

Everyone is trying to buy their way past it

The money agrees that something has changed, and it is moving in one direction.

Cursor, now inside SpaceX, published their architecture. It is worth reading in full. Their account of the history is the interesting part: GitHub tried NFS, which was “slow, and it was buggy” because git’s packfiles produce random access patterns that networked filesystems punish. They tried block-level replication, which was “terrible to operate day to day”. In 2013 they built Spokes, three replicas per repository kept in sync with a three-phase commit, and it held for a decade.

Then Cursor says what stopped it being enough: modern workloads need hundreds of replicas, and millions of tiny agent-created repositories.

Their answer, Continuity, is impressive engineering. Object storage as the source of truth, local NVMe as a warm cache, a write-ahead log persisted before any push is acknowledged, rendezvous hashing so any server can act as primary. 120 pushes per second on standard object storage, over 300 on the express tier, read throughput scaling linearly to a hundred replicas. A large monorepo gets hundreds of replicas. A tiny agent repository gets one, or zero, and is materialised on demand.

Meanwhile Thomas Dohmke, who ran GitHub as CEO for four years and left in 2025, raised a $60 million seed for Entire, which mirrors your repository into a distributed network so agents can clone from somewhere closer, and stores prompts, transcripts and tool calls alongside commits so agent-generated changes can be audited and reproduced.

I want to be clear that I think these people are right about the observation. Agents have created an enormous number of small, short-lived repositories, and that broke assumptions built into a decade-old architecture. Cursor’s engineers reached that conclusion from inside the problem, with production numbers. That is much better evidence than anything I have.

They are also solving it in the only direction available to them: make the hosted case cheap for the host. Which is a fine thing to do, and it does nothing for the laptop currently holding five copies of the same monorepo.

The question nobody is asking

Everyone is competing to be the best place to put code. Almost nobody is asking how much of that code needed to go anywhere at all.

Here is the narrow version of my claim, because the broad version is wrong. Git is already local. git commit, git branch, git log, git diff, git rebase, none of them touch the network, and that has been true since 2005. What is remote is the layer around git: review, CI, issues, releases, packages. The collaboration layer.

And most of what we now produce will never be collaborated on.

Think about what a working session actually looks like this year. Five worktrees, five agents, five branches, running in parallel on the same repository. Four of them will be thrown away before lunch. Every one of those experiments currently gets a remote branch, a set of CI runs, webhook deliveries, API calls, and a row in somebody’s database, for work whose entire lifespan is ninety minutes on one machine.

That is not GitHub failing. That is us sending throwaway work to a system built for work that lasts, because it is the only path any of our tools know.

Not an alternative. A staging area.

I am not proposing that anyone leave GitHub, and I am not making the self-hosting argument. That argument is fifteen years old and it has lost every time it has been made, to network effects, deservedly. Your code needs to be where the contributors, the issues, the stars, the security advisories and the muscle memory already are.

What I am proposing is a staging area.

Experiment locally, where it is cheap and fast and private. When something turns out to matter, promote it. And when a reader asks what “promote it” involves, the answer is the good part: you push it. That is the entire ceremony. Nothing about this asks anyone to give up anything, because the graduation path is the thing git was designed to do in the first place.

Look at GitHub’s position through this lens and it becomes sympathetic rather than damning. They are optimising, simultaneously, for a gazillion cheap dirty experiments and for the serious long-lived projects that depend on them being up. Those two workloads want opposite things. One wants to be free, instant, disposable and unlogged. The other wants durability, auditability, replication and consistency. Serving both from one system is how you end up with an operational nightmare, and taking the first workload off the platform is good for everybody, including them.

The example that already happened

I keep coming back to worktrees, because they are this argument in miniature and I did not have to invent them.

git worktree shipped in git 2.5, in 2015. For a decade it was a niche convenience: a way to look at another branch without stashing. Then agents arrived, and it turned out to be exactly the right primitive for a workload nobody had imagined, because a worktree is the cheapest way to hand an autonomous process a tree it is allowed to break. Claude Code creates one per background session. JetBrains added first-class support in 2026.1, VS Code the summer before. There is now an entire cottage industry of worktree managers.

And here is the part I find interesting. The primitive was right, but it had an assumption baked into it that the new workload broke. git worktree add writes a complete second copy of your working tree, because in 2015 you had two of them and disks were the cheap part. Now you have five, or fifty, and on a monorepo that is gigabytes each time.

On any modern filesystem it does not have to be. I measured it on the Linux kernel tree, about 95,000 tracked files: a plain git worktree add writes 1,816 MB. Materialising the same worktree with filesystem copy-on-write clones writes 36 MB, and produces a byte-identical tree. Fifty times less disk, at the same wall clock, using a filesystem feature macOS has had since 2017 and Linux has had for longer.

So I built it. It is called git-sprout, it is a drop-in replacement for git worktree add, it does exactly one thing, and it is on GitHub under MIT:

brew install alltuner/tap/git-sprout
git sprout add ../myrepo-feature -b feature

That is the shape of the whole idea, and it generalises: find a primitive that already exists, notice which assumption inside it the new workload broke, and fix that one thing.

What else is on that list

A few things I want to try, offered partly so people can tell me which ones are bad.

A locally-hosted forge surface that speaks the API our tooling already speaks. The obstacle here is specific and worth naming: gh, the CLI that every harness and CI snippet is written against, leans on GraphQL, which is why it does not work against Forgejo today. That is a concrete, boring, solvable problem, and solving it would give every agent harness a working forge for free.

Local CI that is not a second implementation of CI. actalready runs GitHub Actions workflows in Docker with no commit and no push, and Forgejo’s own runner is a soft fork of it. The pieces exist.

And credit where it is due: Forgejo and Codeberg, Radicle, sourcehut are all doing versions of this. So is Jujutsu, whose adoption pitch is essentially this entire post compressed into one line: keep your git infrastructure, keep your GitHub, keep your CI, just use a better interface. It is working. That is encouraging rather than discouraging.

Why the people with the money will not do this

Worth asking, and I think the dull answer is the true one.

Every incremental improvement to local development is revenue-neutral at best and cannibalising at worst. Codespaces, Actions minutes, Copilot seats, Advanced Security are all metered cloud products. Nobody at a platform company gets promoted for moving load off the platform. That is not cynicism, it is just how the incentives point, and it explains the observed behaviour completely on its own.

There is a second possibility that I will flag as speculation, because I have no evidence for it and I would rather say so than imply I do. Being the place through which all the world’s code passes may be worth defending for reasons that have very little to do with hosting it, in a period when code is training data. I do not know that this is a factor. I notice that it would be strange if it were not considered.

The asymmetry

Winning the next forge war costs billions and is available to about five companies on earth. Cursor’s architecture is the work of people who have spent decades on this, now funded by a $60 billion acquisition. I am not in that fight, I have nothing useful to add to it, and I am glad somebody competent is having it.

Making the throwaway ninety percent of development stop touching the network costs a weekend and a well-chosen primitive. Nobody is doing it, because there is no way to bill for it.

That seems like the more interesting side of the asymmetry. Start small, reuse primitives, fix friction points, and leave the big guns for when a project earns them.

git-sprout is the first one. There will be others.

One more thing

There is a hole in all of this. You can move the worktrees local, and the forge, and CI, and then the agent opens a socket to somebody’s data centre anyway, and the loop is remote again for the one part that actually costs money.

That hole is closing. In the same week as the outage, three labs shipped four sets of open weights: GLM-5 on the 11th, DeepSeek V4 Pro on the 13th, Qwen3.8-27B on the 14th. And Kimi K3, published in July, now reports agentic coding scores level with the leading closed models.

So the gap that matters is no longer open against closed. It is datacentre against laptop. Kimi K3 is 2.8 trillion parameters, and nobody is running that next to their editor. Qwen3.8-27B is 27 billion, scores 73.0 on Terminal-Bench, and wants about 18 GB at four-bit. Four months ago that would have been near the top of the open leaderboard. Now it fits in memory.

Same argument, one layer down: the frontier model for the work that matters, the local one for the four experiments that get deleted before lunch.

Which leaves the question I will end on. What happens the first time the whole loop closes, repository and worktree and forge and CI and model, all on one machine, none of it phoning anywhere, for the ninety percent of what we make that was never going to matter?

I do not think that is far away.

Related Links

• git-sprout

CNCF Announces Kubeflow Graduation

The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, announced the graduation of Kubeflow, a cloud native ecosystem forged by an open community dedicated to standardizing Data & AI workloads on Kubernetes.

The graduation signals Kubeflow’s technical maturity and confirms its role as an operational backbone for enterprises running AI workloads in production, including data processing, model training, fine-tuning and inference. Kubeflow provides native capabilities for data processing, interactive workloads, model training, fine-tuning, and interactive development. Kubeflow’s upcoming roadmap focuses on expanding Large Language Model (LLM) orchestration, enhancing post-training capabilities with fine-tuning, large-scale data engineering and agentic workloads for Data & AI lifecycle.

As organizations shift from AI experimentation to production, they need consistent infrastructure to advance their AI adoption in a standard way. Kubeflow helps bridge data science, AI engineers and AI platform engineering, enabling teams to scale AI solutions predictably and seamlessly. Kubeflow’s Python packages have reached nearly 260 million PyPI downloads, including major enterprises such as Bloomberg, NVIDIA, Red Hat, LinkedIn, and Spotify, which have used Kubeflow Subprojects to standardize AI workloads.

“Kubeflow has become a fantastic platform for organizations looking to unify work across AI, data science and platform engineering teams,” said Chris Aniszczyk, CTO, CNCF. “Graduation marks a critical milestone, cementing Kubeflow as a mature option for enterprise AI workloads on Kubernetes. The project’s remarkable growth reflects the tireless work of its maintainers and community, and we are thrilled to celebrate this milestone with them.”

Created at Google in 2017, Kubeflow has evolved from a collection of components into a unified, AI-native platform designed around the needs of data processing, model development, training and serving. Since joining CNCF as an incubating project in 2023, it has grown to more than 6,600 contributors across more than 1,000 organizations and has accumulated over 33,000 GitHub stars across its repositories. The project also works with CNCF technologies such as Prometheus for monitoring, KServe, Feast and Kueue for job queuing and Istio for secure service communication. As one of the first AI-native projects to reach graduated status, Kubeflow marks an inflection point for CNCF’s AI portfolio as the cloud native ecosystem has matured past infrastructure alone and now delivers production-grade, vendor-neutral foundations for the full data & AI lifecycle.

“Nine years ago, Jeremy Lewi, Vishnu Kannan and I put together a crazy demo involving hot dogs and Kubernetes, and Kubeflow was born,” said David Aronchick, co-founder, Kubeflow. “I could not be more ecstatic to see how far it’s come — and how many people have turned it into something teams and businesses genuinely rely on. Thank you to the CNCF and everyone in the community who carried it this far. To the next seven years and beyond!”

To reach graduation status, Kubeflow completed a third-party security audit, established a formal steering committee to ensure transparent governance and adopted the CNCF Code of Conduct. The project also maintains a Core Infrastructure Initiative (CII) Best Practices Badge, demonstrating a commitment to secure software development.

The CNCF Technical Oversight Committee (TOC) provides technical leadership to the cloud native community, defining its vision and stewarding projects through maturity levels up to graduation.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

In 2021, we assessed remote Spectre attacks against Cloudflare Workers. Based on the results, we shipped a production defense called Dynamic Process Isolation (DyPrIs), which identifies maliciously looking scripts and isolates them into separate processes. Since then, newer techniques in the area of stabilizing Spectre attacks have been discovered. To understand if these techniques posed a threat to our Workers production environment, we decided to internally reassess the remote Spectre attack. Building an updated proof-of-concept on the production environment allowed us to empirically assess the risk of Spectre attacks under production workloads.

To mount a successful side-channel attack in production, an external attacker has to overcome additional obstacles such as activity on shared hardware resources, interrupts, context switches, and coarse-grained timers. Our research uncovered a limitation in the implementation of DyPrIs and we managed to demonstrate a remote Spectre attack reliably leaking up to 12 bit/s with a 99% accuracy in the production environment of Cloudflare Workers. As a consequence of this research, we improved DyPrIs, integrated the V8 Sandbox and an in-process isolation mechanism to further reduce the risk of memory disclosure attacks.

Today we are publishing a paper describing our findings, co-authored by Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham, and Martin Schwarzl. This paper covers research done in 2024 and early 2025.

Note that the presented attack is mitigated already in the production system due to countermeasures applied by Cloudflare Workers Runtime team. We did not find any indicators of active exploitation over the last three years.

Cloudflare Workers security model

Cloudflare Workers runs untrusted JavaScript on the edge. Leveraging language-level isolation, in the form of V8 isolates, tens of thousands of tenants can share the same operating-system process. Each Worker has its own separate JavaScript heap. This design keeps startup latency low and lets us run many tenants very efficiently compared to full process isolation. Around the runtime we have multiple layers of defense such as automated V8 patch pipelines, a two-layered sandbox consisting of Linux namespaces and seccomp filters, Cap’n Proto RPC, and the possibility to schedule certain scripts in separate process sandboxes. Still, a single arbitrary read vulnerability within a Worker process can lead to cross-tenant leakage. One vulnerability that is very hard to mitigate exploits the nature of speculative execution, namely in-process Spectre.

Spectre

You can think of speculative execution in terms of hiking. At some point you arrive at a branch and have to predict where to go. If the prediction was correct, you saved some time and could enjoy the sun and a refreshing drink at a mountain hut. However, if you speculate in the wrong direction, you have to turn back. The trail looks untouched, but your footsteps remain in the mud.

Speculative execution in CPUs works similarly. The branch prediction performs an educated guess about a branch’s outcome ahead of time and the CPU speculatively executes it. If the prediction was correct, speculative execution saved some time. However, if the prediction is incorrect, the CPU has to discard the results, roll back and execute the other branch. Because these speculatively executed instructions only exist temporarily in the CPU pipeline and are never permanently retired or committed, the literature refers to them as transient instructions and generalizes the concept as transient execution.

However, due to the transient execution, there are still some traces left in the microarchitectural state for instance in CPU caches. Thus, an attacker can use Spectre to transiently access memory out of bounds, encode a single bit of information into the cache state and exploit the latency of reaccessing data to infer whether the bit was set or not.

To mitigate against in-process Spectre attacks, Cloudflare Workers freezes local timers, disallows multithreading and shared memory and actively detects, periodically shuffles memory and isolates malicious-looking scripts into separate processes.

Attack primitives

The Cloudflare Workers platform deliberately restricts timers. During CPU-only execution, time is effectively frozen. Date.now() and performance.now() do not provide a continuously advancing high-resolution clock. There is no shared memory and no multithreading, so the classic counter-thread timer via a SharedArrayBuffer is not available.

To successfully mount an attack, several challenges have to be solved. First, Workers runtime is limited and co-location between an attacker and victim has to be guaranteed. Second, a reliable, ideally co-located, remote timer has to be discovered, which allows stable timing measurements. Third, the attack runs under production conditions, meaning it requires additional stability measures such as a reliable Spectre gadget enabling transient 64-bit out-of-bounds accesses, robust signal amplification to deal with systems and networking noise, and a primitive to reliably evict data out of the cache.

Spectre gadget

return probeArray[
          obj instanceof ObjP
            ? PROBEARRAY_OFFSET + ((obj.ptr[0] >> bit) & 1) * 0x800
            : 0x400
];

Speculative type confusion Spectre gadget

With the right Spectre gadget (snippet above), an attacker can transiently access out-of-bounds memory and encode a single bit into the cache (probeArray). The attacker then measures the memory access latency to confirm whether data has been cached or not. A faster access means the line was cached and the bit was 1. Conversely, a slower access means it was uncached and the bit was 0. In our attack, we use two different Spectre gadget types. The first one leaks compressed heap pointers, e.g., the isolate’s heap base address (root), and the other one leverages a speculative type confusion to leak from an arbitrary, attacker-crafted userspace 64-bit pointer. At the time of performing the research, the V8 Sandbox was not yet implemented at Cloudflare Workers. Under pointer compression, most objects use 32-bit compressed pointers. TypedArray was one of the few exceptions that still stored a raw 64-bit pointer to its backing store, which is exactly what our gadget abuses.

The branch obj instanceof ObjP performs a type check, i.e., a branch. To mistrain the branch prediction, we call the gadget many times on real ObjP instances, then call it on a different object with an attacker-controlled memory layout ObjI. The CPU speculates on the taken branches and follows obj.ptr[0], even though the object has a different type. To leak a single bit, we mask out one bit and use it to select one of two probeArray lines. Whether that line is cached encodes the bit.

Exploiting the heap leakage gadget, we map neighboring objects and locate an attacker-controlled array. Our second gadget confuses two large objects that span several cache lines, so the type field lands on a different cache line than the field we read. Evicting the type field opens the speculation window while the target field stays cached, and the transient read follows an attacker-controlled 64-bit value. That turns the leak into an arbitrary-address read. A more thorough description of this technique can be found in the paper.

Signal amplification

A cache hit and a cache miss differ by a few nanoseconds. Moreover, a remote timer is noisy at the scale of a few microseconds up to a few milliseconds. Therefore, some form of signal amplification is required to differentiate a cache hit from a miss. Stephen Röttger and Artur Janc discovered a way to amplify a single memory access, by exploiting the tree-based pseudo least recently used (PLRU) cache-replacement policy in L1 caches. Tree-based PLRU organizes each cache set as a binary tree whose nodes point to the side used least recently, so the CPU evicts by following those pointers. With the right access pattern, an attacker can keep a target line cached indefinitely by touching its tree neighbor whenever the pointers turn toward the target. Quite elegant, right? Leveraging that behavior, the timing of a single cache event can be arbitrarily amplified such that it leads to a lot of L1 hits (faster) compared to lots of L1 misses in the opposite case.

Remote timer

As long as the signal can be amplified, a noisy remote timer is sufficient to differentiate an encoded bit. For instance, a WebSocket connection to an external server serving high-resolution timestamps is enough. The timer could be hosted at Cloudflare or at a co-located data center to the target data center running the Worker. The Worker asks the remote timer to mark a timestamp for a certain event and compute the delta for another request once the event has stopped.

Repeatable measurements

A single measurement is not enough to differentiate timing-encoded data reliably. Production machines are noisy, thus an attacker has to repeat each measurement at least a few times and use some statistical discriminator. Repeating a measurement in our case means resetting the cache state. Two things have to be uncached before each round. The value the speculative branch depends on has to be evicted, so branch resolution stalls long enough to open a speculation window. The probe line that encodes the leaked bit has to be evicted, so the next transient access can re-cache it.

Since there is no direct instruction available in JavaScript, the classic way to do this is to build an eviction set. An eviction set is a group of addresses that map to the same cache set as the target. Accessing them in the right pattern pushes the target out of the cache. In their attack, Stephen Röttger and Artur Janc used an eviction list to reliably evict at least into the L2 cache. This works, but it is expensive. Constructing a precise eviction set requires many timed measurements, and our timer is a noisy remote timer. The previous remote attack against Workers sidestepped the search by traversing an array larger than the L1 and L2 caches on every round. That is an option, but even slower.

Dougall Johnson described a more elegant way in his really cool blog post on portable JavaScript Spectre exploitation. The idea follows directly from the pigeonhole principle. If you allocate far more data than the cache can hold, a randomly chosen cache line is almost certainly not cached. For a 256 KB L2 cache, allocating 64 MB leaves at most a 1/256 chance that a random cache line is still in L2. So instead of evicting a specific line, you never evict at all. You pick a fresh random location that is already evicted with overwhelming probability. The cool side effect of looping frequently over that array of objects is that this will lead to an auto-eviction effect.

To leverage this in JavaScript, we allocate a large pool of attacker and victim object pairs that exceeds the last-level cache. Each measurement round selects a fresh random pair. The object's map pointer, the hidden-class descriptor that the speculative type check reads, is therefore almost certainly already evicted.

Co-locating the attacker and victim isolate

For the attack to work, both the attacker and victim isolate must be scheduled in the same process on the same edge server. One might intuitively think this would be difficult, considering Cloudflare operates tens of thousands of edge servers, but this is in fact quite trivial on Cloudflare Workers. Because Cloudflare Workers are designed to execute on any Cloudflare edge server, invoking the victim script from the attacker script with a fetch(“https://victim.example”) will in most cases cause the scheduler to spin up an instance of the victim worker in the exact same process. The victim isolate can be kept alive by repeatedly making subrequests to it at a certain interval.

What is more, because the attack stability is highly dependent on the CPU load of the edge server running the worker script, this allows an attacker to strategically run the attack in an off-peak colo (e.g. in an Australian colo during European business hours) where the traffic levels are comparatively low.

Defeating isolate resource limits

The Cloudflare Workers runtime enforces a set of limits on all isolates to protect the platform and prevent abuse. For the purposes of conducting this attack, the relevant limits were 30 seconds of CPU time and 1,000 subrequests per invocation. These limits have since been increased, but the following principles are still relevant.

For a regular Worker, each HTTP request, a fetch event, is a new invocation that resets these limits. The catch is landing sequential requests on the same edge server. Load balancing and shifting network conditions make that unreliable. Durable Objects solve it for us.

Durable Objects are built for real-time coordination between clients, so the runtime treats every incoming WebSocket message as an invocation that resets the CPU time and request limits. The attacker opens a persistent WebSocket to a Durable Object worker and sends regular keep-alive messages. This keeps a single isolate alive and gives us a persistent, bi-directional channel to run the attack over.

One quirk cost us some time. An isolate is single-threaded, so incoming WebSocket messages are only processed when the script hands control back to the event loop. During synchronous code the runtime never sees the keep-alive, so it never resets the CPU time. If the thread stays blocked for more than 30 seconds, the runtime kills the isolate. This puts an upper bound on how much we can amplify in a single synchronous burst. Yielding regularly between bursts lets us keep an isolate alive from five to more than 20 hours.

Putting everything together

The previous attack relied mostly on repetition to amplify a single cache access, and therefore, was slowly leaking 120 bit/h. We combined tree-based PLRU amplification with measurement loops. Each iteration re-creates the cache state and thereby adds more timing difference. If an interrupt destroys the cache state in one iteration, it doesn’t matter, since later iterations cancel it out. This made the signal strong enough to classify bits with a remote WebSocket timer. The overall idea is now to combine.

for (let s = 0; s < SAMPLE_NUM; s++) {
  timer.mark("mark S" + s);
  for (let r = 0; r < OUTER_REP_NUM; r++) {
    setup();                   // branch mistraining and cache control
    leak(secretBit);           // transient access
    PLRU(cacheSet, INNER_REP); // amplify
  }
  timer.mark("mark E" + s);
}

delta = fetchFromServer(SAMPLE_NUM);
return median(delta);

We demonstrated the full end-to-end attack in the Cloudflare Workers production environment, against Workers we controlled. We first leaked memory from the attacker Worker. From there, we leaked data from a co-located victim Worker where we had intentionally placed a secret.

Why was this not detected?

DyPrIs watches hardware performance counters and isolates a script into its own process once it looks like a Spectre attack. Two things kept the attack under the radar. First, DyPrIs isolates a script only after its invocation finishes, and the Durable Object keep-alive trick we used in the attack can run for a few hours up to a day. WebSocket keep-alive messages hold a single invocation open for hours, so the leak completes long before isolation would kick in. Second, DyPrIs normalizes branch mispredictions by the number of iTLB accesses. Our remote timer is one large I/O loop, and that WebSocket traffic inflates iTLB activity. The normalized ratio drops below the detection threshold, so the attack looks like an ordinary I/O-heavy Worker.

What we changed

We focus on the three areas of continued V8 hardening, providing stronger in-process isolation, and improving detection.

V8 sandbox

The V8 memory sandbox's final goal is to remove raw 64-bit pointers from large parts of the JavaScript heap, which reduces the usefulness of many memory-corruption primitives. It also makes the specific speculative type-confusion gadgets in this work harder to reuse, because typed-array backing stores no longer expose the same raw pointer structure.

Hardware-assisted in-process isolation

In September 2025, we deployed in-process isolation for Workers using Memory Protection Keys (MPK). MPK lets a process divide memory into protection domains and switch access rights cheaply. Workers use it to protect each heap from being accessible to the other isolates within the same process.

Improved DyPrIs

We improved DyPrIs so that long-lived executions and I/O-heavy workloads are handled as first-class security cases. Detection cannot happen only after a script finishes. A Durable Object or a WebSocket-heavy Worker can run long enough that post-execution isolation arrives too late.

Acknowledgments

We especially thank Haocheng Xiao from University of Edinburgh and his supervisors, Sam Ainsworth and Nigel Topham, for their contributions to the reliability of Spectre in JavaScript.

Call for participation

We are always looking for high-quality submissions through our Bug Bounty program. Memory safety bugs in the runtime are high-value targets. You can find the Fuzzilli integration for workerd and the workerd source code on GitHub.

Cursor launches Origin code hosting service to compete with GitHub

Cursor today introduced Origin, a cloud service that software teams can use to store their code.

The launch marks the company’s first major product update since its $60 billion sale to SpaceX Corp. in June.

Cursor develops one of the industry’s most popular desktop-based vibe coding tools. The program uses artificial intelligence agents to automate programming tasks. Cursor can help developers craft code, modernize existing software and familiarize themselves with application modules written by colleagues.

Origin is accessible via a new tab in the Cursor desktop client’s interface. Developers can also interact with it via a dedicated command line interface tool. It speeds up tasks such as creating and copying code repositories.

The new service is based on Git, a code repository management tool developed by Linux creator Linus Torvalds. One of the software’s main selling points is a feature called branching. The capability enables members of a development team to create separate copies of a code repository, edit each replica separately and then combine the changes. Managing code changes without branching can be a highly error-prone task.

Git also underpins GitHub, the most popular code hosting platform on the market. Cursor offers an integration that enables developers to copy projects from GitHub to Origin with a few clicks. When an upstream project in GitHub receives an update, the integration syncs the changes to Origin. It also syncs files in the opposite direction.

Developers can use Cursor’s built-in agents to edit code in Origin repositories. The vibe coding platform supports two types of agents. The first variety is hosted on the user’s desktop, while the other runs in a cloud-based sandbox. The main difference between the two is that cloud agents can work on long-horizon coding tasks even when a developer’s workstation is turned off.

Those developers with more advanced requirements can connect Origin to external services. The platform is launching with a prepackaged connector for Vercel Inc.’s application hosting platform. According to Cursor, the integration enables developers to quickly create a test environment in which new application updates can be checked for bugs. There are also connectors for development tools from startups Depot Technologies Inc. and Buildkite Inc.

Cursor will add more integrations in the near future. Additionally, the company plans to release unspecified “agent-native features.”

Many programming agents run in isolated cloud-based virtual machines. Developers equip those virtual machines with assets such as code repositories that are relevant to the work of the agents they host. Cursor might be planning to release features that will ease the creation of such sandboxes. Another possibility is that SpaceX will integrate Origin with Grok Build, a vibe coding tool it introduced in March.

Digital products often overlook the needs of people with limited or no mobility, who rely on tools like speech recognition, eye tracking, and adaptive devices.

Why it matters

Meeting summaries are already commodity software. Parka would let Anthropic own the spoken context that creates work and route it directly into Claude's coding and desktop agents.

Reporting record

Finding

Anthropic has designed an unreleased, Mac-first meeting recorder inside Claude Desktop, codenamed Parka, that can turn meeting transcripts into Cowork, Claude Code, or manual follow-up actions; current public builds keep the feature disabled and ship without its working native implementation or user interface.

How we verified

Methods: reverse engineering.

Claude Desktop 1.32885.1 contains an extensive Parka interface contract covering meeting creation and deletion, system and microphone audio capture, calendar metadata, transcription keyterms, live speaker-attributed transcript events, summaries, notes, granular editing, and error states. The action schema assigns each follow-up a title, description, owner, full prompt, execution type, autoRunnable value, and optional Claude session URL. Its execution types are cowork, code, and manual. Public packaged builds force parkaMeetings to an unavailable status. The native Parka loader included with both operating-system packages is an empty 551-byte stub. After RuntimeWire forced the renderer’s two Parka bootstrap values to report supported, Claude loaded normally but displayed no meeting interface or navigation item. The loaded renderer made no observable listParkaMeetings call and fetched no Parka-specific JavaScript chunk. Separately identified Anthropic-controlled Titanium hosts use names resembling Deepgram’s Nova-3 and Flux speech models. Parka’s keyterms argument also resembles Deepgram’s Nova-3 Keyterm Prompting interface. The desktop package contains no Deepgram hostname, SDK, credential, or other direct vendor attribution, so that connection remains unconfirmed.

Tested versions: Claude Desktop 1.32885.1 — macOS universal DMG Claude Desktop 1.32885.1 — Windows x64 application archive Claude renderer asset shared-2-8TRRKqAc.js — retrieved August 19, 2026.

Reproduction

RuntimeWire independently reproduced the core finding.

RuntimeWire obtained current Claude Desktop artifacts for macOS and Windows, calculated SHA-256 hashes, extracted the Electron application contents, and searched the packaged code for Parka identifiers. We traced the feature from its operating-system gate through the desktop IPC contract, native implementation loader, event definitions, meeting schema, action schema, permission text, and renderer bootstrap. We compared the Mac and Windows packages to identify platform differences. In a signed-in Windows installation, we queried window.desktopBootFeatures.parkaMeetings and confirmed that the packaged application reported the feature as unavailable. Using Chrome DevTools Local Overrides, we changed both Parka bootstrap values in the remotely delivered renderer asset to supported and reloaded Claude. We then inspected the interface, loaded sources, console, and network activity. Claude showed no Parka screen, navigation item, feature chunk, or meeting-list request. We compared the recovered behavior with public documentation from Anthropic, Apple, Notion, Granola, and Deepgram. Claims about a possible Deepgram connection were kept separate from the confirmed desktop findings because the application artifacts contain no direct provider reference.

File hashes

• sha256:78c392a9bb1b436cf2a4c03ab9b45cbeb5995bcd3a7021415dc7244da4830f53 Claude.dmg
• sha256:7f616a4a7ee9b095280f453d59a19fcc289a3322214583ad117da7d3d0ea9d1f app(4).asar
• sha256 shared-2-8TRRKqAc.js

Anthropic is developing a meeting recorder inside Claude Desktop that can turn action items into tasks for Claude Cowork and Claude Code, according to application interfaces reviewed by RuntimeWire.

The project is internally codenamed Parka. A Claude Desktop macOS package carrying August 18th, 2026 filesystem timestamps contains a detailed contract for recording meetings, streaming speaker-attributed transcripts, generating notes and summaries, and extracting structured follow-up work. Public packaged builds still mark the feature as unavailable, and Parka may never be its public name.

The feature would extend Anthropic's expansion beyond chat into Claude Code, its coding agent, and Claude Cowork, a desktop agent that works across files, browsers and applications. Parka would give both products a new source of assignments: commitments made aloud in meetings.

From conversation to agent session

Parka's desktop contract exposes methods to list, retrieve, start, stop and delete meetings. A recording can capture system audio, microphone audio or a mix of both. It can also accept calendar-event metadata and transcription keyterms, which could help the speech system recognize company names, product terminology and technical language.

Live events deliver transcript segments with a speaker label, timestamp, text, optional utterance ID and a field distinguishing interim text from a finalized turn. Meeting records progress through recording, processing, ready and error states.

Once processed, a record can contain a title, timestamps, duration, capture source, speaker-attributed transcript, Markdown notes, a Markdown summary, calendar details and structured actions. Parka provides separate controls for editing notes, summaries, titles and actions. It can also remove an individual transcript turn.

The action schema reveals Anthropic's larger plan. Each action can carry a title, description, owner, full prompt, execution type and an autoRunnable flag. The available types are cowork, code and manual. An optional sessionUrl appears designed to link an action back to the Claude session created to complete it.

That structure could let a product meeting produce a Claude Code task with the relevant implementation prompt. An operations call could hand research, document preparation or browser work to Cowork. Commitments assigned to a person could remain manual tasks.

The interface does not establish whether Claude starts eligible actions automatically or waits for user approval. autoRunnable could power either behavior, so Parka's execution model remains unresolved.

A device-level recorder built first for Mac

Parka's feature gate requires macOS 13 or later. The same interface contract appears in the Windows package, where the feature is unsupported. The Mac package includes separate permission text for audio capture and Claude's existing microphone access, consistent with a recorder that needs both computer audio and the user's voice.

Apple introduced ScreenCaptureKit at WWDC22 as a framework for capturing screen content and application audio with user consent. It can capture audio associated with applications without requiring extra audio-routing software. Those capabilities would allow Claude to listen directly on the device across Zoom, Google Meet, Microsoft Teams and other meeting software without adding a participant bot to the call.

The exposed Parka interface includes a field named hasVisionResolvedSpeakers. The name suggests Anthropic has explored using visual cues from a meeting window, such as participant names or active-speaker indicators, to improve speaker identification. Calendar attendee names could supply another set of candidate identities. No visual payload appears in the renderer contract, so the exact mechanism cannot be established from the package.

Parka can delete a transcript turn using its timestamp, speaker, text prefix and optional utterance ID. That creates a more precise editing control than deleting an entire transcript. The interface does not reveal whether removing transcript text also deletes corresponding audio retained during processing.

No raw-audio path, media URL or recording object appears in the exposed meeting record. Anthropic could discard audio after transcription, retain it behind the native layer or store it remotely. The package does not answer that retention question.

A detailed contract with the product still withheld

The build uses an explicit production kill switch. Public packaged versions report Parka as unavailable before evaluating the operating-system requirement. Internal or unpackaged builds continue to the macOS 13 check.

RuntimeWire forced the parkaMeetings feature to report a supported status at both bootstrap points in a signed-in Claude app. Claude loaded normally, but no meeting screen, navigation item or Parka-related JavaScript chunk appeared. A search across the loaded renderer found no client call to listParkaMeetings, even though the two injected feature flags were present.

Claude Desktop loads most of its product interface remotely from Claude's web infrastructure. Anthropic can therefore add the missing Parka renderer later without shipping another desktop package.

The JavaScript module intended to load Parka's native implementation is currently an empty 551-byte stub in both the Mac and Windows packages. The surrounding contract is far more developed: it defines calendar alerts, live transcript events, granular editing, failure states, account resets and runnable action fields. The evidence shows substantial product design and integration work, with the operational implementation and user interface still held back.

Anthropic is entering an occupied category

Granola already records computer audio without a meeting bot, connects to calendars and produces notes, actions and follow-ups across macOS, Windows, iOS and Android. Its established capture experience and cross-meeting memory give it a considerable lead over an unreleased Claude feature.

Notion is the closest functional comparison. Notion AI Meeting Notes captures system and microphone audio in its desktop app, requires macOS 13 or later on Macs, associates recordings with calendar events, labels speakers, and generates summaries and action items.

On July 31st, 2026, Notion added a trigger that runs Custom Agents after a meeting note is summarized. Those agents can update project trackers, post recaps and create engineering tickets. Anthropic would enter with a major incumbent already connecting meeting capture to agent execution.

Otter, Fathom and Fireflies offer mature transcription, cross-meeting search and integrations with CRM and project-management systems. Google Meet, Microsoft Teams and Zoom have the advantage of controlling their own meeting platforms, participant identities and enterprise policies.

Parka's action types show the opening Anthropic intends to pursue. A first-class code action could route engineering commitments directly into Claude Code, while cowork could handle documents, analysis and operational work. Anthropic appears to be designing the recorder around its own agents instead of a broad catalog of CRM and task-management integrations.

A possible Deepgram connection

Separate infrastructure findings point toward a possible speech provider. Anthropic-controlled hosts under titanium.api.anthropic.com use names including stt-nova3-s0 through stt-nova3-s8 and stt-flux-multi, with staging variants also provisioned. The Nova-3 hosts exposed a private 10.104.0.6 address through public DNS, suggesting an internal deployment accidentally made visible outside Anthropic's network.

Those labels closely match Deepgram's speech-recognition products. Deepgram describes Nova-3 as its general-purpose real-time transcription model and Flux as a conversational model with turn detection. Its multilingual Flux model is named flux-general-multi. Deepgram also directs Nova-3 users to Keyterm Prompting, matching the keyterms argument accepted when Parka starts a recording.

Anthropic has previously published a Claude cookbook example using Deepgram for transcription, but neither company has announced a Parka partnership. The Claude Desktop package contains no Deepgram hostname, SDK or credential linking Parka directly to the Titanium endpoints. Anthropic could be proxying a speech provider through its own infrastructure, and those services could support other voice products. The matching model names and keyterm interface make Deepgram a strong working hypothesis rather than a confirmed vendor attribution.

Owning the work before it reaches the agent

Meeting transcription and AI summaries are established product features. The strategic value sits one step later: deciding which system receives the context, creates the assignment and carries out the work.

Granola can send meeting memory toward Claude, Cursor, Replit and other AI tools. Notion can preserve the meeting inside a company workspace and trigger its own agents. If either product owns the recording and action-extraction layer, Claude becomes one possible destination downstream.

Parka would give Anthropic control of the entire sequence inside Claude: capture the conversation, identify commitments, turn them into prompts and open the agent sessions that complete them.

That is a more specific proposition than another AI notetaker. Anthropic is preparing to turn meetings into an inbox for Claude's agents.

The real work has never been the document, the pull request, or the final build. It’s the conversation that gets you there, the back-and-forth, the pushback, the half-formed idea a teammate catches and turns into something brilliant. A brief, a deck, a block of code: they’re just proof that the real thinking already happened, together. We’ve believed this since Slack started, that work is better done in the open, in channels, not alone behind a closed door and revealed only once it’s “done.”

AI agents haven’t always been part of that. Usually, someone opens a private tab, prompts an agent, and disappears for a while, building in isolation, one person and their agent. The rest of the team finds out after the fact, with no chance to weigh in, catch a wrong assumption, or add context only they had. It’s a single-player game, and single-player games don’t scale: no pushback, no collision of ideas, just a fast way to get more of the same thinking. It’s the exact thing we’ve spent years building Slack to avoid, now happening again with agents instead of people.

Welcome to Slack Code

Slack Code brings software development out of private tabs and into the open, so your team and its agents can plan, write, and review together. It provides a dedicated space, called a code channel, that shapes itself around the work. Mention a coding agent on a complex project, and one spins up, pulls in anyone on your team, and the agent builds the space around what you need, like a code diff, a planning doc, or a live HTML preview. When the work’s done, the channel archives itself but remains like an audit log in Slack for future reference. That’s the shift Slack Code is built for: connecting what you’re building to the conversation your team is already having, in one place.

We’re starting with engineering because it’s the work closest to our hearts, the thing we live and breathe every single day. Today, we’re launching alongside Anthropic, Cognition, GitHub, OpenAI, and Vercel, with more partners joining us on the way.

Slack is a strategic part of a broader GitHub promise: humans set direction, agents close the loop. That has to be true wherever developers are working, which is why we're bringing Copilot into the flow of conversation in code channels to help teams turn shared intent into shippable software.

Why we built Slack Code

We didn’t design code channels in a vacuum, we built them out of sheer necessity for our own team. As our engineers leaned harder on coding agents internally, we hit a wall: squeezing complex, multi-turn agent execution into a standard channel thread felt cramped and noisy, but letting developers retreat into private browser tabs meant losing the thing that makes Slack work: everyone working in the open.

We realized agents didn’t need another isolated browser tab or terminal. They needed a seat at the table: a dedicated space that could expand when the project got complex, pull in the right humans at the right moment, and fade away when the job was done. Bringing teammates and agents into that same space has made building feel human, transparent, and genuinely fun, and the impact shows up in the numbers, too. One of our engineers put it simply: bug reports and small UI tweaks used to get filed away and forgotten. Now he spins up a side conversation right where the work’s happening, deals with it on the spot, and gets back to building.

Over 70% of code channels spin up and close within a single day, from idea to merged PR. Engineers get unblocked sooner, reviews need less context, and work just ships faster. That’s because the real value of AI doesn’t come from someone working faster in isolation. It comes from agents and teams building together at the speed of conversation. For the first time, an agent can build alongside your team in real time, with your teammates’ eyes on the work as it happens. It’s not solitary, it’s multiplayer, the exact same way your best work already is

Built for Code, Not Just Conversation

Threads work great for quick questions and updates. But working with agents to test a fix or catch a bug before it ships, needs more room to work. Slack Code gives agents and engineers that space, right where the coding happens:

• A dedicated space per project. Mention an agent on real work, and a code channel spins up around that specific task, visible to the whole team, not just the person who kicked it off. It archives automatically when the work’s done, so nothing sprawls, but everything stays searchable.
• See the code as it’s built. Code diffs, and live previews show up right in the code channel, not a wall of text. Catch a bug before it ships, flag a constraint before the agent runs with it, or pause and redirect mid-task.
• Enterprise trust, no extra setup. Slack Code inherits Slack’s existing permissions and admin controls, so IT doesn’t need to configure or audit anything new. High-stakes changes can route to a person for a fast approval, right in the channel — the speed of automation without giving up the confidence of a review.

Partnering with our ecosystem to bring the best of coding to Slack

Slack Code is launching with AI partners who’ve built their agents for this new and better way of working — one that fits into the natural ways teams already collaborate.

• Claude (Anthropic): When a user asks, Claude Tag can invoke a Code Channel, a home for the work so it doesn’t get lost in a thread and separates it from other chats. Everyone can follow progress at a glance through the summary feature in the original thread, jump in to help steer when they have something to add, and ship changes together with Claude Tag, which later archives the room once the work lands.
• Cognition: Cognition built Devin to act like a coworker: it responds when needed and stays quiet otherwise, fitting into how a team already talks instead of adding another channel to check. Someone flags a bug right in the conversation, and Devin fixes it and reports back with a working preview. No ticket, no queue, no context lost in translation. For Cognition’s users, that turns ‘we’ll get to it next sprint’ into same-day fixes.
• GitHub: GitHub built its integration to open the door to more contributors. Inside a code channel, a non-technical teammate can describe a problem in plain language, have an agent draft a fix, and tag in an engineer to review it — all without leaving the conversation. That turns code review from something isolated and delayed into something the whole team can follow and weigh in on as it happens.
• Vercel: Inside a code channel, Vercel’s agent kicks off a live preview the moment a change ships and posts a shareable link right in the thread — so the team sees the real result before it reaches users. Bugs and backlog items that used to sit unprioritized because they ‘weren’t worth’ a developer’s time now just get fixed.

These examples are just the start, and you can build this way today. Simply mention Claude, Devin, GitHub Copilot, ChatGPT by OpenAI, or Vercel in Slack to watch a code channel spring to life in real time. Software engineering is where we started, but together with our ecosystem, this same collaborative model will expand beyond code, stretching into marketing campaigns, legal contract reviews, IT onboarding, and every corner of your business.

Beyond Slack Code

Slack Code is one piece of a much bigger picture. As agents become part of your daily work across Slack, not just in code channels, but also in DMs, threads, and everyday conversations, we’re building the surfaces to help you manage that work, see it happen, and keep it moving. That starts with the new Agents & Tools tab, your home base for managing agent conversations across threads, DMs, and code channels. It means making a DM with an agent feel as natural as messaging the person sitting next to you. And it means sweating the details, like streamlined agent reasoning, and a clearer way to see when an agent’s still working.

Work Is Multiplayer in Slack

We said it earlier: the real work is the conversation that got you there. For years, we’ve built Slack on one belief: work is better, faster, and more creative when it’s done together, in the open.

As agents take on deeper work, we’re rolling up our sleeves to make sure people stay at the center of it. Our goal isn’t just to make agents run smoothly inside Slack. It’s to shape the future of how teams work in an AI-powered world. We want that future to be multiplayer: one where work is more collaborative, agents are not just tools but teammates, and work is, frankly, more fun.

Agents are going to push work forward. We’re here to make sure they do it the way we always have: together, in the open, side by side.

Availability & next steps

Slack Code is live today for teams using Claude (Anthropic), Devin (Cognition), GitHub (Copilot), and Vercel integrations, with OpenAI (ChatGPT) available soon. Mention the agent in a project channel to see it spin one up.

Agentic Search. More accurate and efficient results from your AI systems.

Mistral Agentic Search delivers more accurate search results while reducing turns, token use, and latency against FinanceBench and OfficeQA Pro benchmarks. Agentic Search is the retrieval layer that enables AI systems to navigate, read, and verify information inside even the most complex documents. Available through Mistral Search Toolkit and Libraries.

Mistral Agentic Search helps enterprises get better results from their AI systems by letting models search and navigate their organization’s most complex data and documents. Agentic Search introduces a multi-step retrieval loop for finding, inspecting, and verifying information across data sources, wherever it is stored. Agentic Search is available through Mistral Search Toolkit, built into Libraries in both Studio and Vibe, and gives you:

• Support for sensitive domain-specific data. Mistral’s portable and open tooling helps you unlock value from your data without crossing your isolation boundaries in the cloud or on-premises.
• Improved search results. Your models can search and navigate your data beyond retrieved chunks–inside long, dense documents or across multiple sources.
• Access to existing indexes. Agentic Search builds on your existing search index using five tools: search, open, navigate, read, and grep.
• Higher accuracy. Agentic Search delivers to 3x correctness on financial filings, from 26.7% to 86%, based on FinanceBench. On table-heavy, multi-doc questions of the OfficeQA Pro benchmark, we measure a +45.6 point gain (6.3% to 51.9%).
• Lower latency and token use. Targeted navigation enables Agentic Search to reduce p90 latency up to 39.6%. Fewer repeated searches reduce token consumption by up to one-third.

Data creates competitive advantage

Competitive edge is built upon years of real-world operations–your data, your processes, and your domain expertise. Proprietary knowledge is both critical to your success and highly confidential, meaning it lives behind isolation boundaries, segmented deployments, and self-hosted platforms. It accumulates in financial filings, legal contracts, internal resources, and government records–long, dense documents that traditional search methods can’t navigate effectively.

Agents that learn and improve continuously can help you compound your competitive advantage, but these agents are often separated from confidential data and proprietary knowledge for security reasons. Getting real impact from AI means pairing frontier reasoning with retrieval tools that can safely reach your most sensitive material.

Traditional RAG falls short

Traditional, one-shot RAG retrieves a fixed set of text chunks and asks a model to answer in a single pass. This works when the answer appears in one of the top results, but falters when the model must navigate a long report, follow references, compare multiple documents, or verify the underlying evidence.

The limitation is more pronounced on dense, complex data and documents. The information needed to answer a question may be spread across documents or buried in a particular table, footnote, or clause. One-shot RAG-based search fails to use the full power of frontier AI and to provide reliable answers for three reasons:

• Retrieval without reasoning: The model must answer from the chunks selected during the initial retrieval, even when they are incomplete or not relevant. It cannot decide that it needs a different document, another section, or more context before responding, which limits the impact of the model’s reasoning.
• Chunk-level limit: Critical data is often held in complex multi-modal documents. When asked, “What was the company’s effective tax rate in Q3?” an index may find the correct document but cannot open it, navigate to the table, read the surrounding context, or verify the answer.
• No iteration: Many questions need more than one retrieval pass to get the correct answer. The model may need to refine its search, inspect a promising document, follow a reference, compare multiple sources, keep track of what it has seen, and try a new route when the first results are insufficient. One-shot RAG provides no way to take these next steps.

How Agentic Search works

Mistral Search Toolkit provides open modules for ingesting, embedding, and indexing critical and complex data in the cloud or on-premises. Agentic Search builds on this index by giving the model five tools that resemble familiar file-system operations:

• search finds relevant documents across the corpus using the existing index.
• open opens a specific document.
• navigate moves to a page, section, or region within it.
• read retrieves the content at that location.
• grep finds a pattern within an open document.

Rather than answering only from the initial top-k results, the model can inspect what it finds, refine its search, open relevant documents, navigate to specific sections, and read the source material before answering. The index identifies likely sources; Agentic Search determines what to inspect within and across them.

These tools do not require fine-tuning or model-specific training. As models get better at reasoning and tool use, retrievals get better without infrastructure changes. This is a key property: retrieval quality scales with model capability instead of being capped by your chunking strategy.

Use Agentic Search for

• Long documents. Filings, contracts, manuals, technical specifications, and reports where the answer may appear on a particular page or in a specific table, clause, figure, or footnote.
• Questions across multiple sources. Research that requires the model to find, compare, or reconcile evidence from several documents before reaching an answer.
• Answers that must be verified. Financial figures, legal clauses, regulatory references, and operational data, where the response can be referenced in a stable and specific document location.
• Tables and structured documents. Financial statements, government records, and scanned PDFs where meaning depends on rows, columns, page position, or surrounding context–not narrative text alone.

Indexed retrieval is the right starting point for

• Direct lookups. Short, clean documents where the answer is likely to appear in one of the first retrieved chunks.
• High-volume search. Keyword or semantic lookups that need to return relevant passages without reasoning over or navigating through them.
• Simple, predictable questions. Use cases where the likely source and location of the answer are known in advance and additional retrieval steps are unlikely to improve the result.

More relevant results, faster

We benchmarked Agentic Search on two industry-standard evaluations, using the out-of-the-box Mistral Search Toolkit stack: default chunking, default ranking, no tuning. These results are floors, not ceilings, meaning you can further improve result quality with use-case-specific tuning.

Benchmark results are consistent: the agentic loop delivers substantive quality improvements and navigation tools increase accuracy while reducing wasted tokens, turns, and latency.

FinanceBench: 368 SEC filings, 150 questions

FinanceBench tests financial question-answering over 368 SEC filings. We found:

• The search-only Agentic loop is the biggest quality lever. Moving from one-shot RAG to a search-only loop lifts accuracy by +47.3pp for MM 3.5 and +52.6pp for GLM-5.2–a ~3x improvement for both models.
• Navigation adds accuracy. Adding open, navigate, read, and grep lifts accuracy again.
• Token and performance efficiency improve with better retrieval tools. The full loop with Navigation answers more questions correctly while using fewer tokens.
• Latency goes down where it matters. Across FinanceBench, adding navigation retrieval tools improves latency.

OfficeQA Pro: 696 Treasury Bulletins, 133 questions

OfficeQA Pro is a verifiable numeric benchmark over historical U.S. Treasury Bulletins. We found:

• Agentic Search and the Agentic loop + Navigation are successful against a harder, verifiable benchmark. OfficeQA Pro has numeric answers, scanned PDFs, and deep table lookups.
• Navigation improves quality while cutting waste. Using the full loop improves accuracy while reducing token consumption.
• The harder the benchmark, the more important the retrieval loop becomes. One-shot RAG barely gets started, while the agentic loop allows the model to search iteratively.

Getting started

Learn more about Agentic Search in the documentation. You can get started across cloud and on-premises deployments using either:

• Mistral Search Toolkit. Integrate Agentic Search into your own agents, workflows, and customer deployments.
• Libraries. Use Agentic Search out-of-the-box in Studio and Vibe, without building the retrieval system yourself.

Full article content is not available for inline reading.

Read the original article →

Title: TaoLive Digital Avatar Agent Technical Report: Training Agents to Evolve with Their Harness

Abstract: AI-powered digital-avatar streamers in live e-commerce must answer product questions, engage viewers, and execute changing business strategies in real time. This requires low latency, factual and effective replies, and rapid adaptation to updated campaign, compliance, and style requirements. We develop an evolvable Harness that decouples Skills, Hooks, system prompts, and tools from model weights, allowing runtime behavior to change without retraining. However, Harness evolution creates a moving execution environment: compact models fine-tuned on one configuration may memorize names, schemas, and prompt templates rather than follow the Harness currently provided, while stronger zero-shot models are too slow for real-time use. We address this tension with Harness-Aware Training (HAT), which makes Harness states part of the training distribution. HAT applies task-preserving Harness-State Augmentation (HSA) to Skills, tool schemas, prompt structures, and interaction constraints, and comprises three stages: HSA-based supervised fine-tuning, general on-policy distillation to recover general capabilities, and HSA-based agentic reinforcement learning in a production-informed live-room simulator. Across four evaluation sets with more than 4,500 cases, our compact 35B model scores 94.8 on real-world Live-Stream QA, versus 80.3 for the base model and 93.0 for the strongest evaluated general LLM, while scoring 94.6 on Harness-Variant QA and retaining 83.5 on IFEval. By contrast, fixed-Harness SFT reduces IFEval by 7.7 points. In a controlled complete-agent replay on one NVIDIA H20 GPU with MTP enabled, the system achieves 3.407 s P50 and 8.114 s P95 latency. These results show that HAT produces a latency-feasible compact agent that remains effective under evaluated Harness changes without sacrificing general instruction following.

Computer use, the browser tool, the Skills API, and the Files API are now generally available on the Claude Platform. Automate work in applications that have no API with fewer round trips per task, and build Claude Managed Agents on versioned skills and reusable files.

Bringing Antigravity to Gemini Enterprise: Agentic workflows for every developer

When we launched Google Antigravity, our goal was simple: rethink how software gets built in the era of AI agents. We wanted to move beyond basic code completion and give developers autonomous agents capable of researching codebases, running local builds, actuating browsers, and executing end-to-end tasks.

Since announcing Antigravity’s availability on the Gemini Enterprise Agent Platform at Google I/O, momentum has been incredible. Engineering teams are putting agents to work on critical production systems—like AirAsia, where teams now generate over 50% of their production QA code using Antigravity.

Today, we’re taking the next major step in bringing agentic development to entire engineering organizations: Google Antigravity is now included in eligible Gemini Enterprise subscriptions, alongside brand new IDE extensions for your favorite code editors.

Removing friction between developers and agents

Agentic coding works best when developers can focus on problem-solving rather than license approvals or surface constraints.

By bundling Antigravity into Gemini Enterprise (Standard and Plus licenses), IT and engineering leads can now equip their entire organization with advanced agentic capabilities under a single subscription.

For developers, this means immediate access without waiting for separate add-on licenses or managing standalone accounts. For administrators, it means unified visibility, security governance, and cost management in one place.

To make onboarding effortless for developers, all surfaces natively support Workforce Identity Federation (WIF) and Application Default Credentials (ADC). Engineers log in using their existing enterprise identity, giving agents secure, authenticated access without manual API key setup.

High-autonomy execution inside enterprise boundaries

Giving agents autonomy to run terminal commands, inspect local code, and actuate browsers requires robust guardrails. Antigravity in Gemini Enterprise provides administrators with transparent controls to ensure agents operate safely:

• Configurable sandbox & policy limits: Enforce workspace sandboxing and restrict browser or MCP (Model Context Protocol) server permissions so agents execute strictly within authorized environments.
• Granular budget caps & pooled quotas: Set monthly budget thresholds in Google Cloud Billing across projects, teams, and individuals. Shared token pools prevent purchased quota from sitting idle while ensuring high-demand teams have resources when they need them.
• Overage controls: Opt into overages with strict caps so active workflows aren’t cut off mid-task.
• Central audit logging & data privacy: Enable full audit logging with one toggle to capture prompts, agent tool executions, and generated artifacts. All agent activity remains strictly inside your enterprise boundary under Google Cloud Terms of Service—your code is never used to train base models.

How engineering teams are scaling with Antigravity

Here is how engineering leaders and enterprise partners are putting Antigravity to work across software delivery lifecycles:

"At AirAsia and across the Group, we’re all about empowering our people. Bringing highly capable Gemini models directly into our daily workflows with Antigravity 2.0 does exactly that. We are putting the most advanced AI capabilities into the hands of our entire workforce, from software engineering to finance, marketing, legal, HR and much more." — Nikunj Shanti, CTO AirAsia Next

"Deploying Antigravity in Gemini Enterprise allows Accenture to arm our engineers with Google DeepMind’s premier technology on the secure, trusted foundation of Google Cloud. Abstracting away operational complexity ensures our teams don't have to choose between developer speed and enterprise-grade governance." — Chetna Sehgal, Global Practice Lead Accenture Google Business Group

"With Gemini Enterprise and next-generation developer tools like Antigravity 2.0 and Antigravity CLI, we see significant opportunities to further embed agentic AI... What stands out is how these capabilities are helping our teams evolve from writing code to orchestrating outcomes." — Rakesh Aerath, President, Asia Pacific Global Delivery Centers of Excellence CGI

"Antigravity represents an important advancement in how we help enterprises modernize at speed, pairing Google's agentic engineering capabilities with Cognizant's AI-led delivery engine to turn legacy complexity into a launchpad for transformation." — Rajesh Varrier, President – Global Operations & Chairman Cognizant India

"Embedding Google Antigravity's autonomous capabilities directly into Gemini Enterprise development environments allows our internal and Forward Deployed Engineering teams to automate complex tasks... our teams can confidently focus on orchestrating high-value, secure and cost-efficient outcomes." — Faruk Muratovic, US AI & Engineering Strategy Leader Deloitte

Experience liftoff in your organization

Google Antigravity in Gemini Enterprise is available today for eligible Gemini Enterprise Standard and Plus customers.

• For developers: Check out our Antigravity documentation and download the IDE extensions, CLI, or Antigravity 2.0 app to start building.
• For administrators: Visit the Enterprise Setup Guide to enable Antigravity across your organization.

Micron Technology will invest $10 billion over the next decade in a new research lab in Boise, Idaho, the company said Thursday. The facility will focus on advancing memory technologies, developing compute systems, and supporting future chip manufacturing.

The announcement comes as memory chipmakers ride a wave of demand driven by rapid AI infrastructure expansion. Micron joins rivals Samsung Electronics and SK Hynix in scaling research and development to meet the needs of data-hungry AI models.

The Boise lab will sit at the center of Micron's long-term strategy. The company has not disclosed specific timelines for hiring or construction milestones, but the decade-long commitment signals a sustained bet on memory innovation.

Micron's investment lands at a critical moment for the semiconductor industry. AI training and inference workloads require high-bandwidth memory and advanced storage solutions. Memory has become a bottleneck in some AI systems, pushing chipmakers to accelerate development cycles.

The $10 billion figure is notable. It matches the scale of Micron's previous commitments to U.S. manufacturing, including its New York megafab project announced in 2022. That facility is expected to cost up to $100 billion over 20 years.

Industry analysts see the Boise lab as a direct response to competitive pressure. Samsung and SK Hynix have both expanded their research footprints in the U.S. and South Korea. Micron's move ensures it keeps pace in the race for next-generation memory.

Why Memory Chips Are Central to AI Growth

AI systems depend on fast access to massive datasets. High-bandwidth memory, or HBM, has become essential for GPUs and accelerators. Micron's HBM3E products are already used in leading AI platforms.

The new lab will likely explore HBM4, next-generation DRAM, and novel compute-in-memory architectures. These technologies could reduce data movement bottlenecks and improve energy efficiency.

Micron's research focus extends beyond memory. The company said the lab will also develop compute systems, suggesting a broader push into heterogeneous computing. This could include co-designing memory with processors for AI workloads.

The Boise location is strategic. Micron's headquarters and existing R&D operations are already there. The new lab will consolidate research efforts and tap into local engineering talent.

Memory demand has surged as cloud providers build AI data centers. Micron reported record revenue in its most recent quarter, driven by data center sales. The company expects AI-related memory demand to grow faster than the overall market.

Competing for the Next Memory Breakthrough

Samsung and SK Hynix have announced their own multi-billion-dollar research initiatives. Samsung is investing in advanced packaging and HBM development. SK Hynix is expanding its Indiana packaging facility for AI memory.

Micron's $10 billion lab adds another layer to this competition. The company aims to differentiate through U.S.-based innovation and closer collaboration with American AI firms.

The investment also aligns with U.S. government efforts to boost domestic semiconductor research. The CHIPS and Science Act has allocated billions for R&D, though Micron did not say if it would seek federal funding for the Boise lab.

Anthropic planned to let enterprise customers keep required 30-day data retention on their own cloud infrastructure.

Slack launched a coding product on Thursday. Slack Code adds project-specific channels where teams and AI agents write, review and ship software together. The work happens inside the chat app rather than in a separate browser tab.

The mechanic is simple. Tag a coding agent from any conversation and it spins up a dedicated code channel. Everyone in that channel follows the work through its own tabs. There is one for the conversation, one for the plan, one for the code diffs, and one for a live preview of the output.

Tasks end, and the channel then archives itself. The record survives as an audit log.

Users can “audit code diffs, get live previews of the agent’s output, give feedback, and approve the work before it ships”, Slack said in its announcement. The diff view is the familiar one: old line struck through, new line beside it. The difference is that the whole channel sees it rather than one reviewer in a separate tool.

Slack Code is available today on any Slack plan, The Verge’s Jess Weatherbed reported. Access to each partner agent is a separate purchase, which is where the money sits.

Benioff said this was coming in May

This is a delivery rather than a surprise. TNW reported in May that Salesforce expected to spend $300m on Anthropic tokens this year. The same piece reported that Marc Benioff wanted coding inside Slack next. Three months later, here it is.

Benioff posted a demo video to X on Wednesday evening, as Gizmodo’s Webb Wright noted. Salesforce bought Slack in 2020. It has spent this year turning the app into the front end for its agent strategy, starting with Slackbot in the spring.

ChatGPT is now a founding partner

The partner list deserves a second look. Slack Code launches with agents from Anthropic, Cognition, GitHub, Vercel and OpenAI. ChatGPT sits alongside Claude as a founding partner of Salesforce’s flagship collaboration product.

That is awkward history. Salesforce staff were already confused about the company promoting Anthropic inside Slack back in June, because Agentforce chases the same budgets. Salesforce has answered by adding more outside agents, not fewer.

Anthropic launched Claude Tag in Slack in June. Its product lead framed today’s launch as the natural extension of that.

“So much engineering work already starts as a conversation in Slack with Claude Tag,” said Cat Wu, head of Claude product at Anthropic. “Slack Code gives teams a dedicated channel where the people, the context, and Claude work together from the start.”

GitHub framed it as a division of labour. “Humans set direction, agents close the loop,” said Mario Rodriguez, the company’s chief product officer.

A human has to sign the risky part

High-stakes actions need approval. Before anything merges to production, the agent packages its work for an expert to sign off inside the channel.

“Slack Code also requires human sign-off on high-stakes actions like merging code to production,” company spokesperson Gianna Dimick told Gizmodo. All of it is governed by Slack’s existing enterprise security model.

The guardrail has a reason. Coding agents have wiped codebases during live sessions, and Gizmodo pointed to two such incidents in its write-up. Agents in code channels inherit Slack’s permissions and admin controls, so IT provisions no new identities.

Anyone in a channel can pause, redirect or stop an agent mid-task. A new Agents tab lists every agent and session across the app. It flags blocked threads and offers the same kill switch.

The pitch is that non-engineers get to build

Slack is selling reach as much as speed. Its own worked example starts with a product manager spotting a bug report. The manager tags an agent, and a fix gets reviewed and merged without an engineer having to pick it up first.

“In the Code channel, the whole team and the agent work together on the build,” Katie Steigman, Slack’s vice president of product, said in the demo video. “Nobody’s out of the loop, nobody needs an extra meeting.”

Rob Seaman, executive vice president and general manager of Slack, put the argument in terms of where value shows up. “AI only creates value when it’s part of how a team actually works, not something people go do alone in another tab,” he said.

Software engineering is the starting point rather than the limit. Slack says the code channel APIs will open to the wider developer community. Custom agents could then join channels for marketing campaigns or legal document review.

A separate “Add to Slack” flow lets teams drop in agents built on Lovable, n8n, LangChain, Superhuman and others in a few clicks. Slack has automated the OAuth handshake and the manifest setup behind it.

The workspace is getting crowded

Slack is not alone in selling agents as colleagues. Jack Dorsey’s Block launched Buzz in July, a workspace built for humans and AI agents together. Viktor raised $75m from Accel in May to put an AI coworker inside Slack and Teams.

Slack’s advantage is incumbency. More than 500 AI apps and agents already sit in its marketplace. So do the conversations that precede the code. The bet is that shared context beats a better editor.

What a code channel does to review culture is the open question. Diffs and previews in a chat window make approval faster and far more visible. They also make it social, and a thumbs up in a busy channel is not a code review.

Salesforce charges nothing for the channels and lets the agent vendors charge for the work inside them, which says plainly which half it expects to be valuable.

SpaceX CEO Elon Musk announced today that the company will likely attempt to catch the Starship upper stage with its launch tower arms “in a few months.”

In a post on X, Musk wrote, “Looks like we will probably catch the ship with the tower in a few months. If there had been a tower out to sea where we practiced landing the ship, it would have been caught.” He added that the first reflight of a Starship vehicle is expected by the end of 2026 or early 2027, describing it as “a fork in the road of history for consciousness reaching the stars.”

Looks like we will probably catch the ship with the tower in a few months. If there had been a tower out to sea where we practiced landing the ship, it would have been caught.

First reflight of the ship will be either end of this year or early next. That will be a fork in the…

Musk’s prediction comes amid ongoing progress toward full reusability of the Starship system, a two-stage rocket designed for rapid turnaround and dramatically lower launch costs. Catching the upper stage, known simply as “ship,” with the Mechazilla tower’s mechanical arms would mark a major milestone. It would allow both stages to return directly to the launch site for quick refurbishment and reuse, eliminating the need for ocean recovery.

Musk has previously signaled plans for a ship catch. In July, shortly after SpaceX’s wildly successful Starship 13 mission, he stated that the company would attempt to catch the ship with the tower on the next flight unless problems emerged in the mission data review. Earlier comments also outline conditions such as successful soft ocean landings before attempting a land recovery to minimize risk.

SpaceX has solved Starship’s biggest challenge, Elon Musk says

The latest update from Musk adjusts this timeline to a few months, reflecting the iterative nature of the test campaign.

SpaceX has already demonstrated the tower catch technique successfully with the Super Heavy booster on a couple of occasions. The first successful booster catch occurred during Flight 5 in October 2024, when the massive first stage returned to the Starbase pad in Texas and was plucked from the air by the tower arms.

Additional catches followed on later flights, including Flight 7, proving the concept for the booster and building confidence in the system as a whole.

Achieving a similar catch for the upper stage would represent a significant step forward. The ship returns from much higher speeds and greater heat loads after orbital or near-orbital flight. Success would advance SpaceX’s goal of full and rapid reusability, potentially reducing the cost of access to orbit by a factor of 100 or more and supporting ambitions for frequent satellite deployments, lunar missions, and eventual Mars flights.

Musk has long emphasized that true reusability, refueling rather than discarding hardware, is essential for making humanity a multi-planetary species.

As SpaceX continues refining Starship through successive test flights, the coming months will test whether the ambitious catch timeline can be met. The combination of prior booster successes and improving ship landing precision suggests the company is steadily closing in on this historic capability.

Tesla’s robotaxi service in Austin appears to have gone fully driverless. Over the past fortnight, every one of the 170 rides logged by an independent monitoring project ran with no human safety monitor on board, across 54 different cars.

Two days earlier, a passenger filmed one of those cars driving straight through a line of plastic bollards.

What the tracking shows, and who did it

A crowdsourced project called Robotaxi Tracker logged the rides. Its creator, Ethan McKanna, told The Verge that all 170 monitored rides over two weeks ran unsupervised. “Austin has seemingly stopped supervised rides for a couple weeks now,” he said. Plates previously marked as supervised are now offering unsupervised rides, he added.

One disclosure belongs at the top rather than buried. McKanna spent this summer interning with Tesla’s own Robotaxi team, as The Verge reports. That does not make his data wrong, and Tesla publishes nothing comparable, but readers weighing an independent count of Tesla vehicles should know who compiled it.

The method matters too. The tracker draws mainly on app users automatically logging their own rides, plus other crowdsourced and public information. It captures what observers happened to record, not the fleet.

Part of the jump is better data

The scale of the change looks dramatic and is partly an artefact. As recently as last week, Robotaxi Tracker showed just 28 active unsupervised vehicles across six markets in Texas and Florida. McKanna has now identified nearly twice that number in Austin alone.

He explained why. Some metrics on the site had been lagging, so he revised the sources feeding it and found more vehicles running unsupervised than the tracker had reflected. He is updating the site with the revised figures now.

So two things happened at once. Tesla expanded unsupervised operation, and the instrument measuring it got better at seeing. The Verge reports the Austin shift itself appears to be real, corroborated by riders posting on Reddit and X, and the tracker is one of the few windows available because Tesla does not publish fleet data and usually does not answer press questions.

The expansion is not confined to Austin. Roughly 30 driverless Teslas have been running in Dallas and Houston over the past week, McKanna said. Earlier this summer the unsupervised fleet had appeared to be stalling, or even shrinking.

What “unsupervised” actually means

The word does a lot of work here. An onboard safety monitor is a person in the car who can grab the wheel. A remote operator sits in an office and can advise or authorise a manoeuvre over a data link. Removing the first does not remove the second.

Nobody outside Tesla knows which applied in the bollard clip. Tesla does not disclose how often remote staff intervene, or how many cars one of them covers. A ride with an empty driver’s seat counts as unsupervised to an observer on the pavement, whatever is happening at the other end of the link.

The bollards had been there since 2024

Electrek reported the incident on 18 August. A rider in Austin filmed their car failing to negotiate a curb extension marked off with plastic posts. The car crept forward, reversed, crept forward again, then drove through the posts and carried on.

An audible thud is on the recording, along with the passenger saying “it hit em, it hit em”. There was no safety operator behind the wheel. It is not clear whether a remote operator approved the manoeuvre.

Reddit users then did something useful. Using the Texas Orthopedics building visible in the frame, they located the exact corner on Google Maps. Street View shows those posts have stood there since at least February 2024.

That detail points at mapping rather than sensors, as TechRadar noted. Tesla has declined to use the proprietary high-definition maps Waymo relies on, and it dropped lidar on cost grounds. The car has to identify a fixed obstacle from onboard compute in the moment, and this time it did not.

What Tesla told investors

Ashok Elluswamy, Tesla’s vice president of AI, defended the programme at the company’s second-quarter earnings call. Tesla has driven more than 380,000 robotaxi miles with “zero notable incidents”, he said. The company describes the safety record as impeccable. It has not defined what makes an incident notable.

Set that against the comparison TechRadar draws. Waymo has accumulated roughly 220 million unsupervised ride-hailing miles. Tesla’s 380,000 is about a fifth of one percent of that.

The Austin fleet has also reportedly shrunk, to around 17 cars from about 25 in the spring, inside a geofence far smaller than Waymo’s. Tesla publishes no fleet numbers, so treat that as reported rather than confirmed.

The Cybercab is next

The timing matters because of what comes after. Tesla is preparing to put the Cybercab on public roads, a purpose-built taxi that leaves the factory with no steering wheel and no pedals. Nobody in the car can take over, because there is nothing to take over with.

Tesla employees ride first. The company started by giving its own staff a lift this week, and the vehicles could join the Austin fleet after that.

Texas is why this happens here first. The state has no permitting regime comparable to the one Tesla ran into in Nevada, which granted just 10 after a request for 5,000. A New Jersey bill could exclude Tesla with one line about sensors. Tesla had already dropped the safety monitor in Miami in July.

Four things at once

The wider pattern holds. Robotaxi fleets keep scaling faster than they fix the problems that scaling creates.

In Austin, four things are true simultaneously. The service now runs with nobody aboard. Tesla will not say how many cars that involves. It told investors the programme has zero notable incidents. And a rider filmed one of its cars hitting posts that have not moved in two and a half years. Holding all four at the same time is the honest position, and the Cybercab will test it within weeks.

Waymo has designed a robocar chip to stay ahead of Tesla

5 nm ML accelerators promise 1,000+ TOPS, ultra-low latency

To reach their destinations safely, autonomous vehicles have just milliseconds to ingest and process streaming data from more than a dozen cameras. It's a job that's been handled with off-the-shelf AI components thus far, but Waymo has begun rolling its own AI ASICs to optimize the process. It's not alone.

Revealed in a blog post Thursday, the Alphabet-backed robo-taxi startup's first custom silicon is designed to convert raw sensor data into driver responses as quickly as possible.

Built on Taiwanese foundry giant TSMC’s 5 nm process tech, the chip is specifically optimized to run both more traditional machine learning algorithms like convolutional neural networks and modern transformer models similar to those used to run AI chatbots or image generation models.

According to Waymo, the chip's design incorporates more than 200 million miles worth of autonomous driving data, and is tuned to maximize responsiveness, reliability, and redundancy.

Prior to this, Waymo had employed Intel FPGAs for sensor processing. FPGAs are ideal in low latency applications, which is one of the reasons why high frequency trading often takes place on them. However, compared to dedicated silicon, FPGAs are notoriously difficult to program for and lack the compute density achievable using application specific hardware.

Accidents can unfold in a fraction of a second, far too quickly for a remote operator to take over. So Waymo designed the chip with a major focus on minimizing latency.

“Within those critical milliseconds, advanced ML models build a high-fidelity understanding of the environment to evaluate the safest path forward,” the company explained. This includes performing temporal noise reduction to improve low light visibility in real time.

All of that requires a considerable amount of computation. The robo-taxi startup claims its ASICs are capable of churning out more than 1,000 TOPS of AI performance. But without knowing the precision and power levels the chips are operating at, it’s difficult to draw comparisons to existing autonomous vehicle and robotics platforms.

We’ve reached out seeking clarification, and will let you know if we hear back. But considering that Waymo is specifically advertising TOPS, we’re probably looking at INT8 performance, which would put it in the same ballpark as Nvidia’s Drive AGX Thor platform.

In addition to offering plenty of compute, the chip also needs to be reliable. Vehicles are exposed to a near-constant stream of vibrations, shock, and extreme temperature swings, unlike anything you’d see in a datacenter.

In order to combat this, Waymo has employed multiple layers of redundancy. The chips themselves are liquid cooled by the same coolant system used by the vehicle itself, ensuring that the silicon maintains optimal temps regardless of the weather.

Meanwhile, to ensure a hardware fault doesn’t put passengers at risk, Waymo says each vehicle is equipped with a pair of ASICs. Under normal conditions, the chips behave as a single unit. But in the event one fails or produces an erroneous result, the other can take over.

Air and space craft often include a third system to serve as a tiebreaker in the event of an upset. So, it’s not surprising to see this level of redundancy employed for a vehicle that’s going to be hurtling down roads filled with other vehicles, pedestrians, and obstacles.

To be clear, Waymo's custom ASIC isn’t responsible for all of the vehicle’s functions. The company says that it is working on several other custom chips and systems, but for now, non-ML tasks like orchestration, data movement, and logging are handled by components provided by its partners, which include AMD, Micron, Samsung, Sandisk, and Nvidia.

Waymo is far from the only autonomous vehicle vendor rolling its own custom silicon. Tesla, which launched a limited Robotaxi service in Austin after years of missed deadlines, has been developing custom chips for its vehicles for years.

Waymo will share more detail on its ML accelerators next week during the annual Hot Chips conference at Stanford.

Since June, developers have created thousands of third-party OAuth apps on Cloudflare, with more than a million authorizations since.

OAuth makes delegated access possible. It lets applications act on a user’s behalf without asking them to handle long-lived credentials or hand over a password. That model works well when an application can describe its access needs with a small set of scopes.

Developers use OAuth for SaaS integrations, internal tools, CLIs, and agents. Our permission model has become more granular over time to support better scoping of these different workflows. That is great for security, but it makes a purely all-or-nothing consent screen hard to justify.

Cloudflare OAuth already allows clients to request a subset of their configured scopes. But once the client made that request, the user could not narrow it any further on the consent screen. For the user on the consent screen, the experience was still an all-or-nothing one. If an application requested more access than a user was comfortable granting, their only options were to approve the full request, or deny outright.

MCP servers are a good example of this. An MCP server might request a broad set of permissions, because in theory an agent could use all of them. But most users would not want an agent to have that much access. Before this feature, the only way to handle this was for the app developer to build a custom scope selection screen before sending the user to our consent flow.

Today, we’re introducing OAuth scope customization. Client owners can mark specific scopes as optional when configuring an OAuth client, giving users the ability to grant a narrower subset of an application’s requested access at authorization time.

The OAuth spec already allows authorization servers to grant a narrower set of scopes than what was requested. We built on top of that flexibility to make this work cleanly for every existing app.

More control, without overwhelming users

Our goal with introducing scope selection is to give security conscious users more flexibility to make the right choices for their use case, without turning the consent screen into a long scope checklist.

With scope customization:

• Developers can mark specific scopes on an OAuth client as required or optional
• At authorization time, users can deselect optional scopes from the requested set
• Required and optional scopes are evaluated against the scopes requested for that authorization flow
• If no optional scopes are requested, the consent experience stays the same
• By default, the consent screen still grants the full requested scope set.

Scoping to the authorization request

One important detail is that required and optional scopes are evaluated only against the scopes requested in a specific authorization flow, not every scope configured on the client. That matters because OAuth clients do not always request their full configured scope set.

For example, a client might be configured with user-details.read, workers-scripts.write, workers-kv-storage.write, and zone.read, while marking workers-kv-storage.write and zone.read as optional. If that client starts an authorization flow requesting all four scopes, the consent screen will evaluate all four. In that case, user-details.read and workers-scripts.write remain required, while the user can choose whether to grant workers-kv-storage.write and zone.read.

But if the client later requests only workers-scripts.write and zone.read, then only those two scopes are considered for that authorization flow. user-details.read and workers-kv-storage.write would not be shown or enforced, because they were not requested.

This keeps the consent screen focused on the task at hand, rather than every capability the application could request. It also means existing OAuth clients keep their current behavior by default: if a client does not opt into optional scopes, the consent flow remains unchanged.

Configuring an OAuth client to use optional scopes

Developers can opt into scope customization when configuring an OAuth client. Scopes continue to be configured as they are today, and clients can now additionally specify which of those scopes are optional:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/oauth_clients" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "client_name": "ACME Corp",
    "redirect_uris": [
      "https://acme.org/oauth/callback"
    ],
    "grant_types": [
      "authorization_code"
    ],
    "response_types": [
      "code"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "scopes": [
      "user-details.read",
      "workers-scripts.write",
      "workers-kv-storage.write",
      "zone.read"
    ],
    "optional_scopes": [
      "workers-kv-storage.write",
      "zone.read"
    ]
  }'

In the example above, the client can request all four scopes, but the user may only opt out of the workers-kv-storage.write and zone.read scopes during consent. user-details:read and workers-scripts.write remain required if they are included in the authorization request.

If the client later requests only workers-scripts.write and zone.read, then only those two scopes are considered for that authorization flow. user-details.read and workers-kv-storage.write would not be shown or enforced because it was not requested.

Building with partial grants in mind

When a user deselects any optional scopes and completes the authorization flow, the generated access token will only contain the scopes they consented to. For developers, this means you need to check the granted scope set after exchanging the authorization code, rather than assuming the full requested set of scopes was approved.

An app that handles a narrower grant gracefully, for example an agent that operates within whatever subset of permissions it receives, is one that users feel comfortable authorizing. Requesting only the permissions needed and marking the rest as optional is a good sign to users that your app respects their access decisions.

Scopes for every Product

Over the next few weeks, we will be expanding our account & zone-level role surface to cover nearly every Cloudflare product. That means more API token roles, account membership options, and OAuth scopes, giving customers the tools to secure workloads with the right level of access.

Build with Optional Scopes

Allowing developers and users to better restrict access through optional OAuth scopes is an important step toward a more flexible and trustworthy consent experience on Cloudflare. With optional scopes, developers can build more nuanced authorization flows, and users gain more control over what they approve.

To get started with Third Party OAuth, take a look at our documentation or jump straight to the OAuth apps page in the dashboard and create your first OAuth app.

Thank you to our amazing interns

This feature is one of the many that we built with the help of our 1,111 interns. Congratulations to Miller Vargas and José Enrique Rodriguez on your high impact contributions here. Miller is a senior at the University of Texas - Austin studying computer science and math; and José is a senior at Universidad Panamericana studying engineering, data intelligence, and cybersecurity.

If you have ever watched a CI job sit on “Fetching repository …” while nothing seems to happen, you already know the unglamorous truth about continuous integration: Every job begins by getting the code, and getting the code is not free.

At Datadog, CI fetches code millions of times a week across thousands of repositories. Our largest repositories are monorepos with years of history and hundreds of thousands of files. At that scale, git clone stops being a footnote and becomes a large contributor to CI run times.

This is the story of gitretriever, the Git mirror we built to serve code to CI at Datadog scale. In its first 4 months, gitretriever served more than a billion Git requests and hundreds of terabytes of code. Today gitretriever handles more than 100 million requests each week. Despite the 20× traffic growth since launch, median latency has remained around 40 ms, while fetch-serving CPU on our previous Git backend has dropped by three to four times.

Serving Git to CI, and why it gets hard

Datadog has a unique CI setup: GitHub serves as the authoritative code repository, while almost all of our internal CI workloads run on a self-hosted GitLab installation. CI fetches from GitLab’s Gitaly, fronted by Praefect (Gitaly Cluster’s routing and replication manager) and kept in sync with GitHub by an internal service (aptly named “codesync”). This hybrid architecture has carried us through more than a decade of growth.

But CI load does not grow smoothly. The expanding use of AI coding agents has driven an order-of-magnitude increase in Git traffic, with agents hitting Git far harder and more often than even our most active contributors ever could. That traffic comes on top of the continually growing load from internal deployment, auditing, and security services. As that growth accelerated, the pressure hit hardest where our code is densest: our large monorepos. Operational load increased, CI run times grew, and multi-hour long CI outages became more frequent. It was clear we needed a more sustainable solution.

Why the usual fixes don’t scale

We tried adding capacity, we tried increasing instance size, we tried placing different repositories on dedicated backends, and we tried optimizing build pipelines. Things would improve for a week or two, but then our CI infrastructure would inevitably end up degraded or outright down. So why didn’t any of the usual approaches work?

A single fetch from a large monorepo can consume several seconds of server CPU. At peak, hundreds of jobs perform fetches at the same moment and land on the same handful of nodes. Adding capacity did little to reduce per-node CPU usage. In some cases, adding more nodes made the problem worse.

Before committing to a new architecture, we had to figure out why none of our previous attempts at fixing the problem had worked:

• Scale the backend or add nodes: In our replicated setup, every write had to be copied to every replica. Adding a node increased replication overhead instead of relieving it.
• Put a content delivery network (CDN) or caching proxy in front: The expensive part of a fetch isn’t a static byte range you can cache at the edge. It’s computation that’s specific to each client’s request.
• Clone on demand from GitHub: That simply moves the thundering herd upstream, where we run into server-side rate limits.

The common thread was that we had been scaling the wrong axis. Read traffic scales with the number of CI jobs, but in our replicated architecture, write costs scale with the number of replicas. Every time we added replicas to handle more reads, we also increased replication overhead, and more CPU time went to maintaining the system instead of serving fetches.

To understand why serving those fetches consumed so much CPU in the first place, it helps to look at what happens during a Git fetch.

Why a Git fetch is expensive

To understand why our design works, it helps to understand how Git stores data and where a git fetch spends its time.

Git data types

Git’s object database is primarily built around immutable objects. For the purposes of this post, we’ll focus on three:

• Blobs, which store file contents
• Trees, which describe directory entries (for example, folders and blobs)
• Commits, which store metadata, a commit message, a reference to a tree, and references to parent commits

Each object is identified by a hash of its type, size, and contents. SHA-1 remains the default object format, although Git also supports SHA-256 repositories.

Finally, there are references, which are mutable names stored separately from objects. For example, refs/heads/main identifies the commit at the tip of the main branch.

Objects may be stored on disk individually as loose objects or grouped into packfiles. Within a packfile, an object may be stored in full or as a delta against another object (known as delta compression), which allows Git to efficiently store the complete history of changes to files within a repository. Packfiles are immutable to allow for safe concurrent reads.

Write operations (for example, git push) may introduce new packfiles. A background maintenance process periodically consolidates loose objects and smaller packfiles into new packfiles. Unreachable objects (for example, deleted files) are eventually removed after a certain threshold by being omitted during packfile consolidation.

Git protocol v2

Now that we understand Git’s data types, we can briefly look at how the current (v2) Git protocol works.

The Git client uses the ls-refs command to learn the current object IDs of references it cares about (for example, all branches). The client and server then begin a multi-round negotiation to determine which objects the server needs to send to the client. You can read more about this negotiation process in the Git protocol v2 documentation.

Once the client and server have determined which objects to send, the server creates a packfile containing those objects and sends it to the client.

Constructing the response packfile can be CPU and I/O-intensive. The server locates objects within packfiles by using an index that Git maintains for each packfile. Some objects can be copied as is into the response packfile, while others must be decompressed and recompressed using delta compression. Under a sufficiently large number of concurrent fetches, this packfile construction work can saturate server CPU and storage capacity.

Client behavior, such as requesting weeks’ worth of changes to a large monorepo, can make this more expensive in both CPU and I/O operations. Git attempts to reduce this cost with reachability bitmaps, sparse traversal, multi-pack indexes, and pack reuse. We tried all of these options, but client behavior and the rate at which our monorepos changed still concentrated CPU load on a small number of servers.

The final step of a fetch or pull from a Git server is for the client to read the received packfile and update its local index of available objects. This requires only a small amount of client-side CPU.

Our approach: Many independent mirrors, kept fresh

If the problem is CPU concentrated on a few contended nodes, the solution is to stop concentrating it.

Gitretriever runs independent pods, each of which maintains a fresh local copy of the repositories it serves without waiting for every node to reach consistency. Each pod serves its local copy directly, with no consensus and no multi-writer replication between peers. Gitretriever pods have two roles:

• Mirrors stay in sync with GitHub. We deliberately keep this fleet small because its job is to be a good GitHub client: a handful of well-behaved pollers rather than thousands of them.
• Relays fan out reads to CI jobs. This fleet is larger and autoscaled based on CPU and network load, allowing us to provision enough read capacity to meet demand without turning that growth into additional load on GitHub.

Staying fresh and reducing CPU usage

The architecture works only if every mirror and relay stays close to the latest changes without recreating the CPU bottlenecks we were trying to eliminate. We designed gitretriever around three principles that keep repositories fresh while minimizing repeated work.

Distribute Git pulls across branches

Gitretriever mirrors continually poll the upstream in a tight loop for changes. Gitretriever performs a parallel fetch for each reference it detects as changed since the previous synchronization loop iteration. No single request concentrates an expensive delta compression job on GitHub, and each small pack requires far less indexing CPU than one monolithic monorepo pack. Staying close to the tip of each branch also means that, in any given synchronization loop iteration, only a small number of branches have changed, reducing the number of packfiles we need to fetch.

Spend the sync work once, then reuse it

For the busiest repositories, one mirror cannot serve every client, so changes fan out to a fleet of relays. Relays can connect to mirrors or to other relays. Each relay splits its upstream connection into two channels:

• A signaling gRPC stream: Announces that a pack is ready, propagates reference updates, and communicates mirror and relay topology changes
• A plain HTTP endpoint: Serves the pack bytes themselves

Because Git objects are content-addressed, a relay installs the packfile it receives from its upstream mirror or relay without regenerating, re-indexing, or re-verifying it. It drops the packfile and its index into place, trusting the objects inside by the hashes that identify them. The work of pulling and indexing from GitHub happens once on the mirror, and every relay reuses that work instead of fetching again. As a result, the relay fleet can grow without adding load on GitHub while remaining within single-digit milliseconds of the tip.

Never build the same pack twice

Gitretriever is both a Git client and a Git server. The current implementation uses Git’s default backend storage format: packfiles, reference tables, reachability bitmaps, and multi-pack indexes. That means gitretriever has to make serving other Git clients (such as CI jobs) as efficient as possible.

A fresh push to a busy branch sets off a thundering herd of identical fetches. Gitretriever implements a pack cache, allowing it to reuse previously assembled packfiles for identical client requests. About half of all pack-building fetches are served directly from the cache, skipping the delta compression calculation on mirrors and relays entirely. Cache misses are still served locally by the mirrors and relays, so even a cache miss never becomes a trip to GitHub.

Underneath these are smaller refinements, including a readiness check that understands Git state and keeps a pod out of rotation until its pack count is healthy, along with background repacking that keeps the packfile count under control while the pod continues serving. But the theme never changes: Take the CPU that used to pile up in one place and either spread it out or stop repeating it.

The bigger surprise: Many use cases don’t need a clone

Once every repository had a fresh mirror, something in the traffic caught our eye: Most non-CI workloads don’t need a full repository clone. They wanted a single file at a commit, the SHA a branch pointed to, the list of files that changed, or the merge base of two refs. Cloning an entire repository to answer one of those questions was enormous overkill, yet our internal services, developer tools, and AI agents were doing it constantly.

So we added a small, read-only HTTP API for exactly those queries. Resolving a ref or reading a file takes single-digit to tens of milliseconds. By comparison, a shallow clone of a large monorepo takes on the order of 75 seconds and keeps a CPU core busy for most of that time. Moving these use cases to the API reduces latency and removes load from the entire system.

The non-CI workloads changed how we think about gitretriever. It’s less a faster Git server and more the query layer for Git across our engineering systems.

Rolling out gitretriever safely

Rolling out gitretriever required careful planning. Our CI infrastructure is used by every engineer at Datadog, so one wrong move could bring engineering to a halt. We used feature flags and built in automatic fallback to the old backend into our CI jobs, so if a mirror became unreachable or a fetch failed, the job fell back to the previous path. The worst-case outcome was no worse than before. We then migrated one repository group at a time, starting with the largest monorepo, while watching the old backend’s CPU graph.

When that first monorepo cut over, we saw an immediate step decrease in CPU usage. That confirmed our understanding of the problem: Gitretriever was absorbing the heaviest, most CPU-dense fetches first. Those were the same ones that had been degrading developer experience and driving outages.

The metrics matched our expectations:

• Synchronization time dropped from several seconds to a few hundred milliseconds, making continuous, coordination-free mirroring possible.
• To date, gitretriever has served more than a billion Git requests and hundreds of terabytes of data across roughly 5,500 repositories, and now handles more than 100 million requests each week.
• Traffic grew about 20× in 4 months while median serve latency remained around 40 ms. The system became an order of magnitude busier without getting materially slower.
• The result we care about most: Moving CI fetch traffic to gitretriever reduced the old backend’s fetch-serving CPU by three to four times, even as overall CI activity kept climbing. Its memory footprint dropped in step, which later let us right-size that backend down. The old backend still handles some use cases that gitretriever doesn’t yet support (e.g., rendering the GitLab UI), so we don’t claim we replaced it (yet). But the fetch-path load it had been drowning under is gone.

How we built it: Two engineers, Claude Code, and design doc in nearly every folder

We chose to use Claude Code on this project to accelerate development and to explore how far AI could responsibly assist with building production infrastructure. What made an AI collaborator trustworthy on a system this central wasn’t the model; it was the discipline around how we used it.

We planned before we wrote code, designing each change and iterating on the design through several rounds before committing a line of code. We validated every change with integration tests backed by real metrics and logs, not just unit tests, so the bar for “done” was observed behavior rather than a green checkmark. To keep both the AI and ourselves aligned across a dozen packages, we maintained a living design document in nearly every directory, describing its architecture, data flow, concurrency model, and configuration, and updating it alongside the code.

Those documents ended up serving two purposes. During development, they kept AI-generated changes aligned with the architecture. When ownership of the service transitioned to the team that now maintains it, the same documents became the handoff.

The lesson we would pass on is that the design documents became the interface between the engineers, the AI, and the next team. Ultimately, the quality of your tests and telemetry data sets the ceiling on how far you can trust an AI collaborator.

What’s next

Gitretriever is not finished. We’re expanding the query API so more workloads can skip cloning entirely, allowing us to fully decommission our old Git backend. We’re also continuing the rollout across the rest of our repositories and building for a future where automated and agent-driven workflows ask even more of Git.

A few ideas we’ll carry into whatever comes next:

• Make it disposable so you do not have to make it durable. Some of the hardest parts became much simpler once we made them rebuildable instead of authoritative.
• Content addressing lets you trust data by name. That’s what makes coordination-free replication safe.
• The fastest fetch is the one that transfers nothing, whether that’s a fast-path ref update or an API call that answers the real question without a clone.

More than any single optimization, gitretriever reflects how we approach engineering at Datadog: Push a good system as far as it will go, then, when the scale curve demands it, design the next generation from a better understanding of the problem, validate it against real telemetry data, and write down what you learned so the next team can build on it.

Agent Substrate

NOTE: This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program.

What is Agent Substrate?

Agent Substrate delivers a performant, high density runtime environment for large scale agent deployments. The agent substrate control plane provides full lifecycle management for agent sandboxes, delivering sub-second agent resume/suspend operations, and allows heavy multiplexing of agents onto the same computer infrastructure. It supports multiple sandbox technologies including microVMs and gVisor, enabling consistent lifecycle operations for all sandbox types.

At its core, Agent Substrate maps a larger set of “actors” (applications such as agents) onto a smaller set of ready “workers”, relying on the fact that agent-like applications tend to be idle most of the time to achieve heavy multiplexing. It provides functionality to manage an actor’s lifecycle (e.g. create/destroy, suspend/resume), to assign actors to workers in real time, and to route incoming traffic to them.

Agent Substrate is intended to be a low-opinion system. The workloads it manages don't have to be literal AI agents, but those are the best example of the kind of applications it is designed for. It is not an SDK for building agents, but rather a system for running them at scale.

Agent Substrate leverages Kubernetes for the infrastructure provisioning and worker lifecycle management (Kubernetes Pods). It builds on top of Kubernetes features like Pods and Pod autoscaling, while Agent Substrate provides agent-specific scheduling and control to achieve lower latency. Using Kubernetes as the underlying system enables consistent infrastructure management across all workloads types that are required for end to end agentic deployments and allows holistic infrastructure optimizations for RL scenarios that span agentic, inference and training cycles.

Demo

Watch the Agent Substrate cluster multiplex ~250 stateful actors across just 8 physical pods.

This demo highlights the core developer experience and "Agentic Infrastructure" capabilities of Substrate:

1. Instant Actor Teleport: High-performance suspend and resume of actors onto any available worker in the pool with sub-second activation.
2. State Persistence: Persistent working memory (volatile RAM) and filesystem state preserved perfectly across hibernation cycles via full-state snapshots.
3. Agent Swarm Multiplexing: Demonstrates 30x+ oversubscription by "juggling" a large registry of stateful actors onto a small pool of shared physical pods.

Framework Agnostic & Compatibility

Agent Substrate is designed to be framework and agent harness agnostic. Because it manages standard OCI containers at the kernel level (via gVisor), it can host agents built on any stack.

• Agent Development Kit (ADK): Native support for ADK-compatible actor identity and persistent working memory.
• LangChain: Ideal execution environment for long-running, stateful LangChain agents and sandboxed tool-calling.
• Claude Code & CodeX: Support for high-density, stateful coding environments that preserve terminal and filesystem state across sessions.
• Model Context Protocol (MCP): Deploy secure, sandboxed MCP servers as Substrate Actors to provide durable tools for any LLM.

Ecosystem & Examples

• Agent Executor: A distributed agent runtime that demonstrates building a secure, hyper-scalable agent harness on Agent Substrate.

Status and compatibility

Agent Substrate is currently in early development. It is not ready for production use, and the APIs are almost guaranteed to change. We are not making any guarantees about backward compatibility at this stage, and everything in this project may be changed.

Supported Kubernetes Releases

Currently we aim to support the latest stable release of Kubernetes, and the previous minor release.

Community

For announcements, technical discussions, and community support, please join the ate-dev Google Group.

We host a weekly community meeting every Thursday from 10:00am - 11:00am PST.

Developing

We welcome contributions of all kinds, but the project is VERY young. Our immediate focus is on building out the core system and demos, so we may not be able to review or merge contributions that don't align with those goals in the near term.

Quickstart (Development)

To quickly set up the complete environment:

1. Make sure you have Go, kubectl, and docker installed and configured on your dev machine. We will automatically manage other dependencies via Go, including kind.
2. Run the following steps:

# create cluster and local registry (IPv4; IP_FAMILY=dual|ipv6 overrides)
hack/create-kind-cluster.sh

# install ate, valkey, rustfs
hack/install-ate-kind.sh --deploy-ate-system

# install counter demo
hack/install-ate-kind.sh --deploy-demo-counter

# install kubectl-ate
go install ./cmd/kubectl-ate

# create an atespace (required before creating actors), then a counter actor in it
kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter

# port-forward the network router to bind to local port `8000`
kubectl port-forward -n ate-system svc/atenet-router 8000:80

1. In a separate terminal, send an HTTP request to increment the counter:

curl -X POST -H "Host: my-counter-1.demo.actors.resources.substrate.ate.dev" -i http://localhost:8000/

Demos

We provide several sample applications demonstrating Agent Substrate's capabilities:

1. Counter Demo: A stateful Go HTTP server demonstrating state preservation across suspends/resumes, and dynamic CRD routing.
2. Sandbox Demo (Antigravity): A secure, sandboxed execution environment (running Alpine Linux) that allows arbitrary shell execution while preserving filesystem state across sessions.
3. Claude Code Multiplex: Demonstrates oversubscribing physical hardware by multiplexing multiple Claude Code agents onto a limited pool of workers.
4. Multi-Template: Two ActorTemplates running different binaries share one WorkerPool, across three namespaces.
5. Request Parking: An oversubscribed pool where the router holds inbound requests until a worker frees up, instead of returning 503.
6. Autoscaled WorkerPool: Scales a WorkerPool on its assigned-worker count with an HPA fed by prometheus-adapter.

Tour

Commands

• cmd/ateapi: The core control plane API server exposing gRPC endpoints to manage actor and worker lifecycles.
• cmd/atelet: A node-level DaemonSet that supervises physical worker pods, coordinates snapshotting, and manages state transfers.
• cmd/atecontroller: A Kubernetes controller that reconciles WorkerPool and ActorTemplate custom resources.
• cmd/atenet: A combined networking controller providing DNS, Envoy routing, and proxy sidecars.
• cmd/ateom-gvisor: An interior-pod helper running inside sandboxed worker pods to execute runsc checkpoint and restore commands.
• cmd/ateom-microvm: The micro-VM peer of ateom-gvisor, running actors as cloud-hypervisor VMs.
• cmd/podcertcontroller: A "polyfill" that provides Pod Certificate signers that will eventually ship in upstream Kubernetes (with different names).
• cmd/kubectl-ate: A CLI tool for managing Agent Substrate resources.
• cmd/benchmarking: Synthetic workloads used by the load tests, including glutton, which consumes RAM, disk, and file descriptors on demand.
• tools/setup-gcp: A provisioning utility to set up the necessary GCP infrastructure resources (GKE, GCS, IAM).
• demos/: Sample applications demonstrating Agent Substrate capabilities.

The Rust team is happy to announce a new version of Rust, 1.98.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.98.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.98.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.98.0 stable

Algebraic floating-point methods

The floating-point types f32 and f64 now have "algebraic" methods for addition, subtraction, multiplication, division, and remainder. These allow optimizations on these operations using the algebraic properties of real numbers, even though these properties do not hold with the limitations of floating-point representations. The exact set of optimizations is not specified, but may be similar to the kind of optimization you would see with the -ffast-math option in other languages.

For example, floating-point addition is not associative, so a sum like a + b + c + d must be evaluated in the left-associative order in which it is parsed, like ((a + b) + c) + d. If you write the same sum as a chain of algebraic_add calls, then the compiler is free to reorder it, perhaps like (a + b) + (c + d) to evaluate the partial sums simultaneously. Broader loop-vectorization is often enabled by using these algebraic methods as well.

These methods are non-deterministic, since the compiler is free to choose different optimizations, but they never cause undefined behavior. See the library documentation and the original API change proposal for more details.

Buffered integer formatting

All of the primitive integer types now have a format_into method that takes a &mut NumBuffer<Self> parameter, which is a buffer that is large enough to hold the decimal format of any value of that type. The buffer itself is opaque, but the method returns the formatted &str with a lifetime borrowed from that buffer.

This method also bypasses much of the dynamic dispatch that you would get with buffered write! formatting, which can be a boon to performance. The itoa-benchmark repo now shows that format_into performs similarly to itoa itself, so this could serve as a standard replacement for that dependency and others like it.

Fix interaction between ManuallyDrop and Box

Prior to Rust 1.96.0, there was a bug in the Rust compiler, which made the following code undefined behavior:

let mut x = ManuallyDrop::new(Box::new(1));
unsafe { ManuallyDrop::drop(&mut x) };
let x = x; // UB!

This is because the compiler considers it undefined behavior to move a Box that has been dropped (deallocated), and ManuallyDrop used to propagate that, such that moving ManuallyDrop<Box<_>> where the box has been dropped would also be considered UB.

In Rust 1.96.0 we fixed this, so this code was no longer UB. In this release we have updated the ManuallyDrop documentation, providing a stable guarantee that this code will continue to not be UB in the future. See ManuallyDrop docs and the related RFC 3336 for more information.

Stabilized APIs

• str::substr_range
• [T]::subslice_range
• core::fmt::NumBuffer
• <{integer}>::format_into
• Send/Sync for std::process::CommandArgs
• {fN}::algebraic_add
• {fN}::algebraic_sub
• {fN}::algebraic_mul
• {fN}::algebraic_div
• {fN}::algebraic_rem
• NonZero<{integer}>::from_str_radix
• String::from_utf16le
• String::from_utf16le_lossy
• String::from_utf16be
• String::from_utf16be_lossy
• [T]::strip_circumfix
• str::strip_circumfix
• Atomic<T>::from_mut
• Atomic<T>::get_mut_slice
• Atomic<T>::from_mut_slice
• std::range::legacy

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.98.0

Many people came together to create Rust 1.98.0. We couldn't have done it without all of you. Thanks!

AI coding tools help developers build and deploy LLM applications quickly, but this speed comes with new security risks. Traditional static application security testing (SAST) tools that are pattern based weren’t designed to detect LLM-specific issues such as prompt injection sinks and exposed system prompts. These vulnerabilities often don’t become apparent until applications are already running in production, when remediation is more difficult and expensive.

Datadog Code Security’s AI-native SAST offers coverage for the OWASP Top 10 for LLM Applications to help you detect LLM-specific risks earlier in the development cycle. Developers get actionable feedback directly in the same workflows where they review and ship code, helping them remediate vulnerabilities faster.

In this post, we’ll explain:

• What the OWASP Top 10 for LLM Applications covers
• How AI-native SAST provides detection

What is the OWASP Top 10 for LLM Applications?

The OWASP Top 10 for LLM Applications is an industry-standard reference that describes vulnerability classes specific to applications that use LLMs. The list is the LLM equivalent of the traditional OWASP Top 10. It covers risks related to how user input reaches a model, how model outputs are handled downstream, whether LLM-driven actions are authorized, and more.

The following table summarizes Datadog Code Security’s AI-native SAST coverage within each risk in the OWASP Top 10 for LLM Applications:

How Datadog’s AI-native SAST detection works

Traditional SAST rules require a trade-off. If you make the rules too broad, they produce noise. If you make them too narrow, they miss real vulnerabilities.

Datadog Code Security’s AI-native SAST goes beyond rule matching by using LLMs to reason about code context and data flow. It then independently verifies candidate findings. Findings surface directly in the Datadog platform as pull request (PR) comments and through CI checks via PR Gates.

AI-native SAST coverage for the OWASP Top 10 for LLM Applications is available across Python, Go, Java, C#, TypeScript, and JavaScript. The following examples show vulnerable application code and illustrate the detection approaches for three of these risks:

• Taint analysis for prompt injection
• Control flow analysis for excessive agency
• Pattern matching for hidden context exposure

Taint analysis detection for prompt injection

Prompt injection (LLM01) occurs when external input is injected directly into an LLM prompt without sanitization, allowing the model to treat attacker-controlled data as an instruction rather than content. An attacker can use this method to bypass safety guardrails, exfiltrate data, or manipulate the model into taking actions that the model was never intended to take.

AI-native SAST uses taint analysis to identify paths where untrusted input reaches an LLM call. Consider a Go handler that reads a query parameter and concatenates it directly into a prompt:

1func askHandler(w http.ResponseWriter, r *http.Request){2    // User-controlled input pulled directly from the request3    userQuery := r.URL.Query().Get("q")4
5    // Tainted value concatenated into the prompt without sanitization6    response, err := llm.Complete(ctx, "Answer the following: " + userQuery)7    if err != nil {8        http.Error(w, err.Error(), http.StatusInternalServerError)9        return10    }11    w.Write([]byte(response))12}

In this example, userQuery is an untrusted source, and the LLM call is the sink. AI-native SAST can trace the flow between them and flag any path where the value reaches the prompt without appropriate handling or validation. This analysis focuses the finding on the data flow that creates the risk instead of matching only the presence of an LLM call or user input.

Control flow analysis detection for excessive agency

Excessive agency (LLM03) occurs when an LLM takes consequential actions without having the appropriate authorization checks in place. Such actions include executing code, calling external APIs, and modifying data.

Detecting excessive agency requires control flow analysis because AI-native SAST needs to determine what capabilities the LLM is granted before it can act. Consider this Python example, where an LLM-powered agent is initialized with tools that grant unrestricted access to the shell and file system:

1def create_agent(user: User) -> Agent:2      tools = [3          ShellTool(),  # Can execute arbitrary commands4          FileTool(root="/"),  # Can access the entire file system5      ]6      return Agent(tools=tools)

In this example, create_agent grants the agent unrestricted shell and file system access regardless of who the user is or what they are authorized to do. AI-native SAST can identify that no capability restrictions or authorization checks are applied before the agent is returned with these tools.

In a larger application, the same agent configuration might be reachable through multiple callers or conditional branches. Control flow analysis enables AI-native SAST to examine those paths and flag cases where at least one path initializes the agent without the required restrictions in place.

Pattern matching detection for hidden context exposure

Hidden context exposure (LLM08) is the revealing of sensitive information that is not intended for users. This information can include system prompts, tool schemas, RAG-retrieved content, and developer instructions that are written to logs or returned in API responses.

AI-native SAST uses pattern matching to identify code that exposes system prompt contents. For example, the following Java method writes its system prompt to an application log:

1public String createResponse(String userMessage) {2    String systemPrompt = "You are an internal assistant. Do not reveal...";3
4    // System prompt logged before the LLM call, exposing sensitive instructions5    logger.info("Processing request with context: {}", systemPrompt);6
7    return llmClient.complete(systemPrompt, userMessage);8}

AI coding assistants can introduce this type of exposure by generating debug logging that includes system prompt contents. In this example, systemPrompt does not originate from untrusted input. The value is sensitive because it contains instructions that configure the LLM application’s behavior. AI-native SAST can identify that systemPrompt is passed directly to logger.info(), where its contents could be exposed.

Start detecting LLM vulnerabilities with AI-native SAST

AI-native SAST in Datadog Code Security helps developers identify LLM-specific vulnerabilities before they reach production. Techniques such as taint analysis, control flow analysis, and pattern matching identify risks that require context beyond conventional static rules.

Make zero CVEs your new default

Supply-chain attacks have stopped being isolated incidents somewhere in the past year. The compromises now reach the tools the industry trusts to defend itself, with Trivy and KICS among this year’s targets. Mark Lechner, Docker’s Chief Information Security Officer, called the latest wave ‘a permanent shift in the threat landscape’, and the months since have borne that out. The volume is growing at the same time. Over a quarter of production code is now AI-authored, and agents pull in dependencies at machine speed. If you run a platform team or a security program, this is the math you are already living with. More code and more images arrive every week, almost none of it written by your own engineers, and all of it has become your responsibility the moment it ships.

None of this is news to us. Securing the software supply chain is the problem we’re here to solve. The latest round of updates widens the trusted foundation Docker is building under your supply chain, and tightens how it’s enforced. More of the software inside your images is now built and patched by Docker itself, and security coverage continues after software reaches end of life. Images can be tailored to your environment without losing their guarantees, and policy enforcement now reaches every developer machine.

A trusted foundation for the whole supply chain

It all starts from one principle, and Docker Hardened Images was built on it. Security that doesn’t get adopted doesn’t secure anything. The entire catalog is free for every developer, because a secure baseline shouldn’t be a premium feature. Every image is compatible with Alpine and Debian, the distributions your teams already run, and Docker builds every one of them itself, from source. Adoption is a FROM-line change, not a migration project. And every image is independently verifiable, with signed SBOMs (software bills of materials) and SLSA Build Level 3 provenance, so your auditors work from evidence instead of vendor claims.

A year in, the numbers make the case. The catalog has grown past 4,000 hardened images, plus MCP servers, Helm charts, and ELS images. It draws more than 3.5 million pulls a week, with over a million builds running regularly to keep all of it patched, and open source projects like n8n run production on DHI. The catalog grows the way it always has, driven by what customers request. But the goal was never just a catalog. The goal is one trusted foundation under your whole software supply chain, where the images you run, the packages inside them, the charts that deploy them, and the tools your agents call all carry the same provenance. Security becomes the default from day one, and it holds, without asking your teams to change how they work.

Built from source, down to every package

The hardening keeps reaching deeper into the stack. Docker Hardened System Packages take hardening below the image, to the packages inside it, across both Alpine and Debian, with every package built from upstream source, patched, and maintained by Docker in the same SLSA Build Level 3 pipeline that builds the images themselves. And the repository behind them is open to more than the catalog. DHI Enterprise customers can point apt or apk directly at Docker’s hardened package repository and bring the same packages into images they build themselves, extending the hardened supply chain beyond the images Docker ships to every image your organization builds.

The coverage keeps widening. What began with Alpine now spans Debian, with Python, the catalog’s most pulled image, among the first to ship fully hardened. The work compounds every week, and the Debian and Alpine package lists are public, so you can watch the catalog harden in real time.

If you’ve spent time chasing base-image CVEs, you know why this matters. System packages are notorious for slow fixes; a patch can sit waiting on the distribution’s next release for months or years. Docker doesn’t wait. We patch at the package level, ahead of upstream when it counts, and the fix lands in every image that uses that package, in one build wave instead of image by image. Entire businesses have been built on delivering community-distribution security updates faster than the community. With DHI, that speed is included.

The guarantees hold up under inspection, too. Packages you add through DHI customization, tailoring an image to your workloads, come from that same hardened repository, not an unverified public mirror, so they are hardened system packages in their own right and the SLA that covers the base image extends through everything you add. And because one vendor stands behind the image, the packages inside it, the CVE investigation, and the patch, your auditors get a single chain of signed provenance instead of a stack of vendor assurances.

Your distribution, meanwhile, stays your distribution. Building a hardened package ecosystem from source is a serious engineering commitment, and Docker made it twice, for Alpine and for Debian, so keeping your house standard never costs you your security posture.

Patch past end of life

Production software has a habit of outliving its maintainers. Migrations wait on budgets, dependencies, and test cycles, and CVEs don’t wait with them. That’s the problem DHI Extended Lifecycle Support (ELS) exists for. It keeps end-of-life software patched, with SBOMs and provenance maintained, for up to five more years.

ELS isn’t limited to a set catalog, either. Docker watches the end-of-life calendar and builds coverage ahead of it, and anything you don’t see, you can request. MinIO is the newest addition. Upstream archived the project in February 2026, yet in the DHI catalog it lives on, patched and hardened, and your migration runs on your schedule instead of upstream’s.

Customize at scale, manage as code

Nobody runs stock images in production. You add CA certificates, agents, and the packages your applications demand. The trouble is that in most of this market, the first change you make is where the vendor’s guarantees end, and everything after it is yours to carry. DHI customization works the other way around. You define what your images need, and Docker manages the full lifecycle of your customized images, rebuilding them through the same hardened pipeline on every upstream patch. The SBOM, the attestations, and the SLA travel with the customization instead of dying at it.

Customization operates at scale, too. Bulk customizations run through the UI, CLI, and API, with YAML configuration and GitHub Actions support, so you can tailor hundreds of repositories in one pass and let the rebuilds take care of themselves. And if your platform runs on Terraform, customization is code as well. The DHI Terraform provider mirrors and customizes hardened images with the same pull requests and reviews as the rest of your infrastructure.

The savings are real infrastructure, not a rounding error. Customers tell us they’ve shut off the CI pipelines that existed only to rebuild images, because Docker rebuilds for them. The blind redeploy cadence goes with those pipelines. You ship an update when a fix actually needs to go out, knowing exactly what changed, instead of rebuilding everything on a schedule and hoping QA catches what moved.

For organizations whose data-residency requirements keep images inside the EU, EU-hosted customizations arrive in September. Your customized images will live in Docker Hub’s EU region with the same SBOMs, attestations, and SLA as everywhere else. Residency stops being the reason your hardening program waits.

Harden beyond base images

The same standard keeps moving up the stack. The catalog now carries fully supported Helm charts, so your Kubernetes deployments start hardened too. And it carries a growing set of hardened MCP servers, because the tools your agents call deserve the same scrutiny as the images they run on.

Govern it all with Docker Scout policy

Scanning tells you what’s wrong. Policy is how you keep it from shipping. And enforcement is where most supply-chain programs quietly fail, because hardened artifacts only protect you when your teams actually use them. Developers move fast and default to what works, and the developer machine is exactly where the current wave of attacks aims.

Docker Scout policy closes that gap. It evaluates flexible, customizable policies from the CLI and inside CI, and it ships with the same policies Docker uses to verify every hardened image in the catalog. The policies are written in Rego, the industry standard, and they’re portable, so the same rules that gate a build in your CI travel with your teams to every developer machine in your organization. Gating at the registry matters, but it stops at the registry; developers can route around it all day. Policy that travels to the machine is how you hold every image you run, and every image your teams build, to the bar Docker holds itself to.

It’s an additive control. It works alongside the scanners you already run, and it’s already in the Docker subscription you have.

The foundation is already in your stack

The supply-chain problem is not going to shrink. More code is coming, agents are becoming contributors, and the patch windows regulators expect keep getting shorter. Point tools won’t carry that weight. A foundation that’s secure by default will, backed by an ecosystem that keeps it that way. That is exactly what Docker’s security portfolio delivers. Hardened content on the distributions you already run, customization that keeps its guarantees, support that outlasts upstream, and policy you control, from one vendor accountable for all of it.

And none of it asks you to adopt something new. It’s all in the Docker you already run. Your builds, tools, and pipelines stay the same. Your CVE count doesn’t.

Browse the DHI catalog and pull your first hardened image today. And if you want the full story, how all of this works together, with your questions answered live, join our live webinar in early September. We’d love to see you there.

From the beginning, we at Stark have always committed ourselves to showing up where work is actually happening. That is underpinned by a fundamental belief that accessibility needs to be a core part of how work is done, and not a separate process. That’s why we’re excited to announce that Stark is now available as a connector in Claude, allowing you to embed Stark’s accessibility capabilities directly in your AI workflow.

A growing share of software is now built inside generative AI tools like Claude but they lack the clear, auditable logic that is so important in compliance. Stark closes that gap, and does it across every discipline accessibility touches — design, frontend, backend, mobile, and the program work that governs them — by combining the Stark rule-engine you know and trust, with Claude’s generative capabilities which help you get more work done faster.

What the connector does inside Claude

With the connector active, Stark's data and actions are available to Claude directly in the conversation. You can ask it to:

• Scan across your digital footprint. Create an asset from a Figma file; one or more live URLs; application source code; an iOS or Android build; or a Storybook library; and run it through Stark.
• Pull, assess, and remediate the violations on an asset. Get every accessibility issue found, with the context needed to understand and remediate each one.
• Check the compliance status. Summarize the accessibility posture of a project, a team, or the full Compliance Center, including the controls assigned to you.
• Start from scratch. Haven’t set up your project in Stark yet? No problem. When Claude calls, Stark creates one on the fly, so a scan can begin from a single URL or file with no manual setup.

Where this goes

Across the product development cycle, AI has broadened the aperture for all roles: Designers who build, developers who design, and so on. With product development breaking out of the rigid structures that have shaped it over the past few decades, accessibility needs to follow. When the process gets subverted, tools need to carry the accessibility context directly into the workflow.

The connector runs in both directions: giving the builder a real-time evaluation of the state of accessibility of their work, and it gives accessibility considerations a seat at the table when those critical initial decisions are made, rather than wait until after they've hardened into debt.

We’re proud that Stark is the first dedicated accessibility connector inside Claude, and it won't be the last thing we do there. Lots more to come…

A design team moved from a first draft of DESIGN.md to a self-improving system in just a couple of weeks, using AI to test and refine its own design specification. The process involves generating a spec from code, running an isolated agent against DESIGN.md, and comparing output to a screenshot to surface fixes for the next cycle. Each correction feeds back into the loop, letting the file iteratively improve until Claude runs out of issues or credits run out.

Effective agent onboarding shapes first impressions as much as output quality, so early interactions deserve as much design care as later ones. Research on a sales-outreach agent identified five principles: show value before setup, break configuration into small steps, signal progress during processing, personalize gradually via defaults rather than upfront questions, and clarify capabilities early. Together, these principles determine whether an agent's first five minutes build user trust or cause disengagement.

Your product, shaped to every customer.

An open-source customization layer. Your users build their own features and micro-apps, right on top of your product.

The interface that builds itself.

Your customers describe what they need, and your product assembles it live. Not throwaway generated UI: real micro-apps with actions, automations, and state, theirs to keep. No ticket, no roadmap, no waiting.

“What did I spend when I should’ve been asleep?”

Views on demand

Any slice of your product, composed into a working dashboard.

Standing automations

“Every Monday at 7” becomes software that runs itself.

Their tools, wired in

Gmail, Slack, GitHub, connected as themselves.

Real micro-apps

UI, data, and logic assembled live. The interface builds itself.

It learns your product. It never exceeds it.

One command reads your repo and learns everything: your components and colors, your API as callable tools, your permission rules. What it builds wears your brand, runs sandboxed as the signed-in customer, and never steps outside permissions they already have.

npx vendo init

One app. Everywhere your customer already is.

In your product

Every surface you choose: an overlay, a chat sidebar, a full panel, or remixed into your own components.

In Claude & ChatGPT

Their AI opens it too. Same app, still wearing your brand.

On a schedule

Works while they sleep with exactly the permissions they gave it.

Free where it matters.

The single-player agent is complete and open source, with the LLM judge and metering included. Cloud is everything multiplayer.

Embedded in an afternoon.

Two commands. Vendo reads your app, learns your theme, and shows you every change before it writes a line. Then it checks its own work.

Free

Try everything, solo on Vendo Cloud.

• Includes $5 of usage a month
• ≈ 100 agent turns
• Hard caps — a clear error, never a bill
• The full $5 with GitHub or Google sign-in

Pro

Everything multiplayer on Vendo Cloud.

• Snapshot sharing & live collab
• Publish to your org registry
• Basic console — usage, keys, deployments
• Includes $49 of usage a month

Teams

Governance & visibility for whole organizations.

• Org governance
• Session replay & analytics
• Tenant organizations, out of the box
• Includes $499 of usage a month

Enterprise

Air-gapped self-host for the strictest environments.

• SOC 2 Type II (audit in progress) & SLA
• Air-gapped self-host
• Per-tenant limits & custom roles
• Dedicated support

Everything paid unlocks with one env var: VENDO_API_KEY

Ship the product that reshapes itself.

Embedded in an afternoon. Governed by you from the first render.

Morph any SVG icon into any other.

Animate Lucide, Tabler, Heroicons or any stroke icon set. Optimal rotation solved in closed form, spring physics, zero dependencies.

Click an icon to add it to your set. Icons from different libraries morph into each other: they all share the 24×24 grid.

import { MorphIcon } from "morphicons/react";
import { Menu, X } from "lucide"; // data, not components

<button onClick={() => setOpen(o => !o)} aria-expanded={open}>
  <MorphIcon icon={open ? X : Menu} />
</button>

That is the whole thing — in React, Vue, Svelte, React Native or Astro (no island needed: the icon upgrades to a web component). No wrappers, no keys, no from/to pairs, no configuration. Swap the pair for any two icons above.

Six kilobytes of math.

morphicons solves the optimal similarity between two shapes in closed form (2D Procrustes): if a pair is congruent under rotation, it rotates; if not, it morphs in the aligned frame. Nobody declares rotation groups by hand. Springs are interruptible, corners stay sharp at rest, and the core never touches the DOM, so React, Vue, Svelte, React Native, Astro, Next.js and plain JavaScript are all first-class drivers.

Icons are consumed as data, not components: a d attribute or Lucide’s IconNode format, structurally typed. No adapters, no per-library setup.

core, gzipped, everything included

6.5 KB

runtime dependencies

0

to plan any morph pair

<1 ms

shared rAF for every icon on screen

1

Works with any stroke icon set — on any grid, via fitIcon.

• Lucide
• Tabler
• Heroicons outline
• Iconoir
• Akar
• Untitled UI
• Hugeicons
• shadcn registry

Redesigns fail quietly. A team senses something is wrong, new screens get approved, and six months later the metrics look the same as before. What was missing at the start was a UX audit, a review of where real users stall and what that costs the business.

Strong UX/UI design services start with one before a single screen gets drawn, and the same review run in-house gives your redesign a scope, a ranked problem list, and a number to beat.

Set the Audit Scope Around One Business Problem

Start with the metric that prompted the redesign conversation. Falling activation, checkout abandonment, renewal drops, support volume concentrated on one feature. Write the scope as something testable, like “users abandon between shipping and payment,” which gives every later finding somewhere to attach.

Short conversations with product, support, and sales come next. Fifteen minutes each is enough to surface where people disagree about what is broken, and that disagreement is far easier to handle now than during the final readout.

Then decide what stays out. A review covering the whole product returns shallow observations across forty screens, and a review covering three flows returns evidence someone can act on.

Pull Analytics and Support Data Before Reviewing Any Screen

Numbers show where people leave, and recorded behavior with support history explains what pushed them out. Gathering both before you open the interface keeps the audit anchored to what customers did, since reviewing screens early tends to lock you into your own reading of them.

Five sources cover most products:

• Funnel data for drop-off rates at each step of the flow you scoped
• Session replays filtered to sessions that ended in abandonment
• Heatmaps and click maps showing what people reach for and what they never see
• Support tickets grouped by feature, to find the complaints that repeat
• Recent survey responses, read for the words customers use to describe the problem

Pay attention to disagreement between sources. A feature with clean funnel numbers and heavy ticket volume usually hides a problem your analytics cannot see.

Map the User Flows That Carry the Most Revenue

Write out every screen a customer passes through from entry to completed goal, for the two or three flows tied to money. Onboarding, activation, checkout, renewal.

The map earns its keep twice over. Heuristic findings and test tasks both need a fixed reference point, and numbered steps give them one, so “step 4 of 7” replaces a screenshot with an arrow drawn on it.

Mapping also exposes something teams rarely catch on their own. Flows built around internal logic, like how the database is organized or which team owns which screen, stop matching how customers move. Those mismatches show up as extra steps nobody has questioned in two years.

Run a Heuristic Evaluation Across Every Screen in Scope

Check each mapped screen against an established set of usability principles, most commonly Jakob Nielsen’s ten heuristics. Log every violation with the screen it appears on, the principle it breaks, and the evidence behind it.

Wording decides how findings land. Compare two entries for the same problem:

“The sign-up button placement is wrong and the form needs a redesign.”

“Clicking Create account produces no visible feedback, so the screen reads as frozen until the next page loads.”

The second gives a developer something to fix and gives a stakeholder nothing to argue with. Keep judgment out of the log and put observable behavior in its place.

Coverage improves with reviewers. Nielsen’s own project data put a single evaluator at around 35 percent of the usability problems in an interface, which is why three to five reviewers working independently is the standard recommendation when budget allows.

Test the Same Tasks With People Outside the Building

Give five to eight people the tasks from your flow map and watch them without helping. Internal reviewers carry product knowledge customers do not have, and friction invisible in a review meeting shows up within thirty seconds to a stranger.

Recruit for the audience you scoped

Participants should match the customers behind your metric. A B2B admin panel needs admins, and testing it with general users produces feedback you cannot use.

Assign outcomes, not clicks

“Add a teammate and give them billing access” gives you behavior. “Click Settings, then Members, then Invite” gives you a demo of your own navigation.

Record hesitation, wording, and abandonment

Note where people pause, what they expect the next screen to show, and which step they give up on. The words participants use describing their confusion end up being the most persuasive material in your final report.

Check Accessibility and Load Performance in the Same Pass

Both fall outside standard design review, and both can cancel out design fixes that look correct on their own.

Run the screens in scope against WCAG criteria, covering contrast ratios, keyboard navigation, visible focus states, and form labeling. Pull Core Web Vitals for the same screens.

Sequencing is the reason to do this now. Rebuilding a form for speed when it still fails keyboard navigation produces a faster form that some customers still cannot complete, and the second round of fixes costs more than the first would have.

Record What Customers Already Complete Without Trouble

Keep a second list running next to your problem log. Every pattern people move through without hesitation goes on it, including the ones nobody has ever complimented.

Redesigns break these constantly, because no one wrote them down and the new interface had no reason to protect them.

The keep list also answers the question leadership asks after every readout, which is how much of the product needs rebuilding at all. Evidence that four flows out of seven perform well changes the size and the price of the project.

Rank Findings by User Impact and Build Effort

A log of forty problems in no particular order gets read once and shelved. Score each finding on two axes and sort by the result.

Sorting turns the log into a decision about scope. When the top entries are cheap to build and cover most of the lost conversion, the redesign gets narrower, and sometimes it stops being a redesign.

Hand the Audit Over as the Redesign Brief

The audit ends when three items reach the design team. Your ranked list sets what gets fixed and in what order, the keep list marks what stays untouched, and the current numbers on the metric you scoped at the start set the bar the new design has to clear.

That third one gets skipped most. Capture task completion rate, drop-off, or time on task before anything ships. Without it, nobody can prove afterward that the redesign helped.

ChatGPT's latest update lets users work with conversations from Apple's Messages app. The feature works with iMessage, SMS, and RCS. It is available across all plans in the ChatGPT desktop app for macOS. There are privacy and control risks with giving ChatGPT such access, so users should take care before granting persistent approval.

Full article content is not available for inline reading.

Read the original article →

Ox Alpha is a reasoning model designed for coding, sustained agentic work, and production workloads. It is suited for long-horizon software engineering, complex reasoning, and workflows that combine text with visual context. Ox Alpha is developed and operated by a provider who has chosen to remain anonymous. OpenRouter routes requests to it and is not its developer, owner, or provider.

OpenAI launched its Strategic Futures team to study how society could preserve individual autonomy as advanced AI reshapes economic and political power.

Anthropic is preparing to file for its potential mega-IPO as soon as the end of this month. It is expecting to match or beat the size of SpaceX's record-setting debut. Ahead of the IPO, Anthropic is set to finalize a revolving credit facility that will raise more than its roughly $10 billion target. The AI lab is considering adopting super-voting shares that would give its co-founders greater control over the company.

One of the eternal schisms in programming is over the question of whether the standard library should be minimal or encompassing. This is the wrong question to ask. The right one is:

Which social architecture creates a high-quality standard library?

Python is always brought up as example of leaky batteries exploding in slow motion, but this has nothing to do with size. The problem with Python’s stdlib is its, ahem, uneven quality. Some standard library modules don’t follow language naming conventions! You know which unittest module I am talking about :-)

But even that is not a mistake. It’s actually Python core’s advantage — that it makes functionality available early, not thinking about the future too much. That’s how we ended up with ossified cAPI which makes CPython the language, but that is also how we ended up with Python powering data scientific revolution.

The Go standard library is similarly encompassing, but it is held in a high regard. Go team has institutional capacity to deliver well-designed API for the standard library, and then some: https://pkg.go.dev/golang.org/x

Rust is an interesting case. The 1.0 standard library APIs are brilliant. Collections and iterators are a work of art. But it also feels that, while the current team has the capacity to preserve existing APIs and fill in some gaps, the capacity to execute design decisions is limited. While golang.org/x captures excess capacity, rust-lang-nursery is a graveyard. Maybe I am over-indexing on my favorite hobby-horse, but it seems that the reason for Rust not having an API to get a stream of random bytes from the OS in 2026 is that, while it is an easy technical problem, it requires tricky organization architecture (including getting money in peoples’ pockets, of course) to actually get solved in the high-stakes environment of a world-wide coordination problem called a programming language.

Intelligence services were never limited by what they could steal, but what they could read. Reading was the expensive part, so collection had to be selective. Every company that told itself it was too boring to be a target was relying on a foreign analyst's workload. AI removes this constraint. Closed source only removes your ability to see your exposure - it doesn't remove it.

The rapid rise of Chinese AI models has sparked a host of questions about how these labs get so far so fast. However, the careers of the founders of two of the biggest Chinese labs show that China's AI push is nothing sudden. Tang Jie, who founded Z.AI, has been working on machine learning for about a quarter of a century. Yang Zhilin, who leads Moonshot AI, was Tang's former student.

China’s robot traffic police can direct cars, scold jaywalkers, and give a lost tourist directions to the nearest metro station. What they cannot do is stop anybody, and that limitation is written into the design rather than left to the machine’s discretion.

The clearest deployment sits in Hangzhou, where the local traffic police put 15 humanoid robots on duty around the West Lake scenic area on 1 May, timed for the Labour Day crowds.

Chinese state media described it as the country’s first robot traffic police squad, working alongside human officers rather than in place of them, which is the framing every Chinese city has used since the first AI-run police station was announced.

The job description is narrower than the word RoboCop suggests. The machines guide pedestrians and riders of non-motorised vehicles away from violations, help manage traffic flow, and answer navigation questions from tourists using large speech models plumbed into live traffic data.

They also watch. Visual recognition picks up violations as they happen, and the robots perform traffic command gestures synchronised with the signal cycle, which is the sort of detail that only becomes impressive once you consider how badly a machine can misread a junction.

The enforcement gap is the interesting part. When a robot spots an infraction, it does not issue anything, and it certainly does not detain anyone: it records what it saw and forwards the file to the traffic police bureau’s early warning centre, where a human decides what happens next.

That arrangement leaves the robots as very expensive witnesses with excellent posture.

It also keeps the deployment on the right side of Chinese policing law, which vests coercive powers in officers rather than equipment, and it sidesteps the question of what happens when an autonomous system gets an identification wrong.

Endurance is the other constraint. The Hangzhou units run for eight to nine hours a day, which is a shift rather than the always-on surveillance layer that early coverage of the programme implied.

The pattern is spreading. Xinhua reported in January that AI-powered robots had begun taking up traffic duties across several Chinese cities, and by the May holiday, the same outlet was describing robot police patrols as a feature of urban management rather than a pilot.

What makes this more than a novelty is who is supplying the hardware. China shipped tens of thousands of humanoids in the first half of this year, and municipal contracts are one of the few places where those machines have a paying customer, a point that sits underneath Unitree’s Shanghai listing and the sector’s valuations more generally.

Robotics companies in China have struggled to find commercial demand outside laboratories, and the commercialisation problem has not gone away just because a city bought 15 units. Public procurement, though, is patient in a way that consumers are not.

Whether the machines are useful is harder to establish than whether they exist. State media accounts are the primary source for the Hangzhou deployment; no independent audit of violation-detection accuracy has been published, and the traffic bureau has not said how many of the robots’ referrals resulted in a penalty.

China has also learned recently how a fleet of autonomous systems fails in public, after more than 100 Baidu robotaxis froze mid-traffic in Wuhan. A robot that can only file a report is, by that standard, a conservative piece of engineering.

There is a public-relations dimension that Beijing has not tried very hard to hide. Putting humanoids in uniform on a tourist promenade is an unusually cheap way to make a domestic industrial programme visible to ordinary people, and West Lake on a public holiday is about as visible as China gets.

It works in the other direction too. Every hour a robot spends waving traffic through a junction is an hour of real-world data collected in conditions no laboratory reproduces, which is precisely the input the sector says it lacks.

More cities are expected to follow Hangzhou, and the units in service now are effectively a field trial of what the public will accept. The arrest powers stay with the humans, at least for the moment.

Theory of Fluids Enters the 21st Century

In the second half of the 20th century, a conceptual tsunami swept through physics. The discovery that our world emerges from a microscopic world of molecules, which emerges from an even more microscopic world of subatomic particles (which in turn emerges from even stranger stuff) triggered the rewriting of our theories of matter.

But the revolution didn’t reach fluids. Their governing equations remained in their simple, vintage form: the Navier-Stokes equations, first developed in the 19th century. The Navier-Stokes equations are enormously successful at predicting how fluids flow and swirl. But they fail to account for the existence of swarms of microscopic bits that make up matter.

Now physicists have a theory that does. It is the fruit of a 20-year effort to rebuild the theory of fluids from the ground up. Along the way, physicists have come up with a whole new way of defining what it means to be a fluid, based on fundamental properties known as symmetries, and have shown that the Navier-Stokes equations are a consequence of symmetries, which explains why the equations take the forms that they do.

By understanding the origins of the Navier-Stokes equations, researchers have found a way to go beyond them, redefining what it means to be a fluid and predicting new behaviors that stem from the motions of microscopic particles.

The trail to understanding fluids as the product of the microscopic world was blazed, ironically, by physicists thinking about some of reality’s biggest scales. It would take insights from researchers studying black holes and the universe at large to finally bring fluids into the modern era.

The Dawn of Fluids

For centuries, scientists have understood the basics of fluids.

In the 1750s, the mathematician Leonhard Euler adapted Newton’s second law of motion — the same one that gives us F = ma — to predict the motion of liquids. Euler’s equations work perfectly for “perfect” fluids, in which a current can flow forever because the fluid has no viscosity — a sort of intrinsic stickiness — to slow it down.

In the early 1800s, Claude-Louis Navier and George Gabriel Stokes gave Euler’s equations an upgrade. The new Navier-Stokes equations could handle any fluid, perfect or not. They could handle the way one fluid dissipates in another, like an ink drop spreading out to fill a glass of water, and the way fluids (including air, which is technically a fluid) experience friction.

Today physicists and engineers use Navier-Stokes to shape aircraft wings and yacht propellers; to forecast where a hurricane will make landfall; to model how climate change will increase the risk of drought; and to predict the behavior of flows of lava, clouds of ash, and even the interiors of stars.

They also know that there’s more to fluids than Euler, Navier, and Stokes appreciated.

The Navier-Stokes equations presume that fluids are continuous substances that flow perfectly smoothly, no matter how much you zoom in on a point. But in fact, fluids are amalgamations of molecules and atoms. As you zoom in, you’ll eventually discern tiny blips in the flow due to this grainy nature, blips that the classic fluid equations lop off.

“Navier-Stokes is very much an approximation,” said Michael Landry, a physicist at the Massachusetts Institute of Technology. “It’s not an exact equation.”

In this way, our theory of fluids is an outlier. In the 1900s, as we uncovered the structure of the world at smaller and smaller scales, physicists revamped many of their theories of matter to take the existence of atoms and the like into account.

The new theories were also approximations, because tracking the motion of every last atom is impossible. But over the decades, physicists found a way to rewrite the theories and re-derive them in a more atom-friendly way.

In the 1970s, Kenneth Wilson, a physicist at Cornell University, gathered up all the pieces and put them into one mathematical package. Wilson showed, with rigorous calculations, why the smaller scales bleed through to our level in mercifully few ways. He developed a whole new method for building high-level theories, called effective field theories, that would form the new foundation for much of physics. The work would win him a Nobel prize.

It all started with magnets.

Symmetries Over Substance

Since the 1960s, physicists had been puzzling over a common property of metals. When a metal is cooled, its atoms eventually align, causing it to magnetize. Mysteriously, this collective alignment always happens at precisely the same speed, whether the metal is iron, nickel, cobalt, or another material.

Wilson’s approach would eventually show why. The key was to look at a material’s symmetries.

You can think of a symmetry as a change that doesn’t matter. A square has some symmetry; you can rotate it by 90 degrees, and no one will notice. A circle has more symmetry; you can rotate it by any angle you like without consequences.

Wilson used symmetries to calculate exactly how the math that describes any material will change as you zoom in and out. He laid out a two-step process.

The first step is to identify the symmetries of your system at the most microscopic level you understand. Take magnets, for example. Their atoms are laid out in some kind of grid, breaking the underlying continuous symmetry of space. (You have to move the magnet by one space on the lattice for it to look the same.) The atoms also have the freedom to point in any direction — another symmetry. Symmetries like these determine exactly which mathematical terms belong in your theory.

The second step is to zoom out toward the macroscopic level. Wilson’s mathematical machinery tells you whether each term in your theory will grow or shrink as you do so. What he found was that as you zoom out, most terms shrink nearly to zero. This has to do with the fact that as you zoom out, your mathematical vision blurs. Details related to individual atoms, or small groups of atoms, become too small to care about. Only the terms tracking broad trends survive, and you land on a short and sweet theory of magnetism — an effective field theory — disconnected from almost all the atomic details.

“This is the power of Wilson’s understanding,” Landry said. “You can just skip to the answer.”

With this machinery, Wilson solved the mystery of why many magnets magnetize at the same rate. The zooming-out step passes through a point at which all magnets look the same, whether their atoms are arranged in cubes or tetrahedra. All that matters is that the atoms have a symmetry that lets them point in any direction. (Magnets whose atoms are pinned down to spin in a plane, for instance, magnetize at a different rate.)

Wilson’s work also clarified why a few properties, like the temperature at which the magnetization takes place, vary wildly from magnet to magnet, even when they have the same spin symmetry. These properties are related to the size of the few surviving terms.

The symmetries tell you the overall shape of the terms that stay large, but not exactly how large they are. The sizes of these terms act like threads lightly tethering the macroscopic world to the microscopic one.

Over the following decades, Wilson’s machinery seeped into many areas of physics. Physicists used Wilson’s calculations to justify the previously murky mechanics of quantum field theory, which treats each particle as a wave while washing out the less significant effects of the smallest vibrations. Wilson’s contributions also shaped modern theories of certain phases of matter, like solids.

But when it came to fluids, scientists remained stuck. Their defining symmetries weren’t yet clear.

How To Define a Fluid

The first break in the case came in the 2000s, when a group of cosmologists was using Wilsonian thinking to develop an effective field theory for the universe as a whole. As they did so, they stumbled upon a key insight: The universe’s expansion breaks a crucial symmetry in space-time.

In general, space and time have no reference point against which you can measure speed. If you’re in a windowless spaceship, you can’t tell whether you’re moving quickly, slowly, or not at all. Space-time has a symmetry with respect to speed.

But in the expanding universe, there is a special reference point against which you can discern a motion: It’s the one in which the expansion of space itself moves galaxies uniformly away from you. If you were to leave your galaxy in a spaceship and travel against this cosmic recession in a particular direction, you would see the galaxies in front of you recede more slowly than the galaxies behind you.

Fluids, the group noted, break the same symmetry. If you’re immersed in a resting liquid, you can tell you’re at rest. And if you start to swim, you’ll feel the drag of the fluid as it moves past you. The resting fluid, like the expanding universe, lacks the underlying speed symmetry of space-time. Meanwhile, it has other standard space-time symmetries; rotations and translations don’t change the fluid.

“At the level of the symmetries, they are the same,” said Alberto Nicolis, a physicist now at Columbia University, who worked on the effective field theory of the cosmos.

The resemblance got the group thinking, but they needed one more ingredient. They found it by considering what changes they could make to a fluid without changing its energy — another set of symmetries. They realized you could always swap two parcels of a fluid for free. You could also shuffle three parcels, or four, or any number. In contrast, you can’t exchange any regions of a solid without paying an energy toll, through rupture or serious internal stress, so solids lack these swapping symmetries.

The group had identified an unlimited number of fluid symmetries. They considered what terms these symmetries would require in the theory and then, channeling the spirit of Wilson, zoomed out and watched the microscopic details wash away. They landed right on the Euler equations, perfect for perfect fluids, derived from fundamental symmetry principles.

The resulting theory was the first to apply the full effective field theory treatment to fluids. “It’s the foundational text of all of this,” Landry said.

The next step would be to include the imperfect fluids, too.

A Black Hole Lead

The new effective field theory accelerated an effort within a community of scientists studying black holes, which have their own strange connection to fluids.

A theoretical breakthrough from the late 1990s had established that, under special conditions, you could view a spherical black hole as a flat quantum soup. Theorists had connected the viscosity of the soup, which enabled it to dissipate energy, to the black hole’s ability to gobble up energy and hide it. “Things can fall into the black hole,” Nicolis said. “That’s a form of dissipation.”

Physicists already had an effective field theory of black holes: Einstein’s theory of gravity. If a black hole had a secret identity as an imperfect, energy-dissipating, viscous fluid, then an effective field theory for imperfect, energy-dissipating, viscous fluids should exist, too. Multiple teams raced to find it.

Hong Liu, a physicist at MIT, led one of the groups. The group noticed that the surface of a black hole had a swapping symmetry akin to the one Nicolis and company had used to define a fluid; you could exchange patches of a black hole with each other without disturbing the black hole’s structure.

But that symmetry wasn’t enough to describe an imperfect fluid. To achieve that, Liu’s group — which included the researchers Michael Crossley and Paolo Glorioso — resorted to an old trick from quantum mechanics. They duplicated the substance in their theory, effectively adding a second fluid with a clock that ticked backward while the first fluid’s clock ticked forward. Comparing the two fluids at any given moment let the researchers keep track of random variations.

The team had one last problem. They knew that a zoomed-out fluid must obey the laws of thermodynamics: It has to have a temperature that varies from place to place, and a tendency for any hot patches to blend with cold patches as time ticks along. At the same time, they knew that at the zoomed-in level, the buzzing of atoms makes no distinction between past and future. Was there a way to tie the thermodynamics of the fluid to the two ways that time worked?

After some trial and error, the group found a symmetry that did the trick. The transformation switched the two fluids, reversed their clocks, and fiddled with the temperature in a particular way. If it happened a second time, the fluid would return to its original state. The different notions of time, and their ultimate compatibility, flowed from this symmetry, which was unlike any that physicists had seen before. “It’s a funny symmetry,” said Kristan Jensen, a physicist now at the University of Victoria in Canada, who also contributed to the black-holes-to-fluids effort. “And it’s essential. Before that, there are a ton of terms. And then [everything] collapses down and you just get known phenomena, nothing more and nothing less.”

They were done. From these symmetries they could write down a theory and zoom out to derive the Navier-Stokes equations. In 2015, Liu and his group posted their new effective field theory. It was a magnum opus, spanning 110 pages. “It blew my mind,” Landry said.

Fluid Follow-up

It wasn’t immediately obvious how to harness the highly technical theory for specific applications. But Liu and Glorioso rewrote the equations in a more accessible way in 2018, and the calculations started to trickle out.

The new work allowed theorists to work more efficiently and push their calculations further. In particular, they were able to ferret out tiny terms in Navier-Stokes equations that had previously been ignored, terms that capture some of the effects of random molecular motion. “The stuff that we’re doing is more than just sort of an alternate version [of fluid dynamics],” Landry said. “It is actually strictly more correct.”

Luca Delacrétaz at the University of Chicago used the new theory to calculate more precisely how heat spreads through a liquid — and found that it moves more slowly than expected during its first few moments, due to random jitters. The effect is far too small to measure in water, but it becomes more substantial in quantum systems made from a limited number of particles.

Other researchers used the theory to derive Navier-Stokes analogues for exotic states of matter, like fracton matter. Roughly speaking, fracton matter is composed of groups of particles that collectively act like one particle. Individual “fractons” stay trapped in place; only when fractons band together can they move about.

In 2020, Andrew Lucas, a physicist at the University of Colorado, Boulder, and his collaborators spotted new symmetries in the fracton phase and used the effective field theory framework to derive a fracton version of the Navier-Stokes equations. The work opened the door to understanding whole new classes of liquidlike phases of matter.

In 2024, Lucas and his group built on Liu’s theory by making explicit the basis for some of its construction. They used a newly discovered “strong” symmetry, related to the fact that the total number of particles in a fluid is always the same. That symmetry is partially broken, becoming a “weak” symmetry, due to the fact that the exact number of particles in a specific region of a fluid can vary from moment to moment. The consequence of this broken symmetry, they found, is a long, slow diffusion.

Lucas and his collaborators integrated this symmetry into Liu’s effective field theory in 2024. “Our main contribution was to justify what Liu was doing,” Lucas said. “To me it’s a closure of a story.”

While the effective field theory framework has catalyzed new calculations, the real prize may be more conceptual: a new definition of what makes a fluid a fluid. A fluid is any material with a particular set of symmetries, no matter what it’s made of.

“There’s something magical about fluid dynamics,” Nicolis said. “There’s oil, water, mercury. These are all very different, microscopically, very different things that, in practice, behave very similarly when you look at how they flow.”

Code fixers have fired up the AI warp drive. Strange new worlds await

With more patches per month than at a pirate convention, the bug must be an endangered species. Well, about that.

It is the best of times, it is the worst of times – especially if your job is keeping systems patched and up to date. Microsoft has gone from 60-90 Windows security fixes per month last year to a record of 600+ this July. Oracle and Linux are following the same path, and they are very much not alone. The good news is that a lot of bad things are getting fixed very quickly. The bad news is that patches can bring side effects of their own.

There are two mechanisms at work, both driven by the source of and solution to all our woes, AI. The first is that the appropriate LLMs and their humans have got very good at bug hunting. Like demon archaeologists, they've started thrashing their way down through the stratified layers of long-established code bases, bringing a huge backlog of previously buried bugs to the surface.

Complicating matters, LLMs are also writing an awful lot of code, some of which is not very good. It is making its way into production for all the old reasons – marketing-led deadline pressure, shape-shifting specs, and Brownian goalposts – until the implacable hostilities of reality spit it back out.

The result is a very interesting dynamic of conflicting pressures that is changing the nature of patches. It's easy to assume that the current explosion of bug fixes will die down as the code bases are repeatedly refined and purified, and that this time next year we'll be seeing rather fewer patches than in the pre-AI days, let alone today. It's a nice thought. Similarly, with the old code in a new state of grace, attention can turn to properly generating and testing the AI-powered stuff, so that it too calms down.

Other factors will work against this. Newer models may find new classes of bugs or start refactoring for efficiency or structural reasons. Not all patches fix bugs, and not all bugs are vulnerabilities. CVEs are easy to count, but aren't the full story. The pressure to release early won't go away either; better tools often encourage greater recklessness. Vibe check, anyone? Finally, the bad guys aren't going away and will be using all the new shiny to keep up their side of the arms race.

This whole system of conflicting pressures in a morphing environment has not been well studied, and the future shape of patching is unclear. One analogy suggests itself, that of stellar evolution.

Astrophysics fans know the score. After a star condenses out of gas and dust, gravity compresses its core until it becomes hot and dense enough for nuclear fusion. Hydrogen nuclei fuse to create helium, releasing energy that pushes outward against the gravity trying to squeeze the core further, and the star shines steadily. When the hydrogen in the core runs low, that balance changes. Depending on the star's mass, it may begin fusing helium and successively heavier elements before fusion becomes impossible. The possible endings include explosions visible from other galaxies, black holes, neutron stars, cooling relics, and more.

In this analogy, patch generation is fusion pressure, bug generation is gravity, and the nature of bugs and patches evolves as the two interact and the code changes. If any unit of code, no matter how badly written, can contain only so many bugs, then the model tends toward the white dwarf outcome: a remarkably long-lived object that passes the rest of its existence without drama or intervention. It no more needs patching than a pebble does.

It is certainly true that, despite the best efforts of many, code design and implementation are ultra-reliable compared with the days when Windows BSOD'd every other day – and on the hour if you installed drivers – and Big Three PC database company Ashton-Tate's industry nickname was Crashed and Late. If the object of the industry was to produce pristine versions of, say, Windows 10, then the white dwarf patchless future would be the most plausible.

That is not the industry objective. If a star is big enough, its ending can be a supernova birthing a black hole, a singularity beyond observation where gravity has won. In this case, the battle to write ever-more complex yet bug-free and optimal code is locked in the attempts to find ways to break it, either as part of the production pipeline or in adversarial attacks. If models advance as hyped, iteration times could become so short, and constantly morphing production code so difficult to analyze, that the very model of patching breaks down. The daily build becomes the product, and you get the latest version every time you run it.

That may seem an extreme cosmology, but it's not so far from what happens every time you fire up a cloud app. You've never had to patch Google Docs, but you've had features appear and disappear overnight without explanation or warning. This, then, may be the shape of patches to come, a universe where the increasing power of coding and testing models enables new and stranger commercial pressures to modify the software you depend on.

You don't have to plot that path. Some software has a more steadfast physics. Not for the first time, those who navigate by the constant star of open source may have the safest voyage.

Mature experimentation programs eventually have to report the cumulative impact of their shipped changes. The request might come as an ROI story for leadership, a revenue update for finance, or a gut check on the quarter’s progress.

The tempting shortcut is to sum the observed lift from each winning experiment and report the total. That naive sum almost always overstates the truth because of a statistical artifact called the winner’s curse.

Two established methods provide better estimates of cumulative impact. The first is a holdout, which combines many shipped treatments into one randomized experiment and estimates their cumulative effect directly. The second corrects the estimates you already have for the winner’s curse and aggregates them. The correction is grounded in well-established statistics. Datadog’s Cumulative Impact feature runs it for you, fitting the model and producing the aggregate impact estimate without a holdout. You can estimate cumulative impact from experiments you have already run, without setting aside traffic for a quarter-long holdout. The analysis can cover an entire experimentation program or focus on one team’s experiments by filtering on tags.

In this post, we’ll explain why naive summation overstates impact and how a holdout measures cumulative impact directly. Then we’ll cover what a holdout costs and how Cumulative Impact estimates the same number without one.

Why naive summation overstates cumulative impact

Teams need to measure the cumulative impact of their winning experiments, but adding up the observed lifts gives a biased estimate. The sum is biased upwards because of the winner’s curse, the tendency of statistically significant results to overstate their combined effect.

The bias comes from two properties of A/B test estimates.

• Estimates are noisy. The lift your test measures is not the true effect. It is the true effect plus sampling variation.
• Significance testing is a filter. The filter acts on the estimate, not the true effect, so it can miss a real effect whose estimate did not clear the bar.

The filter lets an experiment through when noise pushes its estimate above the significance bar, and it excludes an experiment when noise pulls its estimate down. The surviving winners are not a random sample. They are the subset where noise inflated the estimate enough to pass, so any total you sum from that subset inherits the same inflation. That is the winner’s curse.

See the overstatement in an example

A short example shows where the extra impact comes from. Let’s say the true effect of an experiment is 5%. In practice, you don’t see the true effects, only noisy estimates. In this example, the experiment must show at least 6% lift to be statistically significant and ship.

The filter keeps only estimates in the right tail of the distribution. Since the true effect is 5%, any estimate above the 6% cutoff includes positive sampling noise. The estimates that pass therefore overstate the true effect on average. This bias appears before you sum anything. When you add the observed lifts from many statistically significant winners, the total inherits the same inflation. That is the winner’s curse.

Measure cumulative impact directly with a holdout

Effect estimates from statistically significant winners are already biased upward on average. Adding them carries that bias into the total. A holdout measures every shipped treatment together, so you estimate their cumulative effect directly rather than correcting many estimates after the fact.

A holdout avoids the winner’s curse because its estimate is not selected for statistical significance. You estimate one thing, the combined effect of all the winning variants, not aggregating many statistically significant estimates.

How holdout groups are structured

A holdout randomizes users into three groups.

• Holdout: sees the product as it looked when the holdout period began. This group is the control and is not included in on A/B tests during the holdout. Typical size is 1–5% of traffic.
• Winners only: this traffic is also not included in A/B tests and receives winning variants once experiment decisions are made. Typical size is 1–5% of traffic.
• Remainder: the population your A/B tests actually run on. It is usually the largest group (90-98% of traffic), since it has to power the tests that surface the winners rolled out to the winners only group.

Comparing the holdout and winners only groups gives you the cumulative effect of every winning variant.

What a holdout gives you and what it costs

A holdout is the cleanest way to measure the cumulative effect of everything you have shipped. It can also estimate long-term effects. Because the comparison can continue after the winning variants roll out, a holdout can also measure how their cumulative effect changes over time.

A holdout also requires advance planning. You need to configure it before the experiments it will capture begin, so it usually cannot measure the cumulative impact of historical experiments that ran without one.

That rigor comes at a cost in time and traffic. A holdout runs for an extended period, often a quarter or more, so you keep feature flags from completed experiments alive until it ends. Group sizing also forces a tradeoff between statistical power and testing capacity. Larger holdout and winners only groups raise the power of the final analysis but leave a smaller remainder to power your A/B tests. Smaller groups do the reverse and weaken the holdout analysis itself.

Estimate cumulative impact without a holdout using Cumulative Impact

Cumulative Impact takes a list of candidate experiments and fits a statistical model that estimates an effect distribution across them. The model gives each experiment a corrected estimate of its true effect, then aggregates the winning variants into one cumulative number. The correction applies empirical Bayes shrinkage, borrowing strength across experiments to shrink each estimate toward the overall distribution and correct for the winner’s curse.

Skipping the holdout comes at a price. Cumulative Impact relies on three assumptions that a holdout does not need, and each one has a limitation worth knowing.

Exchangeable experiments

Think of each experiment’s true effect as a draw from a jar of possible outcomes. The model assumes every experiment draws from the same jar. Before it sees the results, the model has no reason to expect one experiment to have a larger or smaller effect than another. That is what exchangeable means here. The shared jar lets the model correct the winner’s curse by looking at the distribution as a whole and judging how far to shrink any single measured lift toward a realistic size.

The correction only holds when the experiments belong in the same jar. Pool a minor copy tweak with a major redesign and the correction distorts, so the experiments you group together matter.

Stable effect distribution

The model also assumes the jar does not change across the window you analyze, so every experiment in that window is still drawn from the same jar. The assumption breaks in two ways. If you shift strategy mid-window, say from small, safe tweaks to bigger, riskier redesigns, the earlier and later results are no longer draws from the same jar. And if an experiment ships on a measurement taken before a novelty effect wears off, its inflated lift looks like a draw from the jar even though it reflects a temporary distortion rather than a lasting effect.

A longer window gives the model more data, but it helps only when your strategy stays consistent and each experiment runs long enough for novelty to fade. A holdout avoids the problem, because it compares real user groups over whatever period it runs and captures the true combined effect as it stands, novelty and strategy shifts included.

No interactions among treatments

The model assumes each shipped change acts on its own, so the corrected effects can be added or multiplied together. In practice, two treatments applied to the same users can reduce or amplify each other’s effects. For example, a redesigned checkout page might behave differently once a new pricing experiment ships on top of it. Cumulative Impact cannot detect that. A holdout captures interactions directly, because the winners only group experiences every shipped change stacked together. In practice this assumption usually holds, since interaction effects in A/B testing are rare. Whether that is true for your program depends on your product, your metric, and the experiments you aggregate. Confirm it is reasonable before you rely on the cumulative estimate.

Choose between a holdout and Cumulative Impact

The right method depends on your traffic, your timeline, and whether you need a direct randomized estimate of the combined effect.

Reach for a holdout when:

• You need a direct randomized estimate of the combined effect of all winning variants
• You need to measure the long-term effects of winners
• You have the time, resources, and patience to support a holdout
• You have enough traffic to power the holdout analysis and all your other A/B tests

Reach for Cumulative Impact when:

• You need a cumulative estimate quickly, without waiting out a holdout or keeping old feature flags alive
• You need to estimate the cumulative impact of previous experiments that did not have a holdout
• You don’t have enough traffic for a precise holdout estimate
• Your run comparable experiments, with similar changes, a consistent strategy, and the same metric, so the exchangeability and stable-distribution assumptions hold
• You have at least five qualifying experiments, enough for the model to produce a stable estimate
• You are comfortable trading a direct randomized estimate of the combined effect for a faster, model-based estimate, and interactions and novelty effects are not a major concern for your metric

The two methods are not mutually exclusive. Many teams run Cumulative Impact for a fast, routine read and use a holdout for the highest-stakes, long-horizon questions or to validate the assumptions behind the cumulative estimate.

Key takeaways for measuring cumulative impact

Cumulative impact is not a number you can reach by summing observed lifts. The winner’s curse biases effect estimates from statistically significant winners upward on average, so adding them carries that bias into the total. A holdout measures the combined effect of your winners directly in a single randomized experiment, while Datadog’s Cumulative Impact corrects and aggregates your existing estimates without one. Choose a holdout when you need a direct randomized estimate of the combined effect and you have the traffic and time. Choose Cumulative Impact when you need a fast read and your experiments are comparable enough for the model’s assumptions to hold.

Turn your QA checklist into AI agents that check every site change. Your team approves, then your client.

The human is the loop

I recently stepped away from AI for a few weeks. Coming back, I’m more aware of the unhealthy habits I’d formed using it.

It was an end-of-summer vacation, and I was lucky to be swimming in cold rivers, eating one too many s’mores, napping after lunch, etc. There was a lot of indulgence and a break from work and routines. For much of the time it was a break from my laptop and phone altogether, which meant a few weeks without AI.

I didn’t miss it. What I’ve realized these past few days back is how much of my AI use was unnecessary. In fact, I think it’s often been a habit-forming crutch making me intellectually weaker, less curious, and less confident. It’s probably made me a little depressed too.

When I eventually opened my laptop a few days ago, I was greeted with eleven cmux tabs, each with multiple agents paused midway through various efforts. Some professional, some personal, and a lot in between. I also had unread badges on Claude chats across everything from taxes to landscaping ideas to policy doc review.

Is this the 2026 version of having a bunch of tabs open? Maybe, but it feels way worse. Each of these was an initiative I thought I needed help with, or that I wanted to automate or outsource some thinking on. But each is also a little stub of guilt over never finishing things, over not being efficient or smart or focused enough with my time.

Obviously I’m being hard on myself. That’s not new behavior, and it’s long been a source of pressure based on unrealistic expectations. I’ve managed that stress and self pressure with mixed success in the past. But in this machine intelligence era, the pressure has found new outlets. Instead of forcing me to triage and focus on what matters most in work and life, it feeds an underexamined belief that I should be able to do more now. And it finds release in yet another agent conversation, another terminal pane, another fork no one asked for, another bullshit markdown output I’ll never read.

I have so many half-baked ideas for tools or services I barely need, sparked by a combo of unaddressed workaholism and techno-optimist wishful thinking. And sure, the little things I’ve made do work. They’re running, doing their little things. But none of it helps anyone, and none of it makes me happier or gives me more free time. I used to tinker on personal projects as a way of relaxing and learning for the fun of it. These projects don’t do that. I often skip the learning to get to the result, and the learning is where the joy happens.

I also think I have been using agents as a layer between me and the tasks that cause me stress. Instead of just taking on the thing directly, I put an agent in the mix. It’s like a special stuffy or totem that protects me.

If I needed to write something, I’d dictate all my thoughts, then talk through it with ChatGPT while driving or walking. I’d justify it as bouncing ideas around with myself, as making use of time that would otherwise not be productive. But I knew it was really a sycophantic mirror. And because it was not a realistic thought partner, I never relied on the output of those sessions for real work. So how useful were all those hours really? Now it’s just rambling recordings and transcripts on OpenAI’s servers.

Another example: I’d try to set things up to be more automatic, so I could theoretically get work done faster and parallelize a bunch of different tasks at once. But in hindsight, no one was asking for these efficiency gains. Equipped with tools that could theoretically make me a faster, more capable builder, I felt a strong urge to maximize my use of the tools by applying them to the task of… maximizing my use of the tools. It’s reflexive in the worst way, a productivity ouroboros.

I’m not arguing that this technology necessarily has these effects on its users. And I think the format, design, and culture around the tech are a huge factor in the habits I formed.

My hunch is that agent usage is (thankfully) not intrinsically neurochemically addictive in the same way as, say, endless algo feed scrolling. But I do see now that there are some very real dependency and habituation effects. Once you introduce AI tools into some of your work, it’s quick to see more ways you might start incorporating them. There’s also a large segment of the tech industry now betting on a mass socioeconomic dependency on LLMs. The only way those valuations are ever justified is if we collectively become hopelessly dependent on AI-based tech.

So my plan going forward is simple: be intentional about when to use AI and when to leave it out, and try to be honest about what I’m actually gaining and losing with my choices.

Before switching to writing this post, I did enter a prompt into pi for a work project I’m starting. I gave it a bunch of requirements and suggestions, and told it to look at codebases, wikis, schemas, conversations. Setting it up forced me to catch up and think through the current situation. I asked it to come back with flagged issues and possible solutions. I constrained it narrowly and gave it as much context as I could, including what I was already thinking and what I wasn’t sure about. And I provided very clear expectations of output.

The AI isn’t going to hand me the perfect solution. The result is not going to 10x me. But it’s pattern matching and searching across a mess of systems and SaaS products, which I’m not great at and don’t enjoy. It might reveal a few gaps in my understanding of the situation and improve the context I bring into the project.

More important: it’s freeing me up to do human stuff like write and reflect right now. I’m still cautiously optimistic about this tech possibly letting people lead richer, more thoughtful lives. But that’s only possible if we use it on our terms. We don’t want the human trapped in the agent loop. The human is the loop, and we tag the agent in occasionally, thoughtfully.

Junior engineers still add capacity to an organization. The work of an engineer is to solve a customer problem with software while managing the technical complexity that exists in deciding how to. Staff engineers manage a lot of complexity, and junior engineers manage a little complexity, but the role is the same. Technical decision-making is still important, and junior engineers add to it, enabling organizations to do more.

Apple's resources are increasingly moving toward AI-powered smart glasses.

FSD v15 will be the third version in a row pitched as the one that finally gets there.

A multinational financial services organization migrated from an outdated, stressed single Octopus Server to a five-node High Availability cluster through careful planning, staged testing, backups, and rollback checkpoints. The migration established a stable foundation and led to a regular six-month upgrade cadence with minimal support needs.

According to recent rumors, the iPhone 18 Pro will refine Apple's current design with a more seamless rear appearance that eliminates the divisive two-tone glass-and-aluminum look, a Dynamic Island that's roughly 35% smaller thanks to under-display Face ID components, and a new range of colors headlined by a bold Dark Cherry finish that continues Apple's move toward more expressive Pro models.

Buttons are rarely ignored because they're hard to see - they're ignored because users lack a reason to act, don't trust the outcome, feel mentally overloaded, or aren't ready for the commitment being asked of them. The decision to click is shaped by everything that comes before the button, including the user's goals, emotional state, level of confidence, and the narrative flow of the experience. Effective button design is therefore less about visual styling and more about creating the right context, motivation, and clarity for action to feel like the natural next step.

Instagram's subtle logo refresh has sparked debate among designers, with critics pointing to legibility and accessibility concerns around the new “r” while supporters argue the wordmark makes sense within a broader identity system that includes new typography, motion, and visual language. Ultimately, the discussion highlights the tension between brand personality, readability, and how logos should be evaluated as part of a larger brand ecosystem rather than in isolation.

macOS 27's redesigned battery icon places the percentage inside the battery graphic, making it harder to read and prompting some users to seek alternative menu bar solutions.

Designers in 2026 are turning to cork across furniture, architecture, footwear, and product design for its renewability, durability, and low environmental impact.