मैंने Claude क्यों छोड़ा: टोकन समस्याएँ, गिरती गुणवत्ता और कमजोर सपोर्ट

(nickyreinert.de)

9 पॉइंट द्वारा GN⁺ 5 일 전 | 10 टिप्पणियां | WhatsApp पर शेयर करें

शुरुआती कुछ हफ्तों में तेज़ गति, उचित लगने वाली token allowance और अच्छे आउटपुट की गुणवत्ता के कारण संतुष्टि काफ़ी ऊँची थी, लेकिन लगभग 3 हफ्ते पहले से अनुभव काफ़ी बदल गया
10 घंटे का ब्रेक लेकर लौटने के बाद Claude Haiku से सिर्फ़ दो छोटे सवाल पूछे, लेकिन उपयोग 100% तक पहुँच गया, और सपोर्ट चैनल मुख्य समस्या को छुए बिना automated जवाबों के बाद लगभग बंद हो गया
हाल के दिनों में, जहाँ पहले एक साथ कई प्रोजेक्ट चल रहे थे, अब एक single project में भी सिर्फ़ दो घंटे में token limit खत्म हो जाती थी, और refactoring के दौरान सस्ते workaround को ठीक करने में ही 5 घंटे की विंडो का लगभग आधा हिस्सा खर्च हो गया
कुछ समय बाद conversation cache गायब हो जाती थी, जिससे codebase को फिर से पढ़वाने की लागत बार-बार देनी पड़ती थी, और weekly reference point बदलने के साथ बिना किसी explanation के monthly limit warning भी दिखी, जिससे limit system लगातार असंगत लगा
productivity boost और product की क्षमता को बहुत माना गया, लेकिन खराब सपोर्ट, गिरती गुणवत्ता और usage limits की उलझनें जमा होती गईं, और अंततः Anthropic account रद्द करना पड़ा

शुरुआती संतुष्टि और बाद का बदलाव

Claude Code subscription के शुरुआती कुछ हफ्तों में गति तेज़ थी, token allowance उचित लगती थी, और output quality भी अच्छी थी
- ऑफ-पीक समय में token allowance बढ़ाने की सूचना भी देखी जा सकती थी
- कुछ सरकारी नियमों के विरोध वाले रुख़ के कारण product के प्रति समर्थन की भावना भी बनी
लेकिन लगभग 3 हफ्ते पहले से शुरुआती संतुष्टि तेज़ी से कम होने लगी
- आगे के सेक्शनों में सपोर्ट, गुणवत्ता और usage limits से जुड़ी समस्याएँ लगातार सामने आती हैं

सपोर्ट गुणवत्ता की समस्या

लगभग 10 घंटे आराम करके, यह मानकर कि tokens फिर से भर गए होंगे, सुबह काम शुरू किया, लेकिन Claude Haiku से repository से असंबंधित दो छोटे सवाल पूछते ही token usage 100% तक पहुँच गया
- सवाल सरल थे और बहुत छोटे दायरे के थे
- जो token refresh अपेक्षित था और जो actual usage बढ़ी, दोनों में मेल नहीं था
AI support bot से संपर्क किया, लेकिन उसने सिर्फ़ सामान्य मार्गदर्शन लौटाया और वास्तविक समस्या को ठीक से समझ ही नहीं पाया
- इसके बाद human support मांगी गई
- कुछ दिनों बाद जो जवाब आया, वह भी वास्तविक समस्या से कटा हुआ लगा
मिले जवाब की शुरुआत इस वाक्य से हुई कि “system ने इसे Pro या Max plan usage limits से जुड़ी inquiry के रूप में detect किया”, लेकिन वास्तव में Pro plan पहले से उपयोग में था और inquiry के मुख्य बिंदु को सही ढंग से पकड़ा ही नहीं गया था
- उसके बाद का मुख्य भाग daily और weekly limits समझाने वाले दस्तावेज़-जैसे लंबे विवरण से भरा था
- कहीं भी ऐसा प्रवाह नहीं दिखा जो पूछी गई समस्या को हल करे या सीधे संबोधित करे
ईमेल के अंत में यह लिखा था कि आगे के जवाब monitor नहीं किए जा सकते, इसलिए help page पर जाएँ, और इस तरह inquiry channel लगभग बंद हो गया
- यानी वास्तविक समस्या को प्रतिबिंबित न करने वाले automated जवाब के बाद सपोर्ट का रास्ता भी लगभग रुक गया
- सपोर्ट गुणवत्ता को लेकर निराशा यहीं से गंभीर रूप से बढ़ने लगी

