Hi, I wanted to share a project I've been working on that folks here might find interesting. It is using wasi-http and wasi-filesystem to provide files and network access and Wasmtime embedded in a hyper-visor with componentize-py to provide python sandbox code execution.
You can read about the use case here: https://devblogs.microsoft.com/agent-framework/codeact-with-hyperlight/ and the sandboxing tool its self is https://github.com/hyperlight-dev/hyperlight-sandbox
It's still early but it was showing some promising results with end-to-end latency by ~50% and token usage by over 60% in workloads that would benifit from it. Any feedback or thoughts welcome!
@Luke Wagner you seem to want to know when things use wasi and wasmtime for some reason
and @Alex Crichton and @Till Schneidereit, you all saw early versions of hyperlight with wasmtime build differently; we want to call your attention to this as an outcome of some of what you had suggested at that time.
a ton of the work was done by a series of people all in here somewhere: @Lucy Menon first and foremost for a ton of wasi/wit work as well as craploads of critical optimizations that have gotten us here....
Thank you for sharing this, @James Sturtevant and @Ralph—very cool! Any learning/insights/problems you ran into that might be of interest to the Wasmtime team or for Component Model/WASI standardization?
yeah I'm academically curious how the wasi implementation works. what aspects of wasi run in the hypervisor VM and which are deferred to the host OS, and how?
like, where is the policy for what authorities are allowed for http applied?
I'm building something similar, and something I needed out of wasmtime and forced me to wrap it, is dynamic runtime instantiation and introspection of components.
Sandboxed components are loaded and validated, and calls interceded and validated, by a runner that's itself Wasm. But it needs a non-standard API for instantiating a component from bytes, and introspecting imports and exports. I know there an issue open for that, it would be really useful.
@Justin Fagnani dynamic instantiation is on the CM roadmap as part of the Blast Zones feature. For introspection, you might be interested in this ongoing conversation about supporting self-hosted REPLs as components in the wasmtime cli
Pat Hickey said:
yeah I'm academically curious how the wasi implementation works. what aspects of wasi run in the hypervisor VM and which are deferred to the host OS, and how?
Http/s is handled outside the hardware boundary in this case, as that's the "trusted" host code and it's that which applies policy. the component interface in this case is the host invocation call and any tool/skill related callbacks to the host that the code might want to invoke. From the article describing it:
Agents that do a lot of tool calling (data wrangling, light computation, chained lookups, report generation) benefit most. A five-step plan that used to be five model turns becomes one
execute_codeturn containing a short Python script that calls the same tools viacall_tool(...). You save latency, you save tokens, and you keep the reasoning trace compact and auditable, because the full plan lives in a single code block instead of being scattered across several tool-call messages.
in this case, then, WIT is used to handle the call from the host to wasmtime-no-std and thence it's just a regular component call. The agent-framework (the trusted "host" sdk) handles the policy outside the microvm guest.
@James Sturtevant knows all the messy details.
Thanks Ralph! That's the basics. The wasmtime-no-std runs in the guest, the guest component doesn't know anything about the the fact that it is running in a hypervisor and that its being passed through to the host. We are using techiniques called HostFunction in Hyperlight which enable the guest and host to comunicated efficiently.
There weren't to many challenges. For both Componentize-js and componetize-py, the way they stub in standard WASI interfaces was different. In Python, I had to provide a full world with wasi interfaces. In Javascript I had to provide a sub set of interfaces to impelement, since it provided its own shim, this did mean it was hard to override the ones I cared about, for instance Componentize-js was stripping all Filesystem methods from the component in one of its passes.
@Justin Fagnani I assume that the vague claims you're making over on Bluesky are about the features you mentioned here. If you want to help, there are more productive ways to do it than sharing vague things that everyone can attach their worst interpretation to in public
Hi @Till Schneidereit, I was only referring to public comments by what I assume is people on the Wasmtime team, like this:
Stack switching support in Wasmtime is known to be incomplete at this time, and no one is currently staffed to work on it.
https://github.com/bytecodealliance/wasmtime/issues/12941#issuecomment-4178105302
Sorry, I didn't think that would be controversial. Funding is a problem across OSS that I relate to.
as your comment was about wasmtime and not about oss, it seemed somewhat personal -- but yes, OSS funding across the entire ecosystem does not match what its desired usage supports, that's always been the case as you point out.
the people here who are absolutely trying to get all the things done are, in fact, going to get there, but tomorrow doesn't happen for every one. Which I regret, too. I'd love to have that now.....
@Justin Fagnani I think I'm not alone in reading this as saying "Wasmtime is underfunded and I would recommend against using it, because it doesn't even do the most critical things", which you might imagine isn't exactly something that helps us. As Ralph is saying, we'd certainly love to invest in everything reasonably in scope for the project all at once, but that'd not be the reality of what we could do regardless of funding. And the actual reality is that (speaking as someone who's been responsible for a sizable chunk of the investment into Wasmtime throughout its history) I think we've done a huge amount with relatively modest investment, in part precisely by being careful about managing our priorities
Look, sorry if it sounded personal to you but I've never interacted with any of you before, so I'm not sure how it could even be personal.
I also did not come close to saying I recommend against using Wasmtime, or that it can't do the most critical things. Those are not things in my post at all. So, again, sorry if that's your interpretation, but it's quite a stretch from what I actually said.
I think stack switching in Wasmtime is important and one of your team said publicly that it wasn't staffed. That's fine, it happens. It happens to my projects. It isn't even a dig in any way. I would hope that more people out there thinking that Wasmtime needs more funding is a good thing. It's certainly better than people thinking it needs less funding.
just for the future, when you single out one project rather than include it in most oss, it's easy for people deeply invested in that work to feel slighted, like they just got tagged with a complaint -- even if you didn't mean it that way. We gladly accept your intentions that it was a general statement about oss (because we definitely agree). Heck, I'm from a megacorp that doesn't budget even more and I want them to. So I get that complaint; I make it.
We are doing all we can to reach the remainder of the stack switching work, for sure. We will gladly work with anyone who wants to help us finish that off; otherwise, we'll get there, promise.
Last updated: May 03 2026 at 21:15 UTC