dirac - सटीक और टोकन-कुशल ओपन सोर्स AI एजेंट

 (github.com/dirac-run)
3 पॉइंट द्वारा GN⁺ 2026-04-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लंबे context में reasoning performance के डगमगाने की समस्या को कम करने के लिए घनी context curation और tool efficiency के मुकाबले performance optimization पर फोकस करता है
  • gemini-3-flash-preview के आधार पर Terminal-Bench-2 65.2% दर्ज किया, और सार्वजनिक GitHub repositories के 8 जटिल refactoring tasks में 8/8 success हासिल किया
  • Hash-Anchored Edits, Multi-File Batching, और structure-aware editing को जोड़कर कई files को कम round-trips में संभालता है, और TypeScript·Python·C++ जैसी भाषाओं की syntax structure को ध्यान में रखकर बदलाव करता है
  • file read·write, terminal commands, और headless browser को support करता है, साथ ही approval-based workflow और Plan Mode·Yolo Mode·task history resume जैसे CLI flows भी देता है
  • औसत लागत $0.18 और प्रतिस्पर्धी tools की तुलना में 64.8% cost reduction का दावा करता है, और benchmark-specific जानकारी के बिना real-world tasks में performance और cost दोनों सुधारने की बात खास तौर पर उभरती है

मुख्य प्रदर्शन

  • बेंचमार्क परिणाम

    • सभी 8 tasks में 8/8 सही दर्ज किए, और तुलना किए गए tools में केवल Opencode ही समान 8/8 तक पहुंचा
    • औसत लागत $0.18 रही, जो Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38, Roo $0.60 से कम है
    • README के अनुसार Dirac प्रतिस्पर्धी tools की तुलना में 64.8% सस्ता है, और cost के आधार पर 2.8 गुना बचत बताई गई है
    • विस्तृत task descriptions और methodology evals/README.md में देखी जा सकती है

  • task-वार cost विशेषताएँ

    • transformers, vscode, django repositories सहित प्रत्येक refactoring task में अधिकांशतः सबसे कम या सबसे कम श्रेणी की लागत दर्ज की गई
    • उदाहरण के लिए transformers का DynamicCache task $0.13, django का datadict task $0.08, और vscode का sendRequest task $0.25 के स्तर पर है
    • कुछ प्रतिस्पर्धी tools ने Incomplete या Failure दर्ज किया, लेकिन Dirac तालिका में दिखाए गए सभी 8 tasks में Success के रूप में चिह्नित है

approach और design

  • context और editing strategy

    • Hash-Anchored Edits स्थिर line hashes के आधार पर edit location को target करता है, जिससे पारंपरिक line number आधारित editing की "lost in translation" समस्या से बचा जा सके
    • Multi-File Batching से कई files को एक ही LLM round-trip में पढ़ा और बदला जाता है, जिससे latency और API cost कम होती है
    • High-Bandwidth Context optimization सबसे प्रासंगिक जानकारी को ही बनाए रखता है, जिससे token waste कम होता है और agent हल्का व तेज बना रहता है

  • structure-aware editing

    • AST-Native Precision अंतर्निहित है, जिससे TypeScript, Python, C++ जैसी भाषाओं की grammar structure को समझते हुए काम किया जाता है
    • दावा है कि function extraction या class refactoring जैसे structural manipulations को 100% accuracy के साथ किया जा सकता है

  • tool usage model

    • file reading और writing, terminal command execution, और headless browser उपयोग आदि को support करता है
    • task flow approval-based workflow बनाए रखता है ताकि user के पास control रहे
    • model support केवल उन मामलों तक सीमित है जहाँ native tool calling संभव हो, जिसका कारण reliability और performance सुनिश्चित करना बताया गया है
    • README के अनुसार MCP supported नहीं है

