GLM 5.2 बनाम Opus

 (techstackups.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक ही one-shot prompt से raw WebGL 3D platform game बनवाने पर Opus ने अधिक तेज़ और अधिक परिष्कृत परिणाम दिए, जबकि GLM-5.2 ने कम लागत और open weights का फायदा दिखाया
  • GLM-5.2, Z.ai का MIT license open-weight मॉडल है, जो 1M token context और High/Max reasoning levels देता है, लेकिन text-only होने के कारण image-based self-verification में सीमाएँ हैं
  • वास्तविक टेस्ट लागत में GLM-5.2 $5.39 पर रहा, जबकि Opus लगभग $21.92 था; build time क्रमशः 1 घंटा 10 मिनट 40 सेकंड और 33 मिनट 30 सेकंड रहा, यानी गति और लागत के बीच साफ़ trade-off दिखा
  • GLM-5.2 के आउटपुट में texture missing, काम न करने वाले spikes, victory condition की अनुपस्थिति, और debug overlay बचे रहने जैसी बुनियादी समस्याएँ थीं; Opus अधिक साफ़ था, लेकिन हवा में पतले platform collision और दूर से trigger हो जाने वाली जीत की शर्त जैसी दिक्कतें रहीं
  • Benchmark और external evaluations में GLM-5.2 एक मज़बूत open-weight मॉडल दिखता है, लेकिन कई coding और agent tasks में Opus आगे रहता है; इसलिए cost, openness, और visual judgment चयन के मुख्य मानदंड बनते हैं

एक ही कार्य में सामने आया अंतर

  • GLM-5.2 open model की संभावनाएँ दिखाने वाला नया उदाहरण है, लेकिन उसी वास्तविक कार्य में Claude Opus 4.8 ने अधिक तेज़ और अधिक सटीक परिणाम दिए
  • टेस्ट में दोनों मॉडलों को एक ही one-shot prompt दिया गया, और game engine या Three.js जैसी 3D rendering library के बिना browser के लिए 3D platform game को raw WebGL में scratch से बनाना था
  • दोनों परिणाम और source सार्वजनिक हैं
  • दोनों गेम free CC0 assets Kenney Platformer Kit का उपयोग करते हैं

GLM-5.2 का स्वभाव और approach

  • GLM-5.2, Z.ai का नवीनतम flagship model है और MIT license open weights के साथ उपलब्ध है
    • इसे download करके सीधे चलाया जा सकता है या Z.ai API से बुलाया जा सकता है
    • Weights Hugging Face और ModelScope पर उपलब्ध हैं और कोई regional restriction नहीं है
    • vLLM, SGLang, Transformers जैसे frameworks से local serving संभव है
  • यह मॉडल लंबे समय तक चलने वाले बहु-चरण coding agent workflows जैसे long-horizon tasks को ध्यान में रखकर बनाया गया है
    • यह 1M token context window देता है
    • Reasoning levels High और Max हैं, और टेस्ट में High का उपयोग हुआ
  • इसकी निर्णायक सीमा यह है कि यह text-only है
    • GLM-5.2 images नहीं पढ़ सकता
    • Screenshot या diagram को सीधे जाँचना हो, तो Claude Opus जैसे multimodal model की ज़रूरत पड़ती है

कीमत और execution cost

  • Vendor documentation के अनुसार 1M tokens पर GLM-5.2 की कीमत Opus से कम है
    • Claude Opus 4.8: input $5, cache read $0.50, output $25
    • GLM-5.2: input $1.4, cache read $0.26, output $4.4
  • Output tokens के आधार पर GLM-5.2 की कीमत Opus की पाँचवें हिस्से से भी कम है
  • लेकिन वास्तविक game-building test में समय और लागत का संतुलन अलग दिखा
मेट्रिक GLM-5.2 (Pi/OpenRouter) Opus (Claude Code)
Wall-clock build time 1 घंटा 10 मिनट 40 सेकंड 33 मिनट 30 सेकंड
Output tokens 131,000 216,809
अधिकतम context usage 1M का 16% 1M का 19%
Tool calls 128 153
लागत $5.39 actual billed amount लगभग $21.92 estimated
  • Opus ने लगभग आधे समय में काम पूरा किया, जबकि GLM-5.2 ने बहुत कम लागत में इसे पूरा किया

टेस्ट कार्य: raw WebGL 3D platform game

  • यह काम साधारण landing page बनाने से काफ़ी अधिक जटिल था
    • GLB model parser
    • matrix और vector math
    • GLSL shaders
    • skinned skeletal animation
    • fixed timestep loop
    • collision handling
    • follow camera
  • दोनों मॉडलों को एक ही prompt, एक ही assets, और बिना किसी hint के single attempt दिया गया
  • Completion criteria ये थे
    • raw WebGL-आधारित 3D engine और renderer
    • दिए गए 3D character और world model loader
    • gravity और collision के साथ character movement और jump
    • follow camera और keyboard controls
    • एक command से browser में चलने वाला पूरा game
  • दोनों मॉडलों ने GLB binary parser, matrix/quaternion math, WebGL2 renderer, GLSL skinning shader, और substep AABB collision का बड़ा हिस्सा सीधे implement किया
  • Build logs भी सार्वजनिक हैं

खेलने का परिणाम और बचे हुए bugs

  • दोनों गेम third-person 3D platformer के रूप में बने
    • WASD या arrow keys से movement
    • Space से jump
    • Shift से run
    • mouse drag से camera rotate
    • wheel से zoom
    • coins इकट्ठा करना, spikes से बचना, और flag तक पहुँचना लक्ष्य है
    • map के बाहर गिरने पर start point पर वापसी होती है

  • GLM-5.2 परिणाम

    • GLM-5.2 का गेम कुल मिलाकर काफ़ी rough finish दिखाता है
    • Character के कुछ materials गायब थे और character चलते समय movement direction के उलट दिशा में मुड़ जाता था
    • Spike traps character को मारते या reset नहीं करते थे, और flag तक पहुँचने पर भी victory condition trigger नहीं होती थी
    • Camera move होने पर सिर गायब हो जाता था, और debug overlay भी बचा हुआ था
    • Spring पर कदम रखने पर character का अगले platform तक उछल जाना सही काम करता था
    • Kenney models एक अलग file में shared color palette को refer करते हैं, लेकिन GLM-5.2 का renderer वह file load नहीं करता, इसलिए उसे flat colors से बदल दिया गया

  • Opus परिणाम

    • Opus का गेम अधिक साफ़ और बेहतर काम करता है
    • Camera और controller काम कर रहे थे, और spikes द्वारा player को मारने वाला logic भी काम करता था
    • Textures सही तरह लागू थे, animation smooth थी, और flag तक पहुँचने पर जीत मिलती थी
    • बचे हुए bugs बुनियादी functionality की बजाय edge cases के करीब थे
    • Character थोड़ी देर platform के बगल की हवा में खड़ा रह सकता था; यह edge छोड़ने के तुरंत बाद भी jump की अनुमति देने वाले coyote-time grace period के ज़्यादा सेट होने का परिणाम था
    • Flag से अभी काफ़ी दूर होने पर भी victory condition trigger हो जाती थी

self-verification में multimodal अंतर

  • दोनों मॉडलों को काम पूरा करने से पहले आउटपुट verify करने का निर्देश दिया गया था
  • Opus एक multimodal model है, इसलिए गेम render करने के बाद उसने capture किए गए screenshots को सीधे inspect किया
    • स्क्रीन पर बचे debug markers देखकर उन्हें हटाया और फिर finish किया
    • Final scene में block, stairs, coin, gem, spikes, flag, character, score HUD, lighting और geometry की जाँच की
  • GLM-5.2 images नहीं पढ़ सकता, इसलिए वह screenshots सीधे नहीं देख पाया
    • इसके बदले उसने raw pixel data पढ़कर यह जाँचने का workaround अपनाया कि colors लगभग अपेक्षित मानों से मेल खाते हैं या नहीं
    • Saved image में grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black जैसी color conditions देखी गईं
  • इस तरीके से वास्तविक visual समस्याएँ छूट गईं
    • Character धूसर दिखाई दे रहा था और textures गायब थे
    • Debug overlay अब भी स्क्रीन पर बना हुआ था
  • जिन कार्यों में visual output अहम हो, वहाँ images समझने वाली multimodal verification वास्तविक quality difference पैदा करती है

benchmarks में स्थिति

  • Z.ai के model card benchmarks में GLM-5.2 कई श्रेणियों में शीर्ष closed models के ठीक पीछे दिखा, और कुछ reasoning benchmarks में आगे भी रहा
  • मुख्य आँकड़े इस प्रकार हैं
    • HLE: GLM-5.2 40.5, Opus 4.8 49.8
    • HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
    • AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
    • IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
    • SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
    • NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
    • ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
    • SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
    • MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
    • Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
  • ArtificialAnalysis के independent runs भी GLM-5.2 को एक मज़बूत open-weight model मानते हैं
    • Intelligence Index v4.1 score 51
    • MiniMax-M3 44, DeepSeek V4 Pro 44, Kimi K2.6 43 से ऊँचा
    • TerminalBench v2.1 78% था, जो model card के 81 या 82.7 से अलग harness का उपयोग करता है
    • प्रति task output tokens लगभग 43k थे, जो GLM-5.1 के 26k से अधिक हैं
  • Benchmarks का रुझान वास्तविक टेस्ट जैसा ही था
    • GLM-5.2 open-weight models में अग्रणी है और reasoning में कुछ प्रतिस्पर्धात्मक बढ़त रखता है
    • Opus कई coding और agent benchmarks में आगे है

बाहरी प्रतिक्रियाएँ

  • Simon Willison ने GLM-5.2 को “शायद सबसे शक्तिशाली text-only open-weight LLM” कहा
    • उनके SVG test में GLM-5.2 ने साइकिल चलाते pelican का पूरी तरह animated रूप बनाया और कुछ टूटा हुआ नहीं था
    • Scooter चलाते possum वाले test में यह पिछले GLM-5.1 से बेहतर नहीं था, यानी प्रदर्शन पूरी तरह एकसमान नहीं है
  • Artificial Analysis ने GLM-5.2 को अपने Intelligence Index में leading open-weight model माना
    • उनका मानना है कि यह उसी स्तर पर सबसे सस्ता model है और cost-to-intelligence frontier पर स्थित है
    • लेकिन इसे प्रति task लगभग 43k output tokens खर्च करने वाला token-hungry model भी बताया गया
  • Nathan Lambert ने कहा कि LMArena leaderboard के आधार पर GLM-5.2 को Gemini से बेहतर agent माना जा सकता है, और MIT license open model के रूप में इसे “serious accomplishment” कहा
    • उन्होंने इस बात पर ज़ोर दिया कि शीर्ष अमेरिकी मॉडल अभी भी कुल मिलाकर आगे हैं, लेकिन चीनी research labs कम compute में ऊँचे scores तक पहुँच रहे हैं

कौन-सा मॉडल चुनें

  • GLM-5.2, Opus की लागत के एक हिस्से पर मज़बूत प्रदर्शन देने वाला open-weight model है
    • जब cost और openness महत्वपूर्ण हों, और काम मुख्यतः text और logic-केंद्रित हो, तब यह उपयुक्त है
    • Download किए जा सकने वाले weights को closed models की तरह अचानक retire या restrict नहीं किया जा सकता
  • Opus ने टेस्ट में अधिक तेज़, अधिक साफ़ और अधिक सटीक परिणाम दिए
    • यह visual outputs को सीधे देखकर verify कर सकता है
    • जहाँ accuracy, polish, और visual judgment महत्वपूर्ण हों, और cost स्वीकार्य हो, वहाँ यह अधिक उपयुक्त है
  • GLM-5.2, Opus का सीधा replacement होने से अधिक, एक सस्ता और हमेशा उपलब्ध शक्तिशाली सहायक मॉडल लगता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • मुझे सच में समझ नहीं आता कि one-shot prompting को लेकर इतना बड़ा हंगामा क्यों है
    परिभाषा के हिसाब से एक ही prompt किसी software project की complexity को समेट नहीं सकता। आखिर में model बस अपने training corpus में मौजूद code के आधार पर कई assumptions लगाकर result निकालता है
    इसकी बजाय मैं ऐसा coding agent देखना चाहूँगा जो इंसानों द्वारा review की गई spec के guardrails और coding conventions का पालन करते हुए plan file के steps को ठीक-ठीक follow करे। यह भी verify करना चाहिए कि इंसानों द्वारा तय किए गए goal के लिए agent loop guardrails से बाहर निकले बिना goal पूरा होने तक स्थिर रहता है या नहीं
    साथ ही, जिस use case को बनाना है उसके context को समझकर existing code में bugs या performance improvements की संभावनाएँ ढूँढना, और refactoring suggest करना, कहीं ज़्यादा मूल्यवान metric है

    • यह experiment इस मायने में दिलचस्प है कि यह देखता है कि model कुछ हद तक vague और open-ended spec से भी subjectively अच्छा माने जाने वाला result बना सकता है या नहीं
      यह output input से मेल खाता है या नहीं, इस तरह का benchmark कम है; ज़्यादा यह देखने जैसा है कि output internally consistent है या नहीं। अगर game हो, तो क्या वह goal तक पहुँचने पर खत्म होता है, spikes को छूने पर मरता है, और move करते समय कोई अजीब edge cases तो नहीं बनते, इसी तरह
      लेकिन मेरा मानना है कि वही execution environment इस्तेमाल करके experiment को कई बार दोहराना चाहिए था ताकि results की variance भी देखी जा सके
    • समस्या one-shot में नहीं, बल्कि खाली project से शुरू होने वाली greenfield स्थिति में है
      पहले हम उन engineers का मज़ाक उड़ाते थे जो किसी framework के README को follow करके खाली project पर test करते और फिर कहते, “हमारे 10 साल पुराने production app के लिए यही framework सबसे बढ़िया है।” Greenfield सोच हर समस्या का हल भी है और हर हल की समस्या भी
      one-shot capability भी एक महत्वपूर्ण self-measurement metric है, इसलिए इसे मापना चाहिए, लेकिन target पहले से स्थापित large codebase होना चाहिए
    • अभी इस समय कोई भी गंभीर काम one-shot में करने की कोशिश नहीं कर रहा, लेकिन फिर भी यह एक महत्वपूर्ण metric है
      Claude Code और Opus को इतना ध्यान इसलिए मिला क्योंकि execution environment बेहतर हुआ है, जिससे वे user input के बिना भी अपनी कई गलतियाँ खुद ठीक कर सकते हैं। लंबी अवधि में लगता है कि आने वाले समय में सबसे बड़े सुधार कई घंटों की autonomy और self-correction capability में होंगे
    • one-shot को test करना चाहिए, लेकिन तभी इसका मतलब बनता है जब prompt बहुत बड़ा हो, जैसे “इस spec के अनुसार इसे बनाओ”
      कुछ input tokens से लाखों tokens generate करना मुझे बहुत अर्थपूर्ण संकेत नहीं लगता
    • अगर model लगातार जटिल होती जा रही instructions लेकर इंसानी दखल के बिना requirements पूरी कर सकता है, तो overall performance को काफ़ी आसानी से judge किया जा सकता है
      बेहतर models को evaluate करने के लिए बस task में और requirements जोड़ दीजिए। भले ही यह realistic use case न हो, फिर भी मुझे यह उपयोगी तरीका लगता है
      हाँ, अगर कोई software engineer इसे guide करे तो model कहीं बेहतर result दे सकता है। engineer के हिसाब से यह और खराब भी हो सकता है

  • “उसी one-shot prompt के साथ Claude Opus 4.8 को सीधी टक्कर दी: raw WebGL में शुरू से 3D platform game बनाना” जैसे single one-shot runs न तो benchmark हैं और न ही real-world usage का प्रतिनिधित्व करते हैं
    ज़्यादातर agent usage collaborative होता है, इसलिए यह test करना चाहिए कि task देने पर वह test results गढ़े बिना उसे पूरा करता है या नहीं जैसी reliability, और वह मेरी instructions मानता है या अपनी मर्ज़ी से चलता है जैसी controllability

    • मैं लेखक हूँ, और पूरी तरह सहमत हूँ। इस बार यह benchmark नहीं बल्कि vibe test था, और असली benchmarks को मैंने अलग से सूचीबद्ध किया है
      यह test दिखाता है कि जब दोनों models को समय लेने वाला और technically कठिन one-shot task दिया जाए तो वे क्या कर सकते हैं
      collaboration, task delegation, completion, test-driven development, और controllability देखने वाला format आगे ज़रूर आज़माने लायक अच्छा test होगा
    • उल्टा, अभी मैंने Raspberry Pi agent पर GPT 5.5 लगाकर एक clearly defined long-running task रात भर चलाया था; यह लगभग 10 घंटे चला और लगभग खत्म होने वाला है। ऐसा use case भी वैध है
      सोचें तो, मैं जो agent work करता हूँ उसका ज़्यादातर हिस्सा main session से अपने prompts के साथ चलने वाले sub-agents ही होते हैं। इन्हें भी पूरी तरह autonomous work के छोटे version की तरह देखा जा सकता है
    • इसलिए formal benchmarks, side-by-side लंबा analysis, और कई भरोसेमंद लोगों के evaluations—इन सबको मिलाकर देखना चाहिए
      लेख में भी ऐसी बातों को कवर किया गया था, और इसे खुद formal benchmark के रूप में पेश करने का इरादा नहीं था। Formal benchmarks तो पहले से बहुत हैं

  • Anthropic लगातार 529 Overloaded दे रहा था, इसलिए कल मैंने GLM 5.2 के लिए signup करके उसे आज़माया
    मुझे यह पसंद आया, लेकिन GLM 5.2 के xhigh में सिर्फ 2 prompts वाले एक single session ने 5 घंटे reset window वाले light plan usage का 22% खा लिया
    result संतोषजनक था और quality भी ठीक थी। मैं दोनों इस्तेमाल करना चाहता हूँ, इसलिए अच्छा होगा अगर Anthropic और GLM को साथ इस्तेमाल करने वाला कोई integrated subscription plan हो

  • कुछ projects में GLM 5.2 इस्तेमाल करने का मेरा अनुभव यह है कि code लिखना शुरू करने तक इसे काफ़ी समय लगता है, और यह किसी भी तरह तेज़ model नहीं है
    exploration और planning phase में यह काफ़ी भटकता है, फिर बाद में खुद को सुधार लेता है, और इसे control करना आसान नहीं है। क्योंकि यह बाद में follow भी न करने वाली बातें hallucinate कर देता है। फिर भी output quality काफ़ी अच्छी है
    उदाहरण के लिए, मैंने Swift+Zig codebase में rendering optimize की, लेकिन 5,000 data items पर अटक गया। GLM 5.2 ने benchmark बनाने और data निकालने में 20 मिनट लगाए, और मैं frustrate होकर edit के अलावा tools की access रोककर उठ गया। करीब 30 मिनट बाद लौटा तो उसने पहले से बनाए गए benchmark और कुछ “conclusions” के आधार पर 3 bottlenecks optimize कर दिए थे, और यह भी कहा था कि अपने संदेह को verify नहीं कर सकता, इसलिए ज़्यादा data चाहिए
    implementation अच्छी तरह काम कर रहा था, idiomatic था, और non-invasive भी। यह भी कह सकता हूँ कि उसी repository में GPT 5.5 द्वारा बनाए गए result से ज़्यादा idiomatic था। मैं इसे और इस्तेमाल करना चाहूँगा, लेकिन GPT आम तौर पर वही request 5 गुना तेज़ पूरी कर देता है
    GLM 5.2 की वजह से मैं isolated containers और JJ workspaces के अंदर कई instances को parallel चलाने वाली setup तैयार करने लगा हूँ

    • मैंने हाल ही में इसे एक low-priority task पर इस्तेमाल किया था, जिसे दूसरे models solve नहीं कर पा रहे थे, और मैं Opus 4.8 खर्च नहीं करना चाहता था
      समस्या यह थी कि macOS menu bar में left click को intercept करना था, और Ctrl+click या right click को इस तरह menu खोलने देना था जैसे वह सामान्य left click हो, लेकिन conditionally
      problem-solving session के बीच में मैंने model को GLM-5.2 पर switch कर दिया, दोबारा prompt भी नहीं दिया, बल्कि reasoning के बीच में ही बदल दिया, और कुछ मिनट बाद समस्या ठीक हो गई। यह OpenCode Go के subscription-based allocation में इस्तेमाल किया गया था, और ऐसी समस्याएँ Opus usage को मौजूदा 5 घंटे window या यहाँ तक कि साप्ताहिक limit तक भी जला सकती थीं
    • पूरी reasoning trace देख पाना भी अच्छा लगता है
      अगर model को track से उतरते देखूँ या वह कुछ ऐसा पकड़ ले जो मैंने बताया नहीं, तो मैं उसे रोककर ठीक कर सकता हूँ। या फिर यह भी सीख सकता हूँ कि उसने वह चुनाव क्यों किया, जिससे बाद में संदेह कम रहता है

  • मेरा अनुभव भी कुछ ऐसा ही है। मैं इसे Pi में इस्तेमाल कर रहा हूँ; यह स्मार्ट है और आउटपुट भी अच्छा देता है, लेकिन वहाँ तक पहुँचने की प्रक्रिया efficent नहीं है

    • कीमत भी एक समस्या है। मैं इसे आज़माना चाहता था, लेकिन अगर यह Opus से सिर्फ 30% सस्ता है, तो इन समस्याओं के रहते मैं शायद इसे नहीं चुनूँगा

  • इसमें लिखा है, “GLM-5.2 इमेज पढ़ नहीं सकता, इसलिए यहाँ समस्या हुई। क्योंकि यह multimodal नहीं है। इसलिए स्क्रीनशॉट देखने के बजाय raw pixel data पढ़कर यह जाँचने के लिए एक script लिखने की जुगाड़ की गई कि रंग लगभग उम्मीद के मुताबिक आए या नहीं,” लेकिन इससे बेहतर तरीका https://github.com/openbmb/MiniCPM-V का इस्तेमाल करना है

    • सही है। अगर text LLM को vision-only agent का access दे दिया जाए, तो यह समस्या हल हो जाती है
      अगर सच में चाहें, तो इमेज के लिए Opus को भी call कराया जा सकता है, और तब भी शायद लागत बचेगी

  • open source model को प्रयोग में लाने के लिए मैंने Ollama में साइन अप किया
    पिछले 3 महीनों से मैं बस लगातार प्रयोग और इस्तेमाल के स्तर पर था, लेकिन GLM पहला model है जिसे मैं Claude के साथ असली coding काम में हर दिन इस्तेमाल कर रहा हूँ। यह काफ़ी अच्छा है, इसलिए मैं रोज़ Ollama की usage limit पूरी भर देता हूँ

    • दिलचस्प है। आप GLM को किस तरह के कामों के लिए इस्तेमाल कर रहे हैं, और Ollama के ज़रिए आपको कौन-से दूसरे model उपयोगी लगे, यह जानने की उत्सुकता है

  • GLM में token भी कम लगते हैं और tool call भी कम होते हैं, लेकिन completion में दोगुने से ज़्यादा समय लगता है
    अगर वह समय model के व्यवहार में ही नहीं लग रहा, तो वह कहाँ खर्च हो रहा है, यह जानने की जिज्ञासा है
    क्या हर tool call ज़्यादा जटिल है इसलिए ज़्यादा समय लेता है, या model हर token पर ज़्यादा computation करता है, इसलिए tokens per second कम हैं?

    • Opus और GPT 5.5 काम के हिसाब से सोचने और reasoning की तीव्रता को समायोजित करने में बहुत अच्छे हैं, और open weight model अभी उस मामले में कुछ कमज़ोर लगते हैं
      साथ ही GLM 5.2 या DeepSeek v4 Pro जैसे कुछ open weight model की token generation speed काफ़ी धीमी होती है, जिससे महसूस होने वाली latency पर असर पड़ता है। फिर भी GLM 5.2 को धीमा model कहना मुश्किल है; उदाहरण के लिए, अभी Notion के भीतर यह सबसे तेज़ models में से एक है
    • सबसे बड़ा असर उस data center का हो सकता है जहाँ model चल रहा है
      एक और संभावना यह है कि Opus Mixture of Experts जैसी किसी पद्धति का इस्तेमाल करता हो, इसलिए model का वह हिस्सा जो एक बार में memory में लोड होता है, GLM से छोटा हो सकता है
    • यह infrastructure की वजह से हो सकता है। लगता है Anthropic इस मामले में कहीं बेहतर तैयार है

  • GLM 5.2 में एक बड़ी समस्या है जो सार्थक सफलता को सीमित कर सकती है: coding subscription की value
    सिर्फ API pricing देखें तो GLM 5.2 अपने competitors को हरा देता है। लेकिन coding काम में API billing का इस्तेमाल सिर्फ बड़े enterprise करते हैं, और इनके लिए भारी subsidized subscription products धीरे-धीरे गायब हो रहे हैं
    साथ ही, ऐसी कंपनियाँ अपने कर्मचारियों को Chinese API इस्तेमाल नहीं करने देंगी
    individual और small team के नज़रिए से Z.ai की coding subscription, Anthropic और OpenAI से कमज़ोर है। Claude के साथ शायद मिलती-जुलती usage मिल जाए, लेकिन Codex में भुगतान के अनुपात में usage साफ़ तौर पर ज़्यादा है
    Z.ai ने GPT5.5 और Opus 4.8 को कितना catch up किया है, इस पर बहस हो सकती है, लेकिन अगर ऐसी दुनिया हो जहाँ सबकी कीमत एक जैसी हो और मैं खुलकर चुन सकूँ, तो मैं GLM नहीं चुनूँगा
    इसलिए असली सवाल यह है कि GLM 5.3 या 6 में Z.ai का product कितना बेहतर होगा, और OpenAI व Anthropic निकट भविष्य में अपने मौजूदा products को कितना सीमित करेंगे

    • अमेरिका के बाहर से देखें तो तस्वीर अलग दिखती है। European कंपनियाँ अमेरिकी export controls की वजह से Fable खो चुकी हैं, और उससे पहले Anthropic ने घोषणा की थी कि वह data को 30 दिन तक रखेगा
      ऐसी AI के केंद्र में infrastructure बनाना जिसे कभी भी छीना न जा सके, इन कंपनियों के लिए तुरंत value रखता है। Europe के बाहर के दूसरे देश कीमत के प्रति ज़्यादा संवेदनशील हैं, और Chinese कंपनियों से संबंध बनाने को लेकर वही डर भी नहीं रखते
    • API billing का इस्तेमाल सिर्फ बड़े enterprise नहीं करते, इसमें OpenCode जैसे third-party execution environment इस्तेमाल करने वाले लोग भी आते हैं
      साथ ही, अगर “ये कंपनियाँ अपने कर्मचारियों को Chinese API इस्तेमाल नहीं करने देंगी,” तो फिर GLM देने वाला Amazon Bedrock किसे target कर रहा है, यह सवाल उठता है
      individual लोग शायद DeepInfra जैसे सस्ते अमेरिकी providers चुनेंगे। GLM का cached input 10 लाख token पर $0.18 है और Opus का $0.50। Fireworks AI भी एक विकल्प है
    • मेरी नज़र में personal subscription नुकसान सहकर दिया जाने वाला bait है। पैसा enterprise token contracts से कमाया जाता है
      जो कर्मचारी और छात्र 20 डॉलर या 100 डॉलर के plan में हज़ारों डॉलर के token खर्च करते हुए coding के आदी हो जाते हैं, वही enterprise spending को आगे बढ़ाएँगे
      सिर्फ इसलिए कि कोई competitive Chinese model आ गया, यह enterprise spending replace नहीं हो जाएगी; लेकिन अमेरिका या EU में hosted open model ऐसा कर सकते हैं
      GLM 5.2 की मौजूदगी OpenAI और Anthropic की API access pricing पर एक ऊपरी सीमा बना देती है
    • यह महत्वपूर्ण point है। मुझे लगता है API pricing model अंततः वैसे ही गायब हो सकता है जैसे MMS के लिए अलग से पैसे देना गायब हो गया। यह एक पुराना model है
      मेरा अंदाज़ा है कि ज़्यादातर काम coding plan के भीतर ही हो रहा होगा
      लेकिन usage limit के अलावा भी plans का इतना restrictive होना परेशान करने वाला है। वजह समझ में आती है, फिर भी असुविधाजनक है। व्यवहार में देखें तो सिर्फ Anthropic और शायद Google ही सच में बहुत सख्त हैं
      Anthropic ने इस नीति से डर पैदा किया कि अगर उसे लगे कि उपयोग terms of service के अनुकूल नहीं है, तो वह बाद में API rates पर billing कर सकता है। यह बेबुनियाद चिंता भी हो सकती है, लेकिन मुझे सच में लगा कि वे ऐसा कर सकते हैं, इसलिए मैं उससे बचता हूँ
    • OpenRouter में मेरा account और balance था, इसलिए GLM 5.2 को test करते हुए मैंने बेहतर conditions की उम्मीद में z.ai subscription देखने की कोशिश की
      लेकिन वहाँ का infrastructure साफ़ तौर पर overload था, इसलिए 5.2 chat requests 100% timeout हो गईं। जब infrastructure model performance के साथ तालमेल बैठा ले, तब बाद में फिर कोशिश करूँगा, और तभी तय कर पाऊँगा कि subscription वाकई value रखती है या नहीं

  • आज GLM-5.2 aesthetic sense और UI कामों में GPT-5.5 से काफ़ी बेहतर लगा, यह देखकर मैं हैरान था
    फिलहाल मैं Conductor के ज़रिए Claude/Codex setup बनाए रखूँगा, लेकिन इस model की वजह से मैंने OpenCode configure किया और desktop app डाउनलोड की, और आज का ज़्यादातर काम वहीं किया

  • “GLM-5.2 की लागत बहुत कम थी। Opus ने आधे समय में काम खत्म किया और ज़्यादा साफ़-सुथरा game दिया” जैसे वाक्य देखते ही तुरंत LLM-जैसी शैली महसूस होती है
    लगता है सारे model इसी writing style पर converge हो गए हैं, और performance बेहतर होने पर भी यह हिस्सा ज़्यादा बदलता नहीं दिखता

    • यह अच्छा feedback है। इस तरह की LLM-जैसी writing style अभी एक समस्या है जिसका हम सामना कर रहे हैं और जिसे सुधारने की कोशिश कर रहे हैं

टेक्निकल राइटिंग इंडस्ट्री को इस समय बड़ा झटका लग रहा है। कंपनियाँ कम समय में ज़्यादा काम मांग रही हैं और quality काफ़ी गिर गई है, इसलिए रोज़मर्रा में लेखन के वाक्यों की quality निखारने का समय लगातार कम होता जा रहा है
हम अभी इस बदलाव की अग्रिम पंक्ति में काम कर रहे हैं, इसलिए इसका सबसे बड़ा असर हम पर पड़ रहा है, लेकिन साथ ही यह बात कि हम बदलावों को सबसे पहले प्रयोग करके देख सकते हैं, उत्साहजनक भी है और बेहद निराशाजनक भी

  • ऐसा लगता है कि असली लोग भी अब LLM शैली को बहुत ज़्यादा स्वीकार करने लगे हैं
  • सही। यह सच में खटकता है। अब नए लिखे जा रहे लेखों में लगभग आधे एक ही “आवाज़” में सुनाई देते हैं