pydantic/monty

The problem

Agent frameworks increasingly want the model to call tools by writing code rather than emitting JSON tool calls. Once you accept that, you have to run that code somewhere, and the code is untrusted. The default answer is a container per execution, which gives you reasonable isolation along with a cold start measured in hundreds of milliseconds, an orchestration layer to maintain, and a bill that scales with how often your agent reasons. Monty attacks the latency and the infrastructure at the same time: it is a Python interpreter written in Rust that executes a subset of the language inside an environment with no filesystem, no environment variables, and no network, and it can be handed work in under a millisecond from a warm pool.

What's different

Most sandbox projects isolate a real process or a real VM, and they pay for the isolation in startup time and memory. Monty moves the isolation boundary into the interpreter itself, so there is no process to boot and no kernel to schedule. The host exposes capabilities explicitly: functions and mounts are passed in, and the sandbox sees only their return values, as the README's external_lookup example shows. Two consequences follow. First, it is not a general Python runtime: the README points to a documented subset and a limitations page, so anything from the full standard library or C extensions is out. Second, startup latency is advertised at under 1ms from a pool, which is one to two orders of magnitude below the ~1500ms figure the project cites for sandbox services, and that changes what an agent can afford to do per turn. Compared with Pyodide or WASI-style isolation, Monty trades Python completeness for a thinner boundary and a much smaller deployment footprint. Snapshots and resource limits round out the control surface.

Who it's for

This is for teams building agents that execute model-written Python as part of their loop: Pydantic AI users first (Monty is the engine behind Code Mode there), but also anyone who wants sub-millisecond execution without standing up a container service. It fits data-analysis agents, calculation and transformation steps, and any place where the code needs a few host-provided functions rather than the whole ecosystem. It is a poor fit if the generated code needs numpy, pandas, requests, or any compiled dependency, if you need full CPython semantics, or if your threat model requires OS-level isolation rather than an interpreter-level one. Teams already happy with Docker-in-production and tolerant of per-execution latency should look elsewhere.

Cost of adoption

The package is MIT licensed and ships for Python, JavaScript/TypeScript, and Rust, so language coverage is not a blocker. The real cost is the Python subset: you will read the limitations page before committing, and you will likely restructure prompts or generated code so it sticks to what is supported. The commercial Full Monty server is a separate paid product; the OSS package is usable on its own, but the multi-tenant service story is a commercial concern. The project is more than three years old but the public-facing sandbox work is recent, so expect API movement.

Verdict

Monty is not a spike project: it has existed since 2023 and sits underneath Pydantic AI, which is a meaningful production dependency signal, and the 323-point Hacker News thread shows genuine practitioner interest. The +533 stars this month on the Rust board, against a base of roughly 8.8k, reads as steady growth rather than a viral jump. The trade-off is clear and honest: you give up Python completeness for isolation that is cheaper and dramatically faster than a container. If your agents write small, host-mediated Python, it is the most interesting option in this space; if they need the real ecosystem, keep your containers for now.