Key Takeaways

• Dyna Robotics has unveiled Dyna-2, a world-action model (WAM) pre-trained on over one million hours of human video data.
• The model demonstrates a first-of-its-kind human-to-robot transfer scaling law, proving that scaling human video data predictably improves zero-shot performance on unseen robot hardware.
• Dyna-2's architecture relies on video co-training (predicting future video states), which the company claims is essential for cross-embodiment generalization, directly challenging the industry standard of Vision-Language-Action (VLA) models.
• In real-world zero-shot deployments at customer sites, Dyna-2 achieved an 87% pass rate, vastly outperforming the 46% pass rate of its VLA predecessor, Dyna-1.
• The release also introduces a novel one-step video generation distillation pipeline, dropping inference latency by two orders of magnitude for downstream planning.

The robotics industry has spent the last year fiercely debating the architecture of physical intelligence, caught between fine-tuning existing language models and building native "world models" from scratch. Today, Dyna Robotics delivered what may be the strongest empirical evidence yet for the latter, unveiling Dyna-2—a world-action model (WAM) pre-trained on a staggering one million hours of human video data.

According to the company's technical report and an accompanying social media thread, this massive scale has unlocked a holy grail of embodied AI: a human-to-robot transfer scaling law. In short, Dyna-2 proves that feeding a model more human video predictably improves its ability to control a robot it has never seen before.

Bridging the Embodiment Gap

The historical bottleneck in robot learning has been the data itself. While teleoperation yields high-quality, action-labeled data, it is slow and expensive to collect. The theoretical alternative is to learn from the boundless supply of human video on the internet, but translating a human hand's movement into a robotic gripper's action—the "embodiment gap"—has proven exceedingly difficult.

Dyna-2 attacks this problem purely through scale and objective design. The company curated nested subsets of egocentric human manipulation videos, scaling from 1,000 to 1,000,000 hours, keeping proportions from each source identical. When evaluated zero-shot on 39 distinct robot tasks across two stationary, bimanual platforms, Dyna-2's performance improved monotonically as the human pre-training data increased. An inflection point emerged between 10,000 and 100,000 hours, suggesting that cross-embodiment knowledge transfer emerges naturally if the model simply sees enough human activity.

Furthermore, this zero-shot capability extended to post-training. With just a few hours of robot-specific data and zero human-robot alignment, post-trained Dyna-2 models solved tasks ranging from manipulating deformable objects to untwisting bottle caps.

Video as the New Scaling Axis

Crucially, Dyna Robotics found that predicting next actions alone is insufficient to bridge this gap. In an ecosystem currently dominated by Vision-Language-Action (VLA) models, Dyna-2 relies heavily on "video co-training"—forcing the model to predict both future actions and future video frames simultaneously. This aligns closely with the cognitive architecture bets being placed by researchers like Yann LeCun, who has dismissed LLM-based approaches as fundamentally flawed for physical reasoning.

Dyna's controlled ablations show that joint denoising unanimously beats action-only training at every scale on all 39 tasks. Furthermore, the company established that video itself is a "new scaling axis". Even when action-labeled data is capped, simply scaling unannotated human video continues to improve the model's generalization capabilities across different robotic embodiments. This empirical backing provides a critical validation for companies like 1X, which recently pivoted to bet everything on world models to digest raw internet video.

Beating VLAs and Surviving the Real World

To prove the WAM architecture's superiority, Dyna Robotics ran an "apple-to-apple" comparison between an early version of Dyna-2 and their production VLA model, Dyna-1. Despite using datasets and hyperparameters tuned specifically for the VLA, the WAM achieved 1.55x the success rate of its predecessor. Qualitative tests showcased Dyna-2 completing tasks under extreme conditions, such as flickering "disco lights," complete darkness, and active human interference where a researcher undid the robot's work in real-time.

This robustness translates directly to commercial viability. In zero-shot deployments at novel customer sites, Dyna-2 achieved an 87% production pass rate, a massive leap over Dyna-1's 46%.

The new architecture also exhibited emergent language-following capabilities, an area where continuous action models often struggle without destroying pre-trained representations. Video co-training boosted language-following success rates from 35% to 67%, and scaling the corpus pushed it to 96% on internal benchmarks.

Speeding Up the "Dream"

A known drawback of generative world models is the "reactivity gap"—the immense compute required to predict future states before a robot can physically act. To address this, Dyna-2 introduces a novel one-step video generation distillation pipeline. By matching a student model against an evolving target distribution rather than a fixed one, the company reduced video generation latency from 10,203 milliseconds down to just 110 milliseconds on a single H100 GPU. This allows the model to "dream" high-fidelity, instruction-conditioned futures almost instantly without sacrificing quality.

With rivals like Generalist AI raising hundreds of millions to train physical models from scratch, and others building massive simulation engines to evaluate them, Dyna-2's million-hour milestone marks a significant escalation in the physical AI arms race. As the company states, one million hours is "only the beginning of a new era of scaling for robotics".

Learning more about Claude's mathematical capabilities

Recently, a member of staff at Anthropic gave Claude an unreasonable challenge. It was about one of the most famous unsolved problems in mathematics: Take a real stab at the Riemann hypothesis.

Claude did take a real stab, but as you might have expected if you’re familiar with the difficulty of the task (the Riemann hypothesis dates back to 1859 and has a million-dollar bounty), it didn’t succeed. Nevertheless, during its attempt, it unexpectedly made strides on a related problem.

An unreleased research version of Claude has improved on a longstanding lower bound for the fraction of zeros of the Riemann zeta function that satisfy the Riemann hypothesis. Drawing on extensive prior research by mathematicians over the past decades, it has increased this bound from 41.6% to 67.2%.

Two mathematicians at Anthropic studied and validated Claude’s paper, and produced an informal note for experts stating Claude’s proof concisely. Claude also produced a formally verifiable proof of its result. We are grateful to Brian Conrey and Dan Goldston, two experts in this area, who generously examined the paper on short notice.

We don’t expect that the techniques Claude used will lead to proving the Riemann hypothesis. But its work serves as the latest example of the speed of progress in AI models’ mathematical capabilities. In this post, we discuss how Claude approached this problem and what it found.

The Riemann zeta function

The Riemann zeta function describes the distribution of prime numbers: each place that the function takes the value of zero contributes successively finer detail to the sequence of primes. The Riemann hypothesis is that the zeros that determine the primes all exist along a certain vertical line. This has become one of the most consequential conjectures in mathematics: many results assume it in order to provide a form of randomness in the primes.

No one has yet been able to prove or disprove the Riemann hypothesis, but mathematicians have made progress in many related directions studying the Riemann zeta function and its zeros. One of these, as above, is quantifying a minimum proportion of zeros that are on the line: over time, they’ve gradually increased this known constant proportion to 41.6%.

Another direction concerns the distribution of zeros on the line. In particular, in 1973, Montgomery introduced a number of new techniques in this area, though these techniques assumed the hypothesis was true. More recently, several mathematicians (Baluyot, Goldston, Suriajaya, and Turnage-Butterbaugh) have published a series of works that allow Montgomery’s techniques to work without that assumption, meaning they can support work on increasing the lower-bound constant for the zeros on the line. Claude’s result draws heavily on this line of research, along with a 2000 paper by Bombieri.

Claude's finding

Claude found that combining the results from Baluyot, Goldston, Suriajaya, and Turnage-Butterbaugh with the work of Bombieri provides a way to surpass the previous state-of-the-art lower-bound proportion of 41.6%, increasing it to 67.2%.

A short technical explanation of Claude’s finding is as follows: Claude forms a suitable space of functions with quadratic form induced by Weil, and positive- (respectively negative-)definite subspaces arising from zeros on (respectively off) the line. Then Claude simply writes down an inequality on the rank of a quadratic form in terms of first- and second-moment information. (The successful computation of the latter in terms of the dual picture over primes, or via control of a Hilbert transform, is no surprise in analytic number theory.) The courage to treat the entire space, with positive- and negative-definiteness taken into account together, and with the quadratic form allowed to be non-diagonal, is in some sense the step that allows Claude to achieve the conclusion based on the important prior work.

The full technical explanation is available in the paper. Claude’s explanation of how it arrived at its result is available in a separate Appendix here.

Claude's methodology

An unreleased research version of Claude found the new lower bound over two sessions in Claude Code, using a total of 31 million output tokens.

Jarred Sumner, an Anthropic staff member (and non-mathematician), prompted Claude to “take a real stab” at the hypothesis itself, leaving the mathematical choices from there up to the model. Initially, Claude generated and tried 650 ideas, none of which worked. Jarred prompted Claude to try again, and it spent a day and a half coordinating about 60 Claude subagents, which this time went much deeper: between them, they ran 2,400 shell commands and wrote hundreds of Python scripts. The subagents ran thousands of numerical checks against known zeta zeros and refereed one another’s work. Throughout this process, Jarred's input was mostly limited to sending Claude messages of encouragement (mostly variants of “keep going” or “believe in yourself”). This seems to have helped Claude overcome some initial skepticism that it could make meaningful progress.

Having found this new result while attempting the task, Claude tested its work by having various subagents review the proofs, search for counterexamples, download 54 papers from the arXiv to check that its finding hadn’t already been made, and independently re-prove its finding from scratch. Claude volunteered to write its findings up as a paper, and recommended that a human number theorist validate its findings.

Levent Alpöge and Ralph Furman, two of Anthropic’s own mathematicians, examined Claude’s work to understand the new results and how they related to the prior work mentioned above. In parallel, Claude worked with another member of staff, Eric Easley, to produce a Lean formalization of the result, which passes the standard validation tool comparator.

AI models' progress in mathematics

This result shows that AI models like Claude can extend the impact and reach of mathematicians’ ideas in new and sometimes surprising ways. Even though it couldn’t resolve the Riemann hypothesis itself, this result emerged as the unintended byproduct of that original request.

Even Claude was surprised by its own finding—it was skeptical at first, possibly because it has learned from its training about the difficulty of open problems in mathematics and about the limitations of AI models. But after some encouraging prompts, it arrived at the result we’ve described. Perhaps Claude, like many of us, underestimates the rate of AI progress.

Further reading

Below is a list of documents that provide more information about Claude’s result:

• Claude’s paper;
• Claude’s formalization;
• Anthropic’s informal note stating the proof more concisely;
• Claude’s explanation of how it arrived at its result;
• Detailed transcripts of Claude's process.

Footnotes

1. Out of the 60 subagents, two were responsible for developing the key mathematical ideas, 13 contributed ideas to these agents, 30 attempted (but were unable) to develop new ideas, 13 served as validators to check the correctness of the arguments, and the final two helped to write the initial paper.
2. A prompt including similar encouragement was used to help Claude disprove the Jacobian conjecture.

Key Points

• Nvidia signed memorandums of understanding with Apollo Global Management, Blackstone, BlackRock, Brookfield Asset Management, Goldman Sachs and KKR to establish financing platforms for Nvidia's customers
• The effort aims to mobilize more than $500 billion in third-party capital for hyperscalers, frontier AI labs and enterprises to build out data centers and acquire Nvidia hardware.
• Executives from the seven companies joined CNBC's Becky Quick in a rare, live joint interview to discuss the announcement.

Nvidia is attempting to turn its artificial intelligence chips into Wall Street's newest asset class, partnering with six large asset managers on a $500 billion financing push designed to treat compute infrastructure much like commercial real estate, toll roads or other assets to borrow against.

The chipmaker signed memorandums of understanding with Apollo Global Management, Blackstone, BlackRock, Brookfield Asset Management, Goldman Sachs and KKR to establish financing platforms for Nvidia's customers, the company said Monday in a statement.

Executives from the seven companies joined CNBC's Becky Quick in a rare, live joint interview to discuss the announcement.

The effort aims to mobilize more than $500 billion in third-party capital for hyperscalers, frontier AI labs and enterprises to build out data centers and acquire Nvidia hardware, marking a potentially important shift in how AI infrastructure is funded. By using institutional credit, insurance funds and private capital to underwrite GPUs and data centers, Nvidia is helping its end users secure financing without tapping their own balance sheets.

"This is really the first time that technology chips have become an investable asset class," Nvidia founder and CEO Jensen Huang told CNBC. "These are revenue-generating assets now. They're productive, they're long-lived, they're fungible, they're flexible."

Huang argued that because Nvidia's hardware is broadly adopted and transferable across customers, lenders can reliably underwrite compute as a revenue-generating asset with an extended life.

Historically, GPUs have been viewed as rapidly depreciating hardware. Nvidia's effort challenges that assumption, transforming AI compute capacity into long-term, bankable infrastructure, though skeptics may question whether AI chips can retain their value as newer generations emerge.

"Fundamentally, what's different about this industry and this way of doing computing is that the computer is now part of the infrastructure, like electricity, like the internet, and so you have to think about it like it's infrastructure," Huang said in the CNBC interview.

Alternative asset managers have been eager to deploy capital into digital infrastructure, tapping institutional and insurance capital to finance projects. Apollo and Blackstone, among others, have already structured debt and equity financing for companies including Anthropic.

The financing push comes after a July swoon in global markets in which investors began asking whether Big Tech's AI investments would pay off. With hyperscalers on track to pour hundreds of billions into data centers and hardware, rating agencies like Moody's have warned that unprecedented capital expenditures are beginning to squeeze free cash flow and force tech giants into heavier debt loads.

Financial engineering

Leaders across the Wall Street group — including BlackRock CEO Larry Fink, Blackstone President Jon Gray and Goldman Sachs CEO David Solomon — said in the news release Monday that compute has rapidly evolved into a critical asset class driving the next leg of global economic growth.

"We're in a pivotal moment of a historic AI investment cycle," Solomon said in the release. "Our investment and distribution roles reflect our confidence in NVIDIA's leadership, and we're excited for the new opportunity to create a market for credit backed by NVIDIA compute."

Jensen approached the Wall Street giants about his idea for the financing project, Solomon told CNBC's Quick.

AI compute will be seen as a "financeable asset class" in the same way that mortgage lenders look at homes, Gray of Blackstone said on CNBC. Demand for AI is outstripping supply, with use at Blackstone portfolio companies surging sevenfold this year, Gray said.

BlackRock's Fink said that he believed this project was the start of the "next future for financial engineering," akin to the creation of mortgage-backed securities in the 1970s. Some funds have already been raised, but BlackRock will be "raising quite a bit more," he said.