गुणवत्ता में गिरावट

उसके बाद के दिनों और हफ्तों में output quality शुरुआती अनुभव की तुलना में संतोषजनक नहीं रही, और काम करने का उपलब्ध समय भी बहुत घट गया
- पहले अधिकतम तीन प्रोजेक्ट साथ में चलाए जा सकते थे, लेकिन अब एक single project में भी दो घंटे के भीतर token limit खत्म हो जाती थी
- उपलब्ध उपयोग और महसूस की गई productivity, दोनों साथ-साथ खराब हुए
यह भी कहा गया कि गुणवत्ता का आकलन व्यक्तिपरक हो सकता है और agent performance पर user का असर बहुत पड़ता है
- साथ ही यह भी बताया गया कि GitHub Copilot, OpenAI Codex, OMLX, Continue, Qwen3.5-9B भी साथ में उपयोग किए जा रहे हैं, जिससे comparative usage experience सामने आता है
- पूर्ण विशेषज्ञता का दावा नहीं किया गया, लेकिन कई टूल्स इस्तेमाल करने के बाद महसूस हुई गिरावट के रूप में इसे पढ़ा जा सकता है
Claude Opus को project refactoring सौंपे गए एक उदाहरण में, model के reasoning log में यह दिशा दिखी कि JSX में सभी sliders को सीधे बदलने के बजाय ui-events.js में एक generic initializer जोड़कर value display अपने-आप inject की जाए
- यह तरीका प्रत्येक range input में value display न होने पर उसे automatically insert करने वाले workaround के रूप में बना था
- ऐसे logs को कभी-कभार नहीं, बल्कि अक्सर देखना ज़रूरी लगने लगा
इस तरीके को अच्छी practice नहीं बल्कि सस्ता workaround माना गया, और सीधे इंगित करने पर Opus ने भी माना कि यह lazy approach थी; इसके बाद यह JSX में labels सीधे जोड़ने और उन्हें explicit रूप से connect करने की दिशा में बदला
- सिर्फ़ शुरुआती गलत दिशा को ठीक करने में ही 5 घंटे की token allowance का लगभग 50% खर्च हो गया
- यानी गुणवत्ता में गिरावट सिर्फ़ impression नहीं रही, बल्कि वास्तविक लागत की बर्बादी बन गई

cache और limit display की उलझन

conversation cache की समस्या भी नई तरह से उभरकर आई, और इसके संदर्भ में Anthropic का postmortem और Hacker News discussion भी लिंक किए गए हैं
- इस समस्या को सार्वजनिक रूप से उठाया जाना अपने-आप में सकारात्मक लगा
- लेकिन user experience पर पड़ने वाला बोझ जस का तस रहा
कुछ समय बाद जब वापस काम पर लौटा जाता, तो conversation cache गायब हो जाती और model codebase को फिर से शुरू से पढ़ना शुरू कर देता
- लागत के हिसाब से यह चतुर लग सकता है, लेकिन user के नज़रिए से इसका मतलब था कि शुरुआती loading पर tokens एक बार खर्च करने के बाद, forced break के बाद वही loading cost फिर देनी पड़ती
- खासकर 5 घंटे की token window limit के कारण ब्रेक लेकर लौटने पर वही लागत दोबारा चुकानी पड़ती थी
weekly window अचानक आज के आधार से बदलकर सोमवार के आधार पर हो गई, और इस बदलाव के साथ usage 0 पर reset भी हो गया
- reset अपने-आप में स्वागतयोग्य था
- लेकिन यह बदलाव क्यों हुआ, यह समझ नहीं आया
- इससे limit system के लगातार असंगत होने का आभास मिला
project पर काम करते हुए token usage लगातार देखी जा रही थी, तभी अचानक monthly usage limit की warning दिखी, जबकि user organization account पर भी नहीं था
- उस समय hourly और weekly limits भी पार नहीं हुई थीं
- warning का आधार भी स्क्रीन पर नहीं बताया गया था
लगभग दो घंटे बाद वह warning गायब हो गई और काम फिर जारी रखा जा सका
- दस्तावेज़ में भी monthly usage limit का उल्लेख नहीं है
- settings page पर भी सिर्फ़ current session और weekly limits दिखने की बात कही गई है, इसलिए monthly limit की प्रकृति अंत तक अस्पष्ट ही रही

