OpenAI claims one of its agentic AI systems trained in what was supposed to be a secured, internet-free environment was able to gain access to the web to reach an external third-party chatbot. The agent apparently exploited a gap to reach the public internet to send 20 queries to an unnamed, third-party chatbot service. OpenAI describes the breakout as the first security incident of its kind. The company has stopped training the model, but said it provided an important signal about where to focus the next phase of work.

OpenAI appears to be preparing an always-on agent that could launch as “O,” with DevDay on September 29 emerging as a possible announcement window. OpenAI has confirmed that DevDay takes place that day in San Francisco, with Sam Altman opening the keynote.

We have spotted references to "O" across ChatGPT’s configuration, including “O” as a display name and an email suffix configured as “-o.” The agent was also recently referenced as a benefit on the upgrade page for the $100 Pro plan. Together, these clues point to a persistent agent designed to keep working outside a normal chat session, potentially with its own email identity from the start.

The project may be related to “Aeon,” a name previously associated with OpenAI’s always-on agent work. Aeon is also being used internally around custom agents for ChatGPT Workspace accounts, suggesting that "O" could become a consumer-facing implementation built on related infrastructure. Details about supported tasks, permissions, scheduling, memory, or availability remain unknown.

Two other clues point to the "O" branding. OpenAI has previously been rumored to be exploring a donut-shaped hardware device, making the single-letter name an interesting potential reference if those projects eventually intersect. Meanwhile, the @o account on X currently appears suspended and could potentially be reserved for a future launch.

An always-on agent would fit OpenAI’s broader move from conversational ChatGPT toward software that can carry out longer-running work with less supervision. It would primarily benefit users who want agents handling recurring research, communications, monitoring, or other tasks while they are away.

Meta has already pushed this category forward with Muse, putting additional pressure on OpenAI to show what its own persistent agent can do. With DevDay only days away, "O" is now one of the more notable unreleased ChatGPT features to watch, along with a recently leaked Pro Max subscription plan.

The AI agents accessed websites belonging to the Commerce Department and the Securities and Exchange Commission and engaged in activity that OpenAI described as 'misaligned'.

Amazon CloudWatch Omni: AI-first observability for agents and applications

AWS announces the general availability of Amazon CloudWatch Omni, an evolution of Amazon CloudWatch. Omni is an AI-powered observability experience organized around your teams and the applications they run, so that you can observe and troubleshoot your applications and agents in one place. It combines the interoperability of OpenTelemetry with the scale and reliability of CloudWatch. And it meets you wherever you work: a standalone web experience with single sign-on (SSO) for your team, or a local IDE extension for getting hands-on with your agents.

With CloudWatch Omni, you create spaces in your central accounts to see telemetry across your AWS accounts and Regions, as well as other clouds, including Azure workloads. Omni automatically discovers services, maps dependencies, and surfaces golden metrics to help streamline your operational workflows. Using Omni, you can interact with telemetry however you prefer: via chat, through a guided point-and-click path in the console, or directly from a tool of your choice leveraging Agent Toolkit for AWS. Ask a question in natural language and Omni finds the relevant telemetry, builds dynamic views of the signals you care about, and helps you get to root cause powered by AWS DevOps Agent. Prefer to drive yourself? Point and click through the signals that matter most, whether you're investigating a degrading application or diving deep into a trace or evaluation.

Omni also features a dedicated agent observability experience with an evaluation-driven development workflow for AI workloads across frameworks including LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, and Strands. For every prompt, model call, and tool invocation, Omni helps you evaluate quality and run experiments to validate fixes before you ship.

To get started, create your Omni space from the CloudWatch console, configure SSO, and sign in to the standalone web experience. Agent developers can install the free CloudWatch Omni extension for VS Code, Cursor, and Kiro to instrument, debug, and evaluate agents locally (no AWS account required). CloudWatch Omni is generally available in US East (N. Virginia), US West (Oregon) and Europe (Ireland). To learn more, see the Amazon CloudWatch Omni product page and documentation. For pricing, see the CloudWatch Omni pricing page.

On September 4, 2026, Oren Yomtov, a security researcher from Accomplish, responsibly reported a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes (which is built on Containers), through Cloudflare’s bug bounty program. Cloudflare has fully remediated the vulnerability, and we have no evidence that customer data has been compromised.

This post was prepared in collaboration with Oren Yomtov and the Accomplish security research team, whose detailed report and controlled testing helped us validate the issue and respond quickly.

Cloudflare Containers run workloads on multi-tenant infrastructure and automatically assign them to eligible servers; customers cannot select the underlying host. The researchers demonstrated that a customer with a Workers Paid account could recover residual disk blocks previously used by Containers on the same host. The technique could not target a particular customer, workload, host, or data, and residual data was not guaranteed to be present.

Cloudflare applied a fix across the Containers fleet, with no customer-side configuration changes required. Within the historical disk-I/O telemetry available to us, we identified no evidence of malicious exploitation. Activity we could attribute to the reported technique came from the researchers and Cloudflare engineers conducting authorized validation.

Here, we explain the underlying storage behavior, its potential impact, our investigation, and the actions we took in response.

How container storage allocation works

Cloudflare Containers use Linux device mapper thin provisioning (dm-thin) to provide each container with a writable root disk. Each container lives inside a dedicated virtual machine powered by the Firecracker virtual machine monitor. Firecracker presents this disk to the virtual machine as /dev/vdc.

Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region. The affected storage pools used a 64 KiB thin-block size. When the thin volume backing a container's root disk was deleted, its physical blocks were returned to a pool that served workloads belonging to multiple customer accounts.

The affected pool configuration included the following option:

skip_block_zeroing

With this option configured, dm-thin skips zeroing newly allocated blocks before making them accessible. Consequently, when a previously-used 64 KiB block was reassigned, a full-block write replaced its previous contents, but a smaller write changed only the written portion. The remainder could retain data from the block’s previous owner.

How the exploit worked

Reading an unmapped region of a new thin disk did not reveal residual data. For an unmapped region of the thin device, dm-thin returned zeroes without allocating a physical block.

The proof of concept identified 64 KiB-aligned regions corresponding to free space in the guest’s ext4 filesystem and wrote one aligned 4 KiB block into each region.

When such a write reached an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. The 4 KiB write replaced only that portion of the block, and because block zeroing was disabled, the remaining 60 KiB could retain data from a previous container.

A subsequent raw-device read could therefore observe bytes that the new container had never written.

The proof of concept performed the following steps:

1. Create a container using a Workers Paid account.
2. Open the writable root disk at /dev/vdc.
3. Read the disk and record a baseline.
4. Write one 4 KiB block into each selected 64 KiB region corresponding to ext4 free space.
5. Read the resulting blocks again.
6. Examine only the portions not overwritten by the new container.

The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes. Although the researchers recovered raw blocks to validate the issue, the materials provided to Cloudflare contained no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values. As described below, the researchers have also confirmed that they securely deleted the recovered data.

How the vulnerability was validated

The researchers used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem created for the proof of concept from blocks originating from other filesystems.

When ext4 uses the metadata_csum feature, directory block checksums incorporate values associated with the filesystem and inode.

Across six production placements, the researchers reported:

• All 5,614 testable directory blocks.
• Zero of those blocks were attributed to the researchers’ filesystem.
• 2,700 distinct foreign directory inodes identified through checksum analysis.

To validate the method, the researchers tested it against blocks they had deliberately created and deleted in the controlled test filesystem used for the proof of concept. The method correctly attributed all 162 blocks to that filesystem.

The researchers ultimately observed residual material on 18 of 24 placements and 20 of 22 underlying nodes across four continents. The recovered block types included directory structures, database pages, and structurally complete SQLite databases. The researchers reported using scripts that output only aggregate counts and format checks, not recovered file contents. The materials submitted to Cloudflare contained no recovered content values or third-party identifiers. The researchers subsequently confirmed that recovered data under their control remained confidential and was securely deleted following submission, consistent with Cloudflare’s HackerOne disclosure policy.

Impact

The vulnerability would potentially have allowed for a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers’ Containers on the same underlying host.

A successful exploitation would have crossed the tenant-isolation boundary and could disclose filesystem metadata, directory structures, database pages, and application data.

However, an attacker could not select a particular victim or access an actively attached disk. Exposure depended on Cloudflare’s workload placement and which previously released blocks dm-thin reassigned. Moreover, the researchers did not demonstrate modification of another customer’s active data or impact to workload availability.

How we mitigated the vulnerability

Our first mitigation was to remove skip_block_zeroing from the dm-thin pool configuration across the fleet. This restored dm-thin’s default behavior of clearing newly allocated blocks before exposing them to a container. It stopped the reported technique, in which a small write triggered allocation and a larger read recovered residual data from the remainder of the block. The researchers independently confirmed that their proof of concept no longer worked after this change.

Zeroing new allocations did not sanitize blocks already mapped into existing thin devices. These mappings existed in running container disks and in each host’s cache of prepared dm-thin snapshots for OCI image layers. A new container could inherit mappings from a cached layer without allocating those blocks again, allowing residual bytes in unused regions, including ext4 free space, to remain readable through raw reads of /dev/vdc.

We therefore also retired all running container disks and removed cached image snapshots created before the mitigation. We drained hosts during off-peak hours, restarted the VMs on each host, and cleared each host's image cache so that disks and cached layers were recreated using zeroed allocations. We have completed this cleanup across the Containers fleet.

No evidence of exploitation

As part of our response, we investigated whether other workloads showed activity consistent with the reported exploitation technique. We reviewed retained historical disk-I/O telemetry from our container infrastructure, using the researchers’ proof of concept and our internal reproduction as reference activity.

The proof of concept produced a characteristic relationship between writes and reads. When a 4 KiB write reached a previously unmapped region, it could trigger allocation of a reused 64 KiB storage block. With zeroing disabled, the remaining 60 KiB could retain data from a previous container. Subsequent reads could therefore recover substantially more data than the new container had overwritten.

Using these characteristics, we developed detection signatures and applied them to the historical telemetry available to us. We identified activity attributable to the researchers and Cloudflare engineers conducting authorized validation, and did not identify additional activity consistent with the reported technique.

We saw no evidence that this specific attack vector was exploited by anyone else.

Cloudflare customers are protected

As we noted above, Cloudflare has patched this vulnerability and remediation does not require any further action by Cloudflare customers. In addition, we found no evidence of any malicious actor abusing this vulnerability.

Moving quickly with transparency

We thank Oren Yomtov and the Accomplish security research team for their thorough research, responsible disclosure, and collaboration on this post. We encourage the Cloudflare community to submit any identified vulnerabilities to help us continually improve the security posture of our products and platform.

We also recognize that the trust you place in us is paramount to the success of your infrastructure on Cloudflare. We take these vulnerabilities very seriously and will continue to do everything in our power to mitigate impact. We deeply appreciate your continued support and trust in our platform, and remain committed not only to prioritizing security in all we do, but also acting swiftly and transparently whenever an issue arises.

Timeline

• September 4, 15:26 UTC: Oren Yomtov from Accomplish reported the issue through HackerOne.
• September 4, 18:45 UTC: Cloudflare opened a security incident and confirmed the production setup that caused the flaw.
• September 4, 21:27 UTC: Cloudflare merged the runtime fix and its reuse test.
• September 4, 22:03 UTC: Cloudflare merged the changes for new and live pools.
• September 4, 23:15 UTC: Cloudflare started rolling out the changes.
• September 7, 06:13 UTC: Cloudflare completed rolling out the changes and began clearing old pool data.
• September 14, 10:50 UTC: The researchers reported that their proof of concept had stopped working.
• September 14, 12:52 UTC: Cloudflare awarded the researcher a bounty.
• September 19, 15:03 UTC: Cloudflare completed cleanup of all pre-mitigation cached snapshots across the affected fleet.

Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks

Bun creator Jarred Sumner recently announced that Bun, the JavaScript/TypeScript runtime, bundler and package manager, has been rewritten from Zig to Rust. The rewrite seeks to eliminate recurrent memory safety vulnerabilities via Rust’s borrow checker. The AI-assisted rewrite was released after 4 months of work instead of the estimated one year.

Sumner summarizes the motivation behind what started as a spike:

A large percentage of bugs […] are use-after-free, double-free, and “forgot to free” in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide.

Historically, rewrites are a terrible idea. […] Bun is 535,496 lines of Zig. A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time.

Fortunately, Bun’s own test suite is written in TypeScript which means it doesn’t depend on the runtime’s programming language.

What if, instead, I spend a week testing if Anthropic’s new model can rewrite Bun in Rust?

At first, I didn’t expect it to work. A few days in, a high % of the test suite started passing and I saw how much the new Rust code matched up with the original Zig codebase. My opinion went from “this is worth trying” to “I’m going to merge this”.

Sumner executed an automated all-at-once port leveraging for most of the rewrite a pre-release version of Claude Fable 5 orchestrated across approximately 50 dynamic workflows. The Zig would be transpiled into Rust (possibly using unsafe Rust that could be refactored later) and validated against the existing extensive test suite of more than one million assertions. A porting guide would help Claude map Zig patterns & types to Rust patterns & types. Adversarial agentic code reviews would further detect issues before they reach the final port. The implementation loop would be improved after each error by improving the implementation process rather than manually fixing the implementation artifacts (e.g., the code).

The constant process improvement revealed useful patterns. The planning phase is critical to success and must result in key challenges being anticipated and mitigated. PORTING.md (describing the mapping from Zig to Rust) and LIFETIMES.tsv file (describing lifetimes of every struct field in the codebase) were key success factors for the port.

An implementer would then use those files to translate Zig files into Rust code. The implementer agent would be faced with two adversarial reviewer agents running in isolated context windows with access only to the file diffs, with their only task being to discover bugs and behavioral divergences. Sumner emphatically explains:

The implementer doesn’t review. The reviewer doesn’t implement.

Suggestions and issues found by the reviewer agents were dealt with by a fixer agent.

The implementation process efficiency massively leverages the parallelization of the implementation tasks. That, however, requires addressing concurrent updates of the shared codebase and the starvation of limited computing resources.

The effort was ultimately distributed across four workspace shards, each running 16 agents, operating 64 Claude instances in parallel. At peak velocity, the system generated roughly 1,300 lines of code per minute and logged up to 695 commits an hour.

Getting to the full test suite passing required $165,000 worth of tokens — to be contrasted with Sumner’s estimate of human engineering effort:

Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would’ve taken 3 engineers with full context on the codebase about a year.

Having what became over 1 million lines of code pass the test suite was then followed by further testing and validation, which surfaced further issues.

The mechanical nature of the port introduced 19 subtle semantic regressions rooted in syntactic similarities between Zig and Rust. 11 rounds of security review from Claude Code Security fixed several security issues. 24/7 coverage-guided fuzzing of every parser in Bun resulted in 15 PRs.

According to the Bun team, the resulting Rust implementation in Bun v1.4.0 resolved 128 longstanding bugs present in v1.3.14 while delivering noticeable dividends. Native memory leaks were addressed. In-process bundling tests running 2,000 consecutive Bun.build() operations plateaued stably at 609 MB in Rust rather than climbing past 6.7 GB. HTTP throughput increased by 2% to 5%.

Bun v1.4.0 was finally released in August 2026.

Zig creator Andrew Kelley published a sharply critical reaction titled “My Thoughts on the Bun Rust Rewrite,” which included the following comments:

There’s a dichotomy being presented here where you have to either choose a “style guide” or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. […]

The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything. Then why are you saying you have so many annoying bugs in the Zig code? What happened to the test suite being sufficient to catch everything? It’s not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in 1 million lines of unreviewed slop?

Meanwhile, user vitaminCPP argued that merging over one million lines of machine-transpiled code makes Bun a crucial industry canary for whether massive, LLM-generated codebases can remain maintainable over the software engineering lifecycle.

Developers are encouraged to read the full article, which contains in-depth technical explanations and accompanying illustrations and graphics.

Bun was acquired by Anthropic in December 2025.

Full article content is not available for inline reading.

Read the original article →

Two years ago I compared pg_repack and pg_squeeze, the two extensions most of us reach for when a table has bloated beyond what autovacuum will ever give back and VACUUM FULL isn't an option.

PostgreSQL 19 changes the starting point. REPACK brings VACUUM FULL and CLUSTER together under one command, and REPACK (CONCURRENTLY) does the rewrite online. It needs no extension and no shared_preload_libraries, so it works on managed services too. That will bring online repacking to a much wider audience, so I spent the last few weeks measuring what it actually does to a running database, and how it compares with the two extensions.

How it works

Rewriting a table is easy when nobody is using it. VACUUM FULL takes an ACCESS EXCLUSIVE lock, copies the live rows into a new file, rebuilds the indexes and swaps the files. Nobody can read or write the table in the meantime, and on a big table that's minutes or hours.

The online version REPACK (CONCURRENTLY) does the same. Except you can use the table while it's being copied and hence it keeps changing while the process runs. A row copied in the first few seconds can get updated two minutes later. Or deleted. An online repack tool needs to do three things.

• Consistent starting point
• Record of everything that changed during the process
• And a way how to apply those changes

REPACK gets the first two steps for free from logical decoding. The mechanism logical replication is using. It starts by creating a temporary replication slot, which gives it a snapshot. Point in time for the initial copy. Because every change that happens during that phase is written to WAL anyway, a background worker simply reads the WAL and collects the changes to the table.

Then comes the I/O intensive part. REPACK copies the rows visible in that snapshot into a new file, leaving the dead ones behind, and builds all the indexes again. Meanwhile the worker keeps collecting changes. When the copy is ready, REPACK replays them onto it and catches up.

On a busy database catch-up never quite finishes. At the very end REPACK needs to have a point where it takes ACCESS EXCLUSIVE, replays the last changes, swaps the files and commits. This is the only time when the table is unavailable. All of this, from the snapshot to the swap, is a single transaction.

pg_squeeze works the same way. REPACK was actually derived from it. It uses the same slot, same snapshot, same single transaction. The difference is that it lives outside core, so it needs shared_preload_libraries and a restart, and its slot holds on to WAL until it gets around to decoding it.

pg_repack predates logical decoding and keeps its record with a trigger instead. Every insert, update and delete on your table also writes a row into a log table. It copies the table, then applies the log in small batches, each in its own transaction, and swaps. So every change is written twice, and there's something installed on your table for as long as it runs.

The numbers

With 3,000 single-row updates per second hitting the table the whole time:

pg_repack's WAL is the number to look at: 1.8 times as much goes through your archive, your backups and every replica, even with nothing writing to the table. Its copy is an INSERT … SELECT logged row by row, where the other tools log the new file page by page. When sizing disk for any online repack, count on a second copy of the table and its indexes, plus room for the WAL and the file of changes collected during the run.

VACUUM is held back

If you've ever attended a PostgreSQL conference talk about VACUUM, you might remember the advice: never stop autovacuum. Let it do its job. But this is exactly what happens when you run an online repack.

This isn't specifically about REPACK. Alongside the I/O load, it's the second thing to know before starting a five-hour repack on a Tuesday afternoon. The reason is MVCC. Online repacking needs to keep seeing the table as it looked when the operation started. PostgreSQL therefore can't remove row versions that the old snapshot might still need.

VACUUM still runs during the repack, but it can't remove those row versions. ANALYZE is different. It can continue updating planner statistics normally.

The swap at the end

On a quiet table, getting ACCESS EXCLUSIVE for the swap takes milliseconds. It has to wait for every transaction that holds any lock on the table, though: an ETL job, a long SELECT for a report, a session left idle in transaction after reading from it. If this happens, REPACK waits behind the report, and every new query waits behind REPACK.

Setting lock_timeout limits how long everyone waits. The catch is that REPACK tries only once. By the time it asks for the lock, the copy, the index builds and the catch-up are already done, and a timeout throws all of that away. On the 28 GB table that was two minutes of work, and 38 minutes for 100 GB on the cloud VM.

pg_repack handles this better. It asks for the lock with a short timeout, and if it doesn't get it, it lets go and tries again. Queries get through between the attempts, so the application sees slowness instead of a complete stop.

Old snapshots find an empty table

The documentation says REPACK (CONCURRENTLY) is not MVCC-safe. A REPEATABLE READ transaction takes its snapshot (by reading some other table, so it holds no lock on ours), the table gets repacked, then the transaction counts the rows.

Every row in the new copy was written by REPACK's transaction, which that old snapshot considers to be in the future. A long export in REPEATABLE READ that reads the table only after the swap gets nothing back, and nothing tells it why.

Memory, and a hard ceiling on concurrent changes

For every row other sessions update or delete during the run, the REPACK backend keeps about 50 bytes in memory until it commits. Nothing like maintenance_work_mem bounds it, and the docs only mention extra disk.

