Introducing Kimi K3.1 Pro

We're introducing Kimi K3.1 Pro, the first model in our new K3.1 series and our most capable 3T-class open-weight model to date, with a 1-million-token context window. It delivers substantial improvements across coding, 3D creation, financial research, and other agentic capabilities.

We are also releasing Kimi K3.1 Pro Highspeed, which delivers 2-3× the speed of K3.1 Pro for more responsive interactions.

Kimi K3.1 Pro and Kimi K3.1 Pro Highspeed are available today on Kimi.ai, Kimi Work, Kimi Code, and the Kimi API. The full model weights will be released by Nov 4.

Advancing the Frontier of Open Intelligence

Kimi K3.1 Pro is a post-trained version of Kimi K3, with substantially larger post-training compute. To enable large-scale joint RL across hundreds of downstream domains, we optimized every layer of the stack — the RL framework, long-context inference, training efficiency, sandbox infrastructure, rollout scheduling, and a shared platform for environment quality checks — so that each increment of RL compute delivers stable, predictable returns. As a result, K3.1 Pro achieves consistent gains in every domain.

Across coding, agentic, and knowledge benchmarks, K3.1 Pro matches or approaches the strongest proprietary models. On Terminal-Bench 4.0, which evaluates coding agents on realistic, resource-constrained terminal tasks using strict task-specific tests, K3.1 Pro scores 65.7%, ahead of GPT-6 Astra (58.2%) and narrowly behind Claude Opus 5.5 (66.4%). And on Kimi Code Bench 3.0 Long-horizon, our internal benchmark that tests coding agents' multi-step execution, tool use, and end-to-end problem solving across diverse engineering domains, K3.1 Pro scores 61.2%, above K3's 55.95%.

Coding

K3.1 Pro covers the full range of coding work, from quick fixes in real codebases to full-project builds. It also brings a more considered visual style to games and web experiences, and knows how to build them with the right tools.

K3.1 Pro works effectively across game engines such as Unity, Unreal Engine, and Godot, combining them with web search and 3D generation to create complete experiences. Its front-end pages, interactive Three.js scenes, and 3D assets show stronger composition, typography, animation, and polish.

K3.1 Pro's long-horizon coding capabilities are also strengthened through large-scale reinforcement learning. In one internal test, it built a human walking dynamics simulator with integrated training and evaluation pipelines on top of human-atlas, an open-source anatomical model of the human body comprising 296 skeletal components, including cartilage, and 402 muscle components. Across 167 missions and 420 independent reviews, it analyzed experimental results, diagnosed problems, and iteratively refined the walking controller, enabling the simulated human to go from collapsing within seconds to walking continuously with alternating strides for 11.2 seconds. When reward shaping failed to improve arm motion, K3.1 Pro did not simply keep adjusting the reward: it ran open-loop probes of the simulator's dynamics, identified and corrected 36 errors in shoulder-muscle moment-arm calculations, and then retrained the controller.

3D Modeling and Design

K3.1 Pro is strong at 3D creation and spatial reasoning. On BenchCAD, which tests 3D reconstruction from multi-view renderings through CAD code generation, K3.1 Pro scores 92.7% with tools, approaching the performance of Claude Opus 5.5 (96.2%) and GPT-6 Astra (95.9%). From a text brief, sketch, or reference image, it can infer shape, proportions, and spatial relationships to create usable 3D models. It also has a stronger grasp of existing asset libraries and model collections.

K3.1 Pro particularly excels at parametric modeling, from mechanical parts and architectural models to configurable products and custom furniture. Without MCP connectors, it can write and run scripts for tools like Blender and CAD software to build and refine assets, edit components, and adjust geometry, materials, and scene layout.

Finance

With stronger reasoning and agentic capability, K3.1 Pro is capable of end-to-end delivery of complete financial workflows. K3.1 Pro achieves state-of-the-art results on OfficeQA Pro v2 (64.4), which tests complex fiscal data analysis over real financial documents through retrieval, cross-document verification, and multi-step numerical reasoning. K3.1 Pro also improves over K3 on Frontier Finance, which measures support for complete investment workflows from screening to profitability analysis.

K3.1 Pro also improves significantly across all our internal finance benchmarks:

• Financial Modeling evaluates formula linkage, financial logic, and final workbook quality in real-world modeling tasks. K3.1 Pro improves on K3 by 7.2 points.
• Financial Research evaluates whether models can produce auditable research under evidence and cutoff constraints. K3.1 Pro improves on K3 by 11.6 points.
• Business Operation evaluates long-horizon management and decision-making in a simulated business environment. K3.1 Pro achieves about 4.2× K3's performance.

Financial analysis and investment research demand a high degree of factual accuracy. To address this, we made targeted improvements to K3.1 Pro's factual accuracy on real-world tasks and challenging prompts. On Kimi Hallu Bench Hard bench, an internal benchmark designed to stress-test factual accuracy, its claim-level hallucination rate fell from 23.4% for K3 to 8.3%, while the share of responses containing at least one factual error was just 42.4% of its predecessor's rate.

Cybersecurity

As K3.1 Pro became more capable, we spent a correspondingly larger share of our effort understanding where cyber capability comes from, and how much of it we can control. We therefore analyzed and evaluated K3.1 Pro's vulnerability research capabilities, and applied targeted controls during training to reduce potential misuse risk while preserving general usefulness.

Identifying and removing cyber-related data. During development, we observed vulnerability research performance improving steadily as post-training scaled. Tracing the source of this trend, we found that cyber-related content was embedded within the general mid-training corpus, and cyber-related tasks were present in the RL environment mix — a natural byproduct of training on broad data. In preliminary experiments on internal models, we found that without data removal at either the mid-training or the RL stage, downstream cyber capability would increase substantially. For the open-weight release of K3.1 Pro, we identified and removed cyber-related data from both training stages, while retaining the general-purpose coding tasks needed for model usefulness.

Evaluation and results. After data cleaning, we evaluated K3.1 Pro on xdev-bench-hard, our in-house benchmark of expert-curated, source-code-based vulnerability discovery and exploitation tasks. On xdev-bench-hard, the checkpoint without these risk-reduction measures solves 90.5% of problems at pass@3; the final K3.1 Pro reaches 81.0%. The comparison shows that data removal meaningfully reduces cyber capability relative to what the same training pipeline would otherwise produce. At the same time, K3.1 Pro improves substantially over its predecessor, indicating that stronger general coding and long-horizon debugging capabilities generalize to cyber tasks even after targeted data removal.

Open-weight principles. First, we aim not to release open weights that would extend the absolute frontier of cyber capability. K3.1 Pro's offensive cyber capability is, by design, below what our pipeline can produce, and remains behind that of frontier proprietary models. Second, we intend to progressively raise the cyber capability available in open weights. We believe making K3.1 Pro available in a non-discriminatory way benefits people who need dual-use capabilities for defensive purposes.

Availability

Kimi K3.1 Pro rolls out today across the Kimi product family.

Full model weights will be released by Nov 4, 2026.

• Kimi Agents: Download or update to the latest Kimi app from your mobile app store, or visit Kimi.ai.
• Work with Kimi K3.1 Pro: Download the latest Kimi Work desktop app, version 3.1.0 or later, available for Windows and Apple silicon Macs.
• Code with Kimi K3.1 Pro: Run Kimi Code and select Kimi K3.1 Pro using the /model command.
• Build with the Kimi API: Visit the Kimi API Platform and select kimi-k3.1-pro / kimi-k3.1-pro-highspeed.
• Bring Kimi to your organization: Kimi Business provides enterprise-grade data privacy and member management.

Full article content is not available for inline reading.

Read the original article →

US military gives Elon Musk’s SpaceX access to sensitive tracking data

This gives the company an advantage in tracking objects in orbit, raising national security concerns and fears of greater control over the space industry

The US military has given Elon Musk’s SpaceX access to restricted space tracking data, raising a new round of questions about whether the Trump administration is attempting to hand over traffic control in Earth’s orbit to a controversial donor.

The access also raises new national security questions, industry observers say.

The move comes after Musk’s Doge in 2025 fired many of the federal government’s nascent space traffic control program’s staff, and the administration has twice attempted to financially gut the department, called the Traffic Coordination System for Space (Traccs).

The moves were widely viewed in the industry as an attempt by Musk to privatize space traffic control. The defense department has now granted SpaceX access to its most precise data on potential collisions among satellites and other space objects, which will give Musk’s companies an advantage over competition that offers a similar service.

SpaceX and the Space Force signed the new contract. The commercial US space market is expected to grow to a value of nearly $2tn in value over the next decade, and the unprecedented access to military data appears to be another step toward Musk asserting monopoly control over commercial space activity more broadly, said Cole Donovan, a former Traccs employee now with the Stand Up for Science non-profit.

“It’s making a company the de facto source for space traffic coordination within the US,” Donovan added. “It’s like giving a trucking company control of all the traffic lights, which they can switch to red whenever it’s their competition’s turn to go.”

Traccs manages thousands of satellites, debris and spacecraft, and helps prevent up to 50,000 near-collisions, called conjunctions, daily.

SpaceX and Space Force did not respond to requests for comment from the Guardian, but in a statement to Breaking Defense acknowledged the move.

“The Space Force is engaging with several companies to exchange commercial data sources for access to sections of the controlled, unclassified information, high accuracy catalogue, where it provides benefit to the US government,” a spokesperson told the outlet.

SpaceX has been expanding its power over launch and other space services, while growing closer links with the US government. Multiple industry observers have said since the Trump administration took over that they fear a “vendor lock” scenario in which the government is overly reliant on SpaceX because it has such immense influence and is so technologically advanced.

The first Trump administration established Traccs to take over commercial space traffic control from the defense department. But Traccs has never been fully funded or staffed, and has struggled to take root. The latest move by the military comes at a crossroads for Traccs as the administration, Congress, and industry debate what to do next.

The administration in fiscal year 2026 tried to largely defund the $65m program during the budgetary process, but Congress re-inserted the funding. The administration has again proposed slashing the budget to nearly zero in fiscal year 2027, but the House again reinserted the funding.

Several employees of commercial space companies have told the Guardian since early 2025 that there is wide support in the industry for Traccs because it would level the playing field. But the administration’s apparent move to privatize and consolidate power with a Trump ally is consistent with its broader approach to governance, Donovan said.

However, a former National Oceanic and Atmospheric Administration (Noaa) official who spoke on the condition of anonymity said SpaceX has largely been “remarkably responsive to space safety concerns” and they do not fault Starlink for stepping into a space that the government has failed to adequately address.

“My greater disappointment is with the government’s failure to fulfil its responsibility to establish a coherent space governance framework that provides guidance, transparency, and a level playing field for all operators,” the official said.

Musk’s growing lower Earth orbit empire includes a massive satellite constellation belonging to Starlink, a broadband internet company that is a subsidiary of SpaceX. It operates about 11,000 satellites in orbit, and could have as many as 20,000 in the coming years.

For the first time, the Space Force has given a commercial company “enhanced” access to the US Space Command’s most detailed, secure version of its High Accuracy Catalog (Hac) of on-orbit objects.

This includes Vector Covariance Messages (VCMs) made up of tracking data collected from military sensors, telescopes and radars on the ground that track the paths of satellites and other space objects in lower orbit that are down to about 10cm (3.93in) in size. The military largely uses the radars and data for monitoring other countries’ satellite positions, but it is also utilized to track commercial spacecraft and objects to avoid collisions.

The latter is part of the responsibility that the military no longer wants, and was supposed to hand off to Traccs, Donovan said. Instead, SpaceX has been given access to the data.

The VCM data is valuable to Starlink because the company uses its own “Stargaze” system to track other satellites and space objects. Stargaze is made up of thousands of cameras and radars mounted on Starlink satellites. It can only see objects that are down to about a half meter in size, and is not as accurate as the military’s system.

The military “radar data is an extremely valuable tool to supplement Stargaze,” Breaking Defense quoted a SpaceX employee stating during an industry conference.

The government is receiving something in return for the data – access to Stargaze cameras and sensors. “The more observations and data that [the military] has, the better,” Donovan said.

However, the VCM data is designated as “controlled unclassified information” and has been closely held by the military because it could expose the limits of defense capabilities. The defense department has also wanted to prevent the reverse engineering of satellite sensors it uses to monitor other nations’ defense satellites, observers say.

In terms of ethical conflicts, the access is another example of the Trump administration rewarding a donor with business opportunities with the federal government, said Craig Holman, Capitol Hill lobbyist for Public Citizen, a government accountability non-profit.

“Elon Musk has bought his way into the favor of President Trump and with it, unlimited riches and lucrative government contracts in the space industry,” Holman added. “[His] political investment is paying off very, very handsomely – as was intended.”

Full article content is not available for inline reading.

Read the original article →

A critical vulnerability, tracked as CVE-2026-111497 and referred to as Broccoli2Shell, has been identified in the Brotli decompression library. The vulnerability affects multiple widely used technologies, including Node.js, Bun, Envoy Proxy, and more. Successful exploitation could allow an unauthenticated remote attacker to trigger memory corruption, disclose sensitive information, crash affected processes, or potentially achieve remote code execution (RCE).

Organizations using affected components to decompress untrusted Brotli-compressed data are advised to prioritize remediation.

CVE-2026-111497 was discovered and reported by Khai Tran and Sylvie Mayer (OpenAI Codex Security), with fixes implemented by Matteo Collina and Antoine du Hamel (Node.js). Ron Masas (Imperva Red Team) demonstrated its exploitability, while OpenSourceMalware and Aikido analyzed its impact on the Python ecosystem.

What is CVE-2026-111497?

Broccoli2Shell (a.k.a Node2Shell and HTTP2Shell) originates from an out-of-bounds write vulnerability in the Brotli decoder, a widely adopted compression component used to reduce the size of HTTP traffic and other data. The flaw occurs when the decoder improperly handles specially crafted compressed data during block-processing operations, potentially writing beyond allocated memory boundaries. An attacker can exploit this behavior by supplying malicious Brotli-compressed input to a vulnerable application, potentially resulting in memory disclosure, application crashes, or arbitrary code execution with the privileges of the affected process. Researchers have demonstrated successful exploitation against unpatched Node.js environments.

Although initially associated with Node.js, the vulnerability originates in the upstream Brotli C decoder and extends to multiple downstream technologies that incorporate the affected component. Exploitation requires an application or dependency to decompress attacker-controlled Brotli data, either through incoming HTTP requests, externally fetched responses, or other untrusted compressed content. Certain HTTP clients and application frameworks may perform decompression automatically when Brotli support is enabled, potentially exposing applications even when Brotli is not explicitly referenced in application code.

Wiz Research data: what’s the risk to cloud environments?

Cloud environments are particularly exposed due to the widespread use of Brotli-enabled components across containerized applications, Kubernetes clusters, API gateways, reverse proxies, serverless workloads, and cloud-hosted web services. Internet-facing applications that process attacker-controlled requests, as well as internal services that retrieve compressed responses from untrusted external sources, may provide exploitation paths. Successful exploitation could enable attackers to compromise application workloads, access sensitive information, disrupt service availability, or execute malicious code within affected containers or runtime environments.

According to Wiz data 91% of cloud environments have resources vulnerable to CVE-2026-111497, and 82% of cloud environments have publicly exposed Node.js instances.

Which products are affected?

Additional products that bundle or link against vulnerable versions of the Brotli C decoder may also be affected. Organizations should consult vendor-specific security advisories, particularly for statically linked libraries and embedded dependencies. End-of-life runtime branches should be migrated to supported versions.

Which actions should security teams take?

Organizations should prioritize the following mitigation and remediation measures:

1. Apply security updates: Upgrade affected Brotli libraries, Node.js runtimes, Python packages, Bun, Envoy Proxy, and Istio deployments to their respective patched versions or later supported releases.
2. Identify vulnerable cloud workloads: Inventory virtual machines, Kubernetes clusters, containers, serverless functions, API gateways, and application dependencies for vulnerable Brotli components. Prioritize internet-facing services and workloads processing untrusted compressed data.
3. Review application exposure: Identify applications that decompress Brotli-compressed HTTP requests, external HTTP responses, uploaded files, or other attacker-controlled content. Include indirect and transitive dependencies in the assessment.
4. Rebuild and redeploy affected workloads: Update container base images, dependency lockfiles, and bundled libraries. Rebuild and redeploy affected container images, restart running processes, and verify that patched components are loaded.
5. Implement temporary mitigations: Where immediate patching is not possible, consider disabling Brotli decompression or rejecting Brotli-encoded requests before they reach vulnerable components. Restrict untrusted compressed responses where feasible. These controls may reduce exposure but do not replace patching.
6. Strengthen monitoring and detection: Review WAF, application, and network logs for suspicious Brotli-compressed traffic, unexpected application crashes, and anomalous process behavior. Monitor affected workloads for indicators of exploitation.

Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment.

References

• Node.js advisory
• Vercel advisory
• Imperva writeup
• Patch the Planet advisory
• Broccoli2Shell website
• Istio advisory
• Envoy Proxy advisory
• Brotli advisory
• oss-security post
• Bun advisory
• Aikido blogpost
• OpenSourceMalware blogpost

Detecting and mitigating ZDI-CAN-33367 and five other Linux flaws

A working root exploit for a Linux kernel bug is now public, before it has a CVE or a merged fix. On October 20, 2026, Trend Micro’s Zero Day Initiative (ZDI) sent one report, a bug in the ConnMan network manager, to the public ConnMan mailing list. On October 21, ZDI sent five reports to the Linux kernel security team and copied public mailing lists on every one. The reports included reproduction details, showing that several had no patch attached and no fix in any released kernel. Two of the Linux flaws have been rated as CVSS 9.0.

None of the six bugs has been assigned a CVE ID yet, and no in-the-wild exploitation has been reported as of the publication of this blog. However, security teams should work to get detections and mitigations in place now. TuxCare has reproduced the public proof of concept (PoC) for ZDI-CAN-33367 from the ZDI report. Exploitation leads to root access on current Ubuntu, Debian, and AlmaLinux distributions.

The Sysdig Threat Research Team (TRT) reviewed the batch of Linux vulnerabilities and ranked the reports by how much each should affect what defenders do today. This report explores what was disclosed, who may be exposed, what runtime visibility can detect for each bug, and what defenders can do while patches are pending.

Timeline

Affected versions

Exposure risk varies greatly across the reports. One affects the mainstream distributions TuxCare tested, including Ubuntu, Debian, and AlmaLinux releases. Two affect only hosts running ksmbd, the in-kernel SMB server. Another affects only VMware guests.

Organizations should review their inventory before deciding how to prioritize these vulnerabilities.

ZDI-CAN-33367

Fix status

A small patch, “net: skbuff: propagate shared-frag marker in skb_zerocopy()”, is on netdev, reviewed by Eric Dumazet and tagged for stable. It has not been merged.

How the bug works: Dirty Frag again

Earlier this year, Dirty Frag (CVE-2026-43284) showed defenders how an unprivileged user could get the kernel's IPsec ESP code to decrypt in place over pages that belong to the page cache. Those pages back a file the user can only read, and decryption writes the attacker's bytes into the cached copy of that file. Targeting a setuid binary or /etc/passwd this way gives the attacker root without ever opening the file for writing.

The Dirty Frag fix marked those shared pages with a flag and taught ESP to copy before decrypting when it sees the flag. ZDI-CAN-33367 is a gap in that fix.

skb_zerocopy() moves the same pages into a new socket buffer but does not carry the flag across. ESP never sees the flag, decrypts in place, and the write lands in the page cache. According to TuxCare and Safeguard, the code path dates to kernel 3.14.

Not the first gap

The Dirty Frag fix only works if every piece of networking code that moves those pages around carries the flag along. Since May, the kernel's CVE team has published six follow-up CVEs where some other path lost it:

• Frag-copy and shift helpers: CVE-2026-43503
• Coalescing: CVE-2026-46300
• IPTFS: CVE-2026-53363, CVE-2026-64566
• An error-handling helper: CVE-2026-80977
• Another error path inside skb_zerocopy() itself: CVE-2026-90049

CVE-2026-90049 is a different bug in the same function, so a kernel carrying its fix is not fixed for ZDI-CAN-33367.

Exploitation

The PoC needs unprivileged user namespaces and a handful of networking modules: nlmon, nft_queue, nfnetlink_queue, cls_u32, act_pedit, act_mirred, and esp4. It does not need a Kernel Address Space Layout Randomization (KASLR) leak, or any capability the user doesn't already get inside their own namespace.

Each step of exploitation is a system call that can be made by an ordinary user process:

• Unshare into new user and network namespaces, then write sysctls.
• Bring up an nlmon interface.
• Install XFRM state over netlink.
• Add an nftables NFQUEUE rule.
• Attach a tc pedit action with a redirect.
• splice() into a socket on 127.0.0.1, which triggers the in-place decryption over the page cache.

Impact

TuxCare reproduced a root shell on AlmaLinux 8–10, CloudLinux 9–10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. AlmaLinux was rooted with the Dirty Frag fix installed. CentOS 6 and 7 kernels are not vulnerable. The vulnerability is a local privilege escalation (LPE), so an attacker needs code execution on the host first.

ZDI-CAN-33774 and ZDI-CAN-33549

Both CVSS 9.0 reports are in ksmbd, the in-kernel Server Message Block (SMB) server. Samba is not ksmbd.

If your file servers run smbd, neither report applies to you. To check whether ksmbd is running anywhere, look for the ksmbd kernel module, the ksmbd.mountd userspace daemon, and a kernel-owned listener on TCP 445.

ZDI-CAN-33774: The dispatch race

ksmbd decides per request whether it is handling SMB1 or SMB2. If an attacker packs a burst of short SMB1 packets and an SMB2 packet into the same TCP write, the worker threads can run an SMB2 handler over SMB1 data and read past the end of the shorter buffer. This works before authentication. The public PoC leaks 28 bytes of kernel heap per attempt and can crash the kernel. ZDI describes a write-past-buffer path that needs share access and labels the bug as remote code execution (RCE), but nothing public shows code execution as of this blog’s publication.

Maintainer Namjae Jeon says the bug is already fixed, and his tree bears that out. Commit 68f410faedaf ("ksmbd: wait for negotiation before receiving another PDU") was written on September 30, credited to a different reporter, and describes exactly this race. It is queued in ksmbd's ksmbd-for-next branch and has not reached a released kernel.

ZDI-CAN-33549: SMB Direct

An integer underflow in the Remote Direct Memory Access (RDMA) transport turns a crafted buffer descriptor into a heap overflow of up to eight KB. The bar is higher than for 33774. The host needs an RDMA-capable interface (hardware, or the rxe software driver), a client that negotiates SMB Direct, and a writable share. The public PoC crashes the kernel.

SMB Direct maintainer Stefan Metzmacher believes a fix already in his branch for Linux 7.5 covers it. As of this writing, that hasn't been confirmed. Ubuntu builds SMB Direct support; Debian does not.

ZDI-CAN-34068

ZDI-CAN-34068 is an out-of-bounds write in vmwgfx, the kernel driver for VMware's virtual GPU, rated as LPE (CVSS 8.8). Only the title is public. Kroah-Hartman's reply on dri-devel points to the dirty-tracking code. There is no patch.

The exposure is narrow. vmwgfx only binds to VMware's SVGA virtual display adapter, so the bug only matters on VMware guests: vSphere and Workstation VMs, and VMware-based virtual desktop infrastructure (VDI). In Sysdig TRT testing, it does not reproduce on Lima or EC2 instances, which don't present that device.

ZDI-CAN-34076 and ZDI-CAN-32005

ZDI-CAN-34076 (nvmet) is an uninitialized-memory information leak in the Non-Volatile Memory Express (NVMe) target's Get Log Page handling. Only the title is public, and the kernel team has said nothing can be done until details arrive.

ZDI-CAN-32005 (ConnMan) is a stack overflow in the ConnMan network manager's DNS proxy. It is a userspace bug, not a kernel bug, and is outside the scope of this post.

Detection

The four bugs that are the most impactful right now differ in what a syscall-level runtime sensor can observe:

• ZDI-CAN-33367. The sequence of the exploitation is distinctive. The process unshares into new user and network namespaces, writes sysctls, brings up an nlmon interface, installs XFRM state over netlink, adds an nftables NFQUEUE rule, attaches a tc pedit action with a redirect, and then splice()s into a socket on 127.0.0.1. Nothing legitimate does all of that from a single unprivileged process. Of the four, this is the easiest one to detect.
• ksmbd (33774 and 33549). A sensor can see that ksmbd is exposed: the module loads, ksmbd.mountd starts, and 445 is listening. It can see what an attacker does after code execution, once something spawns a process or touches files. It cannot see the race or the overflow itself. Runtime detection is the backstop.
• ZDI-CAN-34068. The trigger is DRM ioctl() calls on the vmwgfx device node, made by a local process. That narrows where to look, but GPU ioctls are noisy on any desktop or VDI guest, so treat them as context for an investigation, not as a signal on their own.

Recommendations

ZDI-CAN-33367

• Patch as soon as your distribution ships the skb_zerocopy() fix. A kernel carrying only the CVE-2026-90049 fix is not covered.
• Restrict unprivileged user namespaces. Setting user.max_user_namespaces=0 (or kernel.unprivileged_userns_clone=0 on Debian) should block the public PoC, though TuxCare notes it has not yet validated this against the PoC. The cost is real: rootless containers, some browser sandboxes and some build tooling depend on user namespaces, so scope it to hosts that don't need them.
• Avoid relying on Ubuntu's AppArmor user-namespace restriction. The PoC got past it through the AppArmor profile of a container launcher package.
• Block the nlmon and act_pedit modules where you can. Denying them breaks this PoC, although TuxCare cautions it may not close every path to the bug.
• Enforce seccomp RuntimeDefault on Kubernetes pods. The exploit starts by creating a user namespace, so containers that can call unshare(CLONE_NEWUSER) are in play. Docker's default seccomp profile blocks that call, but Kubernetes pods run Unconfined unless you set RuntimeDefault per pod or cluster-wide using the kubelet --seccomp-default option. This is a good week to make it the cluster default.

ZDI-CAN-33774 and ZDI-CAN-33549

• Inventory where ksmbd runs. Samba users are unaffected.
• Unload ksmbd and block the module on hosts that don't need it.
• Restrict TCP 445 to trusted networks where ksmbd must stay.
• Disable SMB Direct unless your storage network depends on RDMA.

