Claude Code के performance degradation को ट्रैक करने के लिए दैनिक benchmark

• Claude Code Opus 4.5 के SWE कार्य performance को हर दिन मापकर सांख्यिकीय रूप से महत्वपूर्ण performance degradation का पता लगाने वाला tracking system
• SWE-Bench-Pro के चुने हुए subset का उपयोग करके हर दिन 50 test instances का मूल्यांकन किया जाता है, और परिणाम CLI environment में सीधे चलाए गए वास्तविक model performance को दर्शाते हैं
• पिछले 30 दिनों में औसत pass rate 54% रहा, और baseline 58% की तुलना में सांख्यिकीय रूप से महत्वपूर्ण 4.1% गिरावट दर्ज की गई
• दैनिक और साप्ताहिक परिणामों का विश्लेषण 95% confidence interval और significance threshold (±14.0%, ±5.6%) के आधार पर किया जाता है, ताकि अल्पकालिक उतार-चढ़ाव और दीर्घकालिक रुझानों में फर्क किया जा सके
• एक स्वतंत्र third-party organization द्वारा संचालित, यह model या execution environment में बदलाव से होने वाले performance degradation का जल्दी पता लगाने का टूल है

---

अवलोकन

• इस tracker का उद्देश्य Claude Code Opus 4.5 के SWE कार्य performance में सांख्यिकीय रूप से महत्वपूर्ण गिरावट का पता लगाना है
  • हर दिन SWE-Bench-Pro के contamination-resistant subset का उपयोग करके evaluation किया जाता है
  • इसे सीधे Claude Code CLI में चलाया जाता है, किसी अलग custom harness के बिना, ताकि वास्तविक user environment को दर्शाया जा सके
• यह एक स्वतंत्र third-party organization है, जिसका frontier model providers के साथ कोई affiliation नहीं है
• सितंबर 2025 में Anthropic के performance degradation से जुड़े postmortem के बाद, भविष्य में ऐसे मामलों का जल्दी पता लगाने के लिए इसे resource के रूप में चलाया जा रहा है

performance सारांश

• baseline pass rate: 58%
• पिछले 30 दिनों का pass rate: 54% (655 evaluations के आधार पर)
• पिछले 7 दिनों का pass rate: 53% (250 evaluations के आधार पर)
• पिछले 1 दिन का pass rate: 50% (50 evaluations के आधार पर)
• 30 दिनों की performance गिरावट p < 0.05 स्तर पर सांख्यिकीय रूप से महत्वपूर्ण है
  • 30-दिन का परिवर्तन: -4.1%
  • significance threshold: ±3.4%
• 1 दिन (-8.0%) और 7 दिन (-4.8%) के परिवर्तन सांख्यिकीय रूप से महत्वपूर्ण नहीं हैं

दैनिक और साप्ताहिक रुझान

• दैनिक रुझान (Daily Trend)
  • पिछले 30 दिनों के दैनिक pass rate को visualize किया जाता है
  • baseline 58%, significance threshold range ±14.0%
  • 95% confidence interval भी दिखाया जा सकता है; sample size जितना छोटा होगा, interval उतना चौड़ा होगा
• साप्ताहिक रुझान (Weekly Trend)
  • 7-दिन moving average के जरिए दैनिक volatility को कम करके trend दिखाया जाता है
  • baseline 58%, significance threshold range ±5.6%
  • इसी तरह 95% confidence interval भी दिखाया जा सकता है

परिवर्तन अवलोकन (Change Overview)

• 1-दिन परिवर्तन (कल की तुलना में): -8.0%, सांख्यिकीय रूप से महत्वपूर्ण नहीं
  • 50 evaluations के आधार पर, ±14.0% परिवर्तन आवश्यक (p < 0.05)
• 7-दिन परिवर्तन (पिछले सप्ताह की तुलना में): -4.8%, सांख्यिकीय रूप से महत्वपूर्ण नहीं
  • 250 evaluations के आधार पर, ±5.6% परिवर्तन आवश्यक (p < 0.05)
• 30-दिन परिवर्तन (पिछले महीने की तुलना में): -4.1%, सांख्यिकीय रूप से महत्वपूर्ण
  • 655 evaluations के आधार पर, ±3.4% परिवर्तन आवश्यक (p < 0.05)

कार्यप्रणाली (Methodology)

• हर test को Bernoulli random variable के रूप में model किया जाता है, और 95% confidence interval की गणना की जाती है
• दैनिक, साप्ताहिक और मासिक pass rate के सांख्यिकीय अंतर का विश्लेषण करके महत्वपूर्ण performance degradation है या नहीं यह रिपोर्ट किया जाता है
• हर दिन 50 test instances के साथ evaluation किया जाता है, इसलिए अल्पकालिक volatility मौजूद रहती है
• साप्ताहिक और मासिक aggregate results अधिक स्थिर estimates प्रदान करते हैं
• model changes या execution harness changes से होने वाले performance degradation, दोनों का पता लगाया जा सकता है