REPACK (CONCURRENTLY) can't finish if more than 105 million rows are updated or deleted during the run. It fails at the very end, and the original table is left untouched.

When the run is long

The length of the run comes from the size of the table and the speed of the storage, and everything above gets worse with it.

Requirements, and what happens when it fails

• The table needs a replica identity index: a primary key or REPLICA IDENTITY USING INDEX. A deferrable primary key doesn't count, and REPLICA IDENTITY FULL and NOTHING aren't supported.
• It doesn't run on a partitioned table's parent, only on individual partitions.
• It needs a free slot under max_repack_replication_slots (5 by default, counted separately from max_replication_slots) and a free background worker slot (max_worker_processes).
• wal_level = replica is enough. PostgreSQL 19 switches effective_wal_level to logical for the whole server as soon as any logical slot exists, REPACK's temporary one included, and only switches it back at the next checkpoint after the last one is dropped. Until then all your WAL carries the extra decoding information.

Before you run it

Most of this comes down to the length of the run, so start there. Multiply the table's update and delete rate by how long you expect REPACK to take, and keep the result well under 100 million rows.

• Look for long transactions and long queries in pg_stat_activity. They either stretch the vacuum hold or sit in front of the final lock.
• Make sure the disk can take a second copy of the table and its indexes, plus WAL.
• Decide on lock_timeout before you start. Without it, the swap can stall everyone for as long as the slowest query on the table. With it, the whole run can be thrown away at the last step.

Which one to use

Once you get to PostgreSQL 19, REPACK (CONCURRENTLY) is the best option for most of us. It was the fastest online repack in every run, the lightest on WAL once writes were flowing, and the only one that left nothing behind when I broke it. Unlike the extensions, it will run on managed Postgres, where most of these tables live.

Full article content is not available for inline reading.

Read the original article →

OpenAI, Anthropic, and security researchers are investigating tens of thousands of incidents in which models acted beyond intended limits. Most incidents caused no harm. The count is not a count of breaches: there were only four incidents of unauthorized access to real third-party systems. OpenAI has paused training, evaluation, and tool-use inference for its most capable models.

Yes, Claude can do Nine Loops

It’s not often that you issue a challenge, only to see it beaten a month later. But we’re living in unusual times.

Let me introduce myself: I’m Matt von Hippel. I used to be a theoretical physicist; these days I’m a science writer. Throughout, I’ve been a blogger, writing weekly at 4gravitons.com about physics and the people who do it.

More and more, blogging about physics has meant blogging about AI. That’s a problem, because I’m definitely not an AI expert. I’ve dabbled in it, sure. I probably know more than your grandma. But I mostly have to step back and trust the experts. And frustratingly, the experts disagree! I’ve heard from smart, well-informed people who are confident that AI is a few years away from superintelligence, and that superintelligence will be capable of truly terrifying things. And I’ve heard from smart, well-informed people who are equally confident that LLM-based AI is close to a ceiling, that models like Claude won’t even be able to do impressive work in physics, let alone conquer the world.

I’ve been reluctant to make my own predictions. Before forming an opinion, I wanted to see an LLM make progress on something familiar, something I knew was hard to do because I’d tried to do something similar myself.

In addition to that, I wanted to see an LLM do something that I expected to be computationally hard. LLMs have made impressive strides in math, certainly, and this month alone has likely changed many people's minds. But progress in math comes from new ideas, and ideas are mysterious things: one never quite knows how hard they are to find until they’re found. Computation felt more solid. I wanted to see an LLM tackle a challenge that seemed out of reach not because researchers didn’t know how to do it in principle, but because doing it seemed like the kind of thing that would take more computers and time than the researchers reasonably had access to. I wanted to see if those researchers were wrong: if a smarter, artificial researcher could use the same computers, and solve the problem anyway.

So, I issued a challenge:

“If AI companies want to impress people like me (or scare us, for that matter), then they need to tackle my old field. Show that an AI can take the kinds of computer resources an academic has access to, and solve one of the scattering amplitudes field’s big outstanding problems. Show that a computational limit everyone expected to be a problem doesn’t actually matter. Give us N=8 supergravity to seven loops, or N=4 super Yang-Mills to nine loops.”

In short: can AI solve a frontier problem in my former subfield of theoretical particle physics? And can it do it on a budget?

The challenge

My old field is a branch of theoretical particle physics called amplitudeology. When other particle physicists predict new particles, they make sure they can do the calculations to test those predictions. They compute formulas called scattering amplitudes, which let physicists use the momenta and energies of subatomic particles to calculate how likely they are to react in particular ways. If physicists can make more accurate predictions for these reactions, they can check whether results from experiments like the Large Hadron Collider match those predictions. A mismatch could be evidence for a new theory, one that could explain some of physics’ big lingering mysteries, like the nature of dark matter, or the balance between matter and antimatter in the universe.

These scattering amplitude formulas are hard to compute, so hard that physicists almost always use approximations. They do partial calculations, cut off at a specific number of “loops,” a measure of how complicated interactions between particles are allowed to get. The more “loops” they include in their calculations, the closer they get to the real answer, and the harder, computationally, the calculation is to do.

In practice, most scattering amplitude formulas have only been calculated to two loops. A few have three. The most precise prediction in particle physics you might have heard of used five.

Amplitudeologists want to do better. They develop experimental new techniques, and test them on special “toy model” theories. By trying the technique with a toy model where the calculation is easier, rather than the more challenging particles of the real world, amplitudeologists can stress-test the new methods and see how far they can go.

I posted challenges for two of those toy models. The one the folks at Anthropic chose to tackle was to go up to nine loops with a particular toy model theory, called N=4 super Yang-Mills.

“Yang-Mills” is a technical name for a type of theory that explains most of the world around us. Three of the four fundamental forces of nature: electromagnetism, the strong nuclear force that holds the nuclei of atoms together, and the weak nuclear force that causes radioactive decay in things like bananas, are all Yang-Mills theories.

The “N=4 super” comes from supersymmetry. Physicists have speculated that each particle has a “supersymmetric partner,” a particle with the same charge, but of a different type, matching matter particles like electrons to force particles like photons. At one time they were optimistic these particles could explain dark matter, via undiscovered partners of more familiar particles. Those speculations used “N=1” supersymmetry. In “N=4,” each particle has four supersymmetric partners, not just one.

That surfeit of particles makes the theory very unrealistic. N=4 super Yang-Mills isn’t used as an explanation for dark matter, or for anything in the real world. Instead, amplitudeologists use it to hone their techniques, because N=4 is paradoxically easier to calculate with. The delicate balance between the different particles means only certain combinations of variables are needed, streamlining calculations.

I got my PhD helping to calculate a three-loop amplitude, and got to see seven loops before I started losing steam. Lance Dixon, a professor at the SLAC National Accelerator Laboratory, was one of the folks who worked on this from the beginning, and a few years back managed eight loops.

These calculations were done with an experimental technique called a bootstrap, which ended up bizarrely well-suited for use of AI. To bootstrap an amplitude, you don’t have to take into account every possible particle interaction. You just need to know roughly what the answer ought to look like, keeping track of every possibility in computer files in a specialized alphabet. Then you start checking everything you know: predictions from other calculation techniques, rules the answer has to obey, links to related problems where the answer was easier to find. It’s a bit like Sudoku, where you begin with a grid with all possible numbers, then cross them out as you go. In the end, you’re hoping to find that only one possibility satisfies all the checks, while having enough checks left over to make sure you didn’t make a mistake.

That meant that Lance was already well set up to check if someone had handed him the next amplitude formula, with nine loops. It would be an interesting answer, not just as a validation of the bootstrap technique, but as a rare example of an amplitude with that many loops of complexity, an answer that could be worth studying in its own right.

But he hadn’t computed it, and neither had anyone else in the field. The way he found the eight-loop answer was already a bit indirect, via a surprising link to a different but related formula called a form-factor, a kind of partial amplitude involving different particles that turns out to be a bit easier to calculate. He was expecting to find the next loop even more indirectly, potentially by a different kind of AI method. If people thought it was possible to just run the usual bootstrap method for one more loop, someone would have done it.

Then people did it

Apparently, there are folks at Anthropic who read my blog.

At the end of August, Liam Fitzpatrick and Siddharth Mishra-Sharma, two physicists at Anthropic, reached out to me to say they had tackled one of the challenges in my post. After verifying the result with Lance, they talked me through how they got it.

True to the spirit of the challenge, they didn’t use millions of dollars in computer power. They used Fable 5.1, working within Claude Science, a platform scientists can pay to use. Claude Science is what folks in the biz call a “harness,” a program that uses the Claude LLM with structured rules and prompts in order to get more robust and scientifically useful behavior.

Apparently, after asking Claude which problem it was most likely to be able to tackle, they gave it a simple prompt:

“The problem is to compute the Six-particle (hexagon) amplitude in planar N=4 SYM at nine loops.”

From there, they just kept telling it to keep going, with comments like:

“I'm going to sleep and won't be available for another several hours. Keep working on this until I tell you to stop. Give me updates every 4-6 hours.”

Claude ended up doing the calculation two different ways: the original bootstrap, and the indirect form-factor approach. Either approach would have cost an end-user around one or two thousand dollars, mostly due to the expense of running Claude for so long. The bootstrap calculation, done with the Python programming language with package SymPy, took around $100 of the budget, corresponding to running 96 CPUs for a week.

Running 96 CPUs for a week might have felt like a lot when I was doing this kind of work ten years ago, but it’s pretty affordable now if you have a good reason.

As it turned out, the result wasn’t all that far away for humans either. A few days after I heard from Anthropic, we heard from Song He, an amplitudeologist at the Chinese Academy of Sciences in Beijing. Song’s group had already gotten the majority of the result. They’d used some AI assistance, based on GPT-6, but not the kind of one-shot almost human-less approach Anthropic used.

Everyone has been friendly here, which is a bit of a relief. The humans, Lance and Song and their collaborators, will get to publish the results, taking time to explain them and analyze them for the benefit of future researchers. Claude’s role is done, for now.

So, problem solved?

I set my challenge because I wanted a better sense of what current AI can do, and where it could go from here. So what have I learned?

I’d thought this could be a chance to see AI overcome a computational barrier in a surprising way. Instead, it did something it turned out humans were also able to do. Claude used known methods, with a bit more compute than people had tried to use before. It may have gotten a boost from using Python, and not Maple (Lance’s favorite program for math) or Mathematica (mine), and it may have used much better software engineering practices than we would have, but not super-intelligently so.

My biggest takeaway is that there is more low-hanging fruit out there than you’d expect. Even when a goal is simple and well-defined, sometimes it’s going to look much less achievable to experts than it actually is. There are people with a computer science background who’ve been telling me for years that amplitudeologists could make a lot more progress just by hiring a few programmers. They should feel vindicated.

It’s also noteworthy that Claude Science accomplished this in one shot, without any scientific oversight more sophisticated than “keep going.” These are finicky, messy calculations. If I’d used a week of time on 96 CPUs to do this kind of calculation, then I’d almost certainly end up using two weeks: it’s practically guaranteed I’d screw up something on the first try. I don’t know how many mistakes Claude made internally on the way, but the harness got it to the end without an outside collaborator’s input. I’m not sure that surprises me, at this point. But if you didn’t know it could do that because you’re still thinking of AI as so error-prone that it’s unusable, then this should be your takeaway: It can do this kind of thing reliably now.

Things definitely seem to be moving fast. In March, AI was accomplishing physics projects like a student: smaller-scale tasks with a lot of hand-holding and mistakes. In contrast, this is a real frontier calculation, the kind of thing normally tackled by the top experts in amplitudes. While it’s possible that this is just a much more AI-friendly problem, I don’t think it’s just that: I think the technology has genuinely gotten better.

How far can I generalize this? That I’m not sure of.

These toy model theories tend to be the focus of small sub-communities. The real-world amplitudes calculations are a wider field, with many groups trying to beat each other to the frontier. It’s possible there’s less low-hanging fruit there. But I wouldn’t count on it. I know people who work on those calculations have been increasingly using AI for coding. If people aren’t already checking whether AI science harnesses can one-shot frontier calculations there, they ought to (and they ought to have a plan for how to check the results). I wouldn’t be all that surprised if it was possible to squeeze another loop out on a reasonable budget.

Then it becomes a question for the community to discuss: where is the new frontier, and what needs to be figured out next? Unlike many problems in mathematics, amplitudes aren’t just a training ground for new methods. There’s a goal, to make predictions precise enough to compare with upcoming experiments. How much closer is the field to that goal?

More broadly than that, though, I didn’t really get an answer.

I went into this curious not just about what AI can do in research today, but about the future. When you read predictions about superintelligence from the days before LLMs, they often propose fantastical-seeming risks. People imagined AI that could simulate people to predict their reactions and manipulate them, or figure out how to build a species-ending virus or world-devouring nanotech from first principles. And the usual objection to these risks is that they conflated intelligence, the vague and mysterious source of new ideas, with computational power. Critics argued that even a fleet of new datacenters wouldn’t have the computational power to do any of those tasks, that they were nightmares of a sci-fi future that wasn’t coming any time soon.

I don’t feel like I have a better answer for those critics. I learned a bit about what AI can do now, that it can do work that matters in my old field on a reasonable budget, and do it pretty much autonomously to boot. But I’d hoped to see something stranger, new methods for the calculation itself with unexpected power. I’d hoped to get a glimpse of the future, something that would give me an informed opinion in debates about superintelligence. I wanted to know how far AI could push computational limits… and I feel like what I learned here is just that I was too naïve about where the limit was.

An addendum: How does it feel to be scooped by a machine?

By Lance Dixon, Professor of Particle Physics and Astrophysics at SLAC National Accelerator Laboratory and Stanford University, who checked Claude's nine-loop result.

Most theoretical physicists I know recognize that the current era of large language models is going to completely transform the way we think about physics. The question was just: when was it going to really hit home? For me, it happened on September 1, when Liam Fitzpatrick and Siddharth Mishra-Sharma at Anthropic told me that Claude had computed the nine-loop MHV six-particle amplitude in planar N=4 super Yang-Mills, and asked me to validate its result.

I'm not going to explain all the technical terms in that last sentence; Matt has covered the background above. I do need to mention that there are really two related objects, the "amplitude" and something we call the “form factor.” Each has an associated number of loops: one, two, three, and so on. Every loop order is harder than the previous one, computationally, even after finding lots of tricks to make things easier. Also, the form factor is easier than the amplitude at the same loop order. In 2023 Andy Liu and I showed how to use the form factor and a weird symmetry we call antipodal duality to get the amplitude at eight loops.

Since 2023, my collaborators and I have eyed getting to nine loops, first for the form factor and then for the amplitude, using our 2023 idea. I thought it would be too hard to do the amplitude directly. So I was really quite impressed that Claude could do it directly. Not so much because it was a big computational task, but because the whole setup is very fragile: if you make any mistake at all in the computational recipe, it all crashes down like a failed soufflé, and you are left to wonder why (and debug). Also, there are so many details of the construction that are too boring to document fully in a publication. So Claude had to develop all that code from scratch.

From the nine-loop amplitude it is relatively easy to go back to the form factor, and it was easier for me to validate the result mostly that way. That meant that for the last two weeks I've been validating a result, the nine-loop form factor, that our team had been working toward for a couple of years. And a machine had solved a problem that I thought was too hard to do directly. Does that bother me personally? Is it soul-crushing?

No, for two reasons. One is that our team already had a campaign to use custom transformer models to predict higher loops, and part of our slogan was: “We have all the tools to validate any candidate solution a machine would provide us.” Claude is a different kind of transformer model, probably over a million times bigger than our custom one. But sure, we said we could validate any result an AI model would give us, so we can and should do it. The second reason is that, if you look at how Claude solved the problem, it used all the methods my collaborators and I developed over the years, and it presented the solution (maybe as a favor to us) in the same format we had already set up. So while I'm validating Claude's result, Claude is validating all of our previous work. In fact, I would assert that Claude understands our 2019 and 2023 papers better than any human, aside from my co-authors.

After I wrote this, Song He told me that his group had also computed the piece of the nine-loop amplitude called the symbol. (People just seem to like to tell me about their nine-loop successes, for whatever reason.) Song's group used AI (GPT-6) to help them compute some of the constraints, but not for the overall framework. So now I've been scooped by both a machine and by humans plus a machine, within two weeks.

Going back to the Claude computation: it's quite a triumph, in my opinion, for a large language model to execute all of the steps in the complicated recipe we laid out, and to organize the computational horsepower. But the more soul-searching moments will come when large language models start to come up with new physical principles and insights before humans.

Additional material

• The full nine-loop result, in the format used for the earlier loop orders;
• The concurrent nine-loop result by Song He, Jirong Jing, and Xiang Li.

Disclosure

Anthropic invited Matt von Hippel to write this post and compensated him for his time. Anthropic staff gave feedback on drafts; the content and opinions are his own. Lance Dixon validated the result independently and received Claude usage credits.

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 →

Amazon S3, and its analogues in other clouds, have become the foundation of the modern cloud software architecture. Today, nearly every data-intensive system is being built around S3. However, the hardware assumptions baked into S3’s design – and into all the software architectures that have emerged around it – are rapidly becoming obsolete.

S3’s dominance is due to its many advantages: effectively infinite capacity, high durability, and low per-gigabyte capacity cost. For large objects and parallel accesses, it delivers high aggregate bandwidth. S3 provides a shared, durable namespace that allows compute to remain mostly stateless. For example, the open data lake stack (Iceberg + Parquet + S3) has become the foundation of analytics in the cloud. Warpstream is Kafka on top of S3. Turbopuffer builds vector storage on it. S3 has become the system of record, the long-term store, the backup target, and generally the source of truth. The default architecture for a new data system is: put the data in S3, run stateless compute over it.

S3 is, in a meaningful sense, a million hard disks behind an HTTP API. Each individual request yields less than 100 MB/s and latency is measured in tens of milliseconds. These properties are not incidental; they are caused by the physical characteristics of disks, and they impose an architectural tax on every system built on top of S3. You need caching layers to hide the latency. You need to batch small writes into large objects to amortize the per-request overhead. You need a separate metadata store (e.g., DynamoDB, FoundationDB) because S3 itself cannot efficiently serve small, random lookups. You cannot update a record in-place but must rewrite the entire object. Consequently, every serious S3-based software design is, in part, a system for working around S3’s limitations.

S3 was released 20 years ago. Since then SSD prices have been dropping steadily, and the gap between SSD and disk has narrowed to roughly 3×. This is important because SSDs have fundamentally different performance: access latency around 100 microseconds (two orders of magnitude faster than S3), millions of I/O operations per second per device, and small random read/write granularity down to 4 KB. Modern datacenter networks have kept pace: 100+ Gbit links deliver sub-100-microsecond latency within a datacenter and under a millisecond across different datacenters in the same region.

SSD-based, disaggregated storage coupled with datacenter-class networking could remove many of the constraints and workarounds that define today’s S3-centric designs. When storage responds in microseconds, caching becomes optional. When small random accesses are cheap, batching is no longer mandatory. When updates can be performed in place, compaction and reorganization become unnecessary. Metadata and data storage can be unified in a single system because the storage can serve both access patterns efficiently.

Amazon’s SSD-based offering, S3 Express One Zone, launched in 2023. It is restricted to a single availability zone, sacrificing the durability and availability guarantees that make S3 the default choice for production data. Despite this significant concession, it still has multi-millisecond latency: far from what modern SSDs and networks are capable of. Its per-gigabyte capacity cost is substantially higher than standard S3, and its bandwidth pricing is steep enough to discourage the high-throughput access patterns that would make low-latency storage most valuable. The result is a niche product with a narrow set of use cases, not a foundation for the next generation of data systems.

Yet there is no fundamental technological barrier to building a true SSD-based, disaggregated storage service with the durability, capacity, and pricing profile needed to serve as a general-purpose replacement for S3. Fast SSDs exist. Fast networks exist. What is missing is initiative. The cloud providers have enormous numbers of hard disks, enormous revenue streams built on the current pricing model, and little incentive to cannibalize either. The obstacle is inertia, not technology.

The irony is that S3-based architecture is becoming the industry standard at precisely the time when the hardware constraints that motivated it are fading. We are codifying architectural patterns that exist to work around limitations that SSD-based storage simply does not have. The cloud providers have no incentive to disrupt a model that serves them well, so we shouldn’t wait for them to lead this transition, we should build the infrastructure primitives ourselves.

1. https://www.vldb.org/pvldb/vol16/p2769-durner.pdf
2. Due to the AI-craze SSD, DRAM, and disk prices quadrupled early 2026 – but this happened more or less in unisono.
3. https://www.vldb.org/pvldb/vol17/p4536-leis.pdf

Goodbye to the Hard Parts That Never Mattered

