DEV Community: tauchi हिन्दी

osFoundry में Loop और Graph क्या हैं और कब कौन सा इस्तेमाल करें?

tauchiii — Fri, 06 Nov 2026 18:12:18 +0000

शाम के 6:40 बजे हैं और AI असिस्टेंट ने अभी-अभी बताया है कि फेल हो रहे टेस्ट ठीक हो गए हैं। आप खुद चलाकर देखते हैं। दो अब भी लाल हैं। आप आउटपुट फिर से पेस्ट करके दोबारा पूछ सकते हैं, या यह काम किसी ऐसी चीज़ को सौंप सकते हैं जो तभी रुकती है जब टेस्ट रनर भी हाँ कहे। अगली सुबह मार्केटिंग की एक साथी अलग सवाल पूछती है: क्या ऐसी ही कोई चीज़ हर वर्किंग डे पर उसके आने से पहले तीन कॉम्पिटिटर वेबसाइट चेक कर सकती है?

ये दोनों काम osFoundry के एक ही हिस्से में, दो पास-पास वाले मेन्यू आइटम के नीचे मिलते हैं: Loop और Graph।

एजेंट्स को बिना लगातार निगरानी के चलाने के दो तरीके

Loop किसी एजेंट टीम को एक लक्ष्य की ओर चलाने का दोबारा इस्तेमाल होने वाला तरीका है। इसमें एजेंट्स की एक सूची, आम भाषा में लिखा लक्ष्य, यह जाँचने का तरीका कि लक्ष्य पूरा हुआ या नहीं, सख्त सीमाएँ (कितने राउंड, हार मानने से पहले लगातार कितनी बार फेल) और ज़रूरत हो तो शेड्यूल जैसा कोई ट्रिगर, सब एक साथ होते हैं। यह राउंड में काम करता है, हर राउंड को लक्ष्य के हिसाब से ग्रेड करता है और खुद रुक जाता है। Graph एक सेव किया हुआ वर्कफ़्लो प्रोग्राम है, उन मामलों के लिए जब रास्ता तय नहीं होता: यह किसी नतीजे के आधार पर ब्रांच कर सकता है, किसी हिस्से को पास होने तक दोबारा चला सकता है, काम एक साथ कई एजेंट्स में बाँट सकता है, इंसानी अप्रूवल के लिए रुक सकता है और दूसरे graphs को कॉल कर सकता है। दोनों osFoundry डेस्कटॉप ऐप के मुख्य साइडबार में हैं, पहले Loop और ठीक उसके नीचे Graph, और ऐप का अपना एक-लाइन का फ़र्क ही याद रखने लायक है: Loop हमेशा एक ही रास्ता लेता है, Graph चलते-चलते अपना रास्ता तय करता है।

Loop चलते समय आपको क्या दिखता है

यह पूरा हो चुका एक Loop सेशन है (टेस्ट और फ़ाइल नाम उदाहरण डेटा हैं)। जानने लायक हिस्से:

बाईं ओर सेशन रेल। हर Loop रन अपना अलग सेशन होता है, नीचे उसका स्टेटस लिखा होता है। यहाँ "Verified" का मतलब है कि आख़िरी राउंड जाँच में पास हुआ, न कि AI ने ऐसा कह दिया।
बीच वाले कॉलम के ऊपर राउंड स्ट्रिप। "Round 3 of 4", साथ में इस्तेमाल होने वाली जाँच ("Runs npm test — a zero exit code means done") और लगातार वेरिफ़िकेशन फ़ेल होने का काउंटर, जो कहीं न पहुँच रहे loop को रोकता है।
Rounds टैब। हर राउंड की एक लाइन, जिसमें लिखा होता है कि कितने क्राइटेरिया पूरे हुए ("1 of 3 met", "2 of 3 met", "3 of 3 met")। किसी राउंड को खोलकर देख सकते हैं कि उसमें ठीक कौन-से क्राइटेरिया पास हुए।
दाईं ओर इंस्पेक्टर, जिसमें Goal, Trigger और Hooks टैब हैं।
पैनल्स के ऊपर Pause और Cancel, जब आप चाहते हैं कि यह अगली जाँच का इंतज़ार किए बिना अभी रुके।

यूज़ केस 1: डेवलपर जिसे टेस्ट सच में ग्रीन चाहिए

कौन: दिन के आख़िर में एक सोलो डेवलपर, जिसकी JavaScript सूट लाल है और असिस्टेंट बार-बार जीत का ऐलान कर रहा है।

आप Loop खोलते हैं और New session दबाते हैं। New loop run डायलॉग में पहले से तैयार loops की सूची होती है, और "JS suite" सर्च करने पर Get the JS suite green मिलता है। शुरू करने से पहले दाईं ओर का कार्ड बताता है कि यह कैसे काम करता है: Who runs it (एक डिबगर एजेंट जो तीन टेस्ट स्पेशलिस्ट को लीड करता है), How it stops (ज़्यादा से ज़्यादा 4 राउंड, लगातार 3 बार फ़ेल होने पर रुक जाता है) और How it grades itself (npm test चलाता है, और सिर्फ़ ज़ीरो exit code को ही पूरा माना जाता है)।

Start it के नीचे आप Just add it की जगह Run once now चुनते हैं, प्रोजेक्ट और वह फ़ोल्डर चुनते हैं जिसमें एजेंट्स को काम करना है, और Run it now दबाते हैं। फिर Rounds टैब खोलकर देखते रहते हैं। उदाहरण वाले रन में पहले राउंड ने तीन में से एक टेस्ट पूरा किया, दूसरे ने दो और तीसरे ने तीनों, और उसी पल loop अपने आप रुक गया और सेशन Verified मार्क हो गया।

आख़िर में आपके पास कोई चैट मैसेज नहीं होता जो फ़िक्स का दावा करे, बल्कि राउंड-दर-राउंड रिकॉर्ड होता है कि कौन-सा टेस्ट कब पास हुआ, जिसे आपके अपने टेस्ट रनर ने ग्रेड किया। इसी सूची में Python, Go, Rust और Java सूट, टाइप एरर, lint और flaky टेस्ट के लिए भी loops हैं।

यूज़ केस 2: मार्केटर जिसे हर वर्किंग डे कॉम्पिटिटर रिपोर्ट चाहिए

कौन: मार्केटिंग या प्रोडक्ट से कोई, जो कॉम्पिटिटर साइट्स हाथ से चेक करता है और कोड नहीं लिखता।

उसी New loop run डायलॉग में सबसे ऊपर वाले सेक्शन का नाम "Start here — these need nothing set up" है, और Watch the competitors उसी में है, क्योंकि यह सिर्फ़ वेब पर सर्च करता है और आपकी फ़ाइलों को कभी नहीं छूता। Goal for this run में आप लिखते हैं कि किन पर नज़र रखनी है और क्या देखना है (जैसे कीमतें, नए फ़ीचर और हायरिंग), Run once now चुनते हैं और Run it now दबाते हैं। पहली रिपोर्ट में सिर्फ़ वही होता है जो बदला है, हर लाइन पर तारीख़ और सोर्स के साथ, और किसी कंपनी के अपने बारे में किए गए दावों को अनवेरिफ़ाइड मार्क किया जाता है।

इसे बार-बार चलाने के लिए आप Trigger टैब खोलते हैं और Add a schedule दबाते हैं। Run this on a schedule डायलॉग में प्रीसेट होते हैं (Every 30 min, Hourly, Daily 09:00, Weekdays 09:00), यह cron लाइन और अगले तीन रन का समय दिखाता है, और दो काम के सवाल पूछता है: अगर अगला रन आने तक पिछला रन चल ही रहा हो तो क्या करें (Skip it, या Wait, then run), और अगर कंप्यूटर स्लीप में था तो क्या करें (Up to an hour late, Up to 12 hours late, या However late)।

Save schedule के बाद Trigger टैब में "On a schedule" और अगले रन का समय दिखता है। अब हर वर्किंग डे की सुबह उसके लिए एक रिपोर्ट तैयार रहती है, बिना टर्मिनल खोले। शेड्यूल तभी चलते हैं जब डेस्कटॉप ऐप खुला हो, और इसी के लिए कैच-अप सेटिंग है।

यूज़ केस 3: टीम लीड जिसके वर्कफ़्लो को ब्रांच करना है

कौन: एक लीड जो चाहता है कि किसी बड़े बदलाव की हर फ़ाइल अलग से रिव्यू हो, फिर एक मर्ज की हुई रिपोर्ट बने, और कोई भी ऐसा काम जो वापस न हो सके, उससे पहले इंसानी साइन-ऑफ़ हो।

