Monty - AI-जनरेटेड कोड को सुरक्षित रूप से चलाने वाला हल्का Python interpreter

• AI द्वारा जनरेट किए गए कोड को सुरक्षित रूप से चलाने के लिए डिज़ाइन किया गया Rust-आधारित हल्का Python interpreter, जो container sandbox की जटिलता और latency को हटाता है
• filesystem, environment variables और network access को पूरी तरह ब्लॉक करता है, और केवल वही external functions कॉल की जा सकती हैं जिन्हें developer ने निर्दिष्ट किया हो
• 1 microsecond से कम startup time और CPython जैसी execution performance देता है, तथा Rust·Python·JavaScript तीनों से कॉल किया जा सकता है
• execution state को byte-level snapshot के रूप में save और restore किया जा सकता है, जिससे processes के बीच pause और resume संभव है
• यह Pydantic AI की Code Mode सुविधा को चलाएगा, और LLM द्वारा लिखे गए Python code को सुरक्षित रूप से execute करने वाले मुख्य घटक के रूप में उपयोग होगा

---

Monty का अवलोकन

• Monty Rust में लिखा गया एक experimental Python interpreter है, जो AI द्वारा जनरेट किए गए कोड को सुरक्षित रूप से चलाने के लिए बनाया गया टूल है
  • यह container-आधारित sandbox के cost, latency और complexity से बचता है, और LLM द्वारा लिखे गए Python code को सीधे चला सकता है
  • इसका startup time कुछ microseconds के स्तर पर है, जो सामान्य containers के सैकड़ों milliseconds से कहीं तेज़ है
• समर्थित क्षमताएँ
  • Python code के कुछ syntax के execution का समर्थन, जिसमें type hints-आधारित static type checking शामिल है
  • host access पूरी तरह ब्लॉक, और external function calls केवल उन्हीं functions तक सीमित हैं जिन्हें developer ने स्पष्ट रूप से अनुमति दी हो
  • Rust·Python·JavaScript से कॉल किया जा सकता है, और resource usage tracking और limiting फीचर बिल्ट-इन हैं
  • stdout/stderr capture, asynchronous code execution, और snapshot save/restore का समर्थन
• सीमाएँ
  • standard library में केवल sys, typing, asyncio, dataclasses(आगामी), json(आगामी) उपलब्ध हैं
  • class definitions और match statements का अभी समर्थन नहीं है
  • third-party libraries समर्थित नहीं हैं
• इसका डिज़ाइन उद्देश्य केवल एक है: agent द्वारा लिखे गए कोड को सुरक्षित रूप से चलाना

Pydantic AI integration

• Monty, Pydantic AI की Code Mode को चलाता है
  • LLM, tool calling की जगह Python code लिखता है, और Monty उसे सुरक्षित रूप से execute करता है
  • उदाहरण में get_weather, get_population जैसे functional tools परिभाषित किए जाते हैं, और LLM उन्हें कॉल करने वाला कोड लिखता है

वैकल्पिक तकनीकों से तुलना

• Monty में language completeness सीमित है, लेकिन security, speed और simplicity में यह मजबूत है
  • startup latency 0.06ms, free, आसान installation, snapshot feature supported
• अन्य तकनीकों के साथ तुलना का सार:
  • Docker: पूरा CPython environment, security अच्छी लेकिन startup latency 195ms
  • Pyodide: WASM-आधारित, security कमजोर और startup latency 2800ms
  • starlark-rust: बहुत सीमित language, तेज़ लेकिन Python से अलग
  • sandboxing services: security मजबूत लेकिन cost, latency और setup complexity अधिक
  • YOLO Python(exec/subprocess) : तेज़ लेकिन security बिल्कुल नहीं
• Monty, file access control, resource limits, और snapshot-आधारित pause/resume फीचर्स के जरिए
  AI code execution के लिए सुरक्षित Python environment प्रदान करता है

[GN⁺]

Hacker News की राय