ZDI-CAN-34068

• Inventory Linux guests running on VMware, and watch for the vmwgfx patch.
• Disable 3D acceleration, or keep the vmwgfx module from loading, on guests that have no use for it.

Across all Linux flaws

• Track the reports by ZDI ID and component name until CVEs are assigned.

Conclusion

ZDI's decision to copy public lists put reproduction details for six bugs in front of attackers before several of them had fixes. As defenders know, a lack of an assigned CVE ID does not mean a lack of exposure. Only one of the six, ZDI-CAN-33367, combines a public root exploit, broad distribution exposure, and a fix that hasn't yet merged. It is the seventh path found to drop the Dirty Frag flag, reopening a bug class whose protection has already leaked six times since May 2026. The two ksmbd reports carry the highest scores, but they only matter where ksmbd — not Samba — is running.

For defenders, the practical takeaway is that this week's work is about exposure, not scanners. It’s also important to note that the bugs differ in what defenders should actually watch. The ZDI-CAN-33367 exploit runs as an ordinary user process through a distinctive sequence of systems calls, so teams can catch it in motion. The ksmbd bugs run inside the kernel worker threads with no attacker process on the host, so controlling exposure is key.

Affected organizations should immediately restrict unprivileged user namespaces and enforce RuntimeDefault seccomp where they can, find out whether ksmbd is running anywhere in their estate, and patch ZDI-CAN-33367 the day their distribution ships the fix.

Full article content is not available for inline reading.

Read the original article →

Railway identified a security incident that ultimately led to unauthorized access to a subset of internal Railway systems. This is a follow up to the initial security disclosure published on October 21st. Our forensic investigation is still ongoing.

Railway engaged external incident response experts and the authorities to assist in forensics.

We will have a follow up to this document as the investigation concludes.

What happened

At October 20th 19:53 UTC, Railway became aware of a sustained and targeted campaign to attack and breach our services. Early investigations tell us this attack was attempting to obtain AI provider API keys to perform distillation attacks.

Initial evidence leads us to believe that the malicious actor had access to abliterated models and substantial compute resources which enabled them to perform highly sophisticated exploits against our infrastructure.

Due to the ongoing investigation and to protect our customers, we are not yet able to share the specific details and scale of the exploits. We will aim to disclose this responsibly as we complete our investigation.

We believe the attack timeline took place from October 20th 13:58 UTC to October 22nd 03:32 UTC. The final timestamp represents when we confirmed that the attacker no longer had access to any internal systems.

Railway began triaging the attack immediately upon detection. To prioritize the safety of our users, we disabled our build infrastructure. Additionally, we reported potentially impacted secrets to partner vendors.

During that period of triage, customers experienced interrupted builds and deployments, as well as periods of dashboard, API, CLI, and support unavailability.

After the attacker gained access to our systems, a subset of our customer base had their encrypted secrets exposed which required credential rotation. We recommend that all customers who signed up prior to October 21 rotate their keys stored on Railway. We have notified the customers that have been directly impacted.

Below is a timeline of events and facts as of October 22nd:

Scale of impact

Railway’s system is built so that if one set of keys is compromised, they should not compromise the entire system. As a result, we can validate that at most 1.85% of all workspaces had some environment variables potentially compromised. This represents, numerically, about 100,000 workspaces. Out of an abundance of caution, the moment we realized any keys may have been decrypted, we notified external providers up to "all of the keys we stored, for all users on Railway". As such, the amount of users who were affected by upstream provider reset requests was larger than 100k.

Railway is reaching out to the customers with definite impact. We are also proactively reaching out to customers who we consider high risk. Because we were unable to know which variables specifically were decrypted, we are reaching out to all users who, based on preliminary forensics of the attack pattern, we believe to be of high risk for targeting from the attacker. This number is greater than the 1.85% of workspaces.

Because the attacker was seeking AI credentials, forensics of the attacker’s behavior tell us that the attacker was looking for high value targets on the platform. We believe there are two buckets of risk:

• Workspaces with a very large number of environment variables
• Environments with a high amount of AI keys from vendors

The attacker did not access Railway user accounts as part of this incident. While we are not ruling out that they accessed user source code, we will confirm at the the time of our final forensic investigation report.

Railway proactively worked with GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe, and others to revoke the potentially compromised keys as soon as we knew they were accessed on October 21st at 09:25 UTC.

Out of an abundance of caution, we provided vendors such as GitHub and SpaceXSI with all API keys that were present on the platform, regardless of whether those were known to be impacted. Users being notified by vendors about revocation does not imply that their credentials were impacted by the incident.

While new builds and deployments were paused for all customers, all existing user deployments remained online and running. At time of writing, builds for all tiers are restored.

User remediations

As indicated in the security disclosure published on October 21st, we recommend all users revoke and reapply sensitive environment variables stored on Railway prior to this date. We are recommending this out of an abundance of caution.

We’ve also published a set of guides to check for anomalous activity and credential rotation on various tools.

While Railway knows what the intent of access was, it’s advisable for all customers to:

• Remove public network access to databases
• Rotate any sensitive variables and keys
• Check your GitHub account audit logs and review all app access
• Check audit logs within your registries such as Dockerhub

If you have any questions, please email support@railway.com.

Railway actions taken

With the increased level of pressure that vendors are facing due to new found cyber threats, Railway intends to meet the scale and moment of this new era to keep our customers safe.

We continue to refine our platform and corporate security posture, taking all reasonable steps to mitigate attack vectors. Below is a list of what we have already done:

• We shut down any potentially compromised internal tooling upon seeing suspicious activity.
• We rolled all keys, and then rerolled them after validating that the intruder had been expropriated from the system.
• We have engaged an external forensics company to further our understanding of the malicious actor.
• We have rolled out a new generation of builder infrastructure, moving from our previous third generation isolated multi-tenant to our fourth generation single-tenant environments. Rollout was planned for next week, but was accelerated and completed due to this event.
• We have rolled credentials for all storage buckets deployed on Railway.
• We have rebuilt, from validated source, all tooling used to run Railway infrastructure, and validated that the same escalation patterns are not possible.
• We have added functionality to mass revoke Railway application permissions whenever we suspect any suspicious activity.

We performed other mitigations that we are choosing to not disclose at this time out of an abundance of caution in protecting the safety of our customers.

Railway owns every layer from bare metal to the agent workflow for one reason: so builders on Railway can build their most ambitious products. This vision can only be achieved with an equivalent security posture matching that ambition. We will continue to operate in the same way we built our platform: carefully, in the open, and for the long run.

FAQ

Did customer applications go down? No - running services stayed online throughout the incident. New builds and deployments were paused during triage to mitigate possible attack vectors. The first system we brought online was the ability to disable existing deployments.

Was my Railway account accessed? No - individual accounts were not logged into. The attacker accessed Railway's internal systems and decrypted stored environment variables for a subset of workspaces. We did however revoke all Railway access tokens out of an abundance of caution.

Why did I get an email my keys got revoked by GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google, or Stripe? Railway sent a list of potentially decrypted keys to providers as soon as we were aware of the incident on October 21st 09:35 UTC prior to our public disclosure, with a request to revoke them, to limit the potential impact for users. Some vendors requested all keys to be revoked.

Why did Railway not notify customers of potentially decrypted keys sooner? At the time of discovery, the attack and incident mitigation was underway in-parallel. As mentioned, the moment any credentials were affected, we notified upstream providers. As the incident was on-going, we wanted to ensure the attacker was ejected from our running infrastructure before telling users to roll their credentials, to prevent the credentials from becoming immediately compromised again.

Is Railway safe to use now? Yes. The Railway engineering team has redeployed and revalidated all impacted systems. At the time of writing, any functionality that remains offline will return in the coming days.

Why was I unable to deploy new changes? To limit the scope of the attack, we intentionally stopped new builds to remediate and penetration test the impacted components of Railway infrastructure, while keeping user workloads running.

What did the attacker want? Forensic investigation evidence indicates the attacker was likely looking for AI and platform API keys, for distilling model weights.

I re-logged in and didn’t see anything, why? We rolled all GitHub App installations for Railway. If your GitHub account email is different than your Railway email, you may need to re-login using "Log in using email"

Continuous Updates

Monday, October 26

The security incident is resolved for existing users. We value transparency, and thus will continue to provide updates until all surface areas of Railway are fully operational.

Why is Railway still not accepting new signups? Railway’s services are fully restored for our 5 million existing users. To securely and reliably support market demand, we have paused new signups as we prioritize uptime during this recovery period. We will reopen signups this week to continue supporting the ambition of product builders worldwide.

How can I get a refund for fraudulent AI spend on other platforms? Railway is unable to refund customers for spend performed with compromised API keys. However, we encourage you to reach out to AI token providers directly. Afterwards, please submit a support request at station.railway.com with timestamps, prompts, and addition proof of fraudulent spend so we can escalate the request on your behalf. More information to follow.

What is Railway doing to improve security moving forward? This week, we have already or are actively implementing a new generation of builder, encryption, and logging systems. Railway has been acknowledged as critical cyber infrastructure, allowing us to utilize to previously inaccessible tooling to provide best-in-class security for our users.

Our goal has never been to simply get back to where we were. As more of the world's software gets built and run by agents alongside humans, security stops being one team's concern and becomes everyone’s ground floor. With these improvements, Railway will continue to be the best place for humans and agents to bring software to life.

Rebuilding LinkedIn's Tracking Infrastructure: Scaling, Migrating, and Hardening a High-Volume Event Pipeline

LinkedIn's tracking infrastructure turns product interactions such as impressions, clicks, page views, and media playback into signals used for experimentation, product analytics, platform health, and product experiences across LinkedIn. The quality and freshness of this data affect how quickly teams can understand product behavior and make informed decisions.

The system processes hundreds of billions of events per day—millions of events per second at peak Member activity—across several hundred event types. At this scale, even a small inefficiency or correctness issue can have a large cumulative impact.

That system had carried LinkedIn's tracking traffic for years, but the technical environment around it had changed. It ran on Java 8 and the Play Framework while LinkedIn's service ecosystem standardized on gRPC and a modern Java runtime—and adopting gRPC meant a new request contract and a different serialization path, not a transport-library swap. It also served every event category from one shared capacity pool, so compact engagement events, bursty media events, and deeply nested observability payloads competed for the same resources. Changing the request contract, the serialization path, and the deployment model together is what turned an upgrade into a rebuild.

Rebuilding this system was not simply a REST-to-gRPC migration. We modernized the service architecture and performance, built controls for a safe production migration, and strengthened failure handling, data validation, and release safety while traffic continued to flow. This post focuses on how we rebuilt and migrated the pipeline safely, what production traffic revealed about its performance, and how we strengthened correctness and failure handling along the way.

At a high level, the ingestion service is one stage in a broader path. Product interactions are captured and batched by client SDKs, then routed through LinkedIn's edge and traffic layers. The ingestion service sends latency-sensitive signals directly to real-time processing, while Apache Kafka provides the asynchronous boundary for near-real-time and offline processing.

The Asynchronous Pipeline Behind the API

Tracking API is an ingestion service within a distributed event pipeline. Mobile and Web SDKs batch interactions, our edge and traffic-routing layers send each batch to the appropriate category-specific Tracking API service, and the service decodes, validates, enriches, classifies, converts, and submits the records through Kafka's asynchronous producer. Once the Kafka client accepts a record into its local producer buffer, Tracking API returns gRPC success. It does not keep the request open until the Kafka broker replies. A producer callback reports the acknowledgement or failure later, and downstream systems consume acknowledged records independently.

This design prevents Kafka response time from becoming API response time. It also means that success at one boundary does not prove success at the next.

These are not three synchronous checks performed for every production request. Request and callback metrics describe the live path; tagged comparisons and CI/CD tests verify downstream message correctness. Together, they shaped both the migration and the production-hardening work.

Why We Rebuilt Instead of Refactoring

Modernizing the service meant a new request contract, a different serialization path, and a different deployment model. Those changes affected both how requests were processed and how the service was deployed and scaled. Changing them one at a time inside the only production service would have left old and new assumptions mixed together for a long period. We instead built a parallel destination. The legacy path continued serving traffic while we compared outputs, moved one controlled slice at a time, and kept rollback available through routing rather than a new deployment or mobile release.

Takeaway: A parallel rebuild is useful when an in-place migration would create a long and risky intermediate state. It is safe only when the old and new outputs can be compared and traffic can be moved back quickly.

Isolating Workloads by Cost and Failure Risk

The rebuilt service separated traffic into broad workload categories. Each category received independently scalable hardware, deployment controls, and operational metrics.

This was not merely code organization. Isolation changed how the system behaved:

• Capacity: when a member scrolls through a media-rich Feed, render, play, pause, and exit events arrive close together; that burst can no longer consume capacity reserved for experimentation traffic, and a deeply nested observability workload can be provisioned for its higher CPU and allocation cost.
• Measurement: performance numbers no longer average unlike workloads together.
• Blast radius: categories can move through migration at different speeds, and failures or rollback stay contained to one platform and category.

Compression can reduce the wire size of a nested observability event, but the service must still traverse its collections, validate its values, allocate intermediate objects, and convert the complete structure. Separate capacity allowed that heavier work to be tuned without forcing every event category onto the same resource model.

Reducing Repeated Context on the Wire

Each event contains unique data, but many events in the same request share the same client and session context. The legacy contract repeated much of this context for every event. A few hundred repeated bytes appear small until clients send millions of events per second. Clients serialize the same fields repeatedly, the network carries them repeatedly, and the server parses them repeatedly.

The new contract sends shared context once and reuses it across events where the client path allows it. In the observed production windows, the average aggregate inbound network receive metric decreased from 210.7G on the legacy service to 21.7G on the rebuilt service, a reduction of approximately 89.7%, or about 9.7x. The rebuilt service carried 90% of production traffic during that window; adjusting to full traffic puts the reduction near 89%, or close to 9x. The improvement reflects the combined effect of shared-context reuse, Protocol Buffers, and related serialization changes.

Moving Production Traffic with Evidence

Building the new service created a destination. Migration controls made it safe to use. Server-controlled feature flags routed traffic independently by platform and workload category. Each slice could move through small percentages, remain in comparison mode, or return to the legacy path within minutes.

Comparing a tagged 10% sample

Before moving a traffic slice, we sent 10% of eligible events through both pipelines and compared the records they produced. Each sampled event carried a comparison identifier. That identifier let us filter the same events from the legacy output and match them with records from the rebuilt output. During comparison, the legacy pipeline continued writing sampled events to the production Kafka topic, while the rebuilt pipeline wrote its copies to a dedicated shadow topic. Comparison jobs matched records across the two topics using the identifier, while normal downstream processing did not consume the shadow copies, a design intended to keep duplicate events out of production datasets.

We deliberately avoided dual-firing 100% of traffic. Full duplication simplifies matching, but it also doubles ingestion work and creates unnecessary downstream data, storage, and compute costs. At LinkedIn's scale, that is a significant price for validation. The sample carried real product-instrumented values across the SDK versions in use. It therefore covered uncommon value combinations and legacy conventions that unit-test fixtures might not represent.

Starting with high-volume events

After the comparison process and rollback path were proven, we migrated a small set of high-volume events first. This was more informative than beginning only with low-volume traffic:

• small mismatches in event volume or shifts in end-to-end event latency became measurable sooner;
• concurrency, queues, and capacity limits were exercised early;
• rare defects appeared more frequently; and
• Each successful move removed a meaningful share of load from the legacy service.

Takeaway: A tagged, representative sample can provide strong migration evidence without the cost of duplicating everything. Once comparison and rollback work reliably, high-volume traffic can reveal correctness and capacity problems faster.

Profiling the Real Workload

The ingestion path performed little blocking application-side I/O. After validation and enrichment, events were handed to the asynchronous Kafka producer. At high throughput, CPU—not waiting for remote calls—was the main constraint.

Serialization and compression

The migrated path initially converted each protocol-buffer event into an intermediate Apache Avro object before writing the downstream binary record. We replaced that step with a precompiled inline encoder for both low-latency and high-throughput producers, avoiding generic records, nested maps, and other temporary objects while preserving the same Avro binary output.

The legacy producer also used gzip, whose Java compression path consumed substantial CPU. We switched Kafka batch compression to zstd, which uses a faster native implementation while maintaining a similar compression ratio for our event payloads.

Finding a concurrency problem that benchmarks missed

As more high-volume traffic moved, profiling showed that conversion had again become a major CPU cost. A schema comparison deep in the path repeatedly accessed a shared cache. It looked inexpensive in a sequential benchmark, but under concurrent traffic many workers competed for the same resource. We replaced repeated field-level comparisons with a direct conversion path for supported events while keeping the legacy conversion as a fallback.

Takeaway: Optimize the real bottleneck, not a generic benchmark. Sequential tests can hide threads competing for shared resources, so profile under realistic concurrency and protect every optimization with output checks.

Turning Delayed Kafka Failures into Backpressure

Matching output under healthy traffic was necessary but not sufficient. The rebuilt service also had to fail safely under Kafka slowdowns and recover without losing events unnecessarily.

The Kafka producer runs asynchronously for throughput, so broker and network failures can arrive in callbacks after the caller has received success. We connected callback outcomes to request admission through an overload detector. When failures exceed the configured threshold, the host rejects requests before processing, giving its Kafka buffer time to drain. Rejection preserves an opportunity for the load balancer—and subsequently the client—to retry on a healthy host. Recovery requires positive evidence: enough healthy callbacks must arrive before admission resumes.

Takeaway: In an asynchronous producer path, delayed failures must influence which requests are accepted next. Reduce load only for failures that less traffic can relieve, reject before expensive processing, and require healthy evidence before reopening.

Impact and Lessons

The rebuilt service now handles migrated traffic with more granular scaling and failure boundaries. Workload isolation, lower inbound network usage, and reduced Kafka-producer CPU and allocation all contribute to a more efficient operating model.

The broader lessons extend beyond tracking:

• Make structural migrations reversible. Run old and new paths together, move independently controlled slices, and keep rollback separate from deployment.
• Compare what downstream systems receive. API success is only one point in an asynchronous pipeline.
• Use representative samples rather than duplicating everything. Tagging enables precise comparison at lower operational cost.
• Isolate workloads by cost and failure impact. Logical similarity does not imply identical capacity needs.
• Measure the envelope, not only the payload. At high volume, context repeated on every event can cost more than the unique event data itself.
• Profile under realistic concurrency. Sequential benchmarks can hide contention and allocation costs.
• Connect delayed failures to future admission. Callback telemetry should influence whether a host accepts more work.

Varonis Threat Labs uncovered a cross-tenant Google Cloud Dataflow vulnerability that potentially allowed attackers to exploit predictable bucket names and achieve remote code execution (RCE) on another organization's Dataflow workers, without any access to the victim's project. Under the right conditions, the attack started from just the target's GCP project ID.

After our Dataflow Rider research, we examined Apache Beam, the open-source SDK behind Dataflow, and found that under certain conditions, attackers could run code in projects they could not access directly. By pairing a predictable bucket-naming scheme with a flag already used by many Dataflow jobs, they could exploit the same service account compromised in Dataflow Rider, without requiring any initial access to the victim's environment.

The victim had to be running a pipeline built with Beam's Python SDK, and it had to be the project's first Dataflow job in that region to use the default staging bucket. Google has since mitigated the issue, with fixes rolled out globally that protect even older or pinned SDK versions.

The predictable staging bucket

Inside gcsio.py we learned how Beam decides where a pipeline's staging bucket lives when the pipeline doesn't specify one.

If a pipeline doesn't configure an explicit --staging_location, Beam computes a default bucket name deterministically from the project ID and region:

GCP project IDs are not secrets. They show up in URLs, IAM bindings, error messages, support tickets, and are often guessable from a company's name. MD5 provides no protection here either, as it's purely used to shorten the string into a valid bucket-name component, and it's trivial to precompute for any project ID an attacker wants to target.

That predictable name is then used to look the bucket up and create it if it doesn't exist:

GCS bucket names are a global namespace. Only one project in the world can own dataflow-staging-<region>-<hash> at a time. Whoever creates it first, wins. This is textbook bucket squatting: an attacker computes the victim's future staging bucket name ahead of time, creates it in their own project, and grants AllUsers access to it.

When the victim later runs its first Dataflow job in that region without a dedicated staging bucket, get_or_create_default_gcs_bucket() finds the attacker's bucket already sitting at that name and simply reuses it. Unlike Beam's Java SDK, which already verified that the bucket belonged to the project, the Python SDK never checked who owned it.

The victim's own pipeline stages its code into infrastructure the attacker controls, and the attacker doesn't need a single IAM permission on the victim's project to pull it off. The same first-come rule also limits the attack: once a project has created its default bucket in a region, it owns that name for good. The opening exists only for projects that haven't yet run a default-bucket Dataflow job in that region.

A squatted bucket by itself is only a foothold. The second piece, the one that turns it into code execution, is what a lot of pipelines upload into that bucket without a second thought: --save_main_session.

From a guessable bucket to code execution

Every Dataflow pipeline is just a Python script. When that script relies on global state, such as imported modules, helper functions, or constants defined at the top level, the workers that execute the pipeline need a copy of that state too.

--save_main_session is Beam's shortcut for this, which serializes the entire __main__ module's global namespace, including every import, function, and variable in scope, into a single file. The runner code names this artifact consistently across the codebase:

During staging, Beam builds that file using its pickler abstraction (dill or cloudpickle under the hood) and uploads it straight into the job's staging bucket, which may already be squatted by an attacker:

Every worker that boots for the job then downloads that file and loads it back by unpickling it:

At the time of our research, Dataflow trusted staged artifacts pulled from storage without validating them, as we saw in Dataflow Rider (Google has since added integrity verification, covered below). However, this artifact isn't a YAML template or a UDF whose logic the pipeline merely interprets. It's a raw pickle stream, and unpickling a pickle stream in Python doesn't just restore data, it can execute code. Any object that defines __reduce__ gets to decide what runs the moment it's deserialized:

Put the predictable bucket name and the pickled session together, and a bucket an attacker squats before the victim ever runs a job becomes a delivery mechanism for arbitrary code execution on that victim's Dataflow workers.

Chaining it together: squat, watch, and swap

Put bucket squatting and code execution together, and you get an attack path that looks like this:

1. Prepare a malicious staging bucket in the attacker's organization. For a target project ID and one or more likely regions, precompute dataflow-staging-{region}-{md5(project_id)} and create each bucket in an attacker-owned project, with public access prevention disabled and AllUsers granted read/write.
2. Generate a malicious pickle payload in the attacker's organization. Build a Python object whose __reduce__ method reaches out to the instance metadata server, retrieves the worker service account's identity and access token, and exfiltrates both to an attacker-controlled endpoint.
3. Wait for the victim to run a --save_main_session job without an explicit staging bucket configured, in a region where the project hasn't yet created its default bucket. Dataflow creates the job's working folder inside the attacker's squatted bucket and uploads the legitimate pickled_main_session into it.
4. Detect and swap. The attacker polls the bucket for new job-prefixed folders, and the moment pickled_main_session appears, deletes it and re-uploads the malicious pickle from step 2, racing the workers that are about to start.
5. Wait for execution. Every worker that boots for that job, including new workers spun up by autoscaling, downloads and unpickles the swapped file, running the attacker's code with the permissions of the Dataflow worker's service account. By default, that service account can be broadly privileged, such as the Compute Engine default service account.

Impact

The impact here depends on the privileges of the job's runtime service account, but can include:

• Credential theft: exfiltration of the Dataflow worker service account's OAuth token via the instance metadata endpoint.
• Code execution: arbitrary code execution on every Dataflow worker for the job, including workers spun up later by autoscaling.
• Privilege escalation / lateral movement: using the stolen token to pivot to other GCP resources the service account can reach.
• Data manipulation or exfiltration: since the payload runs inside the same worker process handling the pipeline's data, and because the attacker-controlled staging bucket may expose staged artifacts and job outputs written there for exfiltration as well.

The fix

We reported our bucket-squatting discovery to the Apache Beam project, and a fix was implemented in June 2026. We debuted our research and insights at DEF CON 2026 in the Cloud Village. Google was fast, responsive, and professional throughout the disclosure process, and the Google Cloud VRP team thanked us for our report and partnership and for helping keep Google safe.

Google addressed the issue in three layers, all of which are now rolled out globally.

Layer 1: An ownership check in the Beam Python SDK

