मॉडल से एजेंट तक: Responses API को कंप्यूटर एनवायरनमेंट से लैस करना

हम अभी उस बदलाव के दौर में हैं जहाँ खास टास्क में बेहतर मॉडल्स से आगे बढ़कर जटिल वर्कफ़्लो संभालने वाले एजेंट्स का उपयोग किया जा रहा है. मॉडल्स को प्रॉम्प्ट करके आप केवल उनकी ट्रेन की हुई इंटेलिजेंस तक ही पहुँच सकते हैं. लेकिन मॉडल को कंप्यूटर एनवायरनमेंट देने से आप कहीं ज्यादा व्यापक यूज़ केसेस हासिल कर सकते हैं, जैसे सर्विसेज़ चलाना, APIs से डेटा रिक्वेस्ट करना, या स्प्रेडशीट्स और रिपोर्ट्स जैसे ज्यादा उपयोगी आर्टिफैक्ट्स जनरेट करना.

जब आप एजेंट्स बनाते हैं, तो कुछ व्यावहारिक समस्याएँ सामने आती हैं: इंटरमीडिएट फाइल्स कहाँ रखें, बड़े टेबल्स को प्रॉम्प्ट में पेस्ट करने से कैसे बचें, वर्कफ़्लो को नेटवर्क एक्सेस कैसे दें बिना सिक्योरिटी जोखिम बढ़ाए, और बिना खुद का वर्कफ़्लो सिस्टम बनाए टाइमआउट्स और रिट्राइज को कैसे संभालें.

डेवलपर्स पर अपना खुद का एक्जीक्यूशन एनवायरनमेंट बनाने की ज़िम्मेदारी डालने के बजाय, हमने Responses API⁠(एक नई विंडो में खुलेगा) को कंप्यूटर एनवायरनमेंट से लैस करने के लिए ज़रूरी कॉम्पोनेंट्स बनाए, ताकि वास्तविक दुनिया के टास्क भरोसेमंद तरीके से एक्सीक्यूट किए जा सकें.

OpenAI का Responses API, शेल टूल और होस्टेड कंटेनर वर्कस्पेस के साथ मिलकर, इन व्यावहारिक समस्याओं को हल करने के लिए डिज़ाइन किया गया है. मॉडल स्टेप्स और कमांड्स प्रस्तावित करता है; प्लेटफ़ॉर्म उन्हें एक आइसोलेटेड एनवायरनमेंट में चलाता है जहाँ इनपुट और आउटपुट के लिए फाइलसिस्टम, ऑप्शनल स्ट्रक्चर्ड स्टोरेज (जैसे SQLite), और सीमित नेटवर्क एक्सेस होता है. 

इस पोस्ट में, हम बताएँगे कि हमने एजेंट्स के लिए कंप्यूटर एनवायरनमेंट कैसे बनाया और इसे तेज़, ज्यादा दोहराए जा सकने वाले और सुरक्षित प्रोडक्शन वर्कफ़्लो के लिए कैसे इस्तेमाल किया जाए, इस पर शुरुआती सीख साझा करेंगे.

एक अच्छा एजेंट वर्कफ़्लो एक सटीक एक्जीक्यूशन लूप से शुरू होता है: मॉडल कोई एक्शन प्रस्तावित करता है, जैसे फाइल्स पढ़ना या API से डेटा फेच करना; प्लेटफ़ॉर्म उसे चलाता है, और उसका रिज़ल्ट अगले स्टेप में फीड हो जाता है. हम शेल टूल से शुरुआत करेंगे—यह इस लूप को एक्शन में देखने का सबसे आसान तरीका है—और फिर कंटेनर वर्कस्पेस, नेटवर्किंग, दोबारा इस्तेमाल होने वाली स्किल्स, और कॉन्टेक्स्ट कॉम्पैक्शन को कवर करेंगे.

शेल टूल को समझने के लिए पहले यह समझना ज़रूरी है कि लैंग्वेज मॉडल सामान्य तौर पर टूल्स का उपयोग कैसे करता है: जैसे किसी फ़ंक्शन को कॉल करना या कंप्यूटर के साथ इंटरैक्ट करना. ट्रेनिंग के दौरान, मॉडल को स्टेप-बाय-स्टेप यह दिखाया जाता है कि टूल्स कैसे इस्तेमाल होते हैं और उनका क्या परिणाम होता है. इससे मॉडल यह सीखता है कि टूल कब और कैसे इस्तेमाल करना है. जब हम “टूल का उपयोग” कहते हैं, तो इसका मतलब है कि मॉडल केवल टूल कॉल का प्रस्ताव देता है. वह कॉल को खुद से एक्सीक्यूट नहीं कर सकता.

