6 पॉइंट द्वारा GN⁺ 3 시간 전 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic ने 30 जून 2026 को Claude Sonnet 5 लॉन्च किया और इसका लक्ष्य Sonnet-स्तर की लागत पर अधिक महंगे Opus-स्तर के मॉडल के करीब agent execution क्षमता उपलब्ध कराना है
  • Sonnet 4.6 की तुलना में reasoning, tool use, coding, knowledge work में सुधार हुआ है, और effort नियंत्रण के जरिए अलग-अलग कार्यों के लिए लागत और प्रदर्शन के संतुलन को अधिक बारीकी से चुना जा सकता है
  • सुरक्षा मूल्यांकन में अवांछित व्यवहार, hallucination, चापलूसी, दुर्भावनापूर्ण अनुरोध स्वीकार करना, और prompt injection hijacking की संवेदनशीलता Sonnet 4.6 से कम थी, लेकिन कुछ misaligned व्यवहार Opus 4.8 और Claude Mythos Preview से अधिक थे
  • Free और Pro में यह default model के रूप में उपलब्ध है, और Max, Team, Enterprise, Claude Code, Claude Platform में भी इस्तेमाल किया जा सकता है; API model name claude-sonnet-5 है
  • Claude Platform की कीमत 31 अगस्त 2026 तक input के प्रति 10 लाख token पर $2 और output के प्रति 10 लाख token पर $10 है; इसके बाद यह input $3 और output $15 हो जाएगी, और नए tokenizer के कारण वही input content type के अनुसार लगभग 1.0–1.35 गुना token बन सकता है

Sonnet-स्तर में agent execution का विस्तृत दायरा

  • Claude Sonnet 5 को अब तक के Sonnet मॉडलों में सबसे अधिक agentic रूप में डिज़ाइन किया गया है, और इसका लक्ष्य उस स्तर की autonomous execution क्षमता देना है जिसके लिए कुछ महीने पहले तक बड़े और महंगे मॉडल की ज़रूरत पड़ती थी
  • planning, browser और terminal जैसे tools का उपयोग, और autonomous execution को Sonnet-स्तर के मॉडल पर संभालने लायक बनाया गया है
  • Sonnet 3.5, 3.6, 3.7 ने developers के लिए coding और tool use क्षमता दिखाने वाले शुरुआती Sonnet-स्तर के मॉडल के रूप में जगह बनाई थी, और उसके बाद सबसे स्पष्ट agent क्षमता सुधार Opus-स्तर के मॉडलों में दिखाई दिया
  • Sonnet 5, Opus 4.8 के साथ अंतर कम करता है और कम कीमत पर Opus 4.8 के करीब प्रदर्शन देता है

प्रदर्शन मूल्यांकन और effort नियंत्रण

  • Sonnet 5, Sonnet 4.6 की तुलना में reasoning, tool use, coding, knowledge work जैसे agent प्रदर्शन मानकों पर काफी बेहतर है
  • BrowseComp agent search मूल्यांकन और OSWorld-Verified computer use मूल्यांकन में इसने Sonnet 4.6 से लगातार बेहतर परिणाम दिखाए
  • effort स्तरों की तुलना में Sonnet 5, Opus 4.8 की तुलना में अधिक व्यापक cost-performance विकल्प देता है
    • मध्यम effort पर cost efficiency में बड़ा सुधार है
    • उच्च effort पर कुछ कार्यों में इसका प्रदर्शन Opus 4.8 के बराबर हो सकता है
  • उपयोगकर्ता Sonnet 5 और Opus 4.8 के बीच effort स्तर समायोजित करके अपने प्रोजेक्ट के लिए उपयुक्त लागत-प्रदर्शन संतुलन चुन सकते हैं