यहीं पर Loop सही ढाँचा नहीं रहता। Loop हर राउंड में एक ही प्लान दोहराता है, जबकि इस लीड को हर फ़ाइल के लिए एक रिव्यूअर, फिर एक मर्ज स्टेप और कभी-कभी अप्रूवल के लिए रुकना चाहिए। यह Graph का काम है।

आप Graph खोलते हैं और सूची के बगल वाला प्लस बटन दबाते हैं। Create a Graph दो रास्ते देता है: Start with a working graph (एक सुरक्षित, चलने लायक प्रोग्राम जिसे आप बाद में बदलते हैं) या Choose a starter। Starters आम पैटर्न के तैयार उदाहरण हैं, हर एक के साथ छोटा-सा नोट कि कब इस्तेमाल करें। Review each item, then merge हर आइटम के लिए एक एजेंट एक साथ चलाता है और फिर एक बार मर्ज करता है। Triage and route किसी इनपुट को एक बार क्लासिफ़ाई करके ठीक एक स्पेशलिस्ट को भेजता है। Propose, ask, then apply एक बदलाव तैयार करता है, इंसान के जवाब के लिए रुकता है और सिर्फ़ हाँ मिलने पर ही आगे बढ़ता है।

प्रोग्राम खुद कोड है, ड्रैग-एंड-ड्रॉप डायग्राम नहीं, क्योंकि ब्रांचिंग और सीमित रीट्राई असली कंट्रोल फ़्लो हैं। आमतौर पर आप Maestro या किसी एजेंट से इसे लिखवाते या बदलवाते हैं, और रोज़मर्रा में जो मायने रखता है उसे Configure session में संभालते हैं: Maximum agents at once, टोकन चेतावनी, Hard token ceiling, डिफ़ॉल्ट इनपुट, और हर स्टेप कौन-सा एजेंट और मॉडल इस्तेमाल करेगा।

चलने पर रन पैन में तीन टैब होते हैं। Run स्टेप्स को लाइव दिखाता है, और आप Pause, Resume या Cancel कर सकते हैं। अगर graph किसी अप्रूवल स्टेप पर पहुँचता है, तो एक कार्ड Approve या Decline पूछता है, और इंतज़ार के दौरान बाकी पैरलल काम चलता रहता है। Changes में वे फ़ाइलें होती हैं जो रन ने बनाईं या बदलीं, और इनमें से कुछ को undo किया जा सकता है। History में पिछले रन होते हैं, तो फ़ेल हुआ रन और उसे ठीक करने वाला दोबारा का रन साथ-साथ दिखते हैं। लीड के पास एक ऐसा रिव्यू होता है जिसे दोहराया जा सके और जिसके सभी रन और फ़ाइल बदलाव बाद में जाँचे जा सकें। Graphs ब्राउज़र में पढ़े जा सकते हैं, लेकिन चलाने के लिए डेस्कटॉप ऐप चाहिए।

Loop और Graph एक-दूसरे को काम कहाँ सौंपते हैं

दोनों में से कोई अकेले काम नहीं करता। Loop के Team roster में एजेंट्स Agent team और Agent Registry से आते हैं, और loop खुद एक दोबारा इस्तेमाल होने वाला प्रीसेट है जिसे आप osStudio में वर्ज़न कर सकते हैं, इसलिए क्वालिटी थ्रेशोल्ड या रीट्राई लिमिट बढ़ाने पर चुपचाप बदलाव नहीं, बल्कि हिस्ट्री बनती है। Graph को बनाते समय एक स्थिर आइडेंटिफ़ायर इसीलिए दिया जाता है ताकि loops और दूसरे graphs उसे कॉल कर सकें, यानी शेड्यूल किया हुआ Loop 9:00 बजे एक ब्रांचिंग Graph शुरू कर सकता है। Message में loops और graphs लोगों और अकेले एजेंट्स के साथ किसी चैनल के सदस्य बन सकते हैं, जिससे उनके अपडेट टीम के रोज़ वाले रूम में ही आते हैं। शेड्यूलिंग के बारे में और गहराई से जानने के लिए देखें cron पर एजेंट शेड्यूल करना और एजेंट ट्रिगर।

नए लोग जो सवाल पूछते हैं

क्या Loop बस एक cron job है?
नहीं। शेड्यूल उसका सिर्फ़ एक वैकल्पिक हिस्सा है। Loop यानी टीम, लक्ष्य और जाँच, साथ में राउंड की सीमाएँ, और यह हिसाब रखता है कि हर राउंड ने कौन-से क्राइटेरिया पूरे किए। आप इसे एक बार हाथ से चला सकते हैं और कभी कोई ट्रिगर न दें।

अगर Loop भी एजेंट्स को पैरलल चला सकता है, तो मुझे Graph की ज़रूरत क्यों है?
फ़र्क पैरललिज़्म का नहीं है। Graph तब चुनें जब अगला स्टेप पिछले के नतीजे पर निर्भर हो: किसी एक स्पेशलिस्ट को भेजना, सिर्फ़ फ़ेल हुआ हिस्सा दोबारा चलाना, किसी इंसान की हाँ का इंतज़ार करना, या कोई दूसरा वर्कफ़्लो कॉल करना। अगर हर रन एक ही स्टेप्स से गुज़रता है, तो Loop आसान है।

क्या कोई loop हमेशा चलता रह सकता है और मेरा API बजट ख़त्म कर सकता है?
हर तैयार loop की राउंड की एक ऊपरी सीमा होती है और वह लगातार तय संख्या में फ़ेल होने पर रुक जाता है, और कार्ड शुरू करने से पहले ही दोनों दिखा देता है। Graphs की सेशन सेटिंग्स में Maximum agents at once और Hard token ceiling होते हैं।

क्या मुझे कोड लिखना पड़ेगा?
Loops के लिए नहीं: आप एक चुनते हैं, और डायलॉग में लक्ष्य और ट्रिगर सेट करते हैं। Graph का प्रोग्राम कोड है, लेकिन आप किसी starter से शुरू कर सकते हैं, Maestro या किसी एजेंट से उसे एडिट करवा सकते हैं, और प्रोग्राम को छुए बिना इनपुट, लिमिट और हर स्टेप के एजेंट बदल सकते हैं।

दोनों को आप डेस्कटॉप ऐप में आज़मा सकते हैं, जो osfoundry.io/hi/download पर मिलता है।

osFoundry का Maestro क्या करता है, एक AI चैट जो अपना हर कदम दिखाती है

tauchiii — Fri, 06 Nov 2026 17:50:46 +0000

गुरुवार के 4:40 बजे हैं और प्रिया ने एक AI असिस्टेंट से अपने ऐप के सेटिंग्स पेज पर "Delete account" बटन जोड़ने को कहा है। जवाब आता है, "हो गया, 4 फ़ाइलें बदलीं।" शिप करने से पहले वह जानना चाहती है कि वे चार फ़ाइलें कौन-सी हैं, असिस्टेंट ने यह तय करने के लिए क्या-क्या पढ़ा, और क्या वह बिलिंग कोड के आसपास भी गया। एक सामान्य चैट विंडो उसे बस आख़िरी पैराग्राफ़ देती है, और कुछ नहीं।

एक पैराग्राफ़ में Maestro

Maestro, osFoundry डेस्कटॉप ऐप का फ़ुल-पावर AI वर्कस्पेस है। आप अपनी रिक्वेस्ट वैसे ही टाइप करते हैं जैसे किसी भी चैट में, लेकिन जवाब के साथ उसका पूरा वर्क पाथ आता है: हर फ़ाइल जिसे उसने लिस्ट किया, हर सर्च जो उसने चलाई, हर फ़ाइल जिसे पढ़ा या एडिट किया, और हर टर्मिनल कमांड, हर एक अपनी अलग row में, साथ में अवधि, जिसे आप खोलकर देख सकते हैं। यह आपके कंप्यूटर के किसी फ़ोल्डर के अंदर काम कर सकता है, चुपचाप लिखने के बजाय एडिट प्रस्तावित कर सकता है, और कुछ भी छूने से पहले रुककर आपको प्लान दिखा सकता है। यह साइडबार में Maestro के नाम से मिलता है। अगर आपने ब्राउज़र में ChatGPT या Claude इस्तेमाल किया है, तो वही बातचीत सोचिए, बस बगल में एजेंट का एक्टिविटी लॉग और कुछ ब्रेक जुड़े हुए।

स्क्रीन पर एक नज़र

