dirac-run/dirac

 (github.com/dirac-run)
1 puan yazan GN⁺ 2 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Uzun bağlamlarda akıl yürütme performansının dalgalanması sorununu azaltmak için yoğun bağlam kürasyonu ve araç verimliliğine karşı performans optimizasyonu üzerine odaklanan açık kaynaklı bir kodlama ajanı
  • gemini-3-flash-preview baz alınarak Terminal-Bench-2 65.2% elde etti ve herkese açık GitHub depolarındaki karmaşık refaktör görevlerinden 8 tanesinde 8/8 başarı sağladı
  • Hash-Anchored Edits, Multi-File Batching ve yapı farkındalıklı düzenlemeyi birleştirerek birden fazla dosyayı az sayıda gidiş-dönüşle ele alıyor; TypeScript, Python ve C++ gibi dillerin sözdizimsel yapısını yansıtarak değişiklik yapıyor
  • Dosya okuma-yazma, terminal komutları ve headless browser desteği sunuyor; ayrıca onay tabanlı iş akışı ile Plan Mode, Yolo Mode ve iş geçmişini sürdürme gibi CLI akışlarını birlikte sağlıyor
  • Ortalama $0.18 maliyet ve rakip araçlara kıyasla %64.8 maliyet tasarrufu vurgulanıyor; benchmark'a özel bilgi olmadan gerçek dünyaya dönük görevlerde hem performansı hem maliyeti iyileştirmesi özellikle öne çıkıyor

Temel performans

  • Benchmark sonuçları

    • 8 görevin tamamında 8/8 doğru sonuç elde etti; karşılaştırma grubunda yalnızca Opencode aynı şekilde 8/8 seviyesine ulaştı
    • Ortalama maliyet $0.18 ile Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38, Roo $0.60 değerlerinden daha düşük
    • README'ye göre Dirac, rakip araçlara kıyasla %64.8 daha ucuz ve maliyet tarafında 2.8 kat tasarruf sağlıyor
    • Ayrıntılı görev açıklamaları ve metodolojiye evals/README.md üzerinden ulaşılabiliyor

  • Görev bazlı maliyet özellikleri

    • transformers, vscode, django depolarını içeren her bir refaktör görevinde çoğunlukla en düşük ya da en düşükler arasında maliyet kaydediyor
    • Örneğin transformers içindeki DynamicCache görevi $0.13, django içindeki datadict görevi $0.08, vscode içindeki sendRequest görevi $0.25 seviyesinde
    • Bazı rakip araçlar Incomplete ya da Failure sonucu alırken, Dirac tabloda yer alan 8 görevin tamamında Success olarak işaretlenmiş

Yaklaşım ve tasarım

  • Bağlam ve düzenleme stratejisi

    • Hash-Anchored Edits, kararlı satır hash'lerini temel alarak değişiklik konumunu hedefliyor ve geleneksel satır numarası tabanlı düzenlemenin "lost in translation" sorunundan kaçınıyor
    • Multi-File Batching, birden fazla dosyayı tek bir LLM gidiş-dönüşünde okuyup düzenleyerek gecikmeyi ve API maliyetini azaltıyor
    • High-Bandwidth Context optimizasyonu, yalnızca en ilgili bilgiyi tutarak token israfını azaltıyor ve ajanı hafif ve hızlı tutuyor

  • Yapı farkındalıklı düzenleme

    • Yerleşik AST-Native Precision ile TypeScript, Python, C++ gibi dillerin sözdizimsel yapısını anlayarak çalışıyor
    • Fonksiyon çıkarma veya sınıf refaktörü gibi yapısal manipülasyonları %100 doğrulukla yapabildiğini belirtiyor

  • Araç kullanım modeli

    • Dosya okuma ve yazma, terminal komutu çalıştırma ve headless browser kullanımı gibi yetenekleri destekliyor
    • İş akışı, kullanıcının kontrolü elinde tutması için onay tabanlı iş akışını koruyacak şekilde tasarlanmış
    • Model desteği, yerel araç çağrısı yapabilen modellerle sınırlı; gerekçe olarak güvenilirlik ve performans gösteriliyor
    • README'ye göre MCP desteklenmiyor

