Zerostack - शुद्ध Rust में लिखा गया Unix-प्रेरित coding agent

 (crates.io)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • zerostack Rust में लिखा गया एक न्यूनतम coding agent है, जो कई LLM providers और custom providers को साथ में support करता है
  • यह file read·write·edit, grep, file find, directory listing, permission-gated Bash execution, MCP, और Exa web tools प्रदान करता है
  • इसका आकार लगभग 7 हजार LoC, 8.9MB binary है, और RAM उपयोग खाली session में लगभग 8MB तथा काम के दौरान लगभग 12MB है; CPU idle पर 0.0% मापा गया
  • default provider OpenRouter है, installation cargo install zerostack से होता है, और --sandbox में Bash isolation के लिए bubblewrap आवश्यक है
  • इसमें code·plan·review जैसे built-in prompts, 4 permission modes, session resume, iterative loop, और Git worktrees integration शामिल हैं

zerostack का अवलोकन

  • zerostack Rust में लिखा गया एक न्यूनतम coding agent है, जो pi और opencode से प्रेरित है
  • इसमें OpenRouter, OpenAI, Anthropic, Gemini, Ollama, और custom providers को support करने वाली multi-provider architecture है
  • यह file tools जैसे file read·write·edit, grep, file find, directory listing, और permission-gated Bash execution प्रदान करता है
  • इसमें session save·load·resume, context window बनाए रखने के लिए automatic compression, crossterm-आधारित terminal UI, MCP server connection, और Exa-आधारित WebFetch·WebSearch tools शामिल हैं
  • /worktree के जरिए Git worktrees के बीच जाया जा सकता है, और long-running tasks के लिए iterative loop भी integrated है

प्रदर्शन और installation

  • zerostack का आकार लगभग 7 हजार LoC है, और binary size 8.9MB है
  • RAM उपयोग खाली session में लगभग 8MB और काम के दौरान लगभग 12MB है, जिसकी तुलना opencode या अन्य JS-आधारित coding agents के लगभग 300MB से की गई है
  • CPU उपयोग idle स्थिति में 0.0% और tools उपयोग के दौरान लगभग 1.5% मापा गया; Intel i5 7th gen पर opencode की तुलना idle में लगभग 2% और काम के दौरान लगभग 20% से की गई
  • installation के लिए Cargo और git चाहिए, और इसके लिए यह command उपयोग होती है 
    cargo install zerostack
  • --sandbox उपयोग करने पर सभी Bash commands को isolated environment में चलाने के लिए bubblewrap install करना होगा 
    # Debian/Ubuntu  
apt install bubblewrap  

# Fedora  
dnf install bubblewrap  

# Arch  
pacman -S bubblewrap

Quick Start

  • default provider OpenRouter है, और API key environment variable के रूप में set की जाती है 
    export OPENROUTER_API_KEY="[api_key]"
  • interactive session default prompt code के साथ चलती है 
    zerostack
  • one-shot execution mode में -p से prompt pass किया जाता है 
    zerostack -p "Explain this project"
  • last session को -c से resume किया जाता है 
    zerostack -c
  • provider और model को explicitly specify किया जा सकता है 
    zerostack --provider openrouter --model deepseek/deepseek-v4-flash

Prompt system

  • zerostack में built-in system prompts का एक सेट है, जो agent के behavior और tone को बदलता है
  • इसका लक्ष्य superpower या Claude official skills का विकल्प बन सकने वाला prompt suite तैयार करना है
  • /prompt से registered prompts की list देखी जा सकती है या किसी दूसरे prompt पर switch किया जा सकता है

  • Built-in prompts

    • code default है, और full file·Bash tool access तथा TDD workflow का उपयोग करने वाला coding mode है
    • plan code लिखे बिना exploration करके plan बनाने वाला planning-only mode है
    • review correctness, design, testing, और impact की समीक्षा करने वाला code review mode है
    • debug fixes सुझाने से पहले root cause ढूंढने वाला debug mode है
    • ask read-only mode है, जिसमें केवल read·grep·glob की अनुमति है और write या Bash की नहीं
    • brainstorm code लिखे बिना ideas explore करने और design प्रस्तावित करने वाला design-only mode है
    • frontend-design विशिष्ट और production-grade UI के लिए frontend design mode है
    • review-security exploit हो सकने वाली vulnerabilities खोजने वाला security review mode है
    • simplify behavior बदले बिना clarity बढ़ाने वाला code simplification mode है
    • write-prompt agent prompts बनाने और optimize करने वाला prompt-writing mode है
    • custom prompts $XDG_CONFIG_HOME/zerostack/prompts/ में Markdown files रखकर और नाम से reference करके बनाए जा सकते हैं
    • project root या parent directories में AGENTS.md या CLAUDE.md को अपने-आप पढ़कर system prompt में insert किया जाता है; इसे -n या --no-context-files से disable किया जा सकता है