शेल टूल मॉडल को काफी ज्यादा शक्तिशाली बना देता है: यह कमांड लाइन के ज़रिए कंप्यूटर के साथ इंटरैक्ट करता है और टेक्स्ट सर्च करने से लेकर आपके कंप्यूटर से API रिक्वेस्ट भेजने तक कई तरह के टास्क कर सकता है. परिचित Unix टूलिंग पर बना हमारा शेल टूल वह सब कर सकता है जिसकी आप उम्मीद करते हैं, और इसमें grep, curl, और awk जैसे यूटिलिटीज़ शुरू से ही उपलब्ध हैं.

हमारे मौजूदा code interpreter की तुलना में, जो केवल Python चलाता है, शेल टूल कहीं ज्यादा व्यापक यूज़ केसेस सक्षम बनाता है, जैसे Go या Java प्रोग्राम चलाना या NodeJS सर्वर शुरू करना. यह फ्लेक्सिबिलिटी मॉडल को जटिल एजेंटिक टास्क पूरे करने में सक्षम बनाती है.

अपने आप में, मॉडल केवल शेल कमांड्स का प्रस्ताव दे सकता है, लेकिन ये कमांड्स एक्सीक्यूट कैसे होते हैं? हमें एक ऑर्केस्ट्रेटर की ज़रूरत होती है जो मॉडल का आउटपुट ले, टूल्स को इनवोक करे, और टूल का रिस्पॉन्स वापस मॉडल को लूप में देता रहे, जब तक टास्क पूरा न हो जाए.

Responses API वह तरीका है जिससे डेवलपर्स OpenAI मॉडल्स के साथ इंटरैक्ट करते हैं. जब इसे कस्टम टूल्स के साथ इस्तेमाल किया जाता है, तो Responses API कंट्रोल क्लाइंट को वापस दे देता है, और क्लाइंट को टूल्स चलाने के लिए अपना खुद का हार्नेस चाहिए होता है. हालांकि, यह API बिना अतिरिक्त सेटअप के मॉडल और होस्टेड टूल्स के बीच ऑर्केस्ट्रेशन भी कर सकता है. 

जब Responses API को कोई प्रॉम्प्ट मिलता है, तो यह मॉडल कॉन्टेक्स्ट तैयार करता है: यूज़र प्रॉम्प्ट, पिछली बातचीत की स्टेट, और टूल इंस्ट्रक्शन्स. शेल एक्जीक्यूशन काम करने के लिए, प्रॉम्प्ट में shell टूल का उल्लेख होना चाहिए और चुना गया मॉडल शेल कमांड्स प्रस्तावित करने के लिए ट्रेंड होना चाहिए—GPT‑5.2 और उसके बाद के मॉडल्स इसके लिए ट्रेंड हैं. इस पूरे कॉन्टेक्स्ट के साथ, मॉडल अगला एक्शन तय करता है. अगर यह शेल एक्जीक्यूशन चुनता है, तो यह एक या अधिक शेल कमांड्स Responses API सर्विस को भेजता है. API सर्विस उन कमांड्स को कंटेनर रनटाइम को फॉरवर्ड करती है, शेल आउटपुट को स्ट्रीम करके वापस लाती है, और अगले रिक्वेस्ट के कॉन्टेक्स्ट में मॉडल को देती है. इसके बाद मॉडल रिज़ल्ट्स को इंस्पेक्ट कर सकता है, फॉलो-अप कमांड्स दे सकता है, या अंतिम उत्तर तैयार कर सकता है. Responses API इस लूप को तब तक दोहराता है जब तक मॉडल बिना अतिरिक्त शेल कमांड्स के एक कंप्लीशन नहीं देता.

जब Responses API कोई शेल कमांड एक्सीक्यूट करता है, तो यह कंटेनर सर्विस के साथ एक स्ट्रीमिंग कनेक्शन बनाए रखता है. जैसे-जैसे आउटपुट बनता है, API उसे लगभग रियल टाइम में मॉडल तक पहुँचाता है ताकि मॉडल तय कर सके कि और आउटपुट का इंतज़ार करना है, कोई और कमांड चलाना है, या अंतिम रिस्पॉन्स देना है.