सबसे ऊपर सरफ़ेस टैब। Maestro, Model chat, Multi chat, Research, Wiki और Code सब इसी एक स्क्रीन पर हैं। Maestro वह टैब है जिसमें पूरा टूलसेट मिलता है।
बातचीत के ऊपर डिटेल टैब: Chat, Sources, Files, Changelog, Tools, Pipeline और Logs। ये एक ही रन के अलग-अलग व्यू हैं। Sources में रहता है कि जवाब किस आधार पर दिया गया, Changelog उन फ़ाइलों की लिस्ट है जो इस चैट ने लिखीं, और Logs में स्टेप्स दिखते हैं, और Costs के नीचे हर रिक्वेस्ट की लागत।
ट्रांसक्रिप्ट में प्रोसेस rows। यहाँ Maestro ने src/ लिस्ट किया (38 फ़ाइलें), deleteUser के लिए grep किया, 0 मैच मिले, फिर account.ts और users.ts पढ़ीं। किसी row पर क्लिक करें तो वह खुलकर उस टूल कॉल का सटीक इनपुट और आउटपुट दिखाती है।
मैसेज बॉक्स के ऊपर कंट्रोल स्ट्रिप: sandbox स्विच, Plan OFF/ON, Tools और Goal। बॉक्स के नीचे फ़ोल्डर, प्रोजेक्ट, repo, Router और मॉडल के पिकर हैं।
दाईं ओर प्रीव्यू पैनल, जहाँ कोई फ़ाइल, diff या वेब पेज बातचीत को हटाए बिना उसके बगल में खुलता है (Open File / App / Page, Browse Files, Browser)।

लोग इसे तीन तरह से इस्तेमाल करते हैं

एक सोलो डेवलपर जिसे एडिट से पहले प्लान चाहिए

शुरुआत वाला प्रिया का केस। बदलाव अकाउंट और सेशन से जुड़ा है, इसलिए वह किसी अचानक आए diff को रिव्यू करने के बजाय पहले प्लान पढ़ना चाहती है।

वह कंट्रोल स्ट्रिप में Plan पर क्लिक करती है ताकि Plan ON दिखे।
वह "Add a Delete account button to settings" टाइप करके भेज देती है।
Maestro छह फ़ाइलें पढ़ता है और एक भी नहीं बदलता। जब तक plan mode चालू है, डेस्कटॉप ऐप ख़ुद ऐसे किसी भी टूल को मना कर देता है जो फ़ाइल लिखे या कमांड चलाए, यानी "सिर्फ़ पढ़ना" प्रॉम्प्ट में की गई कोई विनम्र गुज़ारिश नहीं है।
"Awaiting approval" लिखा एक Plan कार्ड आता है, जिसमें Approve और Cancel बटन होते हैं।

उदाहरण वाला प्लान चार फ़ाइलों के नाम बताता है, कहता है कि src/billing/ को नहीं छुआ जाएगा क्योंकि Stripe अपने रिकॉर्ड ख़ुद रखता है, और आख़िर में लिखता है "Nothing has been changed yet." प्लान आते ही plan mode अपने-आप बंद हो जाता है। प्रिया Approve पर क्लिक करती है, और तभी जाकर Maestro चारों फ़ाइलें एडिट करता है और टेस्ट चलाता है (npm test -- account, 3 passed), सब कुछ EDIT और TERMINAL rows के रूप में दिखता है। अगर उसे प्लान पसंद न आता, तो Cancel फ़ोल्डर को बिल्कुल वैसा ही छोड़ देता जैसा वह था।

उसके हाथ में क्या आता है: एक बदलाव जिसे उसने पहले से मंज़ूरी दी, और एक ट्रांसक्रिप्ट जो दिखाता है कि एजेंट ने कहाँ देखा और क्या चलाया।

एक नया टीममेट जो कोडबेस में रास्ता ढूँढ रहा है

डैन सोमवार को टीम में आया है। उसे पता करना है कि लॉगिन लॉकआउट का कोड कहाँ है, लेकिन कोड में कोई उसे "lockout" नहीं कहता, इसलिए टेक्स्ट सर्च से कुछ नहीं मिलता।

Indexes में वह प्रोजेक्ट फ़ोल्डर को एक बार जोड़ता है ताकि उसे मतलब के आधार पर सर्च किया जा सके।
उस फ़ोल्डर पर Maestro चैट में वह पूछता है कि लॉगिन फ़ेल होने के बाद ऐप लोगों को कहाँ लॉक आउट करता है।
वह प्रोसेस rows देखता है: एक फ़ोल्डर सर्च जिसके 2 नतीजे आते हैं, फिर throttle.ts का READ।

जवाब src/auth/throttle.ts (लाइन 1–46) और src/routes/session.ts (लाइन 22–61) की ओर इशारा करता है, और समझाता है कि कोड कहीं "lock out" नहीं कहता: पाँच असफल कोशिशों के बाद वह 15 मिनट आगे का cooldown सेट करता है और पासवर्ड चेक करने से पहले ही 429 लौटा देता है। क्योंकि जवाब में फ़ाइल पाथ हैं और rows दिखाती हैं कि क्या पढ़ा गया, डैन वही लाइनें प्रीव्यू पैनल में खोलकर ख़ुद दावे की जाँच कर सकता है, किसी सारांश पर भरोसा करने के बजाय। इस केस में डिस्क पर कुछ नहीं लिखा जाता, इसलिए वह Approval Mode को डिफ़ॉल्ट पर छोड़ सकता है।

उसके हाथ में क्या आता है: वे दो फ़ाइलें जो मायने रखती हैं, यह वजह कि कीवर्ड सर्च उन्हें क्यों नहीं पकड़ पाई, और एक चैट जिस पर वह चैट लिस्ट से वापस आ सकता है।

एक मार्केटर जो किसी और के repo में कॉपी एडिट कर रही है

सैमी लॉन्च पेज की कॉपी लिखती है, लेकिन वह पेज इंजीनियरिंग repo की एक React फ़ाइल है। वह चाहती है कि नया टेक्स्ट docs/ में रखी टोन गाइड से मेल खाए, और बिना देखे कुछ भी commit न हो।

वह composer का Approval Mode मेन्यू खोलकर Permission & Approve चुनती है, जो टूल कॉल से पहले पूछता है। बाक़ी विकल्प हैं Auto Accept (डिफ़ॉल्ट, टूल तुरंत चलते हैं), Plan First (चलाने से पहले प्लान) और Bypass (कोई अप्रूवल नहीं, push और फ़ॉर्म सबमिट के लिए भी नहीं)।
वह sandbox चालू करती है, ताकि लिखी गई चीज़ें वर्किंग फ़ोल्डर में सीधे पहुँचने के बजाय एक branch पर stage हों।
वह Maestro से लॉन्च पेज का ड्राफ़्ट माँगती है जो docs के साथ मेल खाए। वह docs/tone.md पढ़ता है, सोर्स में सर्च करता है, और src/Launch.tsx में एक एडिट प्रस्तावित करता है।
diff प्रीव्यू पैनल में खुलता है। वह उसे स्वीकार करती है, फिर Export to branch इस्तेमाल करती है ताकि कोई इंजीनियर उसे किसी भी दूसरे बदलाव की तरह रिव्यू कर सके।

उसके हाथ में क्या आता है: ऐसी कॉपी जो उस टोन गाइड का हवाला देती है जिसे उसने फ़ॉलो किया (Sources टैब उसे संभालकर रखता है), एक रिव्यू किया हुआ diff, और main पर किसी सरप्राइज़ के बजाय एक branch।

Model chat, Chat और Multi chat के बीच Maestro की जगह

Maestro अपनी स्क्रीन कुछ सरल भाई-बहनों के साथ साझा करता है, और सही वाला चुनने से समय और पैसा दोनों बचते हैं।

Model chat इसी स्क्रीन का एक टैब है जो हर टर्न आपके चुने एक मॉडल को भेजता है। यह read-only बातचीत है: न फ़ोल्डर, न कुछ करने वाले टूल, न अप्रूवल। जल्दी के किसी सवाल के लिए बढ़िया।
Chat की साइडबार में अपनी जगह है। यह भी पूरी बातचीत के लिए आपके चुने एक मॉडल से जवाब देता है, लेकिन फ़ाइलों वाली क्षमताएँ बनाए रखता है, यानी यह ऐसा एडिट प्रस्तावित कर सकता है जिसे आप Accept या Reject करें, और वह Changelog में दर्ज होता है। इसे तब इस्तेमाल करें जब आप चाहते हों कि कोई ख़ास मॉडल काम करे, बिना किसी router के आपके लिए चुने।
Multi chat एक ही सवाल एक साथ कई मॉडलों से पूछता है। Compare में आप जवाब साथ-साथ पढ़ते हैं; Council में मॉडल जवाब देते हैं, एक-दूसरे के जवाबों को बिना नाम जाने रैंक करते हैं, और एक मॉडल सिंथेसिस लिखता है।