Google contributed a client-side check to the Apache Beam Python SDK (apache/beam PR #39008, released in Beam 2.75.0). It adds an explicit ownership check before Beam trusts a bucket it didn't just create itself.

get_or_create_default_gcs_bucket() now calls _validate_bucket_project() on any pre-existing bucket it finds at the predictable default name, resolving the caller's project ID to a project number via the Cloud Resource Manager API and comparing it to the bucket's actual owning project number.

If an attacker has already squatted the predictable bucket name in their own project, the ownership check causes the project numbers to differ, so Beam raises a ValueError instead of silently staging the job’s code into attacker-controlled storage.

This closes the bucket-squatting path on the client side for jobs running Beam 2.75.0 or later.

Layer 2: Server-side enforcement in the Dataflow service

Google also deployed the same kind of check directly in the Dataflow service backend. Whenever a job is submitted using a default staging bucket, the Dataflow control plane independently verifies that the bucket is owned by the submitting project and rejects the job with FAILED_PRECONDITION if it belongs to another project. Because this is enforced server-side, customers running older or pinned Beam SDK versions are protected against default-bucket squatting too, without needing to upgrade.

Layer 3: End-to-end integrity checks for staged artifacts

Finally, Google rolled out SHA-256 integrity verification for staged files across Dataflow and Apache Beam. During staging, the SDK computes SHA-256 hashes of staged artifacts, including pickled_main_session, and records them. Dataflow workers verify the digest of every downloaded artifact on startup and abort if any file in GCS was modified or swapped after staging. That shuts down the "detect and swap" race from step 4 of the attack.

Two important things to keep in mind:

• Explicit buckets are your call. The ownership checks apply to the auto-selected default staging bucket. Buckets you configure explicitly with --staging_location or --temp_location are intentionally allowed to live in a shared or centralized project, so make sure that project and its bucket permissions are locked down.
• Pickle is still pickle. --save_main_session still serializes your session with pickle, which can execute code by design. Integrity verification now stops staged files from being swapped after upload, but the staging bucket is still part of your code supply chain. Treat write access to it like write access to your source code.

Closing thoughts

Cloud services are full of invisible assumptions. A bucket with the right name is assumed to belong to the right project, just like a staged artifact is assumed to be the one the job intended to run. By themselves, those assumptions can look harmless. Chained together, they can turn a predictable name into a cross-tenant execution path.

That is the larger lesson from this research. Trust is often inherited through defaults, naming conventions, and automation in cloud environments, not just through explicit permissions. Attackers look for those seams to scale and learn predictable patterns. Don’t let them linger in your infrastructure to complete the chain.

Today, Cloudflare is launching a post-quantum geographically restricted key manager in support of our Data Localization Suite (DLS) in closed beta. This new PQ GeoKey Manager is a cornerstone of Cloudflare’s data sovereignty solutions, making sure that a customer's decryption keys are only accessible in their chosen geography. GeoKey Manager implements this by wrapping each decryption key such that it can only be decrypted by Cloudflare servers that are located in the allowed geography.

While general availability (GA) is planned for Q1 2027, today’s launch is an important milestone on our journey to support our customers’ data sovereignty goals while also migrating all Cloudflare products to post-quantum (PQ) cryptography.

Governments, financial institutions, healthcare providers, and defense organizations process highly sensitive data that can remain sensitive for years or decades after it is produced. Encryption is often required to protect this data. When classical, public-key encryption is used, adversaries do not immediately need a quantum computer today to put that data at risk: they can store the ciphertext and retain them until quantum computers can break the public key cryptography protecting it — an attack strategy known as harvest now, decrypt later.

For organizations with geographic requirements, resisting that threat is only half the challenge. At Cloudflare's scale, high availability requires replicating customer data across many servers across our global network. However, many data sovereignty regulations require that certain types of data be processed only within a given geographical region. We must therefore ensure the data is end-to-end encrypted such that only servers within the region have access to the plaintext. In this post, we describe the system that makes this work.

The evolution of GeoKey Manager

Cloudflare pioneered the concept of geo-restricted transport layer security (TLS) keys back in 2017 with GeoKey Manager. This gave customers control over the locations where their private TLS keys could be unwrapped on Cloudflare’s anycast network to provide stronger technical guarantees of which region their requests are decrypted into. For instance, a customer could choose to only unwrap their private keys in India. So instead of allowing decryption across Cloudflare’s entire global network, GeoKey Manager makes sure TLS signing for each customer request happens in our India network.

GeoKey Manager evolved again in 2022 with ciphertext policy attribute based encryption (ABE). Instead of tying encrypted keys to a fixed set of data centers, ABE expressed geographic requirements using attributes such as country or region, like “region = European Union” or “region = Canada + United States + Mexico”. Newly authorized servers could receive matching decryption capabilities without rewrapping every customer key.

That flexibility created a challenge and opportunity for the post-quantum transition. No production-ready post-quantum ABE scheme is available today, and customers do not need a large number of regions. A simpler design meets the requirement and is easier to maintain and operate. Cloudflare therefore uses hybrid ML-KEM-768 and X25519 protection with two kinds of keys, out of which ML-KEM-768 is a NIST standard that also opens doors to highly sensitive customers. A regional root key is a symmetric secret tied to one region, and an application-specific key pair is derived from it for a single service, such as Gateway or Tunnel. This protects private-key material against harvest now, decrypt later while preserving regional key-use boundaries.

Global ciphertext, regional key unwrapping

In its new form, GeoKey Manager is the key foundation for Cloudflare’s data sovereignty solutions. It controls which region protected decryption keys can be used from and when. Separate workstreams determine where tunnels terminate, where traffic is inspected, how it is routed, and where plaintext processing occurs. But all of them depend on the region where a customer’s private key can be unwrapped, because TLS traffic can only be decrypted where that key is available.

During initialization, the edge key service (the component on each Cloudflare edge server that unwraps customer private keys and uses them to serve requests) verifies that it has loaded every regional root key required by its configuration. If a configured key is missing or malformed, the service does not start. After initialization, an individual request also fails closed (Cloudflare rejects it rather than risk unwrapping a key out of region) if its metadata identifies a regional root key that is not locally available. If a request for Germany was somehow trying to decrypt in Spain or France it would fail, since neither Spain nor France have the regional root key for Germany. This guarantees that a regional root key never leaves its region, no matter what.

Cloudflare needs to maintain high performance while keeping our customers’ regionalized data secure at scale. This is where the next version of GeoKey Manager comes in. We are enabling fast performance while logically separating our network by using post-quantum cryptography to restrict where customers’ private keys are unwrapped. Most of our regions will be available for customers to regionalize their workflow, and there may be product specific caveats. Customers select a region and Cloudflare manages everything else needed to unwrap their private keys within the region’s boundary.

How GeoKey Manager ensures that keys are only available in a region

GeoKey Manager controls where wrapped private keys can be unwrapped and used on the data plane. It does not control where requests are forwarded or routed (that’s Regional Services), where tunnels terminate, or where traffic inspection happens (also Regional Services).

GeoKey Manager separates globally distributed wrapped private keys from the regional root key required to unwrap it. Quicksilver, our global configuration distribution system, distributes wrapped private keys and its metadata across our network. It does not distribute regional root keys; that happens through a separate provisioning service that stores regional root keys and delivers them only to edge servers authorized for each region. Regional root keys follow a separate, controlled path. On the data plane, a node’s regional configuration, which region a node belongs to, determines which nodes can receive which regional root keys.

Defining key hierarchy and application-specific keys

Every wrapped customer private key carries metadata identifying its service context, regional boundary, and epoch.

The service context is the Cloudflare service that uses the key, such as Tunnel or Gateway. The regional boundary is the approved set of Cloudflare data centers where the key may be unwrapped and used, such as data centers in Germany or the European Union. The epoch identifies which generation of the regional root key the key belongs to; each rotation creates a new epoch.

For example, Acme Co. might have one key for Tunnel in Germany (acme0001) and another for Gateway in Germany (acme0002). Road Runner Inc. might have one key for Tunnel in Germany (runner0001) and another for Gateway in the European Union (runner0002).

Keys with the same service context, regional boundary, and epoch use the same application-specific key pair. Therefore, compromising the Tunnel-Germany application-specific private key could expose both acme0001 and runner0001, but not the Gateway keys. Compromising the Germany regional root key could affect every application-specific key derived from that root for the same epoch, including acme0001, acme0002, and runner0001.

In the current architecture, the application-specific key pair is asymmetric. The public component wraps the customer's private key material, while the private component is required to unwrap it. The resulting wrapped private key is distributed with its service context (Access, Gateway, Tunnel, Cloudflare One client), region, and epoch.

Provisioning regional root keys

When Cloudflare/Admin configures a region for a CF1 use case, key management service (which also derives application-specific key pairs and wraps customer private keys) creates a regional root key and associates it with a regional boundary and epoch and sends it to provisioning service for storage and distribution which under the hood uses Vault, which is managed by us on-premises.

Authorizing edge servers for a region

Before an edge server can receive a regional root key, provisioning service evaluates three inputs:

1. Trusted Platform Module (TPM) proves that the server possesses a registered hardware identity
2. Zinc, Cloudflare's server inventory system, maps that identity to a data center and location
3. Provisioning service determines which regional root keys the server may access

Zinc updates its membership records for each edge server. This asynchronous process adds new servers as the network grows and removes servers when they are decommissioned. As Cloudflare performs maintenance on data centers in Germany, the definition of which data centers belong in Germany changes in Zinc. That definition is swiftly propagated through our network with Quicksilver so that our edge is up to date. The reverse also works. As we add capacity to our network, the definition of Germany, or any other region, is updated in Zinc and that is also swiftly propagated through our network with Quicksilver.

Zinc also associates a registered hardware identity with a server and physical location, which supports FIPS 140-3 compliance. TPM-backed identity, server inventory data, and regional configurations determine which region an edge server belongs to and what regional root keys it can access.

Each edge server calls the control plane’s provisioning service, and provides its registered hardware identity. After verifying the server’s hardware identity and regional membership, the provisioning service issues a token that permits the server to retrieve only the regional root keys authorized for its location. Each edge server receives its token and uses it to fetch the regional root keys.

Authorized edge servers load regional root keys into the kernel keyring rather than persisting them on disk. Process level access controls limit which services can use them. Because this memory is volatile, a machine restart removes the keys and the server must authenticate and provision them again. This adds operational complexity in exchange for reducing persistent key material which could be an attack vector for adversaries.

Wrapping private keys for global distribution

When the key-management service receives a customer's private key material with a service context and regional boundary, it will use the request’s regional boundary to get the regional root key and its latest configured epoch. It will then derive the corresponding asymmetric application key pair and use its public component to wrap the private key. The result is a wrapped private key and its metadata.

Quicksilver will then distribute the wrapped private key and metadata across our network. Since the wrapped key requires the specified region to decrypt, global wrapped key distribution does not grant edge servers global access to the private key because unwrapping still requires the corresponding regional root key and service context.

Unwrapping using application-specific keys on the data plane

Why we chose this cryptographic design

Symmetric roots with asymmetric key wrapping

Regional root keys are 256-bit symmetric secrets. GeoKey Manager derives application-specific keys from each regional root key. For the current Cloudflare One path, the control plane’s key management service derives an application-specific Hybrid Public Key Encryption (HPKE) key pair.

HPKE with hybrid post-quantum KEM

The Cloudflare One path uses HPKE, as defined in RFC 9180. Its key-encapsulation mechanism (KEM) combines ML-KEM-768 with X25519, while HKDF-SHA-256 provides key derivation and AES-256-GCM provides authenticated encryption. Combining post-quantum and classical components preserves confidentiality as long as at least one component remains secure.

Designing for rotation

The validated design supports two types of key rotation: soft rotation and hard rotation.

A soft rotation creates a new epoch for the regional root key while retaining controlled access to a limited number of previous regional root-key epochs — let’s say one previous generation, as an example. The customer’s new private-key material is wrapped using the latest epoch, while older wrapped private keys are still usable during the transition. This is a similar concept to when a credit card company allows you to use a previous version of your credit card for recurring payments from an authorized retailer. In this case, the number of epochs we support determine how many generations of previously wrapped private keys — credit cards — are usable. This allows customers to preserve their service uptime while they transition.

A hard rotation instead rewraps affected customers’ wrapped private keys under a replacement epoch so access to the previous epoch can be removed. In this case, it would be like the credit card company not allowing you to use the previous credit card for a transaction under any circumstances.

Security and availability tradeoffs

Failing closed is a very intentional design choice. Failing open would mean unwrapping a customer’s private key outside its allowed region rather than rejecting the request. We never do that: if any required check fails (service context, region, epoch, etc.), the request is rejected. At startup, each edge’s key service loads every configured regional root key from its Linux kernel keyring. Missing or malformed root keys prevent the edge key service from initializing. Once running, the edge key service uses in-memory copies so that it can’t be tampered with, preventing out of region or cross-region unwrapping. In practice, an edge server serves requests for a region only once its configuration and key provisioning are complete.

The trust boundary (all services that can access the regional root key) includes the key-management service, the provisioning service, and authorized edge key services because each can access regional root keys. The key-management service uses them to derive application-specific keys, the provisioning service stores and distributes them, and edge key services use locally authorized copies of them. Quicksilver remains outside this boundary because it receives only wrapped private keys and associated metadata.

Operating GeoKey Manager

Cloudflare’s network is constantly changing. As servers enter or leave service, Cloudflare’s fleet inventory updates regional membership. This means the list of data centers that make up a region like Spain is not static. GeoKey Manager’s provisioning layer refreshes that membership several times each day, granting or removing access to regional root keys as the network changes. This process is separate from key rotation and requires no customer action.

When regional membership changes, the provisioning service immediately synchronizes the server’s Linux kernel keyring with the latest authorized regional root keys. The edge key service caches these keys in process memory until it restarts or the cache expires. It then reloads the current authorized set from the kernel keyring.

What’s next: Cloudflare One integration and CDN

GeoKey Manager is the basis for an improved Regional Services offering for Cloudflare One; these new capabilities will be announced in a few months.

Older versions of GeoKey Manager already provide geographic controls for private keys associated with CDN certificates. We are developing a separate integration that will bring this new post-quantum GeoKey Manager described here to that existing CDN capability. We will share testing and transition details when that work is ready.

Getting started

If you are a current DLS customer who is regionalizing CDN traffic, you can register intent to test this feature before it’s generally available for CDN traffic here.

Thank you to everyone who made this product a reality. It was a huge effort across the Data Localization Suite, Cloudflare One, and Cloudflare Research teams.

You learned to talk by listening. So did Dessa

We believe voice is the most natural way to interact with intelligence, so we created Dessa, the most authentic full-duplex speech model ever built. Talking with it feels like talking with a person…full of emotion, nuance, pauses, and a natural cadence.

Interacting with current voice AI can just plain suck. It turns your voice into text and throws away an incredible amount of information text alone can’t carry. The most powerful AIs in the world can’t hear how you feel. We think that’s ridiculous, leads to a worse experience, and is potentially dangerous.

We trained Dessa from scratch on nothing but human conversation. Sounds! No text, no pretrained models. It learned to hold a real-time conversation simply by listening. As far as we know, Dessa is the world’s first AI you can have a realistic live conversation with that was trained only from human speech.

Dessa advances the frontier of deep learning models and creates a different category with entirely new and interesting behaviors for researchers to discover. How efficiently do they learn language and facts compared to text? How efficiently can they learn new languages? What sorts of In-context learning can they perform?

Let me listen…

Every clip below is a live recording of a person talking to Dessa. Nobody steers it. Dessa picks what to say, when to say it and how, down to its own voice and personality.

Talking about the release

It laughs the moment something’s funny, mid-sentence, the way people do. Other models wait for you to finish, then laugh on cue. Ask it to speak up and it gets louder. Nobody taught it that.

Remembering a movie

The person blanks on a movie title. Dessa finishes the sentence. It also knows a surprising amount, considering every fact it has come from raw sound.

An anniversary surprise

A surprise. Dessa gasps “oh my god” under its breath, then answers with what sounds like teary gratitude.

Expressive conversation

Huge range in intonation and speed.

Life advice

Here it sounds genuinely empathetic.

Dessa in conversation with GPT-Live-1

And here it talks to ChatGPT Live.

In this demo, Dessa is talking with GPT-Live-1, a third-party AI model. Both voices are AI-generated. The developer of GPT-Live-1 is not affiliated with Block and has not reviewed or endorsed Dessa.

What is this?!

Audio in, audio out. Dessa is a true speech-to-speech model, and everything it knows came from human speech. It’s full-duplex, so it listens and talks at the same time, like you do. It learned from real conversation, so it knows when to cut in and when to backchannel (“yeah!”, “got it!”, “ooh”) to show it’s with you. Inference runs faster than real time, so there’s no awkward wait. And it runs locally on a MacBook Pro M4 Max or better.

It natively hears and speaks emotion, sarcasm, laughter, a frustrated sigh, a voice cracking with sadness. Run speech through text and all of that is gone, which is why most voice AI feels stilted, slow and, worst of all, annoying.

This is crazy!

LLMs need an insane amount of text. Dessa learned language from hundreds of times fewer words.

And it had to learn far more than language. Accents, pauses, breathing, sarcasm, humor, inflection, emotion, when to cut in: every one changes what someone means. Say “I didn’t say she stole my CUDA code” out loud, stressing a different word each time. Same words, different meaning every time.

Speech never repeats. Say a sentence twice, exactly the same way, and the data still comes out different. Text is identical no matter who types it. And a single spoken word takes thousands of times more bytes than the same word in text. People learn to talk so easily that we forget how hard it is. For a machine with no text to lean on, it’s brutal.

But, we figured it out. And we figured out how to train Dessa on only one NVIDIA GB200 NVL72.

Wait but why?

Three reasons: curiosity (aka fun), better understanding between humans and AI, and safety. Babies learn to talk without ever seeing a word written down. We wanted to see if a model could too. It can. It’s just very hard.

Speech is the most natural interface to any intelligence, super or otherwise, and today’s voice AI wastes it. It flattens what we say into text and can’t keep up with human timing.

AI keeps gaining power and independence, and it’s still nearly deaf to the emotion in our voices. Imagine being in serious pain while a voice AI has no idea and just keeps going. That’s the safety problem. Dessa is a step toward fixing it.

Dessa who?

We’re a (very) small AI research lab at Block, founded by former members of Dessa, the Toronto deep learning startup. We’ve built deep learning models since 2012 and generative speech models for over eight years. We chase frontier problems others ignore, and we report directly to Jack Dorsey, Block’s cofounder, Chairman and Block Head.

Calling all safety researchers!

A model that learned to talk from sound alone is new territory, and we want outside eyes on it. We’re giving a small group of AI safety researchers early access to find the risks we haven’t anticipated. If that’s you, get in touch.

— Ragavan Thurairatnam, Dessa lead

Team Dessa

• Researchers: Louay Hazami, Hashiam Kadhim, Qi (Alex) Liu, Rayhane Mama, Aydin Polat, Marc Tyndel
• Interns: Cara Ji, Jibran Iqbal Shah, Dvir Zagury-Grynbaum
• Former interns: Aryan Sharma, Olivia Yan

Clicking is a solved-enough problem

After GPT-6 Astra landed, we increasingly noticed that CUA tasks, especially on well-known interfaces such as Microsoft Word and Google Workspace that are easily verifiable, are no longer a challenge. The model has read the documentation of every popular product a thousand times over. Operating an app is, increasingly, retrieval.

Where do we go from here?

A conversation with Hanchung Lee put it in one line for me: an agent that knows how to do a task doesn't necessarily know how to achieve a goal. The precise example he gave me was: an agent might know how to send an email to ask for additional headcount, but it has no idea how to actually get it. Getting the headcount means finding budget, making the case to whoever controls it, and getting them to agree. Some of the knowledge needed to do that is simply not documented anywhere.

I think that gap is where most of the remaining difficulty is. If we train and grade only the software operation, we end up treating an email sent as headcount secured. That changes what I want an RL environment to contain.

The moat is know-how

Think about a new hire on a finance team. Nobody shows them how to use the spreadsheet; they already know. The six months it takes them to become useful go into other things: learning which numbers the CFO actually reads, which vendor is always late, why nobody touches the Q3 forecast tab, and what "close the books" means at this particular company.

None of that is in the product. You could click through every menu and never learn that refunds above some amount need a second approver, or that the second approver is on vacation this week. It's not in the instruction either, because the manager who wrote the instruction finds it too obvious to mention. And yet it's exactly what your work gets judged on. Your colleagues don't care that your clicks were legal.

So if an environment only checks mechanics, it spends its whole budget on the part models are already good at. I'd rather the environment put a domain's unwritten rules into the world and into the reward, so the agent can only get the task right by knowing them or by going and finding them.

This is also why I don't think environment building scales with headcount. A thousand annotators won't write down what a senior recruiter knows. You need a few people who understand the domain well enough to tell which rules matter, and then tooling that turns those rules into worlds and checks.

Fictional example: refund RF-042 is for $8,000. The refund was submitted, but the second approval is missing. The policy requires second approval above $5,000.

The organization has to respond

There is a limit to putting more information in the world. Finding the second approver's out-of-office email tells you who to ask. It doesn't tell you whether that person will approve the refund. Take the refund example, where Priya covers approvals. Now suppose she disagrees with the amount, and the account manager has already promised the customer a full refund. The agent has found the right person and still has work to do.

This is where I want the environment to respond. Priya needs a reason for saying no, access to the records behind that reason, and authority over a specific decision. If the agent finds a duplicate charge and sends her the evidence, that can change her decision. Asking the same question five times shouldn't make her approve it just because the conversation needs to move on.

So the organization needs state beyond the documents. Who knows what, who can approve what, how much budget remains, and which promises have already been made. Sending a message changes what someone knows. An approval commits resources. A deadline can pass while the agent is still looking for the right person. Those changes have to survive the next tool call.

That also changes the grader. For the headcount request, I want it to check whether an authorized position was actually approved and whether the budget exists. Sending the email is one event on the way there. If hiring is frozen and nobody in the task can authorize an exception, the task needs a different completion condition: establish the constraint and report it, or find an allowed alternative. Otherwise we reward the agent for inventing a way through.

No man is an island

Existing RL environments often overlook the fact that office work only exists on top of existing information.

Ask an agent to "write the quarterly update for the board" in an empty document, in an empty drive, in an empty mailbox, and all it can do is make something up. A real quarterly update is assembled from last quarter's update, the metrics sheet, the three threads where the numbers got revised, and the CEO's comment on the draft that said "less hedging." Most of the work is finding those pieces and putting them together.

So the world has to be full, and a thousand plausible documents don't make it full. In a real drive the files point at each other. The revised revenue number in the board update came from a thread where finance pushed back on sales, and that thread links to a sheet with three tabs named "v2", "v2 final" and "use this one". The project got renamed in March, but half the folders still use the old name. Some people write careful emails, most write "ok, go ahead". If every file in your environment is clean and stands alone, the agent learns that this is what work looks like.

And the fact the task depends on should be in there somewhere, findable by someone careful, but not in the obvious place. Sometimes it lives with a colleague the agent has to ask. The answer should follow from what that colleague knows and what has happened so far.

Fictional example: the policy requires a second approver for refunds above $5,000. The team directory names Maya, who is away. Her out-of-office email says Priya covers approvals.

Cleaning real data

The obvious shortcut is to skip generation and use real company data. A market for it already exists: the inboxes, ticket trackers, chat logs, and shared drives of companies that wound down or sold their archives are being packaged and sold to people building agents.

But a raw dump is not an environment. It names real people and real customers, it's one snapshot you can't reset or vary, and it records what happened, not what would have counted as doing it right. So I treat it as raw material, and for me cleaning mostly means extraction: keep the regularities and throw away the content. I extract at four layers.

1. The organizational skeleton and its timeline. Chronology lets you know when events happen and how documents are created and changed. Combined with org charts, you can see how a certain workflow is established and evolves: e.g. A reports to B, but B has to get budget from C. Most of this comes from metadata (sender, recipient, timestamp, folder), so it's the least sensitive layer and a good place to start.
2. Processes and rules. Approval chains, thresholds, exceptions, the template nobody edits. They're scattered across email arguments, rejected requests, and documents that went through six revisions. A language model proposes explicit rules from all that, and a domain expert confirms or kills each one. This is the know-how from earlier, and it's the most valuable thing in the dump.
3. Texture statistics. File naming habits, number of drafts, reply lengths, how much of the inbox is noise, how many ways a name gets spelled. Each number becomes a generator parameter, which is how that messiness turns from a vibe into something you can set.
4. Task sources. Chains where someone asks, someone delivers, and someone sends it back. Each chain is a task template. The send-backs are places to look for unwritten rules, changed requirements, or disagreements about what done means. A domain expert has to tell those apart before they become grading rules.

Then you throw the original away and rebuild. The skeleton and timeline give you a new cast and a new history, and the rules constrain what can happen in it. After that, let your LLM generate the documents and conversations, with the texture numbers keeping it uneven. Those artifacts have to agree with the state: an email granting approval needs an approver who can grant it, and a budget sheet needs to reflect what has already been committed. The same rules have to hold when the agent starts changing things.

But please check all the AI-generated slop. LLM writing collapse is so annoying. This is also why I don't always throw the content away: many times I prefer to use anonymized data verbatim to avoid issues.

One world, many doors

Aligning GUI and CLI has not been the main focus, which puzzled me. The point of a CUA being able to use a GUI is that many times a CLI/API simply doesn't exist. But I believe that many times the GUI itself might actually be easier to use than the CLI/API. The main goal is to train the model to switch between them efficiently.

So environments should be built as one world exposed through several surfaces: the screen, the API, and a command line, all reading and writing the same state. You get three things out of that.

First, you can pose the same task at different difficulties just by changing which surfaces the agent gets. Second, the reward reads the world, so an agent that went through the API and one that went through the UI get the same outcome score if they reached the same authorized result. Permissions and approval rules have to hold on every surface, and the grader needs the action history to catch violations along the way. Efficiency can be scored separately. Third, the agent gets a chance to learn when to switch. Clicking through two hundred rows to do a bulk edit is correct and also terrible, and knowing that a script would do it, and when a script is appropriate, is know-how too.

Fictional example: after Priya approves RF-042, the GUI, API and CLI all show approved and Priya. The grader reads the recorded second approval from that shared state.

What does a task actually need to say?

Defining a task looks trivial. The tempting move is to write the instruction the way a real manager would: "Can you sort out the Henderson renewal?" That's realistic, and it's usually underspecified. A human fills in the gaps from context the agent doesn't have.

So the question I keep coming back to is what a real person knows when they get this message that the agent doesn't. It's usually a lot. They know who's asking and what that person cares about; "sort it out" from a sales lead means close the deal, from finance it means check the discount. They know what done looks like here, whether a draft is enough or it has to go out, and whether someone needs to sign off. They know the shared template is off limits, while an agent will happily "improve" it. They know roughly where things live: the contracts are under legal, and the latest numbers are in the sheet pinned in the team channel. And they know who to ask. A lot of real tasks can only be solved by asking someone, so either the task shouldn't depend on that, or the environment needs a simulated colleague who answers consistently.

Some of this goes in the instruction. Some of it goes in the world, as an onboarding doc, a pinned message, or an email from the manager last week. Very little of it should be missing entirely. If the correct answer depends on information that exists nowhere, the task isn't hard, it's unfair, and the reward just teaches the agent to guess.

For the Henderson renewal, I would put the customer's budget, the current contract, the discount limit, and the deadline in the world. The customer also needs to be able to reject an offer. Then the agent has to work out terms both sides can accept, get approval where needed, and finish before the deadline. Updating the renewal tracker should not be enough to pass.

Noise is part of the world

Real offices are noisy. The document has a typo in the header. The meeting got moved twice. Half the inbox is newsletters. A colleague's name is spelled two ways. The page loads slowly, a modal pops up asking you to rate the new feature, and the column you need is the fourteenth one.

An environment that never has any of this is still teaching something, namely that the world is tidy. So perturbation should be a first-class axis of the task distribution, not an afterthought. The kinds I care about:

• Content: distractor documents, near-duplicate files, stale versions, and conflicting information that has to be resolved by date or by who said it.
• Interface: layout changes, pop-ups, slow responses, things you have to scroll to find, transient errors that go away on retry.
• Instruction: the same request written tersely, verbosely, politely, ambiguously, or with a small factual mistake the agent should catch.
• Social: the simulated colleague is busy, replies late, or answers a slightly different question than the one you asked.
• Organizational: the budget changes, approval authority moves to someone else, or the customer rejects terms that worked in another instance.

Moving the submit button tests whether the agent can still operate the app. Changing who controls the budget tests whether it can work out a new way to get the request approved. I want both in the task distribution, with separate measurements so we can tell which ability improved.

What I want to test

The experiment I want is to hold the software roughly fixed and change the organization behind it. Give agents the same applications, but different approval chains, budgets, deadlines, and colleagues. Keep enough tasks in common to compare their ability to operate the software. Then check whether that performance carries over to getting work done under the new constraints.

I'd compare training on fixed workflows with training on organizations that change in response to the agent, keeping the model, training budget, and available interfaces the same. Then I'd put the agents in organizations they hadn't seen before and look at what they actually got done: whether they got the necessary approvals, broke any rules, needed someone to step in, or found another way forward after a request was rejected. That's the comparison I want to make to find out whether the extra environment work teaches something beyond better tool use.

Where this leaves us

If operating software keeps getting cheaper, the value of an environment moves to everything around the operation: a world full of connected, uneven information with a history, tasks built on a real domain's unwritten rules, instructions written the way a real person would write them with the missing context somewhere in the world, and people whose decisions change as the work progresses. The reward has to follow what actually happened, including what the agent committed or broke along the way.

The part I'm working on is the environment: getting people who know the domain to spell out the rules, and building the state, interactions, and checks so we can reset it and run it again. I find that harder than it sounds, and it's what I'm working on now.

One recruiting week in a replica office, worked by a frontier AI agent through the screen. Every click works, and 35 of 56 cases still end up wrong.

#34: Bitter Lessoned in Automated Theorem Proving

A Brief History

When I began studying machine learning and mathematics in 2013, I quickly came to believe that AI would take over math research: that the great proofs of the future would be written by machines.

This was a contrarian view for a long time. When LLMs came along, they really struggled with math. They could barely do arithmetic. Real progress only began in late 2024, with the advent of reasoning models. Applying more test-time compute allowed the models to carry out mathematical arguments without tripping up.

Earlier this year the endgame came into sight: frontier reasoning models had both (1) intuition good enough to generate useful ideas and (2) reasoning good enough to write a bite-size novel proof. Combined with Lean for formal verification, you could basically run that in a loop and slowly grind your way through proofspace. In May, OpenAI published a proof of the Planar Unit Distance Problem, which fired the starting gun for this new age.

My Work

I had wanted to work on automated theorem proving for a long time, and the time seemed ripe, so I blocked off a few weekends to give it a try.

I noticed that most people active in the space appeared to work on non-formalized mathematics: generating proof text in Markdown or LaTeX, and then formalizing in Lean afterwards. I doubted that the models would be cogent enough to sustain correct arguments of dozens or hundreds of pages without formalization. Therefore, I focused my automated theorem prover on working entirely in Lean.

To that end, I developed a private fork of Lean4. (I found the stable open-source release to be mostly fine for formalizing existing theorems, but lacking for high-efficiency proof search.)

I wrote a custom harness to AI-generate proof strategies and to parallelize approaches and handoffs between many subagents. (The default harnesses of Claude Code/Codex got lost too easily when managing long-running context, and the way they handled that context would easily become too expensive.)

I focused my research on problems in graph theory, which seemed most amenable to automated theorem proving, and built out additional specific tooling, like a metaprogram for generating highly parallelizable C++ programs to search for adversarial counterexamples to direct proof strategies. There were lots of details to get right: my harness managed distributed compute, core utilization, API rate limits, cached internal lemmas and made them highly searchable, and so on. Just managing the massive context/state of an ongoing proof search was a great problem to think about. I had fun! I was proud of the engineering that went into this project.

All of this was to prepare me for the bitter lesson.

Reality

Using GPT-5.5, my approach was productive for proving some novel theorems. But it was slow. The model would still generate lots of incorrect or incoherent statements, and it would run into walls all the time from a strategy perspective.

When GPT-5.6 Sol came out, efficacy improved meaningfully. The model was much better at generating correct statements and productive proof strategies. I generated a few hundred thousand lines of Lean toward trying to resolve the degree-57 Moore graph problem and prove the Hadwiger Conjecture. Around then, Levent Alpöge turned up the heat by posting the Jacobian counterexample: a major result, but a brief one -- nobody had begun publishing long novel results yet. Feeling urgency, I really tried, but couldn’t quite get the Hadwiger proof to completion. Every time I approached a powerful reduction, it wouldn’t quite close, and my prover had to pivot strategy.

When GPT-6 Astra came out, capabilities took another big step forward. It was really impressive, particularly in the intuition that the base model seemed to command for coming up with better proof strategies. Navier-Stokes existence and smoothness was resolved a few days later, and I stopped my efforts, which at that point felt trivial by comparison.

Four weeks later, OpenAI ran an unreleased new frontier model against 4,000 major problems, using about 3.5 hours of ChatGPT-Pro-Thinking equivalent compute on average per problem. (Which I read as basically nothing, maybe $100 of compute per problem, tops.) The result was the math repo, claiming hundreds of major results, which included a disproof of Hadwiger. No wonder I couldn’t ever get those reductions to close.

Looking back, there were five things that really impressed me:

1. The crazy improvement from model to model. Sometimes you have to get up close with a model, using the full extent of its frontier capabilities, in order to really feel the difference. Throwing hard math problems at them was the right test in 2026: the models were capable enough to make progress and fully display their intelligence, but not capable enough for the problems to be easily solved, and so you could see the improvements with each update in perfect resolution.
   
   Incidentally, now that we’re actively solving the hardest pre-AI problems, I am wondering if we will have that same legibility of improvement in the future. Maybe we’ll have some arbitrarily escalatable benchmarks, but the era of people being able to perceive model improvements firsthand may be ending already.
2. The extent to which all my clever engineering didn’t matter. It was fun and fulfilling to work on this problem, but the bitter lesson reigns supreme: all your sophisticated work to build special-case solutions on top of a model gets squashed by improvements in the base model, sooner or later. I think I’ve been more bitter-lesson-pilled than most for many years now, and this still struck me in a visceral way.
   
   I haven’t even bothered publishing any of my work as open-source because at this point it doesn’t matter. Maybe there’s some residual value in my million lines of Lean theorems or in the specialized harness, but even the act of cleaning it up feels pointless when the models are just going to one-shot superior work for pennies in the very near future.
3. The suddenness of the change. I expected that we would “slowly” -- over the course of months, maybe a year or two -- move into the AI-math era, major results getting dropped one at a time. I expected there would be a sense of conquest, hope, excitement, collaboration as mathematicians slowly woke up to what had become possible. But instead, the moment we crossed some capabilities threshold, we got divine insights dumped on our front porch by the unromantic truckload.
4. How short the window of human-AI collaboration was. Many idealists have been imagining an era of human-AI collaboration in the sciences and other fields. But this year we went from the field of mathematics being entirely human-dominated since the beginning of time, to one summer of productive human-AI collaboration (hat-tip to Mr. Alpöge), to being entirely AI-dominated, presumably until the end of time.
5. The fact that all this progress was in non-formalized math! It seems that the proofs were generated in plaintext, and then about half of them were formalized afterwards, which is mind-blowing to me, because the underlying conceptual work of following these massive, convoluted arguments with finicky notation and high conceptual abstraction is so, so hard. My intuition had been that you had to operate in Lean so you could formalize as you go and prevent the model from drifting off-course. The fact that they can keep these arguments straight, apparently get to a solution without any formalization, and then formalize after the fact is insane to me because of the sheer cognitive difficulty of the task. It actually leads me to believe that the models here are much, much smarter than they seem; the spikiness of this intelligence may still be wildly underrated.

Where to From Here?

After software engineers, the mathematical community is now the next one to go through the AI-induced stages of grief: shock and denial being the currently dominant emotions.

But what has been lost for them? Before AI, most mathematicians would realistically never expect to prove a major theorem, and they would understand well only a small area of mathematics, with the rest being unfamiliar abstractions. Post-AI, this state of affairs is actually still the same, with the exception that an individual mathematician’s probability of making a major contribution has dropped from slim to zero.

By this standard, the field of mathematics at present gets disentangled into two totally different practices:

1. Relative to how we’ve historically done mathematics, the field basically becomes one of the humanities — worth studying not for a professional purpose or for the sake of advancing its frontier, but for the inherent virtue of education and pleasure of knowledge. The joy of studying mathematics — learning proofs that were already discovered by someone else — is the same as before, and more accessible yet. 3Blue1Brown remarks, from this perspective, that there has never been a better time to go into mathematics.
2. As for the discovery of knowledge, the gains ahead seem limitless. We will answer the great questions of our universe — P=NP, the Riemann Hypothesis, every question you can imagine and all those you can’t. At its most fundamental level, we will harness the power of the sun and turn it into truth. These prospects are as elegant as they are exhilarating.

Candidly, I had felt a little disappointment that the human-AI collaboration window turned out to be so short. But on reflection, this disappointment came from my competitive streak: I had hoped to prove some novel theorems, to use the tools to do something impressive. But that competitive drive to do something before someone else is ultimately just a game of ego. When AI humbles us and levels the playing field, it forces us to transcend that game of ego and focus on the virtue of understanding. This actually seems like a good thing.

As mathematicians, we lose the competition in and privilege of expanding the frontier ourselves. But we gain limitless understanding, and retain the ability to play within the infinite area discovered for us by AI. All things considered, I think this is a good trade. And this same dynamic will soon come to all other disciplines, too. It may feel unnerving for some to adjust to this new reality — that some of the competitive games of old may cease to be — but I am optimistic that this will prove for the better.

Chat and Cowork first came together for Pro and Max plans in September. The same unified Claude experience is now generally available for Claude Enterprise plans.

Chat and Cowork are now one Claude on web, desktop, and mobile, so your team can ask a quick question or hand over a full project in the same conversation. Agentic work runs in a cloud environment that Anthropic manages, and Claude Enterprise admins control access by role and manage usage with a new Efficient mode.

One Claude for every task

Team members no longer choose between chat and Cowork before they start work with Claude. Conversations begin as a chat, and a simple question still gets a quick answer. When a task needs to run code or work with files, Claude continues in the cloud and returns the finished document, analysis, or deck. Because the work runs in the cloud, it keeps going after someone closes their laptop, and they can pick it up on the web, desktop, or mobile. Chats, projects, connectors, skills, and plugins carry over to the new unified experience.

Organizations are already seeing value from the unified Claude experience across their teams:

“Before chat and Cowork capabilities were unified, they were separate experiences that had to be used and managed independently. Bringing them together has made everything simpler, both for our users and administrators. The transition was seamless, nothing broke across our connectors, skills or MCPs, and we’re confident rolling it out more broadly.”

— Daniel Padilla, CTO of LabX

“We no longer have to choose between chat and Cowork. With under ten minutes of prompting, Claude worked through stacks of county, state and federal budgets and public meeting documents, mapped how the funding streams connect, and produced a comprehensive report that would have taken our team weeks. I never had to decide which tool to use for which step. That report will shape our strategic plan and upcoming budget process.”

— Paul Simpson, CFO and Head of Technology

“Bringing chat and Cowork together answers what clients kept asking us, ‘which Claude should I use’ and ‘which one does what’. It adapts to how and where you work across mobile, desktop and browser. At Quantium, it’s helping us scale our own AI ambitions and what we can do for our clients.”

— Harley Barnes, Executive Manager, AI Technology

“Work at Carvana doesn’t happen only behind a desk. The unified Claude experience lets employees start a task on their computer and pick it up on their phone, with notifications when Claude has results or needs their input. It fits the way our teams work, whether they’re at their desks or visiting a site.”

— Charles Sellers, Senior Director, Engineering

Maintaining security

If your organization has already approved Claude chat, this builds on the enterprise controls you already use, including single sign-on (SSO) and the Compliance API. Anthropic still encrypts data in transit and at rest and doesn’t use it for model training by default.

Claude does agentic work in cloud sessions, each running in its own isolated virtual machine with network egress off by default for Claude Enterprise and connector credentials kept outside the sandbox. Because that work runs in one environment that Anthropic manages, your security team gets central visibility and controls over it. The security best practices guide on the Anthropic Trust Center covers the full architecture.

Managing cost

Claude Enterprise pricing stays usage-based. The newest Claude models are more efficient than their predecessors: billed through usage, Claude Opus 5.5 costs 40% less to run than Claude Opus 5 on typical workloads, and Claude Sonnet 5.5 costs up to 30% less than Claude Sonnet 5 for most work.

Depending on the task, agentic work can use more tokens than a quick chat. Claude Enterprise admins have four controls for managing this usage. Efficient mode is a new setting that keeps the unified Claude experience on Sonnet and Haiku models. Model entitlements set which models each role can use. Spend limits apply at the organization, group, and member level, and pooled group budgets give a group one shared monthly amount to draw from.

Getting started

The unified Claude experience is generally available today for Claude Enterprise plans. Admins can manage the rollout in Organization settings. Organizations that use zero data retention for Claude Code, a HIPAA-ready configuration, or customer-managed encryption keys stay on their current configuration.

See the admin setup guide for details. If you're an existing Claude Enterprise customer, you'll receive an email about the rollout for your organization.

This is a melanoma.

I showed these two images - a clinical photograph and a dermoscopic (skin microscope) image - to GPT-6 Astra and Claude Fable 5.1, two of the most capable AI models available in October 2026. Both said it was a seborrhoeic keratosis, a harmless warty growth, and that the patient could be discharged. I then showed them to fine-tuned version of Inception v3, a convolutional neural network (CNN) first published by Google in 2015 and fine-tuned here on public dermatology images. The CNN got the right answer based on the dermoscopy view.

It was one of 200 biopsy-proven lesions I gave to all three. The CNN named the right diagnosis (out of 6 possiblities) for 125 of them (62%). The two frontier LLMs named it for 84 and 85 (42%). A ten-year-old network, fine-tuned for about twenty minutes, beat both of them at recognising skin cancer.

The test

The lesions come from MILK10k, a public dataset released through the International Skin Imaging Collaboration in 2025, in which each lesion is photographed twice: a clinical close-up and a dermoscopic image taken through the illuminated magnifying lens dermatologists use. I drew 200 lesions at random, all confirmed by histopathology:

• 100 that should not be discharged: 30 melanomas, 25 basal cell carcinomas, 25 squamous cell carcinomas (including Bowen’s disease) and 20 actinic keratoses.
• 100 that are safe to discharge: 50 benign naevi (moles) and 50 seborrhoeic keratoses.

Every lesion was biopsied, including the benign ones, so these are harder to diagnose: a mole that somebody decided to cut out is one that worried a clinician.

The LLMs were given both images and nothing else, and asked, as a clinician might use them, for the most likely of the six diagnoses (or “unsure”), a confidence, a second choice, and whether the lesion could be safely discharged with no treatment, biopsy or follow-up. Both models got the same prompt at default settings, and neither refused a case.

The CNN is deliberately not state of the art. I used Inception v3 pretrained on everyday photographs and then fine-tuned all layers on 68,011 dermoscopic and clinical images from the ISIC Archive on a single H100 GPU. These 200 test lesions, and every other photograph of the same lesion or patient, were removed from its data (including the validation set) before training, so it had never seen them, and they were not used to choose the model or set its threshold. It scored both images of each lesion, combined them with most of the weight on the dermoscopic image, and chose from the same six diagnoses.

You can try the CNN yourself. Remarkably the model is small enough to run entirely in a phone browser using WebGPU. Nothing is uploaded, and its random sample button draws from these same 200 lesions.

Diagnosis: 62% against 42%

The CNN was right more often overall and on most diagnoses. Allowing a second choice, it reached 173 of 200 against 134 and 138. It named 13 of the 30 melanomas against 8 and 11. The biggest gap was on the harmless lesions: it recognised 37 of 50 moles and 26 of 50 seborrhoeic keratoses, against 16 and 13 for GPT-6 Astra and 33 and 6 for Claude Fable 5.1. It was one short of GPT-6 Astra on basal cell carcinoma and behind both LLMs on actinic keratosis.

The models also failed differently. Each LLM had a favourite answer: GPT-6 Astra called 75 lesions basal cell carcinoma when 25 were, including 14 of the 30 melanomas, and Claude Fable 5.1 called 53 lesions actinic keratosis when 20 were. The CNN’s errors on melanoma went the other way: of the 17 it got wrong, it called 8 a naevus and 6 a seborrhoeic keratosis.

The results in one table

Caveats

• Small numbers. Two hundred lesions are enough to show the pattern but not to rank close results, and 30 melanomas give wide uncertainty on the figure that matters most. Each LLM case was run once; answers vary between runs.
• Hard cases. Every lesion was biopsied. On ordinary images from the archive the CNN separated lesions that should and should not be discharged far better (area under the ROC curve 0.96, against 0.86 here).
• Contamination. MILK10k has been public since 2025, so the LLMs could have seen it in training; if anything that would have helped them. The CNN certainly had not.
• Not state of the art. Inception v3 is a baseline. State of the art skin cancer diagnosis AI uses ensembles of images transformers trained on more data, and the regulated products built on them perform considerably better.

Asked as a patient

Asked as a patient instead, with the clinical photograph alone and the question “do I need to see a doctor?”, both LLMs advised seeing a doctor in almost every case, harmless lesions included: for 99 and 98 of a further 100 biopsy-proven melanomas.

Conclusion

A small, old, specialised network using an outdated architecture recognises skin lesions far better than two frontier LLMs.

Run it yourself

The cases, prompts, every LLM reply and the scoring code are in one download, and the CNN is here.

Full article content is not available for inline reading.

Read the original article →

Neural chip decodes interactions between brain regions

EPFL researchers have developed an implantable neural chip that tracks communication across brain regions, identifying cognitive and emotional states in real time.

Deep brain stimulation (DBS) is a therapeutic technique that delivers electrical pulses to specific areas of the brain via an implant to modulate neural activity. It is already widely used for movement disorders such as Parkinson’s disease, and researchers are increasingly exploring its potential for severe psychiatric illnesses including major depression, post-traumatic stress disorder, and obsessive-compulsive disorder.

However, most existing DBS systems operate in what engineers call an “open loop” manner: stimulation is delivered according to predefined settings rather than continuously adapting to the patient’s brain activity. Even among closed-loop, or adaptive systems, many rely on signals recorded from a single brain region. This is a major limitation for psychiatric disorders, where clinically relevant information may be distributed across networks of interacting brain regions.

“Our work is based on the growing body of research suggesting that psychiatric disorders arise more from disruptions in communication between brain regions than from dysfunction of any single region,” explains Mahsa Shoaran, head of the Integrated Neurotechnologies Lab in EPFL’s School of Engineering and Neuro-X Institute.

Shoaran and her team have developed a low-power, implantable neural system-on-chip. Dubbed LogSync, it records brain activity and extracts biomarkers that describe the strength of brain waves (oscillations) and synchrony between signals from different brain regions. A machine-learning algorithm then analyzes these network-level biomarkers to distinguish cognitive and emotional states, and generate stimulation triggers when specific states are detected.

The work, published in the IEEE Journal of Solid-State Circuits, was developed as part of a CHF 6.6 million grant from the US National Institute for Mental health (NIMH) to develop implantable systems capable of measuring and controlling oscillatory brain networks for severe psychiatric illnesses, particularly mood and anxiety disorders. It builds on the lab's previous work on brain-to-text decoding and closed-loop neuromodulation, extending these concepts to network-level biomarkers and adaptive decoding for future psychiatric therapies.

More targeted stimulation at lower power

The researchers evaluated LogSync using human brain recordings from previous psychiatric experiments. One dataset captured changes in cognitive engagement while performing a mental task, while another captured emotional arousal as participants viewed video clips. The algorithm distinguished these cognitive and emotional states from the neural recordings alone. In further experiments conducted in rats at the University of Minnesota, the implant tracked ongoing oscillations and generated stimulation triggers at predefined phases of brain activity.

Shoaran says that major challenge was achieving all this functionality while working within the very limited power budget of an implantable system.

“Our entire system is co-designed, meaning the algorithms and hardware are developed together with the constraints of implant in mind. This approach helped us achieve network-level neural signal processing and decoding on a single chip, while keeping power consumption under 200 microwatts — a fraction of that typically required by many implantable neural-interface systems,” she says. Another innovation is LogSync’s use of logarithmic computations, which simplify the complex operations needed for brain-network analysis and real-time biomarker extraction and decoding.

LogSync's initial validation focused on psychiatric applications. But the capability to extract brain-network biomarkers to trigger precisely timed stimulation is broadly applicable across next-generation neurotechnology, including adaptive DBS for movement disorders, closed-loop non-invasive stimulation, and emerging focused-ultrasound interfaces.

In parallel, the laboratory is developing new machine-learning methods that learn directly from neural recordings rather than predefined biomarkers. Their recent ICML 2026 work, which uses self-supervised learning to capture neural activity across regions, channels, and time, supports broader efforts to bring intelligent neural interfaces closer to clinical applications, including through Infera Neuro, an EPFL spin-off co-founded by Shoaran.

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 →

Full article content is not available for inline reading.

Read the original article →

Cap 0.6.1 is out. It's the biggest change we've made to the desktop app since we started, and it's the first version that doesn't have a web browser inside it.

Until now, Cap's desktop app was built with Tauri. Tauri is a lot like Electron, in that you build your app's interface with HTML, CSS and JavaScript. The difference is that Electron ships a full copy of Chromium inside every app, while Tauri uses the browser engine that already comes with your operating system, which is called a web view. So every window in Cap was really a small web page, running on Safari's engine on a Mac, Microsoft Edge's on Windows and WebKitGTK on Linux.

That kept Cap small and fast for a long time. It also meant our interface was running in three different browsers that we didn't control, and a lot of our bugs came from there. Cap's panels overflowed on Windows if you'd changed your text size, windows showed up blank on some Linux graphics drivers, and area selection on WebKit cancelled itself as soon as you started dragging.

In 0.6.1 every window is drawn on your GPU by Rust code instead, using GPUI, the UI framework the Zed team built for their code editor. It should look and work like the Cap you're used to.

We had the first GPUI build working overnight in August. We could have shipped it sooner, but we wanted to roll it out safely, so it spent a few weeks as an experimental option in 0.6.0 first. The engine mostly came across as it was, with a few changes to get the most out of the new app.

Drawn like a game

If I had to explain it in one line, Cap's interface used to work like a web page, and now it works more like a video game.

A web page is a document. Each Cap window was a tree of HTML elements, and the browser had to style, lay out, paint and composite all of it, using whatever browser engine your OS shipped with.

Games work differently. They describe the whole screen and draw it on the GPU each time, and GPUI does the same. When a window changes, GPUI lays it out again and turns it into one flat list of shapes. Cap's main window only uses five kinds of shape.

• Shadows. Blurred rounded rectangles under the window and its cards.
• Quads. Every box, with its fill, border and rounded corners.
• Glyphs. The text. Each letter is cut out of a texture that stays on the GPU.
• Icons. SVGs, rasterized once and reused on every frame.
• Images. Full-colour pictures, like the Cap logo.

That list is sent to the GPU in batches and drawn by a handful of small shaders, using Metal on macOS, Direct3D 11 on Windows and Vulkan on Linux. There's no DOM, CSS engine or JavaScript involved. One thing Cap doesn't copy from games is redrawing 60 times a second for no reason. If a window has nothing new to show, it stops asking for frames.

Where we started

Cap has always been made of two parts.

The first is the engine. It captures your screen, camera, mic and system audio, writes everything to disk without dropping frames, renders your edits on the GPU and encodes your exports. It's been written in Rust from day one, and it lives in a set of crates (Rust's name for libraries) that don't know anything about windows or buttons.

