Live data from Hacker News

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

github.com

131–140 of 179 posts

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#131
post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

[flagged]

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#132
post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

[flagged]

Warning: another fake troll account just created for this comment. The same one left a comment last night on a new account under Simon's comment as well but was flagged.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#133
post #5

I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…

> But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. This is true in a sense, but every little papercut at the lower levels of abstraction degrades performance at higher levels as the LLM needs to spend its efforts on hacking around jank in the Python interpreter instead of solving the real problem.

It is a workaround, so we can assume that this will be temporary and in the future the ai will then start using them once it can. Probably just like we would do.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#134
post #34

Earlier quoted context omitted.

They plan to use to for "Code Mode" which mean the LLM will use this to run Python code that it writes to run tools instead of having to load the tools up front into the LLM context window.

(Pydantic AI lead here) We’re implementing Code Mode in https://github.com/pydantic/pydantic-ai/pull/4153 with support for Monty and abstractions to use other runtimes / sandboxes. The idea is that in “traditional” LLM tool calling, the entire (MCP) tool result is sent back to the LLM, even if it just needs a few fields, or is going to pass the return value into another tool without needing to see the intermediate va…

I like your effort. Time savings and strict security are real and important. In modern orchestration flows, however, a subagent handles the extra processing of tool results, so the context of the main agent is not poluted.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#137
post #60

Earlier quoted context omitted.

[flagged]

Every AI advancement liberates real humans from drudgery and allows them to create what they want more easily. The invention of the digital calculator turned human calculators into accountants, and that's great! We're contributing to the same process now

[flagged]

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#138
post #82
post #73

Earlier quoted context omitted.

How do you feel about software engineers who build open source libraries? Open source has been responsible for enormous productivity boosts in our industry, because we don't all have to build duplicates of exactly the same thing time and time again. But think of all of the jobs that were lost by people who would otherwise been employed building the 500th version of a CSS design system, or a template engine, or code t…

Previously, open source software didn't contribute to automating away jobs, at least not at scale. Open Source libraries weren't potentially maintaining themselves (I know we aren't there yet, but that seems to be the goal). You cannot compare any open source software, even as a whole, to the impact that LLMs have had on labor and are projected too. However, I might now argue it would have been better to not have so…

This is a solid answer to my question, thanks.

I'm an optimist on this and I remain hopeful that AI will create more and better jobs, but I'm not at all certain about that. It's possible it will play out the way you describe, and that will suck.

I'm not ready to blame the 100,000s of software layoffs on AI though - I think the more likely explanation for those is over-hiring during Covid combined with the end of ZIRP.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#139
Totally reasonable project for many reasons but fast tools for AI always makes me chuckle. Imagine your job is delivering packages and along the delivery route one of your coworkers is a literal glacier. It doesn't really matter how fast you walk, run, bike, or drive. If part of your delivery chain tops out at 30 meters per day you're going to have a slow delivery service. The ratio between the speed of code execution and AI "thinking" is worse than this analogy.

Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI

#140
Interesting trade-off: build a minimal interpreter that's "good enough" for AI-generated code rather than trying to match CPython feature-for-feature.

The security angle is probably the most compelling part. Running arbitrary AI-generated Python in a full CPython runtime is asking for trouble — the attack surface is enormous. Stripping it down to a minimal subset at least constrains what the generated code can do.

The bet here seems to be that AI-generated code can be nudged to use a restricted subset through error feedback loops, which honestly seems reasonable for most tool-use scenarios. You don't need metaclasses and dynamic imports to parse JSON or make API calls.

Post reply on HN