Kullanım şekli ve özelleştirme

  • Proje bazlı davranış kontrolü

    • AGENTS.md dosyasıyla proje bazlı talimatlar uygulanarak davranış özelleştirilebiliyor
    • .ai, .claude, .agents dizinleri otomatik olarak okunuyor ve Claude skills birlikte kullanılabiliyor

  • CLI kullanım akışı

    • dirac auth ile kimlik doğrulaması yaptıktan sonra dirac "Analyze the architecture of this project" gibi komutlarla görev çalıştırılabiliyor
    • dirac -p "prompt", stratejiyi önce görmek için kullanılan Plan Mode akışı
    • dirac -y "prompt", tüm eylemleri otomatik onaylayan Yolo Mode akışı
    • git diff | dirac "Review these changes" gibi pipe girişiyle bağlam doğrudan aktarılabiliyor
    • dirac history ile önceki işler görüntülenip kaldığı yerden devam edilebiliyor

  • VS Code entegrasyonu

    • VS Code Marketplace üzerinden eklenti kurulabiliyor
    • VS Code kenar çubuğu açılıp Anthropic, OpenAI, OpenRouter gibi tercih edilen AI sağlayıcısı ayarlandıktan sonra yeni bir görev başlatılıyor

Çalışma ortamı ve sağlayıcı entegrasyonu

  • API anahtarları ve ortam değişkenleri

    • Kimlik doğrulama adımını atlamak için ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN gibi değişkenler ortam değişkeni olarak verilebiliyor
    • Tam liste src/shared/storage/env-config.ts içinde yer alıyor

  • AWS Bedrock desteği

    • AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN ile birlikte AWS_BEDROCK_MODEL veya AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN ayarlanırsa otomatik olarak Bedrock provider'ına geçiliyor
    • aws-vault ile birlikte kullanılabilecek çalıştırma örneği de veriliyor
    • Sonnet 4.6 ve üzeri gibi yeni Claude modelleri için us., eu., ap. gibi cross-region inference profile prefix gerekiyor; desteklenen model ID'leri için AWS docs bağlantısına yönlendiriliyor

Proje arka planı

İlgili okumalar