मॉडल एक ही स्टेप में कई शेल कमांड्स प्रस्तावित कर सकता है, और Responses API उन्हें अलग-अलग कंटेनर सेशन्स का उपयोग करके साथ-साथ एक्सीक्यूट कर सकता है. हर सेशन अपना आउटपुट स्वतंत्र रूप से स्ट्रीम करता है, और API उन स्ट्रीम्स को मल्टीप्लेक्स करके स्ट्रक्चर्ड टूल आउटपुट के रूप में कॉन्टेक्स्ट में वापस भेजता है. दूसरे शब्दों में, एजेंट लूप काम को पैरेललाइज कर सकता है, जैसे फाइल्स सर्च करना, डेटा फेच करना, और इंटरमीडिएट रिज़ल्ट्स को वैलिडेट करना.

जब कमांड में फाइल ऑपरेशन्स या डेटा प्रोसेसिंग शामिल होती है, तो शेल आउटपुट बहुत बड़ा हो सकता है और उपयोगी सिग्नल जोड़े बिना कॉन्टेक्स्ट बजट खर्च कर सकता है. इसे नियंत्रित करने के लिए, मॉडल हर कमांड के लिए एक आउटपुट कैप तय करता है. Responses API उस कैप को लागू करता है और एक सीमित रिज़ल्ट लौटाता है जिसमें आउटपुट की शुरुआत और अंत दोनों सुरक्षित रहते हैं, जबकि छोड़े गए कंटेंट को मार्क किया जाता है. उदाहरण के लिए, आप आउटपुट को 1,000 कैरेक्टर्स तक सीमित कर सकते हैं, जिसमें शुरुआत और अंत सुरक्षित रहते हैं:

शुरुआत का टेक्स्ट ... 1000 कैरेक्टर्स ट्रंकेट किए गए ... अंत का टेक्स्ट

साथ मिलकर, कंकरेन्ट एक्जीक्यूशन और सीमित आउटपुट एजेंट लूप को तेज़ और कॉन्टेक्स्ट-एफिशिएंट बनाते हैं, ताकि मॉडल रॉ टर्मिनल लॉग्स से ओवरवेल्म होने के बजाय प्रासंगिक रिज़ल्ट्स पर रीजनिंग जारी रख सके.

एजेंट लूप्स की एक संभावित समस्या यह है कि टास्क लंबे समय तक चल सकते हैं. लंबे समय तक चलने वाले टास्क कॉन्टेक्स्ट विंडो को भर देते हैं, जो टर्न्स और एजेंट्स के बीच कॉन्टेक्स्ट देने के लिए महत्वपूर्ण होता है. सोचिए एक एजेंट स्किल कॉल कर रहा है, रिस्पॉन्स ले रहा है, टूल कॉल्स और रीजनिंग समरी जोड़ रहा है—सीमित कॉन्टेक्स्ट विंडो जल्दी भर जाती है. एजेंट के चलते रहने के दौरान महत्वपूर्ण कॉन्टेक्स्ट खोने से बचने के लिए, हमें एक ऐसा तरीका चाहिए जिससे ज़रूरी जानकारी बनी रहे और अतिरिक्त चीज़ें हट जाएँ. डेवलपर्स से कस्टम समरीकरण या स्टेट-कैरी करने वाले सिस्टम डिज़ाइन और मेंटेन कराने के बजाय, हमने Responses API में नेटिव कॉम्पैक्शन जोड़ा है, जो मॉडल के व्यवहार और उसकी ट्रेनिंग के अनुरूप डिज़ाइन किया गया है.

हमारे लेटेस्ट मॉडल्स को पिछली बातचीत की स्टेट का विश्लेषण करने और एक कॉम्पैक्शन आइटम बनाने के लिए ट्रेन किया गया है, जो महत्वपूर्ण पिछली स्टेट को एन्क्रिप्टेड और टोकन-एफिशिएंट रूप में सुरक्षित रखता है. कॉम्पैक्शन के बाद, अगला कॉन्टेक्स्ट विंडो इस कॉम्पैक्शन आइटम और पहले के विंडो के हाई-वैल्यू हिस्सों से मिलकर बनता है. इससे वर्कफ़्लो विंडो की सीमाओं के पार भी सुसंगत रूप से जारी रह सकते हैं, चाहे वे लंबे मल्टी-स्टेप और टूल-ड्रिवन सेशन्स ही क्यों न हों. Codex इस मैकेनिज़्म पर निर्भर करता है ताकि लंबे समय तक चलने वाले कोडिंग टास्क और इटरेटिव टूल एक्जीक्यूशन को बिना क्वालिटी घटाए जारी रखा जा सके.