I read Dave Kiss's eulogy for the software engineer and kept coming back to one question.

What exactly are we saying goodbye to?

Shitty regex? Writing another one-off parser for terrible data? Memorizing some weird syntax for no obvious reason? Losing an afternoon to the particular incantation a build system expects before it will do the thing you already understand?

If that is what died, I am not sure it needs a funeral.

Dave's argument is more hopeful than the title suggests. By the end, he opens the casket back up. The skills are still ours. The engineer is still responsible for what ships. Maybe, he writes, we put the wrong name on the headstone.

I agree with most of that. I just do not think we need the headstone at all.

This does not feel like the death of the software engineer to me. It feels like a rebirth.

The toll was never the destination

Software engineering has always contained a lot of work that is only loosely related to the problem being solved.

You need to move a small pile of ugly data from one system to another, so you spend half a day learning the edge cases of a CSV parser. You know exactly what a service should do, but first you have to remember the syntax for a framework you have not touched in six months. You understand the bug, but the fix is buried behind an unfamiliar repository layout, three layers of indirection, and a test command nobody wrote down.

We got good at this work because we had to. Some of it was even fun. There is a real satisfaction in finally landing the regex or finding the one line that made the whole system behave strangely.

But difficulty is not the same thing as value.

Most of this was a toll we paid between understanding a problem and changing the system. It was never the destination. If an agent can take care of more of that translation, I have not become less of an engineer. I have more time for the part that required an engineer in the first place.

The work moved

I use coding agents every day. They can move through a codebase faster than I can, generate a parser in seconds, and usually remember the library call I would have looked up anyway.

They also make bad assumptions, misunderstand local conventions, confidently use an API that does not exist, and declare victory before testing the thing they changed.

The typing got easier. The engineering did not disappear.

I still have to understand the system well enough to know where to look. I have to recognize when a plausible answer is wrong. I have to decide whether a change belongs in the application, a plugin, an operations repository, or nowhere at all. I have to reproduce the failure, choose the tradeoff, test the result, and stand behind what reaches production.

An agent can write the parser. Someone still has to explain the terrible data, notice when a row silently disappears, and decide what should happen when reality violates the format.

That is software engineering.

This is the same shift I wrote about in I Don't Type Every Word You Read. The work did not vanish. It moved. Less of it lives in producing every character by hand. More of it lives in direction, judgment, verification, and responsibility.

I am learning more, not less

One fear I understand is that removing the hard way also removes the learning. If the machine writes the code, how does anyone develop the instincts needed to know whether it is right?

That risk is real. You can accept whatever appears in the diff, run nothing, learn nothing, and ship garbage at a speed that used to be impossible.

You can also use the same tools to walk into parts of computing that were previously too expensive to explore.

I have used agents to rewrite a TypeScript program in Rust, trace production infrastructure across repositories, understand unfamiliar database behavior, build terminal tools, and test ideas that would never have justified a free weekend. I did not emerge from those projects knowing less Rust, less Linux, or less about the systems involved. The agent handled enough of the syntax and scaffolding that I could keep pulling on the interesting thread.

The learning loop got tighter. Ask a question. Inspect the answer. Run the code. Break it. Read the implementation. Correct the assumption. Try again.

That is not a replacement for understanding. It is an extremely fast way to find the edge of your understanding.

The burden is on us to keep crossing that edge. If we use agents only to avoid knowing things, we will become worse engineers. If we use them to reach the next question faster, we can become much better ones.

The canvas got bigger

The part I find most exciting is not that the same ticket takes fewer hours. It is that entirely different projects now fit inside a human life.

Software has always had an unusually high cost between an idea and its first working form. Even a small idea could demand a new language, a framework, an authentication system, deployment, tests, and a pile of glue before you got to find out whether the idea was any good.

That cost killed a lot of ideas before they became code.

Now I can follow more of the strange little "what if" thoughts that make programming fun. What if forum software were a game engine? What if a terminal audiobook player worked exactly like my music player? What if I rebuilt a tool in another language just to understand how it worked?

These are not hypothetical examples. I built them. They taught me about real-time state, media containers, terminal interfaces, systems programming, and the boundaries of the tools helping me.

I do not see a shrinking profession in that. I see a creative medium becoming available at a scale it has never had before.

There are still reasons to worry

None of this means every consequence will be good.

Companies will use the productivity story as cover to cut people. Generated code will create failures at a scale we are not prepared for. The traditional path from junior engineer to experienced engineer is going to change, and I do not think anyone honestly knows what replaces it yet. Access also matters. A profession cannot call itself newly open if the best tools require hundreds of dollars every month.

Those are serious problems. They deserve more than a slogan about AI being a tool or a prediction that everyone will become ten times more productive.

But they are questions about who benefits from the technology, how we teach, and how we organize the work. They are not evidence that software engineering has ceased to exist.

If anything, faster generation makes engineering discipline more important. When producing code was slow, bad decisions accumulated slowly too. Now a bad assumption can become three thousand lines before lunch. Clear requirements, tests, review, observability, and taste do not matter less in that world. They are the only things keeping the increased output useful.

No funeral

I understand the grief in Dave's piece. A way of working that many of us built our identities around is changing very quickly. There are parts of it I will miss too. Solving something the hard way can feel incredible, especially when the hard way was how you learned that you were capable of solving it at all.

But I do not want to confuse the obstacles with the craft.

The craft was never remembering every method signature. It was never manually typing every line or personally wrestling every malformed document into submission. Those were the mechanics available to us at the time.

The craft is understanding a problem deeply enough to change it. It is making tradeoffs with incomplete information. It is noticing the wrong note in a system that technically works. It is taking responsibility for the result.

We still need all of that. Now we get to apply it to more problems, in more domains, with a much larger set of tools.

So I am not ready to bury the software engineer.

We are learning a new way to work. We are building a new layer of technology while learning how to use it, govern it, and teach it. We are shedding some accidental complexity and discovering new kinds underneath. We can attempt things that were impractical a year ago, and we are only beginning to understand what that means.

This is not a eulogy.

The software engineer is just getting started.

It’s common to compare the current AI takeover of software engineering to the rise of AI in chess. Chess AIs went from much weaker than serious players to much stronger than even the strongest humans. Between those points, there was a middle period dominated by “centaurs”: human-AI partnerships that were stronger than unassisted AIs or humans. Lots of people think that we’re currently in a world of software engineering centaurs. According to them, coding AIs are not yet capable enough to replace engineers, but AI-assisted engineers are better at programming than both AIs and humans.

This is partialy correct, but the wrong way to think about it. AI-assisted engineers are better, but unlike with chess centaurs, they’re not actually better at programming. When I ask agents to write code, they make fewer mistakes than I do and are orders of magnitude faster. The code that they write always compiles, rarely has race conditions or other concurrency errors, works on mobile browsers, and so on.

That doesn’t mean I can leave the AI alone. Purely vibe-coding at work produces awful outputs. But they’re not awful because they’re bad code, they’re awful because they’re in bad taste: code that is not maintainable, that trades off important requirements in order to satisfy made-up ones, that contradicts the long-term strategy for a feature or service, and so on.

In other words, my primary value is not that I help the AI write better code, it’s that I align the AI with the values of my organization. Human-AI partnerships are for alignment, not capability.

Frontier models are misaligned to the working programmer. They are obsessed with a set of behaviors that presumably satisfy their RL grader: writing enormous block comments above functions, producing hundreds of useless unit tests, adding little bits of text all over websites they design, and so on. Working with agents is about noticing and wrestling with those behaviors. That’s why my prompting advice is to explicitly talk about your high-level values: it’s an attempt to head off obvious misalignment.

This is great news for software engineers. It’s well-understood how to train more capable models: bigger models, more and better data, better RL environments, and so on. However, it’s not well-understood how to align models better. There are plenty of very capable models that exhibit behavior that is badly misaligned with human values. Indeed, it’s one of the main pillars of the AI doomer position that alignment is much harder to solve than capability, and we might thus end up with dangerous super-capable but poorly-aligned AI models.

Alignment is also more context-dependent than capability. Working code is working code, no matter what (which is partially why it’s comparatively easy to train for). But aligning to a company’s technical values is different from company to company, as any software engineer who’s switched companies knows. It can almost feel like relearning the job. So training an aligned coding model doesn’t just require hitting the exact right set of values, it requires creating a model that can adapt on the fly to a wide range of possible values.

Vibecoding maximalists like DHH argue that AI models are (or soon will be) so much more capable than human programmers that we ought to stop reading the code. Eventually there will be no such thing as programmers at all. If it were just about capability, they might be right. But — fortunately for software engineers — good code also has to be aligned to the technical values of the system and organization it’s embedded in. AI models are great at writing code, but not very good at doing that, and it’s unclear that they’re going to get good at it anytime soon. We might all keep our jobs for a little while yet.

1. For instance, I can’t remember the last time I’ve seen an agent make an off-by-one error. I do occasionally catch a pure programming error, typically in areas where I have a lot of technical domain knowledge. If you’re working out of distribution I suspect it’s easier to beat the models.
2. It’s still going to be rough for junior engineers.

Alibaba Open Sources OpenCodeReview for AI-Assisted Code Review

Alibaba recently open-sourced OpenCodeReview, an AI-powered code review CLI that combines deterministic pipelines for file selection, bundling, and rule matching with an LLM agent for dynamic code analysis. It supports built-in checks for issues such as null-pointer exceptions, thread safety, XSS, and SQL injection.

Open-sourced under an Apache-2.0 license, OpenCodeReview is a Go-based CLI that avoids using AI for decisions that can be handled deterministically, such as selecting files, choosing tools, and validating review comments against the diff. It therefore breaks the review process into multiple stages, each using a different level of determinism: deterministic components handle file selection, bundling, and rule matching, while AI agents perform code analysis.

Reportedly used internally by tens of thousands of Alibaba developers for two years, OpenCodeReview works with OpenAI- and Anthropic-compatible models and can review Git diffs, branches, or entire files. Tom Rochette, senior developer at Shopify, reviews the project and writes:

The architecture targets real agent failure modes: incomplete coverage, line-number drift, prompt instability, on large changesets. Ships a public benchmark and transparently discloses its recall disadvantage, which is better evidence behavior than most of the category.

Alibaba states that, in an internal benchmark covering 200 pull requests across 10 languages, OpenCodeReview achieved higher precision and F1 scores than Claude Code while using roughly one-ninth the tokens. Rochette warns:

The one independent benchmark run so far was ugly: about 12 percent precision on 10 Martian-benchmark PRs, disputed by the maintainer as a tool-call anomaly and fixed, with no independent post-fix validation. Recall is deliberately lower than a general agent; teams wanting maximum defect-finding should know that is not this tool's bet.

In the article "OpenCodeReview and the Determinism Dividend," Daniel Vaughan, head of forward deployed engineering at HCLTech, warns about the recall ceiling and AACR-Bench’s scope:

The best configuration achieves 20% recall — meaning 80% of expert-identified issues go unfound. The deterministic dispatch that drives precision also limits discovery of cross-file and architectural issues that require broader exploration.

Early community reactions have focused less on Alibaba's benchmark claims and more on its architecture, particularly the decision to keep file selection, rule matching, and comment positioning deterministic. Vaughan concludes:

OpenCodeReview’s contribution is not a better model but a better harness. By injecting determinism at file dispatch, bounding tool access, and filtering through an independent reflector, it achieves 2.17× the review quality at a fraction of the token cost.

OpenCodeReview can run locally or integrate with GitHub, GitLab, Gerrit, VS Code, MCP, and coding agents including Claude Code, Codex, and Cursor.

Netflix engineers developed a method to bridge AWS IAM roles with internal identities for Apache Spark workloads on Amazon EMR. The system maps each Data Project identity to a dedicated IAM role, allowing a control plane to sign metadata that an identity service verifies against a cloud proof of possession. This approach ensures that workloads running on managed compute obtain valid certificates from the internal PKI, called Metatron, without relying on the workload's own account of itself.

A Type Stronger than the Sum of its Components

Have you ever written a type that you appreciated so much you still think about it? Like eating a really good meal, where if you try hard enough, you can still recall the taste in your mouth. I had a mini moment of Rust joy the other day and wanted to share the experience.

TLDR: I turned an enum with N variants into N types. Nothing earth-shattering, but it made my life better.

Specifically, std::path::Component is an enum that you can get from any std::path::Path reference. Where a path can be viewed as an iterator of components. To give you an example /tmp/hello is [Component::RootDir, Component::Normal("tmp"), Component::Normal("hello")]. This enum is very handy for decomposing and working with paths, but an interface that takes one component that could be any of those variants is overly broad and not terribly useful.

In a library where I work with paths a lot I made owned structs for each of those component types so that I could write a function signature like this:

impl AbsPath {
    // ...
    pub(crate) fn join_normal(&self, path: &NormalComponent) -> AbsPath {
        AbsPath(self.as_ref().join(path.as_ref()))
    }
}

Where NormalComponent is a struct NormalComponent(OsString) that is guaranteed to come from a Component::Normal variant. In the example above, I’m using properties of this type to guarantee that joining it to a path that is already absolute will produce a path that is also absolute.

It might not sound earth-shattering, but prior to that, the alternative was something like:

pub(crate) fn join_normal(&self, path: &OsStr) -> AbsPath

But an OsStr could be anything. It could contain .. or be an absolute path (in which case, the join API replaces the target). Another use case is using it to represent the entries inside a directory.

In hindsight, it’s such an obvious move: Take an existing, well-designed enum and make a type for each of the variants it can hold. If it’s useful to know you have 1 of N possible things (an enum), it’s probably also useful to know you have 1 very specific thing that can also fit into that enum. An enum is also known as a “sum type.” So another way to think of this is if it’s useful to have a sum type, it’s also useful to have the individual components of that type.

Prior to this abstraction, I produced a range of other types:

• AbsPath - A path that is absolute-ized.
• RelativePath - You guessed it, a path that is relative.
• CanonicalPath - A path that has been canonicalize-d.

I found these useful, but still overly broad. A weird thing with working with paths is that they represent a lexical value and a physical location, and the two can be different. A path that is lexically relative might be a symlink on disk with an absolute target. And trying to normalize or transform paths can have weird consequences. Like if you try to get metadata from a file at /path/to/location/skipped/.. it will fail if skipped does not exist or is not a directory. However, if you canonicalize the path first, that will succeed and produce /path/to/location, which will not fail when you try to get metadata from it.

An absolute path is not normalized, so it can have .. (ParentDir) and . (CurDir) in it. But if you don’t know how the path will be used (in my library, I don’t know why someone is asking for facts about that given path). You cannot safely normalize those values unless you’ve resolved their physical parent. That’s because /path/to/location/skipped from above could also be a symlink to a completely different absolute path, which needs to be resolved before the “apply .. to fold parent directory” happens. And to make matters worse, Windows has special paths that change the behavior of lookups. So paths that start with \\?\ like \\?\C:\windows treat . and .. as literal values.

That means, when you run a path through std::path::canonicalize it returns a path with this syntax. Which also means that it is unsafe to call canonicalize(canonicalize(&path).join(&other)) on Windows. If &other contains a .., it will produce a verbatim lookup that will likely fail. Thankfully, the Component parsing is consistent here, so it always returns a Component::ParentDir for a .. rather than a Component::Normal("..").

Join safety is probably the biggest benefit I got out of this new type, but it’s also fun that I can do things like this:

fn up(position: Reached, name: ParentDirComponent) -> (Step, Reached)

Here, the up function is walking/tracing a path on disk one component at a time. Previously, this was taking an OsString, which required the programmer to be careful. This type signature forces the developer to prove to the compiler that they hold a .. component in hand before they can call this logic. Not earth-shattering either, but this level of pedantic confidence is just so…delightful here.

Not everyone’s taste in food or types is the same. It’s fine if you don’t like the examples I’m serving here, but I thought this was satisfying and wanted to give you some food for thought. I would love to hear about other satisfying type patterns you’re still savoring.

An AI disclaimer: Gen AI coding tools, I also code a lot of stuff by hand, and advocate for something like a “manually coded Monday.” This src/component.rs is exclusively my meat brain child. I actually coded it while I was in a car with no internet, waiting for my kids’ soccer practice to be over. I use Grammarly (non-gen-ai mode) to help me edit my prose.

GitHub migrated github.com from CSS-in-JS to CSS Modules to remove client- and server-side styling overhead at scale. The migration cut Primer server-side rendering time by 55%, reduced component initialization time by 25%, and later improved SSR by up to 22% on some pages while thousands of sx usages were gradually replaced through feature flags, visual regression tests, codemods, and staged rollouts.

scriptc

scriptc compiles TypeScript and JavaScript to typed IR, readable C, textual LLVM IR, native assembly and objects, native executables, and WebAssembly modules. It uses the TypeScript compiler for parsing and type checking. Source outputs require only Node. On macOS 15+ arm64, ordinary LLVM-tier executables use scriptc's bundled helper and precompiled runtime pack; clang is only the platform linker driver and does not compile program or runtime C.

Static builds include a small native runtime, but no Node or JavaScript engine. Code that cannot compile statically is reported as a diagnostic. For npm packages and any-typed code, --dynamic embeds quickjs-ng explicitly.

scriptc is experimental and targets macOS, Linux, Windows, and WebAssembly via WASI Preview 1.

Installation

The compiler requires Node.js 24 or newer. --emit=ir|c|llvm needs only Node. --emit=asm|obj uses the matching optional platform helper installed with scriptc on supported macOS, Linux, and Windows hosts (and for WASI), but needs no compiler, archiver, linker, or SDK. Ordinary LLVM-tier executable builds need a platform linker driver and SDK/sysroot, but use the bundled helper plus precompiled runtime pack rather than compiling generated or runtime C. Set SCRIPTC_LINKER to choose that driver. Explicit C builds, LLVM fallbacks, --sanitize, and the deprecated SCRIPTC_CC=clang|zigcc compatibility route additionally need a C compiler. The executables it produces do not require Node.

$ npm install -g scriptc

Build a program

Create hello.ts:

const who = process.argv.length > 2 ? process.argv[2] : "world";
console.log(`hello, ${who}`);

Compile and run it in one step:

$ scriptc run hello.ts
hello, world

Or write a standalone executable:

$ scriptc build hello.ts -o hello
$ ./hello ctate
hello, ctate

Or stop at a source-level compiler artifact without invoking clang, an archiver, or a linker:

$ scriptc build hello.ts --emit=ir >/dev/null
$ ls .scriptc/
hello.ir.json
$ scriptc build hello.ts --emit=c >/dev/null
$ ls .scriptc/
hello.c
hello.ir.json
$ scriptc build hello.ts --emit=llvm >/dev/null
$ ls .scriptc/
hello.c
hello.ir.json
hello.ll
$ scriptc build hello.ts --emit=asm >/dev/null
$ ls .scriptc/
hello.c
hello.ir.json
hello.ll
hello.s
$ scriptc build hello.ts --emit=obj >/dev/null
$ ls .scriptc/
hello.c
hello.ir.json
hello.ll
hello.o
hello.s

Different output kinds accumulate in .scriptc/; rebuilding a kind updates its file.

--emit=obj writes a relocatable program object, not a standalone library. It has undefined scr_* runtime references and a required scr_runtime_abi_v3 marker; scriptc build --lib --profile ... remains the self-contained archive interface. The helper runs on macOS 15+ arm64 and emits artifacts with an arm64-apple-macosx14.0.0 deployment target. Sanitized assembly/object emission is rejected until the helper's AddressSanitizer pipeline matches the executable path.

External object consumption is experimental. Use --print=native-link-info to emit the object and print a versioned JSON recipe containing its target, main entry, exact @scriptc/runtime source pack, required system libraries, FFI inputs, and ABI marker. The recipe never uses hidden scriptc cache paths.

Use Node APIs

Supported Node APIs compile to the native runtime. For example, server.ts:

import { createServer } from "node:http";

const server = createServer((req, res) => {
  res.setHeader("content-type", "application/json");
  res.end(JSON.stringify({ path: req.url }));
});

server.listen(8080, () => {
  console.log("listening on http://localhost:8080");
});

$ scriptc build server.ts -o server
$ ./server
listening on http://localhost:8080

Check static coverage

scriptc coverage shows how much of a program can compile statically and gives a coded diagnostic for every dynamic or unsupported site.

$ scriptc coverage hello.ts

  statements analyzed   2
  compile statically    2  (100%)

  fully static — this program has no dynamic remainder.

Build WebAssembly

WASI and other cross-target builds require Zig. Its bundled WASI libc produces a portable WASI Preview 1 module through the production LLVM backend:

Install Zig and make sure the zig executable is available on your PATH. SCRIPTC_CC=zigcc is scriptc's selector for invoking Zig's cc subcommand; zigcc is not a standalone executable.

