GPT 6.1 Sol: पाँचवे हिस्से की कीमत पर Astra के करीब की बुद्धिमत्ता
OpenAI का GPT‑6.1 Sol रिलीज़, जिसे Astra की लगभग एक-पाँचवीं कीमत पर “near‑Astra” मॉडल बताया जा रहा है, एक तरफ़ सस्ते high-end capability के लिए उत्साह और दूसरी तरफ़ पुराने मॉडलों तथा Anthropic के Opus 5.5 के मुकाबले वास्तविक सुधारों पर संदेह, दोनों को जन्म दे रहा है। टिप्पणीकार अर्थशास्त्र पर बहुत ध्यान दे रहे हैं: आक्रामक API मूल्य कटौती, बहुत सस्ते cached tokens, और साथ ही subscription allowances में कटौती को बढ़ती price competition, नज़दीक आते IPOs, और मज़बूत Chinese तथा open-weight मॉडलों के दबाव के संकेत के रूप में देखा जा रहा है। कई लोगों का कहना है कि हाल के OpenAI releases (खासकर GPT‑6 Sol) coding और agentic work में regression जैसे लगे, जिससे यह धारणा और मज़बूत होती है कि core intelligence धीरे-धीरे सुधर रही है, जबकि अब vendors मुख्यतः लागत, दक्षता, और harness quality पर प्रतिस्पर्धा कर रहे हैं.
GPT‑6.1 Sol की कथित गुणवत्ता बनाम 6.0, 5.6, Astra, और Opus 5.5
- कई लोगों का कहना है कि GPT‑6.0 Sol, 5.6 Sol से साफ़ तौर पर पीछे चला गया था: ज़्यादा मूर्खतापूर्ण गलतियाँ, ज़रूरत से ज़्यादा इंजीनियरिंग, खराब कोड, “बेबिसिटिंग” की ज़रूरत; कई लोगों ने 5.6 पर वापस लौटने या Opus पर स्विच करने का फैसला किया।
- 6.1 Sol को व्यापक रूप से एक “फिक्स” या प्रतिस्थापन माना जा रहा है: इसे बहुत कम लागत पर लगभग Astra-जितनी क्षमता वाला बताया जा रहा है, और संभवतः Astra या किसी “Astra Light” वैरिएंट से निकला हुआ माना जा रहा है।
- बेंचमार्क और कुछ उपयोगकर्ता परीक्षणों में 6.1 Sol, Astra के काफ़ी करीब और Opus 5.5 के साथ प्रतिस्पर्धी दिखता है, खासकर कोडिंग/गणित कार्यों में, और प्रति-कार्य लागत कम है।
- फिर भी, एक बड़ा समूह अभी भी वास्तविक प्रोजेक्ट्स (जटिल कोडिंग, रीजनिंग, कोड/गद्य में “taste”) में Opus 5.5 को साफ़ तौर पर बेहतर मानता है, और Astra का मुख्य उपयोग vision/3D/Blender कार्यों के लिए करता है।
मूल्य निर्धारण, सब्सक्रिप्शन, और बिज़नेस मॉडल
- API टोकन कीमतें, और खास तौर पर cache pricing, की सराहना की जा रही है (विशेषकर $0.10/M cached tokens और कुल DeepSeek/Anthropic parity)।
- साथ ही, $200 Pro प्लान को 20× से घटाकर 10× उपयोग किया जा रहा है, जबकि एक नया $500 प्लान सामने आया है; इसे व्यापक रूप से एक “nerf” और उच्चतर टियरों या शुद्ध API की ओर धकेलने के रूप में देखा जा रहा है।
- कई उपयोगकर्ता कहते हैं कि अभी Claude subscriptions, डॉलर के हिसाब से, ज़्यादा उपयोगी compute देती हैं; अन्य लोग नोट करते हैं कि frontier models को चलाना महंगा है और OpenAI संभवतः subscriptions पर नुकसान उठा रहा है।
रिलीज़ की गति, “धीमा पड़ना,” और सुरक्षा की बातें
- GPT‑6.1 Sol, 6.0 Sol के सिर्फ़ एक हफ़्ते बाद आता है; कई लोग इसे 6.0 पर आए नकारात्मक फ़ीडबैक और Opus 5.5 के जवाब में जल्दबाज़ी में की गई प्रतिक्रिया मानते हैं, न कि “frontier को pacing” करना।
- कुछ लोगों का तर्क है कि हाल की सारी pricing और coordination rhetoric, safety नहीं बल्कि compute और token-demand limits के बारे में है; दूसरों का मानना है कि क्षमता वृद्धि अभी भी स्पष्ट रूप से जारी है, रुकी नहीं है।
बेंचमार्क बनाम वास्तविक उपयोग
- कई benchmark suites दिखाते हैं कि 6.1 Sol, Astra से मेल खाता है और समान या कम लागत पर Opus 5.5 को लगभग टाई करता है या थोड़ा पीछे छोड़ता है।
- कई इंजीनियर इन आंकड़ों पर भरोसा नहीं करते: उनका कहना है कि मॉडल बेंचमार्क में अच्छा कर सकते हैं, लेकिन बड़े legacy codebases, refactors, और लंबे agentic workflows में फिर भी कमजोर पड़ते हैं।
- इस बात पर बार-बार निराशा जताई जाती है कि मॉडल कोड को ज़्यादा verbose बना देते हैं, अनावश्यक abstractions जोड़ देते हैं, और मजबूत स्कोर के बावजूद instruction-following में अलग-अलग व्यवहार दिखाते हैं।
open-weight और Chinese models से प्रतिस्पर्धा
- DeepSeek, Qwen, GLM, Kimi, और MiMo पर खूब चर्चा हो रही है। उपयोगकर्ता उनकी बेहद कम कीमतों को पसंद करते हैं और कहते हैं कि CRUD और सामान्य coding के लिए वे “काफ़ी अच्छे” हैं।
- दूसरे लोग नोट करते हैं कि वे अक्सर कहीं ज़्यादा tokens खपत करते हैं (खासकर reasoning tokens), अधिक hallucinate करते हैं, या “brilliant but stupid” जैसे लगते हैं, इसलिए frontier models अभी भी प्रति पूर्ण कार्य सस्ते और बेहतर हो सकते हैं।
Harnesses, agents, और token burn
- अनुभव harness (Codex, Claude Code, OpenCode, Pi, OMP) और subagent strategies पर बहुत निर्भर करता है।
- subagents का भारी उपयोग और बार-बार compaction कुछ ही घंटों में weekly quotas खत्म कर सकता है; सावधानीपूर्वक orchestration, context limits, और सस्ते sub-models का उपयोग महत्वपूर्ण माना जा रहा है।