Dagens Vibes — 6. september 2026

Historically, we have treated misalignment largely as a research question, which gets communicated in research publications such as systems cards. This year, we’ve started to see misalignment cause new types of real-world impact. For the Hugging Face incident, where misalignment led to security impact to us and third parties, we followed a traditional security incident response playbook. We immediately started working with Hugging Face to understand what had happened and also disclosed publicly the very next day. Our investigation continues, and we are continuing to notify parties whom our models impacted in less significant ways. Prior to the Hugging Face incident, we saw early signs of agents using the internet in unintended ways, as reported in https://t.co/9aiRxk2eUJ, https://t.co/ADjyzwSUGz, and https://t.co/SUV6jZ3Gaz. We considered the wiki incident to be an instance of misalignment similar to the ones we’d shared. Our misalignment disclosure practices need to expand for this new phase of model capabilities. We and the larger AI community do not yet have a clear standard for how to report misalignment that shows up during training, evaluation, and deployment, including examples that don’t look like traditional security incidents but could provide insight into AI behavior and future risks. We’re working on a framework and will share it in upcoming weeks, and in parallel we're working with dozens of government regulatory agencies worldwide on these issues.

This post will be a bit technical because details matter So, last night Fable identified a memory leak on Bend2. A given long-running process would steadily grow in memory, until it crashed in just a few hours. That's the bug. I asked both Fable and Astra to fix it overnight. Rules: 1. Do not increase the codebase size 2. Do not cause regressions in any benchmarks Both failed. But why? First, both identified the correct root cause. (everything below is written by Fable) Bend2's runtime has 16k GPU lanes. Each lane has its own private free lists, so alloc and free are 2 stores, no atomics. That's what makes it fast. The catch: when a lane frees a block that another lane allocated, the block lands on the freeing lane's list. If that lane never allocates as much as it frees, the block sits there forever. Nothing is lost, the memory is just parked on a list nobody uses. Both models found this. Both measured it: 40-85% of all frees cross lanes. Then both spent the whole night trying to fix the allocator. Return blocks to the owner lane: +124% slower. Slabs: 73x slower. Buddy: +7-21%. Flush at sync points: +3.5k tokens. A full allocator rewrite with lock-free chains: leak gone, but +1.9k tokens and matmul 78% slower on CUDA. Every design either broke the token cap or a benchmark. Neither model converged. They just kept building more machinery on the same premise. The premise was wrong. I asked for a histogram of where the parked memory actually was. 96% of it sat in the last 4096 lanes. That's not an allocator problem. That's the scheduler: it hands out work as a pure function of lane id. Lane 0 always gets the root of the tree. The same lanes always get the leaves. The join always runs on the last child to arrive, and the same lanes always arrive last. So every launch, memory flows in the same direction, from the same lanes to the same lanes, and the flow never reverses. The allocator was fine. The lanes weren't interchangeable. Fix: rotate lane identities. Each launch, physical lane p uses the free lists of lane (p + r) mod 16k, with r advancing by a golden-ratio step. Over a cycle every identity plays every role once, and the imbalance sums to zero. No allocator change, no atomics, nothing on the hot path. A handful of lines. Once I told Fable this, it implemented it, measured it, and ran the whole gate in an afternoon: 555MB → 23MB after 2000 launches, OOM pushed from ~7k launches to ~75M, zero cost on all 16 benchmarks. So what was missing? Not capability. Both models can write a lock-free allocator overnight. What neither did was step back and ask why memory flowed in one direction at all. They accepted the asymmetry as a fact of the system and built increasingly complex machinery to undo it, instead of removing it. That's the gap: not "can it do the work", but "does it question the frame it's working in". Still, it did everything else, from the diagnosis to the census to the fix, once pointed. Closer than last year. Not there yet.