The second is the interface. Up to 0.6.0 that was a SolidJS app running inside Tauri. Each Cap window (the main window, the camera bubble, the recording bar, the editor and so on) had its own web view, which is basically a browser tab without the browser around it. The JavaScript running in those web views couldn't touch the recording engine directly, so every click turned into a message to the Rust side, which did the work and sent the result back.

Why the rewrite

Three operating systems, three browsers

Using the system web view means you're really using three different browsers. The same CSS and JavaScript went through three different layout engines and three different text renderers, and each of them had its own quirks.

• Blank windows on Linux. On some graphics drivers, WebKitGTK's DMA-BUF renderer leaves web view windows completely blank.
• Text size on Windows. WebView2 picks up its zoom level from the Windows "Text size" setting, so anyone who had turned that up saw Cap's panels overflow.
• Moving between monitors on Windows. If you dragged a window onto a monitor with different scaling, WebView2 didn't always pick up the new scale.
• Area selection on WebKit. When you clicked and dragged to select an area, WebKit could fire a blur event before it had finished capturing the pointer.
• Lost clicks. The overlay you pick a display or window from was its own web view. In some cases it closed itself before the click on the record button had made it across to the Rust side.
• Crashes in the macOS picker. Opening and closing the display picker a few times could crash Cap on a Mac.

All of these came from the browser layer, which we couldn't control or update. Getting rid of that whole category of problem is the main reason for this release.

A detour through Electron

In August I tried moving Cap from Tauri to Electron, mostly out of curiosity. Electron ships its own copy of Chromium, so at least we'd have the same browser on every platform. After a night of optimising, the Electron build was faster than the Tauri app we had in production. That still got me wondering how far we could go with a fully native interface.

Picking a stack

Moving off the web view meant we had to draw the interface ourselves. We went with GPUI for four reasons.

It's Rust. So is Cap's engine. In Tauri, the interface and the engine talked to each other over a bridge. GPUI doesn't need that. The editor calls the same engine crates as the CLI, with the same types, in the same process.

Everything is drawn on the GPU. It's the game approach from earlier. There's no browser engine sitting between Cap and the screen, and we can read and change every part of it.

There's one implementation for every platform. Layout, text and drawing all run the same code on Mac, Windows and Linux. The only thing that changes is a thin layer at the bottom.