Maestro से काम अक्सर ऐप के दूसरे हिस्सों में आगे बढ़ता है। Research एक सवाल को स्रोतों वाली रिपोर्ट में बदलता है, Code अपनी branch पर एक कोडिंग एजेंट चलाता है, Indexes किसी फ़ोल्डर को मतलब के आधार पर सर्च करने लायक बनाता है (जैसे डैन के केस में), और Version → Merge Station वह जगह है जहाँ sandbox वाले बदलाव merge होते हैं। अगर कोई टर्न गड़बड़ हो जाए, तो चैट में /rewind टाइप करने से उस टर्न में बदली गई फ़ाइलें वापस आ जाती हैं। गहराई से समझने के लिए, Maestro orchestration पेज डिटेल टैब्स के बारे में बताता है, और plan mode पेज अप्रूवल फ़्लो समझाता है।

लोग सबसे पहले क्या पूछते हैं

क्या plan mode बस प्रॉम्प्ट में लिखा एक निर्देश है?
नहीं। जब तक Plan ON है, हर वह टूल जो read-only लिस्ट में नहीं है, ऐप द्वारा डिस्पैच किए जाते समय ही मना कर दिया जाता है। यानी एजेंट पढ़ सकता है, सर्च कर सकता है और ब्राउज़ कर सकता है, लेकिन जब तक आप प्लान को अप्रूव न करें, वह एडिट या कमांड नहीं चला सकता।

Plan स्विच और Approval Mode के Plan First में क्या फ़र्क है?
Plan अगली रिक्वेस्ट के लिए एक बार का स्विच है: जाँच करो, प्लान दिखाओ, इंतज़ार करो। Approval Mode टूल कॉल के लिए चैट का स्थायी नियम है, Auto Accept से लेकर Bypass तक। Plan First उसकी चार सेटिंग्स में से एक है।

प्रोसेस rows बहुत ज़्यादा हैं। क्या मैं इन्हें छिपा सकता हूँ?
हाँ। Process Detail सेटिंग Full और Compact के बीच बदलती है। यह सिर्फ़ स्टेप्स के दिखने का तरीक़ा बदलती है, टर्न के चलने का तरीक़ा नहीं।

Maestro कौन-सा मॉडल इस्तेमाल करता है?
डिफ़ॉल्ट रूप से Router हर टर्न के लिए एक मॉडल चुनता है, और प्रोसेस rows दिखाती हैं कि कौन-सा चला। आप composer से मॉडल मोड (क्लाउड, लोकल या सेल्फ़-होस्टेड) बदल सकते हैं, या पूरी बातचीत के लिए एक ही मॉडल तय रखना हो तो Chat इस्तेमाल कर सकते हैं।

डेस्कटॉप ऐप आप osfoundry.io/hi/download से ले सकते हैं।

osFoundry का Local Model कैसे काम करता है, ओपन मॉडल चुनने से लेकर अपनी मशीन पर उसे ट्यून करने तक

tauchiii — Fri, 06 Nov 2026 17:02:59 +0000

गुरुवार शाम के 4:40 बजे हैं और एक विंडो में कॉन्ट्रैक्ट का ड्राफ्ट खुला है। आप चाहते हैं कि कोई AI उसकी भाषा कसकर ठीक कर दे, लेकिन यह डॉक्यूमेंट आपके लैपटॉप से बाहर नहीं जा सकता, और आपको यह भी पक्का नहीं पता कि Hugging Face के सैकड़ों ओपन मॉडल में से कौन-सा 16 GB मेमोरी पर लोड भी होगा। यह पता लगाने के लिए पूरी शाम टर्मिनल में बिताने का मन भी नहीं है।

ओपन मॉडल से जुड़े हर काम के लिए साइडबार में एक ही ग्रुप

Local Model, osFoundry का वह हिस्सा है जो आपके अपने कंट्रोल वाले हार्डवेयर पर चलने वाले open-weight मॉडल संभालता है। डेस्कटॉप ऐप के साइडबार में यह एक अलग कैटेगरी है, जिसमें तीन सब-हेडिंग हैं: Run (Explore, Providers, Servers, Playground, Deployments, Cloud GPU, GPU Endpoints), Build (My Models, Datasets, Training, Quantize, Notebooks) और Measure (Eval, Benchmarks, Safety)। अगर आपने Ollama या LM Studio इस्तेमाल किया है, तो Run वाला हिस्सा जाना-पहचाना लगेगा: मॉडल ढूंढो, डाउनलोड करो, उससे बात करो। फर्क यह है कि इसी ग्रुप में आप मॉडल को छोटा भी कर सकते हैं, अपने उदाहरणों पर fine-tune कर सकते हैं और अपने सवालों से टेस्ट भी कर सकते हैं, यानी मॉडल का पूरा सफर एक ही ऐप में रहता है। डिवाइस पर inference के लिए साथ में आया llama.cpp सर्वर इस्तेमाल होता है, इसलिए अलग से कुछ इंस्टॉल नहीं करना पड़ता। यह गाइड उन नौ स्क्रीन को कवर करती है जिन्हें ज़्यादातर लोग इस्तेमाल करते हैं: Explore, Servers, Playground, My Models, Datasets, Training, Quantize, Eval और Benchmarks।

Explore पर पहली नज़र

ज़्यादातर लोग Explore से शुरू करते हैं, और इसका लेआउट दिखाता है कि पूरी कैटेगरी किस तरह सोचती है: पहले आपकी मशीन, फिर मॉडल।

बाईं ओर का Filters पैनल Hugging Face के टास्क (Text Generation, Summarization, Translation, Embeddings, साथ में Multimodal, Vision और Audio ग्रुप) को समूहों में दिखाता है और इसमें एक सर्च बॉक्स भी है।
ऊपर का बैनर कुछ भी दिखाने से पहले आपकी मशीन को पढ़ता है। ऊपर के उदाहरण में यह बताता है: 16 GB unified memory, मॉडल के लिए लगभग 12 GB इस्तेमाल लायक, इस वक्त लगभग 9 GB खाली, और यह कि अनुमान Q4_K_M और 4K context मानकर लगाए गए हैं।
हर मॉडल कार्ड पर फिट का बैज होता है: हरा Fits, पीला Tight, लाल Too big, हर एक के साथ अनुमानित मेमोरी। कुछ भी छिपाया नहीं जाता; जो मॉडल फिट होते हैं, वे बस पहले दिखते हैं।
ऊपर दाईं ओर के Providers और My Registry बटन क्लाउड API वेंडर्स और आपके पास पहले से मौजूद मॉडल्स पर ले जाते हैं।
किसी कार्ड पर क्लिक करने से उसका डिटेल खुलता है, जहां Install Locally मॉडल का एक वर्ज़न डाउनलोड करता है, आमतौर पर बैज से मेल खाता quantized GGUF।

तीन लोग, इस्तेमाल के तीन तरीके

एक लैपटॉप वाली सोलो डेवलपर

Maya 16 GB वाले MacBook पर साइड प्रोजेक्ट बनाती है। उसे commit मैसेज और छोटे नोट्स लिखने के लिए एक लोकल मॉडल चाहिए, ज़्यादातर इसलिए कि ट्रेन में ऑफलाइन काम कर सके।

वह Explore खोलती है, Text Generation पर फ़िल्टर करती है और लाल बैज वाले सब मॉडल छोड़ देती है। दो कैंडिडेट हरे दिखते हैं, तो वह Install Locally से दोनों इंस्टॉल कर लेती है। फिर Playground खोलकर एक prompt लिखती है और दोनों मॉडल को पैनल के रूप में जोड़ती है। Playground एक ही prompt दो से चार मॉडल को एक साथ भेजता है और जवाब अगल-बगल दिखाता है, हर पैनल के नीचे पहले टोकन तक का समय और शब्दों की गिनती के साथ।

बाद में उसे एक मॉडल पसंद आता है जो सिर्फ फुल-प्रिसिज़न F16 फ़ाइल के रूप में उपलब्ध है। यह लगभग 15 GB का है, उसके लैपटॉप के लिए बहुत बड़ा। Quantize में वह इसे "The model to shrink" में चुनती है, Q4_K_M चुनती है, जो ऐप ज़्यादातर लोगों के लिए सुझाता है, और शुरू कर देती है। साथ में आया llama-quantize फ़ाइल को उसकी मशीन पर ही दोबारा लिखता है; कुछ भी अपलोड नहीं होता।

ऊपर के उदाहरण में नतीजा 4.58 GiB है, मूल फ़ाइल से 3.3 गुना छोटा। भरोसा करने से पहले वह Measure quality पर क्लिक करती है, जो नई फ़ाइल की तुलना मूल फ़ाइल से करके Compare टेबल में "same top token" और औसत KLD कॉलम भरता है, फिर tokens per second के लिए Measure speed। Try it in Playground पर एक क्लिक इसे बाकी दोनों के बगल में वापस रख देता है। शाम खत्म होने तक उसके पास एक फिट होने वाला मॉडल है, यह दिखाने वाले आंकड़े कि छोटा करने की कीमत क्या रही, और टर्मिनल हिस्ट्री बिल्कुल नहीं।