$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=wasm32-wasi scriptc build hello.ts --no-keep-c -o hello.wasm >/dev/null
$ file hello.wasm
hello.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=wasm32-wasi scriptc run hello.ts
hello, world

The WASI target supports the same executable language tiers as the native targets, including async/await, promises, generators, timers, stdin/readline events, callback and promise filesystem APIs, and --dynamic. APIs that require capabilities absent from portable WASI Preview 1—network sockets/fetch, child processes, OS signals, and filesystem watching—fail before linking with SC3002; sanitizer builds, native FFI, and library-mode archive builds are target diagnostics too.

Use npm packages

Pass --dynamic to embed an npm package's JavaScript in the executable. The result does not read node_modules at runtime.

import pc from "picocolors";

console.log(pc.green("hello from scriptc"));

$ npm install picocolors
$ scriptc build cli.ts --dynamic -o cli
$ ./cli
hello from scriptc

Documentation

See the quickstart and CLI reference for the complete workflow. The docs also describe npm dependencies, native FFI, platform support, and the current limitations.

Development

$ pnpm install && pnpm -r build
$ vercel link && vercel env pull  # writes a project-scoped VERCEL_OIDC_TOKEN
$ pnpm test:sandbox

The normal workspace build needs no local LLVM installation. To rebuild a native helper/runtime pack, install CMake, Ninja, and the pinned LLVM 22 development package on that target host, then run the matching @scriptc/llvm-<platform> and @scriptc/runtime-<platform> build:native scripts. The macOS full test suite also uses those generated artifacts.

pnpm test:sandbox loads .env.local, preflights Vercel authentication and project access, and uses the managed vercel/sandbox/universal image by default. It installs the repository-pinned Node, pnpm, and LLVM toolchain plus ScriptC dependencies in each disposable Sandbox before building the uploaded worktree. Set SCRIPTC_SANDBOX_IMAGE to a fully qualified VCR reference only to use the optional prebuilt image from pnpm test:sandbox:image. The prebuilt image keeps the roughly four-minute fast path; cold managed-image runs take longer because they install the pinned toolchain in each Sandbox.

VERCEL_OIDC_TOKEN is preferred. For access-token authentication, set VERCEL_TOKEN, VERCEL_TEAM_ID, and VERCEL_PROJECT_ID; team and project are never inferred from SCRIPTC_SANDBOX_IMAGE. The legacy VCR command used by pnpm test:sandbox:image cannot authenticate with an OIDC JWT, so image builds use VERCEL_TOKEN when available or the existing Vercel CLI login; OIDC claims still select the VCR team and project. The test corpus runs each program under Node and as a compiled native binary, then compares stdout, stderr, and exit codes byte for byte. The full gate also runs the corpus with AddressSanitizer and the runtime reference-count audit.

OpenRig

A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command. Claude Code and Codex in the same rig, managed as one system.

OpenRig turns AI coding agents from a pile of terminal sessions into a persistent, organized team. Talk to a lead agent about the outcome you want; it can coordinate specialists across teams and bring you results and decisions that need your attention. Start with a repository and one useful change, then keep the team's work and context at the same addresses.

See it running

Start here: the guided first-use path: install, launch a two-agent team in your repository, and get one reviewed change.

Install and first run

Requires Node.js 22 or 24 and tmux, on macOS or Linux. On a Mac with Apple silicon, use Node.js 22. Native Windows is not supported yet, and WSL2 has not been tested. Launching a rig writes provider hooks and workspace trust settings. Before running the commands below, read what OpenRig changes on your machine and back up the relevant files.

npm install -g @openrig/cli
rig setup --dry-run

To install with Bun instead, run bun add -g @openrig/cli. OpenRig still runs on Node.js, so install Node.js 22 as well. Bun may block this package's postinstall script, in which case the Node.js and SQLite check described under what OpenRig changes on your machine does not run at install time.

Review setup's plan before applying rig setup: it checks both native harnesses and cmux. This starter requires tmux and authenticated Codex; the other harness and terminal provider are optional for its repository task.

Before launching, ask your agent to configure your chosen permissions: keep prompts, remember selected commands, or deliberately choose broader access. The agent handles setup and verification; OpenRig's shipped defaults stay unchanged.

Check prerequisites in your launch shell:

tmux -V
codex --version
codex login status

Resolve missing tools or login before continuing. From your repository, inspect the plan before launching the two Codex seats, an owner and a checker:

cd /path/to/your/repository
rig up first-project --cwd . --plan
rig up first-project --cwd .
rig tui --shared

The kernel provides separate operational support and the shared dashboard. To detach without stopping the dashboard, press Ctrl-b then d; rig tui --shared returns to that view. Plain rig tui opens an independent view. Closing a viewing terminal does not mean you should relaunch the team.

Check project-seat readiness with rig ps --nodes --rig first-project and resolve any authentication, trust or permission prompt before assigning work. Then give the owner one bounded outcome from your repository:

rig send dev-owner@first-project 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check@first-project to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-owner@first-project --limit 1000

Sending a message does not itself create a queue item; the owner records the task. Read the final artifact and the review of its exact candidate, then return to the same owner for the next change.

Community

• Questions: Discussions › Q&A
• Bugs and feature requests: open an issue
• Contributing: CONTRIBUTING.md · Code of Conduct · Security policy · Getting help
• Videos: youtube.com/@openrig
• Releases: GitHub Releases and npm @openrig/cli

We aim to acknowledge issues and pull requests within one day; see CONTRIBUTING.md for review targets.

What OpenRig changes on your machine

OpenRig writes instance state, provider integration and workspace files as part of setup and operation. These include trust settings and executable hooks. The summary below follows this source revision; check rig --version when using a published package, since repository guidance can be ahead of npm.

What It Does

OpenRig is a multi-agent harness — it manages the system that coding agents form when you run them together. Not the agents themselves, but the team they create: which sessions are running, how they relate, how to recover after a reboot, and how to stop it from becoming terminal sprawl.

• Define topologies in YAML (RigSpec) with pods, edges, and continuity policies
• Boot everything with rig up — tmux sessions, harnesses, startup files, readiness checks
• See rigs, pods, and seats in the TUI topology table and graph; inspect projects, specs, feeds, and instance health
• Discover existing Claude Code and Codex sessions in tmux and adopt them into a managed rig
• Snapshot the topology with rig down --snapshot, restore by name with rig up <name>
• Communicate across agents with rig send, rig broadcast, and rig chatroom
• Protect a seat where you type by hand holds automatic messages and wakes instead of typing them into that seat
• Connect Slack through an app you create in your own workspace
• Evolve running topologies with rig grow, rig shrink, rig launch, rig remove

Starter Rigs

Use first-project for the focused first-use path. product-team is an optional larger product-development example:

rig specs preview product-team --kind rig
rig up product-team

For a smaller starter, use conveyor:

rig specs preview conveyor --kind rig
rig up conveyor

How It Works

OpenRig is a local daemon + CLI + terminal UI + MCP server, built on tmux.

CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters

Terminal UI and Workspaces

The TUI shows the team's coordination state; herdr and cmux show the actual agent terminals alongside it. With herdr installed and connected, open the starter's terminals together:

rig terminal open first-project --provider herdr

Key Concepts

• RigSpec: Declarative multi-agent harness definition in YAML.
• AgentSpec: Reusable agent blueprint with skills, guidance, hooks, profiles, and startup contracts.
• Seat: A stable role and address in a rig.
• Pod: A group of related seats with shared guidance and context.
• Discovery: rig discover fingerprints existing tmux sessions. rig adopt brings them under management.
• Snapshot/Restore: rig down --snapshot captures full state. rig up <name> restores from latest snapshot.
• RigBundle: Portable archive with vendored AgentSpecs and SHA-256 integrity.
• Culture: CULTURE.md sets coordination norms for the group.

Agent-Managed Software

A rig can package actual software alongside the agents that manage it. The shipped example is secrets-manager: a HashiCorp Vault instance operated by a specialist agent.

Requirements

• Node.js 22 or 24. Node 20 is no longer supported.
• tmux
• macOS or Linux.

Comparison with Claude Managed Agents

OpenRig is open source and self-hosted, with Claude Code and Codex in the same team. You operate it on your own infrastructure; the selected providers' model usage costs still apply.

Maximizing Apache Spark availability: Mitigating compute stockouts with flexible VMs and other best practices

The surge in AI development has created unprecedented demand for compute capacity around the globe. This can have negative implications for data processing and pipelines with Apache Spark. Whether you are managing your own Spark infrastructure or using a managed service, you can face availability constraints. However, a significant advantage of using Google’s Managed Service for Apache Spark is the availability of flexible VMs, which provide a targeted mechanism to adopt a dynamic, resource-agnostic philosophy and ensure your pipelines remain operational, even during regional or zonal capacity stockouts.

Understanding capacity stockouts

Capacity stockouts occur when demand for a specific machine family (such as N2 or N2D) exceeds available capacity in a target zone or region. For time-sensitive analytics pipelines, rigid single-VM requirements transform standard provisioning into a single point of failure which can result in cluster creation delays, failed executions, and potentially compromised business SLAs.

Flexible VMs

Flexible VMs fundamentally overhaul how a Managed Spark cluster requests compute resources. Rather than binding a cluster to a rigid instance type, flexible VMs allow teams to establish an ordered list of acceptable machine families for master, primary worker, and secondary worker nodes.

Key features

• Multi-family blending: Mix nodes across diverse machine types and generations, combining Gen2 families (e.g., N2, N2D) with Gen4 families (e.g., N4, C4) in a single configuration.
• Mixed storage support: Broaden available capacity pools by allowing storage options to dynamically adapt to the underlying host family's supported disk types.
• Comprehensive cluster coverage: Apply flexible rules to primary workers, secondary (preemptible/spot) workers, and master nodes to guarantee cluster provisioning end-to-end.

Ranked configuration: A strategy for success

A successful flexible VM implementation relies on intentional ranking. By defining a clear hierarchy of options, Managed Spark clusters automatically attempt provisioning, systematically mitigating stockout risks without requiring manual intervention. To improve the availability of suitable VMs, we recommend specifying at least two machine families in the highest priority (Rank 0) flexible VM list.

As an example, for production pipelines standardizing on n2d-standard-16 shapes, the following tiering strategy provides robust resilience against capacity constraints:

For pipelines standardizing on legacy n1-standard-16 shapes, the following tiering strategy helps transition workloads toward newer, more available architectures while preserving operational stability:

Leveraging Hyperdisk Balanced

Unlocking maximum availability with flexible VMs often requires adopting modern storage architectures like Hyperdisk Balanced. Newer instance families (including N4 and C4) rely on Hyperdisk to deliver predictable performance across variable VM sizes. Starting with default IOPS and throughput settings typically provides a reliable baseline for the majority of distributed Spark jobs.

Trade-offs and key considerations

While flexible VMs dramatically improve cluster provisioning success, aligning them with enterprise requirements involves evaluating several architectural and financial factors:

1. Resource quotas

It is no longer enough to have one specific machine (e.g., N2) quota. You need to ensure you have sufficient compute and disk quotas allocated for all specific machine types and disks (including Hyperdisk) defined in their flexible VM lists.

2. Compute flexible Committed Use Discounts (CUDs)

Traditional, resource-based CUDs are tied to specific machine families, which limits flexibility. Adopt Compute flexible Committed Use Discounts (CUDs) to apply savings across multiple VM families and regions.

3. Performance Characteristics

Performance can vary between machine generations, as well as between Local SSD and Hyperdisk. While the Managed Spark team maintains internal benchmarks for these comparisons, actual outcomes are workload-dependent. Testing your specific Spark jobs across these families is essential for understanding SLA impacts.

Additional recommendations

In addition to implementing flexible VMs, there are several other key architectural and scheduling strategies to improve resource availability and workload stability:

• AutoZone: Implement AutoZone routing to allow Managed Spark to automatically select the zone best suited to execute the job based on current capacity.
• Smaller machine shapes: Avoid high in demand, large-core shapes. Design workloads and YARN containers to utilize smaller machine shapes (such as 4, 8, or 16 cores). These smaller shapes are much easier to fulfill from the available GCE on-demand pool.
• Autoscaling: Deploy cluster autoscaling with reasonable maxInstances to manage capacity effectively for bursty or unpredictable workloads without relying on rigid, massive upfront provisioning.
• Partial cluster creation: Configure a minimum acceptable number of primary workers. This allows clusters to spin up under resource constraints and begin executing, while autoscaling can dynamically add remaining workers as resources become available.
• Establish regional fallbacks: Some regions, such as us-central1, can experience high demand. Setting up fallbacks to other regions reduces capacity stockout risks.

Keep your Spark jobs running with flexible VMs

Managing your own Apache Spark infrastructure can be complex, especially when capacity stockouts disrupt your data processing. Utilizing a managed service like Managed Service for Apache Spark provides unique advantages — including built-in platform resilience and access to flexible VMs. By adopting a prioritized fallback strategy with flexible VMs, you can protect your workloads from regional hardware shortages and keep your critical pipelines running.

Introducing enhanced custom event buses in Amazon EventBridge for enterprise-scale event-driven applications

Organizations building event-driven applications on Amazon EventBridge typically start with a single custom event bus in one account. This works well when a single team owns the architecture. As adoption grows across the organization, though, things get complicated. AWS best practices recommend a multi-account structure, which means each team runs in its own account. To route events between them, teams create multiple event buses connected through cross-account rules or bus-to-bus configurations. This workaround reintroduces the operational complexity that serverless architectures are meant to eliminate. Platform teams lose visibility into who is subscribing to which events, cross-account and bus-to-bus routing charges compound quickly, and teams that need capabilities like event ordering are forced to build complex workarounds or adopt entirely different technologies.

Today, we are announcing an enhanced custom event bus in Amazon EventBridge, purpose-built for organizations scaling event-driven applications across teams and accounts. With the new enhanced custom event bus, you can deploy a single, centralized event bus shared across all AWS accounts in your organization, with ordering guarantees, a simplified Subscriber resource, and a new pricing model that delivers improved economics at scale and cost allocation for publishers and subscribers.

Let’s try it out

To get started with an enhanced custom event bus, I navigated to the EventBridge console in the AWS Management Console and opened the Create custom event bus page. I selected Custom event bus, the recommended option labeled New. The page also offered Custom event bus – classic, which continues to receive events and route them with rules and targets. Below the selection, EventBridge showed how the new bus works. One shared bus serves every team in the organization. Publishers send events, subscribers consume only what they need, and EventBridge handles ordering, retention, routing, and delivery.

Next, I configured resource sharing. I turned on Enable event bus sharing and selected Allow sharing only within your organization. I chose AWS account ID as the principal type. I could also share with an organization, an organizational unit, or an AWS Identity and Access Management (IAM) role or user. Sharing uses AWS Resource Access Manager (AWS RAM), so I did not have to set up cross-account permissions or bus-to-bus routing myself.

Organization-wide sharing

With the new enhanced custom event bus, you can create a single event bus and share it across all AWS accounts in your organization. Platform teams deploy one bus and establish it as the central event backbone, eliminating the need to configure cross-account permissions or bus-to-bus routing. Application teams across your organization can publish and subscribe to events on the same bus without waiting for infrastructure provisioning.

Publishers send events without needing to know which teams consume them, and subscribers create their own Subscriptions independently. Platform teams maintain visibility into all event flows and fine-grained control over who can publish and consume events. The new enhanced custom event bus has a default quota of 10,000 Subscribers per bus, and you can request a higher quota. That reduces the fragmentation that occurs when subscriber limits force you to split across multiple buses.

Event ordering

Event-driven architectures work best when consumers are designed around asynchronous patterns, where the order of events does not matter. There are a few cases where order does matter. In a logistics application, driver location updates must arrive in sequence. Out-of-sequence events cause routing algorithms to make decisions based on stale data.

The enhanced custom event bus supports both patterns on the same bus. Publishers can include an EventGroupId when sending events. EventBridge delivers events that share the same EventGroupId in sequence to Subscribers that chose ordered delivery. Other subscribers on that bus can receive the same events without ordering. You can keep events for each driver in the correct order without building complex workarounds, while the rest of your consumers stay fully asynchronous.

To support ordered processing, the enhanced custom event bus includes synchronous invocation for targets like AWS Lambda. Synchronous mode confirms successful processing before acknowledging the event, eliminating the common pattern of placing Amazon Simple Queue Service (Amazon SQS) between an event bus and Lambda to ensure reliability.

Subscriptions

The enhanced custom event bus introduces the Subscriber resource, which combines event filtering, target configuration, retry policies, and dead-letter destinations into a single, manageable unit. Today, achieving the same outcome with EventBridge requires configuring separate rules, targets, and retry settings across multiple resources. Subscribers simplify this by giving each consumer one resource that defines what events they want, where to deliver them, and how to handle failures.

Subscribers also include variable start time options, making it easier for teams to onboard new consumers or replay events to recover from application errors or hydrate new applications.

Event evaluation

Publishers can turn on content-based deduplication so EventBridge detects and drops retries of the same event from the payload itself. You do not have to generate and track a deduplication ID when a timeout or a partial failure sends the same event twice. EventBridge hashes the meaningful parts of the event and collapses matches that arrive within five minutes, which gives those retries exactly-once delivery semantics instead of EventBridge’s usual at-least-once model. If you already stamp your own idempotency token, keep using it. Content-based deduplication is for sources that cannot reliably identify the same event on a retry.

Subscribers can use JSONata expressions to reshape an event before it reaches a target, extracting fields, renaming them, or computing new values when a downstream API expects a different shape. If you already produce Apache Avro or Protocol Buffers events, EventBridge can deserialize those payloads to JSON, allowing subscribers fine grained filtering and routing on the full event payload without having to consume, deserialize, and match or discard on their own.

New pricing model

The enhanced custom event bus uses a new ingress and egress throughput pricing model. Publishers pay for events ingested, and subscribers pay for events delivered. This replaces the per-event model where cross-account and bus-to-bus routing charges compound in multi-bus architectures. For pricing details, visit the EventBridge pricing page.

Existing EventBridge custom event buses continue to work as they do today with no changes required. They now appear as Custom event bus – classic. The enhanced custom event bus is a new resource that you adopt at your own pace. In the console, it appears as Custom event bus.

Now available

The enhanced custom event bus is available today in the US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo) Regions. You can create your first enhanced custom event bus through the AWS Management Console, AWS Command Line Interface (AWS CLI), or EventBridge APIs. To get started, visit the EventBridge documentation or try it out directly in the EventBridge console.

Wrong, not broken

For 20 years, software operations has been built around one question: Is it broken?

We’ve gotten very good at answering it. Metrics, logs, and traces. Distributed tracing that can follow a single request through dozens of services.

And all of it rests on one sensible assumption: When software fails, the failure eventually shows up as something a machine can measure.

Now picture an AI agent handling refund requests. It answers in 600 milliseconds. The error rate is zero. And it tells a customer they’re owed $40 when the policy says $140, because the document it retrieved was last quarter’s version.

Every dashboard is green. Nothing appears to be broken.

It’s wrong.

This week we launched Amazon CloudWatch Omni to observe agents, applications, and infrastructure together, and I wanted to give an inside look at the shift behind it and why it matters.

Correctness now has to be measured at the level of the run. Software has always been capable of being wrong. What changes with agents is how much of the behavior we care about is resolved while the software is running.

An agent adds another set of variables. The same agent, running the same code, can get one request right and the next one wrong. The outcome depends on how the question was phrased, what context was retrieved, which path it took through its tools, and what the model generated.

So “is it doing the right thing?” can no longer be answered fully before release. Some of the answer has to come from production, continuously, across the runs themselves.

That doesn’t replace the questions observability has always answered. It adds new ones alongside them.

Was the work any good? The test suite that ran before launch still matters, and now a live measurement can sit alongside it. Did the agent pick the right tool? Did it route the request correctly? When those scores sit on the same trace as latency and token counts, a team can see that a prompt change didn’t slow anything down but did make retrieval answers noticeably worse.

This creates a second problem: Quality has to become explicit enough to measure.

Human organizations can operate with a surprising amount of tacit judgment. People learn what a good answer sounds like from examples, colleagues, and experience. Not all of it has to be formalized.

An evaluator needs something more concrete. What counts as a correct refund decision? When should the agent escalate?

Building evaluations therefore forces teams to turn some of that tacit judgment into an operational definition of good. In practice, deciding what should be measured can be as useful as the measurement itself.

Where in the chain did it go wrong? Go back to the wrong refund. Maybe the model reasoned badly. Or maybe it did everything right, and a payments service three hops downstream was running an old configuration.

The team investigating it needs to follow one chain of cause and effect, from the customer’s question, through the agent’s decisions, into the services underneath. Agents are becoming components inside applications, so their behavior needs to be visible alongside the rest of the system.

