NVIDIA will sell significantly more Oberon Rubin racks and Oberon Rubin “Ultra” racks to make up for this shortfall. We discuss the implications of these mass NVIDIA delays and cancellations for the memory, PCB, and ODM supply chains in our Core Research and AI Accelerator Supply Chain model. 6/6🧵

This news also comes as the 4-compute-die Rubin Ultra has been cancelled, leaving only the smaller 2-compute-die Rubin Ultra, which will deliver roughly half the real-world performance of the 4-die Rubin Ultra. 5/6🧵

As the NVIDIA roadmap indicates, CPO NVSwitch will not be available until Feynman. As a result, NVIDIA currently has no proven solution to expand the scale-up world size for Rubin Ultra, leaving a gap for competitors like AMD MI500X or TPUv8i Broadfly to gain scale-up advantages over Rubin Ultra. 4/6🧵

NVL72x2 back-to-back rack architecture was the new proposed architecture NVIDIA was developing as an alternative to Kyber. It was designed to increase the pure-copper NVLink scale-up world size by placing two Oberon racks back-to-back. However, it has since been cancelled due to heavy pushback from CSPs and hyperscalers over its odd design and heavy operational burden. 3/6🧵

Kyber NVL144 rack architecture has been delayed to 2028 as the PCB midplane remains challenging from a manufacturability standpoint. NVL576, which connects 8x Oberon racks over CPO between the NVSwitches, is also likely delayed or restricted to small volumes given the current challenges with CPO. 2/6🧵

MASSIVE DELAY: Just 3 months after Jensen demoed Kyber NVL144 at GTC, it has faced major setbacks and has been delayed by more than 12 months, pushing it back to 2028. Below, we explain why Kyber has faced massive delays and why NVIDIA’s NVL72x2 back-to-back rack architecture was also cancelled, leaving Rubin Ultra with a limited scale-up domain. 👇️ 1/6🧵

God bless America the land of the free and home of the brave 🫡 250

So while all harnesses make slightly different decisions while performing this "plan, act, verify" pattern, this loop is the common skeleton driving all agentic tasks. So let's stop talking about harnesses like they're magic! While good harness engineering helps, the real power is still in the models themselves. Everything else is just REST all the way down. (5/5)

When you send a message, the harness will route your request to the appropriate LLM server, then apply some chat templates to convert the HTTP request to something the model can better understand. The harness will also add more advanced parameters to control cache, max output tokens, and other things depending on the type of request. Given the context described above, the model will decide what tools, if any, to use. If the model chooses a tool, it will literally generate the appropriate tool use JSON and return it in the response body! This tool use is then parsed in the harness on the host machine and executed, and its output is automatically sent back to the LLM for processing. (4/5)

So a "harness" is really a context orchestration tool. Every request body it builds typically has the same three parts: 🟠 System Prompt: the "you are Claude Code" setup, plus injected stuff like your file tree or recent commits 🟠 Tool Definitions: a list of JSON schemas describing available tools the model has to "act", I.e., Bash, FileRead, etc. 🟠 Messages: the chronological list of user/assistant messages, as well as thinking blocks. Since the model is stateless, the harness reassembles and resends all of these parts every turn. What differs between Claude Code, Codex, and OpenCode is not only the TUI/UX features, but how this context is managed. For instance, people like Pi because you have more control over how the harness is managed and therefore how the context is. (3/5)

It is first helpful to understand how the underlying models work. Opus, GPT 5.5, etc (the models) are all stateless -- they remember nothing between requests. That is, each time you press "enter" at the prompt factory, the harness rebuilds the entire conversation and ships it (this is why prompt caching is so important!). There is no memory sitting on the server. Whatever the model "knows" about your session exists only because the harness packed it into that one request. (2/5)

Everyone's always talking about agentic coding harnesses: Claude Code, Codex, OpenCode, Pi... the list goes on. But what's the difference between all of them? What even Is a harness anyway? In this thread, we'll take a look under the hood. (1/5)🧵

Memory as a share of Hyperscaler CapEx has drawn a lot of chatter, especially after MU earnings last week. Some market participants are shocked at how high it could be next year. We published our initial view in late February, and many clients pushed back on our 30% number: "Memory is in the teens as a share of a server BOM. How could overall CapEx be that high?" In May, after pricing rose even faster than expected, we responded directly: combine DRAM, NAND, and HBM, and memory spend in an Nvidia system clears 30% by YE26 and moves above 40% in CY27. We expect this dynamic to be better understood in the coming months.

The Bottom Line: SPHBM4 shifts the complex engineering burden of AI chips. Instead of buying a hyper-expensive, proprietary "Silicon Interposer ABF Substrate" combo, chipmakers will shift entirely to buying ultra-large, high-layer ABF or even pull forward the adoption of glass substrates as performance requirements are pushed directly onto the substrate layer. The substrate boom is just getting started. (6/6)

🟠 It "democratizes" HBM. Right now, HBM is locked behind a massive bottleneck: only a few specialized foundries have the advanced packaging tech (like TSMC CoWoS) to build them. This keeps HBM restricted to ultra-premium AI accelerators. SPHBM4 changes the game. By allowing standard packaging houses to wire HBM, mid-tier AI chips, networking silicon, and even consumer gaming GPUs can adopt it. HBM demand will continue to grow faster than suppliers can even increase capacity. (5/6)

🟠 It shoots layer counts through the roof. Moving 32 Gbps signals directly across an organic substrate is an electrical nightmare. To prevent data corruption and electromagnetic interference, you can't just use a basic low layer count ABF substrate. SPHBM4 will force the use of premium, high-density ABF (and upcoming glass) substrates packed with 20 to 28 layers just to handle the complex routing, power and ground shielding. High-layer-count substrates consume more material, yield fewer units per manufacturing run, drastically increasing overall substrate factory demand and drive up pricing. (4/6)

🟠 It blows up the physical size of the substrate. Traditional HBM must sit microscopic millimeters away from the GPU because wide parallel signals degrade instantly over distance. Because SPHBM4 uses high-speed serial lanes, memory can sit up to 20mm away. This extra breathing room means there is room for more HBM per package, as chip packaging footprints get much larger, dramatically driving up the total square footage of substrate material needed per chip. (3/6)

The idea is simple: maintain HBM4 performance while drastically reducing the reliance on expensive, supply-constrained advanced packaging. How? By slashing the pin count to 1/5th but quadrupling signal speeds to 32 Gbps. This allows HBM-level bandwidth using standard substrates, while pushing the connection distance out to 20mm for vastly superior thermal management. Here is why SPHBM4 is a massive win for the substrate industry: (2/6)

This last week JEDEC announced a new standard for SPHBM4: Standard Package High Bandwidth Memory (JESD330-4). It utilizes the same DRAM stacks as HBM4, but swaps in a different buffer die. The goal? Enable HBM assembly in standard packaging and break the AI Advanced Packaging bottleneck. (1/6)🧵

Meta Compute: Everyone Wants To Be A Cloud Zuck Takes Plan B? SpaceX 2.0, Bedrock 2.0, MSL Isn't Giving Up, Scaling RecSys by 10x... ClusterMAX ranking coming soon? newsletter.semianalysis.com/…