फिर से रिलीज़ का समय।

तीन हफ्ते पहले, मई राउंड-अप ने पूरे स्टैक को एक ही पोस्ट में समेट दिया था। तब से दो सबसे यूज़र-फेसिंग टूल्स ने एक-एक नया माइनर शिप किया — Octocode 0.16.0 और Octobrain 0.8.0, दोनों 7 जून को कट हुए — और इसके ऊपर Octolib की 0.21.5 से 0.23.0 तक की चढ़ाई।

इन सबमें एक ही धागा चलता है, और इसे शुरू में ही कहना ठीक रहेगा: यह राउंड कुछ भी कॉन्फ़िगर न करने के बारे में है। Octolib 0.23.0 में Git checkout को देखने और एक स्थिर project ID निकालने का एक साझा तरीका जुड़ा। Octocode 0.16.0 अब अपनी project identification सीधे उसी को सौंप देता है; Octobrain 0.8.0 ने उसी कदम में automatic project discovery उठा ली। नतीजा यह है कि जिन दो टूल्स को आप वास्तव में किसी codebase पर इंगित करते हैं, वे शुरू होते ही काम करते हैं, किसी भी repo में, बिना किसी project ID को हाथ से सेट किए।

चलिए वहीं से शुरू करें जहाँ यह सबसे ज़्यादा मायने रखता है।

Octocode 0.16.0 — एक सर्वर, हर repo, अब Swift के साथ

github.com/muvon/octocode · 0.15.0 → 0.16.0 · 7 जून

0.15.0 local-first रिलीज़ थी — कोई API key नहीं चाहिए, hybrid search और reranking डिफ़ॉल्ट से चालू। वह एक single index को आउट ऑफ़ द बॉक्स अच्छा बनाने के बारे में था। 0.16.0 इस बारे में है कि जब आपके पास सर्च करने के लिए एक से ज़्यादा codebase हों तब क्या होता है।

Multi-repository server mode — mcp-proxy की जगह। सबसे बड़ा बदलाव। यह एक breaking change है, लेकिन अपग्रेड के लायक है। अब तक, एक ही असिस्टेंट के ज़रिए कई repositories सर्व करने का मतलब था single-repo Octocode इंस्टेंसेस के बेड़े के आगे एक mcp-proxy चलाना — ज़्यादा मूविंग पार्ट्स, ज़्यादा को ज़िंदा रखना, ज़्यादा को समझाना। 0.16.0 उस layer को मिटा देता है। एक Octocode MCP सर्वर अब natively multi-repository बोलता है। आप एक बार कनेक्ट करते हैं, और आपका एजेंट हर कनेक्शन पर एक ही प्रोजेक्ट में बंद होने के बजाय आपके इंडेक्स किए हुए codebases में सर्च कर सकता है।

ध्यान दें: mcp-proxy को हटाना 0.16.0 की breaking-changes सूची का इकलौता आइटम है। अगर आपका सेटअप आज Octocode को proxy के ज़रिए लॉन्च करता है, अपग्रेड पर बस वही हिस्सा बदलना होगा।

Zero-config project identification। Octocode अब यह पता लगाने का अपना लॉजिक नहीं रखता कि कोई डायरेक्ट्री किस प्रोजेक्ट की है — यह उसे Octolib को सौंप देता है, जो Git remote से एक स्थिर identity निकालता है (यह क्यों मायने रखता है, इस पर नीचे और)। फ़ायदा: यह वही identity है जो Octobrain और बाकी स्टैक अब निकालते हैं, तो memory और code search इस बात पर सहमत होते हैं कि "यह प्रोजेक्ट" का मतलब क्या है, बिना आपके कुछ भी जोड़े।

Swift, एंड टू एंड। 0.16.0 Swift को indexer और structural grep दोनों में जोड़ता है। अगर आप किसी iOS या macOS codebase में काम कर रहे हैं — और अब हमारे पास उनमें से कई हैं, Vext, Timex, और TypeTab के बीच — तो Swift symbols semantic search और pattern matching के लिए first-class हैं, सिर्फ़ plain text नहीं।

env var के ज़रिए custom config path। अब आप एक fixed location पर निर्भर रहने के बजाय एक environment variable से Octocode को किसी config file पर इंगित कर सकते हैं। छोटा बदलाव, पर CI jobs और अलग-अलग सेटिंग्स वाले कई प्रोजेक्ट्स को सँभालने वाली मशीनों के लिए quality-of-life में बड़ी जीत।