कॉम्पैक्शन सर्वर पर बिल्ट-इन रूप में या एक स्टैंडअलोन '/compact' एंडपॉइंट के ज़रिए उपलब्ध है. सर्वर-साइड कॉम्पैक्शन आपको एक थ्रेशहोल्ड सेट करने देता है, और सिस्टम अपने आप कॉम्पैक्शन का टाइमिंग संभालता है, जिससे जटिल क्लाइंट-साइड लॉजिक की ज़रूरत खत्म हो जाती है. यह थोड़ा बड़ा इफेक्टिव इनपुट कॉन्टेक्स्ट विंडो देता है जो कॉम्पैक्शन से पहले छोटे ओवरेज को सहन कर सकता है, ताकि लिमिट के करीब रिक्वेस्ट्स को रिजेक्ट करने के बजाय प्रोसेस और कॉम्पैक्ट किया जा सके. जैसे-जैसे मॉडल ट्रेनिंग विकसित होती है, वैसे-वैसे नेटिव कॉम्पैक्शन सॉल्यूशन भी हर OpenAI मॉडल रिलीज़ के साथ विकसित होता रहता है.

Codex ने इस कॉम्पैक्शन सिस्टम को बनाने में हमारी मदद की, साथ ही यह इसका शुरुआती उपयोगकर्ता भी रहा. जब किसी एक Codex इंस्टेंस को कॉम्पैक्शन एरर मिलता था, तो हम जांच के लिए दूसरा इंस्टेंस शुरू कर देते थे. इसका नतीजा यह हुआ कि Codex को सिर्फ इस समस्या पर काम करते हुए ही एक नेटिव और प्रभावी कॉम्पैक्शन सिस्टम मिल गया. Codex की खुद को जांचने और सुधारने की यह क्षमता OpenAI में काम करने का एक खास दिलचस्प हिस्सा बन गई है. ज़्यादातर टूल्स में यूज़र को उन्हें इस्तेमाल करना सीखना पड़ता है; Codex हमारे साथ-साथ खुद भी सीखता है.

अब स्टेट और रिसोर्सेज़ को समझते हैं. कंटेनर सिर्फ कमांड्स चलाने की जगह नहीं है, बल्कि यह मॉडल के लिए वर्किंग कॉन्टेक्स्ट भी है. कंटेनर के अंदर, मॉडल फाइल्स पढ़ सकता है, डेटाबेसेस को क्वेरी कर सकता है, और नेटवर्क पॉलिसी कंट्रोल्स के तहत एक्सटर्नल सिस्टम्स तक पहुँच सकता है.

कंटेनर कॉन्टेक्स्ट का पहला हिस्सा फाइल सिस्टम है, जो रिसोर्सेज़ को अपलोड, व्यवस्थित और मैनेज करने के लिए होता है. हमने कंटेनर और फाइल⁠(एक नई विंडो में खुलेगा) APIs बनाए ताकि मॉडल को उपलब्ध डेटा का एक मैप मिल सके और वह व्यापक, शोर-भरे स्कैन करने के बजाय टार्गेटेड फाइल ऑपरेशन्स चुन सके.

एक आम एंटी-पैटर्न है कि सारा इनपुट सीधे प्रॉम्प्ट कॉन्टेक्स्ट में भर दिया जाए. जैसे-जैसे इनपुट बढ़ता है, प्रॉम्प्ट को ज़रूरत से ज्यादा भरना महंगा हो जाता है और मॉडल के लिए उसे नेविगेट करना मुश्किल हो जाता है. बेहतर तरीका यह है कि रिसोर्सेज़ को कंटेनर फाइल सिस्टम में स्टेज किया जाए और मॉडल को यह तय करने दिया जाए कि शेल कमांड्स से क्या खोलना, पार्स करना या ट्रांसफॉर्म करना है. इंसानों की तरह, मॉडल्स भी व्यवस्थित जानकारी के साथ बेहतर काम करते हैं.