एक दमदार डेस्कटॉप वाली छोटी टीम

चार लोगों की एक एजेंसी के ऑफिस में ढेर सारी मेमोरी वाला एक डेस्कटॉप और कई पतले लैपटॉप हैं। बड़े मॉडल सिर्फ डेस्कटॉप पर फिट होते हैं, लेकिन इस्तेमाल सब करना चाहते हैं।

डेस्कटॉप पर कोई Servers खोलता है, This Mac चुनता है और उसके Access टैब पर जाता है। वह "Allow access from other devices on the local network (LAN)" पर टिक करता है और Remote Access चालू करता है। इसके बाद पैनल उन सभी लोकल मॉडल की लिस्ट दिखाता है जिन्हें मशीन सर्व करेगी। Device keys में वह New key पर क्लिक करता है, उसे किसी साथी के लैपटॉप का नाम देता है और Create key दबाता है; हर key को अलग से revoke किया जा सकता है, और सिर्फ inference वाली key मॉडल चला सकती है लेकिन agent sessions तक नहीं पहुंच सकती।

हर लैपटॉप पर साथी Servers खोलता है, Add Server पर क्लिक करता है, डेस्कटॉप का पता डालता है, key पेस्ट करता है और Test Connection इस्तेमाल करता है। कनेक्ट होते ही डेस्कटॉप के मॉडल लैपटॉप के मॉडल पिकर में बाकी मॉडल की तरह दिखने लगते हैं। ऐप खुद बताता है कि यह ट्रैफ़िक सादा HTTP है, इसलिए यह भरोसेमंद नेटवर्क, जैसे ऑफिस LAN, के लिए है।

फिर कोई Benchmarks खोलता है, New Benchmark पर क्लिक करता है, मॉडल चुनता है और Quick suite रहने देता है। रन tokens per second, पहले टोकन तक का समय और latency रिकॉर्ड करता है, ताकि टीम समझ सके कि शेयर किया गया मॉडल कॉल के दौरान इस्तेमाल के लायक तेज़ है या सिर्फ रात के batch जॉब के लिए। अगर धीमा लगे, तो Servers में एक Config टैब भी है, जहां Speculative Decoding में एक छोटा draft मॉडल सेट किया जा सकता है, फिर Restart now, और तुलना के लिए benchmark दोबारा चलाया जा सकता है।

आखिर में टीम के पास भारी काम करने वाली एक मशीन है, हर लैपटॉप के लिए एक key जिसे बाकियों को परेशान किए बिना वापस लिया जा सकता है, और "क्या यह काफी तेज़ है" का मापा हुआ जवाब।

कोड न लिखने वाले एक ऑपरेशंस लीड

Ken एक छोटी ऑनलाइन दुकान का कस्टमर सपोर्ट संभालता है। उसके दो सवाल हैं: कौन-सा मॉडल इनवॉइस का टोटल सही पढ़ता है, और क्या कोई मॉडल दुकान के अपने अंदाज़ में जवाब देना सीख सकता है?

पहले सवाल के लिए वह Eval में जाकर Custom Benchmark पर क्लिक करता है। नाम देता है, दस इनवॉइस पेस्ट करता है और हर एक का अपेक्षित टोटल लिखता है, Exact Match रहने देता है और Create Benchmark पर क्लिक करता है। फिर New Eval Run: वह अपने कंप्यूटर के दो मॉडल पर टिक करता है, अपने benchmark पर टिक करता है और Start Evaluation पर क्लिक करता है। सवाल उसकी अपनी मशीन पर हर मॉडल को जाते हैं।

इस उदाहरण में एक मॉडल को 90 और दूसरे को 70 मिलते हैं, और Diff कॉलम 20 पॉइंट का फर्क दिखाता है। यह उसके अपने डॉक्यूमेंट्स पर आया नतीजा है, किसी और का leaderboard नहीं।

अंदाज़ वाले सवाल के लिए वह ग्राहकों के कुछ सौ पुराने मैसेज और उन पर टीम के असल में भेजे गए जवाब इकट्ठा करता है, हर लाइन में एक जोड़ी। Datasets में वह यह फ़ाइल ला सकता है, या Hub टैब से पब्लिक डेटा ढूंढ सकता है, और "Use for Training" से उसे आगे भेज सकता है। Training में वह New Job पर क्लिक करता है और चार स्टेप पूरे करता है: Base Model, Dataset, Config और Review। Training Target में वह Local (This Device) चुनता है, जिसे स्क्रीन डिवाइस के GPU पर चलने वाला और मुफ़्त बताती है, और तरीका LoRA।

Start Training के बाद जॉब चलते-चलते अपना loss दिखाता है। पूरा होने पर ट्रेन किया गया adapter My Models में उस base मॉडल के बगल में दिखता है जिससे वह बना है, और पूरे हुए रन पर "Chat with your model" उसे डिवाइस वाले runtime के लिए तैयार करता है, ताकि वह Playground में उससे कुछ पूछ सके। आखिर में उसके पास एक छोटा, प्राइवेट मॉडल है और एक benchmark जिसे वह हर नए मॉडल पर विचार करते समय दोबारा चला सकता है।

Local Model आगे काम कहां सौंपता है

यह कैटेगरी अकेले नहीं चलती। जो मॉडल आप इंस्टॉल या कनेक्ट करते हैं, वे उसी मॉडल लिस्ट में दिखते हैं जिसे चैट इस्तेमाल करता है, इसलिए लोकल मॉडल सामान्य बातचीत का जवाब दे सकता है या Playground में उस क्लाउड मॉडल से तुलना में रखा जा सकता है जिसे आपने Providers में जोड़ा है। Explore से "Use in Notebook" उस मॉडल के लिए सेट किया हुआ JupyterLab notebook खोलता है, लोकल या किसी hosted instance पर। जब मॉडल को लैपटॉप की जगह असली GPU चाहिए, तो Deployments और Cloud GPU काम संभालते हैं और उसे managed endpoint पर रखते हैं। किसी मॉडल के ग्राहकों तक पहुंचने से पहले Safety, deploy किए गए मॉडल पर red-team टेस्ट suites चलाता है। लोकल inference पेज डिवाइस वाले इंजन को और विस्तार से बताता है, और LoRA fine-tuning पेज ट्रेनिंग वाले हिस्से को।

लोग सबसे पहले क्या पूछते हैं

क्या मुझे GPU या गेमिंग PC चाहिए?
नहीं। छोटे और मध्यम आकार के मॉडल के लिए हाल का कोई लैपटॉप काफी है; Explore के फिट बैज डाउनलोड से पहले ही बता देते हैं कि आपकी मशीन क्या संभाल सकती है। ज़्यादा ताकतवर डेस्कटॉप या रिमोट सर्वर बस लिस्ट को लंबा कर देता है।

क्या कुछ क्लाउड पर भेजा जाता है?
लोकल inference, Quantize और लोकल ट्रेनिंग आपकी मशीन पर चलते हैं। Cloud GPU ट्रेनिंग, Cloud GPU endpoints और Providers वे हिस्से हैं जो बाहरी सेवाएं इस्तेमाल करते हैं, और स्क्रीन पर इन पर लेबल होता है, जैसे ट्रेनिंग डायलॉग में "Managed cloud GPU · needs credits"।

Eval और Benchmarks में क्या फर्क है?
Eval आपके तय किए सवालों पर जवाबों की क्वालिटी को स्कोर करता है। Benchmarks स्पीड और मेमोरी मापता है: tokens per second, पहले टोकन तक का समय और latency।

ऐप कहां से मिलेगा?
Local Model डेस्कटॉप ऐप में चलता है, जिसे आप osfoundry.io/hi/download से ले सकते हैं।

osFoundry के Code, IDE और Wiki कई AI एजेंट्स के साथ-साथ चल रहे कोडिंग काम को रिव्यू करने लायक कैसे रखते हैं

tauchiii — Fri, 06 Nov 2026 15:46:14 +0000

शाम के 4 बजे हैं और लंच के बाद से तीन कोडिंग एजेंट एक ही repository पर काम कर रहे हैं। एक ने कार्ट टोटल की राउंडिंग ठीक की, दूसरे ने डिस्काउंट कोड जोड़ा, तीसरे ने tests लिखे। तीनों कह रहे हैं "done"। main में कुछ भी जाने से पहले आप दो बातें जानना चाहते हैं: क्या दो एजेंट्स ने एक ही function दोबारा लिख दिया, और क्या तीनों बदलाव साथ मिलाने पर भी tests पास करते हैं?