उपयोग का तरीका और customization

  • project-वार behavior control

    • AGENTS.md file के जरिए project-specific instructions लागू कर behavior को customize किया जा सकता है
    • .ai, .claude, .agents directories को अपने-आप पढ़कर Claude skills का भी उपयोग करता है

  • CLI usage flow

    • dirac auth से authentication करने के बाद dirac "Analyze the architecture of this project" की तरह task चलाया जा सकता है
    • dirac -p "prompt" Plan Mode है, जिसमें पहले strategy देखी जाती है
    • dirac -y "prompt" Yolo Mode है, जो सभी actions को auto-approve करता है
    • git diff | dirac "Review these changes" की तरह pipe input से context सीधे दिया जा सकता है
    • dirac history से पिछले tasks देखकर उन्हें फिर से जारी रखा जा सकता है

  • VS Code integration

    • VS Code Marketplace से extension install किया जा सकता है
    • VS Code sidebar खोलकर Anthropic, OpenAI, OpenRouter आदि preferred AI provider सेट करने के बाद नया task शुरू किया जाता है

runtime environment और provider integration

  • API keys और environment variables

    • authentication step छोड़ने के लिए ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN आदि को environment variables के रूप में लिया जा सकता है
    • पूरी सूची src/shared/storage/env-config.ts में है

  • AWS Bedrock support

    • AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN के साथ AWS_BEDROCK_MODEL या AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN सेट करने पर यह अपने-आप Bedrock provider पर स्विच हो जाता है
    • aws-vault के साथ उपयोग किए जा सकने वाले execution examples भी शामिल हैं
    • Sonnet 4.6 या उससे नए Claude models के लिए us., eu., ap. जैसे cross-region inference profile prefix की आवश्यकता होती है, और supported model IDs के लिए AWS docs देखने का निर्देश दिया गया है

project background

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

