एक छोटी स्टेटस लाइन, ताकि दिमाग हल्का रहे

जब कोडिंग एजेंट काम करता है, टर्मिनल में हलचल की कमी नहीं होती। कमांड आती हैं, फ़ाइलें बदलती हैं और नए संदेश दिखते हैं। फिर भी मेरे सवाल कहीं छोटे हो सकते हैं: इस सेशन में कौन-सा मॉडल चल रहा है? इसका कॉन्टेक्स्ट कितना भर गया है? क्या मैं वही सेशन देख रहा हूँ जो समझ रहा हूँ? और इस काम में खर्च कितना हो रहा है?

घूमता संकेतक किसी और सवाल का जवाब देता है

मेरा पिछला ETA लेख अपने समय की योजना पर था: इंतज़ार करूँ, विषय बदलूँ या बाद में लौटूँ? स्टेटस लाइन उसी समस्या का दूसरा पहलू सँभालती है। अगला कदम चुनने से पहले मैं सामने वाले सेशन की स्थिति साफ देखना चाहता हूँ।

घूमता संकेतक बताता है कि कुछ हो रहा है। लंबा ट्रांसक्रिप्ट बताता है कि क्या हो चुका है। लेकिन ज़रूरी नहीं कि दोनों में से कोई वह जानकारी एक नज़र में दे जो मुझे चाहिए।

स्टेटस लाइन क्या सामने लाती है

दिया गया टर्मिनल दृश्य इस विचार को ठोस बनाता है। एक लाइन में चुना हुआ रूट, उससे तय हुआ मॉडल, कॉन्टेक्स्ट का उपयोग और लागत के अनुमान साथ दिखते हैं। प्रोजेक्ट और अकाउंट की पहचान की जगह तटस्थ उदाहरण रखे गए हैं।

रूटिंग लेबल और उससे चुना गया मॉडल अलग-अलग जानकारी हैं। यहाँ रूट OpenRouter से होकर एक OpenAI मॉडल तक जाता है। यह विस्तारित कॉन्फ़िगरेशन है; Claude Code के डिफ़ॉल्ट इंटरफ़ेस के बारे में दावा नहीं।

कॉन्टेक्स्ट डिस्प्ले में 1,000,000 में से 186,551 टोकन, यानी 19.0%, दिखते हैं। इससे अमूर्त क्षमता समझना आसान होता है। लेकिन 19% कॉन्टेक्स्ट का मतलब काम 19% पूरा होना नहीं है, और इससे अकेले बाकी मिनटों का पता नहीं चलता।

लागत वाले फ़ील्ड साफ तौर पर अनुमान या प्रदाता-विशिष्ट काउंटर हैं। उनकी अपनी परिभाषाएँ चाहिए; मैं स्टेटस लाइन की किसी संख्या को सत्यापित बिल नहीं मानूँगा। इस सेटअप में पूर्वानुमान और ऑटोमेटिक मोड अतिरिक्त संकेत हैं, यहाँ बताए गए न्यूनतम रेंडरर की सुविधाएँ नहीं।

लागत पर नज़र भी उसी लाइन में होनी चाहिए

स्टेटस लाइन जोड़ने की सबसे उपयोगी वजहों में लागत को सामने रखना शामिल है। एजेंट लगातार काम करता रह सकता है, जबकि मैं भूल जाऊँ कि कितने प्रयास, दोबारा रन या समानांतर सेशन शुरू कर चुका हूँ। यह बात मैं बिल देखते समय नहीं, पहले ही जानना चाहता हूँ।

स्क्रीनशॉट में “est. $6.61” और “OR today $9.31” हैं। ये अलग लेबल वाले दो काउंटर हैं; इन्हें सीधे जोड़ देना सही नहीं होगा। इन पर निर्भर होने से पहले मुझे इनका दायरा, कीमत का स्रोत और अपडेट होने का तरीका समझना होगा। अनुमान दिशा तय करने में मदद करते हैं; वास्तविक शुल्क जाँचने के लिए प्रदाता के उपयोग रिकॉर्ड ही सही जगह हैं।

मेरा व्यावहारिक तरीका सरल होगा:

• शुरू करने से पहले खर्च की एक सीमा तय करें जहाँ रुककर समीक्षा होगी। अप्रिय आश्चर्य का इंतज़ार करने के बजाय तय करें कि आगे के रन कब रोककर जाँचे जाएँगे।
• बढ़ते खर्च को उपयोगी नतीजों के साथ मिलाकर देखें। अगर वही टेस्ट बार-बार फेल हो और खर्च बढ़ता जाए, तो एक और बड़ा प्रयास करवाने से पहले काम का दायरा घटाएँ या रुकावट की जाँच करें।
• अगला कदम सोच-समझकर चुनें। छोटा अगला काम, उपयुक्त मॉडल या मैनुअल जाँच काफी हो सकती है। मॉडल बदलने पर भी वही गुणवत्ता जाँच ज़रूरी रहती है।

