मैंने Claude क्यों छोड़ा: टोकन समस्याएँ, गिरती गुणवत्ता और कमजोर सपोर्ट
(nickyreinert.de)- शुरुआती कुछ हफ्तों तक तेज़ गति, उचित लगने वाली token allowance, और अच्छे परिणामों की गुणवत्ता के कारण संतुष्टि काफ़ी अधिक थी, लेकिन लगभग 3 हफ्ते पहले से अनुभव में बड़ा बदलाव महसूस होने लगा
- 10 घंटे का ब्रेक लेकर लौटने के बाद Claude Haiku से सिर्फ़ दो छोटे सवाल पूछे, लेकिन उपयोग अचानक 100% तक पहुँच गया, और सपोर्ट चैनल असल मुद्दे को छुए बिना automated जवाब देकर लगभग बंद हो गया
- हाल के दिनों में, जहाँ पहले एक साथ कई प्रोजेक्ट चलाए जा सकते थे, अब एक ही प्रोजेक्ट में 2 घंटे के भीतर token limit खत्म हो जाती है; refactoring के दौरान सस्ते workaround को ठीक करने में ही 5 घंटे की विंडो का लगभग आधा हिस्सा खर्च हो गया
- कुछ समय बाद conversation cache गायब हो जाती थी, जिससे codebase को फिर से पढ़ने की लागत बार-बार देनी पड़ती थी; ऊपर से weekly reference point बदलना और बिना किसी explanation के monthly limit warning दिखना, limit system को असंगत बनाता है
- उत्पादकता में बढ़ोतरी और प्रोडक्ट की क्षमता को बहुत मानने के बावजूद, कमज़ोर सपोर्ट, गिरती गुणवत्ता, और usage limit को लेकर भ्रम जमा होता गया और अंततः Anthropic अकाउंट रद्द कर दिया गया
शुरुआती संतोष और बाद का बदलाव
- Claude Code subscription के शुरुआती कुछ हफ्तों में गति तेज़ थी, token allowance उचित लगती थी, और परिणामों की गुणवत्ता भी अच्छी थी
- non-peak समय में token allowance बढ़ाने की सूचना भी देखी जा सकती थी
- कुछ सरकारी नियमों के विरोध वाले रुख के कारण प्रोडक्ट के प्रति समर्थन की भावना भी बनी
- लेकिन लगभग 3 हफ्ते पहले से शुरुआती संतोष तेज़ी से गायब होने लगा
- इसके बाद के सेक्शनों में सपोर्ट response, quality, और usage limits की समस्याएँ लगातार सामने आती हैं
सपोर्ट की गुणवत्ता की समस्या
- लगभग 10 घंटे आराम करके यह मानकर सुबह काम शुरू किया कि token फिर भर गए होंगे, लेकिन Claude Haiku से repository से असंबंधित दो छोटे सवाल पूछते ही token usage 100% तक पहुँच गया
- सवाल सरल थे और उनका scope भी छोटा था
- अपेक्षित token refresh और वास्तविक usage spike मेल नहीं खाते थे
- AI support bot से संपर्क किया, लेकिन उसने सिर्फ़ बुनियादी दिशा-निर्देश लौटाए और असली समस्या को ठीक से समझ भी नहीं पाया
- इसके बाद human support माँगा गया
- कुछ दिन बाद आया जवाब भी वास्तविक समस्या से कटा हुआ, एक template जैसा लगा
- मिले हुए जवाब की शुरुआत इस पंक्ति से हुई कि “system ने इसे Pro या Max plan usage limits के बारे में query के रूप में detect किया,” जबकि वास्तव में Pro plan पहले से इस्तेमाल हो रहा था और सवाल का मूल बिंदु भी यह नहीं था
- इसके बाद लंबे दस्तावेज़-जैसे हिस्से में daily और weekly limits की व्याख्या जुड़ी हुई थी
- पूछी गई समस्या को हल करने या सीधे address करने जैसा कोई प्रवाह नहीं दिखा
- ईमेल के अंत में यह भी लिखा था कि आगे के replies शायद monitor न किए जाएँ, इसलिए help page पर जाएँ; यानी inquiry channel लगभग बंद हो गया
- असल समस्या को प्रतिबिंबित न करने वाले automated जवाब के बाद सपोर्ट का रास्ता भी रुक गया
- सपोर्ट गुणवत्ता को लेकर निराशा यहीं से गंभीर होने लगी
गुणवत्ता में गिरावट
- अगले कुछ दिनों और हफ्तों में परिणामों की गुणवत्ता शुरुआती अनुभव की तुलना में संतोषजनक नहीं रही, और काम करने का उपलब्ध समय भी बहुत घट गया
- पहले अधिकतम 3 प्रोजेक्ट एक साथ चलाए जा सकते थे, लेकिन अब एक ही प्रोजेक्ट में 2 घंटे के भीतर token limit समाप्त हो जाती है
- उपलब्ध usage और महसूस की जाने वाली productivity, दोनों साथ-साथ बिगड़े
- यह भी माना गया कि quality का आकलन subjective हो सकता है और agent performance पर user का असर काफ़ी होता है
- साथ ही यह भी बताया गया कि GitHub Copilot, OpenAI Codex, OMLX, Continue, और Qwen3.5-9B भी साथ में इस्तेमाल किए जा रहे हैं, इसलिए तुलना का अनुभव मौजूद है
- पूर्ण विशेषज्ञता का दावा नहीं किया गया, लेकिन कई tools इस्तेमाल करने के बाद महसूस हुई गिरावट के रूप में इसे पढ़ा जा सकता है
- एक उदाहरण में Claude Opus को project refactoring सौंपा गया, जहाँ model के thought log में यह दिशा दिखी कि JSX में हर slider को सीधे edit करने के बजाय
ui-events.jsमें एक generic initializer जोड़कर value display को अपने-आप inject किया जाए- यह तरीका हर range input में value display न होने पर उसे auto-insert करने वाला workaround था
- ऐसे logs को कभी-कभार नहीं, बल्कि अक्सर देखना ज़रूरी महसूस होने लगा
- इस तरीके को अच्छी practice नहीं बल्कि सस्ता workaround माना गया; सीधे इंगित करने पर Opus ने भी इसे lazy approach माना और JSX में labels सीधे जोड़कर explicit linking की दिशा में बदला
- शुरुआती गलत दिशा को ठीक करने में ही 5 घंटे की token allowance का लगभग 50% खर्च हो गया
- यानी गुणवत्ता में गिरावट केवल impression नहीं रही, बल्कि वास्तविक लागत की बर्बादी में बदली
cache और limit display को लेकर भ्रम
- conversation cache की समस्या भी नई तरह से उभरी, और इसके संदर्भ में Anthropic का postmortem तथा Hacker News चर्चा भी लिंक किए गए हैं
- इस मुद्दे को सार्वजनिक रूप से handle करना अपने-आप में सकारात्मक माना गया
- लेकिन user experience पर पड़ने वाला बोझ जस का तस रहा
- कुछ समय बाद काम पर लौटने पर conversation cache गायब हो जाती थी, इसलिए model codebase को फिर से शुरू से पढ़ना शुरू कर देता था
- लागत के नज़रिए से यह व्यावसायिक रूप से समझदारी भरा हो सकता है, लेकिन user के लिए इसका मतलब है कि शुरुआती loading पर token एक बार खर्च करने के बाद forced break के बाद वही loading cost फिर चुकानी पड़े
- खासकर 5 घंटे की token window limit के कारण ब्रेक लेने के बाद लौटने पर यही लागत दोबारा देनी पड़ती थी
- एक बार weekly window अचानक आज-आधारित गणना से बदलकर सोमवार-आधारित हो गई, और इस बदलाव के साथ usage 0 पर reset भी हो गया
- reset अपने-आप में स्वागतयोग्य था
- लेकिन यह बदलाव क्यों हुआ, यह समझ में नहीं आया
- इससे यह प्रभाव बना कि limit system लगातार एक जैसा नहीं है
- project पर काम करते हुए token usage लगातार देखते समय, जबकि user organization account पर भी नहीं था, अचानक monthly usage limit की चिंता करने वाली warning दिखाई दी
- उस समय hourly और weekly limits भी पार नहीं हुई थीं
- warning किस आधार पर दिखाई गई, इसका स्क्रीन पर कोई explanation नहीं था
- लगभग 2 घंटे बाद वह warning गायब हो गई और फिर काम जारी रखा जा सका
- documentation में भी monthly usage limit का उल्लेख नहीं है
- settings page पर भी केवल current session और weekly limits दिखने की बात लिखी है, इसलिए monthly limit की प्रकृति अंत तक अस्पष्ट ही रही
productivity का असर और अंतिम cancellation
- प्रोडक्ट के प्रति लगाव अब भी बहुत है, और सैद्धांतिक रूप से सब कुछ बहुत अच्छा काम करता है तथा अवसर भी बहुत हैं
- Claude-आधारित अपना harness बनाया गया, और background में GitHub issues संभालने वाले Claude Caude को भी बहुत सराहा गया
- Claude Cowork के साथ Nerd Enzyklopädie का लेखन जारी है
- productivity में बढ़त single-digit multiplier नहीं, बल्कि एक पूरे स्तर की रही; दिमाग में आए विचारों को कुछ साल पहले की तुलना में कहीं तेज़ और आसान तरीके से लागू किया जा सकता है
- प्रोडक्ट की क्षमता और वास्तविक उपयोगिता स्पष्ट रूप से सामने आती है
- feature set को भी काफ़ी विचारपूर्वक तैयार किया गया माना गया
- साथ ही, ऐसे प्रोडक्ट को चलाने की तकनीकी और organizational कठिनाइयों को भी समझा गया है; inference बेचना incremental cost वाला ढांचा है, इसलिए हर अतिरिक्त समय और हर नए ग्राहक के साथ लगभग उसी स्तर के compute resources चाहिए होते हैं
- यानी economies of scale का लाभ लेना आसान नहीं है
- service operations की कठिनाई से इनकार नहीं किया गया
- अंततः यह निष्कर्ष निकाला गया कि Anthropic शायद एक साथ बहुत अधिक नए customers को संभाल नहीं पा रहा, और उस दबाव को कम करने के लिए अकाउंट cancel कर दिया गया
- प्रोडक्ट के प्रति लगाव और वास्तविक इस्तेमाल में महसूस हुई operational समस्याओं के बीच का अंतर इस cancellation decision तक पहुँचा
- कमजोर सपोर्ट, गुणवत्ता में गिरावट, और limits को लेकर भ्रम—इन सबका संचयी परिणाम
10 टिप्पणियां
"शुरुआती कुछ हफ्तों तक तेज़ स्पीड और उचित लगने वाली token allowance"??
उचित कौन तय करता है?
जब महीने के 220 डॉलर वाले सर्विस से 99.5% availability भी हासिल नहीं होती, तो लगता है कि क्या यूज़र ही बेवकूफ़ बन रहे हैं। Claude.ai तो 99% भी हासिल नहीं कर पाता।
आप इसकी जगह कौन-सी सेवा इस्तेमाल कर रहे हैं? Codex? कोई ढंग का विकल्प दिख नहीं रहा, इसलिए फिलहाल मैं इसे ही इस्तेमाल कर रहा हूँ...
यह भी सही है कि कोई विकल्प नहीं है, लेकिन 99% uptime भी बनाए नहीं रख पाने वाली सेवा मैंने ज़िंदगी में पहली बार इस्तेमाल की है..
लगता है GitHub को 99 तो छोड़िए, 95 के लिए भी जूझना पड़ेगा
Claude ai में project data sync की समस्या की वजह से उसे छोड़कर जाना आसान नहीं है, और फिलहाल Claude Code, Codex, और Gemini CLI को साथ-साथ इस्तेमाल करने का सोच रहा हूँ।
अगर कोई विकल्प है, तो मैं भी जानना चाहूंगा।
मासिक उपयोग सीमा
वार्षिक उपयोग सीमा
हाहा...
Claude और ChatGPT अगर प्रतिस्पर्धा करें तो उपभोक्ताओं के लिए अच्छा है, haha. Gemini भी जल्दी मैदान में आए, और चीनी models की प्रगति भी जबरदस्त है, तो उम्मीद है सब जमकर भिड़ें।
Hacker News राय
विस्तृत spec docs को Markdown और example code के साथ कई files में लिखकर Claude Sonnet को देने पर भी, वह कभी requirements छोड़ देता था, duplicate code बनाता था, या बेवजह data processing जोड़ देता था
कई बार ऐसा लगता था कि tests बस pass करवाने के लिए चीज़ों को जबरन सजाया गया है, और आखिर में code लिखने के बजाय मुझे बहुत बड़ी मात्रा में code पढ़ना पड़ता था
वैसे भी असल में काम करते समय coding से ज़्यादा मुश्किल code पढ़ना और mental model बनाना होता है, और Gen AI के साथ यह बोझ और बढ़ जाता है
इसलिए Anthropic की मौजूदा pricing पर मुझे यह सीधा घाटे का सौदा लगता है
मैं vibe coding नहीं, बल्कि ऐसा software बना रहा हूँ जिस पर असली users निर्भर हैं, इसलिए subscription जल्द ही cancel करने का सोच रहा हूँ
जैसे सामान्य test·linter cycle में जोड़कर उससे review कराना, third-party libraries को जल्दी evaluate करना, नए topics पर research करना, RFC या design docs का draft बनाना, या मुश्किल problem पर सोचते समय बातचीत के साथी की तरह इस्तेमाल करना
AI कंपनियों की दिशा कुल मिलाकर मुझे पसंद नहीं, और copyright violation के ऊपर खड़े होने वाली असहजता भी बनी हुई है, लेकिन latest models कुछ मामलों में हैरान कर देने जितने smart हैं
बढ़ा-चढ़ाकर बेचे जा रहे vibecoding hype को मानने की ज़रूरत नहीं; सिर्फ productivity tool के रूप में भी यह काफ़ी valuable है
चाहे बिल्कुल न इस्तेमाल करें, या किसी खास कंपनी को पैसे न दें, फिर भी सिर्फ vibecoding देखकर पूरी technology को खारिज करने की ज़रूरत नहीं है
पूरे system spec को मत सौंपिए; design खुद कीजिए, ज़रूरत हो तो design assistance लीजिए, लेकिन implementation एक बार में एक-एक task में कराइए, इससे accuracy बेहतर रहती है
हर step पर review करें, सुधार करवाएँ, फिर आगे बढ़ें; तब भी यह सब कुछ खुद लिखने से तेज़ रहता है और नियंत्रण भी कहीं ज़्यादा रहता है
यह दरअसल एक अतिरिक्त documentation step वाले vibecoding के अधिक करीब है, और अगर goal organizing work कम करना है तो Sonnet के बजाय उस समय का best model चुनना बेहतर है
फिर भी कोई भी model सब कुछ पूरी तरह नहीं करेगा, इसलिए all-or-nothing तरीके से उपयोग न करें
judgment अपने पास रखते हुए सिर्फ उन हिस्सों में AI लगाना यथार्थवादी है जहाँ उससे speed बढ़ती हो
non-junior engineers आम तौर पर इसी दिशा में settle होते दिखते हैं, और LinkedIn या SNS पर app auto-generation वाली अतिशयोक्तियों को अनदेखा करना बेहतर है
मैं लगभग इसी तरीके से काम करके ज़्यादा तेज़ और बेहतर quality वाला code बना रहा हूँ, और कलाई पर दबाव भी बहुत कम हुआ है
फर्क शायद इस बात का है कि AI को सिर्फ वहीं तक काम दिया जाए जहाँ तक वह कर सकता है, और scope को छोटा व incremental रखा जाए
छोटे और स्पष्ट changes review करना आसान है, लेकिन अगर हर दिन 10,000-line code dump मिले तो उसका मूल्यांकन करना मुश्किल हो जाता है
हो सकता है आप बहुत ज़्यादा, बहुत तेज़, और बहुत जल्दी push कर रहे हों
balance बना रहे तो value दिखेगी; भले आपकी उम्मीद जितना विस्फोटक speedup न हो, फिर भी अकेले करने से तेज़ होने की अच्छी संभावना है
validation और confirmation बार-बार चाहिए होते हैं, और plan भी कई बार बदलना पड़ता है, लेकिन implementation में भी मैं Opus ही इस्तेमाल करता हूँ
मौजूदा model cache पकड़ रहा है, इसलिए Sonnet से implementation न करने की warning भी कभी-कभी दिखती है
पढ़ने-समझने में समय लगता है और manual fixes भी अक्सर करने पड़ते हैं, लेकिन ज़्यादातर काम Pro subscription के भीतर हो जाता है
मैं Claude Opus को काफ़ी प्रभावी तरीके से इस्तेमाल कर रहा हूँ, और mid-tier subscription पर limit से अक्सर नहीं टकराता
मेरा workflow autopilot नहीं बल्कि copilot के ज़्यादा करीब है, इसलिए मैं सिर्फ सीमित scope वाले tasks prompt में देता हूँ और लगभग सब कुछ review करता हूँ
ऐसे use case में लगता है कि leading models अब लगभग काफ़ी अच्छे स्तर तक पहुँच चुके हैं
अच्छा होगा अगर properly licensed codebase पर प्रशिक्षित open source models आएँ और LLM-assisted coding commoditized हो जाए
वे चाहते हैं कि हम ज़्यादा tokens खर्च करें ताकि ज़्यादा charge कर सकें, लेकिन साथ ही लोग उम्मीद से अधिक इस्तेमाल कर रहे हैं और मौजूदा pricing model का टिकना मुश्किल लग रहा है
अगर आखिरकार समाधान higher-priced tier में upgrade करना है, तो ये दोनों बातें पूरी तरह टकराती भी नहीं हैं
महीने के 100 डॉलर में हो जाता है, और विकसित देशों में बिजली का बिल इससे कम होने वाले घर भी कम नहीं हैं
मेरे लिए LLM-assisted coding वही है जहाँ हर बदलाव और हर line को पूरी तरह समझा जाए; वरना वह vibe coding है
अगर इस सिद्धांत को सच में गंभीरता से निभाएँ, तो $100 tier का quota पूरा खत्म करना मुश्किल होना चाहिए
कई models में मुझे यही सबसे अच्छा लगता है, और इसे असली काम करवाने से ज़्यादा कभी-कभी search engine के विकल्प की तरह इस्तेमाल करता हूँ
मुझे कभी नहीं लगा कि LLM सचमुच काम अपने दम पर प्रभावी ढंग से कर देता है; पुराने समय की उपयोगी technical documentation याद आती है
अंत में Claude मुझे developer experience की खाइयों को भरने वाली बैसाखी जैसा लगता है
usage पूरा भरना बेहद मुश्किल है, और असली काम बहुत देने पर भी हफ़्ते का औसत लगभग 30% ही रहता है
लेकिन Pro के समय मैं हास्यास्पद रूप से बार-बार limit पर अटक जाता था, और एक request ही session का 100% पार कराके extra billing तक ले जाती थी
Max 5x मुझे अनुभव में 5 गुना से कहीं ज़्यादा लगता है, लेकिन Anthropic surge rate जैसी चीज़ों को इतना अस्पष्ट रखता है कि पक्का नहीं कह सकता
आजकल HN पर भरे पड़े Opus खत्म हो गया, Codex पर जाओ जैसे posts को मैं काफ़ी संदेह से देखता हूँ
कुछ तो सिर्फ frustration हो सकता है, लेकिन कुछ में astroturfing की गंध भी आती है
वास्तविक काम में बहुत इस्तेमाल करने के बावजूद मैं limit से कभी नहीं टकराया
घंटों तक LLM को चलने देना आखिरकार मेरे अपने समय की बर्बादी जैसा लगता है, क्योंकि फिर मुझे यह ट्रैक करना पड़ता है कि उसने क्या किया और क्यों किया
मेरी चिंता यह है कि लोग प्रोप्रायटरी और अपारदर्शी subscription-based GenAI पर निर्भर होते जा रहे हैं
वे इसे एक ठोस नींव की तरह मानकर उस पर चीज़ें बना रहे हैं, जबकि किसी दिन मालिक वह नींव अचानक खींच भी सकता है
हाल में rate limit थोड़ा परेशान कर रही थी इसलिए CC के बजाय Codex पसंद आया, लेकिन workflow लगभग बदलना नहीं पड़ा
वे इतना पैसा झोंकना चाहते हैं कि competitors पीछे रह जाएँ, एक ऐसी बढ़त बन जाए जिसे कोई छू न सके, और फिर वे अपनी मर्ज़ी से pricing तय कर सकें
फिर भी अभी competition काफ़ी तीव्र है, और coding tools में Anthropic सबसे अच्छा लग सकता है, लेकिन उसकी बढ़त पहले से छोटी हो चुकी है
सच कहूँ तो Opus 4.5 के आसपास ही usable level आ चुका था, और अब उस स्तर के कई models हैं
Gemini Pro 3.1 भी वैसा ही है, और मौजूदा Codex मुझे Opus 4.5 से बेहतर, 4.7 के करीब लगता है
मैं भी एक ही project में models और agents बार-बार बदलता हूँ, और switching cost लगभग शून्य है
claudeकी जगहgemini,copilot,hermesचला दूँ, बस; किसी एक model पर गहरी निर्भरता नहीं हैकंपनियाँ lock-in बनाने वाली features जोड़ने की कोशिश करेंगी, लेकिन top-tier models इतने capable हैं कि कई बार बस जो चाहिए वह कह देने से काम हो जाता है
अभी एकमात्र लगातार दिखने वाला moat शायद best model बनाने की क्षमता है, और वह भी इतना उथला है कि अगर Claude Code कल गायब हो जाए तो भी घातक नहीं होगा
self-hosted open models भी अब काफ़ी करीब आ चुके हैं
OpenAI और Anthropic की competition भी दिलचस्प है, और open source की दिशा भी जुड़ जाए तो लगता है जल्द ही हम वहाँ पहुँच जाएँगे
Claude ने Sonnet medium effort में एक session limit का 100% और extra billing तक खर्च कर दिया, 53 मिनट तक सोचता रहा,
और अंत में सिर्फ
API Error: Claude's response exceeded the 32000 output token maximum...दियाAPI Error: Claude's response exceeded the 32000 output token maximumआया—यह मज़ाक बिलकुल फिट बैठता हैपिछले कुछ महीनों में मैंने यह कई बार देखा है; पहले लगा था कि यह AWS Bedrock की समस्या है, लेकिन शायद सिर्फ वही कारण नहीं है
मैं और मेरे कई सहकर्मी पिछले दो महीनों में Claude में cognitive decline बहुत ज़्यादा महसूस कर रहे हैं
4.5 usable था, 4.6 वास्तव में शानदार था; मेरी निजी benchmark के हिसाब से 4.5 मुश्किल से 2-way pointer merge loop तक track कर पाता था, 4.6 3-way तक, और 1M context में k-way तक संभाल लेता था
इसी tracking क्षमता की वजह से यह वास्तविक production code को समझने और बदलने में उपयोगी था
लेकिन दो महीने पहले से 4.6 चीज़ें भूलने लगा और मूर्खतापूर्ण निर्णय लेने लगा; तुलना करने पर पता चला कि यह सिर्फ मेरे साथ नहीं था
4.7 भी बहुत बेहतर नहीं है, और पिछले कुछ हफ्तों से ऐसा लगता है जैसे auto level of effort downgrade से लगातार लड़ रहा हूँ
कुछ गड़बड़ लगे और settings देखें, तो पता चलता है कि quietly downgrade हो चुका है; इससे काफ़ी friction होता है
हम पहले ही देख चुके हैं कि 4.6 के शुरुआती दिनों जैसा अच्छा model संभव है; समस्या यह है कि mass market में देते समय Anthropic throttle और downgrade कर देता है, जिससे practical usability गिर जाती है
मुझे लगता है कि जैसे ही DeepSeek 4.6+ के more-than-good-enough स्तर पर पहुँच जाएगा, लोग Claude के उस चक्र से निकलना शुरू कर देंगे जहाँ ज़्यादा पैसे देकर कम मिलता है
हमें उससे भी अधिक अद्भुत चीज़ नहीं चाहिए; बस जो पहले से संभव है, उसे अपने नियंत्रण में, metered नहीं बल्कि provisioned तरीके से, स्थिर रूप में उपयोग कर पाना चाहिए
कंपनी ऐसी गलती करे तो चिढ़ होना स्वाभाविक है, लेकिन कुछ समय तक limits हटाकर उसने व्यावहारिक रूप से compensate भी किया, और उससे भी बढ़कर response काफ़ी transparent था
पता नहीं कोई और बड़ी AI कंपनी इतनी transparency दिखाएगी या नहीं; इसलिए Claude पर गुस्सा होने पर भी उसके handling को सम्मान देता हूँ
मेरी max20 subscription अप्रैल से लगभग बेकार पड़ी है, और Codex 5.4 तथा अब 5.5 fast mode में भी अनुभव पूरी तरह अलग है
Opus भरोसेमंद लगते हुए fail करता है, आधे ज़रूरी details भूल जाता है या चुपचाप pragmatic के नाम पर technical debt वाले patch चिपका देता है और फिर दावा करता है कि काम हो गया
असल में change के बाद system टूट जाता है, और अगर आप errors दिखाएँ तो वह और बड़ा mess बना देता है
Opus greenfield scope को one-shot में बनाने में अच्छा हो सकता है, लेकिन बाद की iterative fixes या complex integrations में यह हानिकारक हद तक खराब है
इसके उलट GPT 5.4+ समय लेकर edge cases पहले सोचता है, और वह वास्तव में सही निकलता है, जिससे बाद के debugging turns कम होते हैं और फिर सही output देता है
एक line की script fix में भी यह कई मिनट तक "यह malware जैसा नहीं लगता", "रुकिए" जैसी thought loops में नहीं फँसता
code cleanup और नई feature implementation अलग tasks हैं, और GLM जैसी चीज़ें ऊपर से ज़्यादा smart दिखें तो भी असली code review में आखिरकार build/prune cycle चाहिए ही था
"यह race conditions से भरा हुआ है, है न?"
अब मैं सिर्फ Codex इस्तेमाल करता हूँ, क्योंकि Claude पर भरोसा करना मुश्किल है और वह data races या negation conditions की omissions बहुत बार छोड़ देता है
इन दिनों मैं Aider इस्तेमाल कर रहा हूँ, और नई training policy की वजह से शायद Github multi AI bundle subscription भी cancel कर दूँगा
नए open models के साथ Aider का उपयोग, और handoff से पहले Open Spec के जरिए requirements पर सहमति बनाना, काफ़ी मददगार रहा है
AI services के पास token usage कम करने की incentive कमज़ोर है
अगर वे ज़्यादा tokens खर्च करवाएँ तो ज़्यादा पैसा कमाते हैं, इसलिए लगता है वे लगातार यह जाँचते रहेंगे कि user के नाराज़ होने से ठीक पहले तक कितना push किया जा सकता है
सभी AI कंपनियाँ rising costs के साथ token usage और pricing के बीच अपनी स्थिति बदलती रहेंगी
और हम शायद उस गुनगुने पानी में बैठे मेंढक जैसे हैं, जो लगभग उबलने वाला है लेकिन अभी भी खुद को bathwater बता रहा है
AI कंपनियों के पास भी वैसी ही incentive है
सस्ता होगा तो उपयोग बढ़ेगा, और जब तक price cost से ऊपर है, profit बढ़ सकता है
इसलिए अपनी cost कम करने की वजह भी उनके पास पूरी है
इसलिए सिर्फ token efficiency को लक्ष्य बनाकर मैंने (cline fork) open source https://github.com/dirac-run/dirac बनाया है
मेरा अनुमान है कि ये closed lock-in vendors समय के साथ users को पर्याप्त रूप से frustrate कर देंगे, और अभी contributors भी ढूँढ रहा हूँ
सुनने में conspiracy theory जैसा लगता है, लेकिन Anthropic जैसी कंपनियाँ तब भी लाभ में रहती हैं जब model काम पूरा नहीं कर पाता
हाल में मैंने over editing phenomenon पर भी पढ़ा; लगता है मशीन कभी खत्म करना ही नहीं चाहती
कुछ-कुछ dating app जैसा, जो अच्छा match नहीं चाहता
क्योंकि अगर सफलता मिल गई तो user subscription बंद कर देगा
कल मेरे लिए समझ आने का क्षण था
मैंने local LLM से जुड़े Claude Code को एक simple extraction task दिया, और वह 10 मिनट तक बस भनभनाता रहा
वही data और prompt सीधे
llama_cppchat UI में model को दिया, तो 1 मिनट से कम में single-shot में काम पूरा हो गयाइसलिए लगता है कि coding agent खुद, या LLM से बात करने के तरीके में कहीं न कहीं कुछ गलत है
अभी मैं बेहद simple open source coding agent ढूँढ रहा हूँ; Nanocoder Mac पर ठीक से install नहीं होता और node-modules बहुत भारी हैं, Opencode भी पूरी तरह open source नहीं लगता
फिलहाल मैं खुद coding agent की भूमिका निभाते हुए
llama_cppweb UI इस्तेमाल कर रहा हूँ, और यह काफ़ी ठीक चल रहा हैrepository पर तो MIT License लगा है
अगर आपको "बेहद simple" coding agent चाहिए, तो customized agent बनाना वास्तव में बेहतर बैठ सकता है
मैंने भी इस हफ्ते Anthropic के अजीब behavior से परेशान होकर ऐसा करके देखा, और कुछ ही दिनों में उपयोगी चीज़ खड़ी कर ली
मेरे मामले में BeOS या पुराने Mac पर Claude Code उपलब्ध नहीं था, इसलिए खुद bootstrap करके pieces जोड़ना और भी आसान लगा
इस process से model वास्तव में कैसे काम करता है, और Claude Code के अंदर कितने हास्यास्पद band-aid patches चलते हैं, यह भी बहुत सीखने को मिला
बेशक, इससे agent या harness को हल करनी पड़ने वाली मुश्किलों की समझ भी बनती है
और
llama_cppकी तुलना में Claude Code के slow होने की समस्या मुझे भी दिखी; मेरा अंदाज़ा है कि API traffic को subscription traffic से ज़्यादा priority मिलती हैAPI काफ़ी तेज़ लगती है, लेकिन उतनी ही महंगी भी पड़ती है
उसका architecture उम्मीद से कहीं ज़्यादा simple है
मैंने vLLM पर endpoint syntax बदलने वाला एक पतला shim लगाकर ऐसा वास्तव में किया है
कभी-कभी वही Claude model किसी समय logic error करता है और किसी समय नहीं
Claude की performance समय पर निर्भर लगती है, और इसे दिखाने वाला एक graph भी है
https://marginlab.ai/trackers/claude-code/
और भले इस पर खुलकर कम बात होती हो, लेकिन मुझे लगता है कि एक ही model में भी quantization के हिसाब से output में काफ़ी अंतर आता है
4-bit और 8-bit की compute requirements भी अलग होती हैं और output quality भी
https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization
मुझे पता है frontier models हमेशा बिल्कुल एक जैसे behave नहीं करते, लेकिन peak hours में memory या resource usage कम करने के लिए कहीं कोई fidelity dial घुमाकर performance adjust की जाती होगी—ऐसा सोचने का मन होता है
60% line अगर 95% confidence interval के भीतर ही है, तो क्या वह सिर्फ measurement noise नहीं हो सकता?