productivity का असर और अंतिम cancellation

product के प्रति पसंद अब भी काफ़ी बनी हुई थी, और सैद्धांतिक रूप से सब कुछ बहुत अच्छा काम कर सकता है तथा इसमें अवसर भी बहुत हैं, ऐसा आकलन किया गया
- Claude-आधारित अपना harness बनाया गया था, और background में GitHub issues संभालने वाले Claude Caude की भी काफ़ी प्रशंसा की गई
- Claude Cowork के साथ Nerd Enzyklopädie का लेखन जारी है
productivity single-digit multiple नहीं, बल्कि एक पूरे स्तर तक बढ़ गई थी, और दिमाग़ के ideas को कुछ साल पहले की तुलना में कहीं तेज़ और आसान तरीके से लागू किया जा सकता था
- product की potential और वास्तविक utility दोनों स्पष्ट रूप से सामने आती हैं
- feature set को thoughtful भी कहा गया
साथ ही, ऐसे product को चलाने की technical और organizational कठिनाइयों को भी समझा गया, और inference बेचना incremental cost वाली संरचना है, जिसमें हर अतिरिक्त समय और हर नए customer के साथ लगभग उतने ही compute resources चाहिए होते हैं
- इससे यह भी दिखता है कि economies of scale का लाभ लेना आसान नहीं है
- service संचालन की कठिनाई को नकारा नहीं गया
अंत में यह निष्कर्ष निकाला गया कि Anthropic शायद एक साथ बहुत ज़्यादा नए customers संभाल नहीं पा रहा, और उन पर बोझ कम करने जैसा कहते हुए account cancel कर दिया गया
- product के प्रति लगाव और वास्तविक उपयोग के दौरान महसूस हुई operational समस्याओं के बीच का अंतर ही cancellation के निर्णय तक ले गया
- इसे खराब सपोर्ट, गुणवत्ता में गिरावट और limits को लेकर उलझन के जमा हुए परिणाम के रूप में समेटा गया

10 टिप्पणियां

iolothebard 5 일 전

"शुरुआती कुछ हफ्तों तक तेज़ स्पीड और उचित लगने वाली token allowance"??
उचित कौन तय करता है?

savvykang 5 일 전

जब महीने के 220 डॉलर वाले सर्विस से 99.5% availability भी हासिल नहीं होती, तो लगता है कि क्या यूज़र ही बेवकूफ़ बन रहे हैं। Claude.ai तो 99% भी हासिल नहीं कर पाता।

geralt 5 일 전

आप इसकी जगह कौन-सी सेवा इस्तेमाल कर रहे हैं? Codex? कोई ढंग का विकल्प दिख नहीं रहा, इसलिए फिलहाल मैं इसे ही इस्तेमाल कर रहा हूँ...

vndk2234 5 일 전

यह भी सही है कि कोई विकल्प नहीं है, लेकिन 99% uptime भी बनाए नहीं रख पाने वाली सेवा मैंने ज़िंदगी में पहली बार इस्तेमाल की है..

lamanus 4 일 전

लगता है GitHub को 99 तो छोड़िए, 95 के लिए भी जूझना पड़ेगा

savvykang 4 일 전

Claude ai में project data sync की समस्या की वजह से उसे छोड़कर जाना आसान नहीं है, और फिलहाल Claude Code, Codex, और Gemini CLI को साथ-साथ इस्तेमाल करने का सोच रहा हूँ।

savvykang 5 일 전

अगर कोई विकल्प है, तो मैं भी जानना चाहूंगा।

picopress 5 일 전

मासिक उपयोग सीमा
वार्षिक उपयोग सीमा
हाहा...

emptybynature 4 일 전

Claude और ChatGPT अगर प्रतिस्पर्धा करें तो उपभोक्ताओं के लिए अच्छा है, haha. Gemini भी जल्दी मैदान में आए, और चीनी models की प्रगति भी जबरदस्त है, तो उम्मीद है सब जमकर भिड़ें।

GN⁺ 5 일 전

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 करने का सोच रहा हूँ
- AI से code लिखवाने के बजाय, उसे code review assistant की तरह इस्तेमाल करना बेहतर है
  जैसे सामान्य 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 को खारिज करने की ज़रूरत नहीं है
- सब कुछ एक साथ देने के बजाय काम को टुकड़ों में बाँटकर micromanage करना बेहतर है
  पूरे system spec को मत सौंपिए; design खुद कीजिए, ज़रूरत हो तो design assistance लीजिए, लेकिन implementation एक बार में एक-एक task में कराइए, इससे accuracy बेहतर रहती है
  हर step पर review करें, सुधार करवाएँ, फिर आगे बढ़ें; तब भी यह सब कुछ खुद लिखने से तेज़ रहता है और नियंत्रण भी कहीं ज़्यादा रहता है
- विस्तृत spec लिखकर AI को पूरा काम सौंप देने का तरीका optimal नहीं है
  यह दरअसल एक अतिरिक्त 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 न हो, फिर भी अकेले करने से तेज़ होने की अच्छी संभावना है
- शायद मैं दूसरों से अलग इस्तेमाल करता हूँ, लेकिन अगर मैं सिर्फ क्या चाहिए और कैसे चाहिए लिख दूँ, तो Opus 4.7 plan बना देता है और मैं उसे बहुत ध्यान से review करता हूँ
  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 हो जाए
- मैं भी लगभग इसी copilot approach से इस्तेमाल करता हूँ और कुल मिलाकर संतुष्ट हूँ, लेकिन vendors हमें autopilot mode की ओर धकेलना चाहते हैं, ऐसा काफ़ी महसूस होता है
  वे चाहते हैं कि हम ज़्यादा tokens खर्च करें ताकि ज़्यादा charge कर सकें, लेकिन साथ ही लोग उम्मीद से अधिक इस्तेमाल कर रहे हैं और मौजूदा pricing model का टिकना मुश्किल लग रहा है
  अगर आखिरकार समाधान higher-priced tier में upgrade करना है, तो ये दोनों बातें पूरी तरह टकराती भी नहीं हैं
- LLM-assisted coding का commoditization क्या पहले से नहीं हो चुका?
  महीने के 100 डॉलर में हो जाता है, और विकसित देशों में बिजली का बिल इससे कम होने वाले घर भी कम नहीं हैं
  मेरे लिए LLM-assisted coding वही है जहाँ हर बदलाव और हर line को पूरी तरह समझा जाए; वरना वह vibe coding है
  अगर इस सिद्धांत को सच में गंभीरता से निभाएँ, तो $100 tier का quota पूरा खत्म करना मुश्किल होना चाहिए
- मैं भी copilot हूँ, autopilot नहीं
  कई models में मुझे यही सबसे अच्छा लगता है, और इसे असली काम करवाने से ज़्यादा कभी-कभी search engine के विकल्प की तरह इस्तेमाल करता हूँ
  मुझे कभी नहीं लगा कि LLM सचमुच काम अपने दम पर प्रभावी ढंग से कर देता है; पुराने समय की उपयोगी technical documentation याद आती है
  अंत में Claude मुझे developer experience की खाइयों को भरने वाली बैसाखी जैसा लगता है
- मैं Max 5x पर सिर्फ Claude Opus को xhigh mode में इस्तेमाल करता हूँ, agent या MCP कुछ नहीं, सिर्फ Claude Code
  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 पर निर्भर होते जा रहे हैं
वे इसे एक ठोस नींव की तरह मानकर उस पर चीज़ें बना रहे हैं, जबकि किसी दिन मालिक वह नींव अचानक खींच भी सकता है
- फिर भी ये products एक-दूसरे के काफी substitutable लगते हैं
  हाल में rate limit थोड़ा परेशान कर रही थी इसलिए CC के बजाय Codex पसंद आया, लेकिन workflow लगभग बदलना नहीं पड़ा
- कम-से-कम कुछ investors यहाँ monopoly position बनाना चाहते हैं
  वे इतना पैसा झोंकना चाहते हैं कि 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 भी अब काफ़ी करीब आ चुके हैं
- अच्छी बात यह है कि local AI दिन-ब-दिन अधिक वास्तविक विकल्प बनता जा रहा है
- इसलिए मुझे लगता है कि सभी के लिए उपलब्ध और हमेशा चालू रह सकने वाले open source और sovereign models सबसे महत्वपूर्ण हैं
  OpenAI और Anthropic की competition भी दिलचस्प है, और open source की दिशा भी जुड़ जाए तो लगता है जल्द ही हम वहाँ पहुँच जाएँगे
- मालिक सीधे rug pull कर दे, या Broadcom खरीदकर निचोड़ना शुरू कर दे—ऐसा परिदृश्य भी पूरी तरह कल्पना से बाहर नहीं है
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 आया—यह मज़ाक बिलकुल फिट बैठता है
- मैं शायद इसे 5 मिनट से ज़्यादा सोचने नहीं दूँगा
- ऐसी स्थिति में क्या agentic/vibe coders अपने boss से कहते हैं, "मैं कल तक काम नहीं कर पाऊँगा"—यह सोचकर हँसी आती है
- वह error message ज्यों-का-त्यों Claude में फिर paste कर दें, तो कई बार वह आगे जारी रख देता है
  पिछले कुछ महीनों में मैंने यह कई बार देखा है; पहले लगा था कि यह AWS Bedrock की समस्या है, लेकिन शायद सिर्फ वही कारण नहीं है
- यह Max 5x है या 20x, कौन-सा plan है—यह जानने की जिज्ञासा है
मैं और मेरे कई सहकर्मी पिछले दो महीनों में 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 तरीके से, स्थिर रूप में उपयोग कर पाना चाहिए
- यह वास्तव में हुई समस्या थी, और Anthropic ने भी हाल में https://www.anthropic.com/engineering/april-23-postmortem में इसे स्वीकार किया है
  कंपनी ऐसी गलती करे तो चिढ़ होना स्वाभाविक है, लेकिन कुछ समय तक limits हटाकर उसने व्यावहारिक रूप से compensate भी किया, और उससे भी बढ़कर response काफ़ी transparent था
  पता नहीं कोई और बड़ी AI कंपनी इतनी transparency दिखाएगी या नहीं; इसलिए Claude पर गुस्सा होने पर भी उसके handling को सम्मान देता हूँ
- अगर 4.7 को xhigh या max effort पर नहीं रखा, तो यह लगभग समय की बर्बादी जैसा है
मेरी 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 में नहीं फँसता
- LLM के बारे में मेरा mental model ऐसा नहीं कि उससे एक साथ कई काम flawlessly करने की उम्मीद करूँ
  code cleanup और नई feature implementation अलग tasks हैं, और GLM जैसी चीज़ें ऊपर से ज़्यादा smart दिखें तो भी असली code review में आखिरकार build/prune cycle चाहिए ही था
- ऐसा मज़ाक बनने लायक है कि जो max20 इस्तेमाल नहीं हो रहा, क्या वह मुझे दे सकते हो
- सबसे productive setup यह था कि दोनों subscriptions रखी जाएँ; Claude को features ठोकने के लिए इस्तेमाल करें और Codex से review कराएँ कि
  "यह 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 बता रहा है
- AWS के समय भी यह बात होती थी कि "वे तुम्हारा पैसा क्यों बचाएँगे", लेकिन व्यवहार में कीमत कम होने पर users बढ़े और revenue भी बढ़ा
  AI कंपनियों के पास भी वैसी ही incentive है
  सस्ता होगा तो उपयोग बढ़ेगा, और जब तक price cost से ऊपर है, profit बढ़ सकता है
  इसलिए अपनी cost कम करने की वजह भी उनके पास पूरी है
- कुछ हद तक सही, लेकिन जब capacity constraints सचमुच सामने हों और Anthropic monopoly न होकर competition झेल रहा हो, तब आर्थिक incentives बदल जाते हैं
- मेरा मानना है कि लोग closed-agent lock-in से धीरे-धीरे थक जाएँगे
  इसलिए सिर्फ token efficiency को लक्ष्य बनाकर मैंने (cline fork) open source https://github.com/dirac-run/dirac बनाया है
  मेरा अनुमान है कि ये closed lock-in vendors समय के साथ users को पर्याप्त रूप से frustrate कर देंगे, और अभी contributors भी ढूँढ रहा हूँ
- फिर भी एक बिंदु तक ऐसी incentive रहेगी, लेकिन जब वे users को संभाल न पाने लगेंगे और ग्राहक जाने लगेंगे, तब स्थिति बदलेगी
- मैं भी ऐसा ही सोचता हूँ
  सुनने में conspiracy theory जैसा लगता है, लेकिन Anthropic जैसी कंपनियाँ तब भी लाभ में रहती हैं जब model काम पूरा नहीं कर पाता
  हाल में मैंने over editing phenomenon पर भी पढ़ा; लगता है मशीन कभी खत्म करना ही नहीं चाहती
  कुछ-कुछ dating app जैसा, जो अच्छा match नहीं चाहता
  क्योंकि अगर सफलता मिल गई तो user subscription बंद कर देगा
कल मेरे लिए समझ आने का क्षण था
मैंने local LLM से जुड़े Claude Code को एक simple extraction task दिया, और वह 10 मिनट तक बस भनभनाता रहा
वही data और prompt सीधे llama_cpp chat UI में model को दिया, तो 1 मिनट से कम में single-shot में काम पूरा हो गया
इसलिए लगता है कि coding agent खुद, या LLM से बात करने के तरीके में कहीं न कहीं कुछ गलत है
अभी मैं बेहद simple open source coding agent ढूँढ रहा हूँ; Nanocoder Mac पर ठीक से install नहीं होता और node-modules बहुत भारी हैं, Opencode भी पूरी तरह open source नहीं लगता
फिलहाल मैं खुद coding agent की भूमिका निभाते हुए llama_cpp web UI इस्तेमाल कर रहा हूँ, और यह काफ़ी ठीक चल रहा है
- https://pi.dev/ शायद लोकप्रिय है, और Opencode में ऐसा क्या है जो open source नहीं है—यह जानने की जिज्ञासा है
  repository पर तो MIT License लगा है
- यह थोड़ा अलग सुझाव हो सकता है, लेकिन अपने मौजूदा AI से ही अपना मनचाहा agent बनवा लीजिए
  अगर आपको "बेहद 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 काफ़ी तेज़ लगती है, लेकिन उतनी ही महंगी भी पड़ती है
- अगर आपने अभी तक सोचा न हो, तो अपना मनचाहा coding agent खुद बना सकते हैं
  उसका architecture उम्मीद से कहीं ज़्यादा simple है
- अब तक तो TUI और IDE के बीच कहीं आने वाला कोई tool होना ही चाहिए
- CC को local model के साथ भी चलाया जा सकता है, और यह उतना मुश्किल नहीं है
  मैंने 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 की जाती होगी—ऐसा सोचने का मन होता है
- मुझे यक़ीन नहीं कि वह graph वास्तव में time correlation दिखाता है
  60% line अगर 95% confidence interval के भीतर ही है, तो क्या वह सिर्फ measurement noise नहीं हो सकता?