एक codebase के लिए तीन स्क्रीन

osFoundry एक डेस्कटॉप ऐप है जो चैट, एजेंट्स, फ़ाइलें और टूल्स एक ही विंडो में रखता है, और कोड के लिए इसमें तीन जुड़ी हुई स्क्रीन हैं। Code वह जगह है जहाँ आप एक साथ कई एजेंट्स को काम सौंपते हैं: हर run को अपनी Git branch और अपना working folder (एक worktree) मिलता है, और कोई भी फ़ैसला लेने से पहले आप रिव्यू करते हैं, टेस्ट करते हैं और merge का preview देखते हैं। कुछ भी अपने-आप merge नहीं होता। IDE किसी लोकल फ़ोल्डर के लिए कोड एडिटर है, जिसमें explorer, source control, terminal, problems और tests पैनल हैं, और एक assistant कॉलम है जो देखता है कि आप कौन-सी फ़ाइल में हैं। Wiki आपकी मशीन पर मौजूद repository पढ़ता है और ऐसे documentation पेज लिखता है जो path:line का हवाला देते हैं, और जब उस हवाले वाला कोड बदलता है तो पेज को मार्क कर देता है। Code और Wiki, Maestro, Model chat, Multi chat और Research के बगल में टैब के रूप में हैं; IDE का साइडबार में अपना अलग आइटम है। अगर आप Git पैनल वाले VS Code से परिचित हैं, तो IDE जाना-पहचाना लगेगा। Code किसी pull-request inbox जैसा ज़्यादा है, फ़र्क़ बस इतना है कि लेखक आपके एजेंट्स हैं और branches कभी आपके लैपटॉप से बाहर नहीं गईं।

Code टैब पर एक नज़र

इस स्क्रीन पर आप क्या देखते हैं (runs उदाहरण डेटा हैं):

रेल के ऊपर का बैनर। "3 agents finished · they disagree on 1 file" एक भी diff खोलने से पहले फ़ाइल का नाम बता देता है, यहाँ src/cart.js। Review together बटन एक साझा रिव्यू शुरू करता है।
run रेल। runs इस हिसाब से ग्रुप किए गए हैं कि उन्हें आपसे क्या चाहिए: Ready to review, Needs attention, और एक मुड़ा हुआ History। हर लाइन में टास्क, जोड़ी और हटाई गई लाइनें, एजेंट ने कितनी देर काम किया, और उसकी branch दिखती है।
बीच में बातचीत। किसी run पर क्लिक करें और पढ़ें कि एजेंट से क्या कहा गया था और काम करते समय उसने क्या कहा।
दायाँ पैनल। Changes, Files, Commits, Review और PR टैब हर run का असली diff दिखाते हैं, पहले uncommitted काम, फिर वह जो उसकी branch पर commit हुआ।
नीचे दाईं ओर Merge station। पूरे हो चुके runs चुनें, और यहीं आप उन्हें टेस्ट करते हैं और उन्हें एक साथ merge करने का preview देखते हैं।

उपयोग का उदाहरण: एक repo पर तीन एजेंट्स के साथ एक tech lead

Dana एक छोटी वेब टीम लीड करती हैं और checkout sprint को तीन एजेंट runs में बाँटती हैं: कार्ट टोटल में राउंडिंग ठीक करना, checkout में डिस्काउंट कोड जोड़ना, और price formatter के लिए tests लिखना। हर run New run से एक लाइन के टास्क और उसके लिए चुने गए एजेंट के साथ शुरू हुआ, इसलिए हर एक की अपनी branch और फ़ोल्डर है और काम करते समय कोई भी दूसरों की फ़ाइलों से नहीं टकरा सकता।

जब बैनर कहता है कि वे असहमत हैं, तो वह तीनों runs पर टिक करती हैं और Review together पर क्लिक करती हैं। Merge पैनल पर लिखा आता है "3 runs · conflicts not checked yet · 3 not yet tested", जो हरी झंडी के बजाय एक ईमानदार "अभी हमें नहीं पता" है। उसके नीचे src/cart.js को contested टैग किया गया है, और हर branch के hunks आमने-सामने दिखाए गए हैं: राउंडिंग फ़िक्स और डिस्काउंट कोड, दोनों ने total() को दोबारा लिखा था।

फिर वह हर run पर test दबाती हैं। tests उसी run के अपने worktree के अंदर चलते हैं, इसलिए उनका अपना checkout कभी छुआ नहीं जाता। डिफ़ॉल्ट रूप से "Tests must pass before a branch can merge", और यह नियम Settings में बदला जा सकता है। तीनों पास हो जाते हैं, लेकिन अलग-अलग पास होना साथ में पास होने जैसा नहीं है, इसलिए वह Preview combined merge दबाती हैं। ऐप पहले branches को एक अस्थायी कॉपी में merge करता है और नतीजा बताता है: दो साफ़ merge होती हैं, एक में conflict है।

वह दोनों साफ़ branches को अपनी current branch में merge करती हैं। सिर्फ़ उसी पल उनकी branch बदलती है। डिस्काउंट कोड वाली branch वैसी ही रहती है, ताकि एजेंट राउंडिंग फ़िक्स के ऊपर अपना बदलाव दोबारा कर सके। अगर वह पूरी branches के बजाय हर कोशिश का सबसे अच्छा हिस्सा चाहतीं, तो Combine into a branch से अलग-अलग hunks टिक करके उनसे नई branch बना सकती थीं।

लंबे दिनों में काम आने वाली एक और बात: अगर कोई run काम कर रहा हो और ऐप बंद हो जाए, तो वह run "running" के बजाय Interrupted के रूप में वापस आता है, इस नोट के साथ कि उसकी branch सुरक्षित रखी गई है।

उपयोग का उदाहरण: assistant के साथ refactor करता एक अकेला डेवलपर

Kenji अकेले एक शॉप का front end संभालते हैं। आज सुबह उन्हें formatPrice बदलना है, और उन्हें पक्का नहीं पता कि इसे कौन-कौन call करता है। वह साइडबार से प्रोजेक्ट फ़ोल्डर IDE में खोलते हैं। एडिटर का लेआउट वही जाना-पहचाना है: बाईं ओर Explorer और Source Control, बीच में टैब, नीचे Terminal, Output, Problems और Tests, और दाईं ओर Assistant, जहाँ वह synced चैट या डिवाइस पर ही रहने वाली local चैट शुरू कर सकते हैं।

वह formatPrice पर राइट-क्लिक करके Show Code Graph चुनते हैं। पैनल में Callers और Calls की लिस्ट आती है। भरा हुआ डॉट मतलब call सीधे कोड से पढ़ी गई; खाली डॉट मतलब उसका अनुमान लगाया गया, इसलिए उसे हाथ से एक बार देख लेना चाहिए। Impact of change callers के भी callers तक जाता है और इस उदाहरण में दिखाता है "15 symbols · 14 files · 3 tests"। किसी लाइन पर क्लिक करने से उसी जगह पहुँच जाते हैं, और Send to chat पूरा graph context के रूप में assistant को दे देता है।

बाद में assistant उनके लिए एक config फ़ाइल एडिट करता है। Source Control में फ़ाइल modified दिखती है, और खोलने पर एक छोटा रोबोट निशान और status line बताते हैं कि इसे आख़िरी बार AI ने लिखा था, मॉडल और उसके बताए कारण के साथ। Review उस write से ठीक पहले सेव की गई कॉपी के मुक़ाबले side-by-side diff खोलता है, इसलिए उन्हें सिर्फ़ वही बदलाव दिखता है। यहाँ दिखता है कि timeout 30 सेकंड से घटाकर 3 कर दिया गया, ठीक उस comment के नीचे जिसमें लिखा है कि बड़े uploads में 20 सेकंड या उससे ज़्यादा लगते हैं। वह commit से पहले ही इसे पकड़ लेते हैं।

अगर कोई एजेंट किसी ऐसी फ़ाइल में लिखता है जिसमें उनके बिना सेव किए बदलाव अभी बाकी हैं, तो एडिटर बताता है कि एडिट करते समय फ़ाइल डिस्क पर बदल गई, और चुपचाप किसी एक को चुनने के बजाय Keep mine या Use the disk version का विकल्प देता है।

उपयोग का उदाहरण: एक सपोर्ट इंजीनियर जिसे कोड बदलना नहीं, समझना है