दिखाई देने वाला काउंटर अपने आप बजट की सीमा लागू नहीं करता और रिक्वेस्ट नहीं रोकता। API शुल्क, सब्सक्रिप्शन और प्रदाता-विशिष्ट बैलेंस भी अलग रखने चाहिए। मकसद समय और तकनीकी गुणवत्ता के साथ खर्च को भी सोच-समझकर किए जाने वाले फैसले का हिस्सा बनाना है।

प्रतिशत दिखे तो उससे कोई उपयोगी फैसला निकलना चाहिए

कॉन्टेक्स्ट का बढ़ता आँकड़ा काम की निरंतरता के बारे में सोचने का संकेत है। क्या अगले कदम स्पष्ट हैं? क्या ज़रूरी फैसले कहीं स्थायी रूप से लिखे गए हैं? अगला हिस्सा शुरू करने से पहले छोटा हैंडओवर मदद करेगा?

ऐसा कोई सार्वभौमिक प्रतिशत नहीं है जहाँ से सेशन खराब हो जाता है। छोटा, साफ दायरे वाला काम और फैलती हुई पड़ताल बातचीत से अलग-अलग माँगें रखते हैं। मैं संख्या को संकेत मानूँगा, फिर काम को खुद देखूँगा।

कॉन्टेक्स्ट मीटर यह भी नहीं बता सकता कि एजेंट को अनुमति या किसी फैसले की ज़रूरत है। उसके लिए ध्यान माँगने वाला स्पष्ट संकेत चाहिए, जो इस शृंखला का अलग विषय है।

“पता नहीं” भी उपयोगी जवाब है

सबसे बेकार डिस्प्ले वह है जो गायब जानकारी को चुपचाप भरोसा दिलाने वाली संख्या बना दे। कोई फ़ील्ड उपलब्ध न हो तो लाइन को यही कहना चाहिए।

स्क्रीनशॉट में उपलब्ध मान दिखते हैं। कोई मान गायब हो तो हरे शून्य से बेहतर मुझे साफ “उपलब्ध नहीं” लगेगा। इससे पता चलता है कि कौन-सी जानकारी नहीं है, बजाय ऐसी सटीकता का भ्रम देने के जिसका डिस्प्ले समर्थन नहीं कर सकता।

इतना छोटा कि समझ और हटा सकें

Claude Code में स्टेटस लाइन कॉन्फ़िगर की जा सकती है: एक स्थानीय कमांड सेशन का JSON पढ़कर डिस्प्ले प्रिंट करती है। आधिकारिक संदर्भ में मॉडल और कॉन्टेक्स्ट फ़ील्ड का विवरण है। इससे एक और डैशबोर्ड के बिना शुरुआत करने का व्यावहारिक रास्ता मिलता है।

न्यूनतम वर्शन में मैं मॉडल और कॉन्टेक्स्ट से शुरू करूँगा। लागत का अनुमान तभी जोड़ूँगा जब उसका स्रोत और दायरा स्पष्ट हो। रेंडरर दिए गए फ़ील्ड ही इस्तेमाल करे: रिपॉज़िटरी स्कैन, नेटवर्क खोज या बातचीत का संग्रह नहीं। ये इस उदाहरण के डिज़ाइन फैसले हैं, हर स्टेटस लाइन एक्सटेंशन के बारे में वादे नहीं।

रेंडरर चालू करने से पहले मैं उसे ज्ञात इनपुट से आज़माऊँगा और देखूँगा कि गायब मान साफ तौर पर गायब ही दिखें। मेरे लिए उपयोगी शुरुआत समझ में आने वाले संकेत हैं, संख्याओं का सबसे बड़ा संग्रह नहीं।

मकसद दिमाग में कम चीज़ें याद रखना है

स्टेटस लाइन एजेंट की सोच बेहतर नहीं करेगी और उसके बदलावों की समीक्षा की जगह भी नहीं लेगी। लेकिन जिस जानकारी को मुझे याद रखना या ढूँढ़ना पड़ता है, उसके लिए वह एक छोटी, एक-जैसी जगह दे सकती है।

एजेंट टूलिंग की यही दिशा मुझे दिलचस्प लगती है: बुनियादी संदर्भ समझने के लिए कम रुकावटें, और उन फैसलों के लिए अधिक ध्यान जिनमें सचमुच इंसान चाहिए।

आप अपने कोडिंग सेशन के नीचे एक शांत-सी लाइन में क्या देखना चाहेंगे?

संदर्भ

Claude Code की स्टेटस लाइन का आधिकारिक दस्तावेज़, 27 अक्टूबर 2026 को जाँचा गया।

प्रोजेक्ट और अकाउंट की पहचान के लिए तटस्थ उदाहरणों वाला स्क्रीनशॉट। संख्याएँ स्नैपशॉट हैं, लाइव माप नहीं।