शुरुआती उपयोग मामलों में दिखा कार्य करने का तरीका

  • शुरुआती access partners ने Sonnet 5 को पिछले Sonnet मॉडलों की तुलना में कहीं अधिक agentic बताया
  • ऐसे उदाहरण मिले जहाँ पिछले Sonnet मॉडल बीच में रुक जाते थे, लेकिन Sonnet 5 ने जटिल कार्य अंत तक पूरे किए और स्पष्ट रूप से न कहे जाने पर भी अपने परिणाम स्वयं जाँचे
  • सत्यापित workflow में coding और non-coding दोनों तरह के कार्य शामिल थे
    • multi-step software engineering कार्यों में इसने लगातार coding, tool use और debugging संभाली
    • Salesforce account tier update और enterprise contacts को launch announcement भेजने वाले 2-step कार्य को इसने अंत तक पूरा किया
    • वास्तविक pull request के दर्जनों मामलों में इसने testing और verified results तक का काम स्वयं किया
    • bug investigation में reproduction test लिखना, fix implement करना, बदलाव stash करना, और bug के दोबारा न आने की जाँच तक का काम एक साथ किया
    • brownfield code में race condition, hidden test, और failure के वास्तविक root cause को ट्रैक करने में इसकी विशेष ताकत दिखी
  • legal research और analysis, ClickHouse के live data exploration, और Pace के insurance workflow जैसे non-coding कार्यों में भी प्रदर्शन और गति बेहतर होने के उदाहरण मिले

सुरक्षा मूल्यांकन और cyber security सीमाएँ

  • deployment से पहले की सुरक्षा जाँच में Sonnet 5 ने Sonnet 4.6 की तुलना में समग्र सुरक्षा में सुधार दिखाया
  • agent सुरक्षा के संदर्भ में malicious requests को अस्वीकार करने और prompt injection हमलों द्वारा hijacking की कोशिशों के खिलाफ इसकी प्रतिरोधक क्षमता बेहतर हुई
  • Sonnet 4.6 की तुलना में hallucination और चापलूसी की दर कम थी, और misuse cooperation तथा deception जैसे misaligned व्यवहारों की जाँच करने वाले automated behavior audits में इसका score भी कम रहा, यानी परिणाम अधिक सुरक्षित थे
  • हालांकि अधिक सक्षम Opus 4.8 और Claude Mythos Preview की तुलना में इस मूल्यांकन में कुछ misaligned व्यवहार की दर थोड़ी अधिक थी
  • Sonnet 5 को जानबूझकर cyber security कार्यों के लिए प्रशिक्षित नहीं किया गया
    • यह कुछ रोज़मर्रा के और हानिरहित cyber कार्य कर सकता है
    • software exploit development जैसी संभावित रूप से खतरनाक cyber skill evaluations में इसका प्रदर्शन Opus 4.8 और Mythos 5 से काफी कम है
    • Firefox browser vulnerability exploit development evaluation में यह पूरी तरह काम करने वाला exploit नहीं बना सका, लेकिन Sonnet 4.6 की तुलना में आंशिक सफलता दर थोड़ी अधिक थी
  • क्योंकि यह पिछले मॉडल की तुलना में इन कार्यों में थोड़ा अधिक सक्षम हुआ है, इसलिए इसे cyber safeguards डिफ़ॉल्ट रूप से सक्षम करके जारी किया गया है
    • यह खतरनाक cyber उपयोग को real time में पहचानकर ब्लॉक करता है
    • यही safeguards Claude Opus 4.7·4.8 पर भी लागू हैं
    • Sonnet 5 का समग्र cyber security risk level कम आंका गया है, इसलिए यह Fable 5 safeguards जितना सख्त नहीं है, जो cyber security कार्यों की अधिक व्यापक श्रेणी को ब्लॉक करते हैं
  • पूरा मूल्यांकन Claude Sonnet 5 System Card में देखा जा सकता है