अलर्ट सुविधा

• जब performance degradation सांख्यिकीय रूप से detect हो जाए तो email alert भेजा जाता है
• उपयोगकर्ता अपना email address दर्ज करके subscribe कर सकते हैं
• subscription confirmation के बाद alerts प्राप्त किए जा सकते हैं; त्रुटि होने पर retry guidance दी जाती है

---

[iolothebard]

Claude Code बेवकूफ़ नहीं हुआ है… बल्कि शायद ऐसा हो कि उसे इस्तेमाल करने वाला व्यक्ति Claude का और बेहतर इस्तेमाल करना सीख गया हो…

[GN⁺]

Hacker News की राय

• मैं Claude Code टीम से Thariq हूँ
  26 जनवरी को हुई harness समस्या को ठीक कर दिया गया था। 28 जनवरी को तुरंत rollback भी पूरा कर दिया गया, इसलिए claude update कमांड से latest version में update करने की सलाह है

  • Claude 2.1.x version अक्सर रुक जाता है या CPU को 100% इस्तेमाल करता है, इसलिए यह लगभग इस्तेमाल न करने लायक है। संबंधित issue GitHub #18532 में है
  • Claude ने tokens बर्बाद किए, तो क्या इसके लिए कोई मुआवज़ा है?
  • “harness issue” का सही मतलब क्या है, और इसका क्या प्रभाव पड़ा, यह और जानना चाहता हूँ
  • समस्या 26 जनवरी से पहले भी थी। उसी समय से Claude “सुधार” के नाम पर plans को मनमाने ढंग से बदलने लगा था
  • model से ज़्यादा quality control system को लेकर जिज्ञासा है। क्या वास्तविक output samples की नियमित जाँच होती है, या benchmarks से performance degradation को monitor करने की कोई internal process है? AI safety के लिहाज़ से भी ऐसी verification ज़रूरी है

• मैं SWE-bench का सह-लेखक हूँ
  अभी test शायद केवल 50 tasks पर दिन में एक बार चल रहा है। accuracy बढ़ानी है तो 300 tasks पर दिन में 5~10 बार test करके average निकालना चाहिए। server load जैसे random factors का परिणामों पर बड़ा असर पड़ सकता है

  • server overload से होने वाली performance degradation भी क्या measurement का हिस्सा नहीं होनी चाहिए? अगर उद्देश्य सिर्फ model distillation को मापना नहीं है, तो
  • शायद model run cost समस्या है। अच्छा होगा अगर Anthropic थोड़ी credits support दे, या donation link खोल दे
  • दिन के अलग-अलग समय पर performance gap और बड़ा हो सकता है
  • SWE-bench चलाने की लागत इतनी ज़्यादा है कि उसे पर्याप्त बार चलाना मुश्किल है। mafia-arena.com पर भी ऐसी ही समस्या है
  • “server overload है इसलिए measurement accurate नहीं है” यह बात अजीब लगती है। तो क्या Claude के ठीक से काम करने के कुछ working hours भी हैं?

• मैं यह बताता हूँ कि मुझे क्यों नहीं लगता कि Anthropic जानबूझकर users को खराब model दे रहा है

  1. accuracy में गिरावट छोटी है और oscillation की तरह ऊपर-नीचे हो रही है
  2. Sonnet 4.5 के लिए comparison baseline नहीं है, और GPU load के समय Opus भी Sonnet स्तर तक गिर सकता है
  3. संभव है कि कई checkpoints की A/B testing चल रही हो। Claude Code version updates या token sampling की non-determinism भी वजह हो सकती है
  • वैज्ञानिक explanation समझ में आती है, लेकिन रोज़ इस्तेमाल करने पर साफ़ लगता है कि performance खराब हो रही है
  • मुझे भी लगता है कि A/B testing ही मुख्य वजह है। context window limits या system prompt changes जैसी बातें transparently बताई जानी चाहिए। आदर्श रूप में users को खुद version चुनकर feedback देने का विकल्प होना चाहिए
  • graph 8 जनवरी से ही क्यों शुरू होता है, यह जानना चाहता हूँ। वह समय असामान्य रूप से ऊँचा दिन भी हो सकता था
  • load के अनुसार performance-cost tuning को automatically बदला जा रहा हो सकता है। शुरुआत में high performance से शुरू करके बाद में cost बचाने के लिए model को छोटा करना या MoE experts की संख्या घटाना जैसी tuning हुई हो सकती है
  • “गिरावट बहुत छोटी है” यह दावा statistical significance को नज़रअंदाज़ करने वाला सिर्फ subjective judgment है

• statistical methodology अजीब है
  वे सिर्फ पुराने values के confidence interval को देखते हैं और यह जाँचते हैं कि नया value उसके बाहर है या नहीं, लेकिन यह difference की statistical significance जाँचने का सही तरीका नहीं है। दोनों measurements में uncertainty होती है, इसलिए difference का confidence interval निकालना चाहिए। साथ ही, अगर monthly comparison करना है तो 60~31 दिन पहले के data की तुलना 30 दिन पहले से कल तक के data से करनी चाहिए, इसलिए graph में कम से कम दो महीने का data दिखना चाहिए