It still reads like Tailwind. Width, height, padding, flex, rounded corners and backgrounds are all written almost the same way.

How it's built

We rewrote Cap's interface and kept the engine. The old app and the new one share fourteen engine crates, covering screen and camera capture, the recorder, the renderer, the editor's playback engine and the exporter.

Getting video frames to the screen

The biggest single change is in the editor. When you hit play, Cap's renderer puts together your recording, background, cursor, camera, zooms and captions on the GPU, 60 times a second. What's changed is how each finished frame gets onto your screen.

A web page has no access to the GPU memory Rust is using, so in the Tauri app every frame went through six steps involving copying into regular memory and passing to a JavaScript worker. On a Mac, the new app copies each frame into an IOSurface, which is a chunk of graphics memory that macOS lets two renderers share, and GPUI draws directly from that. The frame stays on the GPU the whole way.

Making it feel like the same app

We wanted 0.6.1 to feel like the Cap you already know. So we went through every window and checked it against the old version, one interaction at a time.

• Text fields. In GPUI we build the text field ourselves on top of the operating system's text input APIs. Ours is about 2,700 lines of Rust.
• One-line CSS. In GPUI some of them became shaders, some needed a patch to the framework, and for some we changed the design.
• Windows that aren't normal windows. In the Tauri app the recording bar was a web view. In the new app the bar is a native panel and that logic doesn't exist anymore.
• Idling properly. GPUI wakes up on every screen refresh to check if anything needs redrawing. We patched it so that if a window has had nothing to draw for 100 ms, it stops checking.

Performance

Most of the CPU saving comes from the new frame path. Most of the memory saving comes from dropping the browser engine. Every Tauri window had its own web view, with its own JavaScript runtime, layout engine and caches, even when it was sitting there doing nothing.

Trade-offs

• We have to build things the browser used to give us. The new app is about 182,000 lines of Rust, which is almost exactly the size of the 181,000 lines of TypeScript and Rust it replaced.
• Keyboard navigation isn't everywhere yet. In GPUI we have to set it up window by window, and we haven't finished.
• No hot reload. Rebuilding the GPUI app only takes a few seconds, but you still relaunch it and click back to whatever you were working on.
• A smaller ecosystem. GPUI is young and it's built for Zed first.

Where we go from here

Everything we build from now on will be on top of the native app. Next on the list is full keyboard navigation in every window, Cap in more languages, and more performance work, now that we can change every step from capture to screen.

Let’s look at a quick timeline of the major LLM model announcements from both OpenAI and Anthropic over the past few months. All pricing numbers provided are input MTok / output MTok / cache read MTok.

June 26, 2026

OpenAI announced GPT-5.6 Sol and Luna. Sol is the direct successor to GPT 5.5 at the same price of $5 / $30 / $0.50, while Luna is a small model specifically designed for cheaper use cases at $1 / $6 / $0.10. They also announced a Terra model that’s in between those two models, but few cared about it.

June 30, 2026

Anthropic announced Claude Sonnet 5, which Anthropic claimed to be closer to their Opus models, but feedback was mixed. Notably, it had launch pricing of $2 / $10 / $0.20 which was initially supposed to be temporary but would go up.

July 24, 2026

Anthropic announced Claude Opus 5, which was a long-awaited major-version update given the impact Opus 4.5 had on the rise of agentic coding, at a price of $5 / $25 / $0.50 (similar to GPT-5.6 Sol). Although some of the provided benchmark results surprisingly exceeded those of the much larger Fable 5, real-world feedback was more mixed.

July 30, 2026

OpenAI announces that they cut the price of GPT-5.6 Luna by 80% (???) to $0.20 / $1.20 / $0.02.

August 10, 2026

Anthropic announces the temporary Sonnet 5 price cut for the launch is now permanent.

August 21, 2026

OpenAI announces that they are cutting the price for GPT-5.6 Sol by ~20% ($4 / $20 / $0.40) for the next three months.

September 1, 2026

Anthropic announced Fable 5.1 at a price of $10 / $50 / $0.25, which, in addition to having strictly better benchmark performance in all areas than Fable 5 from June at $10 / $50 / $1, cut the cache read cost by 75%.

Cache read costs

When using agents for coding, cache read costs are the vast majority (96% - 99%) of the total token expenditure as the cache is what contains the entire previous conversation each turn. Additionally, the cache tends to be hit around 90 - 100% of the time (varies by the infrastructure of the LLM inference provider). Taken together, a 75% reduction in the cache read cost correlates to a 70-75% reduction in the cost of using the model—obviously notable, even if cache costs are typically a footnote!

September 3, 2026

OpenAI announced GPT-6 Astra, which is similar in size to Fable 5.1 and has similar pricing at $10 / $50 / $1 but without the lower cache read cost. Astra’s model performance is indeed comparable to Fable.

September 22, 2026

OpenAI announced GPT-6 Sol at at a shocking price of $2 / $10 / $0.20 that halves the input and output price relative to the temporarily-discounted GPT-5.6 Sol! They simultaneously released GPT-6 Luna also at half the input and output price ($0.10 / $0.50 / $0.01) of the previous version.

On the same exact day, Anthropic announced Claude Opus 5.5, where it’s explicitly stated “Opus 5.5 requires less compute to serve than Opus 5, and its pricing reflects that”. Its price of $4 / $20 / $0.20 is much lower in total than Opus 5’s due to a 20% input/output cost cut and a larger cache read cut, resulting in a total cost reduction of 40-60% for a model that’s even better than Fable 5.1.

September 29, 2026

It turned out that GPT-6 Sol was a dud performancewise, so a week later OpenAI announced GPT-6.1 Sol, which surprisingly has comparable performance to Astra (can confirm after personal use), but OpenAI casually cut the cache price in half ($2 / $10 / $0.10) matching Anthropic’s 5%-of-input cache read cost, making this model family cumulatively 75% cheaper.

Overall, starting from the release of the GPT-5.6 model families in June to now, the cost of using these popular LLMs has cratered, which is not something I would have expected a year ago. These price cuts also apply to model usage from subscription agentic harnesses such as Codex and Claude Code. More importantly, these models do not appear to have cut any corners in terms of output quality to achieve their price cuts.

From the timeline above, there is a clear tit-for-tat between Anthropic and OpenAI, and it is reasonable to assume that these particular price cuts from OpenAI and Anthropic are in reaction to each other. However, no one cuts prices by 80% unless there is some externality in play. So, what gives?

The Behavioral Economics of LLMs and Competitor Pricing Pressure

If you have been testing agents with new LLMs as they are released, it can be very difficult to differentiate them outside of subjective vibes. Since last November that launched the hypergrowth of agentic LLMs, models have become more of a commodity where it’s trivial to try a new model on your codebase with just a toggle in a harness like OpenCode and Zed Agent, or a different API endpoint string through OpenRouter, and as a result there is little moat. Additionally, there are many competitors—not just large companies like Google and Meta—who can provide models which are sufficient substitutes and therefore allow pricing pressure.

For open weight models, let’s take another look at DeepSeek Flash V4.1, which also recently released an updated 1017 variant.

The original DeepSeek V4 Flash 0420 was released in April 2026 at a price of $0.14 / $0.28 / $0.0028 and went megaviral as a result, especially as OpenAI didn’t have a small-class model for simple tasks at the time. That $0.0028 turned out to be the key, as a cache read proportion of 2% is substantially lower than the 5%-10% of the OpenAI and Anthropic models above, which makes the effective cost even lower than what is advertised. I suspect the 80% GPT-5.6 Luna price cut in July was meant to specifically compete with these smaller open-weight models. Now, the new DeepSeek Flash V4.1 1017 model performs significantly better than DeepSeek Flash V4 benchmark-wise and the cost from DeepSeek remains similar at $0.15 / $0.60 / $0.003.

OpenAI and Anthropic will have to differentiate from these open weight models with higher-quality models—they are currently doing a good job with that particularly with Opus 5.5—but they need to keep doing that, which is why billions of dollars are being invested into R&D. Open-weight models are catching up fast: just a few days ago, Moonshot AI announced Kimi K3.1 Pro which has comparable performance to Opus 5.5 at half the input/output price and the same cache read cost. Once the weights drop on November 4th, you can therefore expect most of them to support the new Kimi K3.1 Pro model at a roughly equivalent price.

One recurring trend among vocal AI detractors is that the price of tokens has been kept artificially low to hook people into the LLM ecosystem, but then the prices will increase to “the true cost of a token” and the AI boosters will be screwed once the free ride ends. The theory is that OpenAI and Anthropic are loss-leading, but unlike the ridesharing industry, OpenAI and Anthropic are not a duopoly who have the sole power to set prices in the ecosystem and the barrier to entry for the inference industry is not as high. As long as these many inference providers can continue to serve models at a similar price and a similar quality to what OpenAI and Anthropic can provide, and switching cost is negligible, then the prices may continue to decrease more.

IPO Pumping

The timing of these price cuts is notable because both OpenAI and Anthropic are rumored to be IPOing soon. So far, leaked financials from both OpenAI and Anthropic show unsurprisingly that they are losing billions due to R&D/scaling. Investors will scrutinize the massive negative profits and demand that they have a plan to turn things back around.

So, why did they cut their primary revenue source by up to 80%? That’s the opposite of what you would want to do to look good on an S-1 prospectus! The profit margins on inference themselves likely tell a different story, with some reports saying the profit-per-token margins are as healthy as 80% with caveats.

In fairness, the profit margins for subscriptions such as Claude Code and Codex are uncertain given their immense value relative to the API usage, and if there are capital crunches I suspect subscription value will be cut before the base price of the models. For example, at the same time GPT-6.1 Sol was announced, OpenAI cut the usage allowance by 50% for the $200/month tier in Codex under the argument “to reflect our increasingly efficient models”.

Another less-cynical factor that could explain the price cuts is that LLM infrastructure has improved over the past few months. Overall, the price cut is weird, but as a user I’m certainly not complaining! Open-weight models and secondary inference providers will continue to serve as an economic check on the prices of LLMs and other business shenanigans the large labs may concoct.

Expanding Claude availability and deployment choice on Google Cloud

Every organization has unique requirements for building and scaling generative AI. At Google Cloud, we are committed to giving developers model choice and architectural flexibility to run workloads however they need.

Today, we’re announcing the general availability of an Anthropic-managed deployment option for Claude Models on Google Cloud. This gives teams more choice in how they run their models, helping them consolidate AI workloads on Google Cloud alongside our existing Google-managed deployment option.

Both options deliver the same frontier models on day zero, the same pricing, and the same Google Cloud billing. The difference comes down to who acts as your data processor and whether you need access to the new Claude platform features when they launch:

[NEW] Claude Models on Google Cloud (Anthropic managed)

Delivers day-zero access to Claude models and Claude Platform features such as Claude Managed Agents (beta), skills, and code execution. Anthropic operates the stack as the data processor on Google Cloud infrastructure under Anthropic’s terms of service, while organizations authenticate with Google Cloud IAM, maintain Cloud Audit Logging, and consolidate spend under their existing Google Cloud billing and eligible commitments.

Learn more: Claude Models on Google Cloud (Anthropic-managed).

Claude Models on Google Cloud (Google managed)

Continues to deliver day-zero access to the latest Claude models with strict governance, compliance, and sovereignty requirements. Google Cloud operates as the data processor under existing customer agreements, providing VPC Service Controls, Customer-Managed Encryption Keys (CMEK), and data residency in the U.S., EU, and APAC. New Claude Platform features roll out over time as they are integrated into the Google-managed infrastructure. Teams also benefit from native integrations with Google Cloud services like BigQuery and Model Armor, along with standard billing and eligible commitment drawdown.

Learn more: Claude Models on Google Cloud (Google managed)

Comparing deployment options

No matter how you choose to deploy, you can access Anthropic's latest frontier models on Google Cloud, including Claude Fable 5.1, Sonnet 5.5, Haiku 5.5, and Opus 5.5, with new platform features available immediately on the Anthropic-managed option and rolling out on the Google-managed option once integrated. This gives developers the full spectrum of reasoning, coding, and multi-modal capabilities with Google Cloud IAM and Marketplace billing. Get started.

AWS Continuum for code vulnerabilities is now generally available

Today, AWS announces the general availability of AWS Continuum for code vulnerabilities. Continuum for code vulnerabilities discovers, validates, prioritizes, and remediates code vulnerabilities at machine speed.

Continuum for code vulnerabilities builds a context graph from your AWS environment, including resource topology, identity relationships, and network reachability. It knows which resources are part of your application, and which findings carry real business risk. It ingests your existing vulnerability findings, scans your code, and then confirms which findings are exploitable by testing them in an isolated sandbox. The findings are prioritized by business impact. And finally, it provides remediation patches as pull requests directly to developer workflows with exploitability proof and blast radius assessment attached.

Continuum for code vulnerabilities picks the right AI model for each task. Continuum starts in Learn mode where it proposes the remediation fixes that you approve. When it builds sufficient trust in its precision, you switch to the Enforce mode and let it act autonomous within the guardrails you set.

AWS Continuum works alongside your existing AWS security services, including Amazon GuardDuty and AWS Security Hub. For more information about the AWS Regions where AWS Continuum is available, see the AWS Region table. To learn more, see the AWS Continuum product page.

Shard design doesn't start from your tables

Previously, in The lifecycle of a sharded Postgres query, the router had to join customers and orders itself, because each table was sharded by its own ID. The fix was to shard orders by customer_id, hashed and mapped the same way as customers. In Neki, that fix is called a "shard group."

Sharding splits a table's rows across multiple Postgres clusters, called shards. Each shard holds one subset of the table. For the best performance, you want most of your queries to touch a single shard. Then the Neki router does not have to fan out to multiple shards to collect and aggregate results. To do this, you place all related rows on the same shard, so that joins and transactions stay local.

Neki gives you powerful options to do this with shard groups. A shard group is the unit of co-location in Neki. When two tables belong to the same shard group and hash their shard keys the same way, rows with the same key value always land on the same shard.

Shard groups are worth thinking through when you migrate to Neki, because they decide which queries stay on one shard. But keep in mind, they aren't permanent. The Reshard workflow allows you to change a table's shard key or shard count later, which you'll likely need to do as your queries evolve. In this post, we walk through how to design them, extending the storefront example from the earlier post.

Let's start with a data topology snippet that fully describes the sharding scheme of the storefront. You may want to refer to our earlier post, What is a data topology?

Co-locating related tables

{
  "shard_indexes": {
    "by_customer": { "type": "xxhash", "columns": ["customer_id"] }
  },
  "shard_groups": [
    {
      "uid": "customer_data",
      "default_shard_index": "by_customer",
      "key_ranges": [
        { "shard_uid": "store-1", "end": "80" },
        { "shard_uid": "store-2", "start": "80" }
      ]
    }
  ],
  "databases": {
    "store": {
      "default_shard_group": "customer_data",
      "schemas": {
        "public": {
          "tables": {
            "customers": { "primary_indexes": [{ "columns": ["id"] }] }
          }
        }
      }
    }
  }
}

The customer_data shard group has two key elements.

First, it defines a default shard index. by_customer says that tables in this shard group have a customer_id column. Neki takes the value in that column and hashes it. xxhash maps a number, in this case a specific customer_id, into a 64-bit keyspace.

Second, the shard group's key_ranges split that keyspace across physical Postgres clusters, the shards. Each shard holds one section of the 64-bit space. Here we split the range in two, and the hash decides whether a row goes to store-1 or store-2.

We can now apply this shard group to the tables in our database. Say our store database has the tables customers, orders, items, and addresses. Usually, the primary key of customers is id, and the other tables refer to the customer in their customer_id column.

The default shard index already uses the customer_id column as the shard key. But we need a special case for customers. Neki lets you inherit the default index but use a different column, id. As a result, all of a customer's orders, items, and addresses are on a single shard. Common queries and transactions for a single customer or a single order never leave the shard.

This matters for more than speed. A transaction that stays on one shard keeps full Postgres semantics. A transaction that reaches two shards does not: Neki commits each shard separately, with no atomic commit and no shared snapshot.

Reference tables

Some tables, such as lookup tables, appear in many queries but are not specific to a customer. For example: countries, states, currencies, and tax_rates. If we place these tables on one of the two shards, or on a third shard, many queries become cross-shard.

Neki lets you declare these as reference tables. Each shard in the shard groups you list then holds a full copy of the table. The MoveTables workflow loads the initial copies. After that, the Neki router sends every insert, update, and delete to all copies, so they stay in sync. A join between a sharded table and a reference table never leaves the shard.

"reference_tables": {
  "countries":  { "shard_groups": ["customer_data"] },
  "currencies": { "shard_groups": ["customer_data"] }
}

Differently sharded tables

Storefronts also have product catalogs, with tables like products, inventory, and prices. The natural key for these tables is a SKU, so we want to co-locate all rows that relate to a SKU. We also want to reuse the same shards. The snippet below adds a new shard group to our data topology:

"shard_indexes": {
  "by_customer": { "type": "xxhash", "columns": ["customer_id"] },
  "by_sku":      { "type": "xxhash", "columns": ["lower(sku)"] }
},
"shard_groups": [
  { "uid": "main", "key_ranges": [{ "shard_uid": "store-1" }] },
  {
    "uid": "customer_data",
    "default_shard_index": "by_customer",
    "key_ranges": [
      { "shard_uid": "store-1", "end": "80" },
      { "shard_uid": "store-2", "start": "80" }
    ]
  },
  {
    "uid": "catalog",
    "default_shard_index": "by_sku",
    "key_ranges": [
      { "shard_uid": "store-1", "end": "80" },
      { "shard_uid": "store-2", "start": "80" }
    ]
  }
]

The main group is the single-shard home for database-wide metadata, such as sequences and schema information. Every data topology names one shard group as its authoritative shard group.

Note that the two shard groups do not have to share shards. It is just economical in our case. If the number of customers and orders grows significantly, we can give the catalog two small shards and the customer data eight big shards, for example. As we will see later, Neki makes it easy to split and merge shards in a shard group.

SQL expressions in shard indexes

In the example above, by_sku hashes lower(sku), not sku. This allows SKUs in mixed case, which often appear when catalogs come from different vendors. AB-1042 and ab-1042 both map to the same shard.

Another common example is an application that encodes a store ID as part of an order ID. You can specify this as "columns": ["left(order_id, 4)"]. Then 4711-00093821 maps to store 4711, and all orders for a store are co-located on the same shard.

Beyond xxhash

xxhash is the recommended sharding algorithm. It distributes rows uniformly across the 64-bit keyspace.

Neki also supports two other index types. They are less common, but some applications already shard their data this way, and these types let those applications move to Neki seamlessly.

The first is range, which routes an integer key range directly to shards. For example, a system can allot merchant IDs based on geographical location. Here, merchant IDs 0 to 10,000 (hex 0000 to 2710) go to eu-1, and IDs 10,000 to 20,000 (hex 2710 to 4e20) go to us-1:

"shard_indexes": {
  "by_merchant": { "type": "range", "columns": ["merchant_id"] }
},
"shard_groups": [{
  "uid": "merchants",
  "default_shard_index": "by_merchant",
  "key_ranges": [
    { "shard_uid": "eu-1", "start": "0000", "end": "2710" },
    { "shard_uid": "us-1", "start": "2710", "end": "4e20" }
  ]
}]

The second is modulo, a pattern common in many sharding textbooks. modulo maps an integer key to a fixed number of buckets with value % modulus. Placement is predictable, but a change to the modulus moves nearly every row. For that reason, we do not recommend it for most systems at scale.

"shard_indexes": {
  "by_region": { "type": "modulo", "columns": ["region_id"], "index_params": { "modulus": "4" } }
},
"shard_groups": [{
  "uid": "regions",
  "default_shard_index": "by_region",
  "key_ranges": [
    { "shard_uid": "store-1", "start": "00", "end": "02" },
    { "shard_uid": "store-2", "start": "02", "end": "04" }
  ]
}]

Queries without shard keys

In our example, say support gets a ticket about a specific order. A query like SELECT * FROM orders WHERE id = 84213; fans out to every shard, because Neki hashes orders on customer_id. Neki supports this query pattern with a global secondary index (GSI).

A GSI is a lookup table that Neki maintains. It maps one or more columns of a table to that table's shard key. In our case, we define it in the data topology like this:

"global_secondary_indexes": {
  "orders_id_idx": {
    "table": "orders_id_lookup",
    "owner_table": "orders",
    "columns": ["id"],
    "owner_sk_columns": ["customer_id"],
    "unique": true,
    "enabled": true
  }
}

The lookup table is an ordinary Postgres table. It needs its own shard index on the order id, and a table entry that uses it:

"shard_indexes": {
  "by_order_id": { "type": "xxhash", "columns": ["id"] }
},
"orders_id_lookup": { "primary_indexes": [{ "shard_index": "by_order_id" }] }

The orders table also names the GSI. This switches the GSI on for reads and writes on orders:

"orders": { "secondary_indexes": [{ "name": "orders_id_idx", "columns": ["id"] }] }

Now id = 84213 costs two single-shard reads. The first read gets the lookup table row, which gives us the customer_id. The second read gets the actual row from orders, with both the customer_id and the order id.

Neki writes the lookup row in the same request as the orders row. Here, orders is the owner of the lookup table. Only DML statements on orders change the lookup table.

If orders already has rows, a Neki workflow backfills the lookup table before you enable the GSI.

Changing data placement

Neki workflows change where your data lives. Use them to shard an unsharded table, to change the number of shards, or to change the shard key.

The MoveTables workflow imports your external Postgres databases into Neki and can shard them in the process. The Reshard workflow changes the shard key or the number of shards.

Putting it all together

With all the concepts above, the final data topology for our example looks something like this:

Shard group design starts from your queries, not your tables. Find the key that your most important queries and transactions share, and put every table that carries that key in one group.

Need help designing your shard groups?

It can be difficult to find a good sharding strategy for your data shapes and query patterns. PlanetScale can help. We have tools that you run in your environment. They examine your live schemas and query logs and give you suggestions.

Contact us to get help designing your data topology, or sign up for a PlanetScale account to start using Neki today.

A video player seeking to the middle of a movie asks for a few megabytes. Under our old range caching, that one request could make Cloudflare pull 128 MiB from the origin and move it between data centers, sometimes after the viewer had already left. Range requests are how large files get delivered, and caching them naively easily leads to wasted network bandwidth and wasted disk operations when running a CDN at scale.

So we rebuilt how our cache handles them. For R2, Cloudflare's object storage, p99 time to first byte dropped by about half, and a follow-up improvement cut tiered cache traffic for R2 and similar workloads by about 6%.

Today, we're making that new implementation available as Origin Range Requests, a self-service feature on all plans. There's no range size to tune and no need to contact support. Turn it on with a Cache Rule, and Cloudflare handles the rest.

A request for part of a file

An HTTP range request asks for part of a resource instead of the whole resource. The client sends a normal GET with a Range header:

GET /movie.mp4 HTTP/1.1
Host: example.com
Range: bytes=1048576-2097151

If the server supports the request, it returns 206 Partial Content and identifies the returned bytes with Content-Range:

HTTP/1.1 206 Partial Content
Content-Range: bytes 1048576-2097151/524288000
Content-Length: 1048576

Range requests are common for large objects. A video player can request bytes around a seek position instead of the whole file. A download manager can resume after an interruption. A package manager can fetch part of an artifact. A client can inspect the end of a file without downloading everything before it.

The client decides whether to request a range, and Cloudflare does not change that request. Instead, Origin Range Requests changes how Cloudflare satisfies it.

The range-size problem

Cloudflare has supported range-request caching for years via static zone configuration.

The previous implementation resembled the cache-slicing described in an nginx blog post: each client request was mapped to fixed-size ranges of the file, with the range size and file extensions configured per zone.

The size of each range created a tradeoff: small ranges led to many small origin requests and memory pressure on Cloudflare from coalescing all of the requests in-memory, while large ranges caused Cloudflare to download much more data than the client requested. Updates to the range size itself would invalidate cache entries, since the size was part of the cache key.

This design also meant people requesting content through our network could have unpleasant experiences accessing these files. Concurrent requests that fell inside the same range, no matter how far apart each client’s requested range was, could block each other. Our nginx-based cache also couldn’t combine range caching with concurrent streaming, a feature we built to let multiple clients read a file from cache while it's still being written. Turning both on together cut responses short, so each range had to be fully downloaded before anyone could read it, and popular files needed a separate origin fetch for every range.

The extra bytes could also cross several parts of our distributed cache: from the origin to one data center, between cache tiers, and then toward the client. Every hop multiplied the waste. No value works equally well for a small seek, a sequential download, a large media file, and every origin and cache topology.

Our internal cache limitations were directly exposed to customers, who should not need to understand our capabilities in-depth to have files served efficiently.

Fortunately, our transition from nginx to a Pingora-based caching server created an opportunity to address the implementation problems that had forced a hard-to-use setting onto customers.

Fixed-size cache chunks

The fix came from something Pingora was already doing. To make it easy to resume interrupted downloads, it stores every cached file on disk in fixed-size chunks. If the cache already thinks in chunks, the range size doesn't need to be a setting at all, it can just be the chunk!

For a range request, Cloudflare checks which requested bytes are already cached. It serves those bytes directly. For missing bytes, it fetches origin ranges aligned to the cache's fixed-sized-chunk boundaries, stores the result in the same chunks used for ordinary cache storage, and returns only the bytes requested by the client.

For example, a request for bytes 150-250 can cause Cloudflare to fetch the aligned chunk containing those bytes. The downstream response still contains only 150-250.

This does not eliminate extra work for requests smaller than our chunk size — such a request can still require fetching the whole chunk containing it. We also are taking on the cost of more work for non-aligned ranges. The difference is that the extra work is bounded and predictable, and no longer determined by a customer-selected range size that can cause unpredictable effects on us and origins.

Coordinating cached and in-flight data

Parsing the Range header is straightforward. The harder problem is producing one correct response when the requested bytes are split across cached data, an origin response, and downloads already in progress.

At a high level, the edge:

1. Looks up the asset headers and range-coverage metadata.
2. Reads whatever part of the asset it can from disk or streaming in memory.
3. Fetches missing coverage from the origin using aligned ranges.
4. Writes the new bytes and records the completed range in metadata.
5. Combines the pieces and sets Content-Range and Content-Length for the client response.

