एक context window storage नहीं है — यह working memory है। window में हर token (आपका system prompt, बातचीत का इतिहास, कोई भी documents जो आप paste करते हैं, और मॉडल का अपना output अब तक) समान fixed-size budget के लिए competes करता है। जब लोग कहते हैं कि Claude के पास 200K context window है या Gemini 1M tokens का समर्थन करता है, वे numbers सब कुछ शामिल करते हैं: input और output combined। एक आम ग़लती context window को एक database की तरह मानना है जिसे आप documents से full भर सकते हैं और मॉडल से perfectly खोजने की अपेक्षा कर सकते हैं। वास्तविकता में, मॉडल attention mechanisms के माध्यम से context process करते हैं, और attention के दोनों computational और qualitative limits हैं।
"lost in the middle" समस्या real और well-documented है। Stanford और कहीं और से शोध ने दिखाया कि जब आप critical जानकारी को एक बहुत लंबे context के बीच में रखते हैं, मॉडल इसे शुरुआत या अंत में जानकारी की तुलना में measurably उपयोग करने में बदतर हैं। यह एक theoretical चिंता नहीं है — यह सीधे प्रभावित करता है कि आपको अपने prompts को कैसे संरचित करना चाहिए। यदि आप एक मॉडल को documentation के 50 pages feed कर रहे हैं, सबसे महत्वपूर्ण sections पहले और अंत में रखें, page 25 पर दबे हुए नहीं। कुछ टीमें इसके आसपास काम करती हैं documents को chunking करके और सब कुछ context में dumping करने के बजाय केवल relevant pieces को retrieve करने के लिए RAG का उपयोग करके।
Context window sizes नाटकीय रूप से बढ़ी हैं। GPT-3 2020 में 4K tokens (लगभग 3,000 शब्द) के साथ launched। 2024 तक, Claude ने 200K tokens की पेशकश की, और Gemini 1.5 Pro ने 1M tokens तक pushed किया। Google के Gemini 2.5 मॉडल वह million-token window बनाए रखते हैं। लेकिन बड़ी windows real trade-offs के साथ आती हैं। Latency बढ़ती है क्योंकि मॉडल को अधिक tokens पर attend करना होता है। लागत बढ़ जाती है क्योंकि अधिकांश API providers per token processed शुल्क लेते हैं। और जैसा कि उल्लेख किया गया है, retrieval कार्यों पर quality context size के साथ linearly scale नहीं करती — एक 1M-token window एक needle ढूँढ़ने में 200K-token window से 5x बेहतर नहीं है।
APIs के साथ काम करने वाले developers के लिए, context management एक core इंजीनियरिंग समस्या है। लंबी बातचीत tokens को तेज़ी से जमा करती हैं। एक back-and-forth chat प्रति exchange 500-1,000 tokens consume कर सकती है, जिसका अर्थ है कि एक 4K-token मॉडल बस कुछ turns में जगह से बाहर हो जाता है। Production सिस्टम इसे sliding windows (सबसे पुराने messages को drop करते हुए), summarization (पहले की बातचीत को एक छोटे summary में compressing), या hybrid दृष्टिकोणों के साथ handle करते हैं जो reference material को एक vector database में offload करने और demand पर केवल relevant chunks में pull करने के लिए RAG का उपयोग करते हैं। इसे सही करना अक्सर एक demo जो काम करता है और एक product जो scales के बीच का अंतर है।
एक nuance जो newcomers को trips करता है: context window limit tokens पर है, characters या शब्दों पर नहीं। Tokenization मॉडल और भाषा से भिन्न होती है। English text प्रति 4 characters लगभग 1 token average होता है, लेकिन code denser हो सकता है (variable names और syntax tokens को तेज़ी से खाते हैं), और Chinese या Hindi जैसी non-Latin scripts अक्सर प्रति शब्द अधिक tokens का उपयोग करती हैं। वही document English में 10K tokens और Japanese में 15K consume कर सकता है। अधिकांश providers tokenizer tools या libraries प्रदान करते हैं — Anthropic के पास API response headers में एक token counter है, और OpenAI tiktoken प्रकाशित करता है — ताकि आप अनुमान लगाने के बजाय बिल्कुल माप सकें।