• WebAssembly से बिल्ड किया हुआ वर्ज़न चलाकर देखा। सीधे टेस्ट करने के लिए एक web playground भी बनाया गया है
  अभी class support नहीं है, लेकिन जब LLM class इस्तेमाल करने की कोशिश करता है तो error देखकर खुद ही code को class के बिना फिर से लिख देता है
  build process को समझाने वाली पोस्ट यहाँ है

  • बात सही है, लेकिन lower abstraction level की छोटी-छोटी असुविधाएँ जमा होती जाती हैं तो ऊपर के level की performance गिरती है। LLM असली समस्या हल करने के बजाय Python interpreter की सीमाओं को bypass करने में resources खर्च करने लगता है
  • प्रोजेक्ट बढ़िया है, लेकिन कोई ठोस use case साफ़ नहीं दिखता। क्या यह code mode के लिए MCP calls को Monty functions से बदलने के लिए है, या query pre/post-processing या CaMeL implementation के लिए?
    terminal agent की ताकत network और filesystem access है, इसलिए उस नज़रिए से sandbox container ज़्यादा natural extension लगता है
  • सच कहूँ तो समझ नहीं आता इसकी ज़रूरत क्यों है। मेरे models पहले से कई भाषाओं में अच्छा code लिख लेते हैं, तो फिर सिर्फ़ restricted Python ही क्यों इस्तेमाल करें?
    Typescript, C#, Python — सब बिना दिक्कत इस्तेमाल कर रहा हूँ
  • “class के बिना code फिर से लिख देता है” का मतलब यह है कि यह तभी संभव है जब training data में ऐसा code काफ़ी मात्रा में मौजूद हो। अच्छी बात है कि Stack Overflow पर ऐसा code बहुत है, तो शायद ठीक चले

• इससे Git पर जाने से पहले के Mercurial वाले दिन याद आ गए। उस समय Git चलन में था इसलिए सब वही इस्तेमाल करते थे, लेकिन मुझे Mercurial का UX कहीं बेहतर लगता था
  आजकल सब Python में agent exec लिख रहे हैं, लेकिन मुझे TypeScript/JS ज़्यादा उपयुक्त लगता है। तेज़, सुरक्षित, और types की वजह से information density भी ज़्यादा है। लेकिन इस बार भी शायद मैं ही हार जाऊँगा

  • मुझे Python के JS से बेहतर होने के तीन कारण लगते हैं
    1. समृद्ध standard library (CSV, sqlite3, json आदि)
    2. LLM द्वारा लिखा code ज़्यादातर सीधे चल जाता है। JS में Node/Deno का बँटवारा, import syntax की उलझन, top-level await जैसी अस्थिर चीज़ें ज़्यादा हैं
    3. data processing ecosystem कहीं ज़्यादा मज़बूत है (csv/pandas आदि)
  • 10 साल से ज़्यादा समय से Python और JS दोनों इस्तेमाल किए हैं, और हर बार अजीब exception handling या null/undefined checks की वजह से परेशान हुआ हूँ। इसलिए मैं तो हर दिन Python ही चुनूँगा
  • ऐतिहासिक रूप से Python का scientific और AI ecosystem मज़बूत रहा है। numpy, scipy, PyTorch जैसी libraries इसकी वजह हैं
    व्यक्तिगत रूप से मुझे TypeScript का static type system ज़्यादा पसंद है, लेकिन speed या security के मामले में दोनों भाषाएँ काफ़ी हद तक समान स्तर पर हैं
  • अगर agent code चला सकता है, तो वह data को सीधे process कर सकता है और context कम हो जाता है।
    Python का data processing ecosystem इस काम के लिए अच्छा है, और Pyodide या ty जैसे tools से security concerns भी कुछ हद तक कम किए जा सकते हैं
  • AI की वजह से CPython पर अब आख़िरकार built-in JIT का दबाव आ रहा है। GPU side पर भी Python DSL आधारित JIT बहुत हैं, इसलिए वास्तविक performance gap बहुत बड़ा नहीं है।
    अब NVIDIA भी आधिकारिक तौर पर Python से kernel लिखने को support करता है

• यह प्रोजेक्ट sandboxing problem के लिए एक दिलचस्प approach है। पहले jsrun नाम के एक experiment में Python के अंदर V8 डालकर JS को सुरक्षित तरीके से चलाया गया था
  Monty भी शायद ऐसा ही लक्ष्य रखता है। न्यूनतम interpreter से शुरू करना AI workloads के लिए उपयुक्त है, लेकिन Python के long-tail syntax को संभालना आसान नहीं है
  security और predictability के लिए surface area कम रखते हुए भी LLM द्वारा generate किए गए जटिल code को संभालने लायक features देना — यही सही balance point है

  • लक्ष्य code mode या external function calling को सरल बनाना है। short term में class, dataclass, datetime, json जितना support भी काफ़ी होगा
  • लेकिन security-critical environments में आख़िरकार VM-based isolation ज़रूरी होगी। Monty जैसी approach पर व्यावहारिक सीमाएँ काफ़ी हैं (E2B कर्मचारी की राय)