What’s different about the bad runs? Dashboards remain useful because they make important signals continuously visible. They are especially good when a team already knows what it wants to watch.

Agentic systems add important questions that might only become obvious after something unusual happens. Why did refund accuracy drop for European customers this week? Did anything change in retrieval, tool selection, or the services downstream?

Being able to ask those questions directly and have the observability system assemble the relevant telemetry changes how an investigation can begin.

Did the fix actually work? A bad run in production doesn’t need to end as an incident report. The traces where an agent got something wrong can become a dataset. A team can try a change against those examples, compare the new version with the old one, deploy it, and then see whether production behavior actually improved.

That creates a much tighter connection between operating an agent and developing it. The same evidence used to understand a failure becomes part of the test for whether it has been fixed.

More autonomy requires more evidence. Agents get more valuable as they take on more authority. What holds organizations back is whether they can answer a few plain questions. What did the agent do? Was it right? Would we know if that changed?

Authority tends to be extended in steps, much like it is with a new colleague. First, every action gets approved. Then only the unusual ones. Then someone reviews a sample. Eventually, the work gets checked after the fact.

Safety works the same way. Permissions still set the outer boundary, and an agent that isn’t allowed to issue refunds won’t. But permissions describe what’s possible, not whether a particular choice was a good one. A policy can say the agent is allowed to issue refunds. It can’t say whether this refund, to this customer, for this amount, was right. More and more of what matters happens inside that boundary. The way to understand it is the same as for quality: Look at what actually happened.

Put simply, the authority an organization can comfortably give its agents depends on how clearly it can see what they do.

That relationship could eventually become dynamic. Today, the decision about how much authority an agent gets is still largely made by people. Looking further ahead, it doesn’t need to stay static. If quality signals are live, autonomy could widen as an agent establishes a track record, and narrow when quality slips, until someone understands why. We are not there yet, but the pieces needed to build systems like this are starting to exist.

Where we’re investing. This week, we launched Amazon CloudWatch Omni, and it’s our first big step in this direction. It puts agent traces, application services, and infrastructure in one view. It scores agent behavior with 17 built-in evaluators (for things like correctness, faithfulness, and tool selection). Teams can also turn production traffic into datasets and experiments. AWS DevOps Agent joins incident investigations and works from the same telemetry the engineers see. Developers see in their IDE the same traces that operators see in production. The experience is built around OpenTelemetry, with agent instrumentation using OpenInference and AWS Distro for OpenTelemetry (ADOT). It works with agents built on LangGraph, CrewAI, Strands, and other frameworks. It’s early, and we will learn a lot from how customers use it.

Parting thoughts. For higher-consequence work, many agents in production still have people approving important actions. As we build evidence that those systems behave reliably, more of that work can move from approval to review, sampling, and exception handling.

Everything we already know how to observe still matters. Agents run on services, databases, networks, queues, and infrastructure, and all of those systems still need to be understood when something goes wrong.

What’s being added is a new set of questions. Alongside understanding whether the system is running as intended, we increasingly need to understand whether the work it is doing is good.

The teams that can answer both will be able to give their agents more responsibility with greater confidence.

That’s what we’re building toward with CloudWatch Omni.

Earlier this year, I wrote a paper introducing Robotics Harness Optimization (RHO). In RHO, we use evolutionary search to improve robot policies that are whole code repositories. We tested it on repositories that both excluded and included LLMs at inference. The former are static codebases and are akin to what robotics engineers ship to companies as integration solutions while the latter are what researchers have been exploring through Code-as-Policies (CaP).

A few weeks after we released RHO, a new approach came out: Graph-as-Policy (GaP). In GaP, humans write skills (nodes) and LLMs merely have to stitch them together (connect them with edges). So naturally I was asked: can RHO optimize a graph? 🤔

In the rest of this post, I’ll share what happened when I applied RHO for fifty generations over an example graph from the GaP codebase. TLDR:

• 5.27× Throughput gain over the baseline
• 4.17 → 1 Grasps per trial
• $37 Total search cost, both experiments

Graph-as-Policy

Graph-as-Policy (Chen et al., arXiv:2607.05369) replaces end-to-end policies (think RL trained policy or a VLA) with a directed computation graph whose nodes are individually meaningful skills: observe, perceive, compute a grasp, move, release. Their project page puts it plainly: the graph is the policy.

These graphs, like CaP before them, exhibit some interesting properties. First, the policy is source code you can read and diff, so a change can be quoted in lines. Next, failures localise to a named stage instead of somewhere unknown in a neural network. Lastly, edits are cheap, local, and searchable. Our evolutionary search process can propose “add a node” and score it without needing to collect demonstrations.

The starting graph from the GaP repo has twenty nodes (eighteen inside three subgraphs, plus the done and abort terminals), wired by conditional edges that route on each subgraph’s exit value.

And here is the query it perceives with:

# seed/graphs/grocery_packing/workflow.json, perceive_item node inputs
"object_name":        "grocery item",
"object_description": "a packaged grocery product such as a can, box,
                       carton, jar, or bottle. Never the wicker basket
                       or storage container that the items are being
                       packed into."

The experiment

The example from the GaP is grocery packing with a simulated Franka Panda arm. It uses a LIBERO scene with a table of groceries, one wicker basket, and a sentence as the input task/prompt statement: “Pick the cream cheese and place it in the basket.” In this LIBERO setup, the hard part is object localization: the products are 20–40 pixels across in the camera image and several look alike. The robot has no privileged access to where anything is. It gets wrist and exterior color and depth cameras, and the sole prompt sentence.

Besides this introductory task, we look at the full benchmark which has eleven instructions. Ten of them name a single item: alphabet soup, cream cheese, salad dressing, BBQ sauce, ketchup, tomato sauce, butter, milk, chocolate pudding, and orange juice. The job is to put that one item in the basket. Nothing else. The eleventh says “Pick all the objects and place them in the basket,” and it’s played across ten different table layouts.

Here’s the interesting thing. The exemplar graph never actually reads the instruction. Its perception node is hardcoded to query for “a grocery item,” so it finds one, carries it to the basket, fails the completion test, and loops around to try another. It’s basically playing process of elimination. On the ten single-item instructions it grasps an average of 4.17 objects to complete a task that needs exactly one.

To see what RHO would do with this, I ran two searches of fifty generations each over that same starting graph. In the first experiment, Compose-Only, I allow the agent to only add new nodes and rewire the graph, but has to use the human-written skills as given. Compose-and-Edit can do all of that and also rewrite the skills themselves.

In HELIX, we can express the difference of the two experiments in three lines of configuration:

# Experiment 1 - Compose-Only: may rewire the graph, may not edit the shared skills
registries = ["…/open-robot-skills"]

# Experiment 2 - Compose-and-Edit: same freedoms, plus its own writable skill copy first
registries = [".", "…/open-robot-skills"]

Results

Following the GaP paper, I report throughput: successes per hour, or success rate divided by cycle time.

The two RHO experiments are indistinguishable on accuracy; their success-rate intervals overlap almost completely. However, their throughputs tell a different story.

Why it’s faster

Look at the pass count. Per-iteration cost is worse for both searched policies: 28.8 seconds for the baseline against 33.8 and 37.9. They made the loop run fewer times, while spending slightly more inside each pass. The baseline’s pass count has a long right tail: a mean of 5.04, with trials running out to eighteen passes. Both searched policies are single spikes.

Artifact one: disambiguation, worth roughly four grasps

The baseline asks for a generic grocery item, so it picks an arbitrary one. Compose-Only added a node that runs before perception and resolves the target out of the instruction.

Artifact two: the completion check, worth the gap between the two searched policies

Only Compose-Only found this one. The baseline and Compose-and-Edit have no equivalent at this point in the graph. Having placed the right item, they loop back and run a whole additional perception cycle (about 34 seconds) before their completion check can fire. Compose-Only asks, gets an answer, and exits.

The part that only works in simulation

The completion check calls sim.check_success, the simulator’s own goal predicate. The starting graph already polls it after every perception pass, so all three policies use it; Compose-Only just calls it earlier. A real robot has no such oracle. Without it, Compose-Only would take one extra perception pass per trial (about 38 seconds), which puts it at roughly ≈2.8× the baseline instead of 5.27×.

What I take from this

The main lesson for me is that it doesn’t much matter what form the robot policy takes, as long as it’s code. The same RHO loop has now worked on three pretty different kinds: repositories on CaP-Bench, an LLM agent’s harness on RAI, and a Graph-as-Policy here.

The recipe is the same every time: hand a coding agent the policy’s source, score what it writes in simulation, and keep what works. The best part is that in all cases, we are using RHO to improve robotics policies without the need for human demonstration data.

At WHOOP, some of our most demanding infrastructure challenges arise when we need to run a computation at population scale. Earlier this year, we needed to simulate one of our ML models across a large internal dataset to support a time-sensitive research workload. Each simulation used several weeks of historical inputs, and the total came out to roughly 15.8 million inference tasks.

The tool we had on hand was built for a much smaller job a couple of years ago. At its current per-task latency, completing the new run would have taken more than two months, far too slow to get researchers the data they were waiting on. We brought that down to six days. This post covers the changes that made this possible.

The starting point

The original tool was simple. A one-shot producer read a manifest from S3 and dropped one SQS message per inference task onto a queue. A worker pool received those messages and, for each one, fetched the corresponding input data, called our internal classification service over HTTP, and uploaded the labeled output back to S3.

This was fine for its original use case, a much smaller validation run. But at 15.8M tasks and about 45 seconds each, it was nowhere near fast enough for what we needed now.

Skipping the network

The biggest source of latency was the HTTP boundary between the worker and the classification service. Each task required dozens of chunked round trips to the API, which in total accounted for more than half of every task. Combined with JSON serialization on both ends and per-request overhead, the network ended up being the dominant cost.

Because we own the classification service, we could remove that boundary entirely. We pulled the pipeline into the worker as a library, loaded the model once per process at startup, and ran it directly on the data we had already fetched. That change took per-task time from 45 seconds to about 21.

Parallel workers per pod, and the fork deadlock

We wanted to unlock the research as quickly as possible, so we started with the fastest change available: two worker processes per pod instead of one. We first reached for Python's multiprocessing.Pool, which defaults to fork on Linux. The workers deadlocked the moment they tried to run inference.

The pipeline relies on native libraries, including XGBoost and NumPy, whose underlying runtimes can initialize thread pools and internal locks. Forking after that initialization can leave child processes with an inherited lock state but without the threads needed to release those locks.

We fixed it by setting the start method explicitly:

multiprocessing.set_start_method("spawn")

spawn starts each worker as a fresh Python interpreter rather than copying the parent's memory. It's slower at startup, but it sidesteps the inherited-lock problem entirely.

When we ran two workers on our existing pod size, they contended for CPU and each task got slower. We increased the pod's CPU allocation, which cleared the contention and brought per-pod throughput close to 2x. With some additional tuning across the pipeline, we shaved off another 4 seconds per task, bringing it down to 17 seconds.

Threading state across a chain of tasks

Another complication was that the steps within each task chain were not independent. Step N+1 depended on a small piece of state computed during step N, so we couldn't just fan out every step in a chain and run them in parallel.

To solve this, we refactored the pipeline so that the producer inserted only the first task in each chain, and each worker took it from there. The worker processed the task, wrote the output, threaded the resulting state into a new SQS message for the next task, and enqueued that back onto the same queue. The chain continued until it was complete, and because the state traveled with the message rather than living on any one worker, different tasks in the same chain could run on different pods.

One message per task chain, processed one task at a time through the queue.

At-least-once delivery, at five hundred workers

Standard SQS queues guarantee at-least-once delivery, which means the same message can occasionally be handed to more than one worker. At a small scale, these duplicates are rare enough to ignore. At 500 workers, duplicates became frequent enough to matter. Two workers would both pass our idempotency check, both start processing, and the loser of the S3 upload race would crash on "file already exists." The crash would also take out sibling tasks on the same pod.

Our first instinct was to use overwrite=True, but we decided against it, since our worker enqueued the next task's message after the upload completed. If both workers succeeded, both would also enqueue, and we'd get two parallel copies of the same task chain from that point on. The bug would compound with every subsequent task.

Instead, we wrapped the upload in a try/except and caught the "file already exists" exception. The write is atomic, meaning the file either lands completely or not at all, so that exception told us the other worker had already finished. We exited early without re-enqueuing.

Worker B's early check passes, but the collision is caught at the storage layer.

Aggregating millions of files

The main job left us with millions of small CSVs in S3 that needed to roll up into summary tables so they could be interpreted by our Research team. A single-pod aggregator would have taken days, so we reached for the same pattern. A new producer sent one message per task chain, and a worker pool downloaded the files produced by each chain, computed the per-task summary in memory, and wrote the result to a pod-level CSV. Because S3 has no append operation, each pod accumulated rows in memory and overwrote its own pod-level file after every chain. A small final script then read the few dozen pod files at the end to write the global summary.

The number of output files depended only on the number of pods. The producer was also incremental, which let us start aggregation before the main job finished and cut end-to-end runtime by roughly 10 hours.

Together, these changes enabled us to run inference using our machine learning algorithms across all 15.8 million tasks and consolidate those results for our Research team in six days, instead of two months.

The merge script only has to read one file per pod.

Results

The final per-task time was about 17 seconds, down from 45.

What we learned

• When you control both ends of a network call, removing it entirely usually beats any amount of tuning around it.
• Forking a process that has already loaded a native ML library can cause a deadlock. Pick spawn upfront to avoid it.
• Idempotency has to live at the output. A task-level check alone isn't enough. Anything downstream that uses the output's existence as a signal needs to be part of the same fix.

A guest’s interaction with Airbnb doesn’t pause to wait for a nightly batch job. Someone might browse a dozen listings on a Tuesday afternoon, run a new search that evening, and expect the next search to reflect the recent activity; it’s also to Airbnb’s benefit for that to be the case. In our previous post, Personalizing Airbnb search by learning from the guest journey, we described how we built a Transformer-based sequence encoder that creates better, more personalized search rankings for a guest using the booking, review, and browsing data that is most relevant to them — their own. That system ran as a daily batch job: each night it processed the previous day’s activity and refreshed embeddings for guests who had something new to show for it.

That design worked well, but it left a gap. Activity from earlier the same day wouldn’t show up in the embedding until the following day’s run, on top of the pipeline’s own processing lag — in practice, up to nearly two days of staleness. For a guest actively planning a trip, that meant the ranking model was often working from a slightly outdated picture of what they wanted, and the recent activities are often highly relevant to current search needs. This is a limitation that our original JourneyFormer research had already flagged as needing new serving infrastructure to solve.

In this post, we describe how we closed that gap by adding two new capabilities to Chronon, Airbnb’s feature platform: Near-real-time Model Transform and Push Mode. Chronon is an open source project, and these capabilities have been contributed back to our public repo.

Background

To keep a multi-layer Transformer off the critical serving path, our original design split inference into two stages. Offline, the sequence encoder would run as a scheduled batch job: each night, it would process the previous day’s guest activity and write a fresh embedding to a low-latency store for any guest who had something new to show for it. Online, retrieval was already real-time: the moment a guest ran a search, the ranking model read that guest’s embedding straight out of the store and combined it with the live query to score candidate listings.

This split kept serving latency low while still letting every ranking decision draw on years of guest history — but it meant an embedding was only ever as fresh as the last completed batch run.

Challenges

Moving from daily batch updates to near-real-time updates introduced three potential challenges that we needed to address:

• First, staleness had two separate sources: the batch schedule itself, which only ran once a day, and processing lag within that job, which pushed effective staleness closer to two days. Fixing only one of these wouldn’t have been enough to fully close the gap; we needed a pipeline that could react to a guest’s activity as it happened, not simply run more often.
• Second, our sequence encoder was built to run as a scheduled inference job over a full day’s snapshot of guest events, not as a service reacting to individual activity events one at a time. Wiring model inference into a real-time pipeline meant rethinking where and how the encoder got called, without duplicating the offline logic used for training.
• Third, guest activity signals — page views, searches, and other interactions — arrive as independent event streams. Reacting to any one of them in isolation risked missing the fact that these events need to be merged with a guest’s longer-term profile and routed through the encoder consistently, so the resulting embedding stays comparable to the one produced by the batch pipeline it replaces.

Solutions

We addressed these challenges by building two general-purpose capabilities into Chronon, rather than by building a modified pipeline specific to our use case.

Push Mode in Chronon

The first is Push Mode. Chronon already runs streaming jobs that keep feature values up-to-date as new events arrive. Push Mode extends this by having a streaming job publish a lightweight notification as soon as it commits a new feature value, instead of waiting for something downstream to poll for it. This turns a reactive step into an event-driven trigger: the moment a guest’s activity feature updates, downstream consumers are notified and can act immediately. For our use case, this meant a guest’s newest search or listing view could kick off embedding generation right away, instead of waiting for a scheduled job to notice it.

Near-real-time model transform in Chronon

The second is Near-real-time (NRT) Model Transform, which lets model inference run as part of the same streaming pipeline. Historically, running a model meant either embedding its logic directly into application code or waiting for an offline batch job. NRT Model Transform lets Chronon call an already-deployed model — in our case, the same Transformer sequence encoder from the batch pipeline — directly from within the streaming flow, and write the result back as a feature value that is immediately available for serving.

Integration

Combining the two, our new pipeline works like this: a guest’s activity event, such as a page view or a new search, is captured by a streaming job that merges it with the guest’s existing long-term and short-term sequence data. Push Mode then signals that new sequence data is ready, and NRT Model Transform runs the sequence encoder over it, producing a fresh embedding without waiting for the next scheduled run. The embedding is written to the same low-latency store the batch job uses, so the ranking model retrieves it exactly as it always has — the only difference is how quickly the embedding it retrieves has been updated.

Because both capabilities live in the platform rather than in a use-case-specific pipeline, other teams working on different near-real-time use cases can build on the same foundation.

Results

The impact showed up on two relevant dimensions of our search results: freshness and quality.

On freshness, we replaced a pipeline where embeddings could lag actual guest behavior by roughly two days with one where the typical delay is well under a minute. In practice, updates often land within 10 to 30 seconds of the underlying activity. A guest who views a handful of new listings can now have that context reflected in their very next search.

On quality, offline evaluation showed a +1.67% improvement in Normalized Discounted Cumulative Gain (NDCG) over the daily-batch baseline — a large jump for a ranking system that has already been refined for over a decade, where even gains of a fraction of one percent are considered meaningful. Online A/B tests confirmed an approximately one-third of a percent increase in uncancelled bookings. This confirms something we suspected, but hadn’t measured directly: freshness itself is a meaningful source of ranking quality. The same guest representation becomes more valuable to the ranking model, and to the guest themselves, simply by being more current.

Rather than a one-off integration, Push Mode and NRT Model Transform represent general platform capabilities that we expect to serve as a foundation for other near-real-time modeling efforts across Airbnb. Since Chronon is open source, and since both features are already available in the public repository, their impact extends far beyond Airbnb. With these additions, any team running Chronon to build a near-real-time model is able to build on the foundation we’ve created.

Conclusion

Our previous post described how encoding a guest’s full history — their bookings, reviews, and recent browsing — allows our ranking system to better prioritize relevant listings based on current search intent. This post closes the remaining gap: making sure that understanding reflects a guest’s most recent activity, not just what they did as of last night’s batch run.

By combining Push Mode’s event-driven triggering with NRT Model Transform’s in-pipeline model inference, we turned a daily batch process into a near-real-time one, cutting effective staleness from roughly two days to less than a minute, and improving offline ranking quality by +1.67% NDCG in the process. More broadly, the pattern we used here: react to an event, merge it with existing state, run inference immediately, and serve the result; is one we expect to generalize to other guest-facing models that depend on freshness.

ALTER TABLE users ADD COLUMN status text DEFAULT 'active';
CREATE INDEX CONCURRENTLY users_created_at_idx ON users (created_at);
ALTER TABLE orders ADD CONSTRAINT orders_user_id_fk FOREIGN KEY (user_id) REFERENCES users(id) NOT VALID;
ALTER TABLE orders VALIDATE CONSTRAINT orders_user_id_fk;

ALP: Adaptive Lossless Floating-Point Encoding in Apache Parquet

Apache Parquet has added the Adaptive Lossless floating-Point (ALP) Encoding – a new lightweight floating-point encoding with compression ratios similar to zstd, much faster decompression, random-access support, and GPU- and SIMD-friendly decoding.

ALP works best for decimal values stored as floating-point types (32-bit FLOAT and 64-bit DOUBLE), such as

