Skip to content
Docs Pydantic Docs

Monty

A minimal, secure Python interpreter written in Rust for use by AI.

Monty runs Python written by an LLM without the cost, latency and complexity of a container sandbox. It does not embed CPython: it parses Python with Ruff’s parser and executes it on its own bytecode VM, with no FFI and no C dependencies. That is what makes it small enough to install from PyPI or npm, fast enough to start per request, and portable enough to run anywhere Rust runs, including WebAssembly.

The sandbox has no ambient access to the machine it runs on. Filesystem, environment variables and network are reachable only through host functions and mounts that you hand it explicitly.

Why this exists

LLMs are often faster, cheaper and more reliable when they write a short program that calls your tools, instead of making a sequence of individual tool calls. That idea goes by several names:

All of them need somewhere safe to run the generated code. Monty is that place, without a container or a sandboxing service in the loop.

What Monty can do

  • Run a useful subset of Python — functions, closures, decorators, classes, dataclasses, comprehensions, try/except, f-strings, async/await, and 13 stdlib modules. See the Python subset.
  • Block host access by default — an unmounted sandbox cannot read a file, read an environment variable, open a socket or spawn a process. See the security model.
  • Call functions you provide — the sandbox suspends, your code runs the real function on the host, execution resumes with the result. Sync or async. See host functions.
  • Type check before running — Monty bundles ty and a trimmed typeshed of Monty’s runtime surface, so unsupported APIs generally fail up front rather than halfway through. See type checking.
  • Snapshot and resume — a paused interpreter serializes to bytes you can store in a file or a database and resume later, in another process or on another machine. See snapshots.
  • Bound resource use — limits on heap memory, cumulative execution time, recursion depth and GC interval. See resource limits.
  • Contain crashes — the Python package and the native @pydantic/monty binding run every session in a worker subprocess, so even a stack-overflow abort triggered by adversarial code kills only the worker. The WebAssembly build has no subprocess to use; see the security model.
  • Be called from Rust, Python or JavaScript — and in the browser, via a WebAssembly build.

What Monty cannot do

  • Most of the standard library. Only asyncio, collections, dataclasses, datetime, itertools, json, math, os, pathlib, re, sys, typing and unicodedata are importable, and each covers only part of its CPython surface.
  • Third-party packages. There is no sys.path and no site-packages inside the sandbox; supporting PyPI packages is not a goal.
  • Class inheritance. class Foo(Bar): is rejected at parse time, and so are method decorators like @classmethod, @staticmethod and @property; super() raises NameError. Simple classes without a base class do work.
  • Generators, match statements, del, async with, async for, exception groups, PEP 695 type aliases, complex numbers and t-strings. All are rejected at parse time.
  • User-defined exception classes. The built-in exception types are a fixed set.

The exhaustive, per-feature list of how Monty diverges from CPython lives in limitations/ in the repository. The Python subset explains how to read it.

When to reach for Monty

Monty is a good fit when the code is written by a model, is short-lived, and mostly glues together tools you already own: fetch these three things, join them, filter, do some arithmetic, return the answer.

It is a poor fit for anything that needs the real Python ecosystem — notebooks, data science, user-supplied scripts that import pandas. For those, a container or a sandboxing service is still the right tool. The comparison table in the README walks through the alternatives and where each one wins.

Next steps

Monty will be used to implement code mode in Pydantic AI.

Part of the Pydantic Stack