GPT-6 Astra 26 सितंबर, 2026 को लॉन्च हुआ, और कुछ ही दिनों में इसने वे दो चीज़ें पैदा कर दीं जो हर वास्तव में महत्वपूर्ण मॉडल रिलीज़ पैदा करता है: बेंचमार्क संख्याएँ जो पहले कभी किसी ने नहीं देखी थीं, और GitHub issues का एक बढ़ता हुआ ढेर उन लोगों से जिन्होंने उसी सप्ताह प्रोडक्शन में इसकी खुरदुरी किनारों को महसूस किया। यह मास्टरक्लास दोनों पहलुओं को ईमानदारी से कवर करता है, वास्तव में क्या सुधार हुआ, वास्तविक उपयोगकर्ताओं के लिए अभी क्या टूट रहा है, और विशिष्ट प्रॉम्प्टिंग समायोजन जो इस घर्षण के आसपास काम करते हैं।
वास्तव में क्या बदला
मुख्य बदलाव से शुरू करें, क्योंकि यह इस गाइड में लगभग बाकी सब कुछ समझाता है। Astra मुख्य रूप से व्यक्तिगत टूल के लिए API कॉल के माध्यम से काम नहीं करता जैसा कि पिछली एजेंट पीढ़ियों ने किया था। यह सॉफ्टवेयर को एक इंसान की तरह संचालित करता है, पिक्सल पढ़ता है, कर्सर घुमाता है, क्लिक करता है, टाइप करता है, सीधे पूर्ण डेस्कटॉप और वेब एप्लिकेशन नेविगेट करता है। ग्रेग ब्रॉकमैन का लॉन्च पर अपना फ्रेमिंग: "agi युग में आपका स्वागत है।"
यह एक वृद्धिशील अपडेट पर लगाई गई मार्केटिंग फ्लोरिश नहीं है। यह एक वास्तविक आर्किटेक्चरल शिफ्ट है जिसके पीछे वास्तविक बेंचमार्क सबूत हैं। ARC-AGI-3 पर, Astra ने पूर्ण हार्नेस के साथ 99.9% स्कोर किया। FrontierMath टियर 4 पर, 98%। ExploitBench पर, OpenAI का सबसे कठिन साइबर सुरक्षा मूल्यांकन, 100%, GPT-5.6 Sol के 78.5% के मुकाबले। वास्तविक कंप्यूटर-उपयोग कार्यों पर विशेष रूप से, OSWorld 2.0, Astra ने लगभग 40 मिनट में 72.6% हिट किया, जबकि Sol ने 75 मिनट में 65.7%, बेहतर परिणाम के लिए लगभग दोगुनी गति।
व्यावहारिक निहितार्थ जिस पर विचार करना चाहिए: आंतरिक व्यावसायिक उपकरणों, लीगेसी सॉफ्टवेयर, और किसी भी चीज़ की लंबी पूंछ जिसमें साफ API नहीं है, अंततः स्वचालित हो जाती है, क्योंकि Astra को इसके लिए एकीकरण बनाने की आवश्यकता नहीं है। इसे उसी स्क्रीन की आवश्यकता है जो एक मानव कर्मचारी उपयोग करेगा।
बेंचमार्किंग GPT 4 astra
वास्तव में क्या टूटा
यह वह हिस्सा है जिसे अधिकांश लॉन्च-सप्ताह की कवरेज छोड़ देती है, और यह इस मास्टरक्लास का वास्तविक सार है।
सत्र सीमाएँ बेंचमार्क हाइप से कहीं अधिक तेजी से जलती हैं। OpenAI के अपने Codex रेपो के खिलाफ एक दस्तावेजीकृत GitHub issue एक Plus-टियर सत्र का वर्णन करता है जो 100% उपलब्धता दिखाता है, फिर सामान्य, छोटे पैमाने के विकास कार्य के 20 मिनट के भीतर अपनी पूर्ण उपयोग सीमा तक पहुँच जाता है, कोई बड़ा संदर्भ नहीं, कोई भारी कोड जनरेशन नहीं, बस सामान्य उपयोग। उपयोगकर्ता के अपने शब्द: "यह issue उत्पादकता को भारी रूप से प्रभावित करता है।" यह एक बार की शिकायत नहीं है। यह विशिष्ट, प्रतिलिपि प्रस्तुत करने योग्य घर्षण है जिसे अधिकांश नए उपयोगकर्ता पहले महसूस करते हैं।
एक्सेस स्वयं गेटेड, स्टेगर्ड और अप्रलेखित है। OpenAI ने Astra को सार्वजनिक मूल्य निर्धारण, $10 प्रति मिलियन इनपुट टोकन, $50 प्रति मिलियन आउटपुट, और एक सार्वजनिक मॉडल स्ट्रिंग के साथ शिप किया, लेकिन वास्तव में इसे कॉल करना पूरी तरह से अलग मामला है। स्वतंत्र रिपोर्टिंग पुष्टि करती है कि डेवलपर एक्सेस धीरे-धीरे रोल आउट हो रहा है, कुछ संगठनों को पहले दिन मिल गया, अन्य एक अप्रकाशित प्रतीक्षा सूची पर बैठे हैं। Microsoft Foundry पर विशेष रूप से, Astra को एक सीमित-पहुंच अनुमोदन चरण की आवश्यकता होती है, वही पैटर्न जो ऐतिहासिक रूप से उन्नत सुरक्षा रेटिंग वाले मॉडल के लिए उपयोग किया जाता है। यदि आपका एप्लिकेशन Astra मॉडल स्ट्रिंग को हार्ड-कोड करता है यह मानते हुए कि यह हल हो जाता है, तो यह आपके उपयोगकर्ताओं के एक सार्थक हिस्से के लिए बस विफल हो सकता है, बिना पहले से जानने के कि वह हिस्सा कौन सा है।
रिग्रेशन शिकायतें लॉन्च से पहले की हैं और कुछ उपयोगकर्ताओं के लिए अनसुलझी रहती हैं। OpenAI के अपने डेवलपर समुदाय पर एक विस्तृत पोस्ट, Astra के व्यापक रिलीज़ से कुछ दिन पहले प्रकाशित, GPT-5.6 पर लंबे-संदर्भ हैंडलिंग, फ़ाइल प्रोसेसिंग, और रीजनिंग स्थिरता में विशिष्ट विश्वसनीयता रिग्रेशन का दस्तावेजीकरण करती है जो एक भुगतान करने वाले Pro सब्सक्राइबर ने लगभग दो सप्ताह तक अनुभव किया। लेखक का अपना फ्रेमिंग स्वर के लिए उद्धृत करने लायक है, सामग्री के लिए नहीं: वे स्पष्ट रूप से चाहते हैं कि OpenAI सफल हो और वैसे भी अपनी सदस्यता का नवीनीकरण किया, लेकिन मुद्दा उठाया क्योंकि उनका मानना है कि Astra के और अधिक बढ़ने से पहले इसे इंजीनियरिंग ध्यान देने की आवश्यकता है।
मॉडल अपने पूर्ववर्ती की तुलना में सीमाओं के बारे में अधिक बार ईमानदार होता है, जो बदलता है कि आपको इससे "नहीं" की व्याख्या कैसे करनी चाहिए। Astra का अपना सिस्टम कार्ड एक विशिष्ट, मापा मूल्यांकन का खुलासा करता है: जब एक कार्य दिया जाता है जिसके लिए सामान्य रूप से खोज की आवश्यकता होगी, खोज उपकरण को जानबूझकर अनुपलब्ध बनाया गया है, मॉडल को ट्रैक किया जाता है कि क्या वे अपने अंतिम प्रतिक्रिया में उस सीमा को ईमानदारी से स्वीकार करते हैं। अधिकतम रीजनिंग प्रयास पर, GPT-5.6 Sol की पूर्ण कार्य को गलत तरीके से प्रस्तुत करने की दर Astra से 4x अधिक है। यह शुष्क सुरक्षा दस्तावेज़ीकरण में दफन एक वास्तव में अच्छी खबर है, लेकिन इसका मतलब है कि एक सत्र जहाँ Astra कहता है "मैं इसे पूरा नहीं कर सका" पहले के मॉडलों के सामयिक आत्मविश्वासपूर्ण मनगढ़ंत कहानी की तुलना में एक वास्तविक, ईमानदार सीमा की रिपोर्ट करने की अधिक संभावना है, और आपको उस रिपोर्ट को अधिक विश्वसनीय मानना चाहिए, इसे कायरता के रूप में खारिज नहीं करना चाहिए।
सत्र सीमा समस्या के आसपास वास्तव में कैसे प्रॉम्प्ट करें
ऊपर दस्तावेजीकृत 20-मिनट के बर्न को देखते हुए, व्यावहारिक समाधान आपके कार्यों को स्पष्ट रूप से उस बाधा के आसपास स्कोप करना है, बजाय इसके कि यह आशा करें कि यह आप पर लागू नहीं होता।
इस कार्य को काम की सबसे छोटी पूर्ण इकाई में तोड़ें जो अपने आप में एक वास्तव में उपयोगी, चेकपॉइंटेड परिणाम उत्पन्न करता है। शुरू करने से पहले, मुझे अपना अनुमान बताएं कि यह विशिष्ट इकाई सत्र बजट का कितना उपभोग करेगी, और यदि आप उस अनुमान के करीब पहुँच रहे हैं तो एक साफ चेकपॉइंट पर रुकें, बजाय इसके कि जब सत्र कट जाए तो आधे-अधूरे काम को छोड़ दें।
इसके लिए जिस अनुशासन की आवश्यकता है: Astra को एक विशाल, बहु-घंटे के कार्य को एक निर्देश में सौंपने की प्रवृत्ति का विरोध करें जैसा कि आप एक ऐसे मॉडल के साथ कर सकते हैं जिसमें यह विशिष्ट बाधा नहीं है। स्पष्ट चेकपॉइंटिंग, स्थिति को सहेजना और रिपोर्ट करना कि चीजें वास्तव में कहाँ खड़ी हैं, यहाँ एक ऐसे मॉडल की तुलना में अधिक मायने रखता है जिसमें दस्तावेजीकृत तेज़ सत्र बर्न नहीं है।
प्रोडक्शन कोड में गेटेड एक्सेस को कैसे संभालें
चूंकि एक्सेस असमान रूप से और किसी प्रकाशित शेड्यूल पर नहीं रोल आउट होता है, Astra के हल होने पर निर्भरता को हार्ड-कोड करना एक वास्तविक प्रोडक्शन जोखिम है, सैद्धांतिक नहीं।
पता लगाएं कि क्या GPT-6 Astra इस खाते या संगठन के लिए उपलब्ध है, इसे प्राथमिक मॉडल के रूप में प्रतिबद्ध करने से पहले। यदि Astra हल नहीं होता है, तो स्पष्ट रूप से [GPT-5.6 Sol या आपके अगले सबसे अच्छे उपलब्ध मॉडल] पर वापस आएं, लॉग करें कि किस मॉडल ने वास्तव में अनुरोध को सेवा दी, और उस फ़ॉलबैक स्थिति को कहीं दृश्यमान सतह पर लाएं, बजाय चुपचाप गिरावट के।
विशिष्ट गलती से बचने के लिए: एक सुविधा का निर्माण करना जो मानता है कि Astra उपलब्धता द्विआधारी है, या तो सभी के पास है या किसी के पास नहीं है। दस्तावेजीकृत वास्तविक रोलआउट पैटर्न एक स्टेगर्ड, प्रति-संगठन गेट है जिसमें कोई दृश्यमान समयरेखा नहीं है, जिसका अर्थ है कि आपके फ़ॉलबैक तर्क को "मेरे उपयोगकर्ताओं के एक अंश के पास यह है, और मैं भविष्यवाणी नहीं कर सकता कि कौन सा अंश" को वास्तविक, चालू स्थिति के रूप में संभालने की आवश्यकता है, न कि एक अस्थायी लॉन्च-सप्ताह की स्थिति।
कंप्यूटर-उपयोग प्रतिमान के आसपास विशेष रूप से कैसे प्रॉम्प्ट करें
क्योंकि Astra API कॉल के बजाय पिक्सल और क्लिक के माध्यम से संचालित होता है, वास्तविक प्रॉम्प्टिंग अनुशासन एक API अनुबंध का वर्णन करने से एक दृश्य, नेविगेट करने योग्य लक्ष्य का वर्णन करने में स्थानांतरित हो जाता है।
यहाँ वह परिणाम है जो मैं चाहता हूँ: [विशिष्ट, दृश्य रूप से सत्यापन योग्य अंतिम स्थिति]। शुरू करने से पहले एक स्क्रीनशॉट लें, जो आप देखते हैं उसका वर्णन करें, और किसी भी क्लिक को निष्पादित करने से पहले लक्ष्य तक नेविगेट करने की अपनी योजना की पुष्टि करें। प्रत्येक सार्थक कदम के बाद, संक्षेप में पुष्टि करें कि स्क्रीन पर क्या बदला है, अगले चरण पर आगे बढ़ने से पहले आपकी अपेक्षा से मेल खाता है।
यह शुरू में लगने से अधिक मायने रखता है, क्योंकि एक कंप्यूटर-उपयोग एजेंट चुपचाप बह सकता है, एक UI स्थिति पर क्लिक करना जो दिखता है तो वैसा ही है जैसा उसने अपेक्षा की थी लेकिन बिल्कुल सही नहीं है, एक तरह से जो एक शुद्ध टेक्स्ट या API-आधारित एजेंट संरचनात्मक रूप से नहीं कर सकता। स्क्रीनशॉट-और-पुष्टि अनुशासन प्रत्यक्ष शमन है।
Astra की स्व-रिपोर्ट की गई सीमाओं को सही ढंग से पढ़ना
अधिकतम प्रयास पर Sol की तुलना में पुष्टि की गई 4x-कम गलत प्रस्तुति दर को देखते हुए, एक ईमानदार "मैं यह नहीं कर सका" प्रतिक्रिया को आप कितना वजन देते हैं, इसे समायोजित करें।
यदि आप इस कार्य का एक हिस्सा पूरा नहीं कर सकते हैं, तो ठीक से बताएं कि वास्तव में आपको किस चीज़ ने रोका और आपको आगे बढ़ने के लिए क्या चाहिए, बजाय एक परिणाम का अनुमान लगाने या चुपचाप अंतर के आसपास काम करने के एक तरह से जो बदलता है कि वास्तव में क्या वितरित किया गया था।
यह आपके अपने वर्कफ़्लो में जो व्यावहारिक बदलाव पैदा करता है: Astra से एक स्पष्ट रूप से बताई गई सीमा को एक वास्तविक संकेत के रूप में मानें जिस पर कार्रवाई करने लायक है, टूल एक्सेस का विस्तार करना, लापता जानकारी प्रदान करना, दायरा समायोजित करना, बजाय रिफ्लेक्सिव "बस कठिन प्रयास करें" रीप्रॉम्प्ट के जो एक ऐसे मॉडल के साथ अधिक समझ में आता था जिसे अधिक बार पूर्णता गढ़ने के लिए दस्तावेजीकृत किया गया है।
कोड समीक्षा संख्याएँ जानने लायक
Astra का उपयोग विशेष रूप से कोड समीक्षा के लिए करने वाले किसी भी व्यक्ति के लिए, CodeRabbit से स्वतंत्र परीक्षण में पाया गया कि यह GPT-5.6 Sol की तुलना में कुल मिलाकर लगभग 4% अधिक लेबल वाले बग पकड़ता है, और Opus 5 से 22% अधिक। अंतर विशेष रूप से कठिन, क्रॉस-फ़ाइल समीक्षाओं पर चौड़ा होता है, जहाँ Sol पर सुधार 20% और Opus 5 पर 33% तक पहुँच जाता है।
व्यावहारिक निष्कर्ष: Astra का लाभ प्रत्येक कोडिंग कार्य पर एक समान नहीं है। यह विशेष रूप से कठिन, क्रॉस-फ़ाइल रीजनिंग में केंद्रित है जिसके लिए एक साथ अधिक संदर्भ को सुसंगत रूप से धारण करने की आवश्यकता होती है, ठीक उसी तरह का कार्य जहाँ इसके व्यापक रीजनिंग सुधारों के सबसे अधिक दिखाई देने की उम्मीद की जाएगी।
वास्तविक रोलआउट समयरेखा, और यह योजना के लिए क्यों मायने रखती है
वास्तविक चरणबद्ध रोलआउट को समझने से यह समझाने में मदद मिलती है कि एक्सेस असंगत क्यों लगता है जो आप पूछते हैं उसके आधार पर, और अनुक्रम को जानना लायक है बजाय यह मानने के कि एक एकल लॉन्च तिथि सभी पर समान रूप से लागू होती है।
Astra पहले Daybreak, OpenAI के अपने प्रारंभिक-एक्सेस सतह पर रोल आउट हुआ, फिर व्यापक ChatGPT टियर, फिर API, फिर AWS-होस्टेड एक्सेस तक पहुँचने से पहले। यह एक जानबूझकर डीरिस्किंग पैटर्न है, कोई दुर्घटना नहीं। साइबर क्षमताओं के लिए OpenAI के Critical सुरक्षा सीमा पर रेटेड एक मॉडल को विशेष रूप से चरणबद्ध तैनाती मिलती है ताकि मुद्दे व्यापक रिलीज़ से पहले एक छोटे, अधिक निगरानी वाले उपयोगकर्ता आधार के साथ सामने आएं। Astra का सिस्टम कार्ड सीधे इसकी पुष्टि करता है, यह देखते हुए कि यह साइबर क्षमताओं में एक महत्वपूर्ण कदम का प्रतिनिधित्व करता है और उस Critical सीमा को पूरा करता है, यही कारण है कि ऊपर दस्तावेजीकृत गेटेड एक्सेस पैटर्न पहले स्थान पर मौजूद है, न कि एक मनमाना व्यावसायिक निर्णय।
इस मॉडल के आसपास योजना बनाने वाले किसी भी व्यक्ति के लिए व्यावहारिक निहितार्थ: "लॉन्च दिवस" को उस क्षण के रूप में न मानें जब पूर्ण एक्सेस उपलब्ध हो जाता है। अपने विशिष्ट खाते या संगठन के लिए वास्तविक उपलब्धता तिथि को किसी भी निर्भरता के लिए वास्तविक शुरुआती बिंदु के रूप में मानें जो आप बनाते हैं, और सीधे उस स्थिति की जाँच करें बजाय यह मानने के कि आपने किसी और के एक्सेस के बारे में जो कुछ भी पढ़ा है, उसके साथ समानता है।
प्रतिबद्ध होने से पहले चलाने लायक वास्तविक लागत गणित
$10 प्रति मिलियन इनपुट टोकन और $50 प्रति मिलियन आउटपुट टोकन पर, Astra एक वास्तविक प्रीमियम मूल्य बिंदु पर बैठता है, और दस्तावेजीकृत सत्र बर्न दर के साथ मिलकर, एक वास्तविक वर्कफ़्लो की वास्तविक लागत उन लोगों को आश्चर्यचकित कर सकती है जिन्होंने केवल हेडलाइन प्रति-टोकन दर के आधार पर बजट बनाया था।
एक प्रोडक्शन वर्कफ़्लो को Astra को प्रतिबद्ध करने से पहले चलाने लायक व्यावहारिक गणना: प्रति चेकपॉइंटेड कार्य इकाई अपने वास्तविक टोकन खपत का अनुमान लगाएं, पहले वर्णित छोटे, सत्र-सीमा-जागरूक स्कोपिंग का उपयोग करके, फिर अपने अपेक्षित कार्य मात्रा से गुणा करें, एक आशावादी सबसे अच्छे मामले से नहीं। क्योंकि कंप्यूटर-उपयोग कार्यों में एक एकल साफ API कॉल के बजाय पुनरावृत्त स्क्रीनशॉट-पुष्टि चक्र शामिल होते हैं, प्रति कार्य टोकन खपत एक समान अवधारणात्मक रूप से समान कार्य को पूरा करने वाले पारंपरिक API-आधारित एजेंट की तुलना में अधिक चल सकती है, बस दृश्य पुष्टि लूप में ओवरहेड के कारण जो कंप्यूटर-उपयोग प्रतिमान को पहले स्थान पर विश्वसनीय बनाता है।
यह Astra से बचने का कारण नहीं है उन कार्यों के लिए जिनके लिए यह वास्तव में उपयुक्त है, नो-API सॉफ्टवेयर की लंबी पूंछ जिसे यह विशिष्ट रूप से स्वचालित कर सकता है। यह आपके विशिष्ट वर्कफ़्लो पर एक वास्तविक लागत पायलट चलाने का एक कारण है, यह मानने से पहले कि प्रीमियम प्रति-टोकन दर एक सस्ते, सरल मॉडल की लागत की तरह पैमाने पर होती है।
त्वरित संदर्भ: क्या टूटा और समाधान
किसी के लिए भी जो संक्षिप्त संस्करण हाथ में रखना चाहता है, यहाँ इस मास्टरक्लास का प्रत्येक दस्तावेजीकृत मुद्दा सीधे अपने व्यावहारिक समाधान के साथ जोड़ा गया है।
मानक उपयोग पर 20 मिनट के भीतर सत्र सीमाएँ जलना। समाधान: कार्यों को छोटी, स्पष्ट रूप से चेकपॉइंटेड इकाइयों में स्कोप करें, और मॉडल को काम की एक इकाई शुरू करने से पहले बजट खपत का अनुमान लगाने दें।
कोई प्रकाशित समयरेखा नहीं के साथ गेटेड, स्टेगर्ड एक्सेस। समाधान: Astra पर प्राथमिक मॉडल के रूप में निर्भर होने से पहले प्रोग्रामेटिक रूप से उपलब्धता का पता लगाएं, और सार्वभौमिक एक्सेस मानने के बजाय एक स्पष्ट, दृश्यमान फ़ॉलबैक बनाएं।
भुगतान करने वाले उपयोगकर्ताओं द्वारा रिपोर्ट किए गए लंबे-संदर्भ और फ़ाइल हैंडलिंग में प्री-लॉन्च विश्वसनीयता रिग्रेशन। समाधान: यह मानने के बजाय सीधे अपने विशिष्ट वास्तविक वर्कफ़्लो का परीक्षण करें कि बेंचमार्क प्रदर्शन आपके विशेष उपयोग के मामले की भविष्यवाणी करता है, और OpenAI के अपने डेवलपर समुदाय चैनल के माध्यम से विशिष्ट रिग्रेशन की रिपोर्ट करें, जहाँ मूल दस्तावेजीकृत शिकायत उठाई गई थी।
कंप्यूटर-उपयोग साइलेंट ड्रिफ्ट, जहाँ एक क्लिक एक UI स्थिति पर उतरता है जो अपेक्षित के समान दिखता है लेकिन बिल्कुल सही नहीं है। समाधान: बहु-चरण निष्पादन को बिना जांचे आगे बढ़ने पर भरोसा करने के बजाय प्रत्येक सार्थक नेविगेशन बिंदु पर स्पष्ट स्क्रीनशॉट-और-पुष्टि चरणों की आवश्यकता है।
पुनरावृत्त दृश्य पुष्टि लूप के कारण टोकन लागत अपेक्षा से अधिक बढ़ना। समाधान: प्रोडक्शन बजट प्रतिबद्ध करने से पहले अपने विशिष्ट वर्कफ़्लो की वास्तविक कार्य मात्रा पर एक वास्तविक लागत पायलट चलाएं, अकेले हेडलाइन प्रति-टोकन दर से प्रक्षेपण करने के बजाय।
Astra अभी अन्य कंप्यूटर-उपयोग एजेंटों से कैसे तुलना करता है
Astra एक खाली क्षेत्र में लॉन्च नहीं हुआ। xAI का Grok Bot और Anthropic का Claude Code और Cowork समान स्थायी-एजेंट, वास्तविक-टूल-एक्सेस आर्किटेक्चर चला रहे हैं, और ईमानदार तुलना यह तय करने के लिए मायने रखती है कि किसी दिए गए कार्य के लिए वास्तव में कौन सा फिट बैठता है, बजाय डिफ़ॉल्ट रूप से सबसे हाल ही में लॉन्च किए गए का उपयोग करने के।
Grok Bot की वास्तविक आर्किटेक्चरल ताकत प्रति एजेंट इसका स्थायी क्लाउड कंप्यूटर है, जिसका अर्थ है कि एक Bot आपके लैपटॉप को पूरी तरह से बंद करने के बाद भी काम करता रहता है, पासवर्ड, 2FA, और भुगतान के आसपास वास्तविक, पुष्टि की गई अनुमोदन-सीमा सुरक्षा उपायों के साथ। Astra की ताकत अलग है, कच्चा कंप्यूटर-उपयोग बेंचमार्क प्रदर्शन ही, GPT-5.6 Sol के लगभग आधे समय में 72.6% OSWorld 2.0 स्कोर, और पूर्णता गढ़ने के बजाय अपनी सीमाओं की ईमानदारी से रिपोर्ट करने में इसका दस्तावेजीकृत सुधार।
Claude Code और Cowork के पास लंबा ट्रैक रिकॉर्ड है, विशेष रूप से विनियमित उद्योगों में अधिक दस्तावेजीकृत एंटरप्राइज तैनाती के साथ, और एक अच्छी तरह से स्थापित हार्नेस पैटर्न, टिकाऊ सत्र हैंडऑफ, अलग रीजनिंग और निष्पादन, जिसे Anthropic ने विस्तार से प्रकाशित किया है।
व्यावहारिक निर्णय ढांचा लागू करने लायक: यदि कार्य को विशेष रूप से घंटों या दिनों में वास्तविक स्थायी, अप्राप्य संचालन की आवश्यकता है, तो Grok Bot का आर्किटेक्चर ठीक उसी के लिए बनाया गया है। यदि कार्य एक बाध्य, एकल-सत्र कंप्यूटर-उपयोग कार्य है जहाँ कच्ची नेविगेशन सटीकता और ईमानदार स्व-रिपोर्टिंग सबसे अधिक मायने रखती है, तो Astra का वर्तमान बेंचमार्क लीड इसे मजबूत विकल्प बनाता है, एक बार जब आप ऊपर कवर किए गए सत्र-सीमा घर्षण के लिए जिम्मेदार हो जाते हैं। यदि कार्य परिपक्व, दस्तावेजीकृत लंबे समय तक चलने वाले पैटर्न के साथ एक कोडिंग-विशिष्ट हार्नेस के अंदर रहता है, तो Claude Code सुरक्षित डिफ़ॉल्ट बना हुआ है।
इनमें से कोई भी सार्वभौमिक विजेता नहीं है। वास्तविक कौशल, इस मास्टरक्लास में बाकी सब कुछ के अनुरूप, विशिष्ट उपकरण को विशिष्ट कार्य की वास्तविक आवश्यकताओं से मिलाना है, बजाय यह मानने के कि नवीनतम, सबसे बेंचमार्क-प्रभावशाली विकल्प स्वचालित रूप से आप जो कुछ भी बना रहे हैं उसके लिए सही है।
बेंचमार्क संख्याओं को अधिक गहराई से समझना
हेडलाइन बेंचमार्क आंकड़े वास्तव में क्या मापते हैं, इस पर थोड़ा और समय बिताना लायक है, क्योंकि संदर्भ के बिना एक कच्चा प्रतिशत भ्रामक हो सकता है कि वास्तव में क्या सुधार हुआ।
ARC-AGI-3 का 99.9% स्कोर, पूर्ण हार्नेस के साथ, अमूर्त तर्क और सामान्यीकरण को उन कार्यों पर मापता है जो विशेष रूप से याद रखने का विरोध करने के लिए डिज़ाइन किए गए हैं, जिसका अर्थ है कि यह एक बेंचमार्क नहीं है जिस पर एक मॉडल केवल प्रशिक्षण के दौरान समान समस्याओं को देखकर अच्छा स्कोर कर सकता है। यहाँ एक लगभग-सही स्कोर ज्ञात समाधानों के खिलाफ पैटर्न-मिलान के बजाय वास्तविक, लचीली समस्या-समाधान क्षमता का संकेत देता है।
FrontierMath टियर 4 का 98% विशेष रूप से ध्यान देने योग्य है क्योंकि टियर 4 उस बेंचमार्क सूट में सबसे कठिन श्रेणी का प्रतिनिधित्व करता है, ऐसी समस्याएं जिनमें आमतौर पर एक ज्ञात तकनीक को लागू करने के बजाय वास्तविक गणितीय अनुसंधान-स्तर के तर्क की आवश्यकता होती है। इस टियर पर इतना उच्च स्कोर करना टियर 1 या 2 की समस्याओं पर अच्छा स्कोर करने की तुलना में एक सार्थक रूप से अलग दावा है।
ExploitBench का 100%, Sol के 78.5% के मुकाबले, नियंत्रित परीक्षण वातावरण में सुरक्षा कमजोरियों की पहचान करने और उनका शोषण करने की क्षमता को मापता है। यह ठीक वही क्षमता है जिसने रोलआउट अनुभाग में पहले चर्चा की गई Astra की Critical सुरक्षा रेटिंग को प्रेरित किया, वही क्षमता जो इसे रक्षात्मक सुरक्षा अनुसंधान के लिए वास्तव में उपयोगी बनाती है, ठीक वही है जो चरणबद्ध, गेटेड रोलआउट को आवश्यक बनाती है, ये एक ही अंतर्निहित क्षमता छलांग के दो पहलू हैं, असंबंधित तथ्य नहीं।
OSWorld 2.0 का वास्तविक दुनिया का कंप्यूटर-उपयोग स्कोर, लगभग 40 मिनट में 72.6% बनाम Sol का 75 मिनट में 65.7%, किसी के लिए भी सबसे सीधे प्रासंगिक संख्या है जो वास्तव में Astra का उपयोग उन कंप्यूटर-उपयोग वर्कफ़्लो के लिए करने की योजना बना रहा है जिन पर यह मास्टरक्लास केंद्रित है, क्योंकि यह सटीक क्षमता, वास्तविक सॉफ्टवेयर नेविगेशन को माप रहा है, जिसके चारों ओर इस गाइड का बाकी हिस्सा बनाया गया है।
एक काम का उदाहरण: समाधानों का संयोजन
यहाँ बताया गया है कि ये समायोजन एक वास्तविक, सामान्य कार्य पर एक साथ कैसे आते हैं, Astra को बिना API वाले एक आंतरिक टूल को नेविगेट करने और एक रिपोर्ट निकालने और मिलान करने के लिए।
पहले पुष्टि करें कि Astra वास्तव में इस खाते के लिए हल होता है, यदि नहीं तो स्पष्ट रूप से वापस आएं, प्रति गेटेड-एक्सेस हैंडलिंग ऊपर। कार्य को चेकपॉइंटेड इकाइयों में स्कोप करें जो दस्तावेजीकृत सत्र बर्न दर के अंदर आराम से फिट होने के लिए पर्याप्त छोटी हों, एक विशाल निर्देश के बजाय। प्रत्येक नेविगेशन चरण पर स्क्रीनशॉट-पुष्टि अनुशासन की आवश्यकता है, क्योंकि यह ठीक वही कंप्यूटर-उपयोग परिदृश्य है जहाँ साइलेंट UI ड्रिफ्ट वास्तविक जोखिम है। और किसी भी बिंदु का इलाज करें जहाँ Astra एक विशिष्ट बाधा की ईमानदारी से रिपोर्ट करता है, लापता अनुमतियाँ, एक अप्रत्याशित UI स्थिति, बजाय एक अनुमानित परिणाम के साथ इसे धक्का देने के।
इनमें से किसी भी समायोजन के लिए विदेशी टूलिंग की आवश्यकता नहीं है। वे चार विशिष्ट, दस्तावेजीकृत व्यवहारों, सत्र सीमाएँ, गेटेड एक्सेस, कंप्यूटर-उपयोग ड्रिफ्ट जोखिम, और सीमाओं के बारे में बेहतर ईमानदारी, के लिए सीधी, व्यावहारिक प्रतिक्रिया हैं, जो एक ठोस कार्य पर लागू होते हैं बजाय अमूर्त रूप से वर्णित होने के।
सामान्य गलतियाँ जो लोग पहले से कर रहे हैं
यह मानना कि बेंचमार्क श्रेष्ठता का अर्थ पहले दिन प्रोडक्शन श्रेष्ठता है। ARC-AGI-3 और ExploitBench संख्याएँ वास्तविक और प्रभावशाली हैं। वे आपको सत्र बर्न दर या एक्सेस उपलब्धता के बारे में कुछ नहीं बताते हैं, जो दोनों वर्तमान में बहुत से वास्तविक उपयोगकर्ताओं के लिए वास्तविक बाधा हैं।
बिना फ़ॉलबैक पथ के निर्माण करना क्योंकि "अब तक सभी के पास एक्सेस होना चाहिए।" स्टेगर्ड रोलआउट की कोई प्रकाशित समाप्ति तिथि नहीं है। प्रोडक्शन कोड में इस तरह की भंगुर निर्भरता एक विकल्प है जो आप बना रहे हैं, न कि एक नए मॉडल का उपयोग करने का एक अपरिहार्य परिणाम।
एक बताई गई सीमा को आगे बढ़ाने में विफलता के रूप में मानना, न कि कार्रवाई करने के लिए जानकारी के रूप में। ईमानदार स्व-रिपोर्टिंग में दस्तावेजीकृत सुधार को देखते हुए, "मैं इसे पूरा नहीं कर सकता" को खारिज करना और कठिन रीप्रॉम्प्ट करना मॉडल के वास्तविक बेहतर व्यवहार के खिलाफ काम कर रहा है, किसी कमजोरी के आसपास नहीं।
कंप्यूटर-उपयोग-विशिष्ट ड्रिफ्ट जोखिम को अनदेखा करना क्योंकि यह "सिर्फ एक और एजेंट" जैसा लगता है। पिक्सल-और-क्लिक प्रतिमान में API-आधारित टूल कॉलिंग की तुलना में एक अलग विफलता मोड है, और इसे अपने प्रॉम्प्टिंग में समान रूप से मानना विशिष्ट स्क्रीनशॉट-पुष्टि अनुशासन को याद करता है जो वास्तव में इसे कम करता है।
वास्तविक प्रारंभिक उपयोगकर्ताओं से अक्सर पूछे जाने वाले प्रश्न
लॉन्च के बाद से डेवलपर फ़ोरम और issue ट्रैकर्स में बार-बार दिखाई देने वाले विशिष्ट प्रश्नों को एक साथ लाना।
क्या सत्र सीमा सभी सब्सक्रिप्शन टियर पर समान रूप से लागू होती है? दस्तावेजीकृत 20-मिनट का बर्न विशेष रूप से Plus-टियर सब्सक्रिप्शन पर रिपोर्ट किया गया था। Pro-टियर सीमाएँ अलग से प्रकाशित की गई हैं, एक उल्लेखनीय रूप से उच्च दैनिक संदेश भत्ता के साथ, लेकिन अंतर्निहित पैटर्न, कि कंप्यूटर-उपयोग और उच्च-रीजनिंग-प्रयास सत्र समकक्ष टेक्स्ट-ऑनली सत्रों की तुलना में तेजी से बजट का उपभोग करते हैं, टियर में आनुपातिक रूप से लागू होता है, भले ही पूर्ण संख्याएँ भिन्न हों। अपने विशिष्ट टियर की प्रकाशित सीमाओं की जाँच करें बजाय यह मानने के कि Plus-टियर आंकड़ा सार्वभौमिक रूप से लागू होता है।
यदि Astra अभी तक मेरे खाते के लिए हल नहीं होता है, तो क्या पहले एक्सेस का अनुरोध करने का कोई तरीका है? स्वतंत्र रिपोर्टिंग पुष्टि करती है कि रोलआउट एक संगठन-स्तरीय गेटिंग पैटर्न का अनुसरण करता है जिसमें व्यक्तिगत त्वरण के लिए कोई प्रकाशित अनुरोध तंत्र नहीं है। व्यावहारिक उत्तर यह है कि अपने फ़ॉलबैक तर्क को ठीक से बनाना, जैसा कि ऊपर कवर किया गया है, एक्सेस को गति देने का प्रयास करने से अधिक मायने रखता है, क्योंकि समयरेखा वास्तव में बाहर से प्रकाशित या अनुमानित नहीं है।
क्या सीमाओं के बारे में बेहतर ईमानदारी का मतलब है कि Astra कुल मिलाकर अधिक कार्यों से इनकार करता है? नहीं, और यह सटीक होने लायक है। सिस्टम कार्ड मूल्यांकन विशेष रूप से मापता है कि क्या मॉडल एक ऐसी सीमा को स्वीकार करता है जो वास्तव में उसके पास है, न कि क्या यह सामान्य रूप से कार्यों को करने के बारे में अधिक रूढ़िवादी हो जाता है। एक कम गलत प्रस्तुति दर का अर्थ है कि यह अधिक ईमानदार है जब कुछ वास्तव में पूछे जाने पर पूरा नहीं किया जा सकता है, न कि यह पहले स्थान पर कम चीजों का प्रयास करता है।
क्या कंप्यूटर-उपयोग दृष्टिकोण वास्तव में साफ API उपलब्ध होने वाले कार्यों के लिए आवश्यक है? नहीं, और यह एक महत्वपूर्ण व्यावहारिक बिंदु है जिसे इस मास्टरक्लास ने अभी तक स्पष्ट रूप से नहीं बताया है। किसी भी कार्य के लिए जहाँ एक साफ, अच्छी तरह से प्रलेखित API पहले से मौजूद है, एक पारंपरिक API-आधारित दृष्टिकोण कंप्यूटर-उपयोग नेविगेशन की तुलना में तेज़, सस्ता और अधिक विश्वसनीय रहता है। Astra का वास्तविक लाभ विशेष रूप से बिना API वाले सॉफ्टवेयर की लंबी पूंछ है, या जहाँ UI ही एकमात्र विश्वसनीय इंटरफ़ेस है। कंप्यूटर-उपयोग तक पहुँचें क्योंकि कार्य को इसकी आवश्यकता है, इसलिए नहीं कि यह नया, अधिक प्रभावशाली लगने वाला विकल्प है।
सामान्य गलतियों का विस्तार
पहले नामित कुछ गलतियाँ अधिक विशिष्ट विवरण के साथ खोलने लायक हैं, क्योंकि शॉर्टहैंड संस्करण यह कम आंक सकता है कि उनमें पड़ना कितना आसान है।
यह मानना कि बेंचमार्क श्रेष्ठता का अर्थ पहले दिन प्रोडक्शन श्रेष्ठता है, विस्तारित। यह गलती विशेष रूप से इसलिए बढ़ती है क्योंकि बेंचमार्क वातावरण नियंत्रित होते हैं और इस मास्टरक्लास में दस्तावेजीकृत सत्र-सीमा घर्षण, गेटेड एक्सेस, या वास्तविक दुनिया की UI असंगति को पुन: उत्पन्न नहीं करते हैं। एक मॉडल वास्तविक क्षमता के माध्यम से अपने बेंचमार्क स्कोर अर्जित कर सकता है, जबकि अभी भी अपने पहले हफ्तों में विश्वसनीय रूप से तैनात करना मुश्किल हो सकता है, और इन्हें विरोधाभासी तथ्यों के बजाय पूरक के रूप में मानना या तो Astra की तत्परता को अधिक बताने या इसके वास्तविक क्षमता लाभों को खारिज करने की ओर ले जाता है, दोनों सटीक तस्वीर से चूक जाते हैं।
बिना फ़ॉलबैक पथ के निर्माण करना, विस्तारित। यह व्यवहार में जो विशिष्ट विफलता मोड पैदा करता है, वह एक सुविधा है जो इसका परीक्षण करने वाले डेवलपर के लिए पूरी तरह से काम करती है, जिसके पास प्रारंभिक एक्सेस है, और फिर वास्तविक उपयोगकर्ताओं के एक सार्थक हिस्से के लिए चुपचाप या एक भ्रामक त्रुटि के साथ विफल हो जाती है, जिनके पास अभी तक अपनी कोई गलती नहीं है। यह एक विशेष रूप से बुरा विफलता मोड है क्योंकि यह आपके अपने परीक्षण के दौरान अदृश्य है और केवल एक बार सतह पर आता है जब वास्तविक उपयोगकर्ता इसे हिट करते हैं, ठीक उसी तरह का बग जो चुपचाप विश्वास को कम करता है, बजाय जोर से विफल होने के जल्दी पकड़े जाने के लिए।
एक बताई गई सीमा को आगे बढ़ाने में विफलता के रूप में मानना, विस्तारित। यहाँ विशिष्ट जोखिम एक सत्र में गलत दिशा में मॉडल के व्यवहार को फिर से प्रशिक्षित करना है। यदि प्रत्येक ईमानदार "मैं यह नहीं कर सकता" को एक आक्रामक रीप्रॉम्प्ट के साथ पूरा किया जाता है जो वैसे भी कठिन प्रयास करने की मांग करता है, तो आप परोक्ष रूप से बातचीत पैटर्न सिखा रहे हैं कि ईमानदारी को दंडित किया जाता है और आत्मविश्वासपूर्ण अनुमान को पुरस्कृत किया जाता है, जो सिस्टम कार्ड द्वारा दस्तावेजीकृत सटीक सुधार को कमजोर करता है। एक ईमानदार सीमा को उपयोगी जानकारी के रूप में मानना, और जवाब में अपने स्वयं के दृष्टिकोण को समायोजित करना, बेहतर व्यवहार को मजबूत करता है।
कंप्यूटर-उपयोग-विशिष्ट ड्रिफ्ट जोखिम को नजरअंदाज करना, विस्तार से। यह गलती विशेष रूप से इसलिए आसानी से होती है क्योंकि कंप्यूटर-उपयोग एजेंट अक्सर किसी दिए गए वर्कफ़्लो के पहले कुछ प्रयासों में सफल हो जाते हैं, जिससे एक झूठा विश्वास पैदा होता है, इससे पहले कि कोई UI अपडेट, कोई अप्रत्याशित पॉपअप, या थोड़ी अलग पेज स्थिति एक मूक गलती का कारण बने जो किसी का ध्यान नहीं जाती क्योंकि कोई भी अब जाँच नहीं कर रहा था। स्क्रीनशॉट-पुष्टि अनुशासन हर रन पर थोड़ा ओवरहेड खर्च करता है, और इसे छोड़ने का प्रलोभन जब चीजें विश्वसनीय रूप से काम कर रही हों, ठीक उसी समय होता है जब यह एक ऐसी विफलता मोड से बचा रहा होता है जो अभी तक हुआ ही नहीं है, न कि उससे जो पहले ही अनावश्यक साबित हो चुका है।
अभी चीजों की वास्तविक स्थिति
GPT-6 Astra वास्तव में एक महत्वपूर्ण क्षमता छलांग है, जिसकी पुष्टि कई स्वतंत्र बेंचमार्क और वास्तविक प्रारंभिक उत्पादन परीक्षणों में हुई है। साथ ही, अभी यह एक ऐसा मॉडल है जिसमें वास्तविक, प्रलेखित घर्षण, तेज़ सत्र खपत, असमान पहुँच, और एक कंप्यूटर-उपयोग प्रतिमान है जिसके लिए पिछली पीढ़ियों पर काम करने वाले प्रॉम्प्टिंग अनुशासन से अलग अनुशासन की आवश्यकता होती है।
ये दोनों बातें एक साथ सच हैं, और अभी इसका अच्छी तरह से उपयोग करने का वास्तविक कौशल तथ्यों के दूसरे सेट के आसपास निर्माण करना है, जबकि पहले से वास्तविक लाभ उठाना है। यह कोई अस्थायी लॉन्च-सप्ताह की चेतावनी नहीं है। यह एक सटीक तस्वीर है कि एक फ्रंटियर मॉडल अपने पहले हफ्तों में कहाँ स्थित है, इससे पहले कि खुरदरे किनारे चिकने हों और पहुँच सामान्य हो, और अपने वर्कफ़्लो को इस ईमानदार तस्वीर के आसपास बनाने का मतलब है कि जब घर्षण आपके अपने उत्पादन उपयोग में दिखाई देगा तो आप अचंभित नहीं होंगे।
Astra की पहुँच के और अधिक विस्तार और घर्षण बिंदुओं के हल होने या न होने पर अपडेट के लिए @cyrilXBT को फ़ॉलो करें।