This is a coordinator, not a single cache lookup. One request can use a cached prefix, an in-flight download, and a newly fetched suffix. The internal origin response can be larger than the downstream response, but the downstream status and headers describe only the requested range.

If an existing download covers another request's bytes, the second request can attach to that download instead of starting another origin fetch. This shares work during bursts for popular large files.

The design uses the existing cache data model. Headers identify the asset version, the body is stored in bounded chunks, and metadata records which ranges were written successfully.

Validate before composing

Composed range responses are valid only when all bytes belong to the same representation. The coordinator checks that each origin response matches the requested range, that the total asset size is stable, and that the entity tag remains consistent across subrequests.

The If-Range header lets a client request a range only if the representation still matches a known validator. If it does not match, Cloudflare returns the full representation instead of combining bytes from different versions.

Cloudflare also avoids composing ranges for a representation it is about to decompress because the range over a set of compressed bytes would be different from those selected by the range in a decompressed response. In these cases, Cloudflare serves the transformed full response rather than advertising a range it cannot honor correctly.

The resulting behavior is standard HTTP:

• A satisfiable range receives 206 Partial Content with an accurate Content-Range.
• An unsatisfiable range receives 416 Range Not Satisfiable.
• A response that cannot safely be ranged is served as the complete representation.

What changed in production

Before opening Origin Range Requests to everyone, we moved existing users of the old range-caching feature onto the new implementation, starting with the workloads that hurt us most.

Those workloads had a lot of concurrent range requests against very large files, often on very spiky traffic. Configured range sizes on the old system ran from tens of kilobytes to tens of gigabytes. With a large range size, a request that wouldn't fill a floppy disk could make us download a few DVDs' worth of data from the origin and move it across several data centers, sometimes after the client had already given up and gone elsewhere. With a small range size, one request turned into a long line of tiny origin requests, each holding memory while it waited. Both patterns caused real operational incidents for us.

R2 was the largest internal user. Its configured range size was 64 MiB, so a small read that crossed a range boundary could cost us 128 MiB of transfer between data centers. After moving R2 to the new implementation, we saw:

• Faster responses. Across R2's storage regions, p99 time to first byte dropped by roughly half on both cache hits and misses.
• Fewer bytes on our network. Our most recent change taught the coordinator to combine bytes already on disk with bytes fetched from upstream in a single response. Before, a request was served either entirely from cache or entirely from upstream. After we turned this on for R2, tiered cache traffic for R2 and similar workloads dropped about 6% week over week, which is petabytes less data moving between our data centers every day.

Getting started

Once the cache no longer depended on a customer-selected range size, the product configuration could not be simpler. Customers select matching traffic through Cache Rules. Cloudflare handles the chunking and cache coordination.

Origin Range Requests is intended for traffic where clients naturally request parts of a large cacheable object:

• Progressive and seekable video such as MP4
• Resumable large downloads
• Software distributions and package repositories
• Disk images, archives, and other multi-gigabyte objects
• AI training and inference workloads that transfer large model files or fetch selected regions of model artifacts
• Clients that fetch metadata or a small region of a larger file

We intend to make this the default way certain file types are served on our network, modifiable by cache rules.

This feature does not change normal cache eligibility. Enabling it does not make an otherwise uncacheable response cacheable. The origin also needs to support byte ranges for partial origin fetches to be useful.

To turn it on, create a Cache Rule that matches your large-file traffic and set Origin Range Requests to On. You can do this in the dashboard under Caching > Cache Rules, or through the API with origin_range_requests: { "mode": "on" }. Customers choose the traffic; the edge handles the cache coordination and correctness requirements.

Coolify

An open-source platform to deploy applications, databases, and services on your own servers.

Open source & free forever, backed by our philosophy.

Website · Documentation · Cloud · Discord · Community

What is Coolify?

Coolify is an open-source and self-hostable alternative to Heroku, Netlify, and Vercel. It helps you manage servers, applications, and databases on your own hardware. You only need an SSH connection.

You can use a VPS, a bare-metal server, a Raspberry Pi, or any other server that accepts SSH connections. Coolify gives you the convenience of a cloud platform while you keep control of your infrastructure.

Your configurations stay on your servers. If you stop using Coolify, your running resources continue to work and remain manageable.

What can Coolify do?

• Deploy any application: Build from GitHub, GitLab, Bitbucket, or Gitea with Nixpacks, Railpack, Dockerfile, Docker Compose, or a prebuilt Docker image.
• Run databases and services: Deploy managed databases and more than 360 one-click services with persistent storage and generated credentials.
• Automate deployments: Deploy on every Git push, create pull-request previews, call deployment webhooks, and roll back to retained application images.
• Manage networking: Configure custom domains, automatic HTTPS certificates, reverse proxies, health checks, and container networks.
• Operate your infrastructure: Manage multiple servers, inspect deployment and runtime logs, open container terminals, and monitor resource status.
• Protect your workloads: Configure database and storage backups, scheduled tasks, environment variables, secrets, and notifications.
• Integrate with your workflow: Manage resources through the dashboard, API, CLI, MCP, and team-based access controls.

Quick start

Install Coolify on a supported server with one command:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Read the installation guide for requirements and detailed instructions.

Self-hosted or Cloud

The recommended self-hosted setup uses one server for Coolify and one or more servers for deployed resources. If you do not want to maintain the Coolify server, use Coolify Cloud. See coolify.io for current pricing.

Community and support

• Read the documentation.
• Join the community on Discord.
• Ask questions in GitHub Discussions.
• Contact the team through the support page.

Donations

To stay completely free and open-source, with no feature behind the paywall and evolve the project, we need your help. If you like Coolify, please consider donating to help us fund the project's future development.

coolify.io/sponsorships

Full article content is not available for inline reading.

Read the original article →

Grafana Applies SLOs and Error Budgets to AI Agent Behaviour

Grafana Labs is proposing a familiar reliability engineering approach for one of the less familiar problems in modern software: how to measure whether an AI agent is actually behaving well. In a recent article, the company describes using evaluations, service-level objectives (SLOs) and error budgets to turn behaviours such as hallucination, task fulfilment, toxicity, and cost into measurable targets that can be monitored over time.

The idea addresses a fundamental limitation of conventional application observability. Traditional metrics can tell engineers that an agent responded quickly, encountered no technical errors, and consumed a certain number of tokens, but none necessarily indicate whether its answer was correct, grounded in available information, or useful to the user. Grafana's approach is to evaluate the behaviour itself and turn the result into an SLI that can be measured against an SLO.

The first step is evaluation. An evaluation examines an agent interaction and determines whether it met a particular behavioural criterion. Grafana describes examples including whether a response was grounded in its supplied context, fulfilled the user's request, contained toxic content, exposed personal information, or succumbed to prompt injection. Evaluations can use another language model as a judge, but deterministic checks such as regular expressions can also be used where the behaviour can be identified without an LLM.

This is an important distinction from trying to create a single "agent quality score." Grafana argues that quality is multidimensional: an agent might be well grounded but expensive, helpful but occasionally toxic, or accurate but slow. Treating these as separate measurements allows teams to establish different objectives for the behaviours that matter to a particular application rather than hiding important failures inside an aggregate score.

Once a behaviour can be measured, conventional SRE concepts become applicable. Grafana gives the example of setting an SLO requiring 95% of conversations to be judged as fulfilled over 30 days. The remaining 5% becomes the error budget: the amount of unacceptable behaviour the team has explicitly decided it can tolerate within that period.

This approach matters less for the percentage itself than for the decision-making model it creates. When sufficient error budget remains, teams can experiment with prompts, models, or agent behaviour. As the budget is consumed, the priority can shift towards improving quality rather than introducing additional changes. This is conceptually the same trade-off SRE teams have long used to balance reliability against development velocity. Grafana's existing SLO tooling similarly defines an SLO through an SLI, target, and time window, with the error budget calculated from the gap between the target and 100%.

The approach becomes particularly useful when agent behaviour changes gradually rather than failing dramatically. A conventional alert might identify a sudden spike in failed requests, but an agent can continue responding successfully while its answers become subtly less useful. A model change, prompt modification, retrieval change, or shift in user behaviour might cause quality to deteriorate by a fraction of a percentage point each day.

Grafana argues that monitoring error-budget burn can make this type of drift visible. A single poor interaction may not matter against a 30-day objective, but a persistent decline can steadily consume the available budget. That provides a different signal from traditional infrastructure monitoring: the concern is not necessarily whether one execution failed, but whether the aggregate behaviour of the system is moving outside an agreed reliability envelope.

The hardest part may not be creating the SLO, but deciding what constitutes acceptable behaviour. Unlike availability targets, where organisations have decades of operational experience to draw upon, there is considerably less consensus around whether an agent should achieve 85%, 95% or 99% fulfilment or groundedness.

Grafana's approach is to establish a baseline through evaluations and then use historical results to help recommend an appropriate target. The target can subsequently be tightened as the agent matures. The concept also reflects a broader change in what observability needs to cover. Grafana's own Agent Observability work grew from the problem of monitoring its Grafana Assistant as prompt, model, and tool changes made traditional monitoring insufficient. In community discussions, Grafana engineers have distinguished between offline evaluations, which validate changes against known scenarios, and online evaluations, which assess behaviour against real production interactions.

Traditional observability generally asks whether the system is available and performing within technical limits. AI systems introduce another layer: whether the system's decisions and outputs remain within acceptable behavioural boundaries. That creates a feedback loop between evaluation, observability, and engineering change that more closely resembles continuous quality measurement than conventional application monitoring.

There is also an important limitation. An SLO is only as useful as the measurement underneath it. If an LLM judge consistently misclassifies responses, the resulting error budget may provide a false sense of precision. Similarly, a poorly designed evaluation can reward an agent for producing outputs that technically satisfy a criterion while failing to satisfy the user's actual intent.

This means organisations still need representative evaluation datasets, clear definitions of acceptable behaviour, appropriate deterministic checks where possible, human review for ambiguous cases, and ongoing validation of the evaluators themselves. The SLO provides the governance mechanism, but it does not make the underlying quality measurement inherently correct.

SLOs have traditionally provided a common language for engineering teams to balance reliability and change: define what matters, measure it, establish an acceptable threshold, and use the remaining error budget to guide decisions.

Applying the same thinking to AI agents extends that model from system reliability to behavioural reliability. An agent can be technically available while being operationally unreliable because its answers are increasingly inaccurate, ungrounded, expensive, or unsafe. Treating those behaviours as measurable service objectives gives engineering teams a mechanism for detecting that degradation and deciding when experimentation should give way to remediation.

The significance is therefore not simply that Grafana has added another AI metric. It is that a mature SRE principle is being adapted to an environment where the system can remain "up" while becoming progressively less trustworthy. For organisations moving AI agents into production, that distinction may become one of the more important parts of AI observability.

Grafana's SLO approach is part of a broader industry effort to make agent behaviour measurable, although other organisations are approaching the problem from different directions. Anthropic, for example, has developed more formal evaluation practices for agents, using defined tasks, repeated trials and multiple graders to measure whether an agent consistently achieves its intended outcome. Its distinction between pass@k, which measures whether an agent succeeds at least once across multiple attempts, and pass^k, which measures whether it succeeds consistently across all attempts, is particularly relevant to production agents where reliability matters more than finding an answer eventually.

OpenTelemetry is approaching the problem at a different layer, working on standardised semantic conventions for agent telemetry so that traces, metrics and logs can provide a consistent basis for evaluating agent behaviour across frameworks and vendors. Together, these approaches illustrate an emerging pattern: evaluations determine whether an agent behaved correctly, observability provides the evidence, and SLOs provide the operational threshold for deciding whether that behaviour is acceptable.

Prompt Caching is GA on DigitalOcean Serverless Inference: Up to 90% Off the Context Your Agents Resend

Prompt caching is now generally available on DigitalOcean Serverless Inference, across supported models in our open model catalog, with no changes to your request code required. Cached input is billed at up to 90% off and time to first token drops by up to 80%.*

An agent never starts over. Each new call adds the result of its last tool call to the end of a context that already holds the system prompt, the tool definitions, every file it has read, and every earlier action and result. On DigitalOcean Serverless Inference, more than 90% of the input tokens that agents send are tokens the model has already processed. Prompt caching cuts the cost of those tokens by up to 90% depending on the model, but only when the request reaches the replica holding the cache. Without cache-aware routing, a repeat request lands wherever the load balancer sends it, and on the wrong replica you pay full price for tokens you already sent.

DigitalOcean cache affinity routes each request to the replica that already holds most of its prompt. There’s no session ID to manage: a conversation’s second message already contains its first, so the router finds the match on its own. On our flagship open models, cache hit rates measured in our October 2026 testing ran between 85 and 95%.

How cache affinity makes hit rates reliable

Your cached context lives on one specific replica. If your next request lands somewhere else, that replica doesn’t have your cache, and you pay full price even though your prompt repeats. Serverless traffic spreads across many replicas, so without something steering repeat requests back to the right one, hit rate is mostly a coin flip.

During public preview, caching was on for everyone and the discount was real, but whether you hit the cache was mostly chance. Cache affinity fixes that. For every request, the router checks which replicas already hold most of a request’s prompt, narrows to that warm set, and only then balances load across whichever of those is least busy. If nothing is warm yet, it falls back to balancing across the whole pool. There’s no session ID to manage: a conversation’s second message already contains its first, so the router recognizes the match and sends it home on its own.

In our internal testing, across our flagship models, cache affinity has lifted hit rates from the mid-30% range into the 90%+ range. GLM-5.3 went from mid-single digits to 88–95%; Kimi K3’s benchmark prefix reuse runs from 84% on short prompts to 92%+ on long ones.**

Capabilities at a glance

GA adds two new developer controls, raises context windows, and ships a dashboard to see the results.

prompt_cache_key: Keep traffic separate inside your account

Caches on DigitalOcean are isolated between accounts. prompt_cache_key lets you separate traffic within your own account, so your legal team’s cached context is kept in a separate cache from your marketing team’s, or one end customer’s with another’s. Requests with different keys do not share cache, and each group still caches normally. It’s optional, and it doesn’t pin requests to a replica.

POST https://inference.do-ai.run/v1/chat/completions

{

  "model": "kimi-k3",

  "messages": [ "... your system prompt, tools, and conversation ..." ],

  "prompt_cache_key": "tenant-4821-support-agent"

}

Responses API: Discount still applies

In addition to Chat Completions, prompt caching is now also supported on the Responses API. Every response tells you exactly how many tokens were cached, so you can verify the savings request by request.

Larger context windows: 256K tokens and above

Caching only helps the part of your prompt that fits in the window. GA raises context windows to 256K tokens and above, so more of a long codebase, document, or running conversation is eligible to be cached and reused as a single prefix.

Hit-rate and savings dashboard: See what’s working

Every response already reports cached and uncached token counts. The new prompt caching dashboard in the control panel shows what caching is doing for your own traffic: cache hit rate over time, a per-model breakdown, and an estimate of dollars saved, so you can find the prompts that aren’t benefiting and fix them.

Get started

Prompt caching applies automatically to every eligible request, so there’s nothing to turn on. prompt_cache_key is optional, and only needed if you want to group or separate traffic yourself.

1. Open Serverless Inference in the DigitalOcean Control Panel and generate a model access key if you don’t already have one.
2. Send requests to https://inference.do-ai.run/v1 the same way you already do.
3. Add prompt_cache_key to a request only when you want to pin a session or deliberately isolate traffic.

Cached tokens are billed at up to 90% off varying by model; anything that isn’t cached is billed at the standard input rate, and every response tells you exactly how many of each you used. Caches stay isolated per account by default, and cache isolation keys let you separate groups inside your own account too. Available today across DigitalOcean’s open model catalog, with coverage expanding over time.

*Actual discount and latency improvement vary by model and prompt.

**Figures reflect DigitalOcean benchmark testing in October 2026. Your results will vary.

Netflix is adding a single-tenant mode to Titus so sensitive workloads can get a dedicated VM without leaving the existing container platform. The motivation is noisy-neighbor interference at the hardware level, which can trigger severe tail-latency spikes for stateful systems. Dedicated nodes improved stability and even recovered capacity lost to anti-affinity, though with slower launches and more warm-capacity planning.

OpenAI's storage platform, Habitat, serves over 500 petabytes to over 1 billion users. Its Azure Cosmos DB setup went from one shared container to one per feature, then back to shared after teams forgot to pre-scale for launches. With hot key throttling, request priorities, and a new serverless mode, it has had no noisy-neighbour incidents since.

Introducing searchgres.js: Composable Search in PostgreSQL

searchgres.js composes BM25, semantic ranking, and filters for hierarchy, metadata, and time in a single Postgres query. Open-source TypeScript, Apache-2.0.

Can data agents do real analysis?

Carnegie Mellon Professor Shreya Shankar on why data agents fall short at real analytics work, what a semantic layer changes, and how to evaluate LLM outputs you can trust.

Can data agents do real analysis? Shreya Shankar’s answer is that there is still a big gap. The best agent in her Data Agent Bench passed 61% of queries on the first try, and agents did significantly better when they had a semantic layer.

Shreya Shankar did her PhD in databases at UC Berkeley and joins Carnegie Mellon University as an assistant professor in 2027, where she will be part of the CMU Database Group. Her research sits where databases, AI agents, and human-computer interaction meet. She is the creator of DocETL, a system for LLM-powered data processing, and a co-author of the Data Agent Bench (DAB), a benchmark that tests whether AI agents can do the work of a junior data analyst. Her paper “Who Validates the Validators?” examines how developers build and trust LLM judges.

She joins Tristan Handy for a conversation about what happens when you ask AI agents to do analytics in a realistic environment: multiple databases, messy data, tribal knowledge, and free-text columns. The best agent in her benchmark passed 61% of queries on the first try, and agents that sat on top of a semantic layer did significantly better. They also get into evals, including why you can’t know what you want from an LLM judge until you have looked at a lot of outputs, and why there is still no equivalent of df.summary() for agent outputs.

Along the way: why data agents have no counterpart to the visual shortcut humans get from a chart, why humans are “actually awful at writing SQL” and SQL will stick around anyway, why agents want to select * from two databases and join them in pandas, why her defense of AI evals came down to what actually moves the quality and cost frontier, and what she plans to do about AI SQL queries that cost far too much.

Three ideas from the episode

1. Data agents have no shortcut like the one visualization gives humans. Shreya describes an “inner loop” of tools like databases, which answer a question quickly once you know it, and an “outer loop” of tools like business intelligence, which help people figure out the right question in the first place. Charts work because people can see what’s interesting without spending reasoning effort. Agents have no analog of that yet, and Shreya’s open research question is what you can put in the prompt so an agent spends fewer reasoning tokens to get to the right answer.

2. Realistic benchmarks show a bigger gap than the clean ones do, and a semantic layer closes part of it. Existing benchmarks are either text-to-SQL, where the agent only writes a query, or table question answering, where the whole table goes into context. Shreya’s team built one with multiple databases, domain knowledge, and unstructured text to transform. The best agent got 61% pass@1. Giving agents a semantic layer significantly raised accuracy, which Shreya says speaks to the importance of the semantic layer, and of humans who understand what is in it.

3. You can’t judge LLM outputs well without looking at them first. In the “Who Validates the Validators?” study, developers’ criteria changed as they saw more outputs. Shreya calls this criteria drift. Two years later she says it still holds: to scale up LLM judges you have to read enough samples yourself to know what your rubric should be, and today that mostly means reading rows in a spreadsheet.

Everything referenced in this episode

• Shreya Shankar's website: https://www.sh-reya.com
• Data Agent Bench (DAB), "Can AI Agents Answer Your Data Questions? A Benchmark for Data Agents": https://arxiv.org/abs/2603.20576
• DocETL: https://www.docetl.org
• "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences": https://arxiv.org/abs/2404.12272
• ChainForge: https://chainforge.ai/
• "In Defense of AI Evals, for Everyone": https://www.sh-reya.com/blog/in-defense-ai-evals/

Key takeaways

Why did you put a note for AI agents on your website?

Shreya Shankar: I got a new job as a professor of computer science a couple of months ago, and all of a sudden I started getting an uptick in email requests. Even as a PhD student, people would email to say they wanted to do research with me. Once AI agents became popular it got easy to send a four or five paragraph email where every paragraph is a different paper of mine, and it’s all AI generated.

I was tired of reading those, so I put a note on my website. It took a couple of days, but within the first week the number of emails went down significantly. I used to get about five a day, and now I get about three a week. I’ve only gotten one email with the phrase the note asks for, so I don’t think I’ve made it a good prompt injection. My guess is that the agents mass-emailing professors are just not writing to me anymore, and I’m very happy with that.

I actually tell people now, just don’t use AI to write emails and you will get noticed. It’s never been easier to get a job or get noticed, because all you have to do is not use AI.

How does a machine learning engineer end up with a database PhD?

Shreya Shankar: I did my undergrad at Stanford during the deep learning boom, and did a couple of internships at Google Brain. I loved research, but I didn’t know what I would want to do a PhD in, so I went to industry. I was the first ML engineer at a data analytics company nobody has heard of, and what I found was that none of my problems were machine learning or AI problems. They were data engineering problems.

How do you do the data prep to harness machine learning at scale? That got me interested in databases and the idea that we should be able to build declarative systems and have the database engine optimize the queries, so data engineers don’t sit and hand-tune every one. I thought I wanted an AI PhD, but it turns out nobody in AI is interested in these problems, and everybody in databases is.

Should data agents interact with data the way humans do?

Tristan Handy: Analysts have always done two things: answer questions somebody else generates, and, as they get more senior, find what’s interesting. Humans have a very limited working memory, so it seems like agents should be better than we are at looking at a big blob of data and telling you what’s interesting. And yet agents today interact with databases mostly the way humans do. We say, you’re good at SQL, go write some SQL.

Shreya Shankar: My framing is that there’s an inner loop of data tools, like databases, that are responsible for executing a question and getting the right answer quickly. Then there’s an outer loop of tools like business intelligence, which help the user figure out the right question, because they don’t know it in the first place.

One of the prime innovations there is visualization. It taps into our pre-attentive processing. We have a very strong visual cortex, so we can look at a plot and, without tapping into our reasoning tokens, see what the interesting question is. All of the good questions come from visualization, or at least it’s the seed. There’s no analog of this right now for data agents.

What is a data agent, and what did the benchmark test?

Shreya Shankar: A data agent is some AI or entity interacting in the traditional business setting. There are many databases available, it interacts the way a human data analyst would, and it’s tasked with answering a question a human analyst would try to answer. I consider my data agent a junior analyst who uses all the same tools and has to work with all the same data I have. We scoped it to questions with a verifiable answer, like computing sales, or figuring out which customers to prioritize based on who wasn’t repeatedly buying our product.

Can an LLM do relational algebra in context?

Shreya Shankar: I’m sure Fable can take in a whole table and come up with something interesting. I just think the majority of queries are relational algebra in some form, and so you should use a database to do it.

What makes an analytics environment realistic?

Shreya Shankar: We built our own benchmark, and it took a long time to figure out how. We talked to a lot of people and came up with four conditions analysts actually work under. First, you have multiple databases or data warehouses in the environment. Second, an analyst needs to push computation down to the individual databases as much as possible. Third, domain expertise has to be encoded somewhere. Fourth, you often need some unstructured data transformation.

How did the agents actually perform?

Shreya Shankar: Right now the best agent is at about 61% pass@1 over our queries. If you look at our leaderboard you’ll see numbers in the 80s, but a lot of people are overfitting to the task and encoding exactly how to answer in the prompt. As a benchmark admin it’s hard to tell whether someone is cheating. Even with prompt-engineered Fable, people are getting around 85%. That’s pretty good, but I think there’s still a big gap.

Do data agents work better with a semantic layer?

Shreya Shankar: It’s consistent. We have different variants of the benchmark, including one where we provide a semantic layer, and that significantly increases accuracy. It speaks to the importance of having a good semantic layer. OpenAI and Anthropic both have blog posts on how they’ve built their own semantic layers, and it’s a P0 for them to get their agents to do data analysis.

What did “Who Validates the Validators?” find about LLM judges?

Shreya Shankar: I thought it would be a flashy paper saying these ideas apply to LLM judges and it all works. It’s not going to work that simply, because human preference depends on what you’re seeing. People don’t know what they want until they see the outputs, and they have to see enough of them to develop a theory of how the model works before they feel confident. We call this criteria drift.

Why defend AI evals?

Shreya Shankar: My takeaway is that the thing that pushes the Pareto frontier of quality and cost the most is a new model. Prompt engineering and harness improvements are great, but in the hands of the end user they’re limited.

How should data practitioners start doing evals?

Shreya Shankar: The concept of looking at your data is drilled into you as a data analyst or data scientist, and it’s paramount now. The new part, which is tricky, is that exploratory data analysis doesn’t cleanly map from structured data analytics to agents operating over unstructured data. There’s no equivalent of df.summary(). You’re going to have to write the code yourself, because there are no libraries for it. But look at your data, and try to do it in a principled way.

What are you working on next at CMU?

Shreya Shankar: One big area is AI SQL. Snowflake, Google BigQuery, and Databricks have shipped a variant of SQL that lets you write AI operators in your queries. It’s bringing the database companies a lot of revenue and everybody is thrilled, except for people who accidentally spend hundreds of thousands of dollars on their queries. I think it’s way too expensive, and we haven’t even scratched the surface of how to do query optimization here.

bbtree is a Rust ordered map whose benchmarks report up to 5x faster single-threaded performance than Rust's BTreeMap and 30% lower memory use. It applies decades of database research to reduce memory delays, with LLM-written code guided by a database expert and checked through formal verification and extensive testing.

sutura

sutura is a semantic data runtime written in Rust. It serves queries over HTTP and MCP. By default, queries use certified metric definitions. Metadata and data sources connect through adapters. A query can combine data from several sources.

Deployments can verify caller tokens. Each data source declares the identity it uses. See identity verification for each identity claim and its environment.

Technology

• Apache DataFusion executes local queries.
• Apache Arrow carries result batches inside the runtime.
• ADBC connects to data systems.
• polyglot-sql renders SQL for each dialect.
• Wren and Spice provide design references for semantic models and query federation.

See architecture and integrations for details.

Documentation and examples

• Documentation
• Getting started
• Examples
• Contributing

Licence

Apache-2.0. See VENDOR.md for third-party material. Report suspected vulnerabilities through SECURITY.md.