उपलब्धता, कीमत और API

  • Claude Sonnet 5 सभी प्लान में उपलब्ध है
    • Free और Pro प्लान का यह default model है
    • Max, Team, Enterprise उपयोगकर्ता इसे इस्तेमाल कर सकते हैं
    • Claude Code और Claude Platform में भी यह उपलब्ध है
  • developers Claude API में claude-sonnet-5 का उपयोग कर सकते हैं
  • Claude Platform की शुरुआती कीमत 31 अगस्त 2026 तक input के प्रति 10 लाख token पर $2 और output के प्रति 10 लाख token पर $10 है
  • इसके बाद standard pricing input के प्रति 10 लाख token पर $3 और output के प्रति 10 लाख token पर $15 हो जाएगी
  • उच्च effort स्तर पर token उपयोग बढ़ने को ध्यान में रखते हुए Chat, Cowork, Claude Code, और Claude Platform में request limits बढ़ाई गई हैं
  • Sonnet 5, Sonnet 4.6 का upgrade है, लेकिन यह updated tokenizer का उपयोग करता है
    • प्रदर्शन सुधारने के लिए text processing का तरीका बदला गया है
    • समान input content type के अनुसार लगभग 1.0–1.35 गुना token में map हो सकता है
    • शुरुआती pricing इस तरह तय की गई है कि Sonnet 5 पर migration आम तौर पर cost-neutral रहे

BrowseComp chart update

  • 30 जून 2026 के edit में BrowseComp मूल्यांकन का cost-performance chart अपडेट किया गया
  • मूल chart ऐसे सरल methodology के data पर आधारित था जो Anthropic द्वारा agent search evaluation में उपयोग की जाने वाली standard methodology को प्रतिबिंबित नहीं करता था, और परिणामस्वरूप Sonnet 5 के प्रदर्शन का कम आकलन हुआ
  • अपडेटेड chart को standard methodology और Sonnet 5 system card में उपयोग और चर्चा की गई पद्धति के अनुरूप बनाया गया
    • इस पद्धति में 10M token budget, compression, और programmatic tool calling का उपयोग होता है
  • साथ की व्याख्यात्मक पंक्तियाँ भी अपडेट की गईं

4 टिप्पणियां

 
dhkd63 2 시간 전

शायद मैं opus4.8 का आदी हो गया हूँ, या फिर काफ़ी समय से sonnet इस्तेमाल नहीं किया था...
आज मैंने थोड़ी देर के लिए Sonnet इस्तेमाल किया और बहुत निराश हुआ।
पहले होता तो शायद मैं काफ़ी संतुष्ट हो जाता, लेकिन उम्मीद से ज़्यादा hallucination दिखे।

 
sea715 2 시간 전

fable तो दे दो..

 
seoseonyu 3 시간 전

