Bytecode Alliance — The Road to Component Model 1.0

WASI P3 is almost here, bringing native async support to the WebAssembly System Interface (WASI) and Component Model . In this post, we’re looking to the next big milestone: a stable, formally specified Component Model 1.0.

At February’s Bytecode Alliance Plumbers Summit, Luke Wagner and Alex Crichton gave a preview of what the path to a stable 1.0 actually looks like. At Wasm I/O 2026 in Barcelona in March, Luke expanded on that vision. So let’s take a look at where the Component Model is heading.

A quick refresher on the Component Model and WASI

Before we dive into the future of the Component Model, we should take a moment to review what the specification does, as well as its relationship to WASI.

The Component Model is the specification layered atop core WebAssembly that defines how Wasm binaries bundle, link, and communicate: it specifies the type system, the binary format, the interface definition language, and the calling conventions for passing typed values across component isolation boundaries.

The WebAssembly System Interface (WASI) , in turn, is a standardized set of APIs for accessing system resources like files, sockets, clocks, randomness, and more in a portable, capability-secure way.

WASI interfaces are consumed through the Component Model; together they form the composable, portable foundation of the Wasm ecosystem. (It’s worth noting that Component Model 1.0 and WASI 1.0 are related but distinct milestones: WASI 1.0 will follow from and depend on the Component Model reaching 1.0 first.)

At the Plumbers Summit, Luke described the relationship between the Component Model and WASI as analogous to a microkernel architecture: the Component Model is the always-present microkernel, providing foundational primitives that run across any host. WASI layers on top like OS services (e.g., networking, storage, graphics) that run as processes on top of the microkernel and may or may not be present on a given device. A browser, for instance, has very strong opinions about what I/O APIs exist; WASI interfaces run there via polyfill. But the Component Model itself can be implemented natively in the browser alongside core WebAssembly, since it only provides computational primitives, not I/O.

In practical terms, both WASI and the Component Model are already heavily used in production. Despite ongoing evolution of both the binary format and WASI APIs, platform providers and embedders can give strong backwards-compatibility guarantees. P1 modules still work. P2 components still work. The team has been maintaining this stability since P1 using semantic versioning, side-by-side implementations, and Wasm-to-Wasm adapters. That story continues past 1.0. As Luke put it: “We can start using this stuff now.” But getting to Component Model 1.0 involves critical work across several important areas.

Five areas of work

Luke frames the path to 1.0 around five areas of work:

1. ABI improvements

The Component Model’s current Application Binary Interface (ABI), the calling convention that governs how components pass data to each other, relies on a function conventionally called cabi_realloc, which all components are required to export. When a callee returns a value like a list of strings, the host calls the calling component’s cabi_realloc to allocate memory for each element, then copies everything before returning to the caller. This works, but experience has surfaced real friction: heap fragmentation over time, difficulty handling large allocation failures gracefully, one host-to-guest call per value in a list, and trouble using custom memory allocators.

One planned change inverts the control flow. Instead of the host eagerly allocating, the callee returns lazy value handles: opaque i32 indices. When the caller is ready to place a value into memory, it calls a static built-in function with the destination address. Because these built-ins are statically known to the compiler, they can be inlined as if they were instructions.

This lazy ABI resolves the existing friction, and adds a few bonuses: lazy values can be zero-copy forwarded between calls, dropped if unused, and the approach cleans up some complex string transcoding logic that currently lives in the engine by moving it into guest code.

The transition is designed to be non-breaking: the lazy ABI ships as a new opt-in option in a 0.3.x minor release, and producer toolchains adopt it when ready. When 1.0 arrives and adoption is complete, the lazy ABI becomes the default and the option goes away. An adapter tool will handle converting eager components to lazy.

Bundled into the same transition are multivalue returns (using Wasm multivalue for return types at the C ABI level) and an error context value in every result’s error case, so there’s always a standard way for hosts to attach backtraces and debug information.

There is one significant dependency: LLVM doesn’t yet support multivalue at the C ABI...