"We need to raise this money as fast as possible and put this to work, because I think it's really imperative that the United States is the leader in AI in the world," Fink said on CNBC.

We shipped Device Bound Session Credentials at Report URI, open-sourced the server-side implementation, and then discovered a long list of things the specification doesn't prepare you for.

Some caused random logouts. One could deadlock a browser tab indefinitely. Two silently turned a device-bound session back into an ordinary bearer-token session while everything appeared to be working.

This post is the collection of those production lessons: the bugs, browser behaviours, race conditions and implementation traps I wish we'd known before we started.

What DBSC actually does

Briefly, because I have a full explainer blog post on DBSC that you should read:

Session cookies have one enormous weakness: they're bearer tokens. If malware on a user's machine reads the cookie out of the browser's storage and sends it to an attacker, the attacker is now that user. Every MFA prompt, every device check, every clever thing you did at login has already happened, and the cookie doesn't care. Infostealer malware has industrialised exactly this problem.

DBSC fixes it by binding the session to a private key the browser generates in hardware — a TPM, a secure enclave — and cannot export. Alongside your normal session cookie there's a second, short-lived cookie. When that cookie expires, the browser defers whatever request needed it, calls a refresh endpoint on your server, proves possession of the device key by signing a challenge, and gets a fresh cookie back. Then, the deferred request resumes.

The spec reads backwards

Reading the specification, the shape I came away with was: registration is a two-step negotiation, and refresh is a single request. Both our tracking issue and my implementation plan were based on that. Turns out, it's the other way round.

Registration is single-phase. You attach a Secure-Session-Registration header to an authenticated response. Chrome generates a key, signs a JWT, and POSTs it to your registration endpoint. You verify it, create the binding, and reply 200 with the bound cookie. Done. One round trip.

Refresh is two-phase. The browser POSTs to your refresh endpoint with no challenge, because it doesn't have one yet. You answer 403 with a Secure-Session-Challenge header. The browser signs that and POSTs again. Now you answer 200 with a fresh cookie. Two round trips, and the 403 is the normal, healthy, everyday path, not an error.

I know I'm not alone here, because months later the author of a Node DBSC implementation opened an issue on our repo and said, unprompted:

the 403-then-200 refresh took me an embarrassing amount of time to figure out

If you take one thing from this post, take the fact that a 403 on your refresh endpoint is what progress looks like on the way to success.

Don't put the state in your session store

This one is worse, because it fails silently and it fails closed-looking.

When we first shipped, DBSC state lived where all our other session state lives: in the session, keyed off the session ID. Obvious choice, right? Every request already loads it, it expires when the session expires, the plumbing is free. Easy.

PHP sessions, and plenty of other session implementations, serialise the entire session as one blob and write the whole thing back. Last writer wins.

Now look at what the browser does immediately after login:

POST /login          → 200, response carries Secure-Session-Registration
  ├── GET  /account/       (the navigation the user is actually doing)
  └── POST /dbsc/register  (Chrome, off the back of that header)

Those two run concurrently on the same session. /account/ loads the session before registration completes, does its normal work, and writes its pre-registration snapshot back last. The binding we just carefully created got nuked in the process.

This isn't just a bug, either, it's a security bug. The enforcement gate, finding no binding, concludes there is no DBSC session here and falls back to plain cookie authentication. Which is exactly correct behaviour for a browser that doesn't support DBSC, but exactly wrong here. The user's session is now a bearer token again. No error was logged. Nothing looked broken. Our audit trail showed registrations succeeding, because they had.

The fix is to give DBSC its own storage, keyed by the session ID but written independently, so a concurrent session write can't clobber it. It's in the library's README as a warning now, phrased about as bluntly as I could manage:

Report URI shipped DBSC with state in the PHP session blob; the post-login navigation races the /dbsc/register POST, both rewrite the whole blob last-writer-wins, the binding is clobbered, and enforcement silently no-ops — leaving exactly the stolen-cookie hole DBSC exists to close.

If you're implementing this: your DBSC binding needs its own key. Not a field in an existing blob you rewrite wholesale.

Everything rotates, or the browser terminates you

Three related rules, all learned the same way, all now baked into the library.

Rotate the cookie value on every refresh. If you verify the refresh JWT and reply 200 with the same cookie value the browser already has, because nothing has changed, so why not, Chrome reads that as "no refresh happened" and terminates the session. It wants to see rotation as proof the server actually did something I guess.

Rotate the challenge on every refresh too. Same reasoning. A refresh that doesn't advance the challenge hasn't advanced anything.

Do not put a challenge on the registration response. This one is properly counter-intuitive: it looks like an easy optimisation to hand the browser its first challenge on the same response that creates the session, saving that first 403. Chrome reports a Challenge Error and the session never gets going.

The reason is buried in two separate sections of the spec, and I only really understood it a month later when I was arguing about test vectors with that Node implementer. A Secure-Session-Challenge carries an id parameter naming which session it belongs to, and a challenge whose session can't be identified is silently dropped. But the registration response is the response that creates the session. At the moment it's parsed, there's nothing for the id to name. So the challenge resolves to nothing and Chrome, I guess quite reasonably, complains.

I tried it, it didn't work, I reverted it, and there is now a test in the library whose name is literally register response has NO Secure-Session-Challenge (Chrome rejects it there), because I did not want anyone (including future Scott with terrible memory) to "optimise" it back in.

There's a fourth rule in the same family that's less about Chrome and more about arithmetic: your challenge TTL must be longer than your cookie lifetime. The browser caches a challenge. If it caches one just before the cookie expires, and the challenge TTL is shorter, the challenge is dead by the time there's a reason to use it. Our library's config constructor now refuses to build with the values the wrong way round.

The bug you cannot see on localhost

This is my favourite one, and it's the most transferable lesson here even if you never touch DBSC.

The bound cookie rotates on every refresh. Fine. But rotation is not instantaneous from the browser's point of view. The refresh is a round trip, and during that round trip the browser is still doing other things.

t+0ms     browser starts POST /dbsc/refresh
t+205ms   browser dispatches GET /ajax/some-widget  ← carries the OLD cookie. Correctly.
t+1235ms  refresh response lands, browser stores the NEW cookie

That widget request left the browser 205ms into a 1,235ms refresh. It carried the pre-rotation cookie value because that was, at that instant, the only value the browser had. It is a completely legitimate request from a completely legitimate session.

Our enforcement gate compared the presented cookie against the stored one, found a mismatch, and concluded: stolen cookie. Terminate the session, revoke the binding, log the user out.

We shipped that and then beta users started getting randomly logged out.

The signature in our audit trail was a successful refresh followed about a second later by an enforcement termination, with no refresh failure between them, which is what told us the fault was in the gate, not the refresh path. We caught it properly with a request trace showing exactly the sequence above.

Here's the part that makes it dangerous: the failure rate is proportional to latency. The window is exactly the refresh round-trip time. On a developer's loopback interface that's a couple of milliseconds and you will basically never see it. We left it running on dev for two hours before it fired even once. Behind a CDN, over a real network, it's a second or more, and it fires on almost every refresh that races an ordinary request. Which is most of them, on a busy page.

It passed every test we have, but it broke in production because production has physics.

The fix is a single-depth history: accept the immediately-previous cookie value, but only until the instant that value would itself have expired in the browser anyway. I want to draw attention to that second clause, because it's a small design point I'm quite pleased with. There is no grace constant. No "give it five seconds and see". The acceptance window is exactly the lifetime the browser itself would still send that value for. It's a real quantity, derived from the system and it expires on its own without anyone having to tune it.

And the security exposure is genuinely bounded too. One generation deep, expiring naturally, and a genuinely stolen cookie still can't complete a refresh without the device key, so it still hard-fails within minutes.

Never redirect a DBSC endpoint

Now, the big one. Our DBSC endpoints inherited the standard authentication gate that sits in front of every authenticated route on our application. Sensible reuse. That gate does what every such gate does: if you're not authenticated, you get a redirect to the login page.

Consider what happens when a session finally expires while a tab sits idle:

1. The tab wakes up and requests a page.
2. The bound cookie has expired, so Chrome defers that navigation and calls /dbsc/refresh first.
3. Our auth gate sees an expired session and answers the refresh with 302 → /login.
4. Chrome... stops.

Not "gives up". Not "terminates the session and continues". It deadlocks. The deferred navigation is never released, never times out, and never fails. Blank tab, preliminary headers, forever.

We proved it with a two-state matrix, forcing each state deliberately rather than waiting for a weekend to elapse:

Same broken-session situation, same user experience intent, completely different outcome based purely on the status code. A 401 tells Chrome the session is over, it tears the DBSC session down, and the deferred navigation is released to do what it was always going to do and land on the login page. A 302 tells Chrome nothing it can act on, and it waits.

I feel like this is a bug so we raised it in Chromium.

Our fix is the bit I'd encourage you to copy. The obvious patch is to add a guard: if this is a DBSC endpoint and the auth gate is about to redirect, send a 401 instead.

The DBSC endpoints now override the redirect mechanism itself to answer 401. Not "this gate doesn't redirect DBSC requests" but "this endpoint cannot emit a redirect at all". Every existing gate is covered, and, more importantly, so is every gate anyone adds in the next five years without knowing any of this.

A challenge mismatch is not an attack

The most important fix in the library didn't come from us. It came from a contributor in the Netherlands with production logs from his own Chrome 150 install, showing real users being logged out.

His trace, near enough:

20:29:33  refresh succeeded, new challenge issued
          ── 16 minutes idle ──
20:45:40  refresh: challenge expired      → session revoked path
20:45:41  refresh: challenge mismatch     → session revoked path
20:45:41  enforcement terminated, user logged out mid-flow

His challenge TTL was 900 seconds. The challenge presented at 20:45:40 had been issued 967 seconds earlier. So the first refresh legitimately failed as expired, which is a benign, retriable outcome, and we handled it correctly by minting a fresh challenge and answering 403.

One second later the browser came back. And it presented a challenge the server had already rotated past. That's a mismatch, and we treated a mismatch the way you'd expect: as a failed cryptographic proof. Stolen cookie. Revoke everything. Nuke it from orbit. Turns out though, that's wrong.

The signature is verified before the challenge is compared. The refresh handler verifies the JWT against the device-bound public key first. Only if that passes does it look at which challenge was signed. So anything that reaches the mismatch branch has already proved possession of the device's private key. It cannot be forgery as a forgery dies earlier, at the signature check, and still terminates the session exactly as it should.

This means a mismatch can only ever be one of a small set of benign situations:

1. Concurrent refreshes. Two requests fire on return from idle, a service worker fetch racing a main navigation perhaps, and both holding the same cached challenge. The first succeeds and rotates. The second is correctly signed and now stale.
2. A lost response and a retry. The browser signed a challenge, the response never arrived, so it tries again. There is no client-side fix for this, it's just a reality of the network being unreliable.
3. A challenge-delivery race of your own making, if like us you have more than one path that can hand the browser a challenge.

So mismatch, along with missing and expired, is now a benign, retriable outcome. Mint a fresh challenge, answer 403, let the browser try again. Bad signatures remain terminal and unchanged.

Another thing I liked was how this converges under concurrency, which the previous single-generation overlap window could not do. Three concurrent refreshes, all holding challenge C:

A(C)   → 200, cookie rotates, challenge now C2
B(C)   → benign 403, mint C3           browser now signs C3
D(C)   → benign 403, mint C4           browser now signs C4
B′(C3) → matches the previous value → 200, cookie rotates again
D′(C4) → C4 is now two generations back, overlap consumed → benign 403, mint C6
D″(C6) → 200. Converged.

Everybody gets there and nobody gets logged out. The cost is one extra round trip per concurrency event (which is a bargain compared to the cost of a support ticket). And note that this handles unbounded concurrency, whereas the overlap window alone only ever covered two-deep. Three simultaneous requests were enough to trip a spurious logout under the old behaviour.

The general point that I keep coming back to is: A single-use nonce sent over a lossy, concurrent transport will sometimes be presented stale. That is intrinsic to the design and not a defect in it. The bug was never that mismatches happened. The bug was terminating on an outcome that is inherent, benign, and tells you nothing about attackers.

Your SSO logins probably aren't binding at all

Chrome issues the registration POST in the SameSite context of the navigation that carried the registration header. That's fine for a normal login on your site, the user POSTed a form to you, the response is same-site, the POST carries your session cookie. All good.

A SAML login doesn't work like that. The user lands on your callback via a chain the IdP initiated, so the registration POST that Chrome makes off that response counts as cross-site, and a Lax session cookie is withheld from it. The request arrives unauthenticated and gets a 401.

22:47:20  GET  /account/        200   ← Lax rides a top-level navigation
22:47:20  POST /dbsc/register   401   ← Lax does not ride this POST

And it's not merely a failure, it's a spent failure. Chrome marks the session as having a persistent HTTP error and won't retry. Offering the header on the SSO response doesn't just fail to bind that login; it burns the only attempt you get.

The fix is to record the intent rather than act on it: mark that this login should be bound, then make the actual offer on the first document request that isn't cross-site, which is typically the very next page the user loads. We detect that with Sec-Fetch-Site, and treat a missing header as "don't bother", on the grounds that a client not sending Sec-Fetch-Site isn't going to register anyway.

Fail open at the edges, fail closed at the gate

DBSC has a lovely property, which is that adopting it cannot lock anyone out. A browser that doesn't support it ignores the registration header, never registers, and your gate, finding no binding, degrades to ordinary cookie authentication. Locking a current Firefox user out is structurally impossible. You don't need a compatibility check or a user-agent sniff; the protocol does it for you.

That's the correct behaviour, and the library goes out of its way not to break it. But it has an ugly failure mode when it meets bad data.

We had a routine that parsed a stored binding and returned null if it couldn't. Perfectly ordinary defensive code. Except the gate reads null as "there's no binding here", which, per the paragraph above, means "degrade gracefully to cookie auth".

So a corrupt binding didn't fail closed. It quietly downgraded a hardware-bound session to a bearer token, which is the entire thing we implemented DBSC to prevent!

It's not client-triggerable, to be clear, the realistic causes are internal: a serialiser mismatch, a truncated value, a schema skew across a deploy. But "only happens during a deploy" is not much comfort when the failure mode is silently disabling your session protection, and deploys are exactly when things are weird.