जल्दी Fable दे दो... 😢😢

 
GN⁺ 3 시간 전
Hacker News की रायें
  • प्रति कार्य लागत वाले चार्ट को देखें तो लगता है Sonnet 5 को मध्यम effort level से ऊपर इस्तेमाल नहीं करना चाहिए। समान लागत में Opus हमेशा बेहतर करता है, इसलिए अगर Sonnet 5 medium पर्याप्त नहीं है, तो effort level बढ़ाने के बजाय model बदलना ही निष्कर्ष लगता है

    • ऐसी जानकारी सार्वजनिक करने के लिए शुक्रिया, लेकिन इसे follow करना धीरे-धीरे मुश्किल होता जा रहा है। अलग-अलग models और effort levels किस performance देते हैं और किन tasks के लिए सही हैं, इसका mental model खोता जा रहा है
      असल में मैं Claude Code के defaults ही इस्तेमाल करता हूं और वे काफी अच्छी तरह काम करते हैं। हालांकि यह जानने की जिज्ञासा है कि दूसरे users अपने projects के हिसाब से इन settings को कितना experiment और optimize करते हैं
    • यहां दो variables हैं। Claude.ai subscription में Sonnet, Opus से काफी सस्ता लगता है, और इसलिए Max tier में लंबे समय तक Sonnet-only usage bar रहा था
      दूसरा, कुछ tasks में pure input token मात्रा ही सबसे अहम होती है। उदाहरण के लिए multimodal computer-use tasks को Opus में reasoning कम करके ज्यादा efficient नहीं बनाया जा सकता, इसलिए Sonnet जैसे सस्ते models उपयोगी होते हैं
    • मैंने भी वही chart देखा और Opus की तुलना में curve की position काफी चौंकाने वाली थी। Sonnet 5 ऐसा लगता है जैसे “अगर Opus में एक और ultra-low effort level होता?”
    • counterargument के तौर पर कहें तो Sonnet ज्यादा तेज हो सकता है। यह पक्का नहीं, क्योंकि समान task के लिए ज्यादा tokens इस्तेमाल हो सकते हैं, लेकिन synchronous iterative workflow में यह ज्यादा काम निपटाने की संभावना रखता है
      हालांकि असल में model द्वारा बनाए गए results को ठीक करने में इतना समय लग जाता है कि मेरे हिसाब से धीमा होने पर भी ज्यादा smart model कुल समय घटा देता है
    • यह Sonnet model है, इसलिए Sonnet 4.6 से बेहतर होना तो सही है[0]। ज्यादा smart, तेज और सस्ता है, लेकिन Opus 4.8 low या GLM-5.2 की जगह इसे क्यों इस्तेमाल करूं, यह साफ नहीं है
      [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...
  • मेरे benchmark[0] से test करने पर यह GLM-5.2 level का है, लागत 2 गुना है लेकिन speed भी 2 गुना है
    कमजोरियां: commonsense quiz में 0/3, यानी built-in knowledge लगभग नहीं; complex tool-calling tasks में 45/100, जहां कभी-कभी गलत tool call करता है; और puzzle solving में 77 points, जहां car wash-type tests में गलती करता है
    [0]: https://aibenchy.com/compare/anthropic-claude-sonnet-4-6-med...

    • उस benchmark में Gemini 3.5 Flash top model दिखता है, जो मुझे समझ में नहीं आता
    • हमेशा की तरह, GLM-5.2 से तेज होने की बात का बहुत मतलब नहीं है। GLM-5.2 को कई providers serve करते हैं, इसलिए inference speed provider या समय के अनुसार काफी बदल सकती है
    • दोनों को planning और execution में इस्तेमाल करने की मेरी अपूर्ण तुलना के हिसाब से, GLM5.2 बहुत जल्दबाज है और कुछ करने की इच्छा इतनी ज्यादा होती है कि अक्सर समस्या बना देता है। उदाहरण के लिए, जब deployment या git इस्तेमाल नहीं करना चाहिए तब भी करने की कोशिश करता है
      दूसरी ओर Sonnet 5 मेरे इस्तेमाल किए Claude models में काफी ज्यादा आलसी था, और जब मैंने पूछे गए plan additions नहीं जोड़े, फिर पूछने पर झूठ बोला कि कर दिए। analysis[0] देखने पर मेरे लिए इसका value नहीं दिखता, दूसरों के लिए अलग हो सकता है। Fable निश्चित रूप से काफी बेहतर था
      [0]: https://artificialanalysis.ai/models/claude-sonnet-5
  • कई benchmarks में medium से ऊपर effort level पर प्रति कार्य लागत Opus से ज्यादा हो जाती है, इसलिए समझना मुश्किल है कि इसे क्यों इस्तेमाल करें और बस Opus low effort level क्यों न इस्तेमाल करें
    मेरे दिमाग में सिर्फ वही case आता है जब Opus credits खत्म हो गए हों। बेशक API billing वाले use cases होंगे, लेकिन फिर भी लगता है कि low effort level वाला Opus ही इस्तेमाल करूंगा

    • आजकल Opus को बेवकूफी भरी चीजें करने से रोकना बढ़ता जा रहा है, और हर बार कहना पड़ता है कि काम को जरूरत से ज्यादा complex मत बनाओ
      लगता है models problem solving की बजाय user और company से ज्यादा पैसा निकालने की दिशा में optimize हो रहे हैं। मैंने 2–3 lines के simple Python task के लिए साफ निर्देश दिए थे, फिर Opus पूरी library बनाने की कोशिश क्यों करता है, समझ नहीं आता
    • मेरा मानना है कि specific task-based benchmarks रोजमर्रा के agentic use cases को ज्यादा reflect नहीं करते। अगर individual tasks को एक-एक करके solve करके हर बार context clear कर सकते हैं, तो Opus low effort level पर ऐसी efficiency मिल सकती है
      लेकिन real problems solve करते हुए iterate और explore करने पर context length धीरे-धीरे बढ़ती है, और तब Opus अक्सर महंगा हो जाता है
    • पुराने Opus models आखिरकार support से बाहर हो जाने की संभावना ज्यादा है, और समय के साथ यही सबसे सस्ता model बन जाएगा। अभी pricing बढ़ाने का तरीका यही है
    • system card[0] के pages 117–118 पर agentic coding benchmarks देखें तो low effort level पर भी यह Sonnet 4.6 के किसी भी level से बेहतर performance देता है और price भी काफी सस्ता लगता है। इसलिए Opus द्वारा planned tasks संभालने वाले worker के तौर पर यह ठीक हो सकता है
      [0] https://www.anthropic.com/claude-sonnet-5-system-card
    • speed बड़ा कारण है। कई बार simple task जल्दी खत्म करना होता है, और Opus के सोच शुरू करने तक 30–60 seconds इंतजार करना सच में बहुत धीमा लगता है
  • कहा गया है कि Claude Sonnet 5 अब तक के Sonnet में सबसे ज़्यादा agent जैसा बनाया गया है। यह योजना बनाता है, browser या terminal जैसे tools इस्तेमाल करता है, और उस स्तर तक autonomously execute कर सकता है जिसके लिए कुछ महीने पहले तक बड़े और महंगे model की ज़रूरत पड़ती थी
    मैं पूरी तरह agent-driven development के बजाय ज़्यादातर agent-assisted development करता हूँ, इसलिए Opus की तुलना में Sonnet 4.6 ज़्यादा इस्तेमाल करता रहा हूँ। लेकिन यह announcement मुझे सकारात्मक नहीं लगती। जैसे-जैसे model पूरी तरह agentic development के लिए optimize होता है, assisted development के लिए वह और खराब होता गया है और बहुत सख्त व स्पष्ट instructions के बावजूद अक्सर ज़रूरत से ज़्यादा काम फैलाने लगता है
    पिछले कुछ हफ्तों से मैं धीरे-धीरे K2.7 Code और GLM-5.2 की ओर शिफ्ट कर रहा हूँ। assistant use के लिए ये अक्सर काफी होते हैं, और बहुत तेज़ व सस्ते हैं

    • इन कंपनियों में से किसी एक के पास, यूँ कहें तो, agent-assisted development के लिए tailor किए गए model पर समय लगाने का साफ़ मौका है
      समस्या यह है कि लगता है उस कंपनी के अंदर के लोग मानते हैं कि 1–2 साल बाद कोई भी इस तरह काम नहीं करेगा
    • इन दिनों Kimi K2.6 इस्तेमाल कर रहा हूँ। कंपनी approval route से अभी 2.7 इस्तेमाल नहीं कर सकता, लेकिन जब मैं क्या करना चाहता हूँ यह पहले से पता हो और process को टुकड़ों में आगे बढ़ाना चाहता हूँ, तो यह ठीक है
      Opus की तुलना में थोड़ा ज़्यादा सुधारना पड़ता है। लेकिन असली कसौटी “हर line पढ़नी पड़ेगी” और “हर line पढ़े बिना भरोसा किया जा सकता है” के बीच है; मेरे लिए कोई भी model अभी दूसरे स्तर तक नहीं पहुँचा है और कुछ समय तक शायद नहीं पहुँचेगा। architecture brainstorm करके उसे code में बदलने में यह Opus जितना अच्छा नहीं है, लेकिन हमेशा वही समस्या नहीं होती, और ज़रूरत पड़े तो Opus इस्तेमाल कर सकता हूँ
      इसकी वजह से coding-heavy हफ्तों में भी बुधवार या गुरुवार तक spending limit से टकराए बिना पूरे हफ्ते आराम रहता है। हालांकि असल में लगता है कि K2.6 को Opus की तुलना में कहीं ज़्यादा रोकना पड़ता है। जब सिर्फ सवाल पूछना हो और वह तुरंत उसे coding task मानकर दौड़ न पड़े, इसके लिए बहुत ज़्यादा सावधान रहना पड़ता है। दोनों को plan mode में इस्तेमाल करता हूँ, लेकिन K2.6 में Opus से ज़्यादा defensive होकर इस्तेमाल करना पड़ता है
    • कुछ समय के लिए मैं पूरी तरह local models पर चला गया था, जो M1 Mac Studio 64GB memory पर चलते हैं। फिर भी जब local quantized Qwen3.6 कम पड़ता है, ऐसे दुर्लभ मामलों में Openrouter से जोड़कर Kimi, GLM, Deepseek जैसी चीज़ें Anthropic वगैरह की कीमत के एक हिस्से में इस्तेमाल करता हूँ
    • महसूस लगभग वैसा ही है और स्थिति भी मिलती-जुलती है। Sonnet इस्तेमाल करने का बड़ा फायदा response time है
    • OpenAI model, जैसे GPT 5.5, आज़माना अच्छा हो सकता है। यह prompt में तय instructions और boundaries को बेहतर follow करता है, और intelligence loss के बिना Claude models से ज़्यादा सक्षम agent assistant जैसा लगता है
      मेरा ज़्यादातर काम throw-and-forget तरीके का नहीं, बल्कि agentic engineering के करीब है। planning stage में भी लगातार शामिल रहता हूँ, results review करता हूँ और दूसरों की तुलना में agent से बहुत ज़्यादा सवाल पूछता हूँ। requirements, scope, design, कभी-कभी specific module boundaries तक तय कर देने के बाद खाली जगह भरने वाले “supercharged autocomplete” mode की तरह इस्तेमाल करना मेरे लिए सबसे बेहतर काम करता है
  • GLM 5.2 की तुलना में price-performance भी खराब दिखता है। GLM 5.2 में सिर्फ 744B parameters हैं, फिर भी ऐसा है
    system card में लिखा है कि “CyberGym vulnerability discovery में Claude Sonnet 5, Sonnet 4.6 से कम सक्षम है, और Opus 4.8 तथा Mythos 5 से बहुत कम सक्षम है”
    यह भी कहा गया है कि “इस section की दूसरी evaluations की तरह ये results सभी safeguards बंद करके प्राप्त किए गए थे। default mitigations चालू करके चलाने पर Sonnet 5 ने CyberGym में 0 score किया”

    • मैंने GLM-5.2 और Sonnet 4.6 से text फिर से लिखवाया, और large language models non-deterministic होते हैं इसलिए results पूरी तरह अलग निकले। GLM-5.2 ने कई subtle mistakes कीं जिन्हें हाथ से ठीक करना पड़ा, जबकि Sonnet ने दूसरे round में सारी mistakes ढूँढकर ठीक कर दीं
      planning और coding में भी ऐसा ही था। GLM-5.2 “कागज़ पर” अच्छा दिखता है, लेकिन actual use के results अलग थे
      मैं Claude या GLM-5.2 का बचाव करने की कोशिश नहीं कर रहा। नवंबर 2022 से रोज़ large language models इस्तेमाल करते हुए मैंने यह सीखा है कि general tests को अपने project पर verify करना चाहिए। “सब पर राज करने वाला एक model” नहीं है; हजारों models के haystack में से एक specific model ढूँढना पड़ता है
      benchmarks मदद करते हैं, लेकिन वे धीरे-धीरे car ads में mileage specs जैसे होते जा रहे हैं। actual mileage हर व्यक्ति के लिए अलग होता है
    • आखिरकार एक executable business strategy आ गई। security से अनजान code monkeys को सस्ते में बेचो, और उस गड़बड़ को साफ़ कर सकने वाले agent के लिए premium charge करो
    • किसी खास व्यक्ति पर निशाना नहीं है, लेकिन उम्मीद है कि HN की discussion quality कभी इन basic comparisons से आगे बढ़ेगी। हर model launch thread में वही comments दोहराए जाते लगते हैं
      “X model T benchmark में Claude Z से Y% बेहतर या खराब है”, “उसका कोई मतलब नहीं, benchmark-tuned है”, “daily coding या agent tasks में इस्तेमाल नहीं हो सकता, feel पूरी तरह गलत है”, “लगभग वैसा ही है और बहुत सस्ता है इसलिए मैं हर हाल में इस्तेमाल करूँगा”, “stepwise performance gap के कारण open models की lower cost productivity loss की भरपाई नहीं कर पाती, इसलिए justify नहीं होती” — इसी तरह
      मैं Anthropic से नाराज़ ग्राहक हूँ, और open models तथा non-closed intelligence को सच में support करता हूँ। लेकिन अब meme बन चुके model launch discourse की repetition से कैसे निकला जाए, समझ नहीं आता। मैं भी large language models या benchmarks design करने वाला व्यक्ति नहीं हूँ, और perfect न होते हुए भी information देने की कोशिशों की सच में सराहना करता हूँ। ऐसे announcement comments नियमित रूप से पढ़ने वाले ज़्यादातर लोग शायद ऐसा ही महसूस करते होंगे
  • Claude Sonnet 5 ने अपने pelican को goose की तरह describe किया
    “एक सफेद goose bicycle चला रहा है, एक wing आगे बढ़ाकर handlebar पकड़े हुए है, और plain white background पर brown ground line है”
    https://simonwillison.net/2026/Jun/30/claude-sonnet-5/

    • हाल के large language models द्वारा बनाए गए pelicans में यह शायद सबसे खराब हो सकता है
      दूसरी ओर GLM 5.2 ने शानदार और independently working fully animated SVG pelican बनाया था
      https://simonwillison.net/2026/Jun/17/glm-52
  • आज गलती से Sonnet 5 थोड़ा इस्तेमाल कर लिया, और software development में यह Opus 4.8 से काफी खराब लगा

  • सोच रहा हूँ कि साइबर सुरक्षा को लेकर ज़रूरत से ज़्यादा paranoia कहीं अंततः मॉडल से कम सुरक्षित code तो नहीं लिखवा देता। सुरक्षित code बनाने की क्षमता होने का मतलब है कि वह साइबर सुरक्षा के बारे में कुछ जानता है, और यह भी माना जा सकता है कि उसी ज्ञान से वह दुनिया भर के बैंकों को hack कर सकता है

    • image generation models में nude content को censor करने की कोशिश में anatomy दिखाने में तरह-तरह की समस्याएँ पैदा हुईं। लगता है ऐसे models में भी security को लेकर वैसी ही समस्याएँ आ सकती हैं
    • शायद वही लक्ष्य हो
  • मुझे इस model से काफी उम्मीद थी, इसलिए तीन अलग-अलग projects में Opus planners से कहा कि Opus sub-agents के बजाय Sonnet का इस्तेमाल करके HPC kernels experiments को तेज़ी से आगे बढ़ाने में मदद करें। लेकिन किसी ने भी code की एक लाइन तक नहीं लिखी, और Sonnet बस चक्कर काटते रहे और tokens बरबाद करते रहे
    याद भी नहीं कि मेरे codebase में Opus के साथ आखिरी बार ऐसा कब हुआ था। अब वापस revert कर रहा हूँ

    • नए model release के समय पहले भी ऐसा हुआ है। जब Opus 4.7 आया था, तब भी 20 मिनट से ज़्यादा “काम कर रहा हूँ” में अटका रहा, तो मैंने उसे पूरी तरह बंद कर दिया और अगले दिन तक इंतज़ार किया
      अपने-आप ठीक हो गया
  • अहम बात यह है: “Sonnet 5, Sonnet 4.6 का upgrade है, लेकिन performance सुधारने के लिए यह updated tokenizer इस्तेमाल करता है, जो model के text process करने के तरीके को बदलता है। यह Claude Opus 4.7 में पेश किए गए tokenizer बदलाव जैसा है। इसकी कीमत यह है कि वही input ज़्यादा tokens में map हो सकता है। content type के हिसाब से लगभग 1.0~1.35x। launch pricing इस तरह सेट की गई है कि Sonnet 5 पर switch करने पर लागत लगभग neutral रहे”

    • तो क्या इसका मतलब है कि launch period के बाद pricing ऐसी सेट होगी कि Sonnet 5 100~135% ज़्यादा महँगा पड़े?
    • “कीमत बढ़ाने के दो तरीके हैं। (1) per-token कीमत बढ़ाना या (2) users की ओर से generate किए जाने वाले tokens की संख्या बढ़ाना। हम वादा करते हैं कि (2) malicious तरीके से नहीं करेंगे। वादा करते हैं”