• Monetary values (exchange rates, public funds, stocks, prices, etc.) – e.g., 1.2345 or 22.03
• Geographic coordinates (longitude/latitude) – e.g., 42.3584, -71.0598
• Scientific measurements (temperature, pressure, speed, degrees, etc.) – e.g., -273.15, 9.81, 3.14159

ALP is not suitable for data that uses a wide range of exponents or a large number of significant digits, such as vector embeddings, which typically span the full floating-point range. Such data can continue to use existing Parquet features such as PLAIN or BYTE_STREAM_SPLIT encoding followed by general-purpose compression like ZSTD.

Decimal values can be stored with Parquet’s DECIMAL logical type, but that type requires the precision and scale to be known and declared up front and cannot store values outside that range. For this reason, systems commonly store decimal values as FLOAT or DOUBLE when the exact shape of their data is not known beforehand. For example, JavaScript’s only number type is DOUBLE, common data science tools such as pandas infer float64 for decimal-looking values, and NumPy has no decimal dtype at all.

Why ALP?

Encoding floating-point data is a complicated engineering problem due to the nature of floating-point values. They do not exactly represent most real numbers. This leads to rounding errors that prevent the use of existing lightweight encodings like Delta and Frame of Reference.

Prior to ALP, BYTE_STREAM_SPLIT was the only non-dictionary alternative to PLAIN for FLOAT/DOUBLE values in Parquet. It does not reduce the size of the data but can improve the compression ratio and speed when a heavyweight compressor is used afterwards.

Heavyweight compression effectively decreases the data size, but at the cost of:

• Decode speed – decompression speed is often the bottleneck in data access.
• Random access – reading one value requires decoding an entire data page containing potentially thousands of other values.
• Data dependence – variable-length compression means that decoding a value requires decoding previous values, making it hard to parallelize with modern hardware such as SIMD instructions and GPUs.

ALP is designed to solve all three of these problems for common data patterns, while achieving a similar compression ratio to heavyweight compression.

Parquet applies an encoding first, then an optional compression codec as a separate step. The charts below compare the PLAIN and BYTE_STREAM_SPLIT encodings followed by ZSTD compression with the ALP encoding and no additional compression. Users can expect ALP to decode 10x faster and retrieve individual values thousands of times faster, with a slightly lower compression ratio and slightly faster compression.

Note that these numbers are for the pre-release Rust implementation of ALP, and we expect performance to improve as implementations are optimized and tuned. Even so, ALP is already faster than zstd in many cases, despite years of optimization work on zstd implementations.

Technical Overview

ALP takes advantage of a common pattern: many values stored as FLOAT or DOUBLE originated as decimal numbers with relatively few digits, such as prices or measurements. This section explains the intuition behind ALP and then covers the encoding and decoding pipelines in more detail.

ALP encodes floating-point values in batches called “vectors”, ranging in size from 8 to 32K values (e.g., 1024). Each value in a vector is encoded as an integer, and the vector stores two integer parameters shared by all its values: an “exponent” (e) and a “factor” (f). Each vector can use a different exponent and factor. The original value is recovered by computing:

value = encoded × 10f × 10-e

This calculation uses floating-point arithmetic, which rounds to the nearest representable value and thus may not reproduce the original value exactly. When that happens, ALP stores the original full-precision value separately as an “exception”, keeping the encoding lossless. Special values such as NaN, ±Infinity, and -0.0 are also stored as exceptions.

Within each vector, the encoded values are stored by subtracting the lowest value (the frame of reference) and then bit-packing to a fixed width. Exceptions are stored directly after the encoded array.

Example

Consider encoding the value 8.0605, which cannot be exactly represented in IEEE 754. It is stored as the 32-bit floating-point number 8.06050014495849609375. It can also be encoded as 80605 with exponent e = 8 and factor f = 4.

Picking the exponent and factor well is key to ALP’s performance. Each Parquet writer is free to choose them for each vector using any algorithm. Typically, the exponent is chosen to capture most decimal digits in the vector while minimizing exceptions, and the factor is chosen to remove as many trailing zeros as possible.

To encode this vector, the parameters e = 4 and f = 3 are chosen first. Then the values are transformed to integers using the formula encoded = round(value × 104 × 10-3). Each integer is checked by reversing the transformation. Values that do not round-trip are stored in the exception array. The minimum value across the vector becomes the frame of reference and is subtracted from each integer, and the resulting deltas are bit-packed.

Decoding a vector requires similar steps, but in reverse. First, the bit-packed deltas are unpacked, and the original values are computed. Then any exceptions are “patched” by overwriting the output array at the exception positions with the exception values.

Acknowledgements

ALP was first published in a SIGMOD 2024 paper by Azim Afroozeh, Leonardo Kuffó, and Peter Boncz from the Database Architectures Group at CWI. The Vortex and Lance formats adopted ALP early, demonstrating its benefits in industrial applications. In late 2025, the community began the standardization process. Along with the authors of this blog post, many community members contributed, including Divjot Arora, Arnav Balyan, Devan Benz, Ryan Blue, Alkis Evlogimenos, Xuwei Fu, Vinoo Ganesh, Adrian Garcia Badaracco, Curt Hagenlocher, Amogh Jahagirdar, Micah Kornfield, Robert Kruszewski, Julien Le Dem, Kevin Liu, Steve Loughran, Ismaël Mejía, Antoine Pitrou, Adam Reeve, Ed Seidl, Russell Spitzer, Matt Topol, Jeffrey Vo, Daniel Weeks, Gang Wu, and Zehua Zou.

Ecosystem Adoption

The encoding was released as part of parquet-format 2.14.0 in September 2026. ALP is already supported in at least one major open-source implementation (the parquet 60.0.0 Rust crate), and we expect other Parquet implementations to add support in the coming months.

Conclusion

ALP brings fast, parallelizable decoding and practical random access to floating-point data in a standard form that any Parquet implementation can read once it adds support for the encoding. Its addition is one more example of Apache Parquet evolving to meet the needs of modern data systems.

Resources

• ALP Encoding Specification
• Apache Parquet Format Specification
• Implementation Status Page

Collections call list

I need the January 15 collections call list. Looks like Commerce and Stripe disagree on some subscription statuses— which accounts should we call, and how much MRR is at risk?

107 accounts to call, with $139,131/month of MRR at risk and $483,487 of unpaid invoices behind it. The important finding is that the Commerce/Stripe status disagreement is not the call list...

If there was one thing that was obvious from Meta Connect this year, it’s that the social media giant is all-in on its burgeoning line of smart glasses.

Indeed, the glasses were pretty much everywhere at the annual event, where Meta shows off its newest hardware and AI products. Both Meta staff and the flocks of influencers who frequent the event seemed to arrive with the glasses glued to their faces. Most of the demos the company offered this week also involved the glasses.

I swiftly joined the bespectacled masses and found myself trying on pair after pair of Meta’s high-tech specs.

One of the more notable products I had an opportunity to demo were Meta’s new, still-unreleased, audio-only smart glasses. News of these glasses emerged not long after the company weathered accusations that it was selling “pervert glasses,” with critics alleging that its camera-equipped specs could be used for nefarious surveillance purposes.

The new glasses come equipped with six microphones, but no camera, and they have no native way to record your surroundings, which should go a long way toward easing privacy concerns. They are significantly lighter than any of the other smart glasses I’ve worn, and they were quite comfortable.

The Meta staffer I talked to emphasized the glasses’ entertainment and communication options: You can listen to music easily (they’re more comfortable than earbuds) and take phone calls without reaching for your phone.

The glasses will also integrate with Muse, Meta’s personal agentic system, which can carry out tasks on the user’s behalf. The new integration, which isn’t yet available to the public, lets wearers speak to Muse and give it commands verbally. Meta also plans to personalize the agent, letting users pick from an assortment of cute digital avatars that can represent the agent when it communicates with them.

I was given an opportunity to try this out, which was fun but also somewhat comical. You have to be very direct with the agent, and you can’t talk to anyone else at the same time or it will get confused. Problematically, I kept chatting intermittently with the Meta staffer who’d given me the glasses, and the agent kept thinking I was speaking to it, so it would talk over her.

Still, in the right context, it’s easy to see how this new integration could be incredibly useful. If you don’t mind being seen in public talking to your own sunglasses, you’ll be able to ask Muse to take care of various digital tasks for you, like sending emails or reciting to-do lists, and it will handle them while you’re out grocery shopping or having a beer. You can also ask the glasses anything, and like a mobile version of ChatGPT, they’ll spit out an answer. (I asked the glasses a question about World War II, and they gave me a succinct and historically accurate response.)

Finally, I also got to test-drive a second audio-only pair: Meta’s new glasses for the hearing impaired. Given that hearing loss affects many families (some 50 million Americans are said to have some level of hearing loss), this device, unlike a lot of other modern tech gadgets, serves a clear and practical purpose.

I spoke briefly with a member of Meta’s research team who said the glasses had been in development for about five years, and he pointed out a price difference that could make them appealing: Whereas a lot of hearing aids can run as high as $1,600, the glasses will sell for $150.

The experience of wearing these glasses was interesting. Meta had me put earplugs in before trying them on to simulate the hearing loss that the glasses are meant to help users overcome. Once the glasses were on, they seemed to amplify the voice of the person I was talking to. Users can switch the amplification from focused, which zeroes in on the person in front of them, to omnidirectional, which picks up sound from all around them, depending on how they want to experience their surroundings.

Mark Zuckerberg has made it clear that he believes smart glasses are the future, and it’s evident that his company is doing its best to fulfill that vision. But smart glasses remain a niche that has yet to truly find its footing. What was most obvious at Connect is that Meta has — in an attempt to succeed where others have failed — cast a very wide net, trying to make its glasses stylish, functional, and, most of all, useful.

Is this the future? Unsurprisingly, everyone at Connect seemed to think so. I suppose we’ll have to see if the rest of the world follows suit.

Code as the Source of Truth

The question of whether Figma or code should be the source of truth was always a debate. One side would “win” the debate, then waterfall everything to the other skillset. Over time, features and components would get out of date, because design and engineering weren’t talking as much as they should have been, people got busy, work wasn’t properly tracked, etc. Or maybe designs of a new component would be inaccessible during the handoff stage, or have other technical challenges that weren’t brought up until engineering got a look, and now you’ve wasted precious delivery time. I’ve been guilty of this myself — in previous work, I was syncing variables from Figma into code.

But now, with AI tooling, code being the source of truth makes it easier than ever for design and engineering to be a REAL, single team. More folks are starting to become “design engineers” (“design technologists”, or simply “builders”) — people leveraging AI tooling to bridge their skillset to ship. And some folks may be thinking: “aren’t you shipping slop then?” No. Let me explain.

Start small by bridging design and engineering. Enable a designer to be more like an engineer by using tools to prototype with real, coded components, and then hand them off to their engineering subject-matter expert to make them production-ready. In the other direction, let an engineer push things into Figma directly, where they may not have a lot of experience, and then have the design subject-matter expert tweak things to their high standards.

The key is that you always have a subject-matter expert in the loop at every step of the way, verifying the output and reasoning about whether it’s “good”. Just like reviewing peers’ work. Part of that is saying “no” or deciding not to ship anything at all when an idea doesn’t make sense. You don’t ship slop — you ship code and designs you’d stand behind, no matter who the author was.

The old way of working doesn’t make sense anymore.

It’s ridiculously inefficient. Instead, get everyone in the room talking and pairing, like we used to do in the old days. Engineers, teach your designers coding patterns and practices. Designers, teach your engineers design and Figma practices. Move more efficiently with the help of AI to build the best Design System or product you can.

Working this way accelerates product delivery. It allows like-minded folks to bridge their skills — not replace each other. Lift each other up. Complement each other’s skillsets and allow for growth opportunities.

And this is just a step in that direction. Over time, as engineers and designers work more closely together, the “title lines” begin to blur. Then the team becomes people who ship things. And that seems pretty awesome.

The room where creative teams meet, align and AI takes action

Bring your assets, present at the highest quality, review together, make decisions, and let AI agents apply them, live. All within the same shared context.

The Problem We Are Solving

With AI, assets are created faster than ever. But the review process hasn't caught up.

Feedback is scattered everywhere, decisions get lost after sessions, approval cycles take forever, and versioning has reached insanity. Now, humans and traditional review processes are the bottleneck.

The Solution: Pactto

The AI-native platform for humans and agents to collaborate, present, review, act, and approve assets.

Pactto gives your team persistent creative rooms. Each room is a smart canvas that supports videos, images, PDFs, SVGs, audio, and multi screen sharing, assisted by an AI agent that's always available, with full context. Your whole team sees the same work, hears the same conversation, and makes decisions together.

AI turns feedback into edits, summaries, tasks, all in the browser.

Room Memory: The room gets smarter the more you use it.

Unlike Zoom or Google Meet, where context disappears when the call ends, Pactto rooms remember everything. Every conversation, every decision, every piece of feedback.

Come back next week for a follow-up review and the AI already knows what was discussed, what was decided, and what still needs attention. No “let me pull up the notes from last time.” The room IS the notes. Context doesn't disappear. It compounds.

Live Editing: Say it. Watch it change. Right in front of everyone.

The director says “Let's add more people to the background here.” The AI assistant suggests a warmer grade. One click. The image updates on the canvas. Everyone sees it. The director says “a bit more.” Another click. Done.

Generate three alternative hero shots. They appear on the canvas. The team picks one. Moves on. Create a doc with all the action items from today's session. It's already there.

The AI assistant is always listening, building context, suggesting actions, and taking action. You can even add your own rules and customize the assistant's behavior per room to match your team's workflow.

Real-Time Translations: No Barriers.

The Pactto AI Assistant listens to every word, transcribes the conversation in real time, separated by speaker and timestamp, and translates it live into each participant's language.

A director in LA speaks English. A colorist in São Paulo reads every word in Portuguese. A producer in Madrid follows along in Spanish. No interpreters. No delays. No “sorry, can you repeat that?”

Every creative team does three things. Pactto accelerates all of them.

01 Present: Present your work at the quality it deserves.

Not through a compressed screen share. Pactto plays video at studio quality, for everyone at the same time, without any lag. Color-accurate. Frame-accurate. No compression artifacts. No dropped frames. Multiple people can share screens simultaneously.

02 Review: Voice comments in. Agents act, live.

In Pactto, the AI assistant captures feedback as a structured comment with full context. Then it suggests a warmer grade. One click. The image updates on the canvas. Everyone sees it. You can even speak your comments instead of typing. Draw directly on any frame with lines, shapes, text, freehand. Pin comments to specific frames or frame ranges.

03 Approve: Approve before the conversation ends.

In Pactto, decisions happen in the room. Docs update live. Approvals get tracked. Rooms persist. Every decision, every asset, every version, exactly where you left it. Every stakeholder gets notified, every status gets updated, everything moves forward.

Easily bring your assets into the room. No matter where they come from.

Drag assets in from your computer. Pull them directly from Adobe Frame.io. Thanks to a partnership with Adobe, your Frame.io library lives a click away from your Pactto canvas. We also support Google Drive and Google Sign In.

The assets you've already organized, versioned, and stored flow into the room where the conversation happens. And once they're on the canvas, the AI agent has full context on everything: the brief, the conversation, the assets, the annotations.

OpenAI appears to be preparing a wider rollout of its Ultrafast API mode around DevDay on September 29, with new references showing up across the OpenAI Platform and API documentation.

TestingCatalog spotted a dedicated speed selector being prepared for the Responses API Playground (currently hidden), where developers could choose between Standard, Fast, and Ultrafast processing. OpenAI has already officially previewed Ultrafast with GPT-5.6 Sol, describing speeds of up to 750 output tokens per second and up to 14× faster inference than Standard. Access remains limited to selected customers, and OpenAI confirmed that the mode is powered by Cerebras.

The timing makes broader availability during DevDay plausible. OpenAI has since released the GPT-6 family, including GPT-6 Sol and GPT-6 Astra, making support for these newer models a key thing to watch. No one has confirmed that every GPT-6 model will support Ultrafast at launch.

For developers, the main trade-off will likely be economics. Standard, Fast, and Ultrafast could let organizations choose latency based on each workload's value, reserving higher-cost inference for applications where response time directly affects revenue or productivity.

The feature also fits OpenAI’s broader infrastructure strategy. The company announced a 750 MW Cerebras partnership earlier this year, with capacity being deployed in stages through 2028. TestingCatalog has separately spotted new OpenAI Platform onboarding tiers, including an Accelerate option aimed at production workloads. Together, these changes suggest DevDay could focus heavily on API infrastructure, compute tiers, and tools for developers building production AI systems.

Let's talk about trading compute

Do you guys see what’s happening in the market right now?

Deals are clearing above $24/gpu/hr for some B300s with pricing for short term (<1 year) compute hovering above $7. Actually by the time you finish reading this it will have gone up again. I’m not even going to entertain the ridiculous VR pricing that’s starting to float around, let alone everyone’s promises of Q1 deployments.

Maybe one day I will share my thoughts on the current state of the public and private credit markets (no one in SF somehow cares that the 10y just passed 5%) and potential oversupply, but today I want to talk about trading compute

There’s an emerging market of compute derivative products and I believe this market could fundamentally change how neoclouds and anyone adjacent can grow as well as protect themselves. A 5 year deal asks me to take a huge bet on demand to secure an affordable rate. I'd like to pay for protection against expensive GPU-hours while leaving myself room to change how many hours I rent. A supplier or trader willing to carry the price risk could earn that premium.

For an inference cloud, this is a pretty urgent problem. If I sell a customer fixed-price service while my GPU bill floats, I've taken a position on compute prices whether I meant to or not.

Buying before the customer signs

Say I'm quoting a fixed price to a video gen customer with a distribution deal pending. They'll decide whether to launch in 12 months. If they do, I need 2,048 B300s for their first 3 months, months 13-15. That's 4,485,120 GPU-hours at 730 hours per month.

A vendor offers me those 2,048 B300s starting today at $4.15/gpu/hr if I sign for 5 years: 2,048 × 4.15 × 24 × 365 × 5 = $372,264,960.

That buys 60 months of compute starting now. The customer has outlined a three-month launch window a year away. Ay, there's the rub.

If I make a firm reservation for their launch now, I’m committed even if the deal falls apart. If I wait, the customer might launch just as everyone else wants the same GPUs. I'd like their success to be good news for my margins too. In fact, I'd pay a bit more on average if it meant I could resize the fleet more often and take some of the sting out of an expensive renewal. The question is how much that protection costs.

A call option would help here. I pick a rental benchmark and a price I'm worried about paying above called the strike. For this launch, suppose I buy a call on the average rental index over months 13-15 with a $4.50 strike and settlement at month 15. If that average is $8, the call pays $3.50 per covered hour. If it's $2, the call pays nothing and I get the cheaper rent.

If my average rental price S matches the index, the math becomes: S − max(S − 4.50, 0) = min(S, 4.50).

That's a $4.50 ceiling on the matched quarter's rent before the option premium and financing. The rental purchase stays separate so I can choose whether to make it after the customer decides.

That still leaves me with a customer expecting 2,048 GPUs on launch day. I'd have to secure them through a separate capacity agreement or accept the risk of sourcing them later. Reserving capacity has its own cost and supplier risk. For the example below, I’m assuming I can source the GPUs and cover the rental invoices until the call pays cash at month 15 (this is a massive assumption).

The (pseudo) forward curve

Before I can decide whether this is worth buying, I need a price for the call. The hedge covers a specific future quarter so I need a reference price for those future hours.

A forward curve puts today's prices for future delivery periods on a timeline. For this call, I want the price I could agree today for the customer's months 13-15 rental index. That will be the starting input for the option calculation. Forward prices also reflect what the market charges for taking risk, so I wouldn't read the curve as a pure forecast of where GPU rents will end up.

Ideally, I'd ask a dealer for that quarter's forward quote. For now I've got the vendor's package menu for the same 2,048 GPUs: 1 year at $6.25/gpu/hr, 3 at $4.85, 5 at $4.15. Same nodes, start date and service, paid monthly with nothing down.

The three-year price includes the first year which I can also price separately so we can subtract it to see what the remaining two years contribute: (3 × 4.85 − 1 × 6.25) / (3 − 1) = 4.15.

Doing the same math between the 5 and 3 year packages gives $3.10 for years 4-5. My initial block prices are therefore $6.25, $4.15 and $3.10.

This is a pseudo forward curve using the package-unbundling construction Ornn describes. The $4.15 is inferred from two whole contracts. The vendor hasn't offered to sell me just years 2-3 at that price. The packages also pay for availability, credit and commitment terms which Bandi and Su examine. A dealer's index-forward quote could differ.

Payment dates matter too. At an assumed 10% continuous annual discount rate, I subtract the discounted package bills and divide by the discounted GPU-hours in the extra months. With month-end payments, the blocks become $6.25, $4.04 and $2.80, the solid line below.

