Monty: Ultra-Fast Secure Rust Python Interpreter for LLM Agents

Monty is a compact Python interpreter in Rust that runs LLM-generated code with microsecond startup, strict isolation, and snapshottable execution state. It offers controlled host functions, resource limits, and embeddable APIs for Python, Rust, and JavaScript.

Monty: Ultra-Fast Secure Rust Python Interpreter for LLM Agents

TL;DR

  • Microsecond-class startup: reported ~0.06 ms latency for running agent-written snippets
  • Restricted runtime: blocks filesystem, environment variables, and network; only host-registered functions callable
  • Snapshotting: parsed programs and mid-execution states serializable via dump()/load(), enabling pause/resume and process migration
  • Resource controls: tracking of memory, allocations, stack depth, and execution time with cancel-on-limit behavior
  • Embeddable across Python, Rust, and JS/TS with no CPython dependency; supports async/sync bridging and host async callbacks
  • Limitations and status: limited stdlib, no third-party packages, classes and match not yet supported; release v0.0.3 on Feb 4, 2026

Monty is a compact Python interpreter implemented in Rust, purpose-built to safely execute code generated by LLMs with extremely low startup overhead. The project targets a narrow but practical use case: enable agents to write and run Python snippets without the complexity and risk of container sandboxes, offering microsecond-class startup times, controlled resource limits, and snapshotable execution state.

What Monty is and what it’s for

Monty is designed specifically to run code produced by agents. It exposes a restricted Python runtime that:

  • Blocks direct access to the host environment: filesystem, environment variables, and network access are disallowed unless explicitly provided as host functions.
  • Allows controlled host function calls: only functions registered by the embedding application are callable from Monty code.
  • Supports modern Python type hints and includes ty for typechecking bundled into a single binary.
  • Snapshots execution so the interpreter state can be serialized to bytes and restored later, enabling pausing, resuming, and moving execution across processes.

The runtime aims for a small, secure surface suitable for tool-use by agents rather than general-purpose Python programming.

Key features

  • Extremely low startup latency (reported on the repo as around 0.06ms) so agent-written code can run with minimal overhead.
  • Snapshotting: both parsed programs and mid-execution states can be serialized with dump()/load(), enabling caching and long-lived workflows.
  • Resource controls: tracking of memory, allocations, stack depth, and execution time with the ability to cancel execution when limits are hit.
  • Embeddable across ecosystems: callable from Python, Rust, and JavaScript/TypeScript since Monty has no CPython dependency.
  • Async and sync bridging: supports async or sync execution and can call back to host async functions.

Practical usage patterns

Monty is consumable from multiple languages. The repository documents:

  • Python integration via the pydantic-monty package with examples for running async agents, iterative external-function workflows using start()/resume(), and serialization of Monty and MontySnapshot objects.
  • A Rust API (MontyRun, MontyObject, RunProgress) including dump()/load() serialization.
  • JavaScript/TypeScript bindings are available to embed Monty where a Rust runtime can be used.

Typical workflows include agent-written logic that calls external tool functions iteratively; Monty pauses at those calls and returns a snapshot describing the call so the host can perform the external operation and then resume execution.

Limitations and design trade-offs

Monty intentionally restricts language features and libraries to reduce attack surface and complexity:

  • Limited stdlib: only a few modules are available (e.g., sys, typing, asyncio; dataclasses and json noted as coming soon).
  • No third-party package support: external Python libraries are not supported by design.
  • Language gaps: currently lacks classes and match statement support (the repo indicates class support is expected in future updates).

These constraints reflect a focus on safe, fast execution for agent use rather than parity with CPython.

Alternatives and positioning

The repository compares Monty to other approaches:

  • Docker and managed sandboxing services provide full language completeness and isolation but incur significant startup latency and operational complexity.
  • Pyodide brings full CPython in WASM but incurs large cold-start costs and different isolation trade-offs for server-side use.
  • Lightweight interpreters like starlark-rust are fast and hermetic but are not Python and lack features needed for agent tool invocation.
  • Naive approaches (exec()/subprocess) offer minimal latency but no security boundaries.

Monty sits between these options by trading language completeness for strict isolation, rapid startup, and snapshot capabilities tailored for agent-driven code execution.

Integration and status

Monty is slated to power code-mode in Pydantic AI, where agents produce code that directly invokes registered tools. The repo emphasizes practical references on agent-oriented code execution such as Cloudflare’s Codemode, Anthropic’s programmatic tool-calling docs, and Hugging Face’s Smol Agents.

The project is experimental and actively developed; the repository lists release v0.0.3 (latest) on Feb 4, 2026. Source, examples, and CI badges are available in the repo.

Further details and examples live in the repository documentation and example folders. For the original project and full documentation, see https://github.com/pydantic/monty.

Continue the conversation on Slack

Did this article spark your interest? Join our community of experts and enthusiasts to dive deeper, ask questions, and share your ideas.

Join our community