The next evolution of Hermes Agent is here! Introducing Hermes Desktop: everything you love about Hermes, now native on your machine. First demoed in Jensen's GTC keynote, it's now in public preview.

The world’s first @nvidia Vera Rubin NVL72 server rack is here. We’re thrilled to deliver the first working, liquid-cooled @Dell PowerEdge XE9812 for @CoreWeave. Built for the next era of AI infrastructure. 🚀🤝

A little secret. About 5% of our production traffic is on the Pi harness, about another 5% is on OpenCode. Reminder you can use your ChatGPT account in a flourishing set of other tools. We’ll continue to make Codex awesome, but you have options.

320 cores of AMD Turin, 640 hyperthreads.

LoongArch uses ACPI. Server ARM systems use ACPI via SBSA. Phytium desktop ARM systems use ACPI. Huawei Kunpeng desktop ARM systems use ACPI. Server RISC-V systems can use ACPI. So if Loongson, Phytium, Huawei, etc can do this, why can’t Qualcomm, MediaTek, Samsung, and friends? And to be clear: I don’t actually care whether the abstraction is ACPI, DT, or something else entirely. I care about the end-user experience. On x86, I can take a ten-year-old Windows or Linux installer and boot it on a system released yesterday. Some things might be flaky, especially DVFS/platform-specific power management, but the machine will generally boot and work. On SDX2E, I can’t even boot a Linux distro from six months ago, let alone ten years ago. I’m not sure there’s a single normal distro installer ISO today, other than maybe Gentoo/Arch-adjacent stuff, that boots on it out of the box. As an end user, that is not acceptable. If non-x86 architectures want to be taken seriously as general-purpose client platforms, they need an end-user compatibility story at least as good as x86’s. Otherwise, why should anyone care? The point of ACPI in this context is not “ACPI good because ACPI.” The point is that new hardware should not require kernel changes just to boot. ACPI provides standard interfaces for common platform devices, and lets firmware provide the platform-specific glue needed to translate those standard interfaces into whatever weird little thing the SoC actually needs. Can that be done with DT? In theory, yes. There are even generic DT class drivers for some common device types. But in practice, it’s optional, still a moving target, and usually more effort than just adding another compatible string and another driver path. So people mostly don’t use it that way. On ACPI systems, those abstractions are the default path for common platform functionality. A PCIe controller, for example, should not need a bespoke per-board DT binding and kernel-side special casing just to exist. Maintaining upstream DTs for every device does not scale. It cannot scale. We already have too many. The constant schema churn also makes firmware-supplied DTs basically non-viable: OEMs cannot reliably target a moving upstream interface forever. We’ve tried this. It does not work. So again: I don’t care whether the answer is ACPI, better DT class abstractions, or something else. But the requirement is simple: I should be able to boot a normal OS installer on new hardware without waiting for a bespoke kernel port. x86 already delivers that. Non-x86 client platforms need to stop treating it as optional.

Launching pyptx — a Python DSL for writing NVIDIA PTX kernels. One PTX instruction = one Python call. Write pure PTX in Python. Direct Hopper Blackwell support: wgmma, TMA, tcgen05, mbarriers. JAX PyTorch integration. Includes GEMM, grouped GEMM, RMSNorm, SwiGLU, and a PTX→Python transpiler pip install pyptx[torch] pip install pyptx[jax] github.com/patrick-toulme/py…

Qwen-Image-2.0-Pro is now live 🚀🚀 We’ve pushed image quality, multilingual text rendering, and instruction following to a new level, while making performance much more consistent across styles.🌅🌃 Ranked #9 worldwide for Text-to-Image on @arena 🔗Try it now on ModelScope: modelscope.ai/studios/Qwen/Q… modelscope.cn/studios/Qwen/Q… API：modelstudio.console.alibabac…

Thanks to the entire Claude community for giving feedback and continuing to build with us. Read the full post-mortem here: anthropic.com/engineering/ap…