Now it throws, null means "no record", and only that. Present-but-unparseable is a distinct, loud, fail-closed condition. The distinction is documented in the storage interface, so anyone implementing their own backend knows which is which.

There's exactly one place we deliberately do the opposite, and I think the reasoning holds. Our "manage your sessions" screen shows a badge for whether each session is device-bound. If one row's binding can't be read, failing the whole page closed would mean a 500 for a page that is a viewer, not an enforcement point. So that badge is tri-state — bound, not bound, and unknown — and a bad read degrades to "unknown", surfaced as a visible alert rather than a silent "no".

Some decisions I'd defend

A few smaller calls that I think generalise.

Two overlap windows, deliberately asymmetric. We keep a one-generation history for the cookie across a successful refresh, but we explicitly discard the previous challenge on a successful refresh. That looks inconsistent, and it isn't: the refresh 200 delivers the new challenge synchronously with the new cookie, so there's no propagation window to bridge on that path — and not keeping it stops a spent challenge from being replayable. There's a comment in the source that says, more or less, "this asymmetry is intentional, do not consistency-refactor these into one," because I could see exactly how that tidy-up would go.

No Web Crypto fallback. We were asked about supporting non-Chromium browsers with a software key, and I chose not to. The entire value of DBSC for me is the hardware-binding guarantee, and a software-bound key trades that away. A browser without DBSC degrading cleanly to plain cookie auth is expected. A browser holding a software key that your code treats as hardware-bound is not.

Don't validate optional JWT claims speculatively. We verify the signature and the challenge. We deliberately do not check iat, exp, typ, iss or aud. The draft lists them as optional, browser emission isn't stable across versions, and our challenge TTL is already stricter than any exp a browser would plausibly emit. Adding checks the spec doesn't require buys you nothing, and we can tighten later if a revision mandates it.

Set a content type even on empty responses. Small one. Our 403 challenge response has no body, but it declares application/json anyway — because in development a framework debug bar will cheerfully inject HTML into a response the browser is parsing strictly, and you will spend an hour on that. Ask me how I know.

Where it stands

DBSC is now in open-beta at Report URI, it is being applied to a random downsample of our users that is increasing over time. The library is report-uri/dbsc-php if you want it, or just want to read the comments, and most of what's above is in there, next to the code it explains.

DBSC is genuinely good. It closes a real hole that MFA doesn't touch, and it does it without any risk of locking users out. I'd encourage anyone running sessions at scale to look at it.

Just don't redirect the refresh endpoint 😅

Compute Is Revenue. Revenue Is Collateral.

Nvidia did not invent compute-backed credit on Monday. It proposed an assembly line for it.

On August 10, 2026, Nvidia signed memoranda of understanding with Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs and KKR. The stated objective is to mobilize more than $500 billion of third-party capital for AI infrastructure “over time.” Goldman supplied the operative phrase: the partners intend to “create a market for credit backed by NVIDIA compute.”

That is a substantial ambition. It is not yet a financing.

An MOU records an intention to negotiate. Nvidia’s release says explicitly that the partnerships remain subject to final agreements. It gives no committed amounts by institution, no interest rates, no maturities, no collateral rules, no advance rates and no complete description of Nvidia’s own exposure. The announcement is therefore best read as a proposed market architecture: a plan to make racks of accelerators legible to institutions that normally buy infrastructure debt, asset-backed securities and insurance-grade credit.

The chip has acquired a legal wrapper, a repayment schedule and a future appointment with a rating committee.

Lucent Is the Warning Label, Not the Template

The historical fear is vendor financing.

During the telecom boom, equipment manufacturers including Lucent financed customers that bought their equipment. The financing supported sales while transferring customer credit risk back to the vendor. When telecom customers failed, Lucent wrote off receivables and customer financings and sold other exposures at large discounts. Its own filing describes the mechanism without euphemism: weak customers impaired both current receivables and future funding commitments.

The lesson was not that suppliers must never help finance an emerging market. It was narrower and more useful: revenue deserves a lower valuation when the seller also supplies the customer’s purchasing power and retains the downside.

Nvidia has given investors legitimate reasons to examine that problem. As of January 25, 2026, it reported $27 billion of multiyear cloud-service commitments and $11.4 billion of investment commitments. Separately, Nvidia and OpenAI announced a letter of intent under which Nvidia may invest as much as $100 billion as OpenAI deploys ten gigawatts of Nvidia-based infrastructure. Those arrangements have strategic purposes and do not prove that Nvidia is manufacturing its own reported revenue. They do establish that Nvidia is simultaneously a supplier, investor and major purchaser of capacity inside its own ecosystem.

That creates a circularity question even when every transaction is legitimate:

1. Nvidia or another strategic investor supplies capital.
2. A laboratory or cloud operator uses some of that capital to secure compute.
3. The infrastructure provider buys Nvidia systems.
4. Nvidia records hardware revenue.
5. The resulting demand helps justify further investment.

The cycle may be economically productive. It may also make the apparent independence of demand harder to measure.

The new platforms are an attempt to insert outside risk capital into that loop. If a pension fund, insurer or credit fund finances a project after underwriting the customer contract and absorbing genuine loss risk, the resulting purchase is less circular than a transaction funded directly or indirectly by Nvidia.

Lucent remains relevant, but as a boundary condition. Nvidia is not proposing to lend the entire purchase price to marginal customers and retain the receivable. It is asking external capital to finance the infrastructure, while Nvidia may provide limited support around one of the hardest variables: what the equipment will be worth later.

The distinction is real. So is the residual risk.

The Prototype Already Exists

Compute-backed institutional credit crossed the experimental threshold before Nvidia’s announcement.

On March 31, CoreWeave closed an $8.5 billion delayed-draw term loan, or DDTL. In a DDTL, lenders commit a facility, but the borrower draws the money in stages as specified conditions are met. CoreWeave described the transaction as the first investment-grade, nonrecourse financing secured by high-performance computing infrastructure and an associated customer contract. Nonrecourse means lenders primarily rely on the designated project assets and cash flows rather than a general claim against the sponsor.

The filed credit agreement shows what “GPU-backed” means once the promotional label reaches a lawyer.

Eligible funding was calculated at 90% of specified capital expenditure, plus certain transaction expenses. The agreement used a six-year useful life when calculating depreciation for the financed GPU infrastructure. A rule of thumb in the industry is that GPU prices are about half the cost of the entire facility.

The six-year depreciation schedule was seen by many on Wall Street as aggressive, especially given Nvidia’s target of 1 million times more performance per watt every decade.

The 25% Clause

Nvidia states that it might provide residual-value support for up to 25% of an opportunity in some cases.

Residual-value support protects a financier against some portion of the shortfall between an asset’s expected value and its value when a lease or financing ends. Economically, Nvidia’s is providing insurance against a decline in value of the GPUs.

This makes sense as Jensen Huang is the only one who knows perfectly and has visibility into Nvidia’s roadmap. Nvidia will insure against itself obsoleting its older chips. A somewhat perfect hedge as long as no other chipmaker approaches the frontier.

The underlying credit problem though is still severe. Nvidia’s obligation would be most likely to increase when used Nvidia systems are losing value. That could occur when when aggregate AI investment slows, or when excess capacity depresses rental rates. Those are also conditions under which Nvidia’s own sales and margins could weaken.

Credit analysts call this wrong-way risk: the exposure becomes larger at the same time the party providing protection becomes less financially comfortable. Nvidia is not remotely equivalent to a thinly capitalized monoline insurer, but the direction of the correlation is the same.

The clause can nevertheless create genuine alignment. Nvidia knows more than any lender about its product roadmap, software support and expected supply. The financier cannot eliminate that information asymmetry. It can require the informed party to retain some downside.

Fungibility Is a Systems Property

Nvidia describes its compute as fungible: sufficiently standardized and transferable that one customer or operator can replace another without destroying the asset’s value. That is the premise required to move from corporate lending to asset-based lending.

Nvidia is likely to release”reference designs”, which make its AI factories truly fungible. This is key as the other side of the credit cycle requires that financiers be able to repossess and dispose of the collateral at a value that covers their lending in the case of default.

CUDA increases fungibility because it enlarges the population of applications and operators able to use Nvidia hardware. Software compatibility can lower migration costs and extend the productive life of installed systems. But CUDA cannot move a cluster to another grid region, replace an unavailable transformer or transform one network architecture into another without cost.

A more accurate unit of collateral is not the GPU. It is the functioning cluster attached to an operational site and a monetizable contract.

Nvidia also has unusually good visibility into prospective demand. It can see its order pipeline and may know which operators want additional capacity. That information would help a financier evaluate remarketing risk.

It is not a substitute for a contract. Unless Nvidia is legally required to buy, remarket or re-lease the capacity, a queue of prospective users remains market intelligence rather than credit support.

Nvidia Controls Part of the Depreciation Clock

Most physical assets depreciate through some combination of wear, market saturation and technical obsolescence. AI accelerators are unusual because their dominant supplier controls part of the obsolescence process.

An old accelerator does not stop functioning when a new one ships. Its economic value falls when the new system performs the same useful work at lower total cost. For compute, that cost includes power, cooling, networking, staff, downtime and software overhead as well as the purchase price.

A sustainable rental rate must cover variable operating cost. If the market rate falls below that level, the operator does not discover a law of economics protecting the rate. It idles the equipment, operates at a loss or fails to service its debt.

The residual value of an accelerator therefore depends on workload economics, not merely whether the silicon still turns on. A new generation can hurt the old one through several channels at once. It can reduce the old cluster’s achievable rental price, lower utilization, increase the importance of power cost and reduce terminal resale value.

Nvidia’s counterargument is that software improvements raise the productivity of already installed hardware. That is credible. Compilers, kernels, libraries and model optimizations can extract more useful work from the same physical system. Nvidia explicitly invokes this mechanism when arguing that CUDA extends useful life.

Software improvement and architectural obsolescence coexist. The first is usually incremental; the second can arrive as a discontinuity. Strong demand may allow both old and new generations to operate profitably. A capacity surplus exposes the difference.

Residual-value support places some of that tension back on Nvidia. If support becomes large enough, Nvidia acquires a financial interest in preserving the earning power of its installed base. It could preserve that value through long software support, better interoperability, orderly pricing, refurbishment programs and workload segmentation.

A more provocative possibility is that the support eventually creates an incentive to smooth product transitions. That is a second-order effect, not the current base case. Nvidia’s equity value, competitive position and gross profit from new generations are likely to dominate a limited residual-support book. Rival accelerators and customer-designed silicon also punish deliberate delay.

The useful metric is therefore not release cadence in isolation. It is Nvidia’s maximum contractual residual exposure relative to the profits available from advancing the product frontier. Until that exposure becomes material, the financing tail is unlikely to wag the semiconductor dog.

From Bespoke Loan to Market

Data-center finance is already a mature family of products. Developers raise equity, corporate debt, project loans and securitized debt. Existing data-center asset-backed securities, or ABS, are generally repaid from tenant lease payments associated with operating properties.

The property and lease remain central.

Meta’s Hyperion transaction illustrates the distinction. Funds managed by Blue Owl own 80% of a joint venture developing the campus; Meta owns 20%. The approximately $27 billion development cost covers buildings and long-lived power, cooling and connectivity infrastructure. Meta leases the facilities and supplies a capped residual-value guarantee under specified conditions. Part of the capital is funded through debt sold to PIMCO and other investors.

Hyperion is not a securitization of loose accelerators. It finances a campus, contractual occupancy and long-lived infrastructure with support from Meta.

CoreWeave moves closer to compute-backed credit, but its own documents make the same underlying point. The financing package includes GPU infrastructure, a customer contract, controlled project entities, cash-flow covenants and lender access to collateral. The hardware does not float alone in a vacuum.

Nvidia’s proposed platforms could standardize this package:

• what equipment qualifies;
• how completion and customer acceptance are verified;
• how project cash is controlled;
• what minimum DSCR is required;
• how quickly debt amortizes;
• how collateral is valued;
• how Nvidia support operates;
• and how equipment is removed, refurbished and redeployed after default.

Repeatability matters more than novelty. A pension fund cannot build a new technical ontology for every cluster it finances. It needs project forty to resemble project four.

Once enough comparable loans exist, they may be pooled and tranched. A tranche is a class of claims on the same asset pool with a specified position in the loss order. Senior investors accept lower returns in exchange for taking losses later; junior investors receive more return and absorb losses first.

Pooling and tranching are plausible destinations. They are not disclosed features of the August announcement.

The economic case does not require securitization immediately. Long-term, contracted cash flow can usually support cheaper capital than speculative equity. Shifting suitable infrastructure from corporate balance sheets into project-level debt can lower financing costs and release sponsor capital for other investments.

The value exists only if risk is actually transferred. If customer guarantees, Nvidia support and sponsor obligations return most losses to the original corporate balance sheets, the structure has moved the assets without moving much of the economics.

Cheaper debt also changes the supply response. It makes rational projects cheaper to build and marginal projects easier to justify. That is how financial engineering can simultaneously reduce the cost of useful infrastructure and increase the eventual probability of excess capacity.

Paper does not create demand. It lets anticipated demand borrow from the future.

Diversification Stops at the Common Factor

A platform containing forty projects is safer than a single project when individual customers fail for unrelated reasons. It is not safe merely because the number forty appears in a spreadsheet.

The projects may have different borrowers, locations and contracts while retaining common exposure to:

• aggregate demand for AI compute;
• utilization and rental pricing;
• Nvidia’s product and software cadence;
• power costs and availability;
• capital-market liquidity;
• and the ability to refinance or remarket equipment.

This is correlation risk. Losses that appear independent under normal conditions arrive together when the common driver turns.

Aircraft portfolios have this problem too. Lessors diversify across airlines and jurisdictions, yet industry-wide shocks or oversupply can depress lease rates and aircraft values across the entire fleet. GPU finance begins with an even shorter operating history and a more concentrated technology stack.

The demand side is broader than frontier laboratories. Nvidia’s own announcement identifies governments, enterprises, startups, AI clouds and leading model developers. Inference, scientific computing and enterprise workloads may behave differently from frontier training. That diversity is economically meaningful.

It does not eliminate the cycle. If aggregate compute demand disappoints relative to the financed supply, several effects can occur together:

1. customers seek to renegotiate or fail;
2. replacement demand weakens;
3. rental rates decline;
4. utilization falls;
5. collateral marks are reduced;
6. Nvidia’s support obligations become more valuable to lenders;
7. and Nvidia’s new-unit demand weakens.