• लगभग एक हफ्ते पहले Claude करीब एक घंटे के लिए down था। restore होने के तुरंत बाद शायद users कम होने की वजह से speed 3 गुना से भी ज़्यादा तेज़ हो गई। उस एक घंटे में मैं सामान्यतः आधे दिन का काम निपटा सका। ऐसा लगा जैसे resource constraints के बिना भविष्य की एक झलक देखी हो

  • US holiday period में भी usage limits ढीली होने से सब कुछ बहुत ज़्यादा smooth चल रहा था
  • मेरे साथ भी कुछ दिन पहले ऐसा ही हुआ। वह इतना तेज़ था कि मैंने “claude speed boost” तक search किया। पुराने modem upgrade की तरह क्षणिक बिजली जैसी speed थी
  • बहुत ज़्यादा तेज़ हो जाए तो थोड़ा अफ़सोस भी होता है। अभी तो कम से कम यह महसूस होता है कि model मेहनत कर रहा है

• user prompts में गालियों की आवृत्ति मापी जाए तो model performance गिरने पर user hostility बढ़ना पकड़ा जा सकता है

  • लेकिन क्या Claude user prompts को ‘बस ऐसे ही’ scan करने का कोई तरीका है?
  • “How’s Claude Doing This Session?” जैसे feedback prompt के तुरंत बाद गालियाँ बढ़ने की correlation है
  • मैं तो सामान्य रूप से ही काफ़ी गालियाँ देता हूँ, इसलिए data skew हो सकता है
  • मैं भी ऐसा ही हूँ, यह जानकर तसल्ली हुई
  • कभी-कभी जब वह बहुत बेवकूफ़ी भरा जवाब देता है तो गाली निकल जाती है। यह ऊँची expectations की वजह से है

• समय के साथ model को धीरे-धीरे quantize किया जा रहा हो सकता है। इससे scalability और cost reduction आसान हो जाती है, और नया version तुलनात्मक रूप से ज़्यादा “बेहतर” भी दिख सकता है

  • मैं रोज़ 5~10 घंटे इस्तेमाल करता हूँ, और पिछले एक हफ्ते में यह साफ़ तौर पर ज़्यादा बेवकूफ़ लगा है। वे इनकार करें तब भी अनुभव में बदलाव महसूस होता है
  • quantization किए बिना भी conversation length घटाकर या reasoning time कम करके load घटाया जा सकता है
  • open models GPT-OSS और Kimi K2.x भी 4bit layers पर train किए गए थे। Opus 4.5 की प्रति token लागत 8 गुना ज़्यादा है, इसलिए यह बड़ा model हो सकता है, लेकिन subscription pricing structure की वजह से सीधी तुलना आसान नहीं है
  • Anthropic ऐसा infrastructure cost से बुरी तरह बँधा हुआ company नहीं लगता। इतनी कड़ी competition में quality को जानबूझकर घटाना खराब strategy होगी। संभव है users ‘honeymoon effect’ के बाद defects को ज़्यादा साफ़ देख रहे हों
  • फिर भी ऐसी gradual degradation strategy काफ़ी संभव लगती है। इससे नए model के relative improvement effect को maximize किया जा सकता है

• API mode में Claude एक निश्चित token count पार करते ही अचानक बेवकूफ़ हो जाता है, और “line 23 में bug है” कहकर पूरी functionality मिटा देता है जैसी अजीब हरकतें करता है। ChatGPT 3.5 से भी हो सकने वाली simple fixes तक fail हो जाती हैं। समझ नहीं आता ऐसा क्यों होता है

  • शायद यह resource constraints की वजह से है। कुछ users को बहुत अच्छे answers देने के बजाय, ज़्यादा users को ठीक-ठाक answers देना चुना गया होगा
  • मेरे साथ भी यही अनुभव रहा है। Claude धीरे-धीरे आलसी होता जा रहा है

• पिछले एक हफ्ते में Claude की code quality साफ़ तौर पर खराब हुई है। उदाहरण के लिए, Enum पर frozen इस्तेमाल करने को कहता है, या जिस function में पहले से urlparse इस्तेमाल हो रहा है उसमें फिर से urlparse सुझाता है। पहले वह ऐसी बुनियादी गलतियाँ नहीं करता था

• LLM providers में reasoning consistency की कमी एक बड़ी शिकायत है। ChatGPT में भी यही है; 45k tokens से ऊपर input देने पर intelligence तेज़ी से गिर जाती है या input cut हो जाता है। कम से कम “refusal” message देना बेहतर होगा; चुपचाप downgrade हो जाना भरोसा तोड़ देता है। transparency सच में बहुत महत्वपूर्ण है

  • शायद यह Maximum Effective Context Window phenomenon से जुड़ा है