अंदर ही अंदर security hardening। दो बदलाव जो आपको दिखेंगे नहीं पर जिनके बारे में जानना चाहिए: Git URL credentials अब normalization के दौरान हटा दिए जाते हैं, तो embedded token वाला कोई remote कभी किसी stored project URL में नहीं लिखा जाता; और storage layer अपने table names को centralize करता है और अपनी SQL queries को harden करता है।

cargo install octocode --version 0.16.0
# or grab a binary at https://github.com/muvon/octocode/releases

Octobrain 0.8.0 — मेमोरी जो खुद को कॉन्फ़िगर करती है

github.com/muvon/octobrain · 0.7.0 → 0.8.0 · 7 जून

0.7.0 शोर भरी थी — sleep consolidation, half-life decay, goal-anchored memory, HyDE recall डिफ़ॉल्ट से चालू। वह रिलीज़ इस बारे में थी कि आपकी AI की memory अपने आप क्या करती है। 0.8.0 उस आखिरी चीज़ को हटाने के बारे में है जो आपको अब भी हाथ से करनी पड़ती थी: इसे बताना कि यह किस प्रोजेक्ट में है।

Automatic project discovery और ID derivation। 0.8.0 की मुख्य बात, और धागे का दूसरा आधा हिस्सा। Octobrain अब प्रोजेक्ट को खोज लेता है और उसका ID अपने आप निकाल लेता है — और अंदर ही अंदर इसने अपनी git utilities की जगह Octolib की ले ली (रिलीज़ Octolib 0.23.0 पर बढ़ती है), तो जो identity यह निकालता है वह वही है जो Octocode निकालता है। Octobrain को किसी repo के अंदर शुरू करें और इसकी memory उस प्रोजेक्ट से खुद बंध जाती है: न कोई project parameter पास करना, न कोई ID एक टूल से दूसरे में कॉपी करना, और न यह जोखिम कि आपका code search और आपकी memory अलग-अलग प्रोजेक्ट्स पर इंगित कर रहे हों। जो memory पहले से self-maintaining थी अब self-configuring भी है।

env var के ज़रिए custom config path। Octocode जैसी ही ergonomics में जीत, सोच-समझकर — दोनों टूल्स ने इस राउंड वही capability उठाई ताकि वे CI और multi-project मशीनों पर एक जैसा व्यवहार करें।

एक leaner MCP surface। 0.7.0 ने toolset को 8 टूल्स से घटाकर 5 कर दिया था। 0.8.0 जो बचा है उसे ट्यून करता है: tool listing और memory provider ऑप्टिमाइज़ हुए हैं, और project तथा role locking अब decoupled हैं — तो एक ही प्रोजेक्ट पर काम करने वाले दो roles, या प्रोजेक्ट्स में फैला एक role, एक ही lock पर contend करना बंद कर देते हैं।

0.8.0 नोट्स में कोई breaking changes सूचीबद्ध नहीं, तो यह 0.7.0 से एक clean अपग्रेड है — और व्यवहार में आप project ID पास करना बंद कर पाते हैं, क्योंकि Octobrain अब इसे खुद ही पता लगा लेता है।

cargo install octobrain --version 0.8.0
# or grab a binary at https://github.com/muvon/octobrain/releases

Octolib 0.21.5 → 0.23.0 — वह plumbing जिसने ऊपर वाला सब संभव बनाया

github.com/muvon/octolib · 0.21.5 → 0.23.0

