
monty v0.0.20
A minimal, secure Python interpreter written in Rust for use by AI
Monty
A minimal, secure Python interpreter written in Rust for use by AI.
Experimental - This project is still in development, and not ready for prime time.
A minimal, secure Python interpreter written in Rust for use by AI.
Monty avoids the cost, latency, complexity and general faff of using a full container based sandbox for running LLM generated code.
Instead, it lets you safely run Python code written by an LLM embedded in your agent, with startup times measured in single digit microseconds not hundreds of milliseconds.
What Monty can do:
- Run a reasonable subset of Python code - enough for your agent to express what it wants to do
- Completely block access to the host environment: filesystem, env variables and network access are all implemented via external function calls the developer can control
- Call functions on the host - only functions you give it access to
- Run typechecking - monty supports full modern python type hints and comes with ty included in a single binary to run typechecking
- Be snapshotted to bytes at external function calls, meaning you can store the interpreter state in a file or database, and resume later
- Startup extremely fast (<1μs to go from code to execution result), and has runtime performance that is similar to CPython (generally between 5x faster and 5x slower)
- Be called from Rust, Python, or Javascript - because Monty has no dependencies on cpython, you can use it anywhere you can run Rust
- Control resource usage - Monty can track memory usage, stack depth, and execution time and cancel execution if it exceeds preset limits
- Collect stdout and stderr and return it to the caller
- Run async or sync code on the host via async or sync code on the host
- Use a small subset of the standard library:
sys,os,typing,asyncio,re,datetime,json,dataclasses(soon)
What Monty cannot do:
- Use the rest of the standard library
- Use third party libraries (like Pydantic), support for external python library is not a goal
- define classes (support should come soon)
- use match statements (again, support should come soon)
In short, Monty is extremely limited and designed for one use case:
To run code written by agents.
For motivation on why you might want to do this, see:
- Codemode from Cloudflare
- Programmatic Tool Calling from Anthropic
- Code Execution with MCP from Anthropic
- Smol Agents from Hugging Face
In very simple terms, the idea of all the above is that LLMs can work faster, cheaper and more reliably if they're asked to write Python (or Javascript) code, instead of relying on traditional tool calling. Monty makes that possible without the complexity of a sandbox or risk of running code directly on the host.
Note: Monty will (soon) be used to implement codemode in Pydantic AI
Usage
Monty can be called from Python, JavaScript/TypeScript or Rust.
Python
To install:
uv add pydantic-monty
(Or pip install pydantic-monty for the boomers)
pydantic-monty is a metapackage pairing pydantic-monty-client (the
pydantic_monty module) with pydantic-monty-runtime (the monty worker
binary). Install pydantic-monty-client alone if the binary already comes from
somewhere else.
Usage:
from typing import Any
import pydantic_monty
code = """
async def agent(prompt: str, messages: Messages):
while True:
print(f'messages so far: {messages}')
output = await call_llm(prompt, messages)
if isinstance(output, str):
return output
messages.extend(output)
await agent(prompt, [])
"""
type_definitions = """
from typing import Any
Messages = list[dict[str, Any]]
async def call_llm(prompt: str, messages: Messages) -> str | Messages:
raise NotImplementedError()
prompt: str = ''
"""
Messages = list[dict[str, Any]]
async def call_llm(prompt: str, messages: Messages) -> str | Messages:
if len(messages) < 2:
return [{'role': 'system', 'content': 'example response'}]
else:
return f'example output, message count {len(messages)}'
async def main():
async with pydantic_monty.AsyncMonty() as pool:
async with pool.checkout(
script_name='agent.py',
type_check=True,
type_check_stubs=type_definitions,
) as session:
output = await session.feed_run(
code,
inputs={'prompt': 'testing'},
external_lookup={'call_llm': call_llm},
)
print(output)
#> example output, message count 2
if __name__ == '__main__':
import asyncio
asyncio.run(main())
Execution happens in a pool of monty worker subprocesses, so even a memory
error triggered by adversarial code (stack overflow, allocator abort) can
never crash your process — the worker dies, raises MontyCrashedError, and
is replaced. There is also a fully synchronous API:
import pydantic_monty
with pydantic_monty.Monty() as pool:
with pool.checkout() as session:
# session state persists between feed_run calls
session.feed_run('x = 21')
print(session.feed_run('x * 2'))
#> 42
JavaScript / TypeScript
To install:
npm install @pydantic/monty
The JS package is a native (napi) binding over the same Rust worker pool the
Python package uses — the binding and the monty worker binary ship via
platform-specific npm packages:
import { Monty } from '@pydantic/monty'
await using pool = await Monty.create()
await using session = await pool.checkout()
// session state persists between feedRun calls
await session.feedRun('x = 21')
console.log(await session.feedRun('x * 2')) // 42
// external functions may be async
const result = await session.feedRun('await fetch_data()', {
externalLookup: { fetch_data: async () => 'data' },
})
For browsers (or anywhere subprocesses are impossible) the same package
exposes an in-process WebAssembly build under the @pydantic/monty/wasm
subpath (no crash isolation: a sandbox crash is a host crash there).