monty-go runs LLM-generated Python inside Go via a WASM-sandboxed Monty interpreter

A Python interpreter embedded in a Go binary

monty-go, a library from fugue-labs whose GitHub page reached the Hacker News front page, wraps Pydantic's Monty Python interpreter in a pure-Go package. Monty is compiled to WebAssembly, and monty-go runs that module through wazero, a WASM runtime written entirely in Go. The practical result: a Go service can execute Python code — typically written by a language model — inside its own process, with no containers, no subprocesses and no CGO linkage. According to the project's README, the embedded interpreter adds roughly 2.9 MB to a Go binary, and a WASM instance starts in under a millisecond.

Installation is a single go get of github.com/fugue-labs/monty-go, after which a runner takes a code string plus a map of input variables and returns the evaluated result.

One model call instead of many

The README's motivation section argues that models work faster, cheaper and more reliably when they emit code rather than chaining sequential tool calls. Instead of an agent issuing three separate invocations — one search, a second search, then a comparison — the model writes a short Python snippet that calls the same capabilities as ordinary functions. A single round trip replaces three, and the orchestration logic, variables, loops and error handling live in Python instead of in the model's step-by-step reactions. The project points to Anthropic's writing on programmatic tool calling and code execution with MCP, Cloudflare's Code Mode, and Hugging Face's Smol Agents as earlier expressions of the same pattern.

Host functions pause and resume the interpreter

The core mechanism is interception. When the Python code invokes a function the host has declared, Monty halts execution, hands the call to a Go callback, and resumes once that callback returns a value. The callback can do anything Go can do — HTTP requests, database queries — while the interpreter itself never gains direct access to the network or disk. Multiple functions can be registered at once and dispatched by name inside a single callback.

The same interception covers operating-system behaviour. Filesystem operations such as Path.read_text and environment access are routed to a Go handler, and the README is explicit that nothing touches the real filesystem unless the handler permits it. print() output is captured through a similar hook rather than leaking to stdout.

Limits and cancellation for runaway code

Generated code that loops forever or allocates without bound is the obvious failure mode, and monty-go addresses it with explicit ceilings: a maximum wall-clock duration, a memory cap in bytes, a limit on total allocations, and a recursion-depth bound. Breaching any of them terminates the run cleanly with a typed *MontyError. Go's context.Context deadlines are also respected, so cancelling the context stops the WASM instance outright.

Built to power code mode in Gollem

monty-go is designed to sit underneath Gollem, fugue-labs' agent framework for Go. Existing Gollem tools can be wrapped into one code-execution tool: the model writes Python that calls them as functions, Monty pauses at each call, and the Go implementations service the pauses. The README's comparison claims N model round-trips collapse into a single one, with the trade-off that the model writes the control flow once up front instead of reasoning through each intermediate result. Gollem contributes typed outputs, guardrails, cost tracking and multi-provider support around the sandbox.

Why it matters

Safely running model-written code has usually meant containers, network-isolated sandbox services or a separate execution microservice — heavyweight machinery for teams that just want an agent to glue a few tools together. monty-go bets that a WASM sandbox embedded in the application binary is enough: skipping CGO keeps cross-compilation trivial, in-process execution removes network hops and cold starts, and the pause/resume design keeps every capability as an ordinary Go function under the host's control. The small footprint and hard resource ceilings make it plausible for agents running at scale or on constrained hosts.

The caveats are the usual ones. An interpreter behind a WASM boundary will not offer the native-extension side of the Python ecosystem, and a sandbox is one layer of defence rather than a complete isolation story for genuinely hostile code. Still, for agent builders in Go, monty-go turns "let the model write the code" from an infrastructure project into a library import.