कुछ ज़रूरी बातें, क्योंकि यही वह layer है जो चुपचाप काम करता है। Octolib हमारे हर LLM कॉल के पीछे का इंजन है, और हाल ही में यह वह जगह भी बन गया है जहाँ साझा, non-LLM utilities रहती हैं ताकि ऊपर वाले टूल्स हर एक उन्हें दोबारा से न बनाएँ।

  • Git repo detection और project ID derivation (0.23.0)। वह हिस्सा जिसे Octocode 0.16.0 स्पष्ट रूप से सौंपता है, और जिस पर Octobrain 0.8.0 उसी रिलीज़ में आया। "क्या यह Git repo है, इसका canonical remote क्या है, इसके लिए एक स्थिर ID क्या है" का लॉजिक एक ही जगह रखो, और Octolib पर निर्भर हर टूल को वही जवाब मिलता है। यही पूरी वजह है कि zero-config project identity पूरे स्टैक में consistent है, बजाय इसके कि तीन टूल्स हर एक अपने-अपने तरीके से थोड़े-थोड़े गलत हों।
  • Response schema enforcement (0.23.0)। Octolib अब जाँच सकता है कि किसी मॉडल का output किसी अपेक्षित response schema से मेल खाता है — कहीं भी उपयोगी जहाँ आप किसी LLM से structured output वापस parse कर रहे हों।
  • Claude Opus 4.8 सपोर्ट (0.21.7)। सबसे नया Opus जोड़ा गया है, साथ में OctoHub structured output और finish-reason सपोर्ट ताकि callers बता सकें कि कोई generation क्यों रुका, सिर्फ़ यह नहीं कि रुका।
  • Minimax M3 और M3-highspeed (0.21.8)। roster में दो और मॉडल।
  • Parallel tool handling और connection timeouts (0.22.0)। parallel tool calls का बेहतर handling और HTTP client पर एक connection timeout, request handling एकल send_and_read path के पीछे unified — किसी धीमे या अटके endpoint के एजेंट को stall करने के कम तरीके।
  • Token-accounting fixes (0.21.6)। Cached tokens अब double-count नहीं होते, और compression summaries अब conversation history को block नहीं करतीं। अगर लंबे cached sessions पर आपके cost numbers थोड़े ज़्यादा दिख रहे थे, तो यही वजह है — और यह ठीक हो गया है।

अगर आप Rust से LLMs को कॉल करने वाला कुछ भी बनाते हैं, तो यही वह layer है जिस पर standardize करें: हर provider जो Octolib पहले से बोलता है, एक ही trait के पीछे, उसी retry logic और उसी cost accounting के साथ।

और Octofs? 0.4.3 पर टिका — जानबूझकर

github.com/muvon/octofs · 0.4.3 · अपरिवर्तित

Octofs ने मई राउंड-अप में 0.4.3 शिप की — regex search, parallel file walking, और एक delete कमांड — और तब से इसे किसी रिलीज़ की ज़रूरत नहीं पड़ी। यह उपेक्षा नहीं है; यही तो बात है। filesystem layer स्टैक का वह इकलौता हिस्सा है जिसे आप boring और predictable चाहते हैं, और अभी यह वैसा ही है। जब इसके ऊपर का runtime यह बदलेगा कि वह files को कैसे छूता है, Octofs फिर आगे बढ़ेगा। तब तक, 0.4.3 अपना काम कर रही है।

Octomind 0.30.0 — अलग से शिप हुआ

इस स्टैक को आपस में बाँधने वाला runtime, Octomind, ने भी 3 जून को 0.30.0 शिप किया — portable workflow files, project-local guardrails, और session observability। इसका अपना अलग लेख है, तो हम बस आपको वहीं भेज देते हैं: octomind.run पर Octomind 0.30.0 की रिलीज़ नोट्स।

ये कैसे जुड़ते हैं

स्टैक पिछले महीने जैसा ही है। जो बदला वह यह कि अब इसके बारे में कितना कम सोचना पड़ता है। Octolib 0.23.0 अब Git से एक बार project identity निकालता है, और Octocode 0.16.0 और Octobrain 0.8.0 दोनों इसे पढ़ते हैं। Octocode के आगे कोई proxy नहीं। कॉन्फिग्स के बीच कोई project ID कॉपी नहीं। कोई जोखिम नहीं कि आपका code search और आपकी memory अलग-अलग प्रोजेक्ट्स पर इंगित कर रहे हों।

एक साल पहले, इन्हें आपस में जोड़ने का मतलब था एक proxy, एक कॉपी किया हुआ ID, और यह उम्मीद कि दोनों सहमत हों। वह gap अब बंद है। सिंगल बाइनरी, Apache-2.0, सब के सब।

हम पहले से अगले पर लग चुके हैं। अगर यहाँ कुछ आपकी रुकी हुई किसी चीज़ को अनब्लॉक करता है, issue खोलें — जून में माँगे फीचर्स जुलाई में शिप करने की प्रवृत्ति रखते हैं।

— Don