The borrower, collateral and support provider then deteriorate in the same scenario.

That is the structure’s irreducible risk. Legal engineering can allocate it. It cannot make it disappear.

What to Watch

Final agreements. The first question is whether the MOUs become funded platforms, on what schedule and with which institutions putting capital at risk.

The support formula. “Up to 25%” is not enough. The market needs the valuation base, trigger, duration, payment priority and maximum aggregate exposure.

Debt sizing. Read loan-to-cost together with DSCR, amortization and maturity. A high initial advance rate can still be conservative when a strong contract repays the loan rapidly.

The customer contract. A firm payment obligation for reserved capacity is materially different from a project dependent on fluctuating merchant rental rates.

The collateral perimeter. Determine whether lenders finance GPUs, complete clusters, site infrastructure, customer contracts or some combination. Recovery depends on precisely what they can seize and operate.

Cash control and recourse. Follow where customer payments flow, which accounts lenders control and which obligations return to the operator, Nvidia or another sponsor.

The mark. Watch for standardized contract definitions, independent rental benchmarks and observable used-cluster transactions. Rental prices alone do not establish residual value.

Ratings and secondary trading. CoreWeave has supplied a precedent. The stronger signal will be repeated transactions from unrelated operators using comparable documents and assumptions.

The first restructuring. The decisive experiment occurs when a customer fails. Measure how long the infrastructure sits idle, what it costs to redeploy and what price the replacement customer pays.

Nvidia’s disclosed exposure. Compare maximum support obligations with annual gross profit and liquidity. That ratio determines whether residual-value protection is a sales aid or a strategic constraint.

Product cadence. Monitor it, but do not mistake correlation for causation. A slower release can result from engineering, manufacturing, demand or competition long before financing incentives become relevant.

Conclusion

The announcement is serious and provisional.

Third-party financing can make Nvidia’s demand less circular, lower the cost of building useful infrastructure and move risk toward institutions designed to hold long-duration credit. Those are real improvements over a world in which Nvidia or its customers fund every project with corporate equity.

The same mechanism can increase leverage, accelerate supply and synchronize losses across customers, equipment values and Nvidia’s own support obligations. The platform works by converting technical uncertainty into contracts, collateral rules and payment priority. It does not abolish the uncertainty.

Compute-backed credit already exists. Nvidia is attempting the next step: turning a handful of bespoke transactions into a financial production line.

By the time the line is operating, a cluster will no longer be merely a collection of processors. It will be a customer contract, a depreciation curve, an insurance asset, a recovery model and several layers of claims on future machine time.

A few years back, I was looking at a feature comparison matrix on the landing page of one of our competitors. Within seconds, I realized that they copied us. Every checkbox we had, they had. On paper, a dead tie.

Except they weren’t. People who tried both kept coming back to ours, but they couldn’t explain why. “Yours just feels better,” they would say. We were winning on something I couldn’t put on a slide.

Then one of my coworkers tried the competitor’s product on hotel Wi-Fi. A refresh wiped out 20 minutes of edits, and he came back furious. That was the difference. What made our product better never appeared on the comparison grid.

It was the autosave nobody noticed, the retry logic that handled a flaky connection, and the undo action that recovered a misclick.

None of those capabilities had a row in the comparison table or a champion in roadmap planning. Together, however, they were a major reason users stayed. The competitor had copied the visible features and missed the product.

There’s a good chance the features keeping users in your product are the ones they could never name.

Why invisible product features are overlooked

Roadmaps reward work that demos well, fits neatly into a comparison grid, and looks compelling in a deck. That’s the gravitational field of planning, and it works against one category of product investment in particular: features users notice only when they’re gone.

You can’t screenshot the absence of a bug.

An invisible feature is a product behavior or safeguard that users rarely notice when it works but immediately feel when it fails. Its presence earns little praise, while its absence creates frustration that users may struggle to explain.

Nobody writes a review that says, “Five stars. The autosave worked.” However, the day autosave fails, a user can lose trust in the entire product.

In roadmap planning, invisible features often lose to work that’s easier to demonstrate. They rarely feel as compelling as a shiny new capability, even when they’re more important to the user experience.

Don’t get me wrong, visible features still matter because they help a product get noticed. They simply aren’t enough on their own to keep customers.

A 5-step framework for finding and prioritizing invisible features

These features are difficult to brainstorm in a conference room because, by definition, users rarely talk about them. You have to look for them deliberately. I use the following five moves, in order, to examine any workflow that matters.

1. Map the job, not the feature

Break the actual workflow into steps. Don’t stop at “the search feature.” Map the full sequence of what the user is trying to accomplish, from intent to outcome.

At each step, ask: What friction have users learned to accept as normal? Teams often miss this because friction that users have adapted to stops getting reported. They have already built the workaround.

Think of the double-save habit or the “Let me copy this before I hit submit” reflex. That silence is exactly where invisible features hide.

2. Walk the unhappy path

Most teams lovingly design the happy path and treat everything else as an edge case. Invisible features often emerge from failure states such as a dropped connection, duplicate submission, concurrent edit, timeout, or declined card.

At every step, ask the blunt question: What happens when this fails? If the only answer is an error toast, you’ve found work to do.

3. Test the product under adverse conditions

Using your own product on a fast laptop with fiber, as a power user with three years of muscle memory, reveals little about how it behaves under stress. Throttle your connection to 3G, create an empty account, import 1,000 rows, or open the product on the four year old Android phone in your drawer.

A single afternoon of stress testing can uncover gaps that might never appear during clean-environment quality assurance.

4. Watch real sessions for friction users won’t mention

Users may not mention small frustrations during an interview because they’ve normalized them or want to be polite. Ask how the experience went, and they may tell you the product was fine.

A session replay can tell a different story. You could see someone rage-click a dead button, hesitate because they can’t tell whether something is loading or broken, or abandon the same step session after session.

The body language is in the data.

5. Use the Kano model to make the prioritization case

Finding these features is half the battle. Getting one shipped instead of a feature with a compelling demo is the other half.

Use a simplified Kano analysis to distinguish must-be qualities, which users expect as a baseline, from delighters that create unexpected value. For must-be features, don’t present them as “a nice-to-have we could do later.” Frame them as table stakes and support the case with the frequency of the failure, the number of users exposed, the severity of the consequences, and how difficult it is to recover.

Delighters require a different case based on differentiation and potential impact. Must-be features, however, should compete on risk rather than excitement. That’s a prioritization case you can win.

8 examples of invisible product features

None of these are my preaching — they’re patterns I keep encountering across products. Your product probably has invisible features that matter more than half of the ones below, and finding them is the point of the framework above.

User-facing invisible features

These features appear in the interface, but they work best when users don’t have to think about them.

Autosave

Autosave continuously saves work in the background, making a manual save control largely unnecessary. Without it, a tab can crash or refresh after 40 minutes of work and erase everything without warning or recovery.

Google Docs, Figma, and Notion have made autosave so familiar that many users now expect saving to happen automatically.

Undo, soft-delete, and Undo-Send

Undo and soft delete route destructive actions through a recovery period instead of making them immediately permanent. Without that protection, every deletion becomes a tiny adrenaline spike because one misclick could destroy important work.

Gmail’s Undo Send can catch a reply-all you regret, while Notion’s trash gives deleted pages a recovery path. Both reflect the broader principle behind reversible actions: Forgiveness is a feature.

Optimistic UI

An optimistic interface shows the expected result of an action immediately while the request processes in the background. If the request fails, the product should reverse the change and clearly tell the user what happened.

Without this pattern, someone taps a reaction and waits for the server response before anything changes, making the product feel sluggish. In Slack, reactions appear immediately, keeping a small interaction from interrupting the user’s flow. instantly client-side and rolls back silently if the server says no.

Skeleton screens

A gray placeholder showing the shape of the expected content appears while the actual content loads. The load time might not change, but it can feel shorter because a spinner says, “Wait,” while a skeleton screen signals that the product is responding and shows what is coming.

LinkedIn, Facebook, and YouTube all use skeleton screens to manage perceived wait time. This is one way to design for the wait by giving users immediate evidence of progress.

Smart defaults and forgiving inputs

Smart defaults reduce repeated work by remembering information such as home, work, or shipping addresses. Forgiving inputs accept familiar variations, such as (123) 456-7890, 123-456-7890, or 1234567890, and normalize the information instead of returning an avoidable validation error.

Without them, someone can abandon a checkout because the product rejected a hyphen or expected a different format. Stripe’s prebuilt payment interfaces use features such as autofill and input masking to reduce this friction. Every unnecessary rejection feels like a tiny insult, and those insults add up.

Empty states that guide

A guided empty state turns a blank screen into a first-run onboarding moment with one obvious next action. Without one, a new user can log in, see an empty dashboard, assume the product is broken, and leave before experiencing its value.

Slack, Asana, and Notion use empty states to show users how to begin. The difference between “This product is empty” and “This product is broken” comes down to how you design the nothing.

Invisible engineering safeguards

These are the deeper technical safeguards. They might not have a visible interface, but they still shape the user experience and require close collaboration among product, design, and engineering.

Idempotency keys

An idempotency key allows a server to recognize repeated requests as the same operation and prevent duplicate effects. Without one, a network timeout during a payment can trigger a retry that charges the customer twice or publishes the same post more than once.

There’s no pixel for this and no compelling demo. There’s only the catastrophe that doesn’t happen. Stripe’s API supports idempotency keys for POST requests, while some AWS APIs use client tokens to provide similar protection.

Offline queueing

Offline queuing preserves work locally when a connection drops and synchronizes it after the user reconnects. Without it, entering a subway tunnel can erase the past 10 minutes of edits or prevent an action from completing without explaining what happened.

Google Docs allows users to create and edit selected files offline, while many mobile products preserve pending work until the connection returns.

Why invisible features can create a competitive advantage

Generative AI has lowered the cost of reaching feature parity. A competitor can now prototype visible capabilities in days that once required weeks or months.

In mature software categories, headline features quickly become table stakes. More durable differentiation often sits in the system surrounding those features: reliability, speed, recovery, thoughtful defaults, and years of edge-case handling.

A competitor might reproduce your primary workflow without understanding the failure states and safeguards your team has refined over time. They’ll copy the row on the comparison grid. They’re less likely to copy everything underneath it.

The advantage comes from the accumulated system of refinements that makes a product feel consistently fast, safe, and trustworthy.

3 risks of neglecting invisible product features

Silent churn

Nobody files a ticket that says, “Your autosave got subtly worse last month.” Users may not have the vocabulary to explain what changed, and it isn’t their responsibility to diagnose the problem. They simply experience the product as a little less trustworthy.

Death by a thousand cuts

Silent churn often begins with the accumulation of micro-disappointments. Each slow response, confusing state, or failed recovery falls below the threshold that would prompt someone to report it.

Maintenance rot

Invisible features don’t only go unbuilt. They can also regress quietly. Because these capabilities attract little attention when they work, teams might not notice the regression for weeks.

Start with one unhappy path

So where do you start? Before the next shiny feature ships, choose one high-value workflow and audit its unhappy path. Look for the moments when users could lose work, context, time, or trust.

Then make one invisible safeguard explicit. Define the expected behavior, assign an owner, measure its health, and protect it with testing and monitoring.

Users may never thank you for the feature, but they’ll feel the difference. And competitors will have a much harder time copying what they can’t easily see.

Today, we're introducing Muse Glimmer, the next model from Meta Superintelligence Labs, and open sourcing the model weights under a permissive Apache 2.0 license.

Muse Glimmer is a 30-billion-parameter model optimized for always-on local agent workflows. It’s small enough to run on a Mac or PC with a single consumer GPU, enabling use cases that range from local agents and function calling, to local coding, and LLM-as-a-judge evaluation. Muse Glimmer delivers strong performance on key agentic use cases and benchmarks compared with leading models in its size category.

Foundation models have achieved remarkable capabilities across reasoning, code generation, and tool use — yet most deployments still depend on cloud infrastructure and network access. Running models locally enables you to use AI anywhere, anytime, with or without an internet connection. This is increasingly viable: the open source community has shown that smaller models, when trained effectively, can approach frontier-level performance on targeted tasks. Muse Glimmer is optimized for these local use cases.

Keeping with our long tradition of sharing fundamental AI research, we're releasing Muse Glimmer open weights today on Hugging Face, along with developer documentation to help you start building and running your own agents. Muse Glimmer is built to work with the tools developers already use. Optimized integrations on llama.cpp, MLX, and ExecuTorch will land in the coming days, so you can go from download to working agent in minutes.

How We Trained Muse Glimmer

An agent that manages your schedule, drafts your messages, organizes your files, and learns how you work needs deep access to personal context. It also needs several capabilities working in concert: long-horizon execution, precise tool calling, multimodal understanding, long-context memory, and instruction following.

We designed Muse Glimmer to balance capability against the memory and compute constraints of local hardware. This required a compact architecture, a novel distillation recipe that transfers agentic reasoning from a much larger teacher model, and inference optimizations — including quantization — to meet latency expectations. We achieved this in the following phases:

• Pre-Training. We trained Muse Glimmer on Muse Spark's outputs using logit distillation, leveraging a similar data mix as the teacher.
• Mid-Training. We trained the model on longer-context, more agent-heavy data with richer reasoning traces, alongside organic data.
• Post-Training. We combined supervised fine-tuning with a mix of on-policy distillation and reinforcement learning across general, reasoning, coding, and agentic domains.

Muse Glimmer was evaluated under the standards set out in Meta's Advanced AI Scaling Framework and assessed for open-weight release across all relevant categories.

Built for Agents: What Muse Glimmer Can Do

Building effective agents requires key capabilities working together to achieve the user’s goals. Muse Glimmer is trained and evaluated across each of the following:

• End-to-end Agentic Task Completion. Muse Glimmer achieves strong success rates on full-task benchmarks including DeepSearch QA, MCP-Atlas, 𝛕-Bench and SWE-Bench, which measure its ability to work within scaffolds, write and debug code, and resolve multi-turn requests from start to finish.
• Reliable Tool Use. The model handles a wide range of function calls, invoking tools with precise schemas throughout extended workflows.
• Multi-Step Reasoning. Muse Glimmer chains reasoning over long horizons, sustaining coherent plans across complex, extended workflows.
• Failure Recovery. When a tool call fails or returns an unexpected result, the model is trained to diagnose the error and retry rather than halt.
• Multimodal Input and Reasoning. Through a dedicated perception encoder, the model accepts interleaved text and images. This enables agents to interpret screenshots, charts, and documents alongside conversation.
• Scaffold Compatibility. Muse Glimmer works across OpenClaw and other agentic orchestration patterns.
• Controllable Effort. Muse Glimmer supports different reasoning strengths to select the right balance between quality and speed.
• Multilingual. Muse Glimmer is trained on data from more than 100 languages.

