Monty: a Rust sandbox for AI-written Python

Many AI apps have a model write a short Python program and then run it. Starting a container for every call is slow, and calling exec() inside your own process gives the generated code your process’s permissions. Monty is an open-source Python sandbox that Pydantic wrote in Rust for code written by models. On November 10, 2026, its GitHub repository showed 8,875 stars; the latest release, v1.5.0, came out on November 5.

Core features

• No ambient access: the sandbox has no filesystem, environment variables or network. The docs say that with no mounts and no host functions configured, it cannot read a file or an environment variable, open a socket or spawn a process, because the interpreter has no operation for any of these.
• Explicit host functions: external_lookup hands named functions to the sandbox. When code calls one, execution pauses, the function runs on the host, and the result returns to the sandbox. The docs warn that these functions run with the host process’s full authority, so validate their arguments the way you would any untrusted input.
• Sessions keep state: within one checkout, variables survive across feed_run calls, so earlier commands are not replayed. A new checkout cannot see the previous session’s variables; in our test, it raised NameError.
• Snapshots: sandbox state can be dumped to bytes at an external call or at the end, then restored later. Monty does not authenticate snapshots, so confirm where restored bytes came from before you load them.
• Commercial Support: the same workers run behind a gRPC server or a container image, with OS-level isolation and horizontal scaling added. The docs list it as a not-free option; OSS Monty is MIT-licensed.

Typical use cases

• Developers adding a code-execution tool to an agent: the model writes a short program for a calculation or a data reshape, and the host supplies only the functions it needs. The README’s example works this way: the model’s code calls a host nutrition function, and the sandbox sees only the return value.
• Teams already on Pydantic AI: the README says Monty runs agent-written code inside Pydantic AI’s Code Mode.
• Services that need a fresh sandbox per request: the project’s comparison puts a local Docker container at about 195 ms and a hosted sandboxing service at about 1,500 ms (see the table below).

Quick start

The README installs the Python package with uv add pydantic-monty. We installed the same package, version 1.5.0, with pip into a new virtual environment on Python 3.15.2 (arm64) and ran the README example. It printed a chocolate bar powers a 10 W bulb for 26.7 hours, the same output the README shows.

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

In the example, nutrition runs on the host, and the sandbox sees only what it returns.

Benchmarks

The numbers come from the project’s comparison page (pydantic.dev/docs/monty/reference/alternatives/). It measures the time to get a new sandbox and run 1 + 1 in it.

Setup	New sandbox	Execution
OSS Monty, checked out of a pool	about 0.8 ms	local
Commercial Support, client pool already open	about 2 ms	remote
WASI / wasmtime	about 16 ms	local
Local Docker, running container, docker exec	about 195 ms	local
Hosted sandboxing service, existing Daytona sandbox	about 1,500 ms	remote
Pyodide, Deno sandbox	about 2,700 ms	local

Method notes from the same page: unless a section says otherwise, the chart was measured on 2026-09-03 on an Apple M3 Max (macOS 26.5.2) with CPython 3.14.7, one sample per new sandbox. The OSS Monty figure comes from a 2026-09-24 run with pydantic-monty 1.0.0b3, against a pool whose worker already existed after the pool sat idle for a second. The page also says a back-to-back checkout takes 0.04 ms. The hosted-service row used the daytona 0.207.0 SDK, with sandboxes in Daytona’s EU region, called from London.

Our own run: on an Apple M1 Mac running macOS 27.2 with pydantic-monty 1.5.0, we ran checkout plus 1 + 1 back to back 400 times on November 10, 2026, discarding the first 40. The median was 0.07 ms, in the same range as the page’s 0.04 ms back-to-back figure. That is one machine and one version, so it does not transfer to other hardware.

Summary

Monty suits developers who run model-written Python and want a light sandbox per request, and who can work within Python’s subset. It is a poor fit if you need full CPython and its libraries, if you need OS-level isolation without paying for Commercial Support, or if you want untrusted code to run inside your own process.

Read three limits before you deploy. First, OSS Monty is a language-level sandbox, not a container or a VM: the docs say there is no container, no seccomp filter and no virtual machine, so isolation comes from the interpreter itself. Second, OSS Monty runs on the same machine as the calling app; the docs point to Commercial Support for OS-level isolation. Third, it implements only part of Python: the limitations page says class inheritance is rejected at parse time. The release pace is also fast. v1.1.0 through v1.5.0 shipped between October 5 and November 5, so review each release’s changes before you upgrade.

The repository is MIT-licensed, and its primary language is Rust. The project asks security reports to go through the repository’s private advisory channel and mentions a continuing bounty program. For a VM-level alternative, see App Sandbox: it provides open-source VMs on Windows 11 Home for AI agents to drive through a headless API, a different layer from Monty’s language-level isolation.