सब कुछ लोकल में – ऑफलाइन AI वर्कस्पेस निर्माण
(instavm.io)- लोकल LLM रनिंग और कोड सैंडबॉक्स वातावरण का उपयोग करके, क्लाउड पर निर्भरता के बिना AI वर्कस्पेस सेट करने का तरीका
- Ollama से लोकल LLM चलाकर, Apple Container से अलग-थलग VM में कोड execute करके और Playwright के साथ headless browser के ज़रिए automation एवं इंटरनेट एक्सेस सक्षम करना
- UI को
assistant-uiपर बेस करते हुए मॉडल चयन ड्रॉपडाउन और ai-sdk इंटीग्रेशन, तथा MCP(Model Context Protocol) के जरिए सुरक्षित कोड रनिंग environment बनाया - MCP से कनेक्ट हुए Coderunner VM में Jupyter server और browser चला कर चार्ट निर्माण, इमेज/वीडियो एडिटिंग, GitHub tools इंस्टॉल, और वेब खोज को privacy-सुरक्षित तरीके से रन करना
- वर्तमान में यह सिर्फ़ Apple Silicon पर काम करता है; आगे चलकर UI सुधार, ब्राउज़र डिटेक्शन बाईपास, और टूल मैनेजमेंट फ़ंक्शन मजबूत करना बाकी है
आवश्यकताएँ और पृष्ठभूमि
- लक्ष्य: सभी कुछ लोकल में चलाना — कोई cloud/remote code execution नहीं
- मौजूदा LLM chat apps (जैसे ChatGPT, Claude) क्लाउड-आधारित LLM chat, क्लाउड/लोकल code execution और इंटरनेट एक्सेस जैसी सुविधाएँ देती हैं
- ओपन सोर्स LLM के बढ़ते उपयोग ने सवाल खड़ा किया कि क्या ये सारी चीज़ें पूरी तरह लोकल की जा सकती हैं
- सिर्फ लोकल LLM पर्याप्त नहीं, इसलिए कोड को अलग वातावरण में execute होना चाहिए और browser आधारित content access भी चाहिए
विचार
- LLM को पूरी तरह लोकल वातावरण में रन करना
- केवल लाइटवेट VM के अंदर कोड रन करके host सिस्टम पर संभावित risk को ब्लॉक करना
- नई जानकारी/टूल खोज और automation के लिए headless browser जोड़ना
- AI planning से लेकर code execution तक पूरी तरह लोकल में होने वाला privacy-first वर्कफ़्लो बनाना
- किसी बाहरी सेवा को डेटा दिए बिना फोटो, वीडियो एडिटिंग आदि विविध काम लोकल में करना
टेक स्टैक
- LLM: Ollama (लोकल मॉडल + कुछ external मॉडल सपोर्ट)
- UI:
assistant-ui+ ai-sdk (मॉडल चयन फीचर जोड़कर) - VM रनटाइम: Apple
container(पूरी तरह अलग VM environment उपलब्ध कराता है) - ऑर्केस्ट्रेशन:
instavm/coderunner(MCP से Jupyter server कनेक्शन) - ब्राउज़र ऑटोमेशन: Playwright (MCP tool के रूप में expose)
Mac ऐप प्रयास और बदलाव
a0.devसे native Mac ऐप बनाने की कोशिश की, लेकिन वह iOS-first होने से मुश्किलें आईं- Electron + NextJS wrapping भी try किया, पर complexity कारण छोड़ना पड़ा
- अंततः लोकल web-based
assistant-uiपर शिफ्ट किया गया
Assistant-UI का कस्टमाइज़ेशन
- मॉडल चयन ड्रॉपडाउन जैसी मल्टी-मॉडल सपोर्ट फीचर की अपेक्षा थी, लेकिन वास्तविकता सीमित रही
- उदाहरण देखकर ai-sdk से सीधे multi-model चयन फीचर implement किया
- शुरुआती चरण में OpenAI/Anthropic की तरह क्लाउड मॉडल भी support किए, फिर धीरे-धीरे लोकल शिफ्ट की strategy अपनाई
Tool-calling और मॉडल सपोर्ट मुद्दे
- Tool-calling करने वाले मॉडल की ज़रूरत थी, लेकिन Ollama जैसे कुछ मॉडल असल में सपोर्ट नहीं करते
- official docs में tool support दिखता है, लेकिन वास्तविक implementation कई बार अधूरा होता है
- ओपन सोर्स ecosystem तेज़ी से बदलता है, इसलिए tool support status और token pricing दोनों ही बहुत volatile हैं
कंटेनर आधारित अलग-थलग कोड रनिंग
- Apple के Container टूल से Docker की तुलना में प्रत्येक container को पूर्ण अलग VM पर्यावरण मिलता है, जिससे AI-generated code अधिक सुरक्षित चलता है
- VM वातावरण में Jupyter server deploy कर Model Context Protocol(MCP) से expose किया, जिससे Claude Desktop, Gemini CLI आदि tools सीधे use हो सकें
coderunnerMCP server का code ओपन करके बाहरी tools के साथ integration examples दिए- Apple Container अभी unstable है; build/image issues आने पर बार-बार rebuild/restart करना पड़ता है
- वास्तविक वीडियो एडिट टेस्ट में UI + LLM + Coderunner stack का सही काम करना verify हुआ
headless browser एकीकरण
- container के अंदर Playwright आधारित headless browser deploy करके MCP टूल के रूप में expose किया
- नए टूल/जानकारी खोज, GitHub usage search और research automation जैसी use-cases के लिए अपेक्षा
- बेसिक वर्कफ़्लो: लोकल LLM + sandboxed code execution + headless browser का संयोजन पूर्ण हो चुका है
संभावित कार्य उदाहरण
- किसी विषय पर research और summarization
- natural language कमांड से CSV chart generation और rendering
- ffmpeg से वीडियो editing (segment कटाई आदि)
- image resize, crop, format conversion
- GitHub tools की container के अंदर इंस्टॉलेशन
- headless browser से webpage crawling और summarization आदि
फ़ाइल वॉल्यूम माउंट और आइसोलेशन
- Host का
~/.coderunner/assetscontainer के/app/uploadsसे map कर फाइलों को secure shared space में रखा जाता है - execute किए गए कोड को host सिस्टम को सीधे access नहीं मिलता, यानी security बेहतर रहती है
सीमाएँ और आगे की चुनौतियाँ
- अभी केवल Apple Silicon पर्यावरण में काम करता है, macOS 26 विकल्प के रूप में
- टूल मैनेजमेंट, आउटपुट स्ट्रीमिंग आदि के लिए UI सुधार बाकी है
- headless browser कई साइटों पर bot detection के कारण ब्लॉक हो जाता है
निष्कर्ष
- यह project सिर्फ़ एक प्रयोग नहीं, बल्कि computing sovereignty और privacy protection पर केंद्रित मॉडल है
- क्लाउड या remote server पर निर्भरता बिना, अपने निजी लोकल मशीन पर डेटा सुरक्षित रूप से प्रोसेस करने का अनुभव देता है
- बेहतरीन LLM शायद बड़े cloud में ही रह सकते हैं, लेकिन लक्ष्य है कि individual privacy बचाने वाले local AI tools आगे बढ़ें
- ओपन सोर्स
coderunner-uiGitHub पर उपलब्ध है; feedback और collaboration का स्वागत है
2 टिप्पणियां
HN की राय कि यह "सिर्फ़ एक मज़ेदार शौक के करीब" है, मैं उससे सहमत हूँ।
लेकिन चाहें जितना भी इसे इधर-उधर सजाएँ, फिर भी व्यावसायिक विकल्प जितनी सुविधा और गति नहीं पकड़ पाते।
Hacker News टिप्पणी
मैं हमेशा ऐसे अनुभव-आधारित आदर्शवाद की तरफ़ आकर्षित रहता हूँ, लेकिन जब मैं उपलब्ध मॉडल परफॉर्मेंस और क्लाउड पर ऑन-डिमांड चलाने की वास्तविक लागत दोनों को साथ में देखता हूँ, तो यह मेरे लिए किसी व्यावहारिक रणनीति से ज्यादा एक मज़ेदार हॉबी लगता है।
हार्डवेयर इतनी तेजी से विकसित हो रहा है कि सेकेंड-हैंड हार्डवेयर खरीदने पर भी उसकी वैल्यू बहुत तेज़ी से गिरती है, इसलिए उसमें निवेश को मैं न्यायोचित नहीं मान पाता।
ऊपर से लोकल में रन होने वाले वेट्स का परफॉर्मेंस भी काफी घट जाता है, इसलिए अभी इसमें निवेश करना ज्यादा सार्थक नहीं लगता।
मैं भरोसा करता हूँ कि किसी दिन यह स्थिति बदलेगी और अच्छे वेट्स सार्वजनिक होते ही मैं लोकल इनफरेंस स्टैक में निवेश करने के लिए तैयार रहूँगा।
उससे पहले, यह बस तेजी से मूल्य घटने वाली महँगी एसेट को यूँ ही खर्च करने जैसा लगता है।
मैं इन दिनों लोकल LLM इकोसिस्टम को बहुत दिलचस्प पाता हूँ और लोगों को क्या करते हुए देखना मज़ेदार लगता है।
लेकिन हर बार जब मैं अपने MacBook Pro की बड़ी RAM पर लोकल LLM सीधे चलाता हूँ, तब फ़्रंटियर मॉडल (नया SaaS LLM) से अंतर और भी साफ़ दिखता है।
अगर मैं महीने के लगभग $20 दूँ तो टोकन-आधारित खर्च पर कई हाई-पर्फॉर्मेंस मॉडल इस्तेमाल कर सकता हूँ, लेकिन स्पीड और क्वालिटी दोनों में लोकल मॉडल अभी भी पीछे हैं।
केवल benchmark चार्ट देखकर यह गैप ठीक से नहीं दिखता, जबकि वास्तविक उपयोग में FRONTIER मॉडल कहीं बेहतर महसूस होता है।
OpenAI, Anthropic जैसे मॉडल कभी-कभी पहले से ही धीमे और त्रुटिपूर्ण लगते हैं, और लोकल पर यह और बढ़ जाता है।
Privacy के लिए यह किसी हॉबी या प्रयोग में ठीक है, लेकिन मेरे लिए बेहतर है कि मैं अगला MacBook तभी लूँ जब उसमें 128GB RAM जैसा असली हार्डवेयर आ जाए।
मैं मानता हूँ कि API के पीछे मौजूद मॉडल जब आउटपुट से सीधे मुनाफ़ा कमाने लगते हैं, तो आउटपुट की गुणवत्ता धीरे-धीरे गिरने लगेगी।
मुझे लगता है यह बस समय की बात है।
“हार्डवेयर जल्दी बदलता है इसलिए सेकेंड-हैंड हो या नया, उसकी वैल्यू तेजी से गिरती है” वाले तर्क पर मुझे सवाल है।
कई मामलों में सबसे तेज़ स्पेक्स न होने पर भी मॉडल रन किए जा सकते हैं।
अंततः यह opex (operational expenditure) बनाम capex (capital expenditure) की क्लासिक बहस है; वित्तीय नज़रिए से क्लाउड सच में तभी फायदे का होता है जब बहुत specific स्थिति हो (जैसे तुरंत infra खड़ा करना हो और demand forecast नहीं हो)।
LLM में यह कम लागू होता है।
OP ने करीब $600 निवेश की बात की है, जो लगभग EC2 की तीन महीने की कीमत के बराबर है।
ऐसे में सोचता हूँ कि क्या OP के तर्क को संख्या के साथ और ठोस तरीके से सपोर्ट किया जा सकता है।
मैं भी आने वाले बदलाव पर भरोसा करता हूँ।
मैं हाल में Claude Code जैसी चीज़ों का काम में ज़्यादा इस्तेमाल करने लगा हूँ, क्योंकि रोज़-रोज़ coding के लिए किसी कंपनी पर निर्भर रहना नहीं चाहता।
प्लान लिमिट, API खर्च, हर महीने $100–$200 देने की चिंता, और डर कि मेरा डेटा AI कंपनियों द्वारा collect/monitor किया जा सकता है—ये सब परेशान करने वाले हैं।
स्मार्ट होम डिवाइस भी मैं केवल local-controlled वाले ही इस्तेमाल करता हूँ, और बाहर से एक्सेस चाहिए तो खुद सॉफ्टवेयर सेट करके अपने सर्वर पर चलाता हूँ।
अगर कोई कंपनी अचानक सेवा बंद कर दे, कीमत बढ़ा दे, या मेरे डेटा का उपयोग करे, तो मैं इसमें बंधना नहीं चाहता।
लेकिन अभी के लिए अपने हार्डवेयर पर LLM इंस्टॉल करने या VPS पर चलाने के लिए motivation, खर्च, ज्ञान और maintenance में से कोई भी पर्याप्त नहीं है।
मैं अभी Anthropic पर महीने के $20 देने से संतुष्ट हूँ, और मौजूदा ओपन मॉडल अभी फ्रंटियर-ग्रेड SaaS तक नहीं पहुँच पाए हैं।
फिर भी बदलाव का इंतज़ार है।
मुझे लगता है यह स्थिति शायद कभी नहीं बदलेगी।
दो साल बाद अगर GPT-5 लेवल का लोकल विकल्प भी आ जाए, तब भी क्लाउड में उससे बेहतर विकल्प आ जाते हैं, इसलिए वही बहस फिर खड़ी होगी।
यह काम—लोकल, sandboxed execution layer पर फोकस करने वाला—निजी AI workspace को सच में बनाने वाला बड़ा puzzle piece है।
coderunner टूल काफी उपयोगी लग रहा है।
लेकिन दूसरी चुनौती है AI का ‘knowledge layer’, यानी ईमेल, नोट्स, फाइलों जैसे व्यक्तिगत डेटा को समझने की परत।
RAG से कई सालों के ईमेल संभालते समय vector database स्टोरेज आसानी से 50GB पार कर सकता है।
(FYI, मैं Berkeley की उस टीम का हिस्सा हूँ जो इसी समस्या को हल कर रही है।)
हमने LEANN नाम का vector index बनाया है जिसमें embeddings को स्टोर किए बिना लगभग 97% storage बच गया।
इसलिए पूरी डिजिटल लाइफ को लोकल में index करना वास्तव में संभव हो गया।
ऐसा ultra-light knowledge index और local execution engine जोड़ना ही सच में वास्तविक ‘local Jarvis’ की राह लगता है।
कोड: https://github.com/yichuan-w/LEANN
शोध-पत्र: https://arxiv.org/abs/2405.08051
2025 के हिसाब से कई सालों के ईमेल का vector database लगभग 50GB होना उल्टा देखने पर अभी भी एक modest जरूरत लगता है।
LEANN के बारे में जानकारी देने के लिए धन्यवाद।
मुझे विशेष रुचि है कि RAG को LLM एजेंट, पाइपलाइन या execution engine की knowledge layer के रूप में कैसे उपयोग किया जाए।
बड़े codebase और LLM को integrate करना संभव है या नहीं, यह जानना चाहता था; Claude Code के साथ पहले से जुड़े होने के कारण RAG सॉल्यूशन के साथ प्रयोग शुरू करना आसान लगता है।
अगर किसी ने RAG और LLM को जोड़कर बड़े codebase पर वास्तव में काम किया है तो बताइए।
फ्रंट-एंड मॉडल (LM) के लिए मैं शुरुआत cloud से करने वाला हूँ और पहले खुद try करूँगा।
रिफ़रेंस: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md
मुझे embeddings या vector storage structure की लगभग कोई जानकारी नहीं है।
cloud embeddings में क्या कोई ऐसा project है जो इसी “pruned graph” approach को इस्तेमाल करता हो?
यह अजीब लगता है कि index स्रोत डेटा से बड़ा हो जाए।
आमतौर पर तो index को बेहतर फॉर्मैट में होना चाहिए ताकि पहुँच तेज़ हो; इतनी बढ़ी हुई साइज असामान्य लगती है।
“विश्व-स्तरीय” LLM की मदद के बाद भी अपेक्षा के हिसाब से स्मूद न होने का एक कारण यही है कि ये मॉडल कभी-कभी steps छोड़ देते हैं, प्लेटफॉर्म-विशिष्टता नज़रअंदाज़ करते हैं, या उल्टा समस्या बढ़ाने वाली hallucination कर देते हैं।
यह स्पष्ट दिखता है कि native ऐप डेवेलपमेंट का training data अभी भी सीमित है।
native ऐप डिज़ाइन पर ब्लाग या medium लंबी posts लगभग नहीं के बराबर हैं, और ओपन सोर्स डेस्कटॉप ऐप प्रोजेक्ट मोबाइल/वेब की तुलना में काफी कम हैं।
1990s में MS ने प्रोफेशनल राइटर्स को नियुक्त कर Windows coding पर बेहतरीन किताबें (जैसे Charles Petzold) निकालने के लिए निवेश किया था, लेकिन वह पूरा पेशेवर उद्योग अब लगभग खत्म हो चुका है।
इसलिए training data की यह कमी आगे और बढ़ती दिखती है।
यह पूरा software engineering trend भी कुछ ऐसा ही है—native desktop app बनाने वालों की संख्या कम है और करियर के लिहाज़ से इसे लगभग dead-end माना जाता है।
1990s में Windows desktop app developer के लिए मध्यवर्गीय जीवन-यापन लगभग सुनिश्चित था और barrier भी ऊँचा था (C/C++ कठिन था और Windows API सीखना आसान नहीं), क्योंकि MS ने education पर भारी खर्च किया था; अब स्थिति बदल चुकी है।
अब OS vendors (Microsoft, Apple) या कुछ legacy software companies (Adobe, Autodesk आदि) के अलावा desktop app demand बहुत कम है।
मैंने Ollama का macOS ऐप try किया और तुरंत देखा कि वह किसी Google डोमेन से connect होने की कोशिश कर रहा था।
इससे “पूर्णतया private” होने का दावा भरोसेमंद नहीं लगता।
https://imgur.com/a/7wVHnBA
यह सिर्फ़ auto-update check की वजह से था।
https://github.com/ollama/ollama/blob/main/docs/faq.md
ऐसे network calls audit किए जा सकते हैं, इसलिए भरोसे के लिहाज़ से थोड़ा बेहतर लग सकता है।
केवल हर अपडेट के साथ outbound network calls को automate कर ट्रैक करना पर्याप्त है।
vscode में cline plugin और copilot plugin पर भी यही देखा।
मैंने local ollama ही सेट किया और outbound connections block किए, तो काम ही बंद हो गया।
telemetry बंद करने के बाद भी cline ने बाहर से कम्युनिकेशन की कोशिश जारी रखी—बहुत निराशाजनक।
मैं सच में इस बारे में बार-बार सोचता हूँ।
मुझे लगता है कि प्राइवेसी सुनिश्चित करना बहुत सारा friction और challenge लेकर आता है।
मैं अभी भी local approach को पसंद करता हूँ, क्योंकि ज्यादातर मामलों में AI inference धीमी है या local के करीब कोई फर्क नहीं दिखता।
हाल ही में मैंने cerebras (और groq भी सुना) को try किया, और 1000 tokens/sec जैसी स्पीड देखकर patience का threshold बदल गया।
cerebras कहता है कि वे डेटा को record नहीं करते और मैं चाहता हूँ कि भरोसा करूँ कि मैं उनका sponsored उपयोगकर्ता नहीं हूँ (अगर होता तो बेहतर होता)।
सेवा सच में अच्छी है।
फिर भी उम्मीद है कि एक दिन speed में भी meaningful बदलाव आएगा।
diffusion architecture खासकर बहुत तेज़ लगती है।
इस समय सीमा software की नहीं, hardware की है, ऐसा मेरा मानना है।
लोकल में उपयोगी LLM चलाने के लिए करीब $2000 का hardware चाहिए (जैसे Strix Halo, AI Max 395)।
अगर Strix Halo में कुछ और upgrades हुए तो काम काफी आसान होगा।
बदलाव सच में बहुत तेजी से हो रहा है।
https://simonwillison.net/2025/Jul/29/space-invaders/
इस कीमत का hardware लेकर भी “usable” होने का threshold अस्पष्ट लगता है।
किसी तकनीक के उपयोगी होने के लिए instant, magic-जैसा अनुभव ज़रूरी है।
स्लो और अस्पष्ट output के साथ सेटिंग बदलते रहना शुरू करते ही लगभग पूरी value खत्म हो जाती है।
लोकल मॉडल बेहतर हुए हैं, लेकिन कोडिंग क्षमता में अभी भी Claude जैसे मॉडल से नीचे हैं।
मैंने OpenRouter के latest Qwen और GLM मॉडल को सीधे cline पर रन करके देखा; मुझे ये करीब-करीब Claude 3.0 के बराबर लगे।
मुझे लगता है कि benchmark वास्तविकता को ठीक से capture नहीं करते।
ब्रांड और ब्लॉग पोस्ट थोड़ी confusing लगती हैं।
वेबसाइट पर लगता है कि वे cloud में VM चलाते हैं (जैसे Firecracker),
जबकि ब्लाग में मैक के लिए local VM चलाने का आभास मिलता है।
पहले यह बनाते समय जैसा देखा, चाहता हूँ कि नए gpt-oss विकल्प के साथ इसे सीधे explore कर सकूँ।
OP को बता दूँ कि https://github.com/assistant-ui/assistant-ui लिंक काम नहीं कर रहा।
यह प्रोजेक्ट वाकई बहुत बढ़िया और अच्छी तरह डिज़ाइन किया हुआ है।
मैं भी लगभग उसी दिशा में काम कर रहा हूँ; असल बात यह है कि एक क्लिक से cloud और पूरी तरह local दोनों के बीच आसान स्विच हो।
सभी डेटा/सेटिंग/प्रॉम्प्ट केवल local में ही सेव हों और API कॉल सीधे provider को जाएँ, हमारे server से होकर नहीं।
अभी मैं browser में पूर्णतः local inference mlc-llm से चला रहा हूँ (Qwen3-1.7b बहुत अच्छी तरह काम कर रहा है)।
https://hypersonic.chat/