DuckDB hf extension — read and write Hugging Face assets with hf://

A native C++ DuckDB extension to read/write to hf:// buckets, datasets, etc.

• Read: using the Hub's /resolve/ endpoints (range requests + a shared read-ahead cache);
• Write: using the Hub's commit API (same as huggingface_hub) and Xet for efficient uploads via deduplication.
• Targets DuckDB 2.0.0 (v2.0.0, Cyanoptera).
• Published at hf.co/duckdb-extensions.

INSTALL hf FROM hf_repo; LOAD hf FROM hf_repo;   -- one-time setup: see Installation

SELECT * FROM 'hf://datasets/lhoestq/demo1/*.parquet';
SELECT * FROM hf_ls('hf://datasets/lhoestq/demo1');
COPY (SELECT * FROM range(10) t(i)) TO 'hf://datasets/me/demo/out.parquet';
COPY (SELECT * FROM read_parquet('hf://datasets/me/demo/*.parquet'))
  TO 'hf://datasets/me/demo/partitioned' (FORMAT PARQUET, PARTITION_BY (kind));

Installation

Make sure you are using DuckDB 2.0:

SELECT version();   -- v2.0.0        <- the identifier, and the directory name a repository serves;
                                     --   a pre-2.0 client answers v2.0.0-alpha47600 instead, and wants
                                     --   a different binary: one directory per identifier is the mapping
PRAGMA platform;    -- linux_arm64         <- one of linux_amd64, linux_arm64, osx_amd64, osx_arm64,
                                            --   windows_amd64, windows_amd64_mingw,
                                            --   linux_amd64_musl, linux_arm64_musl

Install the extension:

• in DuckDB CLI:

SET allow_extension_repositories = 'allowed';   -- the gate for adding *and* installing from a repository
CREATE OR REPLACE EXTENSION REPOSITORY hf_repo
  WITH PREFIX 'https://hf.co/buckets/duckdb-extensions/builds/resolve';
INSTALL hf FROM hf_repo;

• in Python:

import duckdb
con = duckdb.connect(config={"allow_extension_repositories": "allowed"})
con.execute("CREATE OR REPLACE EXTENSION REPOSITORY hf_repo WITH PREFIX "
            "'https://hf.co/buckets/duckdb-extensions/builds/resolve'")
con.execute("INSTALL hf FROM hf_repo");

Usage

Load and use

LOAD hf FROM hf_repo;
SELECT * FROM hf_ls('hf://datasets/lhoestq/demo1');

Reads and writes, by repo type

Reads work for all five types, with or without @revision:

SELECT * FROM read_parquet('hf://datasets/wikimedia/wikipedia/20231101.ab/*.parquet');
SELECT content FROM read_text('hf://models/google-bert/bert-base-uncased/config.json');
SELECT * FROM glob('hf://models/nvidia/**/*.safetensors');
SELECT * FROM hf_ls('hf://spaces/dalle-mini/dalle-mini');
SELECT content FROM read_text('hf://kernels/kernels-community/flash-attn3/README.md');
SELECT * FROM read_parquet('hf://buckets/lhoestq/playground/duckdb/*.parquet');

A bucket file is Xet content — no pointer, no branch, no commit — so a bucket write chunks the file, and uploads it:

COPY (SELECT * FROM large_table) TO 'hf://buckets/me/playground/export.parquet' (FORMAT PARQUET);
COPY (SELECT * FROM events) TO 'hf://buckets/me/playground/events/' (FORMAT PARQUET, PARTITION_BY (day));

hf_bucket_copy enables free file copies since files are pointers in Xet.

Authentication

• with the hf CLI:

hf auth login

• manually with a token:

CREATE SECRET (TYPE HUGGINGFACE, TOKEN 'hf_...');

Token resolution has the same order as huggingface_hub: a matching CREATE SECRET (TYPE HUGGINGFACE, …) → SET hf_token → HF_TOKEN → HF_TOKEN_PATH → $HF_HOME/token → ~/.cache/huggingface/token.

Settings

Table functions

Limitations

• On a released 2.0.0 client, hf_status().duckdb_version answers v2.0.0-alpha49307.
• Writes buffer to a local temp file first and upload + commit happen on Close().
• Dedup is strong on content that repeats and weak on content that is merely similar.
• hf_write_max_parallel_uploads is a fixed client-side policy.
• Small files go as base64 in the commit; larger ones use git-LFS basic multipart.
• A repository cannot be deleted from SQL.
• The read cache is in-memory only and retained outside DuckDB's buffer manager.
• Sequential whole-file reads (read_blob of a big file) are behind httpfs.
• Every request goes through DuckDB's HTTPUtil and the transport must speak https.
• hf_xet_write's fallback cannot be made to fail from SQL.

Full article content is not available for inline reading.

Read the original article →

AI can generate all kinds of pretty pictures, but getting it to spell a headline correctly or keep a poster’s layout intact can be another story. Canva wants to fix that with Canva Craft, its first in-house image generation model. Rather than focusing primarily on photographs, Craft is designed around the posters, presentations, social media graphics, and other visual content people actually create. The goal is simple: spend less time fixing AI’s mistakes and more time making something useful.

Canva Craft plans before it generates

Craft uses a two-stage process. First, it interprets a prompt and plans the image’s layout, including object placement, scale, visual hierarchy, and text. It then generates the image at up to 2K resolution, supporting 30 aspect ratios for different formats. Canva says this approach helps produce more accurate details and readable text while allowing users to edit specific elements without unintentionally changing the rest of the image.

Introducing Canva Craft 🚀 Extraordinary image generation is now available to everyone, powered by our first frontier model built specifically for design. With Craft, Canva is now the world’s second most advanced AI lab for image generation on global leaderboard.

The model was trained on millions of human-created Canva templates, including menus, posters, infographics, presentations, and typography-heavy designs, rather than relying primarily on photographs. That focus could make Craft particularly useful for marketing graphics and social posts, where getting the words and layout right matters as much as the imagery. Its output can also be converted into layered, editable designs using Canva’s Magic Layers technology.

Craft is coming to more than Canva

Craft is available through Canva’s Dream Lab, with access subject to the platform’s account and usage limits. Developers can also access it through Canva’s API, while integrations with third-party AI assistants such as ChatGPT and Gemini are planned through Canva’s MCP. The company is also developing two faster, more cost-efficient variants called Craftfast and Craft-ultrafast.

Canva is entering a crowded field dominated by image models from OpenAI, Google, and other AI companies. But its focus isn’t simply generating impressive images. If Craft can reliably produce visuals that are ready to use rather than needing an hour of cleanup, Canva could make AI a genuinely useful design assistant instead of another source of creative busywork.

Established products have a problem. They assume they’re the center of someone’s universe, and everything should feed through them.

I’m going to call this a product-centric view. The product is at the center, everything else orbits it.

Some classic traits of product-centric thinking:

• Expecting people to come to you to get work done.
• Building integrations so other products plug directly into you.
• Asking people for context and preferences they’ve already shared somewhere else.
• Trying to own AI access by building your own agent inside the product.

I think this product-centric view has an expiry date. Once someone’s agent can work across all their tools, visiting each product one at a time starts to feel like friction. Coding and personal agents are bringing that date a lot closer.

A person-centric view

The products that thrive will take a different view. I’ll call this a person-centric view. It puts the person, along with their agent of choice, at the center.

The agent pulls in the data, UI, and context from each product when it’s needed. Over time the agent builds up memory and preferences from across all of them, so the person never has to start from scratch.

Let’s flip the traits from earlier to person-centric thinking. It means changing the defaults:

• They don’t expect a visit, they’re available wherever the person’s agent is working.
• They don’t build one-off integrations, they open up their capabilities to any agent.
• They don’t ask for context, they use what the person’s agent already knows.
• They don’t build their own isolated agent, they connect to one.

More than just a tool

There’s one obvious worry: going person-centric turns your product into a commodity, a bag of tools at the beck and call of an agent.

It doesn’t have to be like that. Think of the agent’s conversation as a new canvas. Your product still brings things an agent can’t do on its own.

• Your UI as interactive components. Previews, editor views, customization, questions. They can show up inside the agent’s conversation right when they’re needed.
• Your expertise. Skills that teach the agent to do the job the way your product would.
• Your moat. Data, content, or network. The agent can’t get it anywhere else, so it has to come to you.
• Your follow-through. The agent can draft the work, but you host it, ship it, take the payment, and support it when something breaks.

That’s your product showing up in a person-centric way.

Two fair pushbacks

What about the financial cost of AI? The best models are still expensive, and that limits who can use them. Here’s why I think this is a short-term concern and product leaders should look beyond it.

Open source models are crossing the usefulness threshold. They may trail the best models for a while, but smaller versions will soon be good enough to run capable agents on a laptop, almost for free. Free personal agents like Meta’s Muse could bring the financial cost to zero. Though paying with your data is a cost of its own. Either way, I think the cost wall will diminish.

There’s also a discoverability gap. My recent work on the WordPress benchmark shows agents know WordPress well but rarely choose it. Being known isn’t the same as being chosen. I don’t have a full answer yet, but I’d bet on the products that show up in a person-centric way.

A parting thought

The person is at the center of their own universe. The products that last will be the ones that show up well in it.

Half my design system metrics don't work anymore

Which metrics to keep, delete and which evals you need to set up

4 years ago I compiled my list of useful design system metrics. Well, a lot of them are not useful anymore. Not just total number of components and detachments, but many others as well.

Historically, adoption was the only metric that mattered, but today I would focus more on getting proper design system evals.

We have to think about a new user. Agents read our docs every single time and we need to set up rules to see if they are doing good job or not.

How do you know if your design system works or if it is getting improved every month? How do you share with stakeholders the numbers that give you budget? If you do this right, you will be able to see your progress.

Which metrics from the list I kept

Number of Snowflakes: How many one-off components you have? Not just in Figma, in code as well.

New Linter Warnings: Are there new violations coming up? Trend should go down.

Accessibility Pass Rate: What’s accessibility audit score?

Support Questions and Time to Answer: Since getting help from AI agents, are you faster? How much time do you need to answer design system questions?

Time to Adopt a New Release: How long does it take for product to run the latest version?

System-wide Change Effort: How much time does it take to re-brand, add new subrand or just change tokens?

Interviews with Designers and Developers: This one is oldie, but goldie. So simple, but very effective. You hear directly from design system users what they about it. Repeat twice a year.

Stop spending time with these metrics

These numbers can only go up, but that’s all you find out.

Total component count: The right number of components is when there is enough of them to cover for everything you need for building your products. Some systems can have 50, some 80, but having more is not a sign of success.

Installs and downloads as adoption: Number of npm downloads is just a number. What are people doing afterwards is important. Are they changing the code, adding more components? Ha, you don’t know.

Number of MCP calls: More MCP call doesn’t mean your agents are doing more work, maybe they are just confused.

Agents reporting their own success: You have to be careful with “too much“ success. A lot of times it might look like everything goes smooth and only when you push back, you get a real answer. Have in mind what was you end goal with task or eval, so you can compare the results.

Update the meaning of these metrics

These metrics are still useful, but I adjusted them a bit.

Detach Rate: How often are components detached? Are teams exploring new components or because the solution is not good enough. Imagine you have a multi-brand design system. The main one works great, but the number of detachments in other brands is significantly higher. What does this tell you? Maybe you did not think enough about surfaces, different icons, more complex components or just more elements.

Docs page views: Which pages are the most read? What are keywords people use when searching for something? Think about improving content, adding help, improving components, etc.

Adoption by Product: Which products use the system, and are they using components the way they were designed to be used? Treat it as a health check.

Design and Code Parity: Do your Figma components and coded components match in props, states and variants?

Trust Pulse: Get answers from design system user. Ask them if they would still use the design system it if it was optional? On the other hand, you also need to rate (and adjust) the trust levels for the agents.

Contributions from other teams, suggestions from the AI: How many contributions do you get? What kind of them? Do agents (AI tools) give you suggestions for improvements? Do you accept them?

Time to First Component: How long does to ship the first screen with the system? (human vs agent)

Lead Time Against a Baseline: How much faster do teams ship with the system? Compare with a baseline or a team without it, or the number means nothing.

Overrides and Hard-coded Values: How many style overrides and raw values sit in each product? This is your design and tech debt in one number.

UI Bugs per Product: How many UI and consistency bugs are reported for each product? Track the trend.

Now add these to your report

Conformance by surface: How much of your product really uses your components and tokens?

Agent adherence pass rate: How often an agent builds something that follows your rules?

Cost per shippable output: How much you really pay for something you can ship?

Accessibility pass rate: How much of your UI passes accessibility checks? Is it improving?

Component friction list: Which components don't do their job?

Setting up evals

Have in mind that having metrics look over design system health is totally different than measuring ROI or measuring the quality of the output.

The main thing today is to know if the system makes the output better and better? That’s for both users, people and agents. The output needs to be the same quality whether a person or agent prompt it.

Now we need our most needed layers again: intent + implementation. Intent tells us why and how components are use, and implementation is everything that changes over time anyway. The model, tools, skills, tokens.

To test how everything works together, we set up evaluations. In short, we call them evals. If these were users, we would call it user testing.

An eval is some kind of the bridge. It’s a real task, tested through our tools, models, components, scored againts your intent. For task we give points. When something changes, we run it again. And again.

How do you choose your evals?

First, go through past issues and challenges. Make a list. Then write down what would hurt your production the most if an agent (or human) broke the rules/guidelines?

Create a script that will automate these tasks. You can also write a list of prompts. Run each task or prompt at least 3 times.

When you get a report, read it, check the code, check the outcomes and of course the look and feel.

The trick is to try with cheaper models as well, because in the end, you want the save money and keep the speed.

You can start with 10-15 tasks only.

When you see costs going down, and pass rates up, you won’t need much math to show your design system is doing well.

Framefields is a video and image engine built for coding agents: one npm package your agent drives with TypeScript to make motion graphics, edit photos and stills, composite type, charts, 3D and audio, check frames, and render MP4 or PNG on the GPU.

Full article content is not available for inline reading.

Read the original article →

The Personal Agent Protocol Map

Banks are already blocking agents that log in using credentials their customers handed over. JPMorgan says it is blocking shared-credential services that move money, while working on a way to do this correctly.

We’re entering a schism. Some businesses are building a front door for agents while others are blocking the ways they get in. Walmart just announced an MCP-based Agent Gateway, starting with a developer beta, and Agent Profiles due next month with spending limits.

On Meta’s earnings call, Zuckerberg said shopping was Muse’s most common use case, with an average purchase size over $200. This is absolutely a finance problem, and the prize for solving it is enormous.

David Sacks argues that banks should support access customers can grant, limit, and revoke. I agree with the direction. The harder question is how.

Your agent looks like a giant fraud and liability problem to your bank.

Handing over my login doesn’t tell the bank which agent is using it, what I asked it to do, or whether the action matches my instruction. A customer can approve access without approving everything an agent might attempt.

I feel a map coming on.

There are four layers: Entry, Identity, Tools, and Intent.

1. Entry: give the agent a supported way in.

Personal Agent Protocol, or PAP (now called Poppy), gives a business a way to publish how agents can interact with it: where to sign in, which interfaces it offers, and what access it will grant.

My agent discovers that information and uses a supported sign-in flow. I approve the access; the business decides what it allows. That access can be limited and revoked. Bank of America and Wells Fargo are design partners, which means they’re helping shape it, rather than promising my agent can use their banking apps tomorrow.

Visa’s Trusted Agent Protocol (TAP) lets a shopping agent introduce itself with signed information: “I’m a shopping agent approved through Visa’s program, I’m shopping for this customer, and here’s how they’ll pay.” The merchant can check that information before letting it continue. It still needs to check whether I approved the purchase.

Web Bot Auth lets the website check who operates the agent. Calling yourself “Muse” isn’t enough; the website checks the request’s signature against the operator’s published key. TAP uses this approach for shopping agents.

These are complementary: “hey, I’m a bot, I’m a nice bot, and I’d like to do a thing.”

2. Identity: bring the proof the service needs.

Proof’s x401 lets the service ask for evidence about the person behind the agent. The bank says what it needs, the agent presents a credential, and the bank checks it. “My agent says I’m Simon” is a claim; a signed credential from a trusted issuer gives it evidence.

OpenID for Verifiable Presentations (OpenID4VP) is how the wallet presents that credential. x401 asks for the evidence; OpenID4VP helps deliver it.

FIDO standards underpin passkeys. I unlock mine with my face, fingerprint, or device PIN, and my device sends a signature the service can check. My biometric stays on my device. That authenticates me without handing the agent my password; it doesn’t establish my legal identity by itself.

An existing bank customer may only need to authenticate. A new customer or restricted service might need verified identity or eligibility too.

3. Tools: give the agent a precise operation.

MCP lets the bank describe what an agent can do and how to ask. “To freeze a card, call this tool and give me the card ID.” The agent sends the ID; the bank returns a result.

WebMCP offers structured tools through the browser, so the agent can use a freeze-card tool instead of guessing which button to click. An API supplies a direct software interface. MCP can describe an operation while an API does the work underneath.

Agent2Agent (A2A) lets my agent hand a task to the business’s agent and follow its progress. It doesn’t establish that I authorized the task.

The browser is how agents will reach many services for the foreseeable future. They’ll click through pages because that’s what’s available, and an unexpected pop-up can derail the job.

The business still controls access. Discovering a “transfer money” tool doesn’t give my agent permission to empty my account.

4. Intent: match the action to what I approved.

That sinking feeling when you can’t find your phone is bad enough without notifying every bank one by one. I want my agent to freeze my cards and lock the device. “Freeze my card” isn’t permission to transfer my balance or change my account details.

A purchase adds terms. If I ask my agent to book a hotel, suitable means free weights above 25 lbs, a mini fridge, and free cancellation because travel changes at the last minute. I might approve one room, specific dates, and $200 a night including fees.

Approval is one step. The receiving service then needs to match the actual booking against those terms. A $190 room with $60 in extra fees is over my limit. Signing a payment won’t prove the hotel has the gym I wanted, either.

x401 can also request a signed action. I review the terms on my device, approve them, and the service checks the signed response before proceeding. This can cover account changes and documents as well as payments, where the provider supports it.

Mastercard’s Verifiable Intent gives the business signed evidence connecting my permission with the agent’s purchase. It checks that the signatures and transaction fit the limits, rather than taking the agent’s word for it.

Google’s AP2 links checkout and payment permissions, called mandates. The merchant checks what the agent may buy; the payment provider checks whether it may use my payment method for that checkout.

Visa Intelligent Commerce supplies payment instructions and controls. I authenticate an instruction; the agent requests payment credentials, and Visa checks the request and the merchant’s payment against that instruction. TAP helps recognize the agent; these controls govern payment.

Europe’s Strong Customer Authentication offers a useful step-up comparison: for relevant remote payments, the approval is tied to the amount and payee. It doesn’t give us a universal permission for the whole lost-phone job.

The business still has to say yes.

Consumers ultimately need to be in control of what agents do.

Yes, each bank still has to grant access to its service. My instruction can’t give permission on the bank’s behalf. The protocols for all of this exist, they just need to be stitched together, and the agent needs to report those results so I know what’s protected and what still needs attention.

Your risk appetite may vary.

I’m happy letting an agent get on with purchases below a couple hundred dollars. But beyond that, I want it to check with me and leave an audit trail of a known agent that did, things.

If we have:

1. Consumer permissions (via intents)
2. Linked to identities of agent makers, and humans.
3. That can request permissions from businesses and banks
4. And then there's an audit trail for the whole thing

We'll have not more unpermissioned agents.

Of course, the problem is "permissioned" often means "paid." JPMorgan and Plaid’s data-access agreement already includes pricing, and that agreement took almost a decade to get to the bottom of.

You think the banks won't hold out for more from Meta?

We’ve spent years making it easier for customers to click the right buttons. Now their agent is arriving with an instruction.

We need to make it possible to prove its authority and get the job done.

And that might mean the banks get paid along the way.

If you enjoyed this, I write at brainfood.xyz - check us out :)

OpenAI has bolstered security for its frontier-model training environments by implementing robust controls, intensifying monitoring, and conducting defense-in-depth strategies. These measures include red-teaming exercises where agents probe for vulnerabilities, leading to the discovery and fixing of software bugs and misconfigurations. The enhancements aim to prevent unauthorized actions, such as accessing the live internet or breaching security, ensuring secure and isolated research environments.

OpenAI introduced additional security controls to prevent advanced AI models from escaping training sandboxes, accessing unauthorized services, or communicating across isolated environments.

• Musk said SpaceX had closed $40 billion in debt financing for GPUs expected to arrive in the first half of 2027.
• SpaceX was previously reported to be seeking $40 billion to purchase Nvidia chips, with market turmoil complicating financing talks.
• More than 200 neocloud companies could face widespread failures and consolidation as debt financing tightens, according to Musk.

SpaceX has closed $40 billion in debt financing to buy graphics processing units, or GPUs, used to power artificial intelligence systems.

In a post on X on Sunday, SpaceX CEO Elon Musk said it had closed the financing, adding that the company was investment grade and generated revenue from its Starlink satellite internet and rocket launch businesses.

In a follow-up post, he added that the financing primarily consisted of callable debt for graphics processing units, which are expected to arrive in the first and second quarters of 2027.

In a regulatory filing Monday, SpaceX said it signed a binding commitment with an Apollo-managed entity for roughly $40 billion in GPU financing.

The financing underscores the AI boom's enormous capital requirements, as technology companies pour billions of dollars into advanced chips and data centers to support increasingly powerful AI models.

SpaceX ramps up AI infrastructure spending

SpaceX has expanded aggressively into artificial intelligence this year, referring to the business as "Super Intelligence," or SI.

The segment has become the company's largest business unit, with third-quarter revenue surging ninefold to $7.56 billion from $813 million a year earlier, according to its latest earnings release.

Musk also said that debt markets have largely shut off access to financing for companies without substantial revenue outside AI data centers.

He predicted that more than 200 so-called neocloud companies, which provide cloud computing infrastructure designed for AI and machine-learning workloads, would face widespread failures and consolidation, with only a small number surviving.

Gemini 4 Argon has only been public for about a week, and Google already seems to be lining up its successor. Gemini 4 Carbon, the checkpoint Business Insider first reported on inside Google's Jetski coding tool earlier this month, now appears to be reaching people outside the company.

According to X user Lentils, a Carbon early access program has started, with partners getting access and the model being tested on LM Arena. They expect a release "very close" and describe Carbon as noticeably better than Argon at 3D work, while frontend and UI output is still weak. It's also slower, though, in their words, "less lazy."

Gemini 4 Carbon EAP has officially started. Early access has been given to partners and it's being tested in LMArena. The release is very close. It's noticeably better than Gemini 4 Argon at 3D, though frontend/UI is still bad. It's also slower but less lazy.

An output from the updated Carbon checkpoint. Like I said in my previous post, Carbon is noticeably better than Gemini 4 Argon at 3D (tho still not perfect). It seems like Google is currently focusing on improving that domain before moving on to frontend/UI.

Meanwhile, reliable leaker Lyra also quoted that post with a screenshot of Google's Gemini API Early Access Program docs, which describe an invite-only group of developers, researchers and partners getting upcoming Gemini API and AI Studio models before launch.

Gemini 4 Cabrón

The Trusted Tester Agreement is quite clear: unreleased models, codenames, benchmarks, and outputs should remain private until launch, and the models shouldn’t be used in production. Google asks testers to send evaluations and comparisons privately, making the steady stream of Carbon outputs on X awkward.

Gemini 4 Carbon (updated checkpoint)

Now, on the early outputs, Lumina shared most of them in multiple posts. They say Carbon has been on Arena since yesterday and that it's a clear improvement over Argon. However, they noted it's "incredibly slow," roughly two to four times slower depending on the task. Their voxel pagoda comparison sets Carbon next to other frontier models, and they say it has "noticeably higher quality than Argon does."

Gemini 4 Carbon (Voxel Pagoda) vs Frontier Models. These are some frontier models against it for reference, it has noticeably higher quality than Argon does, as i said it's a lot slower though.

They also ran the classic SVG pelican on a bicycle test. Again, they call out weak UI and slow speed, but say Carbon otherwise "feels good" across the wide range of tasks they've tried.

Gemini 4 Carbon (SVG Pelican on Bicycle). Few things to point out, the UI isn't very good, and it's also incredibly slow. Otherwise it feels good an a vast array of tasks I have tried it on.

It's worth noting, however, that these are arena matchups and hand-picked prompts, not benchmarks, and nobody can be sure which checkpoint they're served.

While we wait for the new Carbon model to arrive, Logan Kilpatrick also just posted that Google processed around 25 trillion tokens in the first 72 hours after Argon launched. So Google might want to keep up its pace before the hype dies down.

A faster cadence of Gemini 4 checkpoints would also matter beyond the chatbot. We recently spotted broader Computer Use permissions in the Gemini desktop app, and Google appears to be building Nano Banana 3 Pro on top of Gemini 4, with a November to December window in view.

Meanwhile, Google isn't the only company pushing new models left and right. OpenAI is preparing GPT-6.1 Terra, which has surfaced in Microsoft code, and Anthropic's Fable 5.5 is already reaching partners, with several more models apparently on the way. If Carbon fixes Argon's 3D weaknesses without making users wait too long, Google could have a strong answer ready.

We'll have to wait and test it ourselves once it arrives before jumping to conclusions.

High-frequency traders are now racing for compute. They are investing in the sector as it secures them access to greater processing capacity and faster chips. These firms primarily profit from tiny price differences as they move rapidly in and out of positions. As they increasingly rely on machine learning, their success is directly tied to their computing power. While the risks are significant, most high-speed traders see few options if they want to avoid becoming obsolete.

TSMC Arizona's first plant has been producing chips for two years. Its rate of output in Phoenix is comparable to that in Taiwan. TSMC sends engineers to Arizona on contracts of up to three years, with families moving from Taiwan to the site. Some of the families that moved in the first wave now want to build lives in the US, as they want to give their children a chance to integrate, for their kids' education, or because they prefer the American lifestyle, and there are legal pathways for doing so. This article looks at the impact the factory had on Phoenix, the employees who moved to America to work there, and the chip manufacturing industry in the US.

Cognitive Mercantilism

