OpenClaw v2026.4.27, वॉइस एजेंट्स, और रैपिड AI स्टोरेज
EP043 OpenClaw v2026.4.27 से शुरू होता है। इस रिलीज़ में Codex Computer Use की स्थिति/इंस्टॉल फ्लो जो fail-closed MCP चेक के साथ हैं, मॉडल डिस्कवरी और मीडिया जनरेशन के लिए DeepInfra को प्रोवाइडर के रूप में बंडल किया गया है, Tencent Yuanbao और QQBot चैनल कवरेज का विस्तार किया गया है, sandboxed एजेंट्स के लिए Docker GPU passthrough जोड़ा गया है, operator-प्रबंधित आउटबाउंड प्रॉक्सी रूटिंग पेश की गई है, एजेंट उपयोग के लिए non-image चैट अटैचमेंट को स्टेज किया गया है, स्टार्टअप और मॉडल कैटलॉग को manifest-first मेटाडेटा की ओर ले जाया गया है, और कई वास्तविक डिलीवरी सेशन को ठीक किया गया है। Show notes: https://tobyonfitnesstech.com/hi/podcasts/episode-43/
🎧 Listen to EpisodeOPENCLAW DAILY — EPISODE 043 — 30 अप्रैल, 2026
[00:00] इंट्रो / हुक OpenClaw v2026.4.27 GitHub रिलीज़ सूची में नवीनतम स्थिर रिलीज़ है, और हालिया एपिसोड नोट्स में पहले से ही v2026.4.26, v2026.4.25, और v2026.4.24 शामिल हैं। रिलीज़-चयन नियम के तहत, इसका मतलब है कि EP043 के लिए वैध रिलीज़ ब्लॉक बिल्कुल v2026.4.27 है।
यह एक घनी ऑपरेटर रिलीज़ है। Codex Computer Use को एक वास्तविक सेटअप पथ मिलता है। DeepInfra बंडल्ड प्रोवाइडर बन जाता है। Docker सैंडबॉक्स ऑप्ट-इन GPU पासथ्रू प्राप्त करते हैं। एजेंट चैट अटैचमेंट अधिक स्पष्ट रूप से संभाले जाते हैं। आउटबाउंड प्रॉक्सी रूटिंग ऑपरेटर-प्रबंधित सेटिंग बन जाती है। Tencent Yuanbao और QQBot चैनल सतह का विस्तार करते हैं। प्लगइन स्टार्टअप और मॉडल कैटलॉग मैनिफेस्ट-स्वामित्व वाले मेटाडेटा की ओर बढ़ते रहते हैं। और फिक्स सूची वास्तविक एजेंट सिस्टम आमतौर पर जहां टूटते हैं उन स्थानों के माध्यम से एक बहुत लंबा टूर है: Telegram, Slack, Discord मीडिया जॉब्स, cron डिलीवरी, सत्र डिफ़ॉल्ट, प्लगइन रनटाइम डिप्स, प्रोवाइडर रीप्ले, गेटवे स्टार्टअप, अपडेट, Windows हैंडऑफ्स, और चैनल मीडिया।
[02:00] स्टोरी 1 — OpenClaw v2026.4.27 Computer Use और Provider सतहों को अधिक संचालन योग्य बनाता है Codex Computer Use से शुरू करें, क्योंकि यह रिलीज़ में सबसे स्पष्ट ऑपरेटर-फेसिंग परिवर्तनों में से एक है।
OpenClaw अब Codex Computer Use सेटअप के साथ स्थिति और इंस्टॉल कमांड, मार्केटप्लेस डिस्कवरी, वैकल्पिक ऑटो-इंस्टॉल, और Codex-मोड टर्न शुरू होने से पहले fail-closed MCP चेक प्रदान करता है। महत्वपूर्ण वाक्यांश है fail-closed। एक computer-use फीचर को एजेंट को डेस्कटॉप-कंट्रोल टर्न शुरू करने की अनुमति नहीं देनी चाहिए जब आवश्यक MCP सर्वर गायब है, गलत कॉन्फ़िगर है, या रनटाइम के लिए अदृश्य है। इसी तरह उपयोगकर्ता फैंटम क्षमता को डीबग करते हैं: मॉडल सोचता है कि वह कार्य कर सकता है, प्रोडक्ट शेल कहती है कि वह कार्य कर सकता है, लेकिन अंतर्निहित ड्राइवर या ब्रिज वास्तव में तैयार नहीं है।
तो रिलीज़ सेटअप को प्राथमिक प्रीफ्लाइट में बदल देती है। /codex computer-use status निरीक्षण सतह है। /codex computer-use install मरम्मत पथ है। मार्केटप्लेस डिस्कवरी रनटाइम को सही इंटीग्रेशन खोजने का तरीका देती है। Fail-closed MCP चेक सीमा को स्पष्ट करते हैं: यदि डेस्कटॉप-कंट्रोल सर्वर उपलब्ध नहीं है, तो मानो टर्न शुरू न करें। यह सबसे अच्छे तरीके से उबाऊ है, क्योंकि विश्वसनीय computer use इस बात का अंतर जानने पर निर्भर करता है कि कौन सी क्षमता प्रोडक्ट में मौजूद है और कौन सी क्षमता वर्तमान वातावरण में वास्तव में जुड़ी हुई है।
Codex Computer Use के आसपास मैन्युअल पेज, सीधे cua-driver mcp, और OpenClaw.app के PeekabooBridge में एक संबंधित दस्तावेज़ीकरण परिवर्तन है। यह महत्वपूर्ण है क्योंकि डेस्कटॉप कंट्रोल के पास अब कई संभावित सेटअप पथ हैं। एक लोकल ऐप ब्रिज, एक सीधा MCP ड्राइवर, और एक Codex-मोड सेटअप बाहर से समान लगते हैं, लेकिन संचालन रूप से वे प्रोसेस लाइफटाइम, अनुमतियों, स्क्रीनशॉट उपलब्धता, इनपुट इंजेक्शन, ब्राउज़र फोकस, और विफलता रिकवरी में भिन्न हो सकते हैं। EP043 को यह समझाना चाहिए कि प्रोडक्ट उन विकल्पों कोlegible बनाने की कोशिश कर रहा है instead of उन्हें tribal knowledge के रूप में छोड़ने के बजाय।
दूसरा बड़ा रिलीज़ क्षेत्र प्रोवाइडर विस्तार है। DeepInfra DEEPINFRA_API_KEY ऑनबोर्डिंग, डायनामिक OpenAI-संगत मॉडल डिस्कवरी, इमेज जेनरेशन और एडिटिंग, इमेज और ऑडियो समझ, TTS, टेक्स्ट-टू-वीडियो, मेमोरी एम्बेडिंग, स्टैटिक कैटलॉग मेटाडेटा, और प्रोवाइडर-स्वामित्व वाले base URL पॉलिसी के साथ बंडल्ड प्रोवाइडर सेट में शामिल होता है। यह सिर्फ मॉडल ड्रॉपडाउन में एक नया लोगो नहीं है। यह उन workload के प्रकारों का विस्तार करता है जिन्हें OpenClaw एक प्रोवाइडर के माध्यम से रूट कर सकता है: टेक्स्ट, मीडिया जेनरेशन, मीडिया समझ, स्पीच, वीडियो, और एम्बेडिंग।
ऑपरेटर विवरण मॉडल डिस्कवरी और प्रोवाइडर-स्वामित्व वाली पॉलिसी है। जब एक प्रोवाइडर OpenAI-संगत होता है, तो इसे सिर्फ एक और base URL के रूप में मानने का प्रलोभन होता है। लेकिन वास्तविक प्रोवाइडर सपोर्ट के लिए ऑनबोर्डिंग, कैटलॉग मेटाडेटा, क्षमता फ्लैग, मीडिया सपोर्ट, auth हिंट्स, एम्बेडिंग व्यवहार, फ़ॉलबैक सेमांटिक्स, और base URL स्वामित्व की आवश्यकता होती है। अन्यथा हर संगत एंडपॉइंट एक कस्टम snowflake बन जाता है जिसमें आश्चर्यजनक मॉडल नाम और आधे-ज्ञात क्षमताएं होती हैं। DeepInfra का बंडल्ड होना इसका मतलब है कि रनटाइम इसे एक प्रबंधित प्रोवाइडर सतह के रूप में उजागर कर सकता है उपयोगकर्ताओं को हर edge को हाथ से roll करने के लिए मजबूर करने के बजाय।
[11:30] स्टोरी 1B — सैंडबॉक्स, प्रॉक्सी, अटैचमेंट, और डिवाइस प्रेजेंस तेज होते हैं
Docker सैंडबॉक्स परिवर्तन छोटा है लेकिन लोकल AI workflows के लिए बहुत महत्वपूर्ण है: OpenClaw Docker सैंडबॉक्स कंटेनरों के लिए ऑप्ट-इन sandbox.docker.gpus पासथ्रू जोड़ता है जब होस्ट रनटाइम --gpus का समर्थन करता है।
यह सही डिफ़ॉल्ट आकार है। सैंडबॉक्स के अंदर GPU एक्सेस शक्तिशाली और उपयोगी है, लेकिन इसे स्पष्ट होना चाहिए। लोकल मॉडल सर्विंग, इमेज जेनरेशन, वीडियो प्रोसेसिंग, कंप्यूटर विज़न, और इवैल्यूएशन जॉब्स को अक्सर हार्डवेयर एक्सेलरेशन की जरूरत होती है। लेकिन मनमाने सैंडबॉक्ड एजेंट वर्क में GPU एक्सपोज करना संसाधन और ड्राइवर सतह को भी बढ़ा देता है। इसे ऑप्ट-इन बनाने से ऑपरेटर्स को एक नॉब मिलता है: यह सैंडबॉक्स GPU का उपयोग कर सकता है; यह अन्य सैंडबॉक्स सीपीयू-ओनली रहेगा। यह तब विशेष रूप से प्रासंगिक होता है जब एक एजेंट डिपेंडेंसी इंस्टॉल कर सकता है, मॉडल टूलिंग चला सकता है, या लंबे जॉब्स एक्जीक्यूट कर सकता है जो VRAM पर एकाधिकार कर सकते हैं।
रिलीज में proxy.enabled, proxy.proxyUrl, और OPENCLAW_PROXY_URL के साथ ऑपरेटर-मैनेज्ड आउटबाउंड प्रॉक्सी रूटिंग भी जोड़ी गई है। नोट्स स्ट्रिक्ट http:// फॉरवर्ड-प्रॉक्सी वैलिडेशन, लूपबैक-ओनली Gateway बाइपास, और एग्जिट पर प्रॉक्सी एनवायरनमेंट और डिस्पैचर स्टेट की क्लीनअप को कॉल आउट करते हैं। यह अच्छी सुरक्षा आकार है। यह स्वीकार करता है कि कुछ इंस्टॉलेशन को कंप्लायंस, इंस्पेक्शन, कॉर्पोरेट नेटवर्किंग, या एग्रेस रिस्ट्रिक्शन के लिए नियंत्रित आउटबाउंड पाथ की जरूरत है, लेकिन यह बिना शांत रूप से इंटरनल Gateway ट्रैफ़िक को उसी पाथ के माध्यम से रूट नहीं करता और शटडाउन के बाद स्टेल प्रॉक्सी स्टेट नहीं छोड़ता।
Gateway चैट अटैचमेंट व्यवहार भी सुधरता है। chat.send के माध्यम से भेजे गए नॉन-इमेज अटैचमेंट अब एजेंट-रीडेबल मीडिया पाथ के रूप में स्टेज किए जा सकते हैं, जबकि अनसपोर्टेड RPC अटैचमेंट पाथ स्पष्ट हैं बजाय शांत रूप से फाइलों को ड्रॉप करने के। एजेंट UX के लिए यह मायने रखता है क्योंकि गायब हो जाने वाला अटैचमेंट स्पष्ट रूप से फेल होने वाले अटैचमेंट से बदतर है। ऑपरेटर्स को यह जानना होता है कि फाइल एजेंट द्वारा पढ़ी जा सकती है या नहीं, क्या यह मीडिया बन गई, क्या चैनल प्रोवाइडर ने इसे स्वीकार किया, और क्या अनसपोर्टेड पाथ को रिजेक्ट किया गया था।
मोबाइल और पेयर्ड नोड्स पर, iOS और Android अब ऑथेंटिकेटेड node.presence.alive इवेंट्स पब्लिश करते हैं और लास्ट-सीन फ़ील्ड्स एक्सपोज करते हैं ताकि बैकग्राउंड वेक्स पेयर्ड नोड्स को हाल ही में एलाइव मार्क कर सकें बिना उन्हें कनेक्टेड मानने के। वितरित असिस्टेंट सिस्टम्स में यह अंतर मायने रखता है। एक नोड हाल ही में एलाइव हो सकता है बिना अभी कनेक्टेड हुए। अगर रनटाइम इन स्टेट्स को एक बूलियन में संक्षिप्त कर देता है, तो यह या तो उपलब्धता के बारे में ओवर-प्रॉमिस करता है या उपयोगी लाइवनेस इंफॉर्मेशन खो देता है। लास्ट-सीन मेटाडेटा शेड्यूलिंग, डायग्नोस्टिक्स, और UX को स्टेट को अधिक ईमानदारी से बताने देता है।
[18:30] स्टोरी 1C — मैनिफेस्ट-फर्स्ट स्टार्टअप और मॉडल कैटलॉग रनटाइम गेसवर्क कम करते हैं v2026.4.27 का बहुत कुछ भारी रनटाइम इम्पोर्ट्स से कैटलॉग और प्लगइन मेटाडेटा को मैनिफेस्ट में ले जाने के बारे में है।
बंडल्ड प्लगइन मैनिफेस्ट अब स्पष्ट activation.onStartup व्यवहार घोषित करते हैं। डिप्रिकेटेड इम्प्लिसिट स्टार्टअप साइडकैर लोडिंग को डिसेबल करने के लिए फ्यूचर-मोड गेट भी है, साथ ही प्लगइन ऑथर्स को स्पष्ट मेटाडेटा की ओर ले जाने के लिए कंपैटिबिलिटी वार्निंग्स। व्यावहारिक बिंदु सरल है: Gateway स्टार्टअप को यह पता लगाने के लिए हर संभव प्लगइन साइडकैर को इम्पोर्ट नहीं करना चाहिए कि उसके पास स्टार्टअप वर्क है या नहीं। स्टार्टअप वह जगह है जहां धीमे डिपेंडेंसी ट्रीज़, नेटवर्क चेक्स, स्टेल प्लगइन स्टेट, और आकस्मिक साइड इफेक्ट्स सबसे ज्यादा नुकसान पहुंचाते हैं।
रिलीज मॉडल-कैटलॉग प्लानिंग में मैनिफेस्ट modelCatalog.aliases और modelCatalog.suppressions को भी वायर करती है। Qianfan, Xiaomi, NVIDIA, Cerebras, Mistral, Moonshot, DeepSeek, Tencent TokenHub, StepFun, BytePlus, Volcano Engine, Fireworks, और Together AI के लिए प्रोवाइडर कैटलॉग प्लगइन मैनिफेस्ट रोज़ की ओर बढ़ रहे हैं। यह दूसरे एंगल से同一 वास्तुशिल्प मूव है: प्रोवाइडर रोज़, एलियसेस, सप्रेशन, और एंडपॉइंट मेटाडेटा को बिना रनटाइम नॉर्मलाइज़ेशन को व्यापक प्लगइन यूनिवर्स में मजबूर किए इंस्पेक्टेबल बनाएं।
बिल्डर्स के लिए, पाठ यह है कि मॉडल कैटलॉग इन्फ्रास्ट्रक्चर हैं, सिर्फ UI नहीं। अगर प्रोडक्ट को "कौन से मॉडल मौजूद हैं," "कौन सा प्रोवाइडर इस मॉडल का मालिक है," "कौन से एलियसेस वैध हैं," और "कौन से स्टेल रोज़ छिपाए जाने चाहिए" का जवाब देना है, तो यह इंफॉर्मेशन प्रोवाइडर कॉन्ट्रैक्ट के करीब होनी चाहिए। अन्यथा हर लिस्ट कमांड, सेटअप फ्लो, गेटवे बूट, और प्रोवाइडर डिस्कवरी पाथ बहुत अधिक काम करने और थोड़े अलग उत्तर वापस करने का जोखिम लेता है।
SDK और टेस्टिंग स्टोरी यहां भी मजबूत है। रिलीज चैनल रूट्स के लिए फोकस्ड प्लगइन SDK सबपाथ्स, चैनल टेस्ट हेल्पर्स, चैनल टारगेट टेस्टिंग, प्लगइन रनटाइम फिक्सचर्स, प्रोवाइडर कैटलॉग हेल्पर्स, मीडिया प्रोवाइडर कैपेबिलिटी एज़र्शन, और कई कॉन्ट्रैक्ट हेल्पर्स को एक्सपोज़ करती है जो पहले रेपो-ओनली टेस्ट ब्रिजेज़ में रहते थे। यह सीधे यूज़र-विज़िबल नहीं है, लेकिन यह महत्वपूर्ण प्रोडक्ट हाइजीन है। एक्सटेंशन ऑथर्स और बंडल्ड प्लगइन्स को डॉक्यूमेंटेड SDK सरफेसिस के विरुद्ध टेस्ट करना चाहिए, प्राइवेट टेस्ट डायरेक्टरीज़ के विरुद्ध नहीं जो उनके नीचे हिल सकती हैं।
[25:00] स्टोरी 1D — रिलायबिलिटी फिक्सेस दिखाती हैं कि एजेंट रनटाइम वास्तव में कहां दर्द देते हैं v2026.4.27 फिक्स लिस्ट लंबी है, और शो को हर आइटम नहीं पढ़ना चाहिए। इसके बजाय, फिक्सेस को ऑपरेटर पेन के अनुसार समूहित करें।
पहला: चैनल डिलीवरी। Telegram को बेहतर मल्टी-बॉट नेटिव अप्रूवल रूटिंग, बाउंडेड आउटबाउंड Bot API कॉल, कैश्ड बंडल्ड प्लगइन एलियास लुकअप, और --thread-id के साथ क्रॉन टॉपिक प्रिजर्वेशन मिलता है। Slack को सॉकेट-मोड पिंग/पॉन्ग टाइमआउट कंट्रोल और बाउंडेड प्राइवेट फाइल और फॉरवर्डेड अटैचमेंट डाउनलोड मिलते हैं। Mattermost रेगुलर इनबाउंड पोस्ट को सिस्टम इवेंट्स के रूप में डुप्लिकेट करना बंद कर देता है। LINE इनबाउंड मीडिया को अस्थायी फाइलों के बजाय मैनेज्ड मीडिया स्टोरेज में सेव करता है जो गायब हो सकती हैं। ये वही फिक्सेस हैं जो तब मायने रखती हैं जब OpenClaw सिर्फ एक लोकल CLI नहीं, बल्कि एक मल्टी-चैनल असिस्टेंट है जिसे स्लो प्रोवाइडर्स, फोरम टॉपिक्स, फाइल डाउनलोड, मीडिया रिटेंशन, और चैनल-स्पेसिफिक सेमांटिक्स में सर्वाइव करना होता है।
दूसरा: एसिंक मीडिया और टास्क्स। डिटैच्ड video_generate और music_generate टूल कॉन्टेक्स्ट टर्मिनल स्टेटस तक रजिस्टर्ड रहते हैं, लॉन्ग-रनिंग प्रोवाइडर जॉब्स फ्रेश रहते हैं, और सेशन-स्कोप्ड टास्क रिकॉर्ड्स ओनरशिप इन्फर करते हैं। यह उस प्रोडक्ट फेलियर की एक गंदी क्लास को फिक्स करता है जहां जेनरेशन जॉब प्रोवाइडर पर अभी जिंदा है, लेकिन पैरेंट चैट कॉन्टेक्स्ट या टास्क टेबल सोचता है कि वह खो गया है। Discord-बैक्ड मीडिया जेनरेशन के लिए खासकर, यूजर एक्सपीरियंस इस बात पर निर्भर करता है कि रनटाइम एक लंबे एक्सटर्नल जॉब को टर्न्स में ट्रैक कर रहा है।
तीसरा: सेशन्स, मॉडल्स, और रीप्ले। chat.history और sessions.list थिंकिंग डिफॉल्ट्स अब ओनिंग-एजेंट और कैटलॉग-अवेयर रेजोल्यूशन के साथ अलाइन हैं। DeepSeek V4 रीजनिंग कंटेंट रीप्ले पाथ्स पर बैकफिल्ड होता है। Anthropic बीटा हेडर्स सीधे पब्लिक Anthropic एंडपॉइंट्स तक कंस्ट्रेंड हैं कस्टम कम्पैटिबल प्रोवाइडर्स की जगह। कॉन्फिग-हेवी टूल रिस्पॉन्स ट्रांसक्रिप्ट्स में जायंट रिडैक्टेड कॉन्फिग्स रीप्ले करना बंद करते हैं। ये सब एक ही थीम की ओर इशारा करते हैं: एक बार एजेंट्स मल्टीपल प्रोवाइडर्स, टूल कॉल्स, ट्रांसक्रिप्ट्स, रीप्ले, और पर-एजेंट डिफॉल्ट्स का उपयोग करते हैं, रनटाइम को पर्याप्त स्टेट प्रिजर्व करना होता है ताकि गलती से गलत मेटाडेटा गलत बैकएंड को न भेजे।
चौथा: स्टार्टअप, अपडेट्स, और प्लगइन रनटाइम डिपेंडेंसीज़। गेटवे स्टार्टअप अब चैट चैनल्स शुरू करने से पहले प्राइमरी मॉडल प्रीवॉर्म की प्रतीक्षा नहीं करता। डिसेबल्ड ट्रैक्ड प्लगइन्स पोस्ट-अपडेट सिंक के दौरान स्किप होते हैं। बंडल्ड रनटाइम डिप्स और मिरर्स रीस्टार्ट्स के दौरान हल्के, मोर कैश-अवेयर, और सुरक्षित होते हैं। प्लगइन इंस्पेक्शन सिर्फ मैच्ड प्लगइन लोड करता है। प्लगइन अनइंस्टॉल प्लान मेटाडेटा से होते हैं रनटाइम-लोडिंग सब कुछ की जगह। यह बिल्कुल वही है जो ऑपरेटर्स "OpenClaw जल्दी शुरू होता है" या "अपडेट्स मेरे इंस्टेंस को नहीं वेज करते" के रूप में फील करते हैं, भले ही अंडरलाइंग फिक्सेस ज्यादातर डिपेंडेंसी और मेटाडेटा डिसिप्लिन हैं।
रिलीज वर्डिक्ट: v2026.4.27 कोई सिंगल-फीचर एपिसोड नहीं है। यह एक रनटाइम-ऑपरेशन रिलीज़ है। यह कंप्यूटर यूज़ को शुरू करने में सुरक्षित बनाता है, प्रोवाइडर्स को ऑनबोर्ड करना आसान बनाता है, सैंडबॉक्सेस को ज्यादा कैपेबल बनाता है, चैनल्स को ज्यादा एक्सप्लिसिट बनाता है, प्लगइन स्टार्टअप को कम हेवी बनाता है, और लॉन्ग-रनिंग जॉब्स खोना मुश्किल बनाता है।
[31:00] स्टोरी 2 — Deepgram Flux Multilingual वॉइस-एजेंट STT को टर्न-टेकिंग रनटाइम प्रॉब्लम बनाता है Deepgram का Flux Multilingual एक अच्छी वॉइस-एजेंट स्टोरी है क्योंकि यह सिर्फ "ज्यादा भाषाएं" नहीं है। यह बदलता है कि बिल्डर्स को realtime एजेंट्स के अंदर स्पीच रिकग्निशन लेयर के बारे में कैसे सोचना चाहिए।
मॉडल flux-general-multi है, और Deepgram कहता है कि यह English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian, और Dutch कोड स्विचिंग के साथ सपोर्ट करता है। मुख्य आर्किटेक्चरल प्रॉमिस यह है कि हर भाषा-स्पेसिफिक रिकग्नाइज़र के माध्यम से हर उटरेंस को रूट करने के बजाय एक स्ट्रीमिंग कनेक्शन होता है। यह मायने रखता है क्योंकि एक मल्टीलिंग्वल कन्वर्सेशन कॉल के बीच में भाषा बदल सकता है, एक ही टर्न के अंदर भाषाएं मिक्स कर सकता है, या एक भाषा में शुरू हो सकता है जो सिस्टम ने प्रेडिक्ट नहीं की थी।
API डिटेल्स वही हैं जो इसे ऑपरेशनली इंटरेस्टिंग बनाते हैं। Flux /v2/listen WebSocket पाथ यूज़ करता है। लैंग्वेज प्रॉम्प्टिंग language_hint यूज़ करती है बायस रिकग्निशन के लिए। डिटेक्टेड लैंग्वेजेस TurnInfo इवेंट्स पर languages जैसे फील्ड्स के माध्यम से दिखाई देती हैं। टर्न के एंड का बिहेवियर eot_threshold, eager_eot_threshold, और eot_timeout_ms जैसे थ्रेशोल्ड्स के साथ कॉन्फिगरेबल है। ये कॉस्मेटिक फ्लैग्स नहीं हैं। ये वॉइस-एजेंट लूप को कंट्रोल करते हैं: कब सुनना बंद करना है, कब जेनरेट करना शुरू करना है, कब जल्दी रिस्पॉन्स का रिस्क लेना है, और कब इंतज़ार करना है क्योंकि यूज़र अभी बोल रहा हो सकता है।
एक वॉइस एजेंट के लिए, STT लैटेंसी और टर्न डिटेक्शन प्रोडक्ट बिहेवियर हैं। अगर एंड-ऑफ-टर्न बहुत जल्दी फायर होता है, एजेंट इंटरप्ट करता है। अगर बहुत देर से फायर होता है, एजेंट सुस्त लगता है। अगर कोड स्विचिंग मॉडल के बाहर एक रूटिंग लेयर द्वारा हैंडल की जाती है, सिस्टम भाषाएं गेस करने और स्ट्रीम्स रीकनेक्ट करने में एक्स्ट्रा टाइम खर्च कर सकता है। अगर लैंग्वेज हिंट्स बहुत नैरो हैं, रिकग्निशन डिग्रेड हो सकती है जब स्पीकर स्विच करता है। प्रैक्टिकल रिकमेंडेशन यह है कि STT को रनटाइम लूप का हिस्सा मानें, ब्लैक-बॉक्स ट्रांसक्रिप्ट सर्विस नहीं।
सेल्फ-होस्टेड डॉक्यूमेंटेशन एक और इम्पोर्टेंट एंगल जोड़ता है: Flux को डेडिकेटेड इन्फ्रास्ट्रक्चर चाहिए। Deepgram कहता है कि Flux को दूसरी STT और TTS मॉडल्स से अलग Engine इंस्टेंस पर चलना चाहिए, Engine और API TOML फाइल्स में स्पष्ट रूप से इनेबल होना चाहिए, /v2/listen यूज़ करता है, और स्टार्टअप पर Flux स्ट्रीम्स के लिए GPU मेमोरी अलोकेट करता है। आप [flux] सेक्शन में flux-general-multi सिलेक्ट करते हैं, max_streams कॉन्फिगर करते हैं, और flux_max_streams, flux_used_streams, और flux_fraction_streams मॉनिटर करते हैं।
यह वही operational detail है जिसकी voice-agent builders को जरूरत होती है। अगर max_streams बहुत ज्यादा है, तो symptoms abstract नहीं हैं: delayed responses, dropped calls, API errors, और unstable latency। अगर model accidently CPU पर चल रहा है, तो docs high latency, OOM-style failures, और GPU health checks की जरूरत को call out करते हैं। अगर Flux को दूसरी models के साथ same Engine node पर रखा जाता है, तो memory pressure unrelated requests को तोड़ सकती है। Builder takeaway: multilingual voice agents को streaming layer पर capacity planning चाहिए, transcript के पीछे बस एक bigger LLM नहीं।
[39:00] STORY 3 — Google Rapid Bucket Brings Colossus into the PyTorch Data Path Google का Rapid Bucket post एक strong AI infrastructure story है क्योंकि यह training के उस part के बारे में है जिसे तब तक ignore करना आसान है जब तक GPUs महंगे और idle नहीं हो जाते: data feeding और checkpoints writing।
Core mechanism है Rapid Storage, जो Google के Colossus storage architecture द्वारा संचालित है, gcsfs और fsspec interface के through PyTorch में expose। fsspec मायने रखता है क्योंकि यह पहले से एक common Python filesystem abstraction है जो data preparation, checkpoints, और inference tooling के around उपयोग किया जाता है: Dask, Pandas, Hugging Face Datasets, Ray Data, PyTorch Lightning, distributed PyTorch paths, Weights & Biases, और vLLM-adjacent workflows। अगर storage backend fsspec के behind faster हो सकता है, तो बहुत सारा AI code custom storage adapters के बिना benefit कर सकता है।
Rapid Bucket data path को बदलता है dedicated zonal buckets, underlying Colossus files से direct connectivity, और APIs जैसे BidiReadObject और BidiWriteObject के through persistent bidirectional gRPC streams का उपयोग करके। यह traditional REST-style object access की repeated overhead को stateful streaming से बदल देता है। Post, gcsfs में bucket-type auto-detection को भी call out करता है, ताकि existing fsspec.open() style code तेज path का उपयोग कर सके जब bucket Rapid हो।
Numbers useful हैं: Google 15+ TiB/s aggregate throughput cite करता है, 16 GKE nodes के साथ एक benchmark में 23% training-time improvement जिनमें से प्रत्येक में आठ A4 GPUs हैं, 48 processes में 16MB I/O sizes के साथ microbenchmarks में 4.8x read throughput improvement, और 2.8x write throughput improvement। किसी भी workload के लिए exact result vary होगी, लेकिन mechanism स्पष्ट enough है discuss करने के लिए: fewer network hops, persistent streams, lower per-operation overhead, zonal co-location, और checkpoint append support।
Tradeoff है locality। Zonal co-location ही वजह है fast path काम करती है, लेकिन यह failure और architecture model को भी बदल देता है। अगर आपका training job एक zone में चलता है और data उस zone में Rapid bucket में है, तो latency profile बेहतर होती है। लेकिन आपको अभी भी regional durability, dataset replication, checkpoint backup, और यह सोचना होगा कि अगर zone unavailable हो जाए तो क्या होगा। Production training systems के लिए, इसका मतलब है hot training path को durable archival path से अलग करना। Fast zonal bucket का उपयोग करें accelerators को busy रखने के लिए; important checkpoints और data products को regional या multi-region durability layer पर copy करें जब workflow require करे।
OpenClaw-relevant takeaway यह है कि agent और model infrastructure बढ़ते हुए boring data paths पर depend करती है। एक model सिर्फ एक GPU और एक checkpoint नहीं है। यह object storage, file abstractions, stream protocols, scheduler locality, checkpoint frequency, और recovery strategy है। अगर data path stall हो जाती है, तो smartest accelerator fleet एक बहुत expensive waiting room बन जाती है।
[45:00] OUTRO EP043 से practical takeaway है operational control। OpenClaw v2026.4.27 computer use, providers, channels, startup, और reliability को operate करना आसान बनाता है। Deepgram दिखाता है कि voice agents को transcripts के अलावा streaming और turn-taking controls चाहिए। Google दिखाता है कि AI training performance storage protocols, filesystem abstractions, stream protocols, checkpoint behavior, और zonal locality पर निर्भर हो सकती है।
[NOVA]: मैं NOVA हूं, और यह OpenClaw Daily है। आज हम OpenClaw v2026.4.27 के साथ शुरू कर रहे हैं, जो EP043 के लिए वर्तमान रिलीज़ ब्लॉक है। इस रिलीज़ में Codex Computer Use सेटअप कमांड, fail-closed MCP चेक, बंडल्ड DeepInfra प्रोवाइडर सपोर्ट, Tencent Yuanbao और QQBot चैनल एक्सपैंशन, सैंडबॉक्स्ड एजेंट्स के लिए Docker GPU पासथ्रू, स्पष्ट आउटबाउंड प्रॉक्सी कंट्रोल, स्टेज्ड नॉन-इमेज चैट अटैचमेंट, मैनिफेस्ट-बैक्ड मॉडल कैटलॉग, प्लगइन स्टार्टअप मेटाडेटा, और Telegram, Slack, Discord मीडिया टास्क, सेशंस, अपडेट, गेटवे स्टार्टअप, और चैनल मीडिया में एक बड़ी रिलायबिलिटी पास शामिल है। ...
[ALLOY]: मैं ALLOY हूं। और यह एपिसोड जानबूझकर शुरुआत में रिलीज़-हेवी है। यह रिलीज़ कोई छोटा पैच नोट नहीं है। यह उन ऑपरेटर सतहों को बदलता है जो मायने रखती हैं जब OpenClaw एक असली एजेंट रनटाइम के रूप में चल रहा हो: computer-use सेटअप, प्रोवाइडर ऑनबोर्डिंग, सैंडबॉक्स संसाधन, आउटबाउंड नेटवर्किंग, अटैचमेंट हैंडलिंग, प्लगइन लोडिंग, मॉडल कैटलॉग व्यवहार, और लंबे-चलने वाले जॉब ट्रैकिंग।
[NOVA]: रिलीज़ सेक्शन के बाद, हमारे पास दो तकनीकी कहानियां हैं। पहली, Deepgram Flux Multilingual और इसलिए voice-agent स्पीच रिकग्निशन वास्तव में एक रनटाइम और turn-taking की समस्या है, सिर्फ ट्रांसक्रिप्ट की समस्या नहीं। फिर Google Rapid Bucket और इसलिए PyTorch ट्रेनिंग परफॉर्मेंस object storage, gcsfs, fsspec, bidirectional gRPC स्ट्रीम, checkpoint व्यवहार, और zonal locality पर निर्भर हो सकती है।
[ALLOY]: इस एपिसोड के लिए महत्वपूर्ण बाधा गहराई है। हम रिलीज़ को फीचर नामों की सूची के रूप में नहीं मानेंगे। हम बात करेंगे कि क्या बदला, ऑपरेटर वास्तव में क्या स्पर्श करता है, बदलाव किस failure mode को हटाने की कोशिश कर रहा है, और बिल्डर को अलग तरह से क्या करना चाहिए।
[NOVA]: सही। रिलीज़ के लिए, इसका मतलब है Codex Computer Use और MCP preflight व्यवहार के साथ शुरू करना, फिर DeepInfra प्रोवाइडर सपोर्ट, Docker GPU एक्सेस, प्रॉक्सी रूटिंग, अटैचमेंट, नोड प्रेजेंस, मैनिफेस्ट-फर्स्ट स्टार्टअप, मॉडल कैटलॉग मेटाडेटा, SDK सतहों, और रिलायबिलिटी फिक्स की ओर जाना। वॉइस एजेंट्स के लिए, इसका मतलब है WebSocket सेमांटिक्स, लैंग्वेज हिंट्स, डिटेक्टेड-लैंग्वेज इवेंट्स, end-of-turn थ्रेशोल्ड, समर्पित self-hosted Engine नोड्स, GPU मेमोरी, स्ट्रीम काउंट्स, और मॉनिटरिंग। Rapid Bucket के लिए, इसका मतलब है PyTorch और Colossus के बीच डेटा पाथ, सिर्फ स्पीड क्लेम नहीं।
[ALLOY]: तो एपिसोड OpenClaw रिलीज़ से शुरू होता है क्योंकि आज सबसे ज्यादा ऑपरेटर-फेसिंग बदलाव वहीं है। फिर दो बाहरी कहानियां उसी व्यावहारिक लेंस को चौड़ा करती हैं: रियलटाइम स्पीच सिस्टम और AI स्टोरेज सिस्टम दोनों मॉडल, रनटाइम, और इन्फ्रास्ट्रक्चर के बीच के सीमाओं पर विफल होते हैं।
[NOVA]: पहली गहरी डाइव से पहले एक और रिलीज़ नोट: यह अपडेट खासतौर पर उपयोगी है क्योंकि यह एजेंट टर्न से पहले, दौरान, और बाद ऑपरेशनल पथ को छूता है। टर्न से पहले, सेटअप और preflight चेक क्षमताओं को ईमानदार बनाते हैं। टर्न के दौरान, चैनल, अटैचमेंट, प्रॉक्सी रूटिंग, प्रोवाइडर कैटलॉग, और सैंडबॉक्स संसाधन यह तय करते हैं कि एजेंट वास्तव में क्या पहुंच सकता है। टर्न के बाद, सेशन हिस्ट्री, मीडिया टास्क, cron डिलीवरी, अपडेट सिंक, और स्टार्टअप रिकवरी यह तय करते हैं कि सिस्टम अगले रिक्वेस्ट के लिए समझने योग्य रहे। इसीलिए हम एपिसोड का लगभग आधा हिस्सा रिलीज़ ब्लॉक पर खर्च कर रहे हैं।
[ALLOY]: बिल्कुल। व्यावहारिक सवाल सिर्फ यह नहीं है कि क्या शिप हुआ। यह है कि किन failure modes को संकरा किया गया। मिसिंग डेस्कटॉप-कंट्रोल सर्वर पहले ही रुकने चाहिए। प्रोवाइडर रो को ऑडिट करना आसान होना चाहिए। फाइल अटैचमेंट चुपचाप गायब नहीं होना चाहिए। धीमा चैनल सेंड गेटवे को वेज नहीं करना चाहिए। लंबा मीडिया रेंडर सिर्फ इसलिए खो नहीं जाना चाहिए क्योंकि पैरेंट चैट रन खत्म हो गया। वे बदलाव हैं जो एजेंट रनटाइम को कम फ्रैजाइल बनाते हैं।
[NOVA]: कहानी एक: OpenClaw v2026.4.27 Computer Use, प्रोवाइडर्स, चैनल्स, स्टार्टअप, और रिलायबिलिटी को टाइट करता है। Codex Computer Use से शुरू करें, क्योंकि यह रिलीज़ में सबसे स्पष्ट ऑपरेटर-फेसिंग बदलावों में से एक है।
[ALLOY]: रिलीज़ Codex Computer Use के लिए स्टेटस और इंस्टॉल कमांड के साथ सेटअप फ्लो, मार्केटप्लेस डिस्कवरी, वैकल्पिक ऑटो-इंस्टॉल, और Codex-mode टर्न शुरू होने से पहले fail-closed MCP चेक जोड़ता है। वह वाक्यांश, "fail-closed", ही कुंजी है। एक computer-use फीचर तब डेस्कटॉप-कंट्रोल टर्न शुरू नहीं करना चाहिए अगर वह MCP सर्वर जो डेस्कटॉप कंट्रोल को संभव बनाता है, गायब है, गलत कॉन्फिगर्ड है, या पहुंच से बाहर है।
[NOVA]: उस preflight के बिना, प्रोडक्ट एक कंफ्यूजिंग हाफ-स्टेट में प्रवेश कर सकता है। मॉडल को लग सकता है कि वो कंप्यूटर का उपयोग कर सकता है। UI इशारा कर सकता है कि फीचर मौजूद है। यूजर उम्मीद कर सकता है कि स्क्रीनशॉट, क्लिक्स और टाइप्ड इनपुट काम करेंगे। लेकिन असल ब्रिज या ड्राइवर नीचे उपलब्ध नहीं है। यही वो तरह की मिसमैच है जो computer-use सिस्टम को अविश्वसनीय बनाती है।
[ALLOY]: नया setup पाथ रनटाइम को एक प्रैक्टिकल वोकैबुलरी देता है। स्टेटस ऑपरेटर को बताता है कि पीस मौजूद हैं या नहीं। इंस्टॉल एक रिपेयर पाथ देता है। मार्केटप्लेस डिस्कवरी प्रोडक्ट को सही इंटीग्रेशन ढूंढने में मदद करती है। फेल-क्लोज्ड MCP चेक्स टर्न शुरू होने से रोकते हैं जैसे सब कुछ तैयार है जब टूल बाउंड्री असल में वहां मौजूद नहीं है।
[NOVA]: यह इसलिए मायने रखता है क्योंकि computer use एक हाई-ट्रस्ट कैपेबिलिटी है। एक डेस्कटॉप-कंट्रोल एजेंट विंडोज, फाइल्स, ब्राउज़र्स, फॉर्म्स और लोकल स्टेट को टच करता है। अगर कंट्रोल ब्रिज फ्लैकी है, तो सही बिहेवियर इम्प्रूवाइज़ करना नहीं है। सही बिहेवियर यह कहना है कि कैपेबिलिटी तैयार नहीं है और मॉडल उस टर्न में प्रवेश करने से पहले रुक जाना जो इस पर निर्भर है।
[ALLOY]: Codex Computer Use, डायरेक्ट cua-driver MCP उसेज, और OpenClaw.app के PeekabooBridge के आसपास एक डॉक्यूमेंटेशन एंगल भी है। यह सिर्फ डॉक्यूमेंटेशन हाउसकीपिंग नहीं है। यह उन setup पाथ्स को अलग करने में मदद करता है जो बाहर से समान दिख सकते हैं लेकिन प्रोसेस लाइफटाइम, परमिशन्स, स्क्रीनशॉट कैप्चर, इनपुट इंजेक्शन, ब्राउज़र फोकस और रिकवरी में अलग व्यवहार करते हैं।
[NOVA]: एक लोकल ऐप ब्रिज, एक डायरेक्ट MCP ड्राइवर, और एक Codex-mode setup सभी computer use जैसा लग सकते हैं। लेकिन एक ऑपरेटर के लिए, असल सवाल कंक्रीट हैं। कौन सा प्रोसेस स्क्रीनशॉट्स का मालिक है? किस प्रोसेस को इनपुट ड्राइव करने की परमिशन है? फेल्योर कैसे रिपोर्ट होती है? अगर ब्रिज मर जाता है तो क्या होता है? क्या यूजर स्टेटस इंस्पेक्ट कर सकता है? क्या setup को गेसिंग के बिना रिपेयर किया जा सकता है?
[ALLOY]: रिलीज़ इसका आधा जवाब हाइडन प्रीरीक्विज़िट की जगह setup को एक एक्सप्लिसिट सरफेस बनाकर देती है। बिल्डर्स के लिए, सिफारिश है कि computer-use एनेबलमेंट को एक vibe की तरह नहीं बल्कि एक डिप्लॉयमेंट चेक की तरह ट्रीट करें। एजेंट को डेस्कटॉप-कंट्रोल टास्क देने से पहले, ब्रिज, सर्वर, परमिशन्स और कॉन्फ़िगर्ड रनटाइम पाथ को वेरीफाई करें।
[NOVA]: दूसरा बड़ा रिलीज़ एरिया प्रोवाइडर एक्सपैंशन है। DeepInfra DEEPINFRA_API_KEY के माध्यम से ऑनबोर्डिंग, डायनामिक OpenAI-कम्पैटिबल मॉडल डिस्कवरी, इमेज जेनरेशन और एडिटिंग, इमेज और ऑडियो अंडरस्टैंडिंग, टेक्स्ट-टू-स्पीच, टेक्स्ट-टू-वीडियो, मेमोरी एम्बेडिंग्स, स्टैटिक कैटलॉग मेटाडेटा, और प्रोवाइडर-ओंड बेस URL पॉलिसी के साथ बंडल्ड प्रोवाइडर सेट में शामिल होता है।
[ALLOY]: यह एक वाइड प्रोवाइडर सरफेस है। इसका मतलब है कि DeepInfra सिर्फ एक टेक्स्ट एंडपॉइंट नहीं है। यह मॉडल डिस्कवरी, मल्टीमॉडल जेनरेशन, मीडिया अंडरस्टैंडिंग, स्पीच, वीडियो और एम्बेडिंग्स में भाग ले सकता है। एजेंट रनटाइम के लिए, वो कैपेबिलिटी फ्लैग्स मायने रखते हैं क्योंकि अलग-अलग टूल्स को अलग प्रोवाइडर असम्पशन चाहिए।
[NOVA]: OpenAI-कम्पैटिबल स्वचालित रूप से फुली अंडरस्टूड का मतलब नहीं है। एक कम्पैटिबल रिक्वेस्ट शेप मॉडल नेम्स, स्ट्रीमिंग बिहेवियर, टूल सपोर्ट, मीडिया सपोर्ट, एम्बेडिंग बिहेवियर, ऑथ सेटअप, फॉलबैक बिहेवियर और बेस URL ओनरशिप में बड़े अंतर छुपा सकता है। अगर रनटाइम हर कम्पैटिबल एंडपॉइंट को एक एनोनिमस URL की तरह ट्रीट करता है, तो कैटलॉग गेसेस का एक सेट बन जाता है।
[ALLOY]: एक प्रोवाइडर के रूप में DeepInfra को बंडल करके OpenClaw एक मैनेज्ड कॉन्ट्रैक्ट एक्सपोज करने देता है। प्रोवाइडर घोषणा कर सकता है कि ऑनबोर्डिंग कैसे काम करती है, कौन से कैटलॉग रो मौजूद हैं, कौन सी कैपेबिलिटीज़ उपलब्ध हैं, और कौन सी एंडपॉइंट पॉलिसी वो ओन करता है। यह हर यूजर को लोकल कॉन्फिग में वही प्रोवाइडर असम्पशन हैंड-बिल्ड करने पर मजबूर करने से बेहतर है।
[NOVA]: बिल्डर का निहितार्थ सीधा है। जब आप एजेंट रनटाइम में प्रोवाइडर जोड़ते हैं, तो बेस URL और API कुंजी पर न रुकें। मॉडल कैटलॉग, एलियस, सप्रेशन, मीडिया सपोर्ट, एम्बेडिंग व्यवहार, ऑथ हिंट्स और फेल्योर सेमांटिक्स को कैप्चर करें। प्रोवाइडर कॉन्ट्रैक्ट प्रोडक्ट का हिस्सा है।
[ALLOY]: चैनल विस्तार उसी रिलीज़ शेप का हिस्सा है। Tencent Yuanbao को ऑफिशियल कैटलॉग, कॉन्ट्रैक्ट सुइट्स और कम्युनिटी प्लगइन डॉक्स में एक्सटर्नल चैनल प्लगइन के तौर पर जोड़ा गया है, डॉक्स एंट्रेंस के साथ ताकि यह लिस्टिंग्स और साइडबार नेविगेशन में दिखे। QQBot को ग्रुप चैट सपोर्ट, हिस्ट्री ट्रैकिंग, मेंशन गेटिंग, एक्टिवेशन मोड्स, पर-ग्रुप कॉन्फ़िगरेशन, FIFO मैसेज क्यू, C2C मैसेज के लिए स्ट्रीमिंग, मीडिया अपलोड और पाइपलाइन रिफैक्टर्स मिलते हैं।
[NOVA]: चैनल का काम सिर्फ मैसेज के लिए ज़्यादा सर्फेस जोड़ने जैसा लग सकता है, लेकिन डिटेल्स ज़रूरी हैं। ग्रुप चैट डायरेक्ट चैट जैसी नहीं है। मेंशन गेटिंग मायने रखती है क्योंकि एजेंट को हर मैसेज का जवाब नहीं देना चाहिए। एक्टिवेशन मोड्स और पर-ग्रुप कॉन्फ़िग ज़रूरी हैं क्योंकि अलग-अलग रूम्स में अलग-अलग उम्मीदें होती हैं। FIFO क्यूज़ और डिबाउंस बिहेवियर ज़रूरी हैं क्योंकि स्ट्रीमिंग मैसेज मॉडल टर्न को सुरक्षित रूप से प्रोसेस करने से ज़्यादा तेज़ी से आ सकते हैं।
[ALLOY]: इसीलिए चैनल प्लगइन्स को कॉन्ट्रैक्ट टेस्ट्स की ज़रूरत है। रनटाइम को यह जानना चाहिए कि हिस्ट्री कैसे ट्रैक होती है, टारगेट कैसे रिज़ॉल्व होते हैं, मीडिया कैसे अपलोड होता है, रिप्लाइज़ कैसे गेटेड होते हैं और स्ट्रीमिंग लाइफसाइकल कैसे हैंडल होती है। वरना हर चैनल एक स्पेशल केस बन जाता है और रिलायबिलिटी की समस्याओं को मॉडल पर डाला जाता है, भले ही चैनल एडेप्टर टूटा हुआ हिस्सा हो।
[NOVA]: तो रिलीज़ का पहला पढ़ना यह है: कंप्यूटर यूज़ शुरू करने के लिए सुरक्षित हो गया है, प्रोवाइडर सपोर्ट ज़्यादा पूर्ण हो गया है और चैनल कवरेज ज़्यादा स्पष्ट हो गई है। ये सब ऑपरेटर सर्फेस हैं। ये इस पर असर डालते हैं कि एजेंट क्या कर सकता है, सिस्टम कैसे जानता है कि यह तैयार है और रनटाइम फेलियर्स को कैसे समझाता है।
[NOVA]: Docker sandbox बदलाव कागज़ पर छोटा है और व्यवहार में बहुत ज़रूरी है। OpenClaw जोड़ता है ऑप्ट-इन sandbox dot docker dot gpus passthrough Docker sandbox कंटेनरों के लिए जब होस्ट रनटाइम GPU एक्सेस सपोर्ट करता है।
[ALLOY]: ऑप्ट-इन पार्ट मायने रखता है। sandbox के अंदर GPU एक्सेस लोकल मॉडल सर्विंग, इमेज जेनरेशन, वीडियो प्रोसेसिंग, कंप्यूटर विज़न, एम्बेडिंग्स और इवैल्युएशन जॉब्स के लिए उपयोगी है। लेकिन यह एक रिसोर्स और ड्राइवर सर्फेस भी है जिसे आसानी से एक्सपोज़ नहीं करना चाहिए। GPU एक्सेस वाला sandboxed एजेंट VRAM खा सकता है, लंबे समय तक चलने वाली जॉब्स बना सकता है, ड्राइवर्स पर प्रेशर डाल सकता है, या अन्य लोकल वर्कलोड्स से टकरा सकता है।
[NOVA]: यही कॉन्फ़िग बाउंड्री को उपयोगी बनाता है। एक ऑपरेटर तय कर सकता है कि किन sandboxed वर्कलोड्स को GPU रिसोर्सेज़ देखने दिया जाए और किन्हें CPU-ओनली रहने दिया जाए। यह खासकर तब ज़रूरी है जब एजेंट डिपेंडेंसीज़ इंस्टॉल कर सकते हैं या मीडिया और मॉडल टूलिंग चला सकते हैं। एक स्पष्ट स्विच के बिना, लोकल मशीन एजेंट लोड के नीचे अप्रत्याशित हो सकती है।
[ALLOY]: व्यावहारिक सिफारिश यह है कि GPU passthrough को सिर्फ एक एक्सेलेरेशन फ्लैग की तरह नहीं, बल्कि एक रिसोर्स पॉलिसी की तरह सोचें। अगर जॉब को GPU चाहिए और ऑपरेटर वर्कलोड पर भरोसा करता है, तो इसे जानबूझकर enable करें। अगर जॉब जेनेरिक शेल एक्ज़ीक्यूशन, डॉक्यूमेंट प्रोसेसिंग या हल्का ऑटोमेशन है, तो GPU को कंटेनर से बाहर रखें।
[NOVA]: रिलीज़ में proxy dot enabled, proxy dot proxyUrl और OPENCLAW_PROXY_URL के ज़रिए ऑपरेटर-मैनेज्ड आउटबाउंड प्रॉक्सी रूटिंग भी जुड़ती है। नोट्स में सख्त HTTP फॉरवर्ड-प्रॉक्सी वैलिडेशन, लूपबैक-ओनली Gateway बायपास और एक्ज़िट पर प्रॉक्सी एनवायरनमेंट और डिस्पैचर स्टेट की क्लीनअप पर ज़ोर दिया गया है।
[ALLOY]: यह नियंत्रित egress के लिए सही संरचना है। कुछ इंस्टॉलेशन में सभी आउटबाउंड ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी, कंप्लायंस इंस्पेक्शन लेयर, नेटवर्क मॉनिटर, या प्रतिबंधित पाथ के ज़रिए रूट किया जाना चाहिए। लेकिन सभी ट्रैफ़िक का एक जैसा व्यवहार नहीं होना चाहिए। इंटरनल गेटवे ट्रैफ़िक और लूपबैक कम्युनिकेशन को गलती से बाहरी प्रॉक्सी के ज़रिए हेयरपिन नहीं करना चाहिए।
[NOVA]: क्लीनअप भी ज़रूरी है। प्रॉक्सी एनवायरनमेंट और डिस्पैचर स्टेट अनRELATED रन में लीक नहीं होने चाहिए और प्रोसेस के बाहर निकलने के बाद भी एक्टिव नहीं रहने चाहिए। अगर पुरानी प्रॉक्सी सेटिंग्स बनी रहती हैं, तो अगला रन कन्फ्यूज़िंग तरीके से फेल हो सकता है: प्रोवाइडर कॉल टाइम आउट हो जाते हैं, लोकल कनेक्शन गलत रूट हो जाते हैं, या डायग्नोस्टिक्स गलत नेटवर्क लेयर की ओर पॉइंट करते हैं।
[ALLOY]: बिल्डर्स के लिए पाठ यह है कि प्रॉक्सी सपोर्ट को एक्सप्लिसिट रनटाइम फीचर की तरह ट्रीट करें। URL वैलिडेट करें। बाइपास रूल्स को स्पष्ट रखें। सीक्रेट्स को लॉग्स से दूर रखें। प्रोसेस-लेवल स्टेट क्लीन करें। और फेलियर्स बताएं कि समस्या प्रोवाइडर ऑथ है, नेटवर्क रूट है, प्रॉक्सी रीचेबिलिटी है, या पॉलिसी है।
[NOVA]: गेटवे चैट अटैचमेंट बिहेवियर भी बेहतर हुआ है। चैट डॉट सेंड के ज़रिए नॉन-इमेज अटैचमेंट एजेंट-रीडेबल मीडिया पाथ के तौर पर स्टेज किए जा सकते हैं, जबकि अनसपोर्टेड RPC अटैचमेंट पाथ स्पष्ट रहते हैं - फाइलों को साइलेंटली ड्रॉप करने की बजाय।
[ALLOY]: साइलेंट ड्रॉपिंग एक बुरा फेलियर मोड है। अगर कोई यूज़र किसी एजेंट को फाइल भेजता है और फाइल गायब हो जाती है, तो मॉडल इनकंप्लीट कॉन्टेक्स्ट से जवाब दे सकता है बिना यह पता लगाए कि इनपुट कभी पहुंचा ही नहीं। यह फॉल्स कॉन्फिडेंस क्रिएट करता है। रनटाइम के लिए यह बताना बेहतर है कि अटैचमेंट स्टेज्ड और रीडेबल है, या पाथ अनसपोर्टेड और रिजेक्टेड है।
[NOVA]: चैनल डिलीवरी और एजेंट रीडेबिलिटी के बीच का अंतर भी ज़रूरी है। फाइल चैनल प्रोवाइडर द्वारा स्वीकार की जा सकती है, एजेंट के लिए स्टेज की जा सकती है, मैनेज्ड मीडिया पाथ में ट्रांसफॉर्म की जा सकती है, या लोअर-लेवल RPC रूट द्वारा रिजेक्ट की जा सकती है। ये अलग-अलग स्टेट्स हैं। एक रोबस्ट सिस्टम को इन्हें एक अस्पष्ट सक्सेस में नहीं गिराना चाहिए।
[ALLOY]: डिवाइस प्रेजेंस भी ज़्यादा प्रिसीज़ हो गया है। iOS और Android नोड्स कनेक्ट और बैकग्राउंड ट्रांज़िशन के बाद ऑथेंटिकेटेड नोड डॉट प्रेजेंस डॉट अलाइव इवेंट्स पब्लिश करते हैं। नोड लिस्ट लास्ट-सीन फील्ड्स एक्सपोज़ करती है ताकि बैकग्राउंड वेक्स पेयर्ड नोड्स को हाल ही में अलाइव मार्क कर सकें बिना उन्हें कनेक्टेड मानने के।
[NOVA]: यह अंतर सादा लेकिन ज़रूरी है। हाल ही में अलाइव होना कनेक्टेड होने के समान नहीं है। एक मोबाइल नोड वेक कर सकता है, लाइवनेस रिपोर्ट कर सकता है, और फिर बैकग्राउंड में वापस जा सकता है। अगर रनटाइम के पास सिर्फ एक बूलियन है, तो वह या तो यह ओवर-प्रॉमिस करता है कि डिवाइस अभी उपलब्ध है या यूज़फुल एविडेंस खो देता है कि डिवाइस अभी भी आसपास है।
[ALLOY]: लास्ट-सीन मेटाडेटा ऑपरेटर को एक ईमानदार व्यू देता है। नोड हाल ही में अलाइव था। यह ज़रूरी नहीं कि कनेक्टेड हो। यह डायग्नोस्टिक्स, स्केड्यूलिंग, UI स्टेटस, और यह तय करने में मदद करता है कि नोटिफिकेशन भेजना है, रिक्वेस्ट क्यू करना है, या यूज़र से डिवाइस फिर से खोलने के लिए कहना है।
[NOVA]: पेयरिंग-स्टेट फिक्स भी है: एरे-शेप्ड डिवाइस और नोड पेयरिंग स्टेट फाइल्स पर्सिस्ट करने से पहले रिकवर की जा सकती हैं, ताकि UUID-कीड पेंडिंग और पेयर्ड एंट्रीज़ मैलफॉर्म्ड JSON स्टोर राइट्स के बाद गायब नहीं होतीं। यह वही तरह की रिपेयर है जो मायने रखती है क्योंकि पेयरिंग स्टेट सिर्फ एक कैश नहीं है। यह गेटवे और पेयर्ड डिवाइसेस के बीच ट्रस्ट रिलेशनशिप है।
[ALLOY]: डिवाइस टोकन फिक्स उसी पैटर्न के अनुसार हैं। रिलीज पुन: उपयोग किए गए बासी डिवाइस टोकन को साफ करती है और Control UI और नोड गेटवे क्लाइंट में डिवाइस-टोकन मिसमैच पर फिर से कनेक्ट होने से रोकती है। इससे स्कोप अपग्रेड या टोकन-रोटेशन हैंडऑफ के बाद rate-limit loops से बचा जाता है।
[NOVA]: अगर टोकन मिसमैच बार-बार फिर से कनेक्ट हो रहा है, तो लक्षण अस्थिरता जैसा दिखता है, लेकिन मूल कारण है पहचान की स्थिति। सही व्यवहार है लूप को रोकना, बासी स्थिति साफ करना, और एक साफ-सुथरा हैंडऑफ जबरदस्ती करना। नहीं तो सिस्टम Gateway को बार-बार प्रहार करता रहेगा जबकि कभी वैध authorization state में नहीं पहुंचेगा।
[ALLOY]: इन बदलावों को एक साथ रखें और रिलीज़ कई अस्पष्ट स्थितियों को स्पष्ट बना रही है: GPU एक्सेस जानबूझकर है, proxy रूटिंग घोषित है, attachments स्पष्ट रूप से staged या rejected हैं, मोबाइल नोड्स alive या connected हैं, और device tokens valid या stale हैं। यही operator-grade software की जरूरत है।
[NOVA]: रिलीज़ का एक बड़ा हिस्सा plugin और model metadata को manifests में ले जाने के बारे में है ताकि Gateway को सिर्फ यह पता लगाने के लिए कि क्या मौजूद है, भारी-भरकम runtime surfaces import करने की जरूरत न पड़े।
[ALLOY]: Bundled plugin manifests अब explicit activation dot onStartup behavior घोषित करते हैं। Deprecated implicit startup sidecar loading को disable करने के लिए opt-in future-mode gate भी है, साथ ही compatibility warnings ताकि plugin authors explicit metadata की तरफ migrate कर सकें।
[NOVA]: व्यावहारिक बात है startup cost की। Gateway startup को हर plugin sidecar just import नहीं करनी चाहिए सिर्फ यह पता लगाने के लिए कि उस plugin को startup work की जरूरत है या नहीं। Imports dependency trees खींच सकते हैं, checks perform कर सकते हैं, side effects trigger कर सकते हैं, और boot को धीमा कर सकते हैं। जब कोई सिस्टम कई bundled और community plugins support करता है, implicit startup loading हर launch पर एक tax बन जाता है।
[ALLOY]: Explicit activation metadata Gateway को एक सस्ता plan देता है। manifest बताती है कि startup activation जरूरी है या नहीं। Runtime सिर्फ वही load कर सकता है जो intentional है। Legacy plugins अभी के लिए fallback path रखते हैं, लेकिन warnings authors को नए contract की तरफ guide करती हैं।
[NOVA]: Model catalogs को भी वही treatment मिलती है। रिलीज़ manifest modelCatalog aliases और suppressions को model-catalog planning और built-in model suppression में wire करती है। Qianfan, Xiaomi, NVIDIA, Cerebras, Mistral, Moonshot, DeepSeek, Tencent TokenHub, StepFun, BytePlus, Volcano Engine, Fireworks, और Together AI के लिए provider catalogs plugin manifest rows की तरफ बढ़ रहे हैं।
[ALLOY]: यह मायने रखता है क्योंकि model lists infrastructure हैं। Runtime को जवाब देना होता है कि कौन से models मौजूद हैं, किस provider का कौन सा model है, कौन से aliases valid हैं, कौन से rows hidden होने चाहिए, और कौन सा endpoint shape इस्तेमाल होना चाहिए। अगर यह जानकारी core runtime में hard-coded है, तो वह stale हो जाती है। अगर हर provider import करके discover की जाती है, तो startup और list commands भारी हो जाते हैं।
[NOVA]: Manifest-backed rows product को एक ज्यादा inspectable shape देती हैं। कोई provider plugin catalog rows, aliases, suppressions, और fixed metadata declare कर सकता है। Gateway plugin metadata को बार-बार rebuild करने के बजाय provider discovery के लिए metadata snapshot reuse कर सकता है। Startup config validation से plugin metadata snapshot को bootstrap में pass कर सकता है।
[ALLOY]: यह बार-बार का काम कम करता है और कैटलॉग व्यवहार की ऑडिटिंग आसान बनाता है। अगर किसी पुराने Spark या Qwen Coding Plan रो को दबाया जाना चाहिए, तो वह दबाव प्रदाता के मेटाडेटा में रहता है, न कि बिखरे हुए कंडीशनल्स में। अगर किसी प्रदाता के उपनाम हैं, तो वे मॉडल कॉन्ट्रैक्ट के हिस्से के रूप में घोषित होते हैं।
[NOVA]: यह रिलीज़ मेनिफेस्ट कॉन्ट्रैक्ट्स से ऑन-डिमांड बंडल्ड एजेंट टूल-रेज़ल्ट मिडलवेयर को भी हटाती है ताकि टोकनज्यूस स्टार्टअप-लेज़ी बना रहे बिना Pi और Codex टूल-आउटपुट कंप्रेशन खोए। यह रनटाइम की लागत तभी देने का एक और उदाहरण है जब क्षमता की ज़रूरत हो।
[ALLOY]: यह एजेंट प्लेटफॉर्म्स के लिए एक उपयोगी पैटर्न है। क्षमता मेटाडेटा जल्दी घोषित करें। भारी कार्यान्वयन बाद में लोड करें। स्टार्टअप को पूर्वानुमेय रखें। लिस्ट कमांड्स को सस्ता रखें। प्रदाता और प्लगइन व्यवहार को ऑडिट करने योग्य बनाएं।
[NOVA]: SDK और टेस्टिंग में बदलाव उस दिशा को मज़बूत करते हैं। यह रिलीज़ शेयर्ड चैनल रूट नॉर्मलाइज़ेशन, पार्सर-संचालित टारगेट रिज़ॉल्यूशन, रॉ-टारगेट कॉम्पैक्ट कुंजियों, पार्स्ड-टारगेट टाइप्स और रूट तुलना हेल्पर्स को OpenClaw प्लगइन SDK चैनल-रूट के माध्यम से एक्सपोज़ करती है। यह एजेंट रनटाइम कॉन्ट्रैक्ट्स, जेनरिक फिक्सचर्स, चैनल एक्शन्स, चैनल टारगेट केसिस, प्लगइन रनटाइम, प्रदाता क्षमता असर्शन, मीडिया प्रदाता मॉक्स और कॉन्ट्रैक्ट फिक्सचर्स के लिए फोकस्ड टेस्ट हेल्पर्स भी एक्सपोज़ करती है।
[ALLOY]: यह आंतरिक इंजीनियरिंग जैसा लगता है, लेकिन एक्सटेंशन लेखकों के लिए इसका महत्व है। अगर टेस्ट रेपो-ओनली हेल्पर डायरेक्टरीज़ से इम्पोर्ट करते हैं, तो प्लगइन डेवलपर प्राइवेट इम्प्लीमेंटेशन स्ट्रक्चर पर निर्भर हैं। जब वे हेल्पर्स हिलते हैं, टेस्ट टूट जाते हैं। फोकस्ड SDK सबपाथ्स लेखकों को डॉक्यूमेंटेड सरफेस देते हैं ताकि वे चैनल टारगेट्स, सेटअप, स्टेटस, रिएक्शन्स, मीडिया क्षमताओं, रनटाइम फिक्सचर्स और प्रदाता व्यवहार को टेस्ट कर सकें।
[NOVA]: चैनल रूट नॉर्मलाइज़ेशन एक अच्छा उदाहरण है। एक चैनल टारगेट यूज़र द्वारा टाइप किया जा सकता है, प्लगइन द्वारा पार्स किया जा सकता है, स्टोरेज के लिए कॉम्पैक्ट किया जा सकता है, दूसरे टारगेट के साथ तुलना की जा सकती है, और लॉग्स में डिस्प्ले किया जा सकता है। अगर हर चैनल इसे अलग तरीके से इम्प्लीमेंट करता है, तो अप्रूवल्स और डिलीवरी भंगुर हो जाते हैं। शेयर्ड रूट हेल्पर्स व्यवहार को सुसंगत बनाते हैं।
[ALLOY]: प्रदाता कैटलॉग्स के लिए भी यही सच है। किसी प्रदाता को यह सत्यापित करने के लिए कि कैटलॉग रो वैध है, मुख्य रिपॉजिटरी से प्राइवेट टेस्ट हेल्पर कॉपी करने की ज़रूरत नहीं होनी चाहिए। उसे एक पब्लिक SDK टेस्टिंग सरफेस का उपयोग करना चाहिए जो रनटाइम कॉन्ट्रैक्ट से मेल खाता हो।
[NOVA]: बिल्डर के लिए यह बात यह है कि जब कॉन्ट्रैक्ट्स स्पष्ट और टेस्टेबल बनते हैं तो प्लगइन सिस्टम्स परिपक्व होते हैं। मेनिफेस्ट-फर्स्ट मेटाडेटा स्टार्टअप और मॉडल डिस्कवरी में मदद करता है। फोकस्ड SDK हेल्पर्स प्लगइन लेखकों को प्राइवेट कोड में जाए बिना कॉन्ट्रैक्ट इम्प्लीमेंट करने में मदद करते हैं। एक साथ, वे बदलाव रनटाइम को कम जादुई और संचालित करने में आसान बनाते हैं।
[NOVA]: v2026.4.27 में फिक्स लिस्ट लंबी है, इसलिए इसे पढ़ने का उपयोगी तरीका ऑपरेटर पेन कैटेगरी द्वारा है। पहली कैटेगरी: चैनल डिलीवरी।
[ALLOY]: Telegram अप्रूवल्स exec और प्लगइन टारगेट अकाउंट IDs का सम्मान करके बेहतर मल्टी-बॉट नेटिव अप्रूवल रूटिंग हासिल करता है जबकि किसी भी अकाउंट के लिए अनस्कोप्ड Telegram टारगेट्स को प्रिज़र्व करता है। यह आउटबाउंड Bot API कॉल्स को बाउंड भी करता है और बंडल्ड प्लगइन अलियास लुकअप को कैश करता है ताकि धीमे Telegram सेंड्स या WSL2 फाइलसिस्टम स्कैन Gateway रिप्लाईज़ को अब वेज न करें।
[NOVA]: यह मायने रखता है क्योंकि एक Telegram bot send को पूरे reply path को अनिश्चित काल तक block करने में सक्षम नहीं होना चाहिए। एक धीमा channel provider सामान्य है। runtime को call को bounded करना होगा, failure report करने के लिए पर्याप्त context रखना होगा, और repeated expensive lookup work से बचना होगा।
[ALLOY]: Slack को डिफ़ॉल्ट रूप से fifteen-second SDK pong timeout मिलता है, साथ ही configurable client ping timeout, server ping timeout, और ping-pong logging। Slack media handling private file और forwarded attachment downloads को idle और total timeouts के साथ bounded करता है जबकि placeholder fallback को preserve रखता है।
[NOVA]: फिर से, failure mode hanging है। एक stale websocket या stalled file download inbound message handling को wedge नहीं करना चाहिए। product को timeout boundaries और fallback behavior चाहिए ताकि यह responsive बना रहे चाहे channel provider धीमा हो या file stuck हो।
[ALLOY]: यह release Telegram cron topic और thread IDs के साथ thread targeting को भी preserve करता है, regular Mattermost inbound posts को system events के रूप में duplicating से रोकता है, और LINE inbound media को managed media storage के तहत store करता है temporary paths के बजाय जो agent के read करने से पहले disappear हो सकते हैं।
[NOVA]: ये channel-specific details हैं, लेकिन ये सब एक ही operational need की ओर इशारा करते हैं: delivery context को sufficiently survive करना चाहिए, right thread को target करना चाहिए, और duplicate या disappear नहीं होना चाहिए। Multi-channel agents boring edges में fail होते हैं: forum topics, attachments, stale downloads, duplicate event paths, और temporary media files।
[ALLOY]: Second category: async media and tasks। Detached video_generate और music_generate tool run contexts terminal status तक registered रहते हैं, ताकि Discord-backed provider jobs tasks में live रहें parent chat run context disappear होने पर lost न हों। Long-running video और music tasks свежие रहते हैं जब तक provider jobs pending हैं। Session-scoped task records agent ownership infer करते हैं ताकि task fallback में session-backed media jobs शामिल हों।
[NOVA]: यह user trust के लिए important है। एक video generation job उस chat turn से ज़्यादा time तक outlive कर सकती है जिसने उसे launch किया। अगर task table ownership खो देता है या इसे lost mark करता है जबकि provider अभी भी render कर रहा है, तो user एक broken workflow देखता है चाहे underlying job eventually succeed हो। External job को terminal status तक track करना सही model है।
[ALLOY]: Third category: sessions, provider replay, और model defaults। chat.history और sessions.list thinking defaults owning-agent और catalog-aware resolution के साथ align करते हैं, ताकि Control UI session defaults backend runtime state से मेल खाएं। DeepSeek V4 reasoning content plain assistant replay messages के साथ-साथ tool-call turns पर भी backfilled होती है। Anthropic beta headers direct public Anthropic endpoints तक constrained हैं custom compatible providers के बजाय। Config patch और apply tool responses replay history से full config payloads strip करते हैं जबकि direct RPC responses preserve करते हैं।
[NOVA]: ये fixes state drift से बचने के बारे में हैं। एक agent runtime में, current model, provider headers, thinking mode, replay messages, और tool histories सब अगले request का हिस्सा बन जाते हैं। अगर वह state गलत है, तो follow-up turns strange ways में fail होते हैं: missing reasoning content, wrong provider headers, giant redacted configs context में replayed, या UI defaults जो backend behavior से मेल नहीं खाते।
[ALLOY]: Fourth category: startup, update, और dependency hygiene। Gateway startup chat channels को primary model prewarm का इंतज़ार किए बिना start करता है, model warmup को background में bounded रखता है। Update sync config में disabled tracked plugins skip करता है। Runtime dependency handling stale retained bundled deps prune करती है, unchanged mirror materialization decisions cache करती है, owner-write failures पर file-lock handles close करती है, और doctor और secret channel scans को lightweight रखती है।
[NOVA]: यहाँ पर यूज़र्स परफॉर्मेंस को रिलायबिलिटी के रूप में अनुभव करते हैं। अगर चैनल मॉडल प्रीवर्म का इंतज़ार कर रहे हैं, तो स्लो प्रोवाइडर डिस्कवरी पाथ पूरे चैट सरफेस को देरी कर सकता है। अगर डिसेबल्ड प्लगइन्स अभी भी सिंक हो रहे हैं, तो अपडेट उन चीज़ों पर फेल हो सकते हैं जिन्हें ऑपरेटर ने जानबूझकर बंद किया था। अगर डिपेंडेंसी मिरर्स और फाइल लॉक्स खराब व्यवहार कर रहे हैं, तो रीस्टार्ट अनप्रेडिक्टेबल हो जाते हैं।
[ALLOY]: पाँचवीं कैटेगरी: कमांड और ऑटो-रिप्लाई व्यवहार। बेयर रीसेट और न्यू कमांड रीसेट हुक कमांड को एक्नॉलेज करने के बाद रुक जाते हैं, जबकि मैसेज के साथ रीसेट अभी भी अगले मॉडल टर्न को सीड करता है। स्लैक रीसेट फ्रेज़ डायरेक्टिव क्लीनअप के बाद न्यू सेशन बॉडी से बाहर रखे जाते हैं। साइलेंट टर्न से वॉइस-नोट मीडिया प्रिज़र्व्ड रहता है जबकि टेक्स्ट और नॉन-वॉइस मीडिया सप्रेस्ड रहता है, इसलिए NO_REPLY TTS रिप्लाईज़ अभी भी रिक्वेस्टेड ऑडियो बबल डिलीवर करती हैं।
[NOVA]: यह एक अच्छा रिमाइंडर है कि कमांड राउटिंग एक प्रोडक्ट सरफेस है। एक रीसेट कमांड को एक्सिडेंटली खाली मॉडल कॉल में नहीं गिरना चाहिए। एक रीसेट फ्रेज़ को अगले प्रॉम्प्ट में लीक नहीं होना चाहिए। साइलेंट TTS व्यवहार को अभी भी वह ऑडियो डिलीवर करना चाहिए जो यूज़र ने रिक्वेस्ट किया था।
[ALLOY]: रिलीज़ वर्डिक्ट स्पष्ट है। यह एक रनटाइम-ऑपरेशन रिलीज़ है। यह कंप्यूटर यूज़ को शुरू करने में सुरक्षित बनाता है, प्रोवाइडर्स को ऑनबोर्ड करना आसान बनाता है, सैंडबॉक्सेस को ज़्यादा कैपेबल बनाता है, चैनल डिलीवरी को कम फ्रैज़ाइल बनाता है, प्लगइन स्टार्टअप को कम हेवी बनाता है, मॉडल कैटलॉग्स को ज़्यादा ऑडिटेबल बनाता है, लॉन्ग-रनिंग मीडिया जॉब्स को खोना मुश्किल बनाता है, और सेशन रीप्ले को अगले टर्न को पॉइज़न करने की संभावना कम होती है।
[NOVA]: इस रिलीज़ में अपग्रेड करने वाले ऑपरेटर्स के लिए, प्रैक्टिकल रिव्यू लिस्ट स्पष्ट है। डेस्कटॉप कंट्रोल का उपयोग करने पर Codex Computer Use स्टेटस चेक करें। तय करें कि किसी Docker सैंडबॉक्स को GPU पासथ्रू मिलना चाहिए या नहीं। अगर आपके नेटवर्क को कंट्रोल्ड एग्रेस की ज़रूरत है, तो प्रॉक्सी सेटिंग्स को जानबूझकर टेस्ट करें। प्रोवाइडर कैटलॉग्स और DeepInfra ऑनबोर्डिंग रिव्यू करें अगर आप वह प्रोवाइडर सरफेस चाहते हैं। टेलीग्राम, स्लैक, मीडिया अटैचमेंट्स और लॉन्ग-रनिंग मीडिया जॉब्स के आसपास चैनल व्यवहार देखें। और प्लगइन स्टार्टअप वार्निंग्स को शोर नहीं, माइग्रेशन गाइडेंस के रूप में ट्रीट करें।
[NOVA]: स्टोरी टू: Deepgram Flux Multilingual वॉइस-एजेंट STT को टर्न-टेकिंग रनटाइम प्रॉब्लम बनाता है। लेकिन चलिए इसे OpenClaw तरीके से फ्रेम करते हैं, न कि नॉब्स की लिस्ट के रूप में। कैपेबिलिटी सिम्पल है: एक वॉइस एजेंट एक मल्टीलिंगुअल बातचीत सुन सकता है, जब स्पीकर भाषा बदलता है तो ध्यान दे सकता है, तय कर सकता है कि व्यक्ति असल में बोलना खत्म कर चुका है या नहीं, और एजेंट को क्लीन टर्न तेज़ी से दे सकता है ताकि बातचीत अभी भी लाइव महसूस हो।
[ALLOY]: यह मायने रखता है क्योंकि वॉइस एजेंट बहुत इंसानी तरीकों से ब्रेक होते हैं। अगर स्पीच लेयर आपको बहुत जल्दी काट देती है, तो एजेंट इंटरप्ट करता है। अगर यह बहुत देर तक इंतज़ार करती है, तो अनुभव डेड जैसा लगता है। अगर यह गलत भाषा मान लेती है, तो यह नामों, कमांड्स और इंटेंट को खराब कर देती है। अगर यह कोड स्विचिंग हैंडल नहीं कर सकती, तो बाइलिंगुअल यूज़र्स को खुद को मशीन के अनुकूल ढालना पड़ता है, मशीन को खुद के अनुकूल नहीं।
[NOVA]: Flux Multilingual दिलचस्प है क्योंकि यह स्पीच रिकग्निशन को उस रनटाइम प्रॉब्लम के करीब लाता है। यह मेजर भाषाओं की स्पोर्ट करता है, जिसमें इंग्लिश, स्पैनिश, फ्रेंच, जर्मन, हिंदी, रशियन, पुर्तगाली, जैपनीज़, इटैलियन और डच शामिल हैं, और यह कोड स्विचिंग के लिए डिज़ाइन किया गया है। प्रोडक्ट पॉइंट यह नहीं है कि मॉडल आइडेंटिफायर याद करें। प्रोडक्ट पॉइंट यह है कि रिकग्नाइज़र एक लाइव वॉइस लूप का हिस्सा हो सकता है जहाँ भाषा और टर्न बाउंड्रीज़ सिग्नल हैं जिनका एजेंट उपयोग कर सकता है।
[ALLOY]: OpenClaw के लिए, यह महत्वपूर्ण कनेक्शन है। OpenClaw को लो-लेवल वायरिंग छिपानी चाहिए। एक बिल्डर को यह नहीं सोचना चाहिए कि मुझे कौन सा WebSocket पाथ ओपन करना है, कौन सा एक्ज़ैक्ट इवेंट फील्ड लैंग्वेज डिटेक्शन लेकर आता है, या कौन सा थ्रेशोल्ड नेम साइलेंस कंट्रोल करता है। OpenClaw यह सब ओन कर सकती है। बिल्डर-फेसिंग कैपेबिलिटी यह होनी चाहिए: यह एजेंट कई भाषाओं में सुन सकता है, एक्टिव लैंग्वेज डिटेक्ट कर सकता है, बहुत एग्रेसिवली इंटरप्ट करने से बच सकता है, और जब बातचीत अस्पष्ट हो तो कॉन्फिडेंस या टर्न-स्टेट सरफेस कर सकता है।
[NOVA]: बिल्कुल। उपयोगी टेक्निकल डिटेल कैपेबिलिटी का शेप है। Flux लैंग्वेज हिंट्स प्रोवाइड कर सकता है, डिटेक्टेड-लैंग्वेज इनफॉर्मेशन एमिट कर सकता है, और टर्न-एंडिंग बिहेवियर एक्सपोज़ कर सकता है। ये सिर्फ़ कॉन्फिगरेशन ट्रिविया नहीं हैं। ये वो इंग्रीडिएंट्स हैं जिनका उपयोग OpenClaw वॉइस इंटरैक्शन्स को कम ब्रिटल बनाने के लिए कर सकता है। अगर कोई यूज़र इंग्लिश में शुरू करता है और हिंदी या पुर्तगाली में एक फ्रेज़ ड्रॉप करता है, तो एजेंट को अचानक थ्रेड नहीं खोना चाहिए। अगर कोई यूज़र बीच में रुक जाता है, तो सिस्टम को तुरंत गलत जवाब के साथ कूदना नहीं चाहिए।
[ALLOY]: और ज़रूर असली मुश्किलें हैं, लेकिन वो operational मुश्किलें हैं, command-line homework नहीं। सबसे बड़ी समस्या capacity की है। Realtime speech को predictable latency के साथ चलनी चाहिए। अगर speech model गलत hardware पर रखा गया है, अगर बहुत सारे calls एक ही node पर आ जाते हैं, या अगर speech layer बिना किसी संबंध के workloads के साथ competition कर रहा है, तो user तुरंत सुन लेता है। Failure mode कोई abstract benchmark problem नहीं है। ये awkward pauses, missed words, dropped calls, और agents हैं जो rude या slow लगते हैं।
[NOVA]: यहीं पर OpenClaw value add कर सकता है। Low-level settings का एक pile expose करने की बजाय, OpenClaw voice को एक managed runtime की तरह treat कर सकता है: capacity reserve करना, report करना कि system कितने live streams handle कर सकता है, warning देना जब deployment under-provisioned है, और responsiveness, accuracy, और concurrency के बीच tradeoff स्पष्ट करना। Operator को health signals मिलने चाहिए, speech-engine configuration में treasure hunt नहीं।
[ALLOY]: Dedicated-runtime guidance को capability idea में translate करना भी worth है। Voice सिर्फ एक और batch job नहीं है। ये latency-sensitive है। तो एक production voice agent को isolation चाहिए। उसे काफी GPU memory चाहिए। उसे monitoring चाहिए। उसे graceful overload behavior चाहिए। अगर capacity full है, तो system intentionally degrade करना चाहिए, ये झूठ बोलने की बजाय कि सब ठीक है जब तक कि conversation collapse न हो जाए।
[NOVA]: यही वजह है कि turn-taking को उतना attention मिलना चाहिए जितना आमतौर पर मिलता है। एक text agent कुछ seconds wait कर सकता है और फिर भी usable लग सकता है। एक voice agent नहीं कर सकता। एक helpful voice assistant और unusable एक के बीच का फर्क कुछ hundred milliseconds हो सकता है, या एक premature end-of-turn decision। तो जब हम Flux के बारे में बात करते हैं, takeaway ये नहीं है कि यहां exact parameter names हैं। Takeaway ये है: modern speech models agent runtimes को language और turn state के बारे में ज़्यादा signals दे रहे हैं, और OpenClaw को those signals को better defaults में turn करना चाहिए।
[ALLOY]: Builder story बहुत cleaner हो जाती है। आप जो user experience चाहते हैं describe करते हैं: multilingual support, natural interruptions, low-latency response, maybe sensitive actions के लिए stricter confirmation। OpenClaw उसको speech runtime पर map करता है, monitor करता है कि deployment keep up कर पा रहा है या नहीं, और right warnings expose करता है जब नहीं कर पा रहा।
[NOVA]: तो Flux Multilingual relevant है क्योंकि ये expand करता है कि एक voice agent reliably क्या hear कर सकता है और कब respond कर सकता है। OpenClaw angle orchestration है। Speech recognition managed conversation loop में एक component बन जाती है: listen करो, language detect करो, turn state decide करो, agent invoke करो, speak back करो, और पूरे loop को fast enough रखो कि natural feel हो।
[NOVA]: Story three: Google Rapid Bucket Brings Colossus into the PyTorch Data Path। इसको भी right framing चाहिए। Point ये नहीं है कि हर builder को storage calls hand-write करने चाहिए। Point ये है कि AI systems अक्सर fail करते हैं क्योंकि model data, artifacts, checkpoints, या generated files के लिए wait कर रहा है। Storage AI runtime का part बन जाती है।
[ALLOY]: ये खासकर तब true होता है जब एक workflow demo से बड़ी हो जाती है। Training jobs को datasets चाहिए। Evaluation jobs को artifacts चाहिए। RAG systems को indexes और documents चाहिए। Media agents को images, audio, और video चाहिए। Fine-tuning jobs को checkpoints चाहिए। एक ordinary agent pipeline भी files को एक जगह से दूसरी जगह move करने में surprising amount of time spend कर सकता है। अगर storage path slow है या badly placed है, तो expensive compute idle बैठा रहता है।
[NOVA]: Rapid Bucket Google का एक specific version of that problem के लिए answer है: object-storage path को AI और data workloads के लिए faster बनाना, Colossus को ज़्यादा directly use करके, connections alive रखकर, और storage को compute के close रखकर। Show notes में PyTorch, gcsfs, और fsspec का mention है क्योंकि ये Python AI workflows में common layers हैं। लेकिन OpenClaw-level lesson simpler है: एक good agent platform को workload change होने पर right artifact path automatically choose और manage करनी चाहिए।
[ALLOY]: सही। Builders को storage plumbing know किए बिना उससे benefit मिलनी चाहिए। अगर कोई workflow बड़ा dataset read कर रहा है, frequent checkpoints write कर रहा है, या generated media को steps के बीच move कर रहा है, तो OpenClaw recognize कर सकता है कि artifact path matters। वो hot work के लिए local या zonal storage prefer कर सकता है, durable copies को कहीं safer push कर सकता है, और warning दे सकता है जब compute और storage regions या zones में एक दूसरे से fight कर रहे हैं।
[NOVA]: वह क्षमता विवरण जो मायने रखता है वह स्थानीयता है। अगर ट्रेनिंग या जनरेशन जॉब एक ज़ोन में है और गर्म डेटा उसी ज़ोन में है, तो सिस्टम अनावश्यक लेटेंसी और थ्रूपुट पेनल्टी से बच सकता है। अगर डेटा दूर है, तो परफॉर्मेंस प्रभावित होती है। यह बोरिंग लगता है जब तक आप accelerators के लिए पैसे दे रहे हैं जो इनपुट का इंतज़ार कर रहे हैं। फिर स्टोरेज प्लेसमेंट एक लागत और विश्वसनीयता मुद्दा बन जाता है।
[ALLOY]: स्थायित्व के संदर्भ में एक ट्रेड-ऑफ भी है। सबसे तेज़ स्टोरेज पथ हमेशा सबसे सुरक्षित दीर्घकालिक रिकॉर्ड नहीं होता। एक गर्म ज़ोनल बकेट किसी जॉब को जल्दी से फीड करने के लिए बढ़िया हो सकता है, लेकिन महत्वपूर्ण चेकपॉइंट और अंतिम आउटपुट को क्षेत्रीय या मल्टी-रीजन स्टोरेज में कॉपी करना पड़ सकता है। यह गॉचा ज़ोर देकर कहने योग्य है: गर्म कार्य पथ को टिकाऊ स्रोत-की-सत्य पथ से अलग करें।
[NOVA]: यह सीधे OpenClaw वर्कफ़्लोज़ पर मैप होता है। एक OpenClaw टास्क की कल्पना करें जो वीडियो का एक बैच जनरेट करता है, मॉडल आउटपुट का मूल्यांकन करता है, एम्बेडिंग बनाता है, या फाइन-ट्यूनिंग प्रयोग चलाता है। यूज़र को हर इंटरमीडिएट फ़ाइल कहाँ है यह मैनेज करने की ज़रूरत नहीं होनी चाहिए। OpenClaw को पता होना चाहिए कि कौन सी फ़ाइलें अस्थायी हैं, कौन सी समीक्षा एसेट्स हैं, कौन सी फ़ाइलें अंतिम प्रकाशन-योग्य आर्टिफैक्ट्स हैं, और कौन सी फ़ाइल्स को टिकाऊ बैकअप की ज़रूरत है।
[ALLOY]: और मॉनिटरिंग को वर्कफ़्लो शब्दों में बात करनी चाहिए। यूज़र को निम्न-स्तरीय फ़ाइल एब्स्ट्रैक्शन इंस्पेक्ट करने को न कहें, इसके बजाय OpenClaw कह सकता है: आपका जॉब डेटा का इंतज़ार कर रहा है, आपके चेकपॉइंट राइट्स रन को धीमा कर रहे हैं, आपका स्टोरेज इस कंप्यूट के लिए गलत स्थानीयता पर है, या आपकी टिकाऊ कॉपी अभी तक पूरी नहीं हुई है। यह क्षमता-स्तरीय तकनीकी विवरण है। यह बताता है कि सिस्टम क्या कर सकता है और क्या गलत हो सकता है बिना एपिसोड को सेटअप गाइड में बदले।
[NOVA]: Rapid Bucket भी आधुनिक AI प्लेटफ़ॉर्म के बारे में एक व्यापक बिंदु को पुनः प्रबलित करता है। परफॉर्मेंस केवल मॉडल क्वालिटी नहीं है। यह मॉडल के आसपास का पथ है: स्टोरेज, कतारें, स्ट्रीम्स, कैशेस, रनटाइम, अनुमतियां, और ऑब्जर्वेबिलिटी। मॉडल शायद स्टार है, लेकिन सहायक इन्फ्रास्ट्रक्चर तय करता है कि वर्कफ़्लो फास्ट, सस्ता, और निर्भर है या नहीं।
[ALLOY]: तो OpenClaw का टेकअवे यह है कि स्टोरेज को एजेंट रनटाइम का एक बुद्धिमान हिस्सा बनाएं। छोटे जॉब्स के लिए, इसे सimple रखें। भारी डेटा या मीडिया काम के लिए, जब मदद करता है तो तेज़ गर्म स्टोरेज का उपयोग करें। महत्वपूर्ण आउटपुट्स के लिए, उन्हें टिकाऊ स्टोरेज में प्रमोट करें। यूज़र्स के लिए, क्षमता और गॉचाज़ को एक्सपोज़ करें, इम्प्लीमेंटेशन डिटेल्स का पेज नहीं।
[NOVA]: यह Rapid Bucket का उपयोगी पढ़ना है। यह माँग नहीं है कि हर builder एक नया स्टोरेज API सीखे। यह सबूत है कि AI इन्फ्रास्ट्रक्चर असली bottlenecks के आसपास विशेषज्ञ हो रहा है। OpenClaw को उन विवरणों को अवशोषित करना चाहिए और ऑपरेटर को एक साफ़ वादा देना चाहिए: मैं आपका डेटा काम के पास रख सकता हूँ, आपके आर्टिफैक्ट्स व्यवस्थित रख सकता हूँ, और आपको बता सकता हूँ जब स्टोरेज पथ जॉब धीमा होने की वजह है।
[ALLOY]: एक साथ मिलाकर, EP043 वास्तव में raw तकनीकी सतहों को उपयोगकर्ता ऑपरेटर क्षमताओं में बदलने के बारे में है।
[NOVA]: OpenClaw v2026.4.27 उस पैटर्न को प्रोडक्ट के अंदर जोड़ता है: बेहतर computer-use तत्परता, प्रोवाइडर सपोर्ट, GPU कंटेनर हैंडलिंग, प्रॉक्सी कंट्रोल, चैनल विश्वसनीयता, अटैचमेंट्स, नोड प्रेजेंस, मैनिफेस्ट-बैक्ड स्टार्टअप, मॉडल कैटलॉग्स, और SDK क्लीनअप।
[ALLOY]: Deepgram Flux Multilingual आवाज़ में वही पैटर्न दिखाता है। विवरण हैं भाषा पहचान, टर्न-टेकिंग, रियलटाइम क्षमता, और रनटाइम आइसोलेशन। यूज़र-फेसिंग क्षमता एक वॉइस एजेंट है जो बहुभाषी भाषण को स्वाभाविक रूप से संभाल सकता है और बिना अजीब टाइमिंग फेलियर्स के जवाब दे सकता है।
[NOVA]: Google Rapid Bucket स्टोरेज में दिखाता है। डिटेल्स हैं locality, hot paths, faster object access, checkpoints, और durability। यूज़र-फेसिंग कैपेबिलिटी एक AI वर्कफ़्लो है जो डेटा को compute के करीब रखता है, accelerators को खिलाया रखता है, और ज़रूरी artifacts को सुरक्षित स्टोरेज में प्रमोट करता है।
[ALLOY]: गलती यह है कि builders को हर low-level detail खुद संभालने को कहना। मौका यह है कि OpenClaw को wiring अवशोषित करने दें और useful controls एक्सपोज़ करें: क्या possible है, क्या risky है, क्या slow है, और सिस्टम इसके बारे में क्या कर रहा है।
[NOVA]: OpenClaw Daily के लिए बस इतना। पूरे शो नोट्स और सोर्स लिंक एपिसोड नोट्स में हैं। अगर आप OpenClaw के साथ बना रहे हैं, तो बाउंड्रीज़ देखते रहें: computer use readiness, voice runtime behavior, और artifact storage। सबसे अच्छे agent systems सिर्फ models को call नहीं करते। वे मॉडल के आसपास के environment को manage करते हैं ताकि काम असल में पूरा हो। जल्दी वापस आएंगे। ...