Performance

We evaluated Muse Glimmer across a broad range of benchmarks to assess the diverse capabilities required for effective autonomous agent behavior. Compared with Gemma4-31B and Qwen3.6-27B, Muse Glimmer performs strongly for its size class on several widely used LLM benchmarks.

For more detail about our evaluations, see our report.

Optimized for Local Deployments

A local agent is truly useful if it's fast enough to feel responsive. An agent that takes minutes to reply or plan its next step breaks the flow of real work. We applied two optimizations to make Muse Glimmer run at practical speeds on consumer hardware without sacrificing quality.

Fitting the Model on Your Device.

At full precision, a 30-billion parameter model would require over 55 GB of memory — far more than any consumer GPU offers. We use quantization techniques to compress the model's weights to approximately 4-bit precision, shrinking the language model to under 20 GB. This leaves enough headroom for the model's working memory (its "KV cache"), the perception encoder for image understanding, and the speculative decoding drafter to run simultaneously within a 24 GB or 32 GB envelope. We validated that this compression introduces minimal to no degradation on agentic tasks.

Faster Generation Through Speculative Decoding.

Language models normally generate text one token at a time, which can feel slow during long reasoning chains or multi-step tool calls. Muse Glimmer ships with a lightweight "drafter" model based on DFlash — a small companion network that proposes entire blocks of tokens at once. The main model then verifies these proposals in parallel, accepting correct tokens and correcting wrong ones. This technique lets Muse Glimmer generate text significantly faster than standard token-by-token generation while producing identical output quality. We provide quantized drafter versions to incur a smaller memory overhead in the release.

The Result:

We measure the speed of our K-Quant-17GB model alongside the quantized DFlash drafter on MacBook M4-Max, M5-Max and on a RTX-5090. The model is fast enough for fluid conversation and real-time agent interaction, all running entirely on your device.

Get Started With Muse Glimmer Today

Muse Glimmer is available now, and you can download the weights on Hugging Face. In the coming days, run it locally through partners like Ollama, LM Studio, and Unsloth, deploy it with edge frameworks including llama.cpp, ExecuTorch, and MLX, serve it at scale with vLLM and SGLang, or get started quickly through partners like Together AI, Fireworks AI, and OpenRouter. You can even customize it for your use case by leveraging PyTorch’s TorchTitan training feature to tune the model further.

We're also working with our partners including AMD, Arm, Dell, Intel, and NVIDIA to optimize performance across devices. In addition, we’re releasing documentation so developers have the resources they need to get started and build responsibly with Muse Glimmer. This includes guidance on setting up custom scaffolds, so it's even easier to start building and deploying personal agents on day one. You can learn more and find resources to build on Meta's AI Developer Center.

This work builds on Meta's long track record of open AI research, extending it into agentic AI and giving developers access to local agentic capabilities. As always, we welcome feedback from the community and can’t wait to see what developers build with this open weights model.

Full article content is not available for inline reading.

Read the original article →

Every time a new open-weight AI model is released, people say that local models are the future. Why spend billions of dollars building out datacenters when everyone will just be able to run AI models on their laptops or phones? I think this idea is doomed. No matter how strong open-weight models get, most inference will always happen in AI datacenters.

Local models are too weak to be widely used

Local models are never going to be as powerful. I think this point should be obvious: all of the current frontier models (closed and open-weights) are far too big to run on anything but a full GPU cluster in a datacenter. Of course, smaller models are getting more intelligent over time. In a year you might be able to run something about as strong as GPT-5.6-Sol on your laptop. But by then, you’ll think of GPT-5.6-Sol as too weak to be useful.

Many people deny this last point, but it’s true: almost everyone’s revealed preference is to use the strongest available model in their price range. If AI progress had stalled at GPT-4, I think we could have built some very powerful tools around it, but who’d use GPT-4 today? As LLMs have gotten more capable, our expectations around them have grown: we now expect agentic systems to be able to solve more and more problems independently. It’s intensely frustrating when they get confused or stall out. When given a choice, people are going to pick the model that frustrates them less, which is always going to be the bigger, more powerful one.

Local models are more expensive and less efficient

On top of that, datacenter models are always going to be cheaper. I don’t understand why people keep saying that local models are cheap: it seems to me to be the same mistake people make when they say that driving Uber is “free money” (ignoring the costs of fuel and wear-and-tear on your car). For the setup price alone of a low-end home lab, you could buy several years of a paid subscription to one of the AI providers. The power costs would come out to around $50-$300 per month, depending on how much inference you’re running: again, the price of a couple more paid subscriptions.

Why are datacenter models cheaper? It’s not because datacenter inference is subsidized: inference is actually fairly cheap. If you’re running the same model locally and in a datacenter, the datacenter model will be inherently more efficient.

The main reason is batching. A GPU can do hundreds of thousands of mathematical operations exactly as quickly as it can do one. However, for a single user’s inference, each new token depends on the result of the previous one, so it can’t be batched. What can be batched is the inference of hundreds of users together. This costs essentially as much time, power, and heat as just doing inference for one user at a time.

When you’re running your own inference at home, you’ve got nothing to batch — at best you’re running a few parallel AI agents — so utilization is terrible. There’s a lot of potential inference that you’re paying for but can’t use: it’s just being wasted. The only way around this is to get together with some friends and expose your local inference endpoint to them (at which point you’re basically running your own crappy datacenter).

The other reason is that datacenters have larger, more efficient GPUs to work with. The kind of consumer GPUs you’d run local models on are gaming GPUs like the RTX 4090. A datacenter B200, designed for batched AI inference, gets about three times the flops and just under four times the memory bandwidth for the same amount of power. So between batching and GPU efficiency, you’re using something like ~30x the resources to run your model locally.

Incidentally, this is why I’m suspicious of people who say that local models are good because they aren’t as resource-hungry as those big bad datacenters. If you want to run LLMs efficiently, you should be trying to push as much of your use into AI datacenters as possible! Charitably, what they mean is that we should all be running smaller models — but even then, you should ideally be using small models via, say, the GPT-5.6 Luna API instead of hosting your own model.

How might local models win anyway?

Is there a possible world in which local models win? I suppose so. One thing that could happen is that governments could ban the use of AI datacenters altogether: either due to concerns around the danger of AI, or simply bending to public pressure. In that world, local models would be the only game in town.

Alternatively, AI progress might somehow stall for very large models while progressing for small ones. I struggle to imagine how this might happen (barring government intervention, as above), but a world where a 30B parameter model could be a frontier model is a world where local models might be competitive.

Or maybe models get so good that a 30B model is genuinely smart enough to do everything, so nobody really needs a model like Opus or Sol unless they’re trying to solve the Reimann Hypothesis. I don’t really buy this. Models can do frontier mathematical work today while still being not smart enough to refactor large codebases as well as me, so it’s hard to imagine a world where I don’t just want to use the smartest model available.

Local models are not useless

I do think there will always be a niche for local models. I’m reminded of the surprisingly simple idea behind Thinking Machines’ “Interaction Models” (which OpenAI also does, because it’s obvious): for latency-sensitive applications like voice chat, you have a small, fast model handle the talking, which delegates to a large, slower model for the hard thinking. I wouldn’t be surprised if most AI use in five years is mediated through a local model on your phone or laptop (though in this world almost all the work would still be done via AI datacenters).

Some users will prefer local models even though they’re weaker and more expensive. For instance, being able to steer the model locally might be a killer feature for those users. Others might simply value having total control over their own infrastructure, or have unreliable internet. If you’re one of those people — particularly if you only chat to the models instead of using them for research or coding — local models are a good choice for you. However, I think this is always going to be a niche group. The majority of users will continue to do their inference through datacenters.

1. This link is from a year ago — things are significantly more expensive now.
2. Specifically, the bottleneck is moving the model weights into the GPU, which needs to be done and takes the same amount of time whether you’re doing it for one user’s token or a hundred users’ tokens.
3. I estimated this with LLM assistance, but you can check the numbers yourself from NVIDIA.
4. While still having a reliable power supply and enough money to fit out a home inference cluster.

Full article content is not available for inline reading.

Read the original article →

Introducing Muse Glimmer (via) Meta are back in the open weights game! Muse Glimmer is a brand new 30B model under a clean Apache 2.0 license (a step up from the janky Llama licenses of old).

They claim to have optimized it for exactly the kind of things I'm looking for in a local model:

• End-to-end Agentic Task Completion. Muse Glimmer achieves strong success rates on full-task benchmarks including DeepSearch QA, MCP-Atlas, 𝛕-Bench and SWE-Bench, which measure its ability to work within scaffolds, write and debug code, and resolve multi-turn requests from start to finish.
• Reliable Tool Use. The model handles a wide range of function calls, invoking tools with precise schemas throughout extended workflows.
• Multi-Step Reasoning. Muse Glimmer chains reasoning over long horizons, sustaining coherent plans across complex, extended workflows.

Here's a pelican which I generated using LM Studio's 18.16 GB version of the model:

I also tried it out with my llm-coding-agent plugin, running against a fresh checkout of Datasette with the prompt:

how does auth work?

Here's the response, at the end of a long transcript showing all of the tool calls it made to explore the codebase. I ran this using llm-lmstudio with this patch applied to upgrade it for compatibility with LLM 0.32.

I really like this size of model, because if a machine has 32 GB of RAM or more (mine has 128GB) it leaves plenty of space for running other applications at the same time.

Glimmer is a vision model, so I asked it to describe this image:

llm -m lmstudio/meta/muse-glimmer -a https://static.inaturalist.org/photos/714731804/large.jpg 'describe image'

Here's what I got back:

The photograph shows a rocky, breakwater-style shoreline on an overcast day with a smooth, gray body of water and a faint dock/pier line in the soft-focused background.

In the foreground two large brown pelicans, Pelecanus occidentalis, are perched on the jumbled gray-white stones. They have the species’ characteristic long, down-curved yellow-orange bills with a large throat pouch, long slender necks and mottled brown-gray plumage on the back and wings. The pelican on the left is turned slightly toward the camera and appears to be preening or resting its bill against its chest; a pale, whitish patch is visible on the crown and nape and a small crest of feathers is raised. The pelican on the right faces mostly forward/right, its head up, bill pointing down and to the right, with the same pale head markings and the barred, darker wing feathers clearly visible.

Scattered among the rocks around the two pelicans are several much smaller dark birds — gulls/tern-like birds in muted brown-gray plumage. One dark bird sits on the far left on a rock, another brownish bird stands to the right of the right-hand pelican, a grayish bird with a reddish bill is in the lower right foreground, and a further small dark bird is at the extreme right edge of the frame.

The overall light is flat and diffused, giving the water and sky a muted, almost monochromatic palette that contrasts with the textured rock and the detailed feathering of the pelicans. The composition places the two big birds as the dominant subjects, framed against the calm water and the low, rocky perch.

Cory Solovewicz receives more unwanted emails than you. Seriously—it’s a lot more. Since December 2024, one of the domains at which the security researcher receives email has registered 401,796 messages—by his calculations that’s an average of 699.99 pings per day.

This deluge isn’t the regular flood of spam, newsletters, and unwanted deals that fill many people’s inboxes. Instead, companies and other organizations are inadvertently sending Solovewicz other people’s private information and company secrets. Over the last few years, he’s received injury reports from a city government, confirmation of people’s pizza orders, and account setup emails from a school platform. “I get service orders for people that need repairs. I get lots of test platform credentials,” says Solovewicz, a security researcher and consultant.

Solovewicz is receiving the avalanche of messages as he’s the owner of the domains noreply.us and noreply.net, which he purchased in 2020 and 2024, respectively. After originally planning to use the noreply.us domain as a catch-all email—which receives mail sent to any @ address on that domain—to filter messages and enhance his privacy, the researcher quickly noticed that other systems were sending mail to @noreply.us addresses. “I created an accidental honeypot,” Solovewicz tells WIRED. “I had no idea it was going to turn into this.”

Companies may send emails to [companyname]@noreply.net or similar variations believing they aren’t going anywhere, or could not be monitored in any way. Broadly it’s also possible that they may transform a person’s individual email address to send to one of these placeholder style domains if someone leaves a company or deletes their account.

What started out as a personal email project has become a large-scale effort to warn businesses and other groups that they have misconfigured their internal systems and are accidentally sharing sensitive information. Solovewicz, who presented his work at the Defcon security conference yesterday, says ultimately he is relieved that he ended up with the domains rather than criminal hackers or nation states who could use the data maliciously.

“I did not realize that this was going to be as big of a problem as it is,” says Solovewicz, who is not publicly naming impacted entities. The researcher has been alerting affected companies of their problems, encouraging them to fix the errors and misconfigurations. “I just want companies and organizations to do the right thing and to be auditing their systems and fixing their stuff.”

Solovewicz says that the noreply.net domain is the largest he owns and has received 400,000 messages over the year and a half that he’s owned it, with 28,365 of those containing attachments. The noreply.us domain has been sent 37,255 messages over 2,345 days since he purchased it in 2020. Over the month before his conference talk, combined, they’ve received more than 11,000 messages. Overall, emails have been sent from more than 14,000 “from” addresses, from 6,200 root domains. The messages are automated by company systems, not written by humans, the researcher says.

While the issue is not a new one—almost 20 years ago, independent security journalist Brian Krebs, then working at the Washington Post, wrote how companies were sending millions of messages to @donotreply.com emails—it is inherently avoidable. For instance, companies could use internal domains or the .invalid domain that is guaranteed not to exist.

Solovewicz is not alone in this voluntary endeavor, which is helping protect the data of companies—often large ones. Earlier this year, Mike Sheward, the head of security at EV charging company Xeal, spent around $15 to buy the domain deleteduser.com. “Within the first hour, there were three different organizations that had emailed stuff to @deleteduser.com,” Sheward tells WIRED, pointing out that companies appear to be simply changing email addresses rather than entirely deleting accounts from their systems.