कंटेनर कॉन्टेक्स्ट का दूसरा हिस्सा डेटाबेसेस हैं. कई मामलों में, हम डेवलपर्स को सलाह देते हैं कि वे स्ट्रक्चर्ड डेटा को SQLite जैसे डेटाबेसेस में स्टोर करें और उन्हें क्वेरी करें. उदाहरण के लिए, पूरे स्प्रेडशीट को प्रॉम्प्ट में कॉपी करने के बजाय, आप मॉडल को टेबल्स का विवरण दे सकते हैं—कौन-कौन से कॉलम हैं और उनका क्या मतलब है—और उसे ज़रूरत के अनुसार रोज़ निकालने दे सकते हैं.

उदाहरण के लिए, अगर आप पूछते हैं, “इस क्वार्टर में किन प्रॉडक्ट्स की सेल्स घटी है?” तो मॉडल पूरे स्प्रेडशीट को स्कैन करने के बजाय सिर्फ संबंधित रोज़ को क्वेरी कर सकता है. यह तरीका तेज़, सस्ता और बड़े डेटासेट्स के लिए अधिक स्केलेबल है.

कंटेनर कॉन्टेक्स्ट का तीसरा हिस्सा नेटवर्क एक्सेस है, जो एजेंट वर्कलोड्स का एक ज़रूरी हिस्सा है. एजेंट वर्कफ़्लो को लाइव डेटा फेच करना, एक्सटर्नल APIs कॉल करना, या पैकेजेस इंस्टॉल करना पड़ सकता है. साथ ही, कंटेनर्स को बिना प्रतिबंध के इंटरनेट एक्सेस देना जोखिम भरा हो सकता है: यह जानकारी को बाहरी वेबसाइट्स तक उजागर कर सकता है, अनजाने में संवेदनशील इंटरनल या थर्ड-पार्टी सिस्टम्स को प्रभावित कर सकता है, या क्रेडेंशियल लीक्स और डेटा एक्सफिल्ट्रेशन को रोकना और कठिन बना सकता है.

इन चिंताओं को दूर करने के लिए, बिना एजेंट्स की उपयोगिता सीमित किए, हमने होस्टेड कंटेनर्स को साइडकार ईग्रेस प्रॉक्सी इस्तेमाल करने के लिए तैयार किया है. सभी आउटबाउंड नेटवर्क रिक्वेस्ट्स एक सेंट्रलाइज़्ड पॉलिसी लेयर से होकर गुजरते हैं, जो अलाउलिस्ट्स और एक्सेस कंट्रोल्स लागू करती है और ट्रैफिक को ऑब्ज़र्वेबल बनाए रखती है. क्रेडेंशियल्स के लिए, हम ईग्रेस पर डोमेन-स्कोप्ड सीक्रेट इंजेक्शन का उपयोग करते हैं. मॉडल और कंटेनर केवल प्लेसहोल्डर्स देखते हैं, जबकि रॉ सीक्रेट वैल्यूज़ मॉडल-विज़िबल कॉन्टेक्स्ट से बाहर रहती हैं और केवल अप्रूव्ड डेस्टिनेशन्स पर ही लागू होती हैं. इससे लीकेज का जोखिम कम होता है और फिर भी ऑथेंटिकेटेड एक्सटर्नल कॉल्स संभव रहती हैं.

शेल कमांड्स ताकतवर होते हैं, लेकिन कई टास्क वही मल्टी-स्टेप पैटर्न बार-बार दोहराते हैं. एजेंट्स को हर रन में वर्कफ़्लो फिर से खोजने पड़ते हैं—रीप्लानिंग, कमांड्स दोबारा जारी करना, और कन्वेंशन्स फिर से सीखना—जिससे इनकंसिस्टेंट रिज़ल्ट्स और एक्सीक्यूशन की बर्बादी होती है. Agent skills⁠(एक नई विंडो में खुलेगा) उन पैटर्न्स को दोबारा इस्तेमाल किए जा सकने वाले और कंपोज़ेबल बिल्डिंग ब्लॉक्स में पैकेज करता है. सीधे तौर पर, एक स्किल एक फोल्डर बंडल होता है जिसमें ‘SKILL.md⁠(एक नई विंडो में खुलेगा)’ शामिल होता है. (जिसमें मेटाडेटा और इंस्ट्रक्शन्स होते हैं) के साथ-साथ अन्य सपोर्टिंग रिसोर्सेज भी होते हैं, जैसे API स्पेक्स और UI एसेट्स.