Priya कस्टमर सपोर्ट में काम करती हैं और उनसे अक्सर पूछा जाता है कि प्रोडक्ट का कोई हिस्सा कैसे काम करता है। वह कोड पढ़ लेती हैं, लेकिन किसी और के repository में grep करते हुए भटकना नहीं चाहतीं। Wiki में वह Open a folder (या https या git@ URL के साथ Clone a public repository) इस्तेमाल करती हैं, और ऐप उनकी मशीन पर प्रोजेक्ट का स्ट्रक्चर पढ़ता है।

प्रोजेक्ट में कुछ भी लिखने से पहले Wiki पूछता है। एक dialog ठीक-ठीक बताता है कि repo के अंदर कौन-सा फ़ोल्डर बनाया जाएगा, और अगर वह Not now पर क्लिक करती हैं, तो कुछ नहीं लिखा जाता। हाँ कहने के बाद वह Generate pages या किसी एक विषय के लिए Write a page इस्तेमाल करती हैं। Settings तय करती हैं कि हर पेज कितने source code से लिखा जाए (Depth: Quick, Standard या Deep) और कितने दावों की जाँच हो (Verification: Off, Sample या Full, जिसमें Full से ख़र्च लगभग दोगुना हो जाता है)। पेज बनने से पहले ख़र्च दिखा दिया जाता है।

हर पेज path:line का हवाला देता है, और किसी हवाले पर क्लिक करने से वह लाइन IDE में खुल जाती है। एक महीने बाद रेल में एक पेज पर निशान लगा होता है, क्योंकि "a file this page cites has changed since it was written", यानी उस पर भरोसा करने से पहले उसे दोबारा बनाना चाहिए। किसी छोटे, एक बार के सवाल के लिए वह पेजों के बगल वाली चैट इस्तेमाल करती हैं, जिसके जवाब भी उसी प्रोजेक्ट से path:line का हवाला देते हैं, और जहाँ वह सीधे शब्दों में नया पेज भी माँग सकती हैं, जैसे "write a page about the retry policy"। पेज ख़ुद repository में markdown फ़ाइलें हैं, इसलिए टीम उन्हें कोड वाले pull requests में ही रिव्यू कर सकती है।

Code, IDE और Wiki काम एक-दूसरे को कहाँ सौंपते हैं

ये तीनों स्क्रीन एक-दूसरे को और ऐप के बाकी हिस्सों को काम आगे बढ़ाती हैं। Wiki का कोई हवाला IDE को उसी लाइन पर खोलता है, और उल्टी दिशा के लिए IDE में Wiki for this folder बटन है। IDE का Assistant और Wiki पेजों के बगल वाली चैट Maestro पर बने हैं, वही assistant जिसे आप osFoundry में बाकी जगह इस्तेमाल करते हैं, इसलिए वहाँ सवाल पूछना किसी भी Maestro चैट की तरह ही काम करता है। किसी codebase में सटीक शब्दों के बजाय मतलब से खोजने के लिए Indexes एक लोकल search index बनाता है जिसे Maestro इस्तेमाल कर सकता है। और जब कोई Code run आपके लैपटॉप से बाहर जाने के लिए तैयार हो, तो Open PR उसकी branch के लिए pull request खोल देता है।

प्रोडक्ट पेजों पर दोनों के interactive demo हैं: Code और IDE।

लोग सबसे पहले क्या पूछते हैं

क्या मुझे डेस्कटॉप ऐप चाहिए?
हाँ। Code, IDE और Wiki लोकल फ़ोल्डरों, Git worktrees, एक shell और language servers पर काम करते हैं, इसलिए ये osFoundry डेस्कटॉप ऐप में चलते हैं।

क्या कोई एजेंट कभी अपने-आप मेरी branch में merge कर देगा?
नहीं। runs अपनी-अपनी branches पर, अपने-अपने फ़ोल्डरों में काम करते हैं। आपकी current branch तभी बदलती है जब आप merge दबाते हैं, और डिफ़ॉल्ट रूप से सिर्फ़ उन्हीं branches के लिए जिनके tests पास हुए हों।

क्या Wiki, Notion जैसी टीम wiki है?
नहीं। यह code repository से documentation लिखता है, फ़ाइल और लाइन का हवाला देते हुए, और जब वह कोड बदलता है तो पेजों पर निशान लगाता है। यह codebase docs के लिए है, जैसे architecture overview या onboarding notes।

जिस branch में conflict हो, उसका क्या होता है?
वह जहाँ है वहीं रहती है। आप अभी साफ़ branches merge कर सकते हैं और एजेंट को conflict वाली branch उनके ऊपर दोबारा करने दे सकते हैं, या Combine into a branch से अलग-अलग hunks चुन सकते हैं।

डेस्कटॉप ऐप osfoundry.io/hi/download पर मुफ़्त में डाउनलोड किया जा सकता है।

osFoundry क्या है और यह डेस्कटॉप AI वर्कस्पेस कैसे काम करता है?

tauchiii — Fri, 06 Nov 2026 13:12:02 +0000

सोमवार सुबह 9:40 बजे हैं और ब्राउज़र में चार टैब खुले हैं: सवालों के लिए एक chatbot, दूसरा इसलिए क्योंकि पहले वाले पर पूरा भरोसा नहीं है, एक editor जिसमें coding agent है, और एक notes ऐप जिसमें पिछले हफ़्ते की रिसर्च पड़ी है। हर टूल आपके काम का एक हिस्सा जानता है, बाकी किसी को कुछ नहीं पता। लंच तक आप एक ही context वाला पैराग्राफ़ तीन अलग-अलग विंडो में कॉपी कर चुके होते हैं।

पाँच टैब की जगह एक ऐप

osFoundry एक डेस्कटॉप AI वर्कस्पेस है: एक ऐसा ऐप जिसमें आप AI models से चैट करते हैं, agents और agent teams को काम सौंपते हैं, notes और searchable knowledge रखते हैं, अपने ही कंप्यूटर पर open models चलाते हैं, और अपनी टीम के लिए छोटे ऐप बनाते हैं। Models तीन जगह से आ सकते हैं: आपकी अपनी मशीन, आपकी अपनी API keys के ज़रिए cloud providers, या किराए के cloud GPUs। ऐप categories में बँटा है और हर category में कई screens हैं। Chat वह जगह है जहाँ आप models से बात करते हैं (Maestro, Multi chat, Branchspace वगैरह)। Workstation में agents लंबे काम करते हैं (Code, Agent, Agent team, Loop, Terminal)। Knowledge में आपका लिखा हुआ और AI की याद रखी बातें रहती हैं। Local Model open models ढूँढने, install करने और टेस्ट करने के लिए है। Custom App internal tools के लिए है, और Discover वेब रिसर्च और न्यूज़ के लिए। अगर आपने VS Code इस्तेमाल किया है, तो सबसे नज़दीकी तुलना ऐसे editor से है जिसमें activity bar का हर icon अलग टूल खोलता है, फ़र्क़ बस इतना है कि यहाँ टूल AI surfaces हैं और सब एक ही projects, memory और models शेयर करते हैं।

एक आम screen कैसी दिखती है

ज़्यादातर लोग Chat category से शुरू करते हैं, इसलिए osFoundry की screens की बनावट समझने के लिए यह अच्छी जगह है। यह Council mode में Multi chat है, example data के साथ: तीन models से एक ही सवाल पूछा गया और फिर हर model ने बाकी के जवाबों को स्कोर दिया।

ऊपर की टैब पट्टी (Maestro, Model chat, Multi chat, Research, Wiki, Code) Chat एरिया की surfaces के बीच स्विच करती है: पूरा Maestro agent, cited sources वाला सीधा सवाल-जवाब chat, एक साथ कई models, deep research, code documentation और coding agents।
Compare / Council स्विच तय करता है कि models मिलकर कैसे काम करें। Compare जवाबों को साथ-साथ रखता है ताकि फ़ैसला आप करें। Council में models अलग-अलग जवाब देते हैं, बिना नाम जाने एक-दूसरे को rank करते हैं, और फिर एक synthesis लिखा जाता है।
हर कॉलम एक model है जिस पर provider टैग लगा है: यहाँ Anthropic, Ollama (लोकल चलता हुआ) और OpenAI। आप एक ही screen पर cloud और local models मिला सकते हैं।
दाईं ओर की पट्टी run के चरण (Answers, Ranking, Synthesis) और Peer review ग्रिड दिखाती है, ताकि आप सिर्फ़ आख़िरी जवाब पढ़ने के बजाय देख सकें कि किसने किसे कितना स्कोर दिया।
Run बटन दबाने से पहले ही बता देता है कि इस run में कितनी model calls होंगी (यहाँ "Run · 7 calls")। Peer ranking बंद करने पर यह संख्या कम हो जाती है।

osFoundry की कई screens इसी पैटर्न पर चलती हैं: बाईं ओर एक list, बीच में असली काम, और दाईं ओर एक inspector जो दिखाता है कि नतीजा कैसे बना।

