Claude Code में Anthropic कम किए गए effort levels का A/B testing कर रहा हुआ दिखता है
Anthropic का Claude Code IDE डेवलपर्स की आलोचना झेल रहा है, जो कहते हैं कि इसके नए Opus और Fable models धीमे हैं, ज़्यादा verbose हैं, और कभी-कभी पर्दे के पीछे से “downgraded” जैसे लगते हैं, जिससे token usage और लागत बढ़ रही है। कई लोग कम “effort” settings पर या पुराने models के साथ बेहतर व्यवहार की रिपोर्ट करते हैं, और कुछ opaque billing incentives और enshitification की आशंकाओं के बीच प्रतिस्पर्धियों या open-weight models की ओर जा रहे हैं। एक Anthropic engineer जवाब देता है कि हाल के बदलाव internal effort mappings के A/B tests हैं, न कि quality reductions, लेकिन users अभी भी undisclosed routing, fluctuating performance, और भुगतान करते हुए test subjects बनाए जाने को लेकर चिंतित हैं.
अनुभूत effort-level बदलाव और model routing
- कई उपयोगकर्ताओं को संदेह है कि Anthropic Claude Code में “effort” settings का A/B testing कर रहा है, जिसमें load के आधार पर या user tier के अनुसार effort को गतिशील रूप से कम किया जा रहा है या सस्ते/कमज़ोर models की ओर routing की जा रही है।
- कुछ लोग बताते हैं कि chat models busy hours में “lobotomized” जैसे लगते हैं, जबकि direct API usage स्थिर महसूस होता है।
- इस पर बहस है कि क्या models अपनी effort level को भरोसेमंद तरीके से report कर सकते हैं; कुछ का कहना है कि यह सिर्फ system-prompt driven है और इसलिए जाना जा सकता है, जबकि अन्य आश्वस्त नहीं हैं।
Model quality, regressions, and verbosity
- कई लोग बताते हैं कि Opus 5 (और Fable) बहुत अधिक verbose, florid, और “LinkedIn-esque” हो गया है, और तुच्छ कार्यों के लिए भी thought की लंबी शृंखलाएँ बनाता है।
- रिपोर्टों में अत्यधिक overkill शामिल है (जैसे, एक साधारण config edit के लिए 40+ मिनट की अनावश्यक analysis) और उच्च effort levels पर math या accuracy का खराब होना।
- एक बार-बार आने वाला विषय: Opus 4.6 बहुत पसंद किया गया; 4.8 और 5 को, बेहतर benchmarks के बावजूद, व्यापक रूप से regressions माना जा रहा है।
- कुछ उपयोगकर्ताओं को Opus 5 कम या मध्यम effort पर स्वीकार्य या यहाँ तक कि मज़बूत लगता है, खासकर complex, multi-repo, multi-document synthesis के लिए।
Token usage, billing incentives, and limits
- यह मजबूत चिंता है कि higher effort defaults, verbose reasoning, और sub-agents द्वारा tokens “जलाना” प्रति-token revenue incentives के साथ मेल खाते हैं।
- अन्य लोग इसका जवाब देते हैं कि tight compute और competition को देखते हुए यह आर्थिक रूप से अविवेकपूर्ण है; users को बनाए रखने वाली चीज़ quality-per-token है।
- opaque, variable token costs और स्पष्ट, fixed resource controls की कमी से निराशा; कुछ लोग इसकी तुलना ऐसे vendor से करते हैं जो आपका “gas pedal” नियंत्रित कर रहा हो।
Alternatives और local/open models के साथ तुलना
- कई टिप्पणीकारों ने Codex, DeepSeek, GLM, Qwen, या Chinese open-weight models की ओर स्विच करने या आंशिक रूप से migrate करने की बात कही, speed, stability, या cost बेहतर होने का हवाला देते हुए।
- $20 subscriptions के मूल्य बनाम local hardware में निवेश पर बहस; कुछ का तर्क है कि local महँगा है, जबकि अन्य predictability और control पर ज़ोर देते हैं।
Trust, transparency, and safety programs
- Anthropic द्वारा configs में बदलाव करने पर opt-out के बिना प्रभावी रूप से “test subjects” बनाए जाने की शिकायतें।
- cyber-verification access रद्द किए जाने और silent downgrades या rerouting (जैसे, Fable → Opus) पर शिकायतें, जो हमेशा स्पष्ट रूप से दिखाई भी नहीं देतीं।
- “enshitification” को लेकर व्यापक चिंता: benchmarks, guards, या margins के लिए इस तरह optimize करना कि रोज़मर्रा की usability खराब हो जाए।