यह स्ट्रक्चर स्वाभाविक रूप से उस रनटाइम आर्किटेक्चर से मेल खाता है जिसे हमने पहले बताया था. कंटेनर पर्सिस्टेंट फाइल्स और एक्जीक्यूशन कॉन्टेक्स्ट प्रदान करता है, और शेल टूल एक्जीक्यूशन इंटरफेस देता है. इन दोनों के साथ, मॉडल जरूरत पड़ने पर शेल कमांड्स (ls, cat आदि) का उपयोग करके स्किल फाइल्स खोज सकता है, इंस्ट्रक्शन्स को समझ सकता है, और उसी एजेंट लूप में स्किल स्क्रिप्ट्स चला सकता है.

हम OpenAI प्लेटफ़ॉर्म में स्किल्स को मैनेज करने के लिए APIs⁠(एक नई विंडो में खुलेगा) प्रदान करते हैं. डेवलपर्स स्किल फोल्डर्स को वर्ज़न्ड बंडल्स के रूप में अपलोड और स्टोर करते हैं, जिन्हें बाद में स्किल ID से प्राप्त किया जा सकता है. मॉडल को प्रॉम्प्ट भेजने से पहले, Responses API स्किल को लोड करता है और उसे मॉडल कॉन्टेक्स्ट में शामिल करता है. यह प्रक्रिया डिटरमिनिस्टिक होती है:

1. स्किल मेटाडेटा प्राप्त करें, जिसमें नाम और विवरण शामिल हैं.
2. स्किल बंडल प्राप्त करें, उसे कंटेनर में कॉपी करें, और अनपैक करें.
3. स्किल मेटाडेटा और कंटेनर पाथ के साथ मॉडल कॉन्टेक्स्ट को अपडेट करें.

जब यह तय किया जाता है कि कोई स्किल प्रासंगिक है या नहीं, तो मॉडल धीरे-धीरे उसके इंस्ट्रक्शन्स को एक्सप्लोर करता है और कंटेनर में शेल कमांड्स के ज़रिए उसकी स्क्रिप्ट्स को एक्सीक्यूट करता है.

सभी हिस्सों को एक साथ देखें: Responses API ऑर्केस्ट्रेशन देता है, शेल टूल एक्जीक्यूटेबल एक्शन्स देता है, होस्टेड कंटेनर पर्सिस्टेंट रनटाइम कॉन्टेक्स्ट देता है, स्किल्स दोबारा इस्तेमाल होने वाली वर्कफ़्लो लॉजिक को लेयर करता है, और कॉम्पैक्शन एजेंट को ज़रूरी कॉन्टेक्स्ट के साथ लंबे समय तक चलने की सुविधा देता है.

इन प्रिमिटिव्स के साथ, एक ही प्रॉम्प्ट एक एंड-टू-एंड वर्कफ़्लो में बदल सकता है: सही स्किल ढूँढना, डेटा फेच करना, उसे लोकल स्ट्रक्चर्ड स्टेट में ट्रांसफॉर्म करना, उसे कुशलता से क्वेरी करना, और टिकाऊ आर्टिफैक्ट्स जनरेट करना. 

नीचे दिया गया डायग्राम दिखाता है कि यह सिस्टम लाइव डेटा से स्प्रेडशीट बनाने के लिए कैसे काम करता है.

शेल टूल और कंप्यूटर एनवायरनमेंट को मिलाकर एंड-टू-एंड वर्कफ़्लो बनाने का विस्तृत उदाहरण देखने के लिए, हमारा डेवलपर ब्लॉग पोस्ट⁠(एक नई विंडो में खुलेगा) और कुकबुक⁠(एक नई विंडो में खुलेगा) देखें, जिसमें स्किल को पैकेज करना और उसे Responses API के ज़रिए एक्सीक्यूट करना समझाया गया है.

हम उत्साहित हैं यह देखने के लिए कि डेवलपर्स इन प्रिमिटिव्स के साथ क्या बनाते हैं. लैंग्वेज मॉडल्स का उद्देश्य सिर्फ टेक्स्ट, इमेज और ऑडियो जनरेट करना नहीं है—हम अपने प्लेटफ़ॉर्म को लगातार बेहतर बनाते रहेंगे ताकि यह बड़े पैमाने पर जटिल, वास्तविक दुनिया के टास्क संभाल सके.