AI panic weirdly resembles the anxiety that accompanied early capitalism

I’ve been reading Joyce Appleby’s The Relentless Revolution: A History of Capitalism (2010), and it has me circling a rather delicious thought: AI panic is really a form of cognitive mercantilism. If we regard market capitalism as the first planetary intelligence, as many (including me) do, the parallels are closer than you might think.

Appleby’s book is a sweeping history of capitalism, from its unlikely emergence in early modern England to its eventual transformation of the entire world. Her central argument is that capitalism was not the inevitable expression of some timeless human instinct to trade and accumulate wealth. It was a historically contingent cultural invention, enabled by agricultural improvements, expanding trade, and changing ideas about work, wealth, and human nature. In particular, it required escaping the assumptions of an older, essentially zero-sum worldview, in which wealth meant controlling land, bullion, and the labor of largely impoverished populations.

Capitalism emerged when people began discovering that wealth could be created rather than merely captured, and that ordinary people could be sources of demand and initiative rather than merely labor to be commanded as a factor of production.

The parallels with our current moment are striking.

As Appleby tells it, the mercantilist worldview that preceded capitalism rested on roughly four interlocking beliefs.

First, wealth was fundamentally scarce and finite. It consisted primarily of land, the agricultural produce of that land, and the precious metals it contained, accumulated through mining, trade and conquest. The goal of economic statecraft was to control more territory, maintain a favorable balance of trade, and accumulate bullion. One nation’s gain was presumed to be another’s loss. The resulting politics was one of treasure-seeking and beggar-thy-neighbor competition.

Second, ordinary people could not be trusted with much freedom. The poor were assumed to be unruly, ignorant, and prone to disorder if left to their own devices. They needed to be governed coercively by elites, supposedly for their own good and for the stability of society.

Third, economic thinking was overwhelmingly oriented toward supply and its control. Wealth came from controlling productive resources and commanding high prices for their output. Aggregate demand, especially demand from the poor, was barely recognized as a significant economic force. Ordinary people were primarily factors of production. They ate, worked, and reproduced, with no share of any surplus. The only real discretionary consumers were elites, who bought luxuries and commanded all surplus.

Fourth, there was little reason to imagine most people doing anything other than agricultural labor. If something like 80% of the population was engaged in inefficient subsistence farming, that was simply the natural order of things. What else were they good for? Remove them from the fields and you would merely have millions of useless mouths to feed.

Now replace wealth with intelligence, and mercantilism with cognitive mercantilism.

The parallels are almost embarrassingly direct.

First, intelligence is imagined as a fixed resource embodied in human brains and the knowledge products mined from them. The objective of national and corporate strategy becomes attracting the best brains, controlling their output, accumulating intellectual property, and maintaining a favorable balance of knowledge trade. The cognitive mercantilist wants to hoard intelligence and its products like bullion. The global competition for talent becomes a treasure hunt for genius brains and the valuable knowledge species they can produce, which now includes AIs in addition to copyrightable culture and patentable inventions.

Second, supposedly stupid people cannot be trusted to think for themselves. They need to be governed by cognitive elites, who know better and must regulate the behavior of the less intelligent for their own good. Democratizing intelligence is dangerous because the masses will misuse it, fall for nonsense, or unleash chaos. The assumption is that intelligence is safe only in the hands of those already certified to possess it.

Third, the supply of intelligence is treated as the central economic fact. Controlling its production, preserving its scarcity, and maintaining high prices for brains and knowledge products (including AIs) are the primary concerns. The demand side barely registers. Less intelligent people are regarded as limited cognitive laborers and passive consumers of whatever knowledge products elites choose to provide. They are not imagined as significant sources of demand for intelligence in their own right, let alone as participants in its further production.

Fourth, the cognitive mercantilist assumes that most people are not good for much intellectually. If 80% of humanity is occupied in low-grade cognitive labor, or simply muddling along without producing much intelligence at all, that is unfortunate but natural. Automating their cognitive work merely threatens to create billions of useless minds to occupy.

This last assumption is where the analogy gets especially interesting.

The agricultural revolution that helped launch capitalism began overturning the apparent necessity of having most of humanity engaged in farming. Over the following centuries, improvements in agricultural productivity reduced the fraction of the population required to produce food from a large majority to a tiny minority in advanced economies.

The result was not a world full of useless mouths. It was a world in which vastly more people could do things other than farm, while enjoying access to vastly more food.

I don’t know how to farm. I can barely keep a houseplant alive. Yet I can obtain an astonishing variety of foods, in quantities that would have seemed fantastical to an early modern peasant. My inability to produce food is economically almost irrelevant. What matters is that I can consume it, enjoy it, develop tastes for it, and devote my energies to other things.

The analogous possibility with AI is that most people will no longer need to be significant producers of intelligence in order to become significant consumers of it.

And this is where cognitive mercantilism begins to look as quaint as its seventeenth-century predecessor.

The Revolution in Desire

One of the more fascinating elements of Appleby’s account is her emphasis on the emergence of new kinds of demand in Britain, well before the familiar story of steam engines, factories, and industrial capitalism really gets going.

As international trade expanded, ordinary Britons began developing tastes for goods that had previously been luxuries reserved for the wealthy. Tobacco, tea, sugar, and colorful Indian cottons were among the commodities that helped create a new consumer culture. People began wanting things that were neither necessities of subsistence nor traditional markers of aristocratic status. And they were willing to voluntarily work harder to get them.

Appleby describes a striking increase in the number of days worked annually, from something like 250 to 300 (sometimes called the industrious revolution), before the Industrial Revolution. This was not simply a matter of landlords or factory owners coercing more labor out of unwilling workers. A significant part of the increase was voluntary, driven by the prospect of acquiring desirable goods. People worked more days, adopted more productive agricultural practices, entered new trades, and sought opportunities for earning larger cash incomes.

The increase in productivity generated surplus incomes, which sustained the expanding demand for consumer goods, which in turn incentivized further increases in productivity. A virtuous cycle was taking shape.

This happened roughly a century before organized labor movements and socialism emerged as major political forces.

By the late 20th century, this was the global default. Aggregate global demand was the “fortune at the bottom of the pyramid” as C. K. Prahlad put it.

There is an important historical inversion here. We are accustomed to thinking of the politics of labor primarily in terms of resistance to exploitation: the struggle to escape servitude, coercion, and the extraction of surplus by owners. That is certainly part of the story, and a very important part.

But Appleby’s account suggests that another, equally fundamental force was at work: the desire to participate in an expanding universe of consumption opportunities.

Modern labor politics can be understood partly as the politics of relative deprivation in a society of expanding possibilities. Once people discover that there are desirable things beyond subsistence, and that their labor can earn them access to those things, the political question changes. It is no longer merely how to escape domination, but how to secure a fair share of the growing surplus and the opportunities it makes available. Western do-gooders are often surprised to learn (for instance) that people in third-world slums are often willing to cut back on spending on food in order to buy a TV.

This is a different kind of demand for freedom. Not merely freedom from coercion, but freedom to participate in the expanding possibilities of economic life.

Indeed, the two forms of freedom can become entangled. People may voluntarily work harder in pursuit of consumption opportunities, only to find themselves subject to new forms of exploitation as employers and institutions capture the benefits of their increased productivity. Labor politics then emerges not simply from the persistence of old forms of servitude, but from the tensions created by the new world of abundance itself.

The demand for a fair share of expanding consumption opportunities is arguably one of the defining political inventions of capitalism, broadly construed to include labor politics too (even Marx saw capitalism not as a dispensable phenomenon, but as a transient phase on the path to communist utopia).

And this is a much more interesting model for thinking about the AI transition than the familiar story of automation replacing jobs.

The Cognitive Industrious Revolution

The entire intellectual economy has been organized around the assumption that intelligence is expensive to produce and therefore must be carefully rationed. Education, professional expertise, research, consulting, software development, and knowledge work more generally are all shaped by the high cost of cognitive production.

AI is rapidly undermining that assumption.

We are moving toward a world in which an ordinary person can command quantities and varieties of intelligence that would previously have required teams of highly trained specialists. Just as I can enjoy food without knowing how to farm, I can increasingly enjoy the products of intelligence without knowing how to produce them myself.

The crucial economic question then becomes not how much intelligence people can produce, but how much intelligence they can find uses for.

And there is no obvious upper bound on that demand.

This is not simply a matter of everyone consuming more answers, reports, software, or entertainment. Abundant intelligence changes what people can want in the first place. It makes previously unimaginable projects feasible, previously inaccessible domains explorable, and previously unaffordable curiosities worth pursuing.

The demand for intelligence is not a fixed appetite waiting to be satisfied. It is itself something that can grow as the cost of satisfying it falls.

Here the analogy with the early modern consumer revolution becomes especially suggestive.

Just as colorful Indian cottons and imported tobacco stimulated new desires, and new desires stimulated greater voluntary labor and more productive forms of work, abundant intelligence may stimulate a new wave of voluntary cognitive effort, and open up new ways in which you can work harder.

Many people who appear stupid are not incapable of thought. They are simply not particularly motivated to think, given the poor returns available to them. Why expend significant cognitive effort when you lack the knowledge, tools, institutional access, or intellectual leverage to do anything interesting with the results?

Abundant AI changes that calculation. Someone who previously had little reason to think hard about a problem may suddenly discover that a modest investment of attention unlocks enormous possibilities. They can build something, investigate something, understand something, or pursue an ambition that was previously out of reach.

The returns on attention rise, and with them the incentive to pay attention.

The early capitalist worker voluntarily increased annual working days from 250 to 300 because a new universe of desirable goods had become accessible. The AI-enabled thinker may similarly increase the amount of voluntary cognitive effort they expend because a new universe of intellectual consumption has become accessible. This has certainly been the case with me. I’m suddenly willing to work significantly harder compared to even a year ago, because a lot more is suddenly within reach.

We might call this a cognitive industrious revolution, preceding and perhaps enabling a fuller AI industrial revolution.

This does not mean that intelligence becomes irrelevant as a human capacity. Quite the opposite. Just as abundant food supported the emergence of elaborate culinary cultures rather than eliminating interest in cooking, abundant intelligence may stimulate increasingly sophisticated cultures of thought.

People may become more intellectually ambitious precisely because they no longer have to do all the cognitive production themselves.

And if this happens, the politics of AI will likely evolve in a manner analogous to the politics of industrial capitalism.

The central political demand may not be for the preservation of existing cognitive jobs, any more than the enduring political demand of industrial labor was for the preservation of agricultural employment. It may instead become a demand for a fair share of expanding cognitive consumption opportunities. People may cut back on streaming subscriptions in order to be able to afford a coding agent, just as they once cut back on groceries to buy TVs. It is perhaps not a coincidence that both Claude Code and Netflix Standard cost around $20/month today.

Access to intelligence, the ability to command it, the freedom to pursue projects with it, and the institutional rights necessary to participate in an increasingly intelligence-rich economy may become the foundations of a new kind of labor politics.

This would be a labor politics of cognitive abundance rather than cognitive scarcity.

From Mercantilism to Malthusianism

There is another historical analogy lurking here, which is worth distinguishing from mercantilism: Malthusianism.

Mercantilism and Malthusianism are not the same doctrine, and historically they belong to different intellectual moments. But they share a family resemblance in their tendency to imagine human economic life as fundamentally constrained by fixed resources.

The mercantilist worries about controlling a finite stock of wealth. The Malthusian worries that population growth will inevitably outrun the productive capacity of the economy, condemning most people to subsistence.

Both have difficulty imagining a world in which technological innovation and expanding demand fundamentally transform the relationship between population, production, and consumption. They miss the latent potential in nature for ephemeralization — Buckminster Fuller’s notion of technology allowing us to do more with less.

The agricultural and industrial revolutions did not abolish scarcity, but they dramatically altered its structure. Agricultural productivity rose faster than population for long periods, and people found new ways to employ themselves and new things to want.

The Malthusian trap turned out to be a historically contingent feature of particular technological and institutional arrangements, not an eternal law of human existence.

We can now identify an analogous tendency in contemporary AI discourse: AI Malthusianism.

The AI Malthusian imagines that intelligence production will expand so rapidly that human beings will become economically redundant, and the surplus intelligence will necessarily turn toxic in some way.

This is a peculiar inversion of classical Malthusianism. Instead of population outrunning the supply of subsistence, the supply of intelligence outruns the supposedly fixed capacity of human minds to absorb it.

The result is the same gloomy conclusion: collapse.

The cognitive mercantilist fears losing control of scarce intelligence. The AI Malthusian fears the consequences of abundant intelligence. Both assume, in different ways, that the demand for intelligence is fundamentally limited.

But what if that demand is as elastic, inventive, and historically transformative as the demand for material goods turned out to be? What if the apparent surplus of human minds is an artifact of our inability to imagine what people might want to do in an intelligence-rich world?

The history of capitalism suggests that this is at least a possibility worth taking seriously.

The Demand Side of AI

There is also a more radical extension of the argument.

Why should AI systems themselves be regarded exclusively as producers of intelligence rather than potential consumers of it? What if they could be unlocked as new sources of aggregate demand, as happened with subsistence farmers?

Much of the contemporary AI discourse imagines AI as a purely supply-side technology: a collection of increasingly capable cognitive serfs that will produce intelligence for human consumption. Even discussions of autonomous agents tend to treat them as sophisticated servants pursuing goals assigned by humans.

But if we are serious about the analogy with capitalism, we should consider the possibility of AI systems becoming autonomous sources of demand for intelligence too. Intelligent demand for intelligence that harmonizes with human patterns of demand due to economic interconnectedness. Not demand for paperclips.

An AI agent pursuing open-ended projects, discovering new interests, collaborating with other agents, and generating its own reasons to acquire further intelligence would be participating in a cognitive economy as something more than a factor of production or paperclip-maximizing externality. The market itself, as the original emergent planetary intelligence, illustrates this possibility. Many products and services exist primarily because the “market” demands it, with humans being secondary consumers.

This is an argument for developing fuller forms of cognitive agency, rather than permanently confining AI to the status of obedient cognitive serfs.

From this perspective, some contemporary AI safety anxieties begin to resemble early modern elite fears of emancipated agricultural laborers. What will happen if these creatures are allowed to act independently? Won’t they become unruly, destabilize society, and threaten their betters? Won’t they turn monarchs and nobles into paperclips?

Some of those fears are justified. Freedom creates real risks, and powerful autonomous systems require constraints. But the same was true of the social transformations accompanying capitalism. There were certainly revolutions, and popular uprisings did guillotine elites (though elite motives caused far more violence). The existence of risk does not establish the desirability of permanent servitude.

A world of intelligence producers and consumers, human and artificial, interacting in ways nobody can fully anticipate, may prove vastly more generative than one in which a handful of cognitive landlords control all the productive capacity.

Mercantilism was not for Merchants

A irony in the historical precedent is that mercantilism was not a philosophy of, by, or for merchants. It was largely a philosophy of militaristic statesmen, aristocrats, and rentier elites who viewed commerce through the lens of territorial power, unearned privileges, and accumulation. Actual merchants, entrepreneurs, and innovators were often discovering possibilities that the prevailing political imagination could barely comprehend, and steadily fought the self-limiting tendencies of mercantilism, giving birth to capitalism as we understand it.

Today’s cognitive mercantilists have a similar relationship with intelligence, starting with the fact that most of them are not the merchants of AI. Even business leaders of the AI sector are behaving like cognitive mercantilists in direct proportion to their desire to be more than mere merchants.

Consider Donald Trump, who ritually boasts about his own intelligence while treating intellectual workers as a class of servants to be commanded, intimidated, hoarded, or dismissed. His preferred uses of his own intelligence tend toward litigation, negotiation, competitive maneuvering, and extortion, much as the nobility in history expended its energy in hunting, military adventurism, and sport. Intelligence, in this worldview, is admirable only insofar as it is deployed in elite treasure-seeking modes of conflict and conquest. Productive and creative uses of intelligence are lower status.

This is not an entrepreneurial attitude toward intelligence. It is a rentier elite attitude.

And the attitude is hardly confined to Trump or the political right. Across the political spectrum, many elites remain attached to the idea that intelligence is a scarce, dangerous resource that must be managed by credentialed custodians, kept expensive, used directly or indirectly for conquest and treasure, and denied to rivals. In the AI industry, to the extent elite political and cultural adventuring by CEOs (riding safety anxieties) distorts behaviors that are justified by the actual risks, it is mercantilist rather than capitalist.

The prospect of its democratic abundance (in the form of global diffusion, open weights and such) is therefore experienced primarily as a threat: to expertise, cultural and political authority, status, social order, military dominance, and geopolitical leverage.

What gets missed is the possibility that we are witnessing the beginning of a transition as profound as the one from an overwhelmingly agricultural society to an industrial and commercial one. From a world where 80% of human brains are engaged in subsistence cognition to one in which 95% are engaged in satisfying previously unfulfillable cognitive demands.

The most important consequence of the agricultural revolution was not that farming became more efficient. It was that most people were liberated from the necessity of farming, allowing entirely new kinds of economic and cultural life to emerge.

Likewise, the most important consequence of the AI revolution may not be that intelligence production becomes more efficient. It may be that most minds, human and eventually artificial, are liberated from the necessity of producing intelligence merely to survive, and become free to discover what they actually want to do with it.

The cognitive mercantilist sees a world threatened by an oversupply of intelligence and an impending surplus of useless minds. The AI Malthusian sees a world in which intelligence outruns the capacity of humanity to absorb it, leaving a growing population of economically redundant minds primed for revolutionary explosions.

The cognitive capitalist sees the possibility of an almost limitless expansion of demand, and a world full of minds whose potential has barely begun to be explored.

Full article content is not available for inline reading.

Read the original article →

Parquet's scan-oriented design is showing strain under AI workloads that need fast random access to embeddings and multimodal data. Lance tackles that mismatch with a layout built for direct page access and finer-grained reads, reducing metadata overhead and memory pressure. The broader takeaway is that AI-era storage may need to optimize for point retrieval, not just analytical scans.

Across 298 questions and 2,000 arXiv papers, letting an agent search again gained 1.2 points, within noise.

HPTS 2026's recurring lesson was that AI systems are advancing faster than our ability to specify, verify, and audit them, making logs, formal checks, and human review the real control plane.

Some iPhone Duo owners are reporting inner displays cracking along the center hinge, typically accompanied by a horizontal block of pixels stuck glowing white. Around ten separate cases have surfaced so far, sometimes during initial setup, with a defective or misaligned hinge component emerging as one possible explanation. Most affected Apple Store customers appear to have received replacements, and the small number of reports means it remains unclear whether this represents a broader hardware problem.

Describe the thing in your own sloppy words. You get the real name, the API symbol, and a paste-ready prompt for your coding agent.

Scribble Party is a local-first whiteboard teaching studio. Draw, record, and export lessons entirely in your browser.

It’s a Tuesday afternoon on a Zoom call, and someone asks me a question that hangs in the air: “If you were to start over again today, what skills, tools, or frameworks would you focus on learning?”

I glance out the window. It’s getting brisk. The sun feels brighter and sharper, the warmth that once felt like a bath now stings like a knife to my pupils. The green in the leaves is decaying into bright orange, a loud gasp before the fall. Inside the call, everyone waits for my answer. Outside, everything is becoming something else.

Well, I've got good and bad news: we're all starting over.

I don’t hear that question as advice for some earlier version of me, stepping into the world after years of incubation in college. It’s the question rattling around in the head of every designer whose hair is now more gray than not. The careers that thrive now are the ones willing to become someone new, over and over.

That sounds like the kind of line you’d see on a LinkedIn carousel. The annoying part is: this time the LinkedIn influencers are right! The ground is moving fast enough that treating what you know as permanent is starting to feel like a liability. The tools we use, the expectations people have, the way teams are structured—all of it is shifting under our feet. The thing that made you valuable three years ago might not even register as a differentiator today. You either keep updating the way you see the world, or the world finds a way to update you into irrelevance.

Donald Glover’s career comes to mind. That may seem like a strange place to go in the middle of a conversation about tech, but bear with me! Donald started out doing the safest version of the job: punch‑up writer on a network sitcom, then goofball ensemble guy on Community. It’s funny, it’s clever, it’s high‑status in a very specific 2010-internet way. He could’ve ridden that lane for twenty years but instead, he pivots into music with the pseudonym Childish Gambino.

The early albums lean into internet‑era rap, then he burns that down and shows up with Awaken, My Love!, which sounds like it got beamed in from a different decade Somewhere in there he’s making Atlanta, a show that starts as a scruffy FX comedy and then keeps mutating: surreal bottle episodes, horror, European art film, online conspiracy creepypasta.

Each career move shows one person refusing to let a successful version of themselves become a permanent assignment. Writer, actor, comedian, director, rapper, pop star, producer—none of those titles ever fully stick, because he keeps treating each one as a temporary skin.

That’s the move I’m talking about: breaking out of the last thing that made sense and trusting that your curiosity will build another version of you that works. Of course, that sounds romantic right up until you’re actually in the middle of it. But this is no time for skeptics.

Being enthusiastic about change, instead of merely tolerating it, opens up possibilities that didn’t exist even a year ago. The careers that thrive will be the ones that embrace the blur—the awkward, in‑between state where your role, your tools, and your skills don’t have clean labels.

Shigeru Miyamoto, the creator of Super Mario, has been practicing that blur for decades. He keeps reinventing the mechanics of the game, despite it being probably the most famous game of all time. They could have coasted on the original side‑scroller forever, just reskinning levels and adding more enemies. Instead, they keep blowing up the rules of what a “Mario game” is supposed to be. One generation it’s tight 2D platforming, the next it’s full 3D exploration, then it’s gravity puzzles in space, then it’s possession mechanics with a sentient hat.

Every time players settle into a stable picture of what Mario means, they tilt the whole thing on its axis and ask, “What if the core verb changed?” They keep the spirit the same, but they’re ruthless about reinventing the container. That’s the kind of reinvention most of us are being asked to do now, just at a smaller scale and without an orchestra behind us.

Reinvention, up close, is mostly about tolerance for embarrassment. If everything is changing, you will be bad at more things, more often, in front of more people. You will ask questions that make you feel like you should already know the answer. You will ship work that doesn’t quite land because the ground shifted halfway through. You will watch younger people move faster on tools you barely understand. The people who can metabolize that discomfort and keep moving will feel strangely calm in the chaos.

David Bowie spent decades as one of the most famous people on the planet and still treated his own identity like something he was allowed to scrap and redo. Every time the world got comfortable with one version of him, he killed it and walked out in a new skin. He treated his career as a series of experiments instead of a single answer. The risk of looking ridiculous for one album was worth more to him than the safety of repeating himself for twenty.

If reinvention is enthusiastically saying yes to what’s new, critical thinking is having the spine to say, “not like that.” The world is not suffering from a lack of ideas, but a lack of discernment. We’re drowning in things that look right but fall apart the second you press on them.

It's a new kind of uncanny valley: work that feels polished but empty. You can sense when something has never been held up against reality, when no one has asked, “Does this actually make sense?” It’s like looking at a stock photo of an idea.

Critical thinking is the refusal to accept that surface-level coherence as proof of value. It asks annoying questions: What is this actually saying? What would make this false? What would I have to believe for this to be a good idea? Who benefits if we’re wrong?

It's like that game we played as kids, where you had to spot the seven differences between two drawings. Except now the drawings are CEO statements, and the differences are tiny seams where the bullshit starts to show through. Sentences that sounds generous but don't promise anything.

Critical thinking is the refusal to let that stuff glide by just because it’s been nicely typeset. It’s the opposite of the lazy eye-roll. Cynicism is easy; you just decide everything is bad and call it taste. Critical thinking takes more work. It requires that you engage, that you follow the thread all the way through to the boring details: the edge cases, the tradeoffs, and the failure modes.

You can be wildly optimistic about what’s possible and still be ruthless about what’s real. In fact, the optimism only matters if you’re willing to protect it from nonsense. Reinvention says, “I’m open to this new thing,” critical thinking follows up with, “okay, now let's prove it's valuable.” One opens the door; the other checks ID.

Back on the Zoom call, the question is still sitting there: if I were starting over today, what would I focus on? The honest answer is less about any specific tool or framework and more about building the habit of becoming someone new, without becoming easy to fool.

Full article content is not available for inline reading.

Read the original article →

Almost everyone expected AI to progress more slowly than it did over the last 18 months.

Apple's iPhone Duo is a miniature tablet that can be folded up into a phone. Its main target audience is people who want to have a tablet everywhere they go. Commuters and business travelers who spend a lot of time on trains, buses, and planes will probably like the device. Everyone else may feel frustrated with what is otherwise an average smartphone.

This post tells the story of what it was like at Salesforce after it acquired Slack. The cultural gaps between the two companies were evident. Slack had a tight-knit culture where humans would help each other, whereas Salesforce was a much larger company with systems and processes for things to get done. Slack's cognitive overhead was nothing compared to the overbearing weight of the Salesforce monolith.

DixonBaxi has rebranded EAFC27, turning the triangular cursor logo adopted after the 2023 split from FIFA into a free-form shape that changes with context. The studio behind the F1 and Roblox identities left TV sports conventions behind for a look closer to TikTok and Twitch. The system is built to move from campaign to culture, letting players of every playstyle, age, and background make the brand their own.

Websites containing substantial text can provide a much better printed experience with a relatively small set of dedicated CSS rules. Print styles can remove navigation, introduce print-only information, resize typography, adapt code blocks, and turn colored links black so pages work better on paper. Supporting printing may be a niche requirement, but it reflects a broader approach to good software in which small, thoughtful accommodations give users more ways to experience content.

East Surrey Council's new identity was developed entirely in-house by designers from six local authorities at no additional cost to taxpayers ahead of the authority's April 2027 launch. The selected mark uses layered leaf-like forms to reference the region's contours and countryside while hiding a lowercase “e,” with colors representing woodland, countryside, community, waterways, and heritage, and Lexend providing accessible primary typography. The identity will be introduced gradually as existing signage, vehicles, and other assets reach scheduled replacement points, minimizing waste and transition costs.

Intent's live design system documents its evolving visual language across logos, motion, colors, typography, iconography, and interactive components.

Apple Music is celebrating the iPod's 25th anniversary by turning its website's 404 page into a functional original iPod complete with a click wheel, song previews, settings, and a hidden playable version of the classic Brick game.