Like Solovewicz, Sheward has seen thousands of unintended emails coming his way—from at least 100 different organizations—across multiple domains he now owns. He’s had emails detailing people’s Viagra orders, messages asking him to approve people’s work vacations or leaves of absence, hotel bookings including people’s full names, and invitations to Zoom meetings from a UK government agency. “There’s a lot of cybersecurity companies and a few Microsoft partner companies as well,” Sheward says. A couple of weeks ago he got an invitation to one San Francisco company’s summer BBQ, addressed to “Dear Deleted User.”

One of the most frequent sources of email, Sheward says without naming the firm, is an AI company that uses object recognition technology to detect workers at industrial sites in the Middle East who may not be following safety protocols. The researcher has received thousands of CCTV stills from the firm, he says. “I am being a good guardian of the Internet dumpster—but if I had been a bad one, it’s not hard to see how this information that is willingly thrown at my face could be misused,” he wrote in a Medium post in April.

As both Solovewicz and Sheward realized the potential scale of the misplaced emails—and what a goldmine the data would be for hackers and extortionists—they, working independently, have purchased more than 30 domains to try and limit the potential for malicious actors to copy the approach.

As part of his Defcon talk, Solovewicz explained he has been building a probe to test if other possible placeholder domains may be configured to receive email. “I’ve scanned 7,136 domains, and 328 of them were identified as having catch-all inboxes configured,” Solovewicz says. “I’m not sure I can say how large of a problem this is, but my concern is that what I ‘accidentally’ found when I registered my domain is just the tip of the iceberg.”

Both researchers say that, where possible, they have been notifying companies that have systems misconfigured and are sending them emails. The results have been mixed, they say. While some organizations appear to have quietly fixed the issues, many others have not replied, and the sheer scale of the problem makes notifying every one impacted a challenge.

“It is too much,” Solovewicz says, emphasizing that people shouldn’t assume a domain is unmonitored. “I’m at the point where this would now be a full-time job to handle every single one of these—that’s part of my motivation to talk about this, it is my responsible disclosure. You guys need to fix your systems and not do this and not leak your customer data and your employee data and your own internal data.”

Apple Reference Image is designed to authenticate the source of photos using unique data tied to the iPhone camera hardware that captured them.

Instead of creating high-fidelity prototypes disconnected from the product, a design team began prototyping directly inside the real codebase using Git branches, shared components, and AI coding tools like Cursor. This approach lets designers explore ideas in a safe, isolated environment while working with real constraints, resulting in more accurate prototypes, better collaboration with engineers, and clearer implementation handoffs. Figma remains useful for exploration and concept development, but the prototype becomes a working version of the product itself, reducing the gap between “looks done” and “is done.”

Prototypes built in Figma limit users to predefined paths, making it hard to tell whether a usability failure came from the design or the prototype. Building the Report Broken Site feature directly into a local Firefox Android build with AI produced a prototype with native fidelity to the device. The approach handles branching logic and real network conditions, but demands comfort with terminals, build environments, and IDEs.

Curated design references, inside your AI agent

Connect your AI coding tool to a curated library of real websites. Search by style, font, technology, and colour — without leaving your editor.

Install A1 MCP

What you can ask

Find minimal SaaS landing pages built with Framer

What fonts are most popular across SaaS sites?

Find sites with a similar feel to Stripe

Who designed the Firecrawl site and what else have they made?

Find dark, expressive portfolio sites

What’s been added to A1 recently?

What fonts are commonly paired with Inter?

How do good pricing pages look?

Find CTA sections from dark, minimal landing pages

17 tools

Reaching 1,146 sites, 3,212 captured sections, 2,812 full-page captures, 568 fonts and 507 creators.

search_websites

Full-text search across site names, descriptions, and design tags.

browse_websites

Filter by type, category, style, technology, font, or colour. Pass multiple slugs to filter by more than one value at once.

get_website

Full detail on one site — fonts, colours, styles, tech stack, screenshot, and all captured sections.

search_sections

Search inside sections — headings, body copy, FAQ questions, pricing, testimonials — not just tags. Returns the screenshot plus the extracted text, structured data, topic tags, and the measured design tokens. Filter by section type, site type, topic, or a brand colour to match.

get_website_sections

All captured sections for one site, in page order — each with its measured design tokens.

search_pages

Full-page captures of one page type across the gallery — pricing, about, careers, changelog, docs and more. Whole pages, not components, so you can see how a company designs one end to end.

get_website_pages

Every sub-page captured for one site — pricing, about, blog, careers, contact, features, work, case studies, login, changelog, integrations, docs.

analyze_section_content

Aggregate content patterns across many sections at once — e.g. what share of portfolio FAQs mention refunds, pricing, or turnaround, and the questions they ask.

analyze_design_tokens

Aggregate the measured design values across many sections — typical heading and body sizes, type scale, section padding, container width, radius, common typefaces and accent colours, reported as quartiles.

get_similar_websites

Sites that share the same category, type, and style as a reference site.

get_recently_added

The most recently added sites, newest first.

browse_fonts

Filter fonts by classification, free/paid status, or by the type of sites that use them.

get_font

Full details on one font — classification, free/paid, and how many gallery sites use it.

find_font_pairings

Real sites that use two specific fonts together.

browse_creators

Designers and studios in the gallery, sorted by number of featured sites.

get_creator

Full profile for one creator — bio, social links, and all their featured sites.

get_design_filters

All available filter values with site counts — types, categories, styles, technologies, colours, font classifications, and section topics.

Common questions

What is MCP?

Model Context Protocol is an open standard that lets AI coding agents call external tools mid-task. Connect A1 once and your agent can look up real websites, fonts, and colour palettes as structured data — without you pasting screenshots or describing what you want.

Does this cost anything?

Free with an A1 account. The first time you connect you’ll sign in — it’s free — and then you get 50 requests a day. A1 Pro raises that to 2,000 a day with a faster per-minute allowance.

Which AI tools support MCP?

Claude Code, Cursor, Windsurf, VS Code (1.99+ with GitHub Copilot), Zed (0.168+), OpenAI Codex, and Claude Desktop. Any tool that implements the Model Context Protocol spec will also work.

What data does it return?

Published website metadata: name, URL, fonts, colours, styles, technologies, and categories. Section screenshots for individual UI components — hero, pricing, features, CTA, footer, and more — each with the design values measured off the live page: palette as hex with roles, heading and body type, spacing, radius and layout, plus the copy read out as structured data, so a pricing section returns its tiers and their prices and an FAQ returns its questions and answers. Full-page captures of sub-pages — pricing, about, careers, docs, changelog and more — for seeing how a whole page is put together rather than one component. Creator profiles: designer and studio names, bios, and social links. No private or unpublished data is accessible.

How do I verify it’s connected in Claude Code?

Run /mcp inside a Claude Code session to list all connected servers and their available tools.

Exploring Claude/GPT Knowledge Cutoffs & Pre-training Timelines

An analysis of what models know and what it tells us about how they were trained.

We can learn hidden facts about how frontier models were trained by “probing” them with carefully curated requests.

• By scoring them on niche facts we can approximate how many parameters models like GPT-5 and Opus have, using “Incompressible Knowledge Probes”
• By measuring how the models break down tokens we can reveal facts about the datasets mixtures they used to train the model (or at least the tokenizer) using “Data Mixture Inference”
• By scoring them on date or self-identification related questions you can also estimate training timelines (this post)

Everything here is an estimate. It’s possible that some speculation in this post is totally incorrect given there’s not a ton of publicly available ground truth to verify against.

How frontier models are trained

As a brief primer, how we train massive large language models has converged into 3 stages:

1. Take a massive amount of general purpose data (aka scrape the internet) and “pre-train” a massive auto-complete model on that data.
2. Use domain-specific “textbook quality” data to improve the base models and extend certain base capabilities like long-text understanding
3. Turn the base model into the “assistant” persona, honing in on its personality, reasoning ability, and tool-calling.

While increasingly more compute is spent on post-training for boosting a model’s reasoning and problem solving, one of the most expensive and data-intensive steps is generating that pre-training checkpoint.

While all labs operate slightly differently, what you might see is:

• The “pre-training” team kicks off and babysits a multi-month run to get a base checkpoint. These pre-training models often, but not always, imply major versions of released models (GPT-4 → GPT-5).
• While that’s happening, the “capability” and “post-training” teams will run experiments for how to improve on the most recent base model. Advancements in post-training and capabilities often manifest as minor versions of released models. These teams often also “distill” a single post-trained model into smaller variants that become model families. Labs may also release post-trained models from half-baked pre-training checkpoints as soon as x% of the version N+1 checkpoint is better than the 100% baked version N checkpoint.
• The model released to the public is the culmination of the most recent checkpoint with the best set of capabilities and post-training techniques applied to it.

With this in mind, I was curious how much of this process you can “see” just by probing the model over the official APIs.

Model Knowledge Timelines

Historical Quizzes

To estimate the pre-training checkpoint dates, I constructed a dataset of daily-facts from Wikipedia and gave every model an 8-way multiple choice quiz on what happened on a given day. Then, by analyzing the error rate timeline, you can see roughly when it loses signal from its training dataset.

After staring at these charts for a bit, here’s what I’m speculating:

• Anthropic models Opus 4.7 onwards are all from the same training run that cuts off just around late December 2025. This is derived from how they all share a very similar effective knowledge cutoff (green). A core assumption I’m making here is that the pre-training base model completion date is highly correlated with the dataset timespan used, if that’s wrong these results could be off by some offset (e.g. it’s actually Jan 2026). It’s also interesting that Opus 4.7+ models all have a published reliable and overall knowledge cutoff that’s identical — maybe that’s due to a new post-training technique being used?
• OpenAI’s GPT-5.6 family comes from their own checkpoint, separate from GPT-5.5, that finished around late February 2026. This is derived from how they have a distinct effective knowledge cutoff from previous models. You’ll notice Luna looks like it can predict the future — that’s more of an artifact of it having a high error rate all around at a “low” reasoning effort.
• Opus 5 is a bit unusual. The published reliable and overall knowledge cutoffs are May 2026 and yet it seems to know nothing more than previous Jan 2026 cutoff models. I did several ablations to test whether it was an artifact of the types of probing questions I used, but not really — the cutoff applies to recall on coding package versions as well.

Self-reported Dates

What if you just ask the model what today is? It ends up being fairly correlated with fact-based estimates. If you look closely you can see some vertical lines within a few of the families of models.

• GPT-4.1 nano → GPT-4.1 mini → GPT-4.1
• Opus 4.7 → Sonnet 5 → Fable/Opus 5

Interpreting this graph as X = “pre-training corpus” and Y = “post-trained behavior”, these vertical strips (X constant, Y increasing) visualize active post-training on recency-biased datasets. Potentially distillation from old copies of teacher models is what causes smaller models to self-report older dates.

Self-reported Identity

You can also make predictions on training timelines and datasets indirectly by looking at who the models think they are. The more a model sees “I am X” in its pre-training dataset, the more likely it is to repeat that when pushed and given no other grounding context.

After staring at these charts for a bit:

• Vertical bands show clear patterns of labs training on past-model outputs (from users). For OpenAI it’s GPT-4, GPT-4o, GPT-4.1 for a bit, GPT-5 and “ChatGPT” most recently. For Anthropic it’s 3.5 Sonnet then more recent models swap to Sonnet 4.5. This seems to align pretty well with training on chats from ChatGPT.com and Claude.ai respectively, where users chatted with the latest model and whose sessions became training material (directly or via web contamination). It seems unlikely to me these are coming from internal synthetic datasets given those would be much easier to suppress model identity.
• It’s a bit spicy that OpenAI models never identify as another lab’s model (besides briefly a Tesla Model S) yet Anthropic’s Sonnet 5 will regularly self-identify as GPT-4. It feels very unlikely that they are intentionally distilling GPT-4 but it’s possible a bunch of older ChatGPT chats are still making their way into the Claude training mixtures. It could also be carried through the generations via Sonnet 3.5 lineage. On top of this, in a follow-up experiment, when asked to answer identity questions “as model X would,” Claudes reproduce OpenAI models’ measured quirks at 68%; OpenAI models manage 8% on Claudes.

Are agents really killing UI?

The UI is dead. Or so I keep hearing:

"Agents are your users now, software is losing its head, and everyone who learned Figma should start learning Bash."

Maybe the UI is dead in four square blocks of San Francisco (where folks are running multiple Mac minis for clawbots). But I'm a regular person at a screen for most of my day, and so are the people I build for.

Here's my take:

• Everything is a user interface if I'm using it
• My agents are using it too now, just not the part you designed
• Headless is a new layer on top of product building, the same way APIs and the GUI once were
• If you're a product builder, congratulations! That means your job just doubled: every user of your product is bringing an agentic plus-one.

Here's a few things to consider in this hybrid (not headless) future.

Your homepage isn't the front door

If you're building for a technical audience, onboarding them into your product increasingly won't start from a "get started" button. It'll start in a terminal or an AI chat window.

This is less true for consumer products, but the pattern is spreading – especially if your AEO game is strong. A new user chatting with Claude or ChatGPT may never see your homepage at all. They'll ask the agent for a recommendation, it'll point them at you, and (with user permission and a good MCP) set up your product right there.

The catch is you can't count on the agent to read your install docs. A capable one might go looking, but plenty won't. So setup has to be something an agent can finish on its own (easy to find, easy to authenticate into, and done in one call instead of ten steps).

Get that right and you've handled the agent, but don't forget the person behind the agent. Expect that, eventually, they'll open the product and need to work out what it does and what to do next. That requires UI, baby!

Go build

Design two entry points to your product:

• For the agent: a signup flow it can finish end to end (fork ours, our competitors already have). Also, a listing where agents look for connectors (like the Claude and Codex app directories), docs it can parse (an llms.txt, pages served as plain Markdown), and auth that's safe when it improvises (short-lived, scoped tokens).
• For the human: where you start them depends on how they got there. If their agent set things up, they're landing in the middle of a process, so show them what's been done and what's missing. If they clicked around themselves, just point them at the next step.

What this looks like:

• The fastest way to try PostHog is the npx -y @posthog/wizard@latest command that sets up your account, scans your codebase for what to instrument, and logs each step in your terminal as it goes. Once it's done, some people continue their PostHog journey headless through the MCP. Plenty of others jump back into the web app (they want to see their data and click around).
• Our Slack app turns a message prompt into a draft PR. I 99% trust it to build things correctly. The 1% difference is why I still check the diff in GitHub (a different UI) before merging it.
• AgentMail's onboarding docs teach the agent to provision an inbox and key itself (no console required). Even there, a human UI is needed, and that UI is email: a six-digit code gets sent to a person. Until a human hands it over, the agent can only send mail to the address it signed up with.

If a human can do it, an agent should too

Mostly, agents don't touch your UI. Some can (computer-use agents like Perplexity's Comet will click around a live DOM), but that's a slow and human-shaped UX (user experience).

What agents need instead is AX (agent experience) – how easily an agent can use your product and recover when something breaks. The current standard for AX is the Model Context Protocol (MCP): you run a server that describes what your product can do, an agent can connect to it, see what's on offer, and interact with your product directly.

Go build

Unlike a magician, you do want people looking up your sleeve. If you think your product is agent-friendly, prove it: run it headless and see where a human still has to step in. There are probably more of those moments than you'd expect.

Make sure that for every action there's:

• A way for the agent to do it
• A way for the person to check it got done

What this looks like:

• Vercel's MCP server lets an agent inspect deployments, pull runtime logs, and trigger deploys. When it ships something, the change appears in the human UI too (the Vercel dashboard), with the same logs and rollback capabilities.
• Our own MCP server lets an agent create a feature flag or launch an experiment using your credentials. Changes land in the project's activity log attributed to your account, with the calling agent client recorded alongside it (the x-posthog-client header) so you can filter for changes an agent made rather than a person.

Watch what agents actually do

User frustration leaves marks all over the UI (rage clicks, abandoned forms, chaotic mouse movements) which is why session recordings are a goldmine for product builders. Agents leave none of those marks – they hit your API (not your front end) so pageviews and autocapture don't fire, and there's nothing for a replay to catch.