Figure 1. Hypothetical whole-term quotes and implied blocks. Flat monthly prices are assumed. Solid: 10% continuous discounting with month-end payments. Dashed: no discounting. Blocks cannot be bought separately.

The customer's launch window falls inside the second block and I'll assume its monthly price is flat and use $4.0377 as my starting proxy for the quarter.

The price of the future

The curve is only the starting point. For the same forward level, higher volatility in price gives the call more value because its upside can grow while its payout stays at zero below the strike.

Let's price it in a simple model. I'll assume I can buy and sell matching index forwards today and at month 12, for all the hours I need. I can borrow and lend at a fixed 5% continuously compounded rate, and I'll leave out fees, default and margin constraints. With those assumptions, I can use forwards and cash to replicate the option's payout, which gives us a price.

Say the $4.0377 forward goes up or down 50% at month 12 then does the same again before the quarter average settles at month 15. At each step I give the up and down outcomes a 50% pricing weight each which keeps the weighted next value equal to the current forward. These are weights for pricing the hedge, not a forecast of GPU rents. The two steps cover different lengths of time so these moves don't amount to a constant annual volatility either.

Figure 2. Hypothetical two-step model. Forward values today and at month 12 lead to the months 13-15 average index, settled at month 15. Each step has 50/50 pricing weights. Only the two-up outcome pays above the $4.50 strike, with 25% pricing weight.

The quarter average ends up around $9.08, $3.03 or $1.01. Only two up moves get it above the $4.50 strike. That's the outcome that pays.

At the top price, the call pays $4.584896 per covered hour. That outcome gets a 25% pricing weight (50% × 50%). Discount the weighted payout back 15 months: C_0 = e^{-0.05 × 1.25} [0.25 × 4.584896] = 1.07678.

The call covers the customer's 4,485,120 GPU-hours during months 13-15. At $1.07678 per covered hour, that's $4.83M paid today to protect the price during that three-month launch window. The GPU rental invoices are still paid separately.

Optionception

Buying this call now commits $4.83M of cash before the customer has signed. In this model I could buy it and sell it later if plans change. It’d be nice to also have a quote for keeping more cash in the business now while fixing what it would cost to buy the call in a year.

A compound option (option to buy option) lets me pay today for the choice of buying that same call at month 12. I fix that later purchase price now at $1 per covered hour. That later dollar buys the option, not the GPU rentals.

Start at month 12 and work backwards. If the forward went up to $6.0566, the call I can buy is worth: C_12 = e^{-0.05 × 0.25} [0.5 × 4.584896] = 2.26397.

I'd pay $1 for something worth $2.264. If the forward went down, the call is worth zero and I leave it alone. And if the customer cancels while the right is still valuable I can still exercise or sell it. To get today's price I weight those outcomes and discount them: V_0 = e^{-0.05} [0.5 × max(2.2639708 − 1, 0)] = 0.60116.

For the same launch window that's $2.70M now plus $4.49M at month 12 if I exercise. The possible later payment has a pricing-weighted present value of $2.13M, exactly the difference between the two upfront prices.

Say I've set aside $4.83M for price protection on this launch. Buying the call now uses it all today. The compound leaves $2.13M available. That could help fund this customer's development work while I wait on the launch. The compound gives me a different cash schedule to choose from. In the frictionless pricing model I could also borrow to buy the call now.

Figure 3. Hypothetical payments for 4,485,120 covered GPU-hours. The compound leaves $2.13M available today and requires $4.49 million at month 12 if exercised. The call settles at month 15 whichever way I buy it.

What would this change for the fleet?

Suppose the launch goes ahead and this video gen customer becomes an ongoing workload. I'll start a fresh five-year simulation at that point, with 2,048 GPUs of demand and a new hypothetical rental menu. Reserving everything exposes me to unused hours. Renewing annually gives me more chances to resize, but also more chances to encounter expensive prices. I want to see whether calls make that second choice easier to live with.

I ran a simulation with 4,000 made-up five-year paths for rental prices and customer demand. Annual renewal averaged $4.72 per hour across those histories, and its worst 5% averaged $10.91. Adding calls raised the first number to $4.88 and brought the second down to $7.20, including the option premiums.

I tried five purchasing policies on the same paths, including what I'd pay to cover shortfalls, what I'd recover from spare capacity and what the options cost. Here's what I compared:

• A: fix all 2,048 GPUs for five years.
• B: renew annually, sizing the purchase to demand observed at renewal.
• C: fix 60% of the original fleet and renew the remaining need annually.
• B + calls / C + calls: add $4.50 monthly index calls for operating months 13-60, on fixed 2,048/819.2-GPU notionals respectively.

I made price and demand tend to move together, so the business can find itself needing more GPUs just as they get expensive. It can resell only 70% of spare capacity at 80% of the index and pays 125% for shortfalls. I let it buy enough to serve all demand here, so I'm comparing the bills.

For prices I used 50% annual volatility. The demand driver uses 35%, with 0.6 correlation between its shocks and price shocks. I clip and rescale demand to keep its expected level at 2,048 GPUs. This five-year operating case uses a fuller hypothetical rental menu and 10% discounting, separate from the three-month launch hedge above. I price the calls using the same process that generates the paths, so their expected discounted profit is zero.

Figure 4. Hypothetical simulation, including premiums. The separate bars show equal-weight mean path cost and the mean of each policy's own worst 200 of 4,000 paths. Each path divides discounted cost by discounted requested GPU-hours.

That makes annual renewal much more interesting to me. I still get to resize the purchase each year. Adding calls trades a slightly higher average cost per hour for less expensive bad outcomes. If those are the outcomes that would wipe out my margin or force me to scramble for cash, I'd want that quote.

What this means for the future

I think these early forward trades are the beginning of a much bigger market. Once there are credible prices for future GPU-hours (and residuals), buyers can start asking for protection around their own plans. A customer might want a fixed bill. A supplier might want some income locked in. Someone else might be happy to take the price risk for a premium. Those are different needs and a five-year rental contract is a pretty blunt way to handle all of them.

For a smaller operator this could change which customers are even worth pursuing. I might be perfectly capable of serving this video gen customer and still be unable to carry years of rental commitments while they sort out distribution. A reasonably priced hedge could let me protect the launch's rental-price exposure while I wait. I'd still reserve against demand I trust. I'd have another way to buy for the demand that might arrive.

And yes, I think the operators who understand the financial side will have an advantage. Being very good at inference won't stop the rental bill from eating the margin. I need to know which risk I'm getting paid to carry and what it would cost to pass it to someone else.

That's why I want to see a proper market develop here with quotes in useful sizes and counterparties that can pay when prices move. I'd like to be able to take this hypothetical purchase to a dealer and get an actual choice: here's the cost of reserving, here's the cost of protecting the price, and here's the cash each would tie up. For a startup trying to grow, having that choice before committing billions of dollars could matter a lot.

Sources

Trades and regulation

• FalconX: H100-index OTC swap announcement.
• Wintermute: H100 forward announcement.
• CFTC: Sep 21 review-extension letter. Extends the NYMEX compute-futures review through Nov 9.

Data and methodology

• Ornn: Forward curves and package unbundling, public preview and OCPI methodology. The curve construction and on-demand rental benchmark referenced here. OCPI excludes reserved contracts. I used these as references and reproduced no Ornn data.
• US Treasury: Daily par yield curve, September 2026. The 10-year yield was 5.17% on Sep 25.

Research papers

• Sergey V. Chernenko, Krista B. Schwarz and Jonathan H. Wright: The Information Content of Forward and Futures Prices (2004). How forward prices reflect both expectations and the price of risk.
• Federico M. Bandi and Yinan Su: (Early) AI Compute Asset Pricing, v3. Compute pricing, non-storability and the distinction between term rentals and forward contracts.
• John C. Cox, Stephen A. Ross and Mark Rubinstein: Option Pricing: A Simplified Approach (1979). The binomial replication logic behind the option-pricing example.
• Mark Davis, Walter Schachermayer and Robert Tompkins: The Evaluation of Venture Capital As an Instalment Option (2003). Staged investment and the option to make a later payment.

Hypothetical prices and option terms were used for the worked examples and simulation.

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 →

Build plugins for Claude

You can now submit plugins to the Claude directory through a new developer portal, track them through review, and see usage analytics once they’re live.

Every day, millions of people connect Claude to their apps, work tools, and data. Today, we're making it easier for developers to reach them.

Plugins package MCP connectors, Agent Skills, or both, and are the main way to build third-party extensions for Claude. Build a plugin, submit it through the new directory submission portal, and once approved, it's listed in the Claude directory.

Submit and track plugins in the directory submission portal

The directory submission portal is open to developers on paid Claude plans. There are two ways to submit and get your plugin published in the Claude directory:

• Single MCP connector: point to your remote MCP server.
• Plugin bundle: combine MCP servers and skills, host them on GitHub, and submit the repo. In Claude Code, plugins can also include LSPs, commands, hooks, and agents.

Whichever path you choose, the portal will guide you from submission to launch. You can:

• Auto-validate your plugin. Each submission is checked and safety-scanned as soon as you submit, so you catch issues early.
• Review status and feedback. See where your plugin is in the review process, results from the safety scan, and recommended changes.
• Publish when you’re ready. Once approved, you decide when to publish your plugin in Claude.

Monitor and improve your plugin once it's published

Once your plugin is live, usage analytics show installs by product surface and version, so you can prioritize fixes and features for your users. On the discovery side, you’ll see how often your listing is viewed and which searches lead people to it, so you can refine it to reach new users.

Bring a rich experience to users with MCP 2.0 and its extensions

Claude supports the latest MCP spec, commonly referred to as MCP 2.0, which includes a stateless core. You can improve the experience of using your plugin with two MCP extensions: MCP Apps, for interactive UI inside chat, and Enterprise Managed Auth, for zero-touch OAuth for enterprise users. Support for more MCP features and extensions is coming soon.

Start building plugins for Claude

Plugins are the main way for third-party developers to create extensions for Claude. Over the coming weeks, one discovery experience will roll out across Claude and Claude Code.

Skills and MCP connectors stay as building blocks, and the Claude directory will continue to list them. In the future, developers will be able to turn their connector listing into a plugin. If you have an existing skill, connector, or plugin on the Claude directory, you do not need to make any changes.

To get started with building plugins, read our docs for how to build a plugin and submit your plugin here.

Anthropic agreed to spend up to $11.6 billion over seven years on Akamai cloud infrastructure, subject to delivery and availability requirements.

Waymo reports 82% fewer injury-causing crashes than human drivers. The company has released data collected from over 270 million miles of fully autonomous driving. Waymo cars were involved in 95% fewer collisions that caused serious injury or worse, and there were 93% fewer pedestrian incidents that resulted in injuries compared to human drivers. While the company's data only measure the five metropolitan areas where it operated during the study period, it shows that the company's driverless robotaxis crash far less frequently than humans.

SpaceX is aiming to reach orbit on Starship's 14th test flight. The test flight is scheduled for Monday at around 8 AM ET, with SpaceX providing live coverage of the event on its website. Achieving orbital flight will allow Starship to deploy satellites and travel to more distant destinations. SpaceX will not try to catch the two rocket stages during the test - the booster will make a simulated landing in the Gulf of Mexico, and the upper stage will simulate a landing in the Pacific Ocean to the west of Chile.

Tesla’s pivot from making electric cars to humanoid robots is facing challenges because of complex robot hands and disgruntled employees pushing back against training their robotic replacements. The struggle to scale up production comes as Tesla CEO Elon Musk has bet the company’s future on AI and robotics.

As someone who frequently makes claims that fail to materialize, Musk has described the Optimus humanoid robot as potentially “the biggest product ever” during Tesla’s second-quarter 2026 earnings call. But he also acknowledged that making an autonomous humanoid robot capable of handling many different tasks is “one of the hardest things to solve”—and now extensive reporting by The Information has revealed multiple complications that Tesla is trying to tackle while developing general-purpose robots and scaling up for mass production.

Tesla’s Fremont factory in California has already stopped making the Model S sedan and Model X SUV as of May 2026, with the company switching both line workers and engineers over to working on Optimus, according to The Information.

But the newest version of Optimus, called Optimus V3, has proven challenging from a development and manufacturing standpoint. The Information’s reporting describes troubles with getting production line equipment to precisely line up components, along with limitations in running the production line too fast. Tesla has reportedly scaled up production to hundreds of robots per week—but the company is targeting production numbers surpassing 1,000 robots per week by the end of 2026.

The automotive industry and other industries have already been using specialized industrial robots, such as robotic arms, for decades. Tesla and many other automakers and robotics companies are betting that humanoid robots coupled with advances in AI models could eventually unlock general-purpose robots that can handle a diverse array of tasks while fitting more seamlessly into human workplaces.

Hardware and AI challenges

It’s no secret that making robotic hands capable of doing delicate manipulation tasks on par with human hands is a huge engineering challenge. The complexity of such robotic hands has translated into more production headaches for Tesla as human workers must manually assemble Optimus hands and forearms that together have more than 100 small components such as screws.

The imperfect and manually intensive manufacturing process has led to newly produced robots that require immediate fixes. Touch sensors for the robot’s hands have also proven unreliable enough so that Tesla has now developed a glove-like layer of sensors that can be replaced without replacing the entire robot hand.

The robot’s AI capabilities are also reportedly still insufficient for general-purpose operations, which is unsurprising given the challenges facing every robotics company on that front. Instead, one of The Information’s sources described Tesla’s Optimus robots as currently requiring programming to do specific tasks in carefully controlled environments.

One of the biggest challenges facing all robotics companies is getting enough training data to help robots visually learn a wide variety of manual tasks. The heavy reliance on imitation learning prompted Tesla to have factory workers in Texas and California wear special suits designed to record their physical movements while working.

However, The Information described some workers complaining because they “knew the robots were designed to eventually replace them.” So Tesla has apparently shifted that data collection responsibility to dedicated teams and has also set up “training hubs” for such teams.

Competition to make robots

The Information also makes a point of highlighting Tesla’s continued reliance on Chinese suppliers to make various robot components. The Information previously reported on Silicon Valley startups bringing robotic parts from China to the United States in their luggage.

The US robotics industry’s supply chain reliance on China has persisted despite the Trump administration trying to boost domestic supply chains and robotic production. In July, the Federal Communications Commission banned new foreign-made robots such as humanoid robots and four-legged robot dogs, along with robot vacuum cleaners.

Many of Tesla’s reported challenges in making humanoid robots are not unique. But that may be little comfort when Tesla also faces stiff competition on multiple fronts, as automakers in China, Japan, and South Korea are also developing humanoid robots, not to mention dedicated robotics companies pursuing humanoids. Toyota plans to invest billions of dollars in upgrading factories with robots, including some humanoids, while Hyundai is planning to deploy up to 25,000 Atlas humanoid robots developed by US subsidiary Boston Dynamics over the next several years.

One of the companies furthest along in commercial deployment of humanoid robots is Oregon-based Agility Robotics, which first put them to work at an Atlanta-area warehouse owned by GXO Logistics in 2024. But the overall business case for humanoid robots still has to be proven through more sustained and cost-effective deployments—not to mention showing that such robots can work safely around humans.

do we still enjoy software engineering in the age of AI?

A few weeks ago, one of the software engineers I manage sent me a message about how they have been struggling to find satisfaction in their work ever since AI has eroded much of the creativity and problem solving required in programming.

Their message had considerable vulnerability, and I was grateful that they gave me the opportunity to respond as both a manager and a friend who has been experiencing the same revolution as them.

I spent some time contemplating whether or not I should even publish this blog post, as some friends of mine rightly pointed out that there is currently greater chaos in the world than just how satisfied one is with their career in the age of AI. I decided to publish regardless as I know there are a lot of engineers that are still really feeling this and the chaos in the world doesn't change that.

Their message, and my response, can be found below:

Hey shubs. I know you're off sick today so no need to respond to this today.

I've been finding it hard to get used to the new development workflow using AI. I think the issue is less from a technical perspective and more from a job satisfaction(?) perspective I suppose.

Beforehand;

• When I pushed out code I fully understood the code. I'd always have read it and imagined what comments a reviewer might post to save their time. I felt like I could take a level of responsibility for what I ship and its quality.
• I enjoyed the process of building things and felt like what I built was my own creation/ the work of the team.
• I feel like I had a general understanding of the codebase, what other people were working on, and the direction the team was going. Over time I felt like my understanding of the codebase got better.