1 टिप्पणियां

 
GN⁺ 2026-04-28
Hacker News की राय

  • Dirac में मुझे ये हिस्से दिलचस्प लगे
    यह Hash-Anchored edits के optimized version से फ़ाइल एडिट करता है, और भाषा के AST का इस्तेमाल करके तय करता है कि कौन-सा कोड context में डालना है, इसलिए बड़े code file को पूरा पढ़ने की ज़रूरत नहीं पड़ती
    काम को पूरी तरह batches में बाँधकर bulk read/modify एक साथ संभालता है, और ज़रूरत पड़ने पर मॉडल bash/python/perl scripts सीधे चलाकर तुरंत analysis भी कर लेता है
    साथ ही context को काफ़ी बारीकी से manage करता है, ताकि अगली बार मॉडल लगभग पक्का जो जानकारी माँगेगा, उसे पहले से ही शामिल करके update किया जा सके

    • मैं हमेशा सोचता था कि AST का इस्तेमाल code editing या change range inference में ज़्यादा व्यापक रूप से क्यों नहीं होता
      पहले एक लेख में किसी ने कहा था कि grep भी काफ़ी हद तक उतना ही असरदार है, और उस context में वह बात कुछ हद तक समझ में आई थी
    • Anchor-based editing में नए anchors को context में inject करना पड़ता है, और Dirac भी diff के ज़रिए ऐसा करता दिखता है, तो मुझे साफ़ नहीं है कि token के हिसाब से यह सच में search and replace से ज़्यादा efficient है या नहीं
      Hash अगर सिर्फ़ एक token का भी हो, तब भी ऐसा ही है, और code में reading writing से ज़्यादा होती है, इसलिए cumulative cost भी बढ़ती है
      पहले जब मैंने लंबे stable anchors के साथ experiment किया था, तो वह उल्टा regression जैसा लगा, और Dirac की efficiency शायद मूलतः फ़ाइल का skeleton ही दिखाने से ज़्यादा आती है
    • Batches all operations का मतलब समझ नहीं आया, इसलिए source देखा; वहाँ ऐसा लगा कि मॉडल से parallel tool calls अच्छे से करवाने की उम्मीद करने के बजाय tool API को ही इस तरह design किया गया है कि वह कई targets की list ले सके
      मेरे अनुभव में भी मॉडल bulk parallel calls एक साथ करने में अच्छे नहीं होते, और model जितना weak हो, यह रुझान उतना ज़्यादा दिखता है
    • SOTA models पर tokens खर्च करने के बजाय, क्या file editing के लिए बहुत सस्ता specialized model इस्तेमाल करना बेहतर नहीं होगा
      ऐसा भी संभव लगता है कि top-tier model सिर्फ़ एक सस्ता editing model बनाकर उसे call करे
    • अगर context को language AST से चुना जा रहा है, तो क्या यह अंततः सिर्फ़ parser वाले languages में ही काम करने वाली संरचना है, यह जानने की जिज्ञासा है

  • यह वाकई दिलचस्प है कि AI harness performance पर कितना बड़ा असर डालता है
    Google के official result में 48% से 65% तक जाना बहुत बड़ा फ़र्क है, लेकिन model comparisons तो बहुत देखे हैं, उसी model पर सिर्फ़ harness बदलने के नतीजे लगभग कभी नहीं देखे
    जिज्ञासा है कि क्या उसी model पर harness performance compare करने वाला कोई leaderboard है

    • शायद पूरे model+harness के Cartesian product की तुलना करनी पड़ेगी
    • सबसे ज़्यादा quote किया जाने वाला benchmark terminal bench 2.0 है, लेकिन यहाँ भी cheating के शक और benchmaxxing की समस्या से पूरी तरह बचा नहीं जा सका
      काफ़ी हैरानी की बात है कि Opus 4.6 में Claude Code सबसे नीचे है; यह Claude Code की सीमा भी हो सकती है, या benchmark खुद क्या दिखा रहा है, इसकी ओर इशारा भी हो सकता है
    • कभी-कभी लगता है कि भविष्य मानव-जैसी centralized intelligence का नहीं, बल्कि octopus-like distributed intelligence का ज़्यादा हो सकता है
      तब असली बात मॉडल से ज़्यादा harness को स्मार्ट बनाना होगी
    • शायद यही काम आख़िरकार terminal-bench भी कर रहा है
    • पिछले कुछ महीनों में उसी local model से खुद testing करके देखा, तो मेरे environment में Claude Code, OpenCode से साफ़ बेहतर था, और OpenCode, Codex से बेहतर था

  • अगर benchmark है, तो कम-से-कम किसी दूसरे model family का एक model और शामिल होना चाहिए, तभी पता चलेगा कि यह generalize करता है या नहीं
    लागत को देखते हुए Minimax 2.7 ठीक विकल्प लगता है, और तब तक यह तय करना मुश्किल है कि नतीजे Gemini 3 Flash पर overfit तो नहीं हैं
    Landing page पर भी साफ़ लिखना चाहिए कि मौजूदा सारे numbers Gemini 3 Flash पर आधारित हैं, और अगर सस्ता होने का मतलब उसी model पर तेज़ होना है, तो completion time को भी benchmark में शामिल करना बेहतर होगा
    इसके अलावा skills, nested AGENTS.md, और MCP support भी migration सोच रहे लोगों के लिए अहम हैं

    • मैंने Minimax 2.7 पर खुद चलाकर देखा; उसे editing tools ख़ास पसंद नहीं आए, और वह जल्दी ही sed से फ़ाइल बदलने की तरफ़ ढह गया
      यह स्वाभाविक लगता है कि मॉडल मनमाने tools पर पूरी तरह generalize नहीं करते, और ख़ासकर file editing जैसे आम कामों में training data में मौजूद tool bias का असर आता है
      उस लिहाज़ से Gemini family agentic tasks में आम तौर पर कम मज़बूत है, इसलिए शायद उसमें किसी खास tool bias भी कम हो
    • अच्छी बातें हैं
      open-weights models के benchmark की भी कोशिश की थी, लेकिन inference धीमा होने के कारण बार-बार timeout हो गया, और terminal bench में timeout बदला नहीं जा सकता था
      इससे जुड़ी शिकायत यहाँ भी लिखी है https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Gemini वाली marking GitHub README में जोड़ दी है, और average completion time कम था, लेकिन कभी-कभी output speed random तरीके से धीमी हो जाती थी, इसलिए उसे सख़्त benchmark में शामिल नहीं किया
      skills / AGENTS.md / MCP की जानकारी भी जोड़ दी है

  • मैंने अभी खुद इसे इस्तेमाल नहीं किया, लेकिन यह जिज्ञासा है कि पूरी नई harness बनाने के बजाय pi के ऊपर extension के रूप में जोड़ने का रास्ता क्यों नहीं चुना
    pi का जो extension API मैंने देखा, वह काफ़ी व्यापक लगा, और Hash anchored edits जैसी चीज़ें भी उसमें काफ़ी हद तक implement की जा सकती थीं
    project को public करने के लिए धन्यवाद, बाद में खुद देखना चाहूँगा

    • कुछ महीने पहले किसी दोपहर Cline इतना धीमा था कि बहुत झुंझलाहट हुई, फिर अंदर झाँकते-झाँकते कुछ जगहें ठीक करनी शुरू कर दीं
      फिर मैं उसमें खिंचता चला गया, और लगभग 70 हज़ार lines changes, 40 हज़ार lines deletions जमा होने के बाद, दो महीने में यह आज की स्थिति तक आ गया
    • इन दिनों local LLM और नए harnesses देख रहा हूँ, तो यह जानना चाहता हूँ कि Pi, OpenCode से व्यवहार में कितना बेहतर है
      और इसे सबसे अच्छे से इस्तेमाल करने के लिए कौन-सा model और customization combination बेहतर है

  • कोड देखते हुए पता चला कि telemetry https://dirac.run/v1/event पर भेजी जाती है
    ऐसा नहीं लगा कि यह खुलकर sensitive information भेज रहा है, और न ही यह malicious लगा, लेकिन API errors भी भेजे जा रहे हैं, इसलिए कुछ मामलों में sensitive content leak होने की गुंजाइश है
    ऊपर से यह opt-out है और endpoint एक solo developer चला रहा है, इसलिए व्यक्तिगत तौर पर मुझे यही वजह इसे न इस्तेमाल करने के लिए काफ़ी लगती है

    • जो telemetry मैंने verify की, वह लगभग यह थी
      dirac.run/v1/event पर machine ID, token usage, model info, events, error के पहले 500 characters, और platform info भेजे जाते हैं
      dirac.run/v1/event/decide पर feature flags हर 60 मिनट में machine ID के साथ fetch किए जाते हैं, और यह telemetry opt-out से अलग हमेशा on रहता है; code modify किए बिना इसे बंद नहीं किया जा सकता
      Web search/web fetch tools requests की details और system headers api.dirac.run के रास्ते भेजते हैं
      Model list भी, भले Anthropic provider इस्तेमाल हो, OpenRouter, HuggingFace, Groq वगैरह पर query भेजती है
    • धन्यवाद
      यह Cline fork है, इसलिए telemetry mechanism वही विरासत में मिला हिस्सा है, और बस debugging में मदद मिले इस सोच से छोड़ा गया था
      कोई malicious intent बिल्कुल नहीं है, और PII न generate किया जाता है, न store

  • harness कितना अहम है यही असली point है, और मुझे लगता है यह व्याख्या लंबे समय तक टिकेगी
    मॉडल उधार लिए जा सकते हैं, prompts भी लगभग कॉपी किए जा सकते हैं, लेकिन benchmark numbers का बड़ा हिस्सा उसके आसपास के harness से तय होता है
    उसी harness के तहत Gemini को Sonnet से बदलने से कम, उसी model में harness बदलने से ज़्यादा फ़र्क आ सकता है
    cheating-agents पर जो लेख तुमने लिंक किया, वह भी आख़िर यही कहता है; वास्तव में जो मापा जा रहा है, वह harness है, और model उस सामग्री के कच्चे आधार जैसा है
    हालाँकि context management कोई सार्वभौमिक गुण कम और मौजूदा पीढ़ी के models की कमजोरी को भरने वाली चीज़ ज़्यादा है, इसलिए कुछ generations बाद यह भी वैसे ग़ायब हो सकता है जैसे question-embedding-based RAG को tools ने पीछे छोड़ दिया

    • इसलिए ARC-AGI-3 harness इस्तेमाल करने की अनुमति नहीं देता
      मॉडल को harness खुद बनाना पड़ता है

  • बधाई, यह सचमुच बहुत अच्छी तरह बना हुआ लगता है
    पिछले कुछ हफ़्तों में मेरी तरफ़ भी harness बनाना सबसे मज़ेदार side project रहा है, और भले मैं चीज़ें अक्सर पूरी नहीं कर पाता, लेकिन खासकर दो अनुभवों पर जिज्ञासा है
    context management में पुराने tool call responses को prune करना, output truncate करना, और automatic compaction काफ़ी असरदार रहे; सब कुछ याद रखने के फ़ायदे से ज़्यादा context घटाने का फ़ायदा मिला
    हाँ, छोटे summaries हमेशा छोड़े
    और subagents की तरफ़, मैं एक ऐसा setup आज़मा रहा हूँ जहाँ main agent को लगभग कोई tools expose नहीं करता, सिर्फ़ run_agent देता हूँ, और नीचे के agents search/execute/fetch इस्तेमाल करते हैं
    अगर subagents सिर्फ़ concise summary लौटाएँ, तो ऊपर वाला context लंबे समय तक साफ़ रह सकता है; हालाँकि prompt design पर अभी और experiments चल रहे हैं

    • धन्यवाद
      अगर API caching supported है, तो pruning को जहाँ तक हो सके छेड़ना नहीं चाहिए, क्योंकि हर prune cache तोड़ देता है और 90% discount caching का फ़ायदा उड़ जाता है
      subagent Dirac में भी है, क्योंकि Cline feature को बेहतर बनाकर लिया गया है, लेकिन models के बीच delegation सीखने की क्षमता में काफ़ी फ़र्क है
      खासकर जब subagent loop में फँस जाए या लौटकर न आए, तब main agent के पास control mechanism होना बहुत ज़रूरी है

  • यह सचमुच दिलचस्प है, और harness बनाते समय मेरे अनुभव से भी अच्छी तरह मेल खाता है
    उसी model के साथ भी अभी काफ़ी बड़ी upside बाकी है
    पिछले साल Anthropic यह narrative आगे बढ़ा रहा था कि नए models के साथ harness एक साधारण tool-wrapped while loop जैसा बनता जा रहा है, लेकिन अब उल्टा लगता है
    harness की तरफ़ explore करने को बहुत कुछ है, और मेरे काम में rolling context window compaction से कहीं ज़्यादा ताकतवर साबित हुआ
    इसके ऊपर अगर persistent high-level summaries और detailed automatic feedback pipeline भी जोड़ दी जाए, तो और बेहतर होता है; हालाँकि यह तब आसान है जब agent का goal साफ़ और consistent हो

  • harness वाला point खास तौर पर दिलचस्प लगा
    जब credits लगभग ख़त्म होने लगते थे, तो छोटे model पर जाना और prompt को ज़्यादा structured करना कई बार gpt-5.4-mini को, अंदाज़े से चल रहे gpt-5.4 से बेहतर बना देता था
    इसलिए मैंने skill distillery शुरू किया, जो अच्छे agent workflow ideas को छोटे, inspectable और installable skills में बदलता है https://github.com/ouatu-ro/skill-distillery
    पहला skill dirac-workflow है, जो Dirac के structured code workflow पर आधारित है; यह Dirac की clone नहीं है, और इसमें runtime, persistent AST index, hash-anchor editing engine, या benchmark harness नहीं है
    इसकी जगह मैंने छोटे AST helpers और workflow discipline को portable skill के रूप में रखा है, और Dirac repository पर इसे लागू करके एक छोटा report भी जोड़ा है
    मूल लेखक के नज़रिए से यह जानना चाहता हूँ कि prompts और tools कितने representative हैं
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • मैं Kimi 2.6 और Dirac के साथ एक Rust codebase refactor कर रहा हूँ
    दिशा Clean Architecture को और मज़बूत करने की है, और काम का दायरा Beads epic और उसके sub-issues में व्यवस्थित किया गया है
    Planning gpt5.5 से की गई थी और completion verification भी gpt5.5 ही कर रहा है
    बड़े codebase refactoring में Dirac, OpenCode से ज़्यादा productive रहा, जबकि OpenCode ने .rs files बिगाड़ दीं और उन्हें वापस revert करना पड़ा

    • क्या gpt-5.5 के साथ भी Dirac इस्तेमाल कर रहे हो?