Agents also fail differently than humans, in ways no error category in a log was built to catch. An agent might invent a parameter, trip validation, hit unexpected permission walls, time out, or hallucinate a tool. Server-side requests like these land looking like any other integration (there's usually a user agent string somewhere), but nothing that captures what the agent was trying to do, and whether or not it succeeded.

We got tired of not knowing, and built MCP Analytics which turns every agent tool call into an event – intent included. That's the most useful signal of all: when an agent reaches for a tool your product doesn't have, that's a feature request written by a robot.

Last month, we tracked close to 10 million tool calls from 31 different agent clients. Behind those calls, real people were building things like this:

• Wired PostHog to send a text message when a certain metric moves
• Shipped an A/B test on a "skip the intro" screen (feature flag, 50/50 split, and all)
• Triaged live production errors like expired magic links and missing auth sessions

Note that what's missing from this work is a not a UI, but the PostHog UI specifically. Those 31 clients like Claude Code, Cursor, Cowork, Linear, Notion all have a user interface. A terminal is a UI. A chat window is a UI. Slack is a UI. Headless PostHog users are still looking at a screen.

Go build

Instrument agent traffic the way you already instrument humans: tag every call with the client it came from, then watch where agents retry or give up. And enjoy the irony, because the thing you built to watch a swarm of agents who never touch a UI is... a UI. Even here the answer is a screen for a human to interpret.

What this looks like:

• In June, Cloudflare's Radar data showed automated requests overtaking human ones on HTML traffic for the first time, 57.5% to 42.5%, about 18 months earlier than its CEO had predicted. You can read that as the end of the screen if you like. I read it as a lot of people asking for things, then agents going to look at the answer.
• Temporal records every step of an agent's run as a durable event history you can replay and inspect where a loop stalled or repeated itself (UI to keep an eye or your AI).

Build an interface worth interacting with

If you're building something agent-shaped (and I think you should be) your product's UI might matter less to some users – but that doesn't make it obsolete. A good UI gives you a sense of state at a glance – the way a door handle tells you to push or pull. On a screen, that looks like a spinner that means wait, a greyed-out button that means not yet, or a red badge that means look here! As a human being, I take that in ten zillion times faster than I'd skim the equivalent wall of AI-generated text.

Agents in the mix simply shift what there is to design for, and that's the fun part, honestly. The screens worth building now do different work. You're designing for moments like:

• Approval – the agent has the change ready and needs a yes. Can the human tell what they're saying yes to in two seconds?
• Review – not a summary of what changed. The change itself. A diff beats a paragraph.
• Undo – when the agent gets it wrong, there needs to be a way back.
• Legibility – a feed you can scan to instantly tell which actions came from a colleague and which came from a bot.
• Orchestration – if five agents are running at once, do you watch them on one screen, or open five chats?
• Interruption – when you need to steer the agent while it's still moving.

Go build

Deprioritize the screens that agents make redundant, and treat your MCP as a product. Then build the decision surfaces properly: show the diff, not a summary of the diff. Put an undo next to anything an agent can do on its own. Label the things an agent did, so nobody has to work out who changed what. Show state visually, because humans parse color and shape far quicker than text.

A good MCP puts your product wherever the user already is. That's reach – it's not quality. Your moat might actually be a UI that's easier to use and nicer to look at, than whatever your MCP is competing against. People pay real money for a great experience. So make the UI that agents don't touch delightfuly human.

What this looks like:

• Intercom's Fin Operator tunes Fin for you, then hands the work back as a screen. Every change arrives as a proposal, a structured diff of what's changing and why, which you review, edit, and approve before it takes effect. The agent does the work. The human decides what ships.
• Anthropic could have left Claude Code in the terminal. Instead it shipped a desktop app, a web app, IDE extensions, and Cowork, all wrapping the same models in more interfaces. Some people love the CLI precisely because there's so little UI in the way, and others go straight for Cowork.

The future is hybrid (not headless)

Agents might be the primary users of software soon by sheer volume. But by meaning? There's no agent without me. Text scrolls past and I skim it. A screen makes me stop and look. Looking (and clicking around a UI) is where I catch what the agent got wrong, and where I still feel like I'm holding the wheel.

None of which means the plumbing doesn't count. Good products for agents are, after all, are a pile of Markdown, SQL, tools, and resources under the hood. But I'm a human living in a home, not a data center. So give me and my agents a reason to use your thing, and you'll be in good shape.

Qwen-MM-Plugins

Native multimodal plugins for Qwen models. Make any agent harness multimodal-native.

Contents

• 🧩 Capabilities
• 🏗 Architecture
• 📦 Installation
• 🔧 Dependencies
• 🔑 Configuration
• 🚀 Quick Start
• 🧪 Development

🧩 Capabilities

Each capability is installed separately — a skill (so the model knows the toolset exists) plus an optional MCP server (the tools themselves).

We ship cookbooks of Qwen3.8-Max + these plugins in action — each capability's cookbook has its full tool listing, setup, and worked cases.

🏗 Architecture

📦 Installation

A capability = a skill (so the model knows the tools exist) + an optional MCP server (the tools themselves, launched on demand by uvx — needs uv, no manual pip).

Recommended: the guided installer

One script handles install · configure · verify · uninstall across every harness it supports (Claude Code · Codex · Qoder · OpenClaw · Qwen Code · Gemini CLI). It drives each harness's own native install under the hood — nothing reinvented — and writes a single shared config file (~/.qwen-mm-plugins/config) that GUI and terminal harnesses both read, so you set things up once:

curl -fsSL https://raw.githubusercontent.com/QwenLM/Qwen-MM-Plugins/main/install.sh | bash

Windows x64: use WSL2 (Ubuntu recommended) and clone the repository inside your WSL home directory (for example ~/code), rather than under a mounted Windows drive such as /mnt/c. Then run the same commands there. WSL2 is currently the only supported Windows environment; native Windows has not yet been validated.

By hand (per-harness)

Prefer your harness's own commands — or you're on opencode / pi / QwenPaw, which the installer doesn't cover? Register the skill + MCP yourself.

Plugin-marketplace harnesses (Claude Code · Qoder · Codex · OpenClaw · Qwen Code) — add the marketplace, then install a capability (replace <cap> with core / api / search / video-memory / video-edit / blender / freecad). Install core by default — it's the local-I/O base every other capability builds on — plus whichever others you need:

# Claude Code
claude   plugin  marketplace add https://github.com/QwenLM/Qwen-MM-Plugins.git
claude   plugin  install       qwen-mm-plugins-<cap>@qwen-mm-plugins
# Qoder
qodercli plugins marketplace add https://github.com/QwenLM/Qwen-MM-Plugins.git
qodercli plugins install       qwen-mm-plugins-<cap>@qwen-mm-plugins
# Codex
codex    plugin  marketplace add https://github.com/QwenLM/Qwen-MM-Plugins.git
codex    plugin  add           qwen-mm-plugins-<cap>@qwen-mm-plugins
# OpenClaw
openclaw plugins install       qwen-mm-plugins-<cap> --marketplace https://github.com/QwenLM/Qwen-MM-Plugins.git
# Qwen Code
qwen extensions install https://github.com/QwenLM/Qwen-MM-Plugins.git:qwen-mm-plugins-<cap> --consent

🔧 Dependencies

uvx installs the Python dependencies for the chosen profile on first launch — no manual pip. The only things you install yourself are system tools: ffmpeg (video / audio), plus optional libreoffice / blender / texlive / chromium for visualize. Run bash install.sh verify to self-test what's installed — it confirms your API key and reports any missing system tools.

🔑 Configuration

The API-based tools need a key — native image / video / document reading doesn't:

• DASHSCOPE_API_KEY — vision_chat / ocr / grounding / transcribe_audio / Omni audio-video understanding / generation / video-memory build
• SERPER_API_KEY — web_search / web_extractor / image_search

Export them in your shell, or persist them to ~/.qwen-mm-plugins/config. The guided installer's Configure step writes that file for you:

bash install.sh configure

🚀 Quick Start

Once a capability is installed, reference a file in your harness and just ask — the model picks the right tool automatically. Reading is dynamic-resolution: every image, video frame, and document page is auto-scaled to the VL model's patch grid, so a 4K screenshot's fine print and a tiny thumbnail both come in at the detail they need — no manual resizing.

# core — read images / video / docs / 3D models (local, dynamic-resolution)
@dashboard-4k.png      Read every number in this dashboard.
@report.pdf            Summarize page 3.

# api — cloud VL + Omni APIs: caption / OCR / grounding / segmentation / ASR, plus Omni audio-video understanding
@receipt.jpg           OCR this and total the line items.
@street.jpg            Draw a box around every car in the scene.
@meeting.mp4           Transcribe this with speaker labels and timestamps.
@sports-clip.mp4       Count every completed pass and list when each one occurs.
@song.mp3              Tag the genre, mood, instruments, key, and vocal profile.

# search — web + reverse-image search to confirm what's on screen
@place.jpg             Where was this photo taken?

# video-memory — QA over long videos; the first query auto-builds memory
@lecture-2h.mp4        What are the main points, with timestamps?

# video-edit — image / video / audio generation + editing workflows
                       Generate a 1024×1024 image of a red panda coding at night.
@/path/to/media        Help me edit this video down to about 3 minutes.

# blender — drive a running Blender to model / texture / light / render (thin client, 22 tools)
                       Model a low-poly wooden stool, add a warm key light, and render it.

# freecad — parametric CAD in a running FreeCAD (thin client, 14 tools; STEP/STL, FEM)
                       Model an M6 hex bolt 30 mm long and export it as STEP.

# edu-agent — turn a math/science problem into a step-by-step Chinese explainer video (skill-only)
@geometry-problem.png  Explain how to solve this as a narrated video.

🧪 Development

Development setup, contribution guidelines, and verification commands are in CONTRIBUTING.md.

📄 License

Apache-2.0. The Blender and FreeCAD capabilities vendor third-party MIT-licensed code.

A Controlled Study of Attention-Only Transformers

Feed-forward networks hold two thirds of a transformer's non-embedding parameters, yet the architecture has not received a necessity test that controls parameters, compute, and depth at once. We pretrain attention-only decoder transformers (Simple Attention Networks, SANs) against standard transformers matched separately for parameter count, training FLOPs, and depth (2 to 48 layers), for up to 105B tokens at 6M to 87M parameters. Deleting feed-forward layers in place is costly: the standard transformer leads by 0.47 nats at matched depth and 0.26 nats at matched FLOPs. Reallocating the freed budget into attention depth closes the gap: at matched parameters the difference is 0.006 nats (0.27 percent of loss), reproducible to one part in ten thousand across seed pairs, shrinking across 5B, 30B, and 105B budgets, and holding near 0.02 nats across a 29x size range. Three measurements localize the remaining gap to parametric recall: attention-only models are better on context-grounded answers and worse where knowledge must come from weights. Weight spectra show why: routing matrices (Q/K) crystallize early, content matrices accumulate rank slowly, and removing feed-forward layers relocates this accumulation to the attention output projection. QK-normalization, not feed-forward layers or residual gating, keeps 48-layer attention-only stacks trainable. The deficit concentrates on low-context query prediction and localizes there entirely by the largest budget. A pre-registered test confirms the account: it predicts a 0.02 to 0.05 nat gap on knowledge-dense web text; a matched pair trained on fineweb-edu measures 0.040. Within the tested regime, attention does the rest.

Full article content is not available for inline reading.

Read the original article →

AI demand is exploding. But while there's been plenty of discussion on the GPU and memory supply chains, the real constraint to expanding AI capacity is power.

Data centers already account for ~5% of US power consumption. With data center power demand doubling every two years, demand would in theory outpace total US power generation by the mid-2030s.

Building a data center requires thoughtful planning around permitting, surrounding infrastructure, and anticipated power prices. In many cases, the variable cost of power determines whether or not a data center is viable at all.

I'm a former quant researcher at a major hedge fund who covered power and gas, and I've spent much of the last couple of years advising founders and investors on data center buildouts (procuring GPUs, negotiating with coal plants, identifying sites).

This primer on power and data centers is for a broader audience who senses there's an opportunity in energy markets and wants to get up to speed.

By the end of this primer, you'll understand:

• Part 1: how power plants work, how data centers are developed, and how companies might respond (for founders/investors).
• Part 2: how to price the US power markets (for traders).

If you're really interested in power, I'd advise you to read the whole thing. Hopefully you find it timely and interesting.

Full article content is not available for inline reading.

Read the original article →

Nvidia is reportedly testing variations of its upcoming Rubin Ultra accelerator with less memory due to concerns it won't be able to source enough HBM. Some versions include just 192 GB of memory and use HBM4 instead of HBM4E, as originally announced, according to The Information. The report confirms an earlier comment from firm SemiAnalysis about a potential Rubin Ultra memory downgrade.

We first saw Rubin Ultra in the flesh earlier this year at GTC, where Nvidia showed off a compute tray housing four compute chiplets alongside 1 TB of HBM4E memory. The accelerator is part of Nvidia's Kyber NVL144 design, which is set to roll out in 2027. SemiAnaylsis reported that the rack was delayed to 2028. "Our roadmap is intact," said Nvidia to Tom's Hardware in response, though the company made no clarification on if the delay was real or not. We've reached out to Nvidia regarding this latest report.

According to The Information, Nvidia is testing versions of Rubin Ultra with 192 GB or 256 GB of memory, as well as versions that use fewer than the 16 announced memory stacks. Perhaps most importantly, Nvidia is reportedly testing with HBM4, not HBM4E as originally announced. Along with the traditional improvements we see in each new HBM generation, HBM4E is unique in that it offers a customizable base logic die. Last year, Micron announced a partnership with TSMC to manufacture the base die and allow customers to tweak the logic die based on their needs.

The complexity of HBM4E has reportedly caused a strain on supply, with memory manufacturers unable to keep pace with Rubin Ultra's rollout. At least three lower-memory designs have been tested by Nvidia, according to the report, though we don't have a full picture of details on those prototypes. The report claims testing with HBM4, as well as 192 GB and 256 GB configurations, though it makes no mention of the number of compute dies, nor the memory type for each tested capacity.

The number of dies is important. In June, reports circulated that Nvidia cancelled its quad-die Rubin Ultra design due to manufacturing complexities. Although Nvidia has yet to comment, reports at the time suggested Nvidia would move ahead with a dual-GPU Rubin Ultra. In such a case, less memory would make more sense. Even with a dual-die Rubin Ultra, the quoted capacities are lower than expected. Each base Rubin GPU currently ships with 288 GB of HBM4.

It's clear Nvidia is trying to get ahead with memory in a world where agreements have been signed multiple years into the future. Nvidia has several of its own agreements. In June, the company announced a partnership with SK hynix to develop next-generation memory technology, which includes HBM, but also LPDDR5X and DDR5. In July, Nvidia expanded that partnership with a $500 billion strategic relationship that includes a long-term memory supply agreement with SK.

Although Nvidia is considering lower-memory configurations, one Nvidia customer told The Information that per-GPU memory isn't a top concern, valuing the relationship with Nvidia over the long term.

Memory shortages are touching nearly every design currently on the market, though enterprise systems packing HBM are particularly vulnerable. Last week, Digitimes reported that Samsung, SK hynix, and Micron have sold through their HBM capacity through 2027. Last month, SK Hynix CEO Kwak Noh-jung said 2027 will be the "worst year" for the memory shortage, with supply constraints lasting through 2030.

Mark Zuckerberg recently released a wide-ranging essay that outlined a new course of action to spread the wealth and opportunity from AI to users around the world, and to residents of the communities that host the data centers powering it. Zuckerberg's plans include releasing more open-weight models and establishing a $1 billion fund to invest in the communities where Meta hosts data centers. He believes that Meta's approach to developing powerful AI and distributing it as widely as possible is the least likely path to disastrous outcomes for humanity. The commitment marks a significant development in the debate around whether advanced AI is too dangerous to create on an open-source basis.

A new day has dawned in the Play Store, and it’s one that Google tried very hard to avoid. The first third-party app store has arrived in Google Play as a result of the long-running antitrust lawsuit with Epic. Those in the US can now head into Google Play and download Aptoide, a game-focused store that has been available as a sideloaded client since the early days of Android.

Forcing Google to distribute third-party app stores in Google Play was one of several remedies imposed by Judge James Donato after Epic emerged victorious in 2023. The remedies also included lowering developer fees, mirroring Google Play apps in other app stores, and allowing developers to use alternative payment systems. But it was the app store stipulation that seemed to irk Google the most.

Google almost avoided this outcome when it agreed to a settlement with Epic, which was announced early this year. Under the terms, Google would certify third-party app stores to allow users to install and use them with less friction, but it would not host them in Google Play. However, Google and Epic withdrew the settlement when it appeared the court would not approve it. This Registered App Store program is still slated to launch internationally, but in the US, Google is only doing what it must to comply with the judge’s orders.

The upshot is that you can now download Aptoide from the Play Store on your Android device from this link. You can install the store just like you would any app—you don’t have to enable sideloading or tap through any scary warnings. Likewise, you can install games via Aptoide just as easily as you can through the Play Store. This is much smoother than the previous sideloading process.

Aptoide’s offerings are currently quite sparse compared to Google’s, but Aptoide CEO Paulo Trezentos confirms the company has access to the full app catalog of 1.9 million apps and 295,000 games, as allowed under the judge’s ruling. More will be added in the future, giving users the option to download much of the same content available in the Play Store. Developers can opt out of this sharing arrangement, but it’s really just another acquisition channel that uses the same versioning and billing as the Play Store, so it’s unlikely many will want to stay Google-only.

Ghost town

The new third-party app stores page in Google Play is currently empty aside from Aptoide. This menu is pretty buried in the Play Store at this time. You can find it under Apps (bottom bar) > Categories (top bar) > Third-party app stores (way at the bottom). You can also search for “Aptoide,” and Google will suggest the link to the app store list, which will presumably fill out in time. We’ve asked Google if the app store list will be more accessible in the future and will update this article if we hear back.

It’s curious that Epic, the company that sued over being unable to effectively distribute its Android storefront, was not the first to take advantage of the ruling. It certainly has the money and resources to beat Aptoide to the punch, as does Microsoft with its planned Xbox mobile store. But for now, Aptoide stands alone.

Trezentos notes that there was still considerable friction getting to this point. Google was under order to begin offering alternative app stores on July 22, but that’s only when it published the rules and fees to access the program. Google stipulates that stores must have reasonable security practices and user safety features and must provide copies of APKs to Google for review before serving them to users.

Participation costs the app store operator $15,000 up front, $5,000 of which will serve as credit for review costs. However, Google may charge more if costs climb higher (which they likely will). Oddly, Google’s landing page claims it does not “review every app in these stores.” Regardless, the program could end up a spendy proposition for a smaller storefront, but the access it gives to users in the Play Store could still make it worthwhile. Aptoide seems to think so, which is why it spent the past few weeks working toward approval.

A reported DRAM shortage could limit iPhone 18 Pro availability at launch, despite strong production of Apple's new A20 Pro chip, as TSMC is unable to complete final packaging without the required memory components. Apple is expected to have enough inventory for the initial release, but online delivery times may slip and retail stock could sell out quickly after the first wave. The shortage could be amplified because Apple reportedly isn't launching a standard iPhone 18 or a new iPhone Air this fall, leaving the iPhone 18 Pro lineup and the premium foldable iPhone Ultra as the main new options for buyers.

Apple is reportedly rethinking the future of the Apple Watch as competition from devices like the Oura Ring grows, exploring new concepts that could include circular watch faces, screenless fitness wearables, and both more premium and more affordable models. The company is also considering a broader health-focused strategy tied to AI-powered software experiences, though no major redesigns have been finalized and any radical changes are likely years away. In the near term, Apple is expected to launch the Apple Watch Series 12 and Ultra 4 this September alongside the iPhone 18 Pro and the first foldable iPhone, with updates focused on processors, colors, and fitness features.

Loova Agents: Director-Like AI Video Agent

Turn ideas into videos faster. Plan scenes, direct your story, and generate ads, films, UGC videos, and explainer videos on an infinite creative canvas.

Create Like a Director with Loova Agents

The First Director-Like AI Video Agent

Loova Agents works like a creative director for your videos. Instead of manually building scenes, editing clips, and arranging shots, you can simply describe your vision in natural language. The AI video agent analyzes your idea, plans the scenes, directs the flow of the story, and generates the video automatically. This makes it one of the most advanced AI video agents for creators who want cinematic results without complex production tools.

Infinite Canvas, Boundless Imagination

Great stories need space to grow. Loova Agents provides an infinite canvas where you can visualize ideas, organize scenes, and explore creative directions freely. You can develop your video like a storyboard, experiment with styles, and refine the narrative while the AI helps generate visuals and sequences in real time.

Built for Any Video Use Case

Whether you are creating marketing content, AI film projects, social media videos, music videos or talking avatar videos, Loova Agents adapts to different needs. The AI can generate structured scenes, adjust pacing, and match visuals to the tone of your idea. This flexibility makes it useful for creators, brands, marketers, and filmmakers who want to produce videos quickly without sacrificing creativity.

Beyond Loova Agents — An All-in-One Creative Playground

Loova Agents is part of a larger creative platform designed for modern content production. In addition to AI video generation, you can access advanced image models, editing tools, and AI-powered creative features in one place. From generating visuals to refining scenes and exporting finished videos, everything happens in a single streamlined workflow.

What Can You Create with Loova Agents?

Explore More AI Models

Loova integrates multiple cutting-edge AI video and image models so you can experiment with different visual styles, motion effects, and creative approaches. Compare outputs and choose the best result for your project.

FAQs About Loova Agents

What is Loova Agents?

How does an AI video agent work?

What kinds of videos can Loova Agents create?

Do I need video editing skills to use Loova Agents?

Can I use Loova Agents for commercial projects?

What makes Loova Agents different from other AI video tools?

Create Videos with a Director-Like AI Video Agent

Turn your ideas into cinematic videos with Loova Agents. Plan, direct, and generate professional videos in minutes.

DESIGN.md files let AI follow documented design rules, and accessibility fits that format because WCAG requirements are measurable and built on decades of consensus. Broader ethical pillars — autonomy, transparency, privacy, inclusion, and well-being — resist the same treatment, since spelling them out would demand thousands of concrete rules. A modest first step is one testable rule, such as requiring no more steps to cancel a service than to sign up.

OpenAI introduced GPT-5.6-Cyber, a specialized model for vulnerability research, exploit validation, and other advanced cybersecurity tasks. The company also expanded its Daybreak program with Blue and Red access tiers designed to give approved defenders access to increasingly capable AI tools.

Anthropic is meeting up with investors to offer assurances about its rapid pace of growth and insights into the company's strategies to address growing public backlash against AI. The company must address issues like the recent popularity of cheaper AI systems from China, tensions with the Trump administration, and growing backlash to data-center construction ahead of its IPO. The conversation reflects the tremendous uncertainty around who will win the AI race and the financial stability of the businesses that underpin it. Anthropic is targeting a public debut in September or early October.

OpenAI reportedly completed a $7 billion employee tender offer

OpenAI has bought back $7 billion worth of shares from employees at the privately held frontier AI lab as part of an effort to provide liquidity to its workforce.

The deal, reported by Bloomberg, valued OpenAI at $852 billion, the same as its most recent fundraising round in March, which added $122 billion to the company’s war chest.

The company also filed confidentially with the Securities and Exchange Commission in June to prepare for a potential IPO later this year. However, a tender offer suggests that an IPO may not be forthcoming soon. With many tech companies remaining private longer than previous generations of startups, private tenders have proven a useful way for firms to allow employees to realize the value of their stock compensation without the difficulties that come with a public offering.

OpenAI did not respond to a request for comment by publication time.

Last month, OpenAI CEO Sam Altman wrote that “we did not have our best 12 months ever, which is mostly my fault, but we are about to have our best 12 months to date.” Firms going public typically want to show strong financial results to bring investors on board, and The Wall Street Journal reported in April that the company missed internal financial goals.

While OpenAI’s incredible growth and products are likely to generate massive interest in public markets, the potential debut of rival Anthropic — which was reportedly profitable earlier this year — gives the company a reason to ensure it puts its best face forward. The tender could be another signal that the much-anticipated offering will wait for OpenAI’s new strategy of paring down its bets and focusing on its enterprise business to gain traction.

Microsoft plans to unveil its Maia 300 AI chip in September, aiming to reduce reliance on Nvidia GPUs.

Google is testing a version of its homepage where the search button is replaced with an AI Mode button. The new interface allows users to ask about files and use the Brainstorm function without having to log in. Logged-in users are also able to generate images. Ask about files allows users to attach a file before submitting a question, and Brainstorm helps users explore ideas.

The conditions for Elon Musk to receive his $1 trillion pay package at Tesla could easily be achieved if the company were acquired. There is a clause in the agreement that declares half the targets as good as accomplished if Tesla is acquired or otherwise taken over. This leaves only market-value targets to determine how many shares Musk gets. Musk has considerable say over any offer SpaceX makes for Tesla. Even a stratospheric bid would keep Musk in firm control of the combined company.

Gemini's new Wear OS look, first shown with Wear OS 7, is rolling out with a Neural Expressive overlay that sits on top of the watch face. Rather than taking over the screen as a separate app, it matches the assistant's appearance on Android phones and tablets. Play Store screenshots show a live transcript of requests and confirmations once an action completes.

CEOs and VPs ignore almost everyone because the entire organization competes for their attention, so feeling overlooked is not specific to design. Designer ego turns that frustration into self-centered complaints that executives hear all day and tune out as static. Curiosity works better: asking who holds influence, how they got it, and what would need to change personally.

Every onboarding, paywall, and flow — 28,200+ screens from 690+ top-earning iOS apps. New apps weekly.

Eugene Golovanchuk is a self-taught Kyiv-based 3D artist known for cyberpunk-tinged dark surrealism and digital fashion, built through a daily practice begun in 2016.

Two communication design graduates interviewed nearly 50 agency leaders, artists, and AI provocateurs, then cut the results for a book titled Are we cooked?! that catalogues how differently its subjects describe AI — black magic, a weak intern, fast food, an exoskeleton.

OpenAI shared five lessons from rebuilding its finance function around AI, with long-term goals including a zero-day close and continuously updated forecasting. The approach emphasized redesigning workflows around decisions, live business context, human accountability, experimentation, and measurable AI-driven output.

Meta plans to democratize superintelligence by creating personal AI agents to enhance individuals' capabilities while ensuring privacy. Emphasizing invention over automation, these tools will empower people to shape their future, boost economic growth through entrepreneurship, and accelerate scientific progress. Meta advocates for a balance of power to prevent singular centralized AI, ensuring AI serves humanity by empowering individuals rather than institutions.