Claude Code, Codex जैसे AI कोडिंग एजेंट्स को कई tmux sessions में चलाकर एक साथ इस्तेमाल करते समय एक समस्या आई। कौन-सा session खत्म हो गया, कौन-सा मेरा इंतज़ार करते हुए रुका हुआ है, यह छूट जाता था, और background में चल रहे एजेंट्स का usage limit लगने के बाद ही पता चलता था।
tmux के साथ यहीं तक सीमा थी, इसलिए मैंने comux बनाया।
comux, AI agents चलाने के लिए tmux-style multiplexer है।
- सभी sessions के agent status (working / ready / blocked) को sidebar में real time में दिखाता है
- agent अपना turn खत्म करे या input का इंतज़ार करे, तो तुरंत desktop notification भेजता है
- server बंद हो जाए या reboot हो जाए, तब भी restart पर हर agent को उसी बातचीत वाले बिंदु पर restore किया जाता है (tmux-resurrect से अलग, यह session को restart करता है)
- agents का usage और जमा हुई notifications को status bar में real time में देखा जा सकता है
यह dependencies के बिना एक single static binary है, इसलिए SSH headless server जैसी जगहों पर भी कहीं भी चल सकता है।
यह बड़े terminal project (copad) का हिस्सा है, लेकिन comux को अलग से भी install किया जा सकता है:
# Comux만 설치
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Copad까지 설치 (Linux & MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
4 महीने की निर्माण यात्रा: https://marshallku.com/dev/road-to-making-my-own-terminal/
जो लोग कई agents चलाते हैं, उनके feedback का स्वागत है।
3 टिप्पणियां
ब्लॉग पोस्ट भी मैंने बहुत दिलचस्पी से पढ़ी।
मैं भी एक मिलती-जुलती वजह से टर्मिनल डेवलप कर रहा हूँ, इसलिए कुछ सवाल पैदा हुए।
व्यक्तिगत रूप से मुझे लगता है कि आजकल जैसा DX environment इतनी तेजी से बदल रहा है, और हर डेवलपर के लिए इतना अलग हो गया है, वैसा दौर शायद पहले कम ही रहा होगा।
मुझे नहीं पता आपने भी ऐसा महसूस किया या नहीं, लेकिन ऐसे समय में मुझे लगा कि control मेरे पास होना ज़्यादा फ़ायदेमंद है,
और जब मैंने सोचा कि AI युग के DX की बुनियाद क्या है, तो मुझे लगा कि वह terminal-based ही है।
हाल में popular हुए काफ़ी टर्मिनल मैंने इस्तेमाल किए हैं, लेकिन ज़्यादातर टर्मिनलों में Korean input भी ठीक नहीं था, और agents इस्तेमाल करने के लिए DX, UX भी असुविधाजनक था। इसलिए मैं भी इस निष्कर्ष पर पहुँचा कि इसे सीधे ख़ुद ही बनाना चाहिए, और मुझे लगता है कि अपने टर्मिनल की वजह से मैंने दूसरों की तुलना में बेहतर productivity हासिल की है।
मेरे मामले में पूरी तरह control हासिल करने के लिए
मैंने यह भी सोचा कि external library dependencies को भी न्यूनतम रखना चाहिए, इसलिए मैंने Zig के साथ ज़्यादातर चीज़ें खुद विकसित करने का रास्ता चुना (वेबव्यू जैसी अपरिहार्य चीज़ों को छोड़कर)।
लेकिन ब्लॉग पोस्ट और code देखकर लगा कि आपने Rust चुना, और
ratatuiआदि में खुद सब कुछ बनाने के बजाय Rust ecosystem में मौजूद external libraries को चुना। इसका कारण जानने की उत्सुकता है।पोस्ट में भी देखा कि external library dependencies से जुड़े कुछ issues थे।
और क्योंकि webview native webview है, ज़्यादातर web environments Safari environment नहीं होते, इसलिए लगता है कि पूरी E2E testing कठिन होगी। क्या इस हिस्से को आप बस external testing tools पर छोड़ने वाले हैं? या आगे चलकर CEF जोड़ने की भी कोई योजना है? यह भी जानना चाहूँगा।
मैं भी अब अपना टर्मिनल काफ़ी इस्तेमाल करते हुए stabilization phase में आ गया हूँ, और अब feature additions, planning, या UX पर बहुत सोचने का चरण चल रहा है। लेकिन development के दौरान crashes और तरह-तरह के bugs काफ़ी रहे होंगे।
यह भी जानना चाहूँगा कि development शुरू करने के बाद लगभग कब आपका बनाया हुआ टर्मिनल इतना stable हो गया था कि आप execution के लिए external terminal की बजाय अपने self-developed terminal में ही प्रवेश करने लगे?
नमस्ते!
अच्छा अनुभव और विचार साझा करने के लिए धन्यवाद।
बेशक, code बनाने की unit cost कम होने से खुद बनाने का रास्ता खुला है, लेकिन निजी तौर पर मैं AI का दौर आ गया है या नहीं, इससे अलग होकर external libraries अपनाने को देखता हूँ।
सिर्फ जब मुझे लगता है कि ये दोनों बातें सही हैं, तभी मैं खुद बनाता हूँ।
कारण कई हैं, लेकिन आखिरकार, code का कितना भी छोटा टुकड़ा हो, अगर मैं उसे manage करना शुरू करता हूँ तो वह अंततः उस क्षेत्र में आ जाता है जहाँ मुझे review, testing, maintenance वगैरह करनी पड़ती है, और मुझे लगता है कि केवल code लिखने से आगे की लागत हमेशा साथ आती है।
Development process में भी जो issues आए, वे window manager जैसे काफी core programs से टकराव से जुड़े थे, इसलिए अगर इसे भी पूरी तरह build from scratch करता, तो external dependencies से टकराव के कारण debugging और testing में लगने वाले समय से कहीं ज्यादा समय implementation और validation में लगाना पड़ता, ऐसा मुझे लगता है।
इसके अलावा, development शुरू करने के बाद से मैंने लगातार दर्द झेलते हुए भी अपना बनाया tool इस्तेमाल किया, और मुझे लगता है कि यह संभव हो पाया क्योंकि मैंने कुछ हद तक dependencies के ऊपर development शुरू किया था।
MacOS में SwiftTerm हटाने वाले उदाहरण की तरह, पहले external dependency लाकर यह जांचा कि मेरी चाही हुई concept काम करती है या नहीं, और जब कुछ ऐसा आया जिसे मुझे implement करना था तो मैंने खुद implement करना शुरू किया; लेकिन उस समय भी external dependency की वजह से मेरे programs चल रहे थे, इसलिए मैं उसी के ऊपर stabilization और features जोड़ने पर लगातार मेहनत कर सका।
साथ ही, webkit जोड़ने पर ज्यादातर web apps वैसे ही काम करते हैं जैसे सामान्य browser खोलने पर करते हैं!
हाल में मैं headless browser को cli से control करने वाले tools और claude in chrome का भी सक्रिय रूप से उपयोग कर रहा हूँ, और terminal तक chromium चढ़ाकर memory का अत्यधिक उपयोग होने से बचाना चाहता हूँ, इसलिए अगर कोई बड़ा मामला न हो तो terminal के अंदर webview का tech stack शायद बहुत नहीं बदलूँगा।
पढ़ने के लिए धन्यवाद!
मल्टीप्लेक्सर install link कट रही है.. README में इस आइटम को देखें, तो आप सिर्फ मल्टीप्लेक्सर install कर सकते हैं.