ONNX Runtime 1.29 Moves Browser AI Towards Native WebGPU
ONNX Runtime 1.29, released on 12 August 2026, expands native WebGPU support, adds more Arm64 CPU kernels, and announces the deprecation of its older WebGL and JSEP browser paths. The release broadens local inference options but does not promise a universal speed gain. Developers also need to review build-dependent POSIX telemetry behaviour in native builds.
On this page
ONNX Runtime 1.29 changes browser inference
Microsoft released ONNX Runtime 1.29 on 12 August 2026. The open-source inference engine is used to execute ONNX models across browsers, phones, computers, and servers, with different execution providers mapping a model onto available hardware.
The main browser decision is a deprecation notice. ONNX Runtime Web is beginning to retire WebGL and JSEP, the JavaScript execution-provider bridge used by older WebGPU and WebNN paths. Microsoft now recommends the native WebGPU execution provider.
Deprecation is not the same as immediate removal. Version 1.29 announces the direction and adds migration documentation, so an existing application does not become a native WebGPU application merely by changing its package version. Developers need to check their session configuration, supported operators, browser requirements, model outputs, and fallback path before switching.
WebGPU covers more language and vision operations
The native WebGPU provider adds an initial PagedAttention implementation, MRotaryEmbedding for Qwen-style multimodal rotary position encoding, and MatMulBnb4 for 4-bit weights. It also adds operations including GRU, DFT, HardSwish, PReLU, and Trilu, while expanding integer support across common tensor operations.
Those additions can reduce the number of models or graph sections that fall back to another execution path. Paged attention is particularly relevant to generative models because it manages the key-value cache in blocks instead of requiring one continuously growing allocation. The release notes call this an initial implementation, so it should be treated as new coverage rather than a guarantee of lower memory use or faster generation in every browser.
ONNX Runtime 1.29 also changes start-up work. Deferred dispatch and staging-buffer improvements are intended to reduce cold-start and upload overhead, and Intel subgroup matrix kernels gained targeted tuning. Microsoft did not publish one cross-browser benchmark for the full release. Results will still depend on the model graph, browser, GPU driver, shader support, precision, and how much work remains on the CPU. Browser AI still needs a complete offline stack, not only a WebGPU feature check.
Arm64 improves, while native telemetry needs review
The CPU runtime adds Arm64 half-precision matrix multiplication and convolution through KleidiAI, along with asymmetric 4-bit and SME2 MatMulNBits kernels. It also adds an Arm64 NEON kernel for rotary embeddings and enables CPU FlashAttention on supported Linux Arm64 systems.
These are useful building blocks for local AI, but support in the runtime does not prove that a particular Android app will use them. The application must ship a compatible build, the exported graph must match supported operations, and the device must expose the required instruction set. Memory pressure, model loading, prompt processing, and heat can still dominate perceived speed. Time before the first token and generation rate should be measured separately.
The release also introduces POSIX telemetry for Linux, macOS, Android, and iOS when ONNX Runtime is compiled with telemetry enabled. Microsoft says this does not alter the public ABI, WebAssembly builds remain telemetry-free, and setting ORT_DISABLE_TELEMETRY=1 before initialisation disables non-Windows telemetry for the process. Local-app developers should verify their exact build flags and disclosure rather than assuming that every native package has identical network behaviour.
Migration should be tested as a product change
The release includes security fixes for external-data path traversal, tensor bounds, malformed shapes, and several CPU and GPU operators. That makes 1.29 worth evaluating even for applications that do not use its new generative-AI kernels, especially when models or external tensor files can come from outside the application.
A safe browser migration starts with the exact production model. Record whether it loads through native WebGPU, which operators fall back, peak memory, cold-start time, first visible output, sustained generation, cancellation, and behaviour after the device warms up. Test WebAssembly fallback separately if the product promises broader compatibility or offline recovery.
Applications should not remove an older path until their supported browser matrix has been checked. Native WebGPU is the stated destination, but WebGPU availability alone does not establish operator coverage, acceptable quality after quantisation, or stable execution on a target phone. The exact artifact and runtime combination still need device testing.