Permission system

  • zerostack सबसे सुरक्षित से सबसे permissive तरीके तक 4 permission modes प्रदान करता है

  • Permission modes

    • restrictive या -R configuration में explicitly allowed न किए गए हर tool action पर approval मांगता है
    • standard default है; ls, cd, git log, cargo check जैसे safe commands auto-approve होते हैं, जबकि write और destructive actions पर confirmation मांगा जाता है
    • accept-all या --accept-all working directory के भीतर की सभी operations auto-approve करता है और बाहरी paths पर confirmation मांगता है
    • yolo या --yolo बिना prompt के सभी operations auto-approve करता है
    • configuration file में tool-wise glob patterns देकर permissions को granular तरीके से configure किया जा सकता है
    • उदाहरण के लिए write **.rs को auto-allow रखते हुए बाकी file writes पर हमेशा confirmation मांगा जा सकता है
    • session allowlist approved decisions को session के दौरान बनाए रखती है, ताकि उसी action के लिए बार-बार confirmation न देना पड़े
    • यदि वही tool call 3 बार या अधिक दोहराया जाता है, तो doom-loop detection warning prompt दिखाता है या configuration के अनुसार उसे reject करता है, ताकि agent destructive actions को बार-बार न दोहरा सके

Slash commands और session management

  • मुख्य slash commands model, thinking level, conversation, sessions, loops, prompts, और permission modes को control करते हैं
  • /model model switch करता है, और /thinking thinking level set करता है
  • /clear conversation साफ करता है, और /session sessions को list·save·load करता है
  • /loop iterative prompt schedule करता है, और /prompt agent prompts को list या change करता है
  • /mode permission system mode set करता है, और पूरी command list /help से देखी जा सकती है
  • sessions $XDG_DATA_HOME/zerostack/sessions/ में save होती हैं
  • -c सबसे recent session को resume करता है, -r sessions browse करके चुनने देता है, और --session <id> किसी specific session को load करता है

Iterative loop

  • zerostack में long-running tasks के लिए iterative coding loop शामिल है
  • agent task को repeatedly पढ़ता है, plan से items चुनता है, काम करता है, tests चलाता है, plan update करता है, और task completion या iteration limit तक loop जारी रखता है
  • loop system एक experimental feature है

  • Loop usage

    • /loop Implement the user authentication system दिए गए prompt से loop शुरू करता है
    • /loop stop active loop को रोकता है
    • /loop status current loop status दिखाता है
    • हर iteration में original task, बदलता हुआ LOOP_PLAN.md, previous iteration summary, और validation output शामिल होते हैं
    • loop active रहने के दौरान slash commands के अलावा बाकी input block हो जाता है

  • CLI-आधारित headless loop

    • नीचे दी गई command से headless loop चलाया जा सकता है 
      zerostack --loop --loop-prompt "Refactor the API" --loop-max 10 --loop-run "cargo test"
    • --loop headless loop mode को enable करता है
    • --loop-prompt <text> हर iteration के लिए उपयोग होने वाला prompt specify करता है
    • --loop-plan <path> custom plan file path specify करता है; default LOOP_PLAN.md है
    • --loop-max <N> maximum iteration count specify करता है; default में कोई limit नहीं है
    • --loop-run <cmd> हर iteration के बाद चलने वाली validation command specify करता है

