True, but while CPython does have a reputation for slow startup, completely re-implementing isn't the only way to work around it - e.g. with eryx [1] I've managed to pre-initialize and snapshots the Wasm and pre-compile it, to get real CPython starting in ~15ms, without compromising on language features. It's doable!
I posted this elsewhere in the thread, and don't want to spam it everywhere (or take away from Amla!), but you might be interested in eryx [1] - the Python bindings [2] get you a similar Python-in-Python sandbox based on a WASI build of CPython (props to the componentize-py [3] people)!
% uv run --with pyeryx python
Installed 1 package in 1ms
Python 3.14.0 (main, Oct 7 2025, 16:07:00) [Clang 20.1.4 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import eryx
>>> sandbox = eryx.Sandbox()
>>> result = sandbox.execute('''
... print("Hello from the sandbox!")
... x = 2 + 2
... print(f"2 + 2 = {x}")
... ''')
>>> result
ExecuteResult(stdout="Hello from the sandbox!\n2 + 2 = 4", duration_ms=6.83, callback_invocations=0, peak_memory_bytes=Some(16384000))
>>> sandbox.execute('''
... import sqlite3
... print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall())
... ''').stdout
Traceback (most recent call last):
File "<python-input-6>", line 1, in <module>
sandbox.execute('''
~~~~~~~~~~~~~~~^^^^
import sqlite3
^^^^^^^^^^^^^^
print(sqlite3.connect(":memory:").execute("select sqlite_version()").fetchall())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
''').stdout
^^^^
eryx.ExecutionError: Traceback (most recent call last):
File "<string>", line 1, in <module>
File "<string>", line 125, in _eryx_exec
File "<user>", line 2, in <module>
File "/python-stdlib/sqlite3/__init__.py", line 57, in <module>
from sqlite3.dbapi2 import *
File "/python-stdlib/sqlite3/dbapi2.py", line 27, in <module>
from _sqlite3 import *
ModuleNotFoundError: No module named '_sqlite3'
It looks like there's not mechanism yet in the Python bindings for exposing callback functions to the sandboxed code - it exists in the Rust library and Python has a ExecuteRusult.callback_invocations counter so presumably this is coming soon?
I'm not super familiar with how pyodide works but I think it uses CPython compiled with Emscripten then needs to be run from a Javascript environment, and uses the browser's (or Node's) Wasm engine.
This uses CPython compiled to WASI and can (in theory) be run from any WASI-compatible Wasm runtime, in this case wasmtime, which has bindings in lots of languages. WASI uses capability based security rather than browser sandboxing and lets the host intercept any syscalls which is pretty cool. Wasmtime also lets you do things like epoch-based interruption, 'gas' for limiting instruction count, memory limits, and a bunch of other things that give you tons of control over the sandbox.
Pyodide/Emscripten might offer something similar but I'm not sure!
Cool to see more projects in this space! I think Wasm is a great way to do secure sandboxing here. How does Amla handle commands like grep/jq/curl etc which make AI agents so effective at bash but require recompilation to WASI (which is kinda impractical for so many projects)?
I've been working on a couple of things which take a very similar approach, with what seem to be some different tradeoffs:
- eryx [1], which uses a WASI build of CPython to provide a true Python sandbox (similar to componentize-py but supports some form of 'dynamic linking' with either pure Python packages or WASI-compiled native wheels)
- conch [2], which embeds the `brush` Rust reimplementation of Bash to provide a similar bash sandbox. This is where I've been struggling with figuring out the best way to do subcommands, right now they just have to be rewritten and compiled in but I'd like to find a way to dynamically link them in similar to the Python package approach...
One other note, WASI's VFS support has been great, I just wish there was more progress on `wasi-tls`, it's tricky to get network access working otherwise...
Great question. We cheated a bit; we didn't compile the GNU coreutils to wasm. Instead, we have Rust reimplementations of common shell commands. It allows us to focus on the use cases agents actually care about instead of reimplementing all of the corner cases exactly.
curl is interesting. We don't include it currently but we could do it without too much additional effort.
Networking isn't done within the wasm sandbox; we "yield" back to the the caller using what we call "host operations" in order to perform any IO. This keeps the Wasm sandbox minimal and as close to "pure compute" as possible. In fact, the only capabilities we give the WASI runtime is a method to get the current time and to generate random numbers. Since we intercept all external IO, random number generation, time, and the Wasm runtime is just for pure computation, we also get perfect reproducibility. We can replay anything within the sandbox exactly.
Your approach with brush is interesting. Having actual bash semantics rather than "bash-like" is a real advantage for complex scripts. The dynamic linking problem for subcommands is a tough one; have you looked at WASI components for this? Feels like that's where it'll eventually land but the tooling isn't there yet.
Will check out eryx and conch. Thanks for sharing!
Hah, that is exactly the same approach I landed on. Fortunately the most common tools either seem to have Rust ports or are fairly easy to port 80% of the functionality! Conch's Wasm file is around ~3.5MB and only has a few tools though so I can see it growing. I think for the places where size really matters (e.g. the web) it should be possible to split it using the component model and `jco` (which I think splits Wasm components into modules along interface boundaries, and could defer loading of unused modules) but I haven't got that far yet.
I did something very similar to you for networking in eryx too (no networking in conch yet); defined an `eryx:net` interface in WIT and reimplemented the `urllib` module using host networking, which most downstream packages (httpx, requests, etc) use far enough down the stack. It's a tradeoff but I think it's pretty much good enough for most use cases like this, and gives the host full control which is great.
Oh full transparency, the vast majority of conch and eryx were written by Opus 4.5. Being backed by wasmtime and the rather strict Rust compiler is definitely a boon here!
The opus 4.5 confession is great haha. We have found Claude Code + Opus 4.5 + Rust with miri/cargo-deny/cargo-check/cargo-fmt + Python with strict type checking/pedantic lint rules/comprehensive test suites to be a winning combination. It makes AI-assisted development surprisingly viable for systems work.
Good to see that you chose a similar path for networking in eryx!
Yes, in fact this is exactly what it was written for! If you're writing a Grafana app plugin (using Grafana Scenes, a library to help write dashboard-like experiences in Grafana apps) you can use Scenes ML to add outlier detection, forecasting or changepoint detection pretty easily: https://grafana.com/developers/scenes/scenes-ml/outlier-dete....
Most of the algorithms in augurs were chosen to solve problems we've had at Grafana, which tend to require a solution that doesn't require tweaking too many parameters and deals with higher frequency series than many other time series algorithms are designed to deal with. For example, the DBSCAN clustering algorithm works without having to choose the number of clusters, and MSTL/Prophet work with multiple seasonalities and sub-daily data.
The other criteria is that they needed to be fast and cheap, which ruled out many of the deep learning/neural net based models, although I'd still like to try some foundation models using Burn or some other Rust deep learning framework!
I started writing this library a while ago after I couldn't find a time series library that really fit my needs (either in Rust or elsewhere, really). Specifically I wanted something that was:
- fast
- portable (I want to be able to run it in the browser, in Python, and in Rust)
- maintainable (please don't write libraries in Jupyter notebooks...)
Augurs meets all three of those for me, and was a lot of fun to write. Plus it has a fun name and I managed to nab the augu.rs domain.
A few things I think are cool:
- the MSTL/ETS implementation is very snappy and can produce forecasts in well under 100ms for quite large time series. This was the initial motivation for writing the library.
- the Prophet implementation includes the option to use a WASM component which wraps the Stan Bayesian framework compiled to WebAssembly, run inside Wasmtime, making it an easy-to-deploy single binary. Interestingly the benchmarks show the Wasmtime version running almost as fast as the native version.
- the whole library can be run in the browser using the npm library - see the demo below for an example
[1] https://github.com/eryx-org/eryx