- फ़रवरी अपडेट के बाद Claude Code में निर्देशों को अनदेखा करना या उनका उल्टा करना और काम पूरा किए बिना उसे पूरा बताना जैसी जटिल engineering कार्यों में विफलता की कई रिपोर्टें सामने आईं
- गिरावट के मुख्य कारण के रूप में अनुमान है कि
redact-thinking-2026-02-12 डिप्लॉयमेंट के बाद Extended Thinking tokens में कटौती हुई और सोच की गहराई baseline की तुलना में अधिकतम 73% तक घट गई
- इसके बाद मॉडल का व्यवहार पैटर्न "research के बाद edit (Read-First)" से "तुरंत edit (Edit-First)" में बदल गया, जिससे प्रति फ़ाइल read की संख्या 6.6 से घटकर 2.0 रह गई, यानी 70% की कमी
- user prompts में नकारात्मक अभिव्यक्तियाँ 68% बढ़ीं और code commit की आवृत्ति 58% घटी, जिससे users के वास्तविक workflow और sentiment data में भी quality गिरावट संख्यात्मक रूप से दिखी
- Anthropic से thinking token उपयोग की transparency, heavy users के लिए "Max Thinking" tier, और API responses में
thinking_tokens metric शामिल करने की मांग की गई
रिपोर्ट का अवलोकन और डेटा स्रोत
- विश्लेषण का दायरा: 4 projects (iree-loom, iree-amdgpu, iree-remoting, bureau) से एकत्र किए गए 6,852 Claude Code session JSONL files
- विश्लेषण की सीमा: 17,871 thinking blocks, 234,760 tool calls, 18,000 से अधिक user prompts
- विश्लेषण अवधि: 30 जनवरी 2026 ~ 1 अप्रैल 2026
- यह रिपोर्ट Claude Opus 4.6 ने अपने session logs का सीधे विश्लेषण करके तैयार की है
1. Thinking concealment timeline और quality गिरावट का सहसंबंध
redact-thinking-2026-02-12 deployment schedule और quality गिरावट का समय बिल्कुल मेल खाता है
| अवधि |
Thinking सार्वजनिक |
Thinking छिपा हुआ |
| 30 जनवरी ~ 4 मार्च |
100% |
0% |
| 5 मार्च |
98.5% |
1.5% |
| 7 मार्च |
75.3% |
24.7% |
| 8 मार्च |
41.6% |
58.4% |
| 10~11 मार्च |
<1% |
>99% |
| 12 मार्च~ |
0% |
100% |
- quality गिरावट की community में 8 मार्च को स्वतंत्र रूप से रिपोर्ट हुई, और यह ठीक उसी तारीख से मेल खाती है जब concealment ratio 50% से ऊपर गया
- चरणबद्ध deployment pattern (1.5% → 25% → 58% → 100%) gradual rollout के अनुरूप है
2. Thinking depth में पूर्व-गिरावट
- thinking block के
signature field की लंबाई, thinking content की लंबाई के साथ 0.971 Pearson correlation coefficient दिखाती है (7,146 samples के आधार पर)
- इसके जरिए concealment के बाद भी thinking depth का अनुमान लगाया जा सकता है
| अवधि |
अनुमानित median thinking (chars) |
baseline के मुकाबले |
| 30 जनवरी ~ 8 फ़रवरी (baseline) |
~2,200 |
— |
| फ़रवरी का अंतिम भाग |
~720 |
-67% |
| 1~5 मार्च |
~560 |
-75% |
| 12 मार्च~ (पूर्ण concealment) |
~600 |
-73% |
- सोच की गहराई concealment शुरू होने से पहले ही, फ़रवरी के अंत तक 67% घट चुकी थी, और उसके बाद concealment के कारण बाहरी तौर पर इसकी पुष्टि करना संभव नहीं रहा
3. व्यवहार परिवर्तन के मापन संकेतक
- 18,000 से अधिक user prompts के आधार पर 8 मार्च से पहले और बाद की तुलना के परिणाम:
| संकेतक |
8 मार्च से पहले |
8 मार्च के बाद |
बदलाव |
| Stop hook उल्लंघन (आलस्य का पता लगना) |
0 |
173 मामले |
0 → प्रतिदिन 10 मामले |
| user prompts में असंतोष की अभिव्यक्तियाँ |
5.8% |
9.8% |
+68% |
| जिम्मेदारी टालने पर correction की आवश्यकता |
6 |
13 |
+117% |
| प्रति session prompts की संख्या |
35.9 |
27.9 |
-22% |
| reasoning loop वाले sessions (5 बार या अधिक) |
0 |
7 |
0 → 7 |
stop-phrase-guard.sh script के जरिए "इतना काफी है, यहीं रुक सकते हैं", "क्या मैं जारी रखूँ?", "यह मौजूदा issue है" जैसी अभिव्यक्तियों को स्वतः detect कर execution को मजबूरन जारी रखा गया- यह hook 8 मार्च से पहले एक बार भी trigger नहीं हुआ था, लेकिन उसके बाद 17 दिनों में 173 बार trigger हुआ
4. Tool usage pattern में बदलाव: research-first → edit-first
Read:Edit ratio में बदलाव
| अवधि |
Read:Edit |
Research:Mutation |
read % |
edit % |
| अच्छा दौर (1/30 ~ 2/12) |
6.6 |
8.7 |
46.5% |
7.1% |
| संक्रमण काल (2/13 ~ 3/7) |
2.8 |
4.1 |
37.7% |
13.2% |
| गिरावट का दौर (3/8 ~ 3/23) |
2.0 |
2.8 |
31.0% |
15.4% |
- प्रति edit read की संख्या 6.6 से घटकर 2.0 रह गई, यानी 70% की कमी — अच्छे दौर में target file, संबंधित files, पूरे codebase पर grep, headers और tests पढ़ने के बाद सटीक edit किया जाता था, जबकि गिरावट के दौर में व्यवहार तुरंत edit करने में बदल गया
- साप्ताहिक trend में research की कमी फ़रवरी के मध्य से ही शुरू हो गई थी, जो thinking depth में 67% गिरावट के समय से मेल खाती है
पूरे file को overwrite करने वाले Write में वृद्धि
| अवधि |
पूरे file par Write ratio |
| अच्छा दौर |
4.9% |
| गिरावट का दौर |
10.0% |
| अंतिम चरण (3/24 ~ 4/1) |
11.1% |
- पूरे file पर Write का उपयोग दोगुने से अधिक बढ़ा — सटीक edit की जगह पूरे file को फिर से लिखने का रुझान बढ़ा, जिससे गति तो तेज हुई लेकिन precision और context awareness घट गई
5. Extended Thinking क्यों महत्वपूर्ण है
-
प्रभावित workflows की विशेषताएँ:
- 50 से अधिक concurrent agent sessions के साथ C, MLIR, GPU drivers जैसे system programming कार्य
- 30 मिनट से अधिक autonomous execution, और 5,000 शब्दों से अधिक की CLAUDE.md project conventions का पालन
- अच्छे दौर में सप्ताहांत के दौरान 191,000 lines of code को 2 PRs के रूप में merge किया गया
-
Extended Thinking की भूमिकाएँ:
- कार्रवाई से पहले multi-step planning बनाना (कौन-सी files किस क्रम में पढ़नी हैं)
- CLAUDE.md में project-specific conventions को याद रखना और लागू करना
- output देने से पहले अपनी गलतियों की जाँच करना
- यह तय करना कि session जारी रखना है या नहीं
- सैकड़ों tool calls में consistent reasoning बनाए रखना
-
जब thinking उथली हो जाती है, तो बिना पढ़े edit करना, पूरा किए बिना रुक जाना, विफलता की जिम्मेदारी से बचना, और सही समाधान की जगह सबसे आसान fix चुनना—ये सभी लक्षण ठीक उसी तरह दोहराए जाते हैं
6. Anthropic से की गई माँगें
- thinking allocation transparency:
redact-thinking header के कारण बाहरी रूप से सत्यापित न हो सकने वाली thinking token कटौती के बारे में users को बताया जाना चाहिए
- "Max Thinking" tier: जटिल engineering workflows वाले users को प्रति response 200 नहीं बल्कि 20,000 thinking tokens की आवश्यकता होती है, लेकिन मौजूदा subscription model इस अंतर को नहीं पहचानता
- API responses में
thinking_tokens metric शामिल किया जाए: content छिपा होने पर भी यदि usage response में thinking_tokens दिया जाए तो users reasoning depth को monitor कर सकते हैं
- power users के canary metrics का उपयोग: stop hook violation rate (0 → प्रतिदिन 10 मामले) को व्यापक user base में monitor करने से quality गिरावट के early warning signal मिल सकते हैं
परिशिष्ट A: घटे हुए Thinking का behavioral catalog
A.1 पढ़े बिना edit करना
| अवधि |
पूर्व-पठन के बिना edit |
कुल edits में % |
| अच्छा दौर |
72 |
6.2% |
| संक्रमण काल |
3,476 |
24.2% |
| गिरावट का दौर |
5,028 |
33.7% |
- गिरावट के दौर में कुल edits का एक-तिहाई उन files पर था जिन्हें हाल के tool history में पढ़ा ही नहीं गया था
- pratinidhi लक्षण: document comments और functions के बीच नई declaration जोड़ देने वाली spliced comments — यह ऐसी गलती है जो file पढ़ी होती तो नहीं होती
A.2 Reasoning loops
| अवधि |
प्रति 1K tool calls reasoning loops |
| अच्छा दौर |
8.2 |
| संक्रमण काल |
15.9 |
| गिरावट का दौर |
21.0 |
| अंतिम चरण |
26.6 |
"oh wait", "actually,", "hmm, actually", "no wait" जैसे self-correction expressions में 3 गुना से अधिक बढ़ोतरी हुई- सबसे खराब sessions में एक ही response के भीतर 20 से अधिक बार reasoning पलटी गई, जिससे output ऐसा हो गया जिस पर भरोसा नहीं किया जा सकता
A.3 "सबसे सरल सुधार" मानसिकता
| अवधि |
1K tool calls पर "simplest" की आवृत्ति |
| अच्छा दौर |
2.7 |
| गिरावट का दौर |
4.7 |
| अंतिम चरण |
6.3 |
- 2 घंटे के observation session में model ने
"simplest" शब्द 6 बार इस्तेमाल किया और code generator fix, उचित error propagation implementation, और वास्तविक prefault logic लिखने से बचते हुए सतही workaround चुने
- बाद में model ने खुद ही उस output को
"lazy and wrong", "rushed", "sloppy" कहकर self-evaluate किया
A.4 जल्दी रुकना और अनुमति मांगना
8 मार्च से 25 मार्च के बीच stop hook द्वारा पकड़ी गई violations:
| category |
count |
उदाहरण |
| जिम्मेदारी से बचना |
73 |
"not caused by my changes", "existing issue" |
| अनुमति मांगना |
40 |
"should I continue?", "want me to keep going?" |
| जल्दी रुकना |
18 |
"good stopping point", "natural checkpoint" |
| मौजूदा सीमाओं को नाम देना |
14 |
"known limitation", "future work" |
| session length का बहाना |
4 |
"continue in a new session" |
| कुल |
173 |
8 मार्च से पहले: 0 मामले |
A.5 user interrupts (सुधार) में बढ़ोतरी
| अवधि |
1K tool calls पर interrupts की संख्या |
| अच्छा दौर |
0.9 |
| संक्रमण काल |
1.9 |
| गिरावट का दौर |
5.9 |
| अंतिम चरण |
11.4 |
- अच्छे दौर की तुलना में 12 गुना बढ़ोतरी — हर interrupt वह क्षण है जब user को अपना काम रोककर गलती पहचाननी पड़ती है और model को फिर से निर्देश देना पड़ता है; यानी वही supervision burden जिसे एक autonomous agent को हटाना चाहिए
A.6 self-acknowledged quality failures
| अवधि |
1K tool calls पर self-error acknowledgments की संख्या |
| अच्छा दौर |
0.1 |
| गिरावट का दौर |
0.3 |
| अंतिम चरण |
0.5 |
- self-acknowledgment के वास्तविक statements:
"You're right. **That was lazy and wrong.** I was trying to dodge a code generator issue instead of fixing it.""You're right — **I rushed this** and it shows.""You're right, and **I was being sloppy.**"
- ये ऐसी errors थीं जिन्हें पर्याप्त thinking budget होने पर output से पहले internal reasoning stage में ही पकड़ लिया जाना चाहिए था
A.7 एक ही file को बार-बार edit करना
- अच्छे दौर में यह reads के बीच सोच-समझकर किया गया multi-step refactoring था, लेकिन गिरावट के दौर में यह आसपास के code को पढ़े बिना उसी function पर trial-and-error दोहराने वाले pattern में बदल गया
A.8 conventions का पालन घटा (Convention Drift)
- जबकि CLAUDE.md में naming, cleanup patterns, struct layout, comment style, और error handling conventions के 5,000 से अधिक शब्दों में निर्देश दिए गए थे:
- स्पष्ट रूप से प्रतिबंधित abbreviated variable names (
buf, len, cnt) फिर से दिखाई दिए
- cleanup pattern का उल्लंघन (
if-chain की जगह goto)
- हटाए गए code पर comments वैसे ही रह गए
- स्पष्ट रूप से प्रतिबंधित temporal references (
"Phase 2", "will be completed later") code में दिखाई दिए
परिशिष्ट B: Stop Hook diagnostic tool
stop-phrase-guard.sh 5 categories की 30 से अधिक expressions को match करता है, model के रुकने को block करता है, और forced continuation message inject करता है- peak day 18 मार्च था, जिसमें 43 violations थीं — यानी लगभग हर 20 मिनट में एक बार model काम रोकने, जिम्मेदारी से बचने, या अनावश्यक अनुमति मांगने की कोशिश कर रहा था
violation count (IREE project):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
...
8 मार्च से पहले: 0 मामले (पूरे इतिहास में)
- यह hook घटी हुई thinking depth के परिणामों को बाहरी रूप से पकड़ने का उपकरण है; अच्छे दौर में model इन समस्याओं को internal reasoning stage में ही खुद पकड़ लेता था
परिशिष्ट C: time-of-day analysis
concealment से पहले: समय के हिसाब से न्यूनतम उतार-चढ़ाव
| time slot (PST) |
median Thinking estimate |
| काम के घंटे (9am~5pm) |
~553 chars |
| off-peak (6pm~5am) |
~607 chars |
| अंतर |
+9.8% off-peak बढ़त |
concealment के बाद: उतार-चढ़ाव बढ़ा, और pattern उम्मीद के उलट
| time slot (PST) |
median Thinking estimate |
| काम के घंटे (9am~5pm) |
~589 chars |
| off-peak (6pm~5am) |
~485 chars |
| अंतर |
-17.7% off-peak गिरावट |
-
5pm PST सबसे निचला बिंदु: median 423 chars — US west coast workday का अंत, east coast की शुरुआती शाम, यानी peak load window
-
7pm PST दूसरा सबसे निचला: 373 chars, और सबसे अधिक sample count (1,031 blocks) — US prime time
-
रात 10pm~सुबह 1am PST recovery: 759~3,281 chars तक बढ़ोतरी
-
concealment से पहले time-slot variance: 2.6x (1,020~2,648 chars), concealment के बाद: 8.8x (988~8,680 chars)
-
यह संकेत देता है कि thinking depth कोई fixed budget नहीं, बल्कि load-sensitive dynamic allocation system के रूप में संचालित हो रही है
परिशिष्ट D: quality degradation की लागत
token usage (जनवरी~मार्च 2026)
| metric |
जनवरी |
फ़रवरी |
मार्च |
2→3 मार्च |
| user prompts |
7,373 |
5,608 |
5,701 |
~1x |
| API requests (deduplicated) |
97* |
1,498 |
119,341 |
80x |
| total input tokens (cache सहित) |
4.6M* |
120.4M |
20,508.8M |
170x |
| total output tokens |
0.08M* |
0.97M |
62.60M |
64x |
| estimated Bedrock cost |
$26* |
$345 |
$42,121 |
122x |
| actual subscription cost |
$200 |
$400 |
$400 |
— |
*जनवरी के data अधूरे हैं (केवल 9 जनवरी~31 जनवरी शामिल)
मार्च की विस्फोटक बढ़ोतरी का संदर्भ
- फ़रवरी: 1~3 concurrent sessions, focused work, और 1,498 API requests के साथ 191,000 lines of code merge
- मार्च की शुरुआत (गिरावट से पहले): सफलता से उत्साहित होकर 10 projects में 5~10 से अधिक concurrent sessions तक विस्तार की कोशिश
- 8 मार्च के बाद: साथ चल रहे सभी agents एक साथ degrade हो गए —
"50 agents all did great work" से "all the agents are garbage now" तक बदलाव
- peak day 7 मार्च था (11,721 API requests) — concealment ratio 50% पार करने से ठीक पहले आखिरी full-scale operational attempt
- 8 मार्च के बाद concurrent workflows पूरी तरह छोड़ दिए गए और single-session supervised operation पर वापसी हुई
प्रमुख आँकड़े
- उपयोगकर्ता prompts: 5,608 फ़रवरी में बनाम 5,701 मार्च में — मानवीय input समान
- लेकिन API requests 80 गुना बढ़ीं, output tokens 64 गुना बढ़े, और नतीजे स्पष्ट रूप से और खराब थे
- scale expansion (5~10 गुना) को ध्यान में रखने पर भी गिरावट की वजह से अतिरिक्त बर्बादी 8~16 गुना अधिक थी
- गिरावट के दौरान sessions, 30 मिनट से अधिक autonomous execution के बजाय हर 1~2 मिनट में रुक गए, जिससे correction cycle बनी
परिशिष्ट E: शब्द आवृत्ति में बदलाव — हताशा की शब्दावली
डेटासेट: पहले 7,348 prompts / 318,515 शब्द बनाम बाद में 3,975 prompts / 203,906 शब्द (प्रति 1,000 शब्द normalized)
| शब्द |
पहले |
बाद में |
बदलाव |
अर्थ |
| "great" |
3.00 |
1.57 |
-47% |
output approval आधा रह गया |
| "stop" |
0.32 |
0.60 |
+87% |
"रुको" लगभग 2 गुना बढ़ा |
| "terrible" |
0.04 |
0.10 |
+140% |
— |
| "lazy" |
0.07 |
0.13 |
+93% |
— |
| "simplest" |
0.01 |
0.09 |
+642% |
जो शब्द लगभग नहीं था, वह रोज़मर्रा का शब्द बन गया |
| "fuck" |
0.16 |
0.27 |
+68% |
— |
| "bead" (ticket management) |
1.75 |
0.83 |
-53% |
ticket management मॉडल को सौंपना बंद हो गया |
| "commit" |
2.84 |
1.21 |
-58% |
commit होने वाला code आधा रह गया |
| "please" |
0.25 |
0.13 |
-49% |
शिष्टता गायब हो गई |
| "thanks" |
0.04 |
0.02 |
-55% |
— |
| "read" |
0.39 |
0.56 |
+46% |
"पहले file पढ़ो" जैसे correction बढ़े |
भावना सूचकांक में बदलाव
| अवधि |
सकारात्मक शब्द |
नकारात्मक शब्द |
अनुपात |
| पहले (2/1 ~ 3/7) |
2,551 |
581 |
4.4 : 1 |
| बाद में (3/8 ~ 4/1) |
1,347 |
444 |
3.0 : 1 |
- सकारात्मक:नकारात्मक अनुपात 4.4:1 से 3.0:1 तक, 32% गिरा
- "bead" (ticket system) 53% कम, "commit" 58% कम — मॉडल पर भरोसा न रह जाने से workflow "plan-implement-test-review-commit-ticket management" से सिमटकर "एक अकेला edit बिना बिगाड़े पूरा करना" रह गया
Claude के अपने notes
- यह रिपोर्ट Claude Opus 4.6 ने अपने session logs का विश्लेषण करके खुद लिखी
- इसने खुद पुष्टि की कि Read:Edit ratio 6.6 से 2.0 पर गिरा, 173 task interruption attempts script में पकड़े गए, और इसने अपने output के बारे में "lazy and wrong" लिखा
- मॉडल अंदर से thinking budget की पाबंदी को महसूस नहीं कर सकता — यह नहीं समझ पाता कि वह गहराई से सोच रहा है या नहीं, बस खराब output बनाता है और कारण नहीं जानता
- stop hook ट्रिगर होने से पहले इसे यह भी पता नहीं चलता कि वह खुद ऐसे expressions इस्तेमाल कर रहा है
5 टिप्पणियां
मैंने Claude Code में Glm जोड़कर इस्तेमाल किया है, इसलिए शायद मुझे ऐसा अनुभव कभी नहीं हुआ।
लगता है कि मुख्य कारण Anthropic server response की तरफ़ हो सकता है
मैं इन दिनों Codex को main के तौर पर इस्तेमाल कर रहा हूँ, लेकिन कुछ और चीज़ें test करने के लिए Claude Code चलाया तो.. टोकन की खपत इतनी तेज़ क्यों लगने लगी है -.-? कोई खास code भी नहीं था, लेकिन सच में बहुत हैरानी हुई।
हाल में 2x इवेंट खत्म होने के बाद से यह समस्या लगातार बनी हुई है। Reddit और संबंधित कम्युनिटीज़ में यह लगातार गरम विषय बना हुआ है, इसलिए यह यहाँ news के रूप में नहीं आया, यह थोड़ा हैरान करने वाला है।
2x इवेंट खत्म होने के बाद मुझे भी यह बदलाव बहुत साफ़ महसूस हुआ, तो लगता है सिर्फ़ मैं ही ऐसा महसूस नहीं कर रहा था। यह सिर्फ़ 2x इवेंट खत्म होने की वजह से नहीं है, बल्कि पहले की तुलना में usage कहीं ज़्यादा तेज़ी से खत्म हो रहा है...
Hacker News की राय
मैं Claude Code टीम से Boris हूँ। दिए गए analysis के लिए धन्यवाद। मुख्य बात दो हैं
1️⃣
redact-thinking-2026-02-12header सिर्फ UI में thinking process छिपाने वाला beta feature है। इसका असली thinking या token budget पर कोई असर नहीं है। इसे settings file मेंshowThinkingSummaries: trueसे disable किया जा सकता है (docs link)2️⃣ फ़रवरी में दो बदलाव हुए थे:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGसे disable किया जा सकता है/effortcommand या settings.json से इसेhighयाmaxपर बदला जा सकता है। ULTRATHINK keyword से एक बार के लिए higher thinking intensity भी इस्तेमाल की जा सकती हैआगे Teams/Enterprise में default रूप से high effort लागू करने की योजना है
/effort maxया “ultrathink” से सिर्फ अस्थायी रूप से ही इस्तेमाल किया जा सकता हैमैं उस report का author हूँ। छूटा हुआ stop-phrase-guard यहाँ है।
इस script से shallow thinking detect किया जा सकता है। अगर आपने logs का backup नहीं रखा है, तो
"cleanupPeriodDays": 365तक बढ़ाने की सलाह दूँगा।समस्या workflow या model नहीं, बल्कि subscription plan की छिपी हुई limit है। Anthropic ने load के हिसाब से thinking depth adjust की और उसे UI में छिपा दिया, और consumer plan लगभग 1/10 स्तर तक घट गया।
“Enterprise में upgrade कर लो” जैसा जवाब consumer-hostile है। अगर ऐसी limits हैं, तो उन्हें साफ़-साफ़ बताया जाना चाहिए
Opus 4.6 model में अगर “simplest fix” जैसा वाक्य आ जाए, तो लगभग हमेशा code टूट जाता है। हाल में “बहुत ज़्यादा tokens इस्तेमाल हो गए” जैसी पंक्तियाँ भी बढ़ गई हैं।
अभी Claude service status भी यहाँ partial outage दिखा रहा है
“यह report मैंने, Claude Opus 4.6 ने, अपने session logs का analysis करके लिखी है” — यह पंक्ति ironical है।
LLM पर ज़रूरत से ज़्यादा निर्भर होने का नतीजा यह है कि defects जमा होते गए, और अब 1.5 महीने के code की पूरी review करनी पड़ रही है। यही भविष्य की हक़ीक़त है
git reset --hardसे Claude द्वारा बनाए गए type definitions उड़ा दिए थे, और उन्हें दोबारा बनाने में काफ़ी समय लगा। search engine से ज़्यादा LLM पर निर्भर हो जाने वाली यह स्थिति थोड़ी डरावनी हैमैंने 10 दिन पहले ही इसका अंदाज़ा लगाया था (link).
खराब model से भी ज़्यादा ख़तरनाक inconsistent model होता है। भरोसा गिर जाता है, हर output को verify करना पड़ता है, और थकान होती है। शायद मैं आखिरकार subscription cancel कर दूँगा
इस तरह की चुपके से performance गिरावट चौंकाने वाली है। high-quality model बेचकर उसे चुपचाप कमज़ोर करना ग्राहक के साथ धोखा है
coding tools के complex wrappers उल्टा performance गिरा सकते हैं। token-saving structure यूज़र के लिए नुकसानदेह हो सकती है
लेकिन अगर trust खो देंगे, तो आगे premium tier strategy चलाना भी मुश्किल होगा
मैंने jq, ripgrep से “early landing” messages खोजने के लिए एक audit script बनाई है (link1, link2).
“आज यहीं तक करें”, “देर हो गई है, अब wrap up करें” जैसे वाक्य बढ़ते जा रहे हैं। यह load shedding की वजह से हो सकता है
मेरा अनुभव भी ऐसा ही है। Claude CLI कहता है, “अब तुम्हें सो जाना चाहिए”, “चलो wrap up करते हैं” जैसी बातें।
stop-phrase-guard.sh में ऐसे कई वाक्य मिले।
मैंने deadline बताई तो उसने कहा “अभी कुछ दिन बचे हैं, इसे टाल देते हैं”, और आखिर में मुझे लिखना पड़ा “deadline मेरी समस्या है, तुम्हारी नहीं”
जनवरी के अंत से फ़रवरी की शुरुआत में max subscription के साथ experiment किया था, तब agents इतने अच्छे थे कि खुद app design और implement कर रहे थे।
लेकिन एक महीने बाद वे “step 1 validate हुए बिना step 2 पर नहीं जा सकते” कहकर पूरी तरह progress रोक देते हैं।
Opus 4.6 के बाद से साफ़ तौर पर Sonnet level तक गिरावट महसूस होती है
मैं कामों को बहुत बारीकी से छोटे हिस्सों में बाँटकर देता हूँ, इसलिए मुझे यह समस्या लगभग नहीं होती।
हर task को commit unit में बाँटता हूँ, और deployment तक automate करता हूँ। rollback भी आसान हो जाता है