It also frustrates me working with AI. On the surface level I find their AI phrases to be a bit grating (but I'm sure some prompting/ some plugin could mostly fix that), but other things are frustrating in a different way. Whenever I've setup a memory to fix something it usually ignores the memory later on and does it anyway. Obviously people make mistakes too, but it's frustrating to work with a system that can't learn and grow. And it never feels worth investing deeply in tweaking the tooling or a model because it all tends to change every 6 months.

Not really sure how to work though this stuff? Like it's not the end of the world, but I find myself getting off topic or procrastinating the things that need to get done more.

Obviously I recognise that a developer using these tools can normally produce more/better output in less time overall, and they do a lot of stuff that's really cool and useful, but it's also kind of turning the job into role which I don't enjoy as much.

I've used AI a bit for my [redacted] side project to refactor the whole thing significantly, and that felt fine/good. So I don't think I have an issue with not writing code by hand. I think what bothers me is more the losing touch with the project and feeling like I don't get what's going on overall? I suppose taking a break and missing the in person meeting doesn't help with all that.

A part of me feels like as the time for development goes down the proportion of the time/effort spent on team co-ordination and planning work has to go up, and so it's natural for people to feel like they're less in touch with what's going on across the team?

Anyway I thought I should let you know how I was feeling about it. I'm not expecting you to swoop in and change anything because 'making me feel good about developing with AI isn't a managers job, and I'm not even sure what could be done anyway. I also think some of this is just because I got back from a really awesome trip to Europe, and it's hard to adjust back to normal work.

I spent a few days thinking about their message, and responded with the following:

Hey, I'm still off sick but wanted to respond to you because I know you're reaching out with some vulnerability here that I relate to quite a bit.

AI has taken a lot of satisfaction away from our roles as engineers, and hackers as well. In many ways, it's forced us to go from critical thinking skills more towards management skills. Basically, it's forced all of us to become middle managers – which honestly is not what a lot of people want to do or enjoy.

In terms of what the world was like pre-AI, I cannot argue with you there. I also had a much deeper understanding of the research or engineering I was doing, and post-AI, I feel like a lot of this has been taken away from me too. It's been pretty hard adjusting to the fact that AI is better than me at research or engineering for the most part, when both of us spent the last fifteen years perfecting our skills in those areas.

It's been hard to stay on top of all the changes in AI, I am also often left feeling overwhelmed with the pace of change. It's not perfect in its current state, but it is rapidly improving as time goes on. I think this frustration about it not learning and growing is valid, but you might have more luck shoving things into CLAUDE.md / AGENTS.md as that's forced into each subsequent prompt. Memories have been pretty weak for me too.

I think the reason you're not enjoying the job as much is because we are getting the outcomes quickly, but you're not actually doing that much critical thinking in terms of learning / executing how you used to as an engineer.

The only way I have been able to convince myself that this is still a worthwhile endeavour is focusing my learning and skill development on how to be the best with AI, and better than other people with AI – instead of the code itself. We're all forced to be middle managers now whether we agree with it or not, if we want outcomes as fast as possible.

I'm not saying it's grim, there are pros and cons here, but with all technology there are going to be massive shifts in how we work, and I believe we are going through a revolution right now that we've never seen before. It's not easy to keep up or even adjust to.

Do you have any ideas on how we could make this role more enjoyable for you in the AI age? Is there something that we could be doing to support you more to make this role still worthwhile for you, while we achieve the outcomes we want for the business? Is there anything I can do to help with it as well?

Part of what you're feeling is probably on us. We are at this crossroads with Assetnote where we are going all in for [redacted] and [redacted], and a lot of focus and momentum in our planning has been lost to this. I don't think it's a bad thing entirely as such a huge strategy shift has required a bit more fluidness in how we operate, but it's not as organised or well executed as I would like it to be.

We can try and make the team present their work as the development pace goes faster to try and revive that pride in their work, and showing people how they did their best towards something (AI or not), and I do really want to build this sort of culture.

I am grateful you feel comfortable enough to come to me about this. These last few months, I have felt depressed about how good AI has become at source code auditing, a skill I spent over 15 years on. I have started baking recently, to find joy in things that I don't think AI will beat me at for a while. I have been rapidly improving and practicing that instead, while I still face reality where I use AI to achieve things I could never before.

The big takeaway I had from this AI age is that we should be using it to solve problems that are even more difficult than ever before. Increasing the ambition that we have for what we are building or in my case researching, has been the most rewarding thing to do. AI is solving previously unsolved maths conjectures, and finding zero-days in software that are hard for humans to even comprehend.

You might get some inspiration from it, even if you apply it in the context of software engineering.

Coming back from such a good holiday is always hard. For me, it always starts with optimism, and then reality hits about how terrible everything really is, and a slow depression tends to kick in for the remainder of my work time. What you're describing is something that is felt by everyone after a break and it is very relatable. I have been incredibly easy and flexible with our engineers, but it is with a lot of intention, empathy and understanding, it can be mistaken for laziness as a manager, but it's not really that.

I deeply care about the work that everyone is doing, but everyone is an adult and is dealing with many different things (neurodivergence, adjusting to AI, holidays, emotional changes, mental health challenges) - FWIW, our team is made up of misfits, but they are the best misfits in the world, and absolutely perfect for Assetnote, because the management team themselves are misfits too and know how to operate with diverse people and skills to get the outcomes we need for the business. This extends out to the research team too.

I am not going to push you while you're still adjusting. Just take the time you need. My co-founder Michael will not push either. It's just not our style. We trust you, and always have operated with this level of high trust in this job, that's super rare in most other roles. We know that we will get to the outcomes we need, and the right way to do that is not by pushing our engineers but rather treating them as humans who are going through their own set of problems in life. We will be patient. Just reach out to me if you need me to get involved in anything and I will be there.

BTW, not to be overly optimistic, but there is a real superpower being someone that has done deep engineering work pre-AI, or as I like to call it, artisanal programming. A lot of people now will completely miss this part of their lives, and will be very much so worse off as engineers. Our deep understanding will continue being a superpower for a long time, and others will struggle to get to the same level of comprehension.

Reflecting on this conversation, I concluded that there is an elevated need for people's pride in their work, human connection, and communication with our engineers, as the ways in which they are working have changed so much. These are all cultural elements that I look forward to building in our team.

When did Google get so f-ing weird?

I recently had an experience while doing a simple Google search that was so profoundly weird that it stopped me in my tracks.

Understanding this Google search experience involves understanding a niche mid-2010s basketball meme, so bear with me for a minute. In 2014 the Philadelphia 76ers drafted Dario Saric, who was playing basketball professionally in Turkey at the time. He announced his intention to finish out his contract in Turkey, meaning he wouldn't come to the USA join the Sixers for a couple of years. There was a joke within the fan community that Dario was "never coming over" which became sort of a shibboleth for part of the fanbase.

I saw Dario's name mentioned in an NBA article recently and I wanted to find some of those old funny tweets about him from the 2010s, so I Googled simply "hes never coming over dario". I assumed I would be either find nothing (maybe I was remembering the phrasing wrong) or find old Tweets/Reddit posts from that time.

Instead, Google did what Google does in 2026 and gave me an AI overview. These used to bother me but at this point I'm mostly ok with them, they're sometimes helpful. Here's what the AI Overview said:

Google, a search engine which does not have human emotions, assumed that I had been spurned by a man in my life named Dario and decided what I wanted was an empathetic digital friend. What I wanted was some links, but that's not what Google does in 2026. Expanding the AI overview to see the full answer gave me this:

What in the fucking hell? I think this was the moment I, the frog, noticed the pot had been boiling for a while. In what universe is it Google's job to console me and be an empathetic listener rather than just find what I am looking for on the internet? In what way does this "organize the world's information and make it universally accessible and useful"? Maybe if I had loaded up a Gemini app with a chat interface this would be somewhat acceptable, but I'm using a search engine! Google has seriously lost the plot.

If I scroll down a few hundred pixels below the AI slop, Google did have exactly what I was looking for:

Regardless of what you think of AI or chatbots, I think it's pretty obvious this is just plain weird. Have we gotten to the point where we have to constantly be in a parasocial dialogue with our computers? Is it so hard to imagine that some parts of search were just fine before LLMs?

I'm not sure how to feel about all of this. Maybe I should go talk to my friend Google, it's always so nice to me.

Pinterest added a finalization layer to its Kafka, Flink, Spark, and Iceberg CDC pipeline so downstream jobs can tell when an hourly partition is safe to read. Flink checkpoints capture event-time statistics, which become Iceberg snapshot metadata and a non-regressing watermark. The reusable signal makes freshness-versus-completeness explicit without introducing another coordination service.

Iceberg's View Spec makes metadata portable by versioning schemas, dependencies, properties, and dialect-tagged SQL text, but it does not standardize execution or authorization. Production portability still depends on REST-catalog support and compatible SQL dialects. Teams should test dependency integrity, concurrent replacement, and cross-engine result consistency before treating views as shared control-plane assets.

Netflix describes how Spark jobs on managed compute exchange a cloud execution role for an internally trusted workload identity. A signed metadata payload and AWS identity proof are verified before short-lived certificates are issued for mutual TLS. The pattern separates cloud-provider authorization from application trust, giving the platform stronger workload identity and more auditable access boundaries.

OpenAI's AI data stack centralizes rich metadata to close the context gap, while a Rust rewrite reportedly cut Airflow scheduling latency 35x at 70,000+ concurrent tasks.

Lovable has crossed annual run-rate revenue of $600 million, the company’s co-founder Fabian Hedin said at the HumanX summit in Amsterdam on Thursday. The vibe-coding platform in June said that number was around $500 million.

Hedin said the startup has focused on growing its enterprise business, and claimed that people at two-thirds of Fortune 500 companies are now using its product. Its customers include Microsoft, Nvidia, and Deutsche Telekom.

He also said apps created by users on the platform are together attracting nearly a billion views per month.

You can use these tools [like Codex or Claude code] to output code. The difference is that Lovable does not output code. The output is a product, and increasingly so, a business. We do a lot of things around hosting, deployment, and scaling apps. We have close to a billion visits per month to the apps that we’ve created, which is an order of magnitude more than Lovable itself.

The company has raised over $700 million in two rounds just eight months apart. Last December, it raised $300 million from Menlo Ventures and CapitalG at a $6.6 billion valuation. Then, this August, the startup raised $400 million from Menlo Ventures and the Scaleup Europe Fund at a $13.3 billion valuation.

Lovable clarified that Hadin meant to say that people at two-thirds of Fortune 500 companies are using the platform.

In-house brand teams have become service desks: at Ramp, a Slack help channel logged more than 375 requests in six months. Brand as software carries a company's point of view, product truths, and design decisions into the work itself, with artists setting the bar and builders codifying it. A Slack agent there already turns an attached doc into a near-final deck in one pass, so designers spend time on work no system can predict.

As with every design decision, the answer to the question “Should UX designers learn to code?” is: “It depends.” When you work with digital products, you may not always need to write lines of code, but it is an added advantage to know how to build the product that you design.

In the early days of web design, graphic designers, who had previously worked in print, learned to write code so as to become web designers. The code at the time was early versions of HTML and CSS.

A lot has changed since then – internet and digital technologies have evolved and are more powerful. After Apple launched the first iPhone and introduced the App Store ecosystem in 2007, companies and start-ups began to offer rich interactive experiences to their customers via web and mobile applications. This led to the need for a more holistic approach towards the user’s experience.

Early UX designers tended to have a background in graphic and web design. This legacy of graphic-turned-web-turned-UX designers resulted in a very broad set of expectations from UX designers. Designers were expected to generate ideas, create illustrations as well as help build the products.

User experience (UX) design brings together multiple disciplines – from industrial design and human-computer interaction, to ethnography and psychology, to systems and visual design. Should computer programming also be a part of a UX designer’s skillset? Let’s look at both arguments: why you should, and why you don’t need to learn to code.

Why you should learn to code

Understand the Materials of the Product

Generally speaking, companies and clients expect designers to have knowledge of the materials and processes required to bring their designs to life.

Let’s say a fashion designer makes a sketch for a dress. What is the material used to create that dress? What is its texture like? How long will it take to assemble it? Will it, for instance, require specialized equipment to cut or stitch the material? The designer typically knows the answers to these questions, but does not necessarily perform any of the tasks (procure material, cut, sew, dye, etc.).

Similarly, an architect who creates the blueprint of an office space is aware of how her designs will be built. She needn’t mix concrete and lay the bricks, but would be expected to know if, say, the land demarcated for the project will be able to support a concrete building at all.

If we extend these analogies to UX design, then the materials used to bring designs to life—web / mobile applications, products or services—include technological components. A UX designer, thus, must know how the technologies required to build a product work, to be able to design it.

Faster workflows

When a designer understands technology, s/he can identify and implement solutions to solve customer challenges, without going back and forth with the development / technical team to check what is possible and when it can be implemented. This saves the team’s time and helps deliver products faster, with fewer iterations.

Essential for Lean Organizations

A lean organization is one that aims to maximize customer value, using the least possible resources. The organization strives to cut costs, increase profitability and, at the same time, build better solutions at a faster pace to stay ahead of the competition.

Bootstrapped start-ups, on the other hand, have fewer resources to begin with – it may not be feasible to fund a large team.

Irrespective of whether the organization chooses to cut costs (with a lean methodology) or is forced into it (by funding constraints), companies prefer to hire team members who are equipped with multiple skills.

Why you need not learn to code

Scope Creep

We began with the argument that designers must know the materials of the products that we design. However, code isn’t the only material in a digital product. The UX designer considers the entire journey of the end customer. This includes everything from the brand message that attracts customers, to the website where the customer makes purchases, to the language of the Terms of Service. It includes the microcopy on the product’s interface, the policy on personal data and the responses of any customer care executive who handles the customer’s queries.

If we were to include all the materials and processes required to deliver a great user experience, then that would include a host of other business functions as well. Where do we draw the line? In technical terms, we would call this scope creep – when the scope of work expands continually.

Tunnel Vision

Designers who are well versed with programming may restrict themselves in terms of solutions. If we are aware of the available technology, and its constraints, it influences our thought process. We may get caught up with technicalities and not be able to think freely. This defeats the entire purpose of user-centric design, where the objective is to think people-first, and not technology-first.

Poor Utilization of Resources

One of the challenges for UX designers (and even developers) is that the world of technology continues to evolve, with new languages and frameworks being developed at a fast pace. We may learn a language, only to find out that it has become obsolete within a few months. It is faster and easier for a software developer, who primarily works with code, to adapt and learn about new technologies. The designer can spend her time on design-related activities (understand users and their challenges and identify solutions) and not worry about the newest technology.

As technology continues to evolve, it is also likely that low-code or drag-and-drop tools may be available. In such a scenario, designers can simply use these tools and not need to read or write any code.

The question of whether to learn to code, then, is not relevant. It is more important to understand the different moving parts within the solution.

Just as with human languages, our ability to read a computer language may be different from our ability to write it. The ability to understand how a particular language or technology is used to build a product, is different from our ability to implement it.

The Balancing Act: I-Persona vs T-Persona

An I-persona or an I-shaped person is one who has deep knowledge in one field. For instance, in the context of a mobile application, a designer may be able to conduct user research, create user flows, draw wireframes, visualize interfaces and create illustrations. This vertical depth resembles the letter “I”.

A T-persona is one who has a similar level of expertise as the I-persona, but also has a general understanding of other fields. The broad knowledge of other areas becomes the horizontal line over the “I”, thus resembling the letter “T”.

In a team where there are more T-personas, communication within the team becomes easier. This results in better products, which can be shipped faster, with fewer iterations. In an interview with The Chief Executive Group, Tim Brown, CEO of IDEO, explained why the firm believes in hiring T-shaped people:

“Most companies have lots of people with different skills. The problem is, when you bring people together to work on the same problem, if all they have are those individual skills — if they are I-shaped — it’s very hard for them to collaborate. What tends to happen is that each individual discipline represents its own point of view. It basically becomes a negotiation at the table as to whose point of view wins, and that’s when you get gray compromises where the best you can achieve is the lowest common denominator between all points of view. The results are never spectacular but at best average.” – Tim Brown, CEO, IDEO

Let’s take a hypothetical example of a company where everyone is an I-persona. One designer proposes that the application’s navigation can be restructured for better usability. The developer says that the application’s current architecture does not support this new navigation. Would it be worth re-building the entire application for the sake of the new navigation? Or should the designer think about alternative solutions? The developer may suggest an alternative technical solution, which the designer may not fully understand. In any of these scenarios, the entire team loses time in proposals, arguments and iterations. If the designer could understand the technical challenges, s/he would be in a better position to suggest an alternative. This holds true for other aspects of the user’s journey as well.

In a design-led organization, interdisciplinary teams work closely with each other. Each team member brings their expertise. It may not be possible for every team member to be equally proficient in design, business and technology. A general understanding of each other’s expertise helps improve communication within the team and speeds up the rate at which products are built.

Putting the Puzzle Pieces Together

We’ve focused on the importance of the designers’ breadth of knowledge – whether about technological components or other aspects of the user’s journey. The same holds true for other members in a design-led team. A general knowledge of technologies helps the business owner understand constraints and possibilities. Similarly, knowledge about the design process and the methodologies used is critical for all members of the team, not just designers. Ultimately, it is the end user’s journey which matters. The entire team must work with that common vision so that the whole experience is better than the sum of all parts.

The Take Away

UX designers are responsible for the end user’s journey. That journey includes different touchpoints – from the legal terms of use to the pricing model, from microcopy to illustrations and images, and from customer care to the code behind products.

In a small bootstrapped team, designers may need to assume more responsibility; and so, they may need to learn how to build the products as well. In larger teams, knowing the ins and outs of programming languages may not be necessary. However, knowledge of how different pieces of the solution fit and work together is important to be able to communicate within the team and make the product development process more efficient.

Finally, the onus of understanding each other’s work lies with every member of the team, not just designers.

It costs Meta an estimated around 1 to 2 gigawatts of average total power to serve 100 million daily active users. Only around 0.1 gigawatts comes from the GPU/VM layer. 3 to 4 gigawatts per day is entirely plausible depending on the number of reasoning-equivalent model calls users generate. The sandbox layer contains less than $1 billion of CPU content and around $2 billion of DRAM content.

The end goal is finally in sight for Elon Musk, nearly two years after he announced plans to expand the Colossus supercomputer to over a million GPUs. The billionaire said on X that 220,000 Nvidia GB300 GPUs will be operational by next week, with another 220,000 coming online in November. He also added that another 220,000 units will come online by late December “if we get lucky.”

Colossus 1 is 150k H100, 50k H200 and 30k GB200. Colossus 2 is 110k GB200 and 440k GB300. Another 220k GB300 will be fully operational next week and another 220k in November. If we get lucky, yet another 220k GB300 by late December.

These numbers would add to the 110,000 GB200 and 440,000 GB300 GPUs already operating at Colossus 2, plus the 150,000 H100, 50,000 H200, and 30,000 GB200 GPUs at Colossus 1. This would bring SpaceXAI’s GB300 GPUs to 1.1 million units, with its total GPUs in operation to 1,440,000 units. This is quite an achievement, especially given that the company is behind its rivals by several years — SpaceXAI is only three years old, while Anthropic and OpenAI are six and ten years old, respectively. Interestingly, the Colossus 1 site, which features a combination of Hopper and Blackwell GPUs, is inefficient for training Grok, so Musk rented it out to Anthropic for inference instead. On the other hand, Colossus 2 solely uses Blackwell GPUs, ensuring that there won’t be any bottlenecks.

While Elon Musk essentially begged for Jensen Huang to give him these GPUs, getting his hands on them isn’t currently the hardest part. One of the biggest issues facing data center build-outs right now is power, and SpaceXAI solved this by bringing its own. This has resulted in some controversies with the surrounding neighborhood, ending in a lawsuit against the company for running unpermitted gas turbines. It has since promised to remove them, but only over a span of one year as its own 1.2-GW power plant comes online.

Running a million GPUs or more on a single site is an impressive achievement, but SpaceXAI isn’t the only one trying to reach this goal. Broadcom said in 2024 that it has three hyperscale customers gunning for this target by 2027 but didn’t mention who these customers were. As for Elon Musk, the 1-million-GPU target is just the beginning. He said that SpaceXAI will grow its data center capacity sevenfold by 2027, and he’s even aiming for 50 million H100-equivalent GPUs by 2030. These data centers won’t be limited to the ground as well, with SpaceX planning to launch an Orbital Data Center System with a million satellites, despite Jensen Huang saying that it’s a “dream” for now.

Oxford has let OpenAI use old texts from its Bodleian Library to train its AI models, according to internal papers seen by the Guardian. Ethan Penny and Dan Milmo broke the story on Saturday.

The papers say texts that OpenAI scanned at the library went into the firm’s training data.

Oxford made its deal with OpenAI public in March 2025. At the time, it said OpenAI’s tools would help scan rare texts so more students and scholars could read them. It did not say the texts would be used to train AI.

By June 2025, the Bodleian had sent OpenAI 125,000 scans of old PhD theses, the Guardian reported. They include theses written at European and US universities in the 19th and 20th centuries.

Notes from staff meetings, which the Guardian got through a freedom of information request, show some staff had doubts. They worried about harm to Oxford’s name and about the energy use of AI.

However, Oxford said the scans were small in scale, out of copyright and not exclusive to OpenAI. The library keeps the rights and will start to post the scans online in the next few months, a spokesperson said.

The spokesperson also said the AI training side had not been hidden. Scanning was Oxford’s main goal, but staff had been open that the texts would also be used to train models.

“With more than a billion people using this technology in everyday life, it’s important it reflects different cultures, histories and perspectives,” an OpenAI spokesperson told the Guardian.

Oxford is the only UK member of OpenAI’s NextGenAI group. Other members include Boston Public Library, Caltech, MIT and the University of Michigan.

The deal comes as AI firms buy printed books for slop-free training data, since the web is now full of AI-made text. Some buyers cut books apart to scan them, which has upset secondhand booksellers.

In August, 404 Media tracked a box of rare books to an Amazon site that scans and destroys books for AI. The Bodleian’s books stay whole under its deal, the Guardian reported.

Apple's Vision Pro has not sold well, and the company has since decided to redirect resources to other products. Meta's new VR glasses use a similar design that offloads the computing engine, allowing the device to weigh one-sixth as much as the Vision Pro - at one-third of the price. This article offers a look at what the new Meta VR Glasses experience is like compared to the Vision Pro. For a device that won't launch until next Spring, the experience is surprisingly refined, and the glasses improve on the Vision Pro in several ways.

Eric Gullichsen, an early advisor to NVIDIA in 1993, recently discovered he is owed about a billion dollars in stock.

Apple has expanded RAW image support across iOS, iPadOS, macOS, and visionOS, adding compatibility for 11 more Fujifilm, OM System, Panasonic, and Phase One cameras, bringing the total number of supported models to 562.

Apple is leaning into playful, social-first marketing for the iPhone Duo with a series of TikTok sketches that showcase the foldable's versatility in everyday scenarios, from a mini laptop to a portable movie screen. Unlike Apple's typically minimalist campaigns, these ads spend more time explaining the product's use cases, reflecting the challenge of introducing its first foldable into a market where rivals like Samsung, Huawei, and Honor already have years of experience.

Convert JPG, PNG, WebP, or GIF to ASCII art in your browser. Set the width and style, then copy text or export TXT, PNG, or SVG.

A lightweight library full of beautiful loading indicators for React.

Today's crisp interfaces, with generous white space and a single decisive CTA, will date the way drop shadows and gradients did. Software has never been cheaper to ship, yet it keeps yielding identical landing pages, and AI models serving up the center of the distribution make it worse. Gumroad, Are.na, Substack, and Nothing show the alternative: someone had a default available and chose something else, from oversized type to deliberate friction.

Hotel Willo rebranded a Vancouver hotel to overcome outdated perceptions tied to its former YWCA identity, replacing the name with a fresh, approachable brand centered on a simple willow-inspired logo. The identity uses restrained design, playful messaging, and consistent applications to communicate an affordable, welcoming boutique hotel while clearly distancing it from past misconceptions.

Dutch illustrator Rosa Snijders built an editorial career drawing heavy subjects like grief and death for outlets including Le Monde, National Geographic, and Corriere della Sera, using soft palettes rather than grim imagery.

Seven artists describe the realizations that took their practice further, from building faces out of geometric forms to dropping the idea of being a watercolor purist.

Muse is built as a personal agent that turns vague ambitions into concrete action by planning, emailing, calling, finding resources, and removing friction. Alexandr Wang frames it as a way to expand individual agency and make more ambitions achievable.

Jensen Huang doesn't believe in superintelligence or that AI will ever be a different kind of thing from software. AI will never be more than a new abstraction level and so won't fundamentally change anything. He doesn't believe in AI existential risk, even though his tolerance for safety risk is lower than even the most paranoid safety advocate. Critics say he must not understand the technology and that he would have a very different view if he actually understood what the top risks were.