1 yorum

 
GN⁺ 2 일 전
Hacker News görüşleri

  • Dirac’ta ilgimi çeken şeyler şunlardı
    Dosyaları Hash-Anchored edits’in optimize edilmiş bir sürümüyle düzenliyor ve hangi kodun bağlama alınacağına karar vermek için dilin AST’sini kullanıyor, böylece büyük kod dosyalarının tamamını okumak gerekmiyor
    Tüm işleri batch halinde gruplayıp çok sayıda okuma/düzenlemeyi aynı anda işliyor; model gerekirse anlık analiz için bash/python/perl betiklerini doğrudan çalıştırabiliyor
    Ayrıca bağlamı oldukça dikkatli yönetiyor; modelin bir sonraki adımda neredeyse kesin isteyeceği bilgileri önceden ekleyerek güncelliyor

    • AST’nin kod düzenleme ya da değişiklik kapsamı çıkarımı için neden daha yaygın kullanılmadığını hep merak etmişimdir
      Eskiden okuduğum bir yazıda grep’in de benzer ölçüde etkili olduğu söyleniyordu; o bağlamda bu da belli ölçüde mantıklı gelmişti
    • Anchor tabanlı düzenleme, yeni anchor’ların bağlama enjekte edilmesini gerektiriyor ve Dirac da bunu diff ile yapıyor gibi görünüyor; bu yüzden token bazında search and replace’ten gerçekten daha verimli olup olmadığından emin değilim
      Hash tek bir token olsa bile durum değişmiyor ve kod yazmaktan çok okunduğu için biriken maliyet de büyüyor
      Daha önce daha uzun stable anchors ile denediğimde de hatta bir gerileme gibi hissettirmişti; Dirac’ın verimi daha çok temelde yalnızca dosya iskeletini göstermesinden geliyor gibi duruyor
    • Batches all operationsın ne olduğunu anlamadığım için kaynağa baktım; modelin paralel tool çağrılarını iyi yapmasını beklemek yerine, tool API’nin doğrudan birden fazla hedefi liste olarak alacak şekilde tasarlandığı anlamına geliyor gibi göründü
      Benim deneyimimde de modeller çok sayıda paralel çağrıyı tek seferde yapma konusunda iyi değil; özellikle daha zayıf modellerde bu eğilim daha belirgin
    • SOTA modellerde token yakmak yerine, dosya düzenlemeye özel çok ucuz bir uzman model kullanmak daha iyi olabilir diye düşünüyorum
      Üst seviye modelin yalnızca daha ucuz düzenleme modelini üretip çağırması gibi bir yaklaşım da mümkün görünüyor
    • Bağlama alınacak şeyi dilin AST’siyle belirliyorsa, bunun sonuçta yalnızca parser’ı olan dillerde çalışan bir yapı olup olmadığını merak ediyorum

  • AI harness’ın performansı ne kadar etkilediği gerçekten çok ilginç
    Google’ın resmi sonucundaki %48’den %65’e çıkmak devasa bir fark; model karşılaştırmasını çok görüyoruz ama aynı modelle yalnızca harness karşılaştırmasını neredeyse hiç görmüyoruz
    Aynı model üzerinde harness performansını karşılaştıran bir leaderboard olup olmadığını merak ediyorum

    • Muhtemelen tüm model+harness Kartezyen çarpımını karşılaştırmak gerekir
    • En çok alıntılanan şey terminal bench 2.0, ama burada da cheating şüphesi ve benchmaxxing sorunları kaçınılmış değil
      Oldukça şaşırtıcı biçimde Opus 4.6’da Claude Code sonuncu çıkıyor; bu Claude Code’un sınırı da olabilir, benchmark’ın bize söylediği bir şey de olabilir
    • Geleceğin insan benzeri merkezi bir zeka yerine, daha çok ahtapot benzeri dağıtık zekaya benzeyebileceğini de düşünüyorum
      O zaman esas mesele modeli değil, harness’ın kendisini daha akıllı hale getirmek olur
    • Aslında terminal-bench’in yaptığı da sonuçta bu değil mi diye düşündürtüyor
    • Son birkaç aydır aynı yerel modelle bizzat test ettiğimde, benim ortamımda Claude Code açık şekilde OpenCode’dan iyiydi ve OpenCode da Codex’ten iyiydi

  • Eğer benchmark’tan söz ediyorsak, en azından başka bir model ailesinden bir tane daha eklemek gerekir ki genellenebilir olup olmadığını anlayalım
    Maliyet açısından Minimax 2.7 makul görünüyor; o zamana kadar bunun Gemini 3 Flash’a aşırı uyarlanmış bir sonuç olup olmadığını söylemek zor
    Landing page’de de mevcut sayıların tamamen Gemini 3 Flash tabanlı olduğu açıkça yazılmalı; ayrıca daha ucuz olmasının aynı model için daha hızlı tamamlanma anlamına geldiği iddia ediliyorsa, tamamlama süresi de benchmark’a eklenmeli
    Bunun yanında skills, iç içe AGENTS.md dosyaları ve MCP desteği de geçiş yapmayı düşünenler için önemli

    • Minimax 2.7 ile bizzat denedim; düzenleme araçlarından pek hoşlanmadı ve çok geçmeden dosyaları sed ile değiştirmeye kaydı
      Modelin keyfi araçlara kusursuz biçimde genellenememesi doğal görünüyor; özellikle dosya düzenleme gibi yaygın görevlerde eğitim verisindeki araç önyargılarını taşıması beklenir
      Bu açıdan Gemini ailesi ajan işlerinde genel olarak daha zayıf olduğundan, belki de belirli araç önyargıları daha az olabilir
    • İyi noktalardı
      open-weights modeller için de benchmark denedim ama çıkarım yavaştı ve sürekli timeout’a takıldı; terminal bench tarafında timeout değiştirilemiyordu
      İlgili şikayetimi buraya da yazdım https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Gemini ibaresini GitHub README’sine ekledim; ortalama tamamlama süresi daha kısaydı ama çıktı hızının rastgele yavaşladığı durumlar olduğu için bunu katı bir benchmark metriği olarak eklemedim
      skills / AGENTS.md / MCP bilgisini de ekledim

  • Henüz bizzat kullanmadım ama neden sıfırdan tamamen yeni bir harness yazmak yerine bunu pi üzerinde bir eklenti olarak kurmayı seçmediğini merak ediyorum
    Gördüğüm kadarıyla pi’nin extension API’si oldukça geniş ve Hash anchored edits gibi şeyler de rahatlıkla uygulanabilirmiş gibi duruyordu
    Projeyi açık kaynak yaptığı için teşekkürler; ileride bizzat incelemeyi düşünüyorum

    • Birkaç ay önce bir öğleden sonra Cline aşırı yavaştı ve bu beni çok bunaltmıştı; içini kurcalamaya başlayınca birkaç yeri düzeltmeye giriştim
      Sonra giderek içine çekildim; yaklaşık 70 bin satır değişiklik ve 40 bin satır silme birikince, iki ay sonra bugünkü hale geldi
    • Bu aralar local LLM’leri ve yeni harness’ları inceliyorum; Pi’nin gerçekte OpenCode’dan ne kadar iyi olduğunu merak ediyorum
      En verimli kullanım için hangi model ve özelleştirme kombinasyonunun iyi olduğunu da öğrenmek isterim

  • Koda bakarken telemetry’nin https://dirac.run/v1/event adresine gönderildiğini fark ettim
    Açıkça hassas bilgi gönderiyor gibi görünmüyor ve kötü niyetli izlenim vermiyor, ama API hatalarını da gönderdiği için bazı durumlarda hassas içerik sızma ihtimali olabilir
    Üstelik bunun tek geliştiricinin işlettiği bir endpoint’e opt-out şeklinde yapılması bana oldukça ürkütücü geldi; kişisel olarak sırf bu yüzden kullanamam

    • Tespit ettiğim telemetry kabaca şunlardı
      dirac.run/v1/event adresine machine ID, token kullanımı, model bilgisi, olaylar, hataların ilk 500 karakteri ve platform bilgisi gönderiliyor
      dirac.run/v1/event/decide üzerinden özellik bayrakları her 60 dakikada bir machine ID ile birlikte sorgulanıyor; bu telemetry opt-out’tan bağımsız olarak her zaman açık ve kodu değiştirmeden kapatılamıyor
      Web arama/web fetch araçları istek içeriğini ve sistem header’larını api.dirac.run üzerinden iletiyor
      Model listesi de Anthropic provider kullanılsa bile OpenRouter, HuggingFace, Groq gibi servislere sorgu gönderiyor
    • Teşekkürler
      Bu bir Cline fork olduğu için telemetry mekanizmasını aynen devraldığı kısımlar var; yalnızca hata ayıklamaya yardımcı olur mu diye bırakmıştım
      Kesinlikle kötü niyet yok ve PII üretmiyor ya da saklamıyorum

  • Asıl vurucu nokta harness’ın ne kadar önemli olduğu ve bence bu kalıcı bir çıkarım
    Modeller kiralanabilir ve prompt’lar da benzer şekilde kopyalanabilir, ama benchmark skorunun önemli bir kısmını çevresindeki harness belirliyor
    Aynı harness altında Gemini’den Sonnet’e geçmenin etkisinden daha büyük bir etkiyi, aynı modelle harness değiştirince görebilirsiniz
    Link verdiğin cheating-agents yazısı da sonuçta aynı şeyi söylüyor; gerçekte ölçülen şey harness, model ise daha çok ham malzeme gibi
    Yine de context management, evrensel bir özellikten çok mevcut nesil modellerin zayıflıklarını telafi eden bir şey gibi; birkaç nesil sonra araçların soru embedding tabanlı RAG’i geride bırakması gibi bu da ortadan kalkabilir

    • Bu yüzden ARC-AGI-3 harness kullanımına izin vermiyor
      Modelin harness’ı kendisinin kurması gerekiyor

  • Tebrikler, gerçekten çok iyi yapılmış görünüyor
    Son birkaç haftadır benim için de harness geliştirmek en eğlenceli yan projeydi; her seferinde bitiremiyorum ama özellikle iki deneyimi merak ediyorum
    Bağlam yönetimi tarafında eski tool call yanıtlarını budamak, çıktıları kırpmak ve otomatik compaction epey iyi sonuç verdi; her şeyi hatırlamanın faydasından çok bağlamı küçültmenin faydası daha büyüktü
    Yine de kısa özetleri her zaman bıraktım
    Ayrıca subagents tarafında, ana agente neredeyse hiç araç göstermeyip yalnızca run_agent vererek; arama/çalıştırma/fetch işlerini alt ajanların yapması yönünde denemeler yapıyorum
    Alt ajanlar yalnızca kısa özetler döndürürse üst bağlamın uzun süre temiz kalacağını düşünüyorum, ama prompt tasarımında hâlâ daha çok deneme yapıyorum

    • Teşekkürler
      API caching destekleniyorsa pruning’e mümkün olduğunca dokunmamak daha iyi; çünkü her prune işlemi cache’i bozuyor ve %90 indirimli caching avantajını ortadan kaldırıyor
      subagent tarafında Dirac, Cline özelliğinin geliştirilmiş bir sürümünü devraldı ama modeller arasında delegation öğrenimi çok tutarsız olduğu için sonuçlar değişken
      Özellikle alt ajanın döngüye girmesi ya da geri dönmemesi durumlarına karşı, ana ajanın kontrol mekanizmasına kesinlikle ihtiyacı var

  • Bu gerçekten çok ilginç ve benim harness geliştirirken yaşadığım deneyimle de çok örtüşüyor
    Aynı modelle bile hâlâ kayda değer bir yukarı potansiyel olduğunu düşünüyorum
    Geçen yıl Anthropic, yeni modeller geldikçe harness’ın araçlarla çevrili basit bir while loop’a yaklaştığı yönünde bir anlatı itiyordu; şimdi ise sanki tam tersine gidiyoruz
    Harness tarafında keşfedilecek çok şey var ve benim işlerimde rolling context window, compaction’dan çok daha güçlü oldu
    Buna kalıcı üst düzey özetler ve ayrıntılı otomatik geri bildirim hattı da eklenince daha da iyi oluyor; tabii bunu uygulamak ajan hedefi ne kadar net ve tutarlıysa o kadar kolay

  • Özellikle harness noktası ilgimi çekti
    Kredim neredeyse bittiğinde daha küçük bir modele geçip prompt’u daha yapılandırılmış hale getirince, bazen gpt-5.4-mini sezgisel kullanılan gpt-5.4’ten daha iyi performans veriyordu
    Bu yüzden iyi ajan iş akışı fikirlerini küçük, denetlenebilir ve kurulabilir skills’lere dönüştüren skill distillery adlı bir şey başlattım https://github.com/ouatu-ro/skill-distillery
    İlki, Dirac’ın yapısal kod iş akışını temel alan dirac-workflow; bu bir Dirac klonu değil, içinde runtime, kalıcı AST indeksi, hash-anchor düzenleme motoru ya da benchmark harness yok
    Bunun yerine yalnızca küçük AST yardımcıları ve taşınabilir bir skill olarak iş akışı disiplini var; ayrıca bunu doğrudan Dirac deposuna uyguladığım kısa bir rapor da ekledim
    Orijinal yazar olarak prompt’ların ve araçların temsil gücü hakkında geri bildirimini almak isterim
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Kimi 2.6 ve Dirac ile bir Rust kod tabanını yeniden düzenliyorum
    Hedef daha güçlü bir Clean Architecture ve iş kapsamını Beads epic ile alt issue’lar halinde düzenledim
    Planı gpt5.5 ile yaptım ve tamamlanma doğrulamasını da gpt5.5 üstleniyor
    Büyük kod tabanı refactor’larında Dirac, OpenCode’dan daha üretken oldu; OpenCode ise .rs dosyalarını bozup geri almama neden olmuştu

    • gpt-5.5 ile birlikte Dirac da kullanıyor musun?