एक solo developer का पहला हफ़्ता

Ken अकेले एक छोटी वेब शॉप चलाते हैं। उन्हें ऐसा AI चाहिए जो उनके codebase को जानता हो, और वे कुछ काम अपने लैपटॉप पर ही रखना चाहते हैं।

सोमवार को वे Local Model खोलते हैं, फिर Explore। यह screen पहले उनकी मशीन को पढ़ती है (इस उदाहरण में 16 GB memory) और हर open model पर एक badge लगाती है: Fits, Tight या Too big। वे हरे badge वाला एक model install करते हैं और Playground में उससे कुछ सवाल पूछते हैं। Playground एक ही prompt दो models पर साथ-साथ चलाता है और दिखाता है कि किसने कितनी जल्दी जवाब देना शुरू किया।

मंगलवार को उन्हें कीमत format करने वाला एक function बदलना है और पक्का नहीं पता कि उस पर क्या-क्या निर्भर है। वे IDE में project खोलते हैं, function पर right-click करते हैं और Show Code Graph चुनते हैं।

यह panel हर caller की list देता है, बताता है कि कौन-से links सीधे code से पढ़े गए और कौन-से सिर्फ़ अनुमान हैं, और Impact of change में जोड़कर दिखाता है कि कितने symbols, files और tests पर असर पड़ सकता है। वे किसी caller पर क्लिक करके उस line पर पहुँच जाते हैं, और Send to chat से graph को Maestro के साथ बातचीत में ले आते हैं।

गुरुवार तक वे छोटे tasks coding agents को सौंपने लगते हैं। ADE screen में हर task का अपना worktree होता है, और Changes टैब diff दिखाता है। जिस line से वे सहमत नहीं, उसके बगल में gutter पर क्लिक करके note लिखते हैं, और सारे unsent notes एक साथ agent को भेज देते हैं। हफ़्ते के आख़िर तक उनके पास छोटे सवालों के लिए एक भरोसेमंद local model होता है और refactoring से पहले impact चेक करने की आदत।

एक छोटी टीम की लीड का पहला हफ़्ता

Aiko चार लोगों की टीम संभालती हैं और हर दो हफ़्ते में एक release निकालती हैं। उनकी दिक़्क़त code लिखना नहीं, बल्कि यह जानना है कि हर कोई, चाहे इंसान हो या agent, क्या कर रहा है।

वे Message से शुरू करती हैं, जो टीम chat है। Channels और DMs वैसे ही काम करते हैं जैसे Slack में, बस एक फ़र्क़ के साथ: AI agents भी channel के members हैं। कोई #release में किसी agent को @mention करता है, और उसका जवाब और run वापस उसी channel में आते हैं जहाँ सब देख सकते हैं।

इसके बाद वे Workstation में एक Agent team सेट करती हैं। एक leader agent specialist members को coordinate करता है, और screen पर Team mail, Handoffs, Sub-agents और Proposals अलग-अलग टैब में रहते हैं, ताकि वे audit कर सकें कि किसने क्या किसे सौंपा। हर release पर होने वाले checks के लिए वे उस टीम को एक Loop में बदल देती हैं: एक trigger (जैसे हफ़्ते के कामकाजी दिनों की सुबह), rounds और retries की सीमा, और success criteria। Loop rounds में तब तक चलता है जब तक criteria पास न हो जाएँ, और हर round में कौन-से criteria पास हुए, इसका हिसाब रखता है।

जब कई agents एक ही repository पर काम करते हैं, तो वे Code इस्तेमाल करती हैं। हर agent को अपनी branch और worktree मिलती है, और कुछ भी अपने-आप merge नहीं होता। वे दो पूरे हो चुके runs चुनती हैं, Preview combined merge दबाती हैं, और main branch को कुछ छूने से पहले ही देख लेती हैं कि कौन-सी files टकरा रही हैं।

Line-level review के लिए वे वही notes इस्तेमाल करती हैं जो Ken करते हैं: code पर pin किया गया note, जो file, line और code के साथ agent को भेजा जाता है। हफ़्ते के आख़िर तक उनके पास एक channel है जहाँ agents का काम दिखता है, एक release check जो अपने-आप चलता है, और एक review step जो merge के बाद नहीं, पहले होता है।

एक researcher और writer का पहला हफ़्ता

Lena workplace policy पर लंबी reports लिखती हैं। उन्हें ऐसे sources चाहिए जिन्हें वे जाँच सकें, और AI के आत्मविश्वास भरे ग़लत जवाबों से वे पहले भी धोखा खा चुकी हैं।

जिन सवालों में एक model का जवाब काफ़ी नहीं, उनके लिए वे Council mode में Multi chat इस्तेमाल करती हैं, यानी ऊपर वाली screen। जब दो reviewers किसी जवाब को कम स्कोर देते हैं, तो उन्हें पता चल जाता है कि और गहराई में जाना है।

बड़े सवालों के लिए वे Agents खोलती हैं, New session दबाती हैं और पहले से तैयार Deep Research Team चुनती हैं। Leader सवाल को हिस्सों में बाँटता है और हर हिस्सा किसी member को देता है, जैसे Data Researcher और Search Specialist।

एक अलग reviewer हर step को उनके पास पहुँचने से पहले जाँचता है, और बिना source वाला step वापस भेजकर दोबारा चलाया जाता है। आख़िरी जवाब एक टेबल के रूप में आता है जिसकी हर row में source होता है, साथ में एक छोटा note कि sources कहाँ असहमत हैं और क्या cover नहीं हुआ (screenshot में example data है)।

असली लिखाई Knowledge में होती है। Paper में वे अपने draft का एक वाक्य highlight करती हैं और उससे एक thinking space जोड़ती हैं, जिसमें Academic search, Browser या सिर्फ़ उसी हिस्से पर चर्चा करने वाला Maestro session जैसे टैब होते हैं। सहायक files और comments एक Note में रहते हैं। Discover में वे Browser में searches सेव करती हैं और News में keyword channels फ़ॉलो करती हैं, ताकि एक report के लिए की गई पढ़ाई अगली report में भी काम आए।

ये एरिया एक-दूसरे को काम कैसे सौंपते हैं

Categories अलग-अलग products नहीं हैं; वे काम आगे बढ़ाती हैं। Local Model नीचे की परत है: Explore से install किया गया model, Maestro, Multi chat और agent sessions के model pickers में दिखने लगता है।

Knowledge, Chat को जानकारी देता है: Memory दिखाता है कि Maestro आपके काम के बारे में क्या जानता है, और Indexed Folders से आप चुनते हैं कि agents किन folders में search कर सकते हैं। Agent sessions, Agent team runs और Loops अपनी रिपोर्ट Message channels में भेजते हैं। Workstation (इसी नाम वाली screen) आपको एक channel, एक note, एक file और एक agent session को एक ही layout में साथ-साथ खोलने देती है। जब agents के साथ बनाई कोई चीज़ टीम का टूल बननी चाहिए, तो वह Custom App में जाती है, जहाँ एक Room टीम के ऐप्स को उसके अपने Maestro chat के साथ रखता है। इन सबकी keys और providers Configuration में रहते हैं। पूरा नक्शा देखना हो तो platform overview में हर screen की list है।

पहले हफ़्ते में लोग जो सवाल पूछते हैं

क्या मुझे यह सब इस्तेमाल करना होगा?
नहीं। ज़्यादातर लोग एक एरिया से शुरू करते हैं, आमतौर पर Chat में Maestro या Local Model में Explore, और जब किसी काम की ज़रूरत हो तब बाकी जोड़ते हैं। Categories projects और memory शेयर करती हैं, इसलिए शुरुआत में किया कोई भी काम बाद में दोबारा नहीं करना पड़ता।

क्या मेरा data मेरे कंप्यूटर से बाहर जाता है?
Local models इस्तेमाल करते समय नहीं; वे आपके device पर चलते हैं। अपनी API keys से जोड़े गए cloud models वह देखते हैं जो आप उन्हें भेजते हैं, और उस इस्तेमाल का बिल provider भेजता है। local-first पेज बताता है कि ये दोनों कैसे अलग रखे जाते हैं।

क्या यह सिर्फ़ developers के लिए है?
नहीं। Code, IDE और Terminal developer tools हैं, लेकिन Message, Paper, Note, Research, Multi chat और Discover writers, analysts और team leads के लिए भी बने हैं।

इसकी कीमत क्या है?
डेस्कटॉप ऐप मुफ़्त में डाउनलोड होता है, और local models चलाने पर osFoundry की तरफ़ से कोई usage charge नहीं लगता। आप इसे download पेज से ले सकते हैं।