Git worktrees integration

  • zerostack branch-wise work workflow को git worktrees के साथ प्रदान करता है
  • chat UI के भीतर worktree बनाया जा सकता है, उसमें काम किया जा सकता है, merge किया जा सकता है, और उससे बाहर निकला जा सकता है
  • Git worktrees integration एक experimental feature है

  • worktree commands

    • /worktree <name> <name> branch पर git worktree बनाकर वहां move करता है; यदि वह पहले से मौजूद हो, तो creation skip हो जाता है
    • /wt-merge [branch] worktree branch को [branch] में merge करता है, push करता है, cleanup करता है, और फिर main repository में लौटता है
    • /wt-exit बिना merge किए main repository में लौटता है

  • Example workflow

    • /worktree feature-x नई branch और worktree directory बनाकर वहां move करता है
    • इसके बाद zerostack को सामान्य तरह से उपयोग करने पर changes feature branch में बने रहते हैं
    • /wt-merge agent को branch merge, push, cleanup करके main repository में लौटने देता है
    • /wt-exit बिना merge के तुरंत main repository में लौटता है

Supported providers और license

  • default provider OpenRouter है
  • OpenAI-compatible providers के रूप में vLLM, LiteLLM आदि support किए जाते हैं
  • Anthropic, Gemini, और Ollama support किए जाते हैं
  • custom providers को $XDG_CONFIG_HOME/zerostack/config.json में arbitrary base URL और API key environment variable के साथ configure किया जा सकता है
  • license GPL-3.0-only है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • मुझे ऐसे टूल्स की बहुत जानकारी नहीं है, लेकिन जानना चाहता हूँ कि Claude Code जैसे मॉडल/टूल की तुलना में इसके क्या फ़ायदे हैं

  • मैं भी फुर्सत के समय में ऐसा ही कुछ खुद बना रहा था, मकसद एजेंट्स को और गहराई से समझना और Rust सीखना था
    लेकिन मैं pi की configurability बनाए रखना चाहता था। खुद को बदलने और नए टूल बनाने की क्षमता बहुत उपयोगी है, और मेरा मानना है कि ऐसे टूल्स को bash के ज़रिए मनमाना कोड चलाने की अनुमति नहीं होनी चाहिए
    हाँ, अगर edit और cargo run का एक्सेस हो तो तब भी मनमाना कोड चलाया जा सकता है, लेकिन जब bash के बिना एजेंट को कुछ करना होता है, तो मैं ज़रूरत पड़ने पर उसी समय टूल बना लेता हूँ

    • मैंने इस बारे में सोचा था, लेकिन Pi TypeScript-आधारित है इसलिए उसके पास स्क्रिप्ट-जैसा environment हो सकता है, जबकि Rust एक compiled language है इसलिए सीमाएँ हैं
      इसलिए मैंने customization की अनुमति देने के लिए दूसरा तरीका चुना। ~/.config/hypernova/prompts/ में मौजूद prompt library Skills का एक सरल विकल्प है, और built-in prompts को superpowers और Claude के frontend-design की जगह लेनी चाहिए
      एजेंट को भारी बना सकने वाली सुविधाएँ compile समय में feature flags से बंद की जा सकती हैं, और कोड छोटा और पढ़ने में आसान है, इसलिए ज़रूरत हो तो zerostack के अपने source पर zerostack चलाकर custom fork बनाया जा सकता है
      permission model, जैसा README में दिखता है, बहुत सोच-विचार के बाद 4 स्तरों में बनाया गया है: बिना किसी command वाले “Restrictive” से लेकर एजेंट जो चाहे वह करने वाले “YOLO” तक, और bash calls के लिए allow/ask/deny regex भी लगाए जा सकते हैं। इस स्थिति में सिर्फ zerostack -R चलाकर सभी टूल्स से permission पूछना अनिवार्य किया जा सकता है
      programmable agent features पर भी काम चल रहा है, लेकिन अभी घोषणा करने की स्थिति नहीं है
    • मैं भी यही चीज़ Zig में बना रहा हूँ

  • हाल ही में मैंने मज़ाक-मज़ाक में लेकिन थोड़ा गंभीर होकर 200 लाइनों से कम का एक संस्करण भी बनाया: https://github.com/pnegahdar/nano
    इसमें REPL, sessions, non-interactive execution, approval जैसी सुविधाएँ हैं। मेरा मानना है कि जैसे-जैसे मॉडल ज़्यादा स्मार्ट होते जाएँगे, developer experience को छोड़ दें तो harness की अहमियत कम होती जाएगी
    शायद कभी इसे SWE-bench पर चलाकर देखूँ

    • 200 लाइनें, बल्कि असल में सिर्फ 190 लाइनों में बनाया — यह सच में कमाल है
      मैंने भी पिछले हफ़्ते मज़े और सीखने के लिए एक खुद बनाया था, और ज़्यादातर coding agents की तरह configured mcpServers के साथ integration भी काम करता है
      मैंने step-by-step यह भी लिखा है कि क्या क्यों ज़रूरी है: https://nb1t.sh/building-a-real-agent-step-by-step/

  • “RAM footprint: ~8MB on an empty session, ~12MB when working”
    यह हिस्सा बहुत अच्छा लगा। Claude Code कई GB इस्तेमाल करता है, इसलिए कम-स्पेक लैपटॉप पर काफ़ी परेशान करता है

    • मैं Go में एक agent framework बना रहा हूँ और वह बहुत हल्का है
      startup time 0.5 सेकंड से कम है और RAM उपयोग भी बहुत कम है। 12 साल पुराने लैपटॉप पर भी बिना धीमा हुए अच्छे से चलता है
      असल में जो चीज़ string concatenation engine के काफ़ी करीब हो, उसके पुराने hardware समेत किसी भी मशीन पर धीमा होने का कोई कारण नहीं होना चाहिए
    • मैं Zed पर शिफ्ट होने की कोशिश कर रहा हूँ, और Agent Client Protocol काफ़ी अच्छा लग रहा है। अगर Claude Code इस तरीके से गुज़रे तो memory pressure कितना कम होगा, यह जानना दिलचस्प होगा
      1: https://zed.dev/acp
    • सही है। सिर्फ इसी बात से बहुत से लोग इसे एक बार ज़रूर आज़माएँगे
    • memory usage इतना बढ़िया है कि अब shellbox.dev के x1 जैसी बहुत छोटी instances पर भी coding agent चलाया जा सकता है
    • यह भी देखना होगा कि कहीं LSP plugin जैसी कोई चीज़ साथ में चल तो नहीं रही

  • घर पहुँचकर इसे आज़माना पड़ेगा। हल्के और तेज़ टूल coding experience में बड़ा फ़र्क़ लाते हैं
    यह जानने की जिज्ञासा है कि prompt-आधारित तरीका, आम skills और sub-agents के संयोजन की तुलना में व्यवहार में कैसा है। मैं अक्सर इन्हें मिलाकर इस्तेमाल करता हूँ — जैसे build fail होने पर /fix-ci skill चलाता हूँ, और sub-agent error message, stack trace, और संबंधित logs निकालकर समस्या हल करता है
    integration tests में अगर DB query की दिक्कत आए, तो एजेंट खुद या मेरे हल्के इशारे पर read-only DB access skill बुलाकर जाँच करता है। जब किसी चीज़ में लंबा और गहरा खोदना हो, तो मैं कहता हूँ, “Sonnet sub-agent का इस्तेमाल करो और DB query skill से इस behavior को debug करो”
    skills तुरंत अतिरिक्त क्षमता देती हैं, और sub-agents context bloating रोकने के लिए isolation देते हैं। अगर एजेंट bash से खुद को किसी दूसरे prompt के साथ चला ले, तो कुछ हद तक वैसा हो सकता है, लेकिन शायद थोड़ा कम smooth होगा — मुझे खुद देखना पड़ेगा

    • ज़्यादातर मामलों में यह skills जैसा ही है, लेकिन इसे “command” से ज़्यादा environment की तरह समझना चाहिए
      उदाहरण के लिए, integrated prompts में से एक /prompt debug एक debug-केंद्रित agent खोलता है, और उस स्थिति में आप उससे सामान्य agent की तरह बात करते रह सकते हैं, फिर /prompt code से वापस standard coding agent पर लौट सकते हैं
      sub-agents अभी supported नहीं हैं क्योंकि पूरा agent इस समय एक ही context buffer में चलता है और मैं इसे हल्का रखना चाहता हूँ। लेकिन जिन tasks में बहुत exploration होती है, वे context window को जल्दी फुला देती हैं, इसलिए sub-agents बाद में जुड़ने की काफ़ी संभावना है

  • मैंने भी Claude Code से ऐसा कुछ बनवाया था, और editing के लिए Dirac की line hashing भी जोड़ी थी
    मैंने Rust इस्तेमाल किया, और plugin के ज़रिए hooks लागू करके self-modification की क्षमता देने का सोचा था, लेकिन अंत में इसे इस तरह व्यवस्थित किया कि improvements की detailed जानकारी अलग फ़ाइल में बनाई जाए, source code अपडेट किया जाए, और फिर दोबारा compile किया जाए
    source code location स्थिर है, इसलिए एजेंट खुद को फिर से लिखकर build कर सकता है। मैं इसे 2x RTX 6000 Pro पर DeepSeek 4 Flash चलाकर इस्तेमाल कर रहा हूँ, और लगभग 138 tok/s मिल रहे हैं
    सच कहूँ तो यह Pi, Dirac, OpenCode से काफ़ी हद तक प्रेरित है। क्या यहाँ से अपनाने लायक कोई नई तकनीक है?

    • हल्केपन के अलावा दिलचस्प features में prompt library, Git worktree integration, और Ralph Wiggum loop integration डाले हैं
    • क्या यह GitHub पर public है?

  • मैंने इसे थोड़ी देर इस्तेमाल किया और यह सच में काफ़ी तेज़ लगा
    यह भी जानना चाहूँगा कि क्या आप contributors ढूँढ रहे हैं, या इसे सिर्फ personal tool की तरह बना रहे हैं
    लेकिन दूसरे models इस्तेमाल करने की कोशिश में कुछ समस्याएँ मिलीं। Azure का gpt-5.5 OpenAI-compatible endpoint इस्तेमाल करने पर भी max_tokens को max_completion_tokens में बदल देता है, इसलिए यह काम नहीं करता
    custom headers पास करने का तरीका भी नहीं दिखा, इसलिए DeepSeek models के लिए reasoning_effort सेट नहीं कर पाया

    • मैं PRs लेने को तैयार हूँ
      जो बातें आपने बताईं वे codebase में साफ़ bug लगती हैं, इसलिए अगर संभव हो तो हर bug के लिए अलग GitHub issue खोल दें

  • Claude Code और Opencode मेरे environment में अच्छी तरह काम करते हैं
    यह थोड़ा मज़ेदार है कि coding agents data center में 1000W से ज़्यादा power और 2TB से ज़्यादा memory पर चलते हैं, लेकिन लोग अपने laptop के आख़िरी कुछ watts और कुछ सौ MB memory पर ध्यान देते हैं
    वैसे भी code compile करने की energy cost के सामने यह छोटी बात है, लेकिन फिर भी इसे तेज़ और हल्का बनाना बुरा नहीं है

    • data center dedicated power lines पर चलता है, लेकिन मेरा laptop battery पर चलता है
      अभी coding agent इस्तेमाल करूँ तो battery काफ़ी जल्दी खत्म होती है, और यह सोचकर हैरानी होती है कि ज़्यादातर काम तो मेरे laptop पर होता भी नहीं
      client-side coding agents को efficient बनाना climate बचाने के लिए नहीं, बल्कि काम के घंटे बढ़ाने के लिए है। असल में यह climate के लिए और बुरा भी हो सकता है
    • स्वाभाविक है कि लोग अपने कंप्यूटर पर चलने वाले software पर ध्यान दें
      दूसरे के कंप्यूटर पर चलने वाला software मेरी समस्या नहीं है। किसी और के server पर क्या चल रहा है, उस पर मेरा नियंत्रण नहीं है, और अगर होता भी, तो उसका RAM cost मैं नहीं दे रहा, इसलिए परवाह नहीं करता
      दूसरी ओर मेरे अपने उपकरण की RAM का खर्च मैं देता हूँ। अगर 1KB से भी कम text दिखाने वाला TUI कई GB memory घेर ले और Windows पर दूसरे apps को OOM से मार दे, या Linux पर HDD में swap करते-करते पूरी मशीन रोक दे, तो परवाह करना ही पड़ेगा
      जब RAM की कीमत सच में 5 गुना और दूसरे parts की कीमत 2~3 गुना बढ़ चुकी हो, तब memory waste से बचना ख़ास तौर पर ज़रूरी हो जाता है
    • यह बात कुछ ज़्यादा ही simplification है
      मॉडल बहुत बड़ा और resource-hungry होना सही है, लेकिन harness इस बात पर बड़ा असर डाल सकता है कि मॉडल का कितना उपयोग होगा
      उदाहरण के लिए, अगर harness में मज़बूत tool set हो, तो मॉडल कहीं ज़्यादा efficiently काम कर सकता है

  • codebase छोटा था, इसलिए मैंने Pi के अंदर DeepSeek v4 Flash को देकर कहा कि जोखिम वाली जगहें देख ले, और उसे ख़ास चिंता की कोई बात नहीं मिली। अच्छा बनाया है

    • चूँकि OP ने कहा था कि code का काफ़ी हिस्सा DeepSeek V4 Flash ने बनाया है, इसलिए मैंने यह देखने के लिए जाँच की कि कहीं पुराने dependencies तो नहीं हैं
      Rust projects में मेरा अनुभव है कि अगर मॉडल को Cargo.toml सीधे न बदलने और cargo add इस्तेमाल करने को न कहा जाए, तो Claude 4.7 Opus भी लगभग हमेशा पुराने dependencies जोड़ देता है
      मैंने इस project के dependencies हाथ से जाँचे और अच्छा लगा कि सब latest versions पर थे। हालाँकि इसका यह मतलब नहीं कि transitive dependencies में कोई समस्या छिपी नहीं हो सकती
      LLM से code review कराने की बात जल्दी ही पसंद-नापसंद का मामला बन सकती है। उदाहरण के लिए, कोड को देखते हुए कुछ methods जो string और enum के बीच आ-जा रही थीं, उन्हें देखकर लगा कि “क्या यह strum में एक #[derive] से नहीं हो सकता था?”। dependency-free एक crate जोड़ने की बजाय provider.rs काफ़ी अधिक संक्षिप्त हो सकता था
      मज़े के लिए मैंने DeepSeek V4 Pro के Max thinking से codebase का “audit” भी कराया, और उसने कहा कि छिपी हुई telemetry के कोई साफ़ संकेत नहीं हैं। लेकिन उसने यह ज़रूर बताया कि project ने panic handler को abort पर सेट किया है, और इस पर मेरी मज़बूत राय है
      शायद binary size के कुछ KB बचाने के लिए libunwind linking से बचा गया होगा, लेकिन फिर crash होने पर binary तुरंत बंद हो जाएगी और user को stack trace नहीं मिलेगा। अगर panic पर उपयोगी debug info मिल सकती हो, तो binary का लगभग 50KiB बड़ा होना मुझे बेहतर सौदा लगता है
      और अगर async task में panic हो जाए, तो उसे recover करके सामान्य error message भी नहीं दिखाया जा सकता; पूरा process तुरंत बंद हो जाएगा
    • code का काफ़ी बड़ा हिस्सा DeepSeek v4 Flash ने लिखा था, और TUI logic का कुछ भाग मैंने खुद लिखा
      क्योंकि DeepSeek एक खास cursor movement logic में बार-बार विफल हो रहा था। memory optimization की प्रक्रिया पूरी तरह मैंने खुद संभाली, और जैसा मैंने दूसरे comment में लिखा, उसमें compiler optimization और अधिक efficient data structures के लिए Rust crates के इस्तेमाल का संयोजन था
    • “Pi के अंदर DeepSeek v4 Flash को देकर जोखिम वाली जगहें देखना” क्या prompt injection की वजह से काफ़ी कमज़ोर जाँच तरीका नहीं है?

  • यह मज़ेदार है कि यह आज ही आया। मैं भी अभी Rust में एक लिखना शुरू करने वाला था
    बड़े projects में opencode को धीरे-धीरे memory leak करते हुए 6GB तक जाते और फिर क्रमशः धीमा पड़ते देखना हैरान करने वाला है
    मैं इसे ज़रूर देखूँगा। बढ़िया लग रहा है

    • सही कहा। यह project तब शुरू हुआ जब एक पुराने laptop पर Firefox और opencode की 2 से ज़्यादा instances साथ चलाने पर OOM killer सक्रिय हो गया था