• थोड़ी अलग बात है, लेकिन इससे Monty Roberts की किताब 『The Man Who Listens to Horses』 याद आ गई।
  यह जानवरों की भाषा सीखने के बारे में है, और किताब का लिंक और वीडियो भी है

• “LLM द्वारा लिखे गए Python code को बहुत तेज़ और सुरक्षित तरीके से चलाना” — यह विवरण दिलचस्प लगा।
  लेकिन uv जैसे Rust-based runtime भी कम से कम 10ms लेते हैं, इसलिए microsecond-level execution मुश्किल लगती है
  फिर भी standard library के बिना mini interpreter का विचार अच्छा है। AI sandboxing के नज़रिए से भी नया है, और Pydantic से ऐसा कुछ आएगा यह उम्मीद नहीं थी

  • Pydantic और FastAPI आजकल सबसे दिलचस्प Python teams में हैं। ये लगातार नए projects निकालते रहते हैं
  • संदर्भ के लिए, uv एक Rust में लिखा runtime है

• मुझे लगता है कि मौजूदा भाषाओं को फिर से इस्तेमाल करने के बजाय AI के लिए एक सख़्त dedicated language बनाना बेहतर होगा
  AI specifications को अच्छी तरह समझता है, इसलिए उसे इंसानों जैसी ढीली syntax की ज़रूरत नहीं होती।
  उल्टा, सटीक structure और consistent format लागू करने वाली भाषा ज़्यादा उपयुक्त होगी।
  मैं भी ऐसी एक भाषा पर प्रयोग कर रहा हूँ, और मेरा मानना है कि AI code generation में इंसानों से भी ज़्यादा अनुशासन की माँग की जा सकती है

  • लेकिन समस्या training की है। किसी नए language को model को सिखाने के लिए बहुत ज़्यादा data चाहिए।
    जो model पहले से Python अच्छी तरह जानता है, उसे “सिर्फ़ यही functions इस्तेमाल करो” जैसी पाबंदी देना कहीं ज़्यादा व्यावहारिक है

• jstanley की “छोटी असुविधाएँ (papercut)” वाली बात सही है, लेकिन दूसरी ओर बड़े पैमाने पर AI-generated code चलाने में security risk ज़्यादा बड़ा मसला है
  file I/O, network, subprocess जैसी सुविधाएँ पूरे CPython को दे देना खतरनाक है
  हाँ, class restriction अजीब लगती है। इसका security से संबंध नहीं है, बस code गंदा हो जाता है।
  शायद यह “minimum features से शुरू करो और धीरे-धीरे बढ़ाओ” वाला approach है

  • सही बात, class restriction security feature नहीं है, बस अभी तक implement नहीं हुई है

• पूरा CPython emulate करने के बजाय, AI code के लिए ज़रूरी न्यूनतम interpreter बनाना एक दिलचस्प approach है
  पूरा runtime attack surface बहुत बड़ा बना देता है, लेकिन restricted subset अपेक्षाकृत सुरक्षित होता है
  error feedback के ज़रिए LLM को खुद इस restricted syntax के अनुरूप ढलने देना भी व्यावहारिक रणनीति है।
  ज़्यादातर tool-use scenarios में metaclass या dynamic import की ज़रूरत नहीं होती

• एक सीधा सवाल है: क्या seccomp से system calls को restrict करना काफ़ी नहीं होगा?
  अगर file access रोकना है तो उससे जुड़े syscalls block किए जा सकते हैं, फिर अलग interpreter की ज़रूरत क्यों है?

  • bvisor जैसे projects उसी दिशा में जा रहे हैं
  • यह सही approach है, लेकिन अगर default runtime बहुत शक्तिशाली हो तो bypass की संभावना भी ज़्यादा रहती है।
    अगर शुरुआत ही बेहद सरल runtime से की जाए तो attack surface छोटा रहता है और सुरक्षा काफ़ी बेहतर होती है

• प्रोजेक्ट अपने आप में समझदारी भरा है, लेकिन “AI के लिए ultra-fast tool” वाली बात सुनकर हँसी आती है
  AI की सोचने की गति इतनी धीमी है कि code execution कितना भी तेज़ हो, कुल अनुभव में बहुत बड़ा फ़र्क नहीं पड़ता
  यह वैसा है जैसे बगल में हिमनद की रफ़्तार से काम करने वाले सहकर्मी के साथ डिलीवरी करना