Monty, a Rust Python sandbox for running code a model writes

No filesystem, no environment variables, no network

The security model is an absence list, and it is short enough to remember. Inside a Monty sandbox there is no filesystem, no environment variables and no network. What the sandboxed code can reach on the host is exactly the set of functions and mounts the caller passed in, and nothing else.

That is a different bargain from a container, which gives the process a filesystem and a network namespace and then subtracts from there. Monty starts from nothing, so there is no ambient authority to argue about. The cost lands on the calling side instead: every capability model-written code wants has to be declared by the program that launches the sandbox, which is more work up front and easier to audit afterwards.

The sub-millisecond number assumes a pool is already running

The README puts a new OSS Monty sandbox at under 1ms taken from a running pool, Full Monty at about 2ms, and a sandbox service at around 1500ms, with a comparison page linked for the measurements. Read that first figure carefully, because the pool is doing the work. Starting cold is a different cost from the one quoted.

The architecture that follows from it is a pool plus a checkout. You construct a pool once, then take a session out of it per unit of work, which is why the first-run example nests two context managers rather than calling a single function. If your workload is one script per user request and nothing else, the pool never gets warm and the headline number is not the number you will see.

uv add pydantic-monty, then checkout and feed_run

Monty ships as a package for all three of its supported languages, and the install commands are the whole first step:

uv add pydantic-monty        # Python
npm install @pydantic/monty  # JavaScript / TypeScript
cargo add monty              # Rust

The first Python run takes a code string, a dict of inputs, and a mapping of host callables. This is the example from the repository, with its own comment showing the output:

from pydantic_monty import Monty

code = """
kcal = nutrition('chocolate bar')['kcal']
hours = kcal * 4184 / (bulb_watts * 3600)
print(f'a chocolate bar powers a {bulb_watts} W bulb for {hours:.1f} hours')
"""

with Monty() as pool:
    with pool.checkout() as session:
        session.feed_run(
            code,
            inputs={'bulb_watts': 10},
            external_lookup={'nutrition': lambda food: {'kcal': 230}},
        )
        #> a chocolate bar powers a 10 W bulb for 26.7 hours

The lambda passed as `external_lookup` executed on the host. The sandbox saw only the dictionary it returned, and the code string itself never touched a socket or a file.

inputs and external_lookup are the only route to the host

The example uses two channels and they are not interchangeable. `inputs` is a plain dict of values handed to the sandbox up front. `external_lookup` maps names to callables that stay on the host and are called from inside the run, with only the return value crossing back. Read together, they are a typed boundary you write by hand instead of one the runtime infers from the code.

The practical consequence is that prompts and code have to be written together. If a model writes `open('data.csv')` or `requests.get(...)`, there is nothing inside the sandbox to resolve that name, so the generator has to be told to emit a call against a declared lookup instead. Teams migrating existing agent prompts hit this rewrite first, before any performance question, and it is worth budgeting for.

Monty implements a Python 3.14 subset, not CPython

This is the limitation to read before adopting. The README calls OSS Monty a Python 3.14 sandbox, and the documentation links to a page devoted to the Python subset. Monty is an interpreter for a subset of the language, not CPython with a policy layer on top, and the repository carries a top-level `limitations` file alongside the crates.

The example directory reflects the supported shape rather than arbitrary Python: spreadsheet, expense analysis, SQL playground, web scraper, julia.py and julia_image.py. Budget for testing the generated code against the subset, not only against your logic.

OSS Monty and Full Monty ship the same workers two ways

There are two products here and the difference is deployment, not behaviour. OSS Monty is the MIT licensed package you install yourself and run in your own process. Full Monty is the commercial server that runs the same sandbox behind a WebSocket as a service, described as running the same workers as a container image.

That split decides who carries which cost. With the MIT package you own the pool, the host functions and the latency profile, and nothing leaves your process. With the commercial server the execution sits behind a WebSocket boundary instead, at roughly the 2ms figure the README quotes. Teams with a policy against running model-written code in their own address space have only the second option, and it is not the one the licence covers.

Docker, Pyodide and WASI are the alternatives on its own comparison page

The project publishes a comparison against four alternatives: Docker, Pyodide, WASI, and sandboxing services. They fail in different directions, which is why the choice is not a ranking exercise.

Docker is the heavyweight baseline: a real filesystem, a real network namespace and a real process, at the cost the README calls latency, complexity and price. Pyodide and WASI are the WebAssembly-based options on the same comparison page. Sandbox services sit at the other end, keeping code off your host entirely and paying for it in round-trip time.

Eighteen workspace members, and cargo builds one by default

The repository is a Rust workspace of eighteen members plus a fuzz crate, with `default-members` set to `crates/monty-runtime`. A bare `cargo build` at the root therefore compiles that one crate rather than the whole workspace, so anyone expecting to build everything needs the explicit workspace command that the Makefile's `install` target runs as `cargo check --workspace`. The workspace requires Rust edition 2024 and rust-version 1.96, and the Python packages are built through maturin rather than setuptools.

Maintenance is brisk. The last push to the default branch was on 2026-11-02, 1.4.0 was published on 2026-10-26 after v1.3.0 and v1.2.0 a few days earlier, and the workspace manifest reads 1.4.0, matching the newest release. Everything is MIT licensed, which covers the OSS package and the repository but not the Full Monty server.

Editorial conclusion

Monty fits a team whose agent writes short Python that computes, transforms or queries through functions the host supplies, and who cannot afford a container per execution. It does not fit code that needs real files, sockets or arbitrary libraries, because the sandbox has none of those and the host channel is something you design by hand. Check the Python subset page against your model's typical output before adopting it, then measure the pool checkout path rather than the sandbox startup number.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pydantic/monty on GitHub
4. README
5. Releases