Claude Sonnet 4 अब 10 लाख token context को सपोर्ट करता है
(anthropic.com)- Anthropic का Claude Sonnet 4 अब अधिकतम 10 लाख token context देता है, जिससे बड़े codebase या कई दस्तावेज़ों को एक साथ प्रोसेस किया जा सकता है
- बेहतर context support के साथ बड़े पैमाने पर code analysis, विशाल document sets की प्रोसेसिंग, और context बनाए रखने वाले agents के विकास जैसे कई उपयोग संभव हो गए हैं
- 2 लाख token से बड़े prompts के लिए API pricing बढ़ती है, लेकिन prompt caching और batch processing के ज़रिए लागत घटाई जा सकती है
- वास्तविक ग्राहक Bolt.new और iGent AI ने इस फीचर से productivity और AI capabilities में बड़ा सुधार हासिल किया है
- फिलहाल Sonnet 4 का long context support Anthropic API और Amazon Bedrock पर beta में उपलब्ध है, और जल्द ही Google Cloud पर भी आने वाला है
10 लाख token context support
- Claude Sonnet 4, जो Anthropic API पर उपलब्ध है, अब अधिकतम 10 लाख token context को सपोर्ट करता है
- इससे एक ही request में 75,000 से अधिक lines of code या कई research papers को एकीकृत रूप से प्रोसेस किया जा सकता है
- 10 लाख token context beta फीचर अभी Anthropic API और Amazon Bedrock पर उपलब्ध है, और Google Cloud के Vertex AI पर भी जल्द सपोर्ट मिलेगा
लंबा context, बढ़ते उपयोग के मामले
- बड़े पैमाने पर code analysis: पूरे codebase (source files, tests, documentation सहित) को एक साथ लाकर project structure को समझना, files के बीच संबंध पहचानना, और system design के आधार पर code improvements सुझाना संभव हो जाता है
- दस्तावेज़ों का एकीकृत सारांश: सैकड़ों legal contracts, research papers, और technical specifications का एक साथ analysis करके, दस्तावेज़ों के बीच के संबंध बनाए रखते हुए व्यापक insights निकाले जा सकते हैं
- context बनाए रखने वाले agents: सैकड़ों tool calls और multi-step workflows के दौरान पूरी API documentation, tool definitions, और interaction history को शामिल करते हुए consistent state बनाए रखने वाले conversational agents बनाए जा सकते हैं
API pricing policy
- 2 लाख token तक के prompts: input $3/मिलियन token, output $15/मिलियन token
- 2 लाख token से अधिक prompts: input $6/मिलियन token, output $22.5/मिलियन token
- prompt caching लागू करने पर latency और cost दोनों कम किए जा सकते हैं
- 10 लाख token context को batch processing के साथ जोड़ने पर अतिरिक्त 50% तक cost savings संभव हैं
ग्राहक उपयोग के उदाहरण
-
Bolt.new
- Bolt.new ने Claude को अपने web-based development platform के साथ integrate करके web development में नवाचार किया है
- "Sonnet 4 की 10 लाख context window की वजह से developers अब बड़े projects को अधिक accuracy के साथ संभाल सकते हैं"
-
iGent AI
- लंदन, UK स्थित iGent AI, Maestro नाम के AI partner के ज़रिए बातचीत की सामग्री को executable code में बदलता है
- "पहले असंभव रही autonomous software engineering क्षमता अब Sonnet 4 के 10 लाख token context से संभव हुई है, जिससे वास्तविक codebase पर कई दिनों तक sessions चलाना संभव हो गया है"
उपयोग का तरीका और आगे की योजना
- long context फीचर फिलहाल Anthropic API के Tier 4 और custom pricing plan customers के लिए beta में उपलब्ध है, और आने वाले कुछ हफ्तों में इसे अधिक उपयोगकर्ताओं तक बढ़ाया जाएगा
- Amazon Bedrock पर भी यह उपलब्ध है, और Google Cloud Vertex AI सपोर्ट भी जल्द आने वाला है
- अन्य Claude product family में भी long context लाने की योजना है
- अधिक जानकारी आधिकारिक documentation और pricing page में देखी जा सकती है
1 टिप्पणियां
Hacker News की राय
पेशेवर software engineering काम में LLM का सचमुच बेहतरीन context retention होना बेहद ज़रूरी लगता है। नया मॉडल थोड़ा बेहतर हुआ है, यह घोषणा व्यावहारिक काम में ज़्यादा दिलचस्प नहीं लगती; लेकिन कीमत सबसे बड़ा निर्णायक कारक है। मेरा codebase context window में समा जाए, यह अच्छी बात है, लेकिन कीमत काफ़ी बढ़ गई है, इसलिए अभी context management बेहतर करना ही सही लगता है। मैं context window का बहुत उपयोग करता हूँ, जो service provider के लिए फ़ायदेमंद है, लेकिन Sonnet वास्तव में कितना प्रभावी ढंग से focus बनाए रखता है, इसके लिए अलग मूल्यांकन चाहिए, इसलिए इसकी वास्तविक value पर भरोसा करना मुश्किल है।
context repo में होता है, और यह मानना पड़ेगा कि LLM के पास हमेशा सारा ज़रूरी context नहीं हो सकता। खासकर बड़े repo एक मशीन में पूरे नहीं समाते। किसी खास काम को पूरा करने के लिए focus बनाए रखने हेतु गैर-ज़रूरी जानकारी हटानी पड़ती है; सब कुछ ठूँस देने से उल्टा एकाग्रता घटती है। पहले window size बहुत छोटा था, और अभी भी छोटा ही लगता है, लेकिन अंततः सही सवालों के ज़रिए repo को समझने की क्षमता चाहिए।
बहुत ज़्यादा context डालने पर LLM के खुद ही भ्रमित होने का जोखिम बढ़ जाता है। लंबे context के साथ बिना reset किए चलते रहने पर focus बिखरने लगता है।
मेरा मानना है कि AI को पूरे codebase के बजाय सिर्फ abstracted जानकारी संभालने के लिए train करना चाहिए। इंसान भी पूरे code को दिमाग़ में रखकर काम नहीं करता, इसलिए LLM को भी ऐसा करने की ज़रूरत नहीं है।
हाल में Claude Code के साथ कुछ हफ़्ते काम करने के बाद मैं इस निष्कर्ष पर पहुँचा हूँ कि agentic AI की वास्तविक value तो उल्टा negative है। फिर भी 6-8 महीने बाद दोबारा कोशिश करूँगा।
मेरा नहीं मानना कि उपयोग का उद्देश्य सिर्फ एक बार में ज़्यादा code को context में ठूँसना है। कुछ कामों के लिए न्यूनतम आवश्यक context होता है, लेकिन 1M context model यह भी माँगता है कि data कैसे डाला जाए, इसके नए तरीके अपनाए जाएँ। इस मॉडल की असली ताकत long-horizon iterative exploration, in-context learning, और reconstruction जैसे deep-dive problems में है; उदाहरण के लिए API changes को 100 files में लागू करने जैसे breadth-first काम होते हैं, लेकिन 15 अलग तरीकों को आज़माकर समाधान खोजने जैसे depth-first कामों में भी इसकी ताकत है। Sonnet 1M खास तौर पर बाद वाली क्षमता में बेमिसाल दिखता है।
Claude Code और token usage को लेकर चिंतित उपयोगकर्ताओं के लिए कुछ tips दिए गए हैं:
/resumeसे वही thread खोलकर context-समृद्ध बिंदु तक double escape करके reset किया जा सकता है।Claude से यह कहने का तरीका इस्तेमाल किया जाता है: “किसी दूसरे session में तुमने task X लिखा था”, और फिर उस context का उपयोग करके सवाल या change request की जाती है।
मैं भी अक्सर ऐसा करता हूँ, लेकिन यह हमेशा अच्छी तरह काम नहीं करता। कभी-कभी पूरी बातचीत का context साथ रखते हुए Claude का उपयोग करना ज़्यादा मददगार होता है।
latency काफ़ी घट जाती है। नए Claude के context loading को शुरू से फिर करने का इंतज़ार नहीं करना पड़ता।
यह प्रक्रिया programmers के लिए astrology जैसी लगती है; जब तक खुद न बताओ, agent codebase पर काम करते हुए क्या करेगा, यह पता नहीं चलता।
दिलचस्प बात यह है कि जब code को किसी दूसरे developer का लिखा हुआ बताकर पेश किया जाता है, तो Claude ज़्यादा समस्याएँ क्यों ढूँढता है, यह जानने की उत्सुकता है।
अब तक Claude Code में सबसे उपयोगी तरीका यह रहा है कि सीधे पूछा जाए: "क्या current diff में bug है?" तब chatbot बदलावों का बारीकी से विश्लेषण करता है, और ऐसे subtle bugs जल्दी पकड़ लेता है जिन्हें ढूँढने में वरना बहुत समय और कई deploy cycles लगते; साथ ही code correctness बढ़ाने के लिए अलग-अलग बिंदु भी विस्तार से बताता है।
यह हैरान करने वाली बात है कि ‘ज़रा और गहराई से सोचो’ जैसा अलग निर्देश दिए बिना भी यह मनचाहे ढंग से काम करता है।
non-coding कामों में भी इस्तेमाल के अनुभव से लगता है कि creativity कम है, लेकिन critical और meticulous reader के रूप में इसकी क्षमता बहुत अच्छी है।
यह भी सुझाव है कि इस feature को Claude Code के hook के रूप में ठोस तरीके से implement किया जाए।
मैं भी कल से ही इस तरीके को आज़माने वाला हूँ।
मौजूदा tools के बारे में मेरा अनुभव यह है:
मेरा अनुभव भी ऐसा ही था (Cline + Sonnet & Gemini के साथ 1 साल), फिर Claude Code मिला और सबसे बढ़कर जब मैंने ‘context को सचमुच साफ़-सुथरे ढंग से manage करना’ सीखा, तब असली breakthrough महसूस हुआ। कुंजी यह है कि AI को code generator नहीं बल्कि architect और implementer की तरह treat किया जाए। अब मैं हमेशा पहले CC से हमारे करने वाले काम का design document लिखवाता हूँ, और उसे code व दस्तावेज़ दोनों refer करने को कहता हूँ। मैं उसे review करके यह साफ़ करता हूँ कि मुझे कौन-सी दिशा चाहिए, फिर काम के steps को chunks में बाँटता हूँ, और हर chunk को और छोटे हिस्सों में तोड़ता हूँ। शुरुआती definition पूरी हो जाने पर context साफ़ कर देता हूँ, फिर हर step पर उससे document पढ़वाकर implementation कराता हूँ। ज़रूरत पड़े तो correction की दिशा देता हूँ, या document बदलकर सिर्फ वही step फिर से शुरू करवाता हूँ। हर step के बाद commit, context clear, फिर अगला step। इस तरह पहले जो feature 2-3 दिन लेता था, वह अब एक दिन के भीतर बन जाता है। नतीजतन reviewed docs, unit tests, Storybook, accessibility (aria आदि) जैसी चीज़ों के साथ बेहतर output मिलता है। अंत में किसी दूसरे model से code review भी करवाता हूँ। भले अभी यह चौंका देने वाली speed न देता हो, फिर भी मुझे लगता है कि यह तेज़ी से विकसित हो रहे tools के लिए skill में future investment है।
मेरे हिसाब से यह tool पुराने Ruby on Rails के
rails newscaffolding जैसा एहसास देता है। LLM उन क्षेत्रों में बिल्कुल फिट है जहाँ tool की official docs समझकर project का शुरुआती skeleton बनाना हो। वहीं legacy systems या बहुत सारी external requirements वाले projects में यह कम उपयोगी है। Databricks जैसे तेज़ी से बदलने वाले tools के लिए यह लगभग बेकार है। अगर training data के बाद नाम, syntax, या features बदल गए हों, तो real-time docs को prompt में सक्रिय रूप से शामिल किए बिना मुश्किल से कोई संभावना बनती है।मेरा workflow Claude desktop और mcp server के filesystem को साथ में उपयोग करता है। मैं Claude को संबंधित file paths बताता हूँ और task हल करने को कहता हूँ। Claude खुद files पढ़कर उनका analysis करता है और ज़रूरी modifications/additions कर देता है। आमतौर पर मैं सिर्फ कुछ build errors paste कर देता हूँ, और वह फिर उन्हें भी ठीक कर देता है। code style को ज्यों का त्यों रखते हुए नया code लिख देने की इसकी क्षमता भी प्रभावशाली है। मैंने इसे Typescript और C# में इस्तेमाल किया है, और मेरे अनुभव में output सिर्फ hobby-level तक सीमित नहीं रहता।
मैं programmer नहीं हूँ, लेकिन मेरे काम में Python और bash code की ज़रूरत पड़ती है। मैं कुछ personal projects और websites भी चलाता हूँ। Claude Code की वजह से अब मैं वे छोटे projects बना पा रहा हूँ जिन्हें पहले समय और क्षमता की कमी के कारण नहीं कर पाता था। अब मैं अपना emacs environment भी खुद सुधार सकता हूँ। यह lisp functions भी तुरंत बना देता है। मेरे लिए यह एकदम perfect tool है। जो काम पहले अटका रहता था, अब वे जल्दी हो जाते हैं और ज़िंदगी आसान लगती है।
मैंने इसे Typescript, Go, SQL, Rust में इस्तेमाल किया है। Rust बहुत जटिल निकला और errors से भरा रहा; मैं चाहता हूँ कि project जल्दी खत्म हो जाए (हालाँकि project खुद ही बहुत कठिन है)। Go इतना simple है कि productivity बहुत अच्छी मिलती है, speed 2x हो जाती है। Typescript React components/animations के लिए ठीक-ठाक है, SQL/PostgreSQL के लिए भी। stored procedures का boilerplate मुझे नापसंद है, और LLM उसे घटा देता है, जिससे कलाई का दर्द भी कम होता है।
इतने सारे options होना निश्चित रूप से अच्छी बात है, लेकिन साथ ही बहुत ज़्यादा context भर देने से LLM output की quality गिर सकती है, क्योंकि LLM आसानी से distract हो सकता है। अगर user इस trade-off को समझे बिना सिर्फ auto mode पर निर्भर रहे, तो Claude Code से लिखे code की quality को लेकर चिंता होती है।
संदर्भ के लिए कुछ उपयोगी लेखों के links दिए गए हैं
अभी तक long context Claude Code में integrate नहीं हुआ है। कहा गया है कि “दूसरे products में भी long context लागू करने के तरीकों की जाँच की जा रही है।” लगता है कि वे इस समस्या को पहले से पहचान चुके हैं और समाधान पर सोच रहे हैं। शायद users के महँगे plans पर अतिरिक्त cost आने से पहले कोई solution लाना चाहते हैं।
पूछा गया है कि इसके बदले क्या alternative recommend किया जाएगा। Claude Code की आदत पड़ रही है, लेकिन best practices में अभी भी कच्चापन है।
Chroma team इस समस्या पर शोध कर रही है, और जल्द कुछ metrics आने वाले हैं।
पूछा गया कि क्या Opus बेहतर नहीं है? जब tokens खत्म होने पर ज़बरदस्ती Sonnet पर switch किया जाता है, तो बड़ा फ़र्क महसूस होता है। यह भी कहा गया कि अनुभव तो बढ़ गया है और ideas भी बहुत हैं, लेकिन coding कठिन लगती थी; Claude आने के बाद ideas को implement करना, testing, और bug fixing सब बहुत तेज़ हो गया है।
chat apps (ChatGPT, Claude.ai) की बड़ी समस्या context window से जुड़ी अजीब हरकतें हैं—अचानक truncation, summarization, ‘ghost snippets’ का फिर से घुस आना वगैरह। user को यह चुनने देना कि context जारी रखना है या नई chat शुरू करनी है, ज़्यादा सुविधाजनक लगता है, लेकिन वास्तविकता में plan और compute limits की वजह से ऐसा संभव नहीं हो पाता। वास्तव में developer tools (Google AI Studio) या API-wrapped chat apps का उपयोग करना पड़ता है ताकि पूरा context सही-सलामत भेजा जा सके। अगर custom chat app बनाया जाए, तो हर message में timestamp डालकर LLM को यह निर्देश दिया जा सकता है कि “हर 10 मिनट पर Markdown table की नई row में उस अवधि की summary लिखो।”
लगता है कि यह pricing पहली बार साफ़ तौर पर मानती है कि token count बढ़ने पर cost ‘square’ की तरह उछलती है। ऐसा लगता है कि किसी LLM provider ने पहली बार nonlinear pricing structure को प्रतिबिंबित किया है। यह तरीका inference scaling laws जैसा दिखता है, जिनसे हम पहले से परिचित हैं।
संबंधित विषय पर एक और चर्चा की ओर भी इशारा किया गया है
यह feature शानदार है, लेकिन यह जानने की उत्सुकता है कि inference speed सुधारने का तरीका क्या हो सकता है। निजी तौर पर 200K context काफ़ी है; बस response speed तेज़ होनी चाहिए। मेरा मानना है कि बहुत से लोग छोटे context size के साथ भी संतुष्ट होंगे, यदि agent कहीं ज़्यादा तेज़ी से काम करे (अभी हर prompt पर 2-3 मिनट इंतज़ार करना पड़ता है)।