dirac-run/dirac

 (github.com/dirac-run)
1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah agen coding open-source yang berfokus pada kurasi konteks yang rapat dan optimasi performa dibanding efisiensi alat untuk mengurangi masalah goyahnya performa penalaran pada konteks panjang
  • Berdasarkan gemini-3-flash-preview, proyek ini mencatat Terminal-Bench-2 65.2% dan meraih 8/8 sukses pada 8 tugas refaktorisasi kompleks di repositori GitHub publik
  • Dengan menggabungkan Hash-Anchored Edits, Multi-File Batching, dan pengeditan yang sadar struktur, alat ini menangani banyak file dengan sedikit bolak-balik serta memodifikasi kode dengan mempertimbangkan struktur sintaks bahasa seperti TypeScript, Python, dan C++
  • Mendukung baca-tulis file, perintah terminal, dan browser headless, serta menyediakan alur CLI seperti workflow berbasis persetujuan, Plan Mode, Yolo Mode, dan melanjutkan riwayat pekerjaan
  • Menonjolkan biaya rata-rata $0.18 dan penghematan biaya 64.8% dibanding alat pesaing, dengan peningkatan performa dan biaya pada tugas dunia nyata tanpa informasi khusus benchmark

Performa inti

  • Hasil benchmark

    • Mencatat 8/8 jawaban benar di seluruh 8 tugas, dan di antara pembanding hanya Opencode yang mencapai 8/8 yang sama
    • Biaya rata-rata $0.18, lebih rendah daripada Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38, dan Roo $0.60
    • README menyebut Dirac 64.8% lebih murah dibanding alat pesaing, dengan penghematan 2.8x dari sisi biaya
    • Deskripsi tugas rinci dan metodologi tersedia di evals/README.md

  • Karakteristik biaya per tugas

    • Pada tiap tugas refaktorisasi, termasuk repositori transformers, vscode, dan django, proyek ini mencatat biaya terendah atau termasuk yang terendah pada sebagian besar kasus
    • Misalnya, tugas DynamicCache di transformers berada di $0.13, tugas datadict di django di $0.08, dan tugas sendRequest di vscode di $0.25
    • Beberapa alat pesaing mencatat Incomplete atau Failure, tetapi Dirac ditandai Success pada seluruh 8 tugas di tabel

Pendekatan dan desain

  • Strategi konteks dan pengeditan

    • Dengan Hash-Anchored Edits, lokasi modifikasi dibidik berdasarkan hash baris yang stabil sehingga menghindari masalah "lost in translation" pada pengeditan tradisional berbasis nomor baris
    • Dengan Multi-File Batching, beberapa file dibaca dan dimodifikasi dalam satu kali bolak-balik LLM untuk mengurangi latensi dan biaya API
    • Optimasi High-Bandwidth Context mempertahankan hanya informasi yang paling relevan untuk mengurangi pemborosan token dan menjaga agen tetap ringan serta cepat

  • Pengeditan sadar struktur

    • Memiliki AST-Native Precision bawaan untuk bekerja dengan memahami struktur sintaks bahasa seperti TypeScript, Python, dan C++
    • Disebut mampu melakukan manipulasi struktural seperti ekstraksi fungsi atau refaktorisasi kelas dengan akurasi 100%

  • Model penggunaan alat

    • Mendukung baca-tulis file, eksekusi perintah terminal, dan penggunaan browser headless
    • Alur kerjanya mempertahankan workflow berbasis persetujuan agar pengguna tetap memegang kendali
    • Dukungan model dibatasi pada kasus dengan native tool calling untuk alasan keandalan dan performa
    • Berdasarkan README, MCP tidak didukung

Cara penggunaan dan kustomisasi

  • Kontrol perilaku per proyek

    • File AGENTS.md dapat digunakan untuk menerapkan instruksi khusus per proyek dan menyesuaikan perilaku
    • Direktori .ai, .claude, dan .agents dibaca otomatis sehingga Claude skills juga dapat dimanfaatkan

  • Alur penggunaan CLI

    • Setelah autentikasi dengan dirac auth, tugas dapat dijalankan seperti dirac "Analyze the architecture of this project"
    • dirac -p "prompt" adalah cara untuk lebih dulu meninjau strategi lewat Plan Mode
    • dirac -y "prompt" menggunakan Yolo Mode untuk menyetujui semua tindakan secara otomatis
    • Konteks juga bisa diberikan langsung melalui input pipe seperti git diff | dirac "Review these changes"
    • Dengan dirac history, pekerjaan sebelumnya bisa dilihat dan dilanjutkan kembali

  • Integrasi VS Code

    • Ekstensi dapat dipasang dari VS Code Marketplace
    • Alurnya adalah membuka sidebar VS Code, mengatur penyedia AI pilihan seperti Anthropic, OpenAI, atau OpenRouter, lalu memulai tugas baru

Lingkungan eksekusi dan integrasi penyedia

  • API key dan variabel lingkungan

    • Untuk melewati tahap autentikasi, proyek ini dapat menerima ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN, dan lainnya melalui variabel lingkungan
    • Daftar lengkap tersedia di src/shared/storage/env-config.ts

  • Dukungan AWS Bedrock

    • Jika AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, serta AWS_BEDROCK_MODEL atau AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN diatur, maka akan otomatis beralih ke provider Bedrock
    • Tersedia contoh eksekusi yang dapat digunakan bersama aws-vault
    • Model Claude terbaru seperti Sonnet 4.6 atau lebih baru memerlukan cross-region inference profile prefix seperti us., eu., ap., dan untuk ID model yang didukung diarahkan ke AWS docs

Latar belakang proyek

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Opini Hacker News

  • Hal yang menarik dari Dirac bagiku adalah bagian-bagian seperti ini
    Ia mengedit file dengan versi optimal dari Hash-Anchored edits, lalu memakai AST bahasa untuk menentukan kode mana yang dimasukkan ke konteks, jadi tidak perlu membaca seluruh file kode yang besar
    Semua pekerjaan dibundel dalam batch untuk menangani banyak operasi baca/edit sekaligus, dan bila perlu model bahkan menjalankan skrip bash/python/perl secara langsung untuk analisis seketika
    Selain itu, konteks dikelola dengan cukup cermat, diperbarui dengan cara menyisipkan lebih dulu informasi yang hampir pasti akan diminta model berikutnya

    • Aku selalu penasaran kenapa AST tidak dipakai lebih luas untuk pengeditan kode atau inferensi cakupan perubahan
      Dulu ada tulisan yang bilang grep juga sama efektifnya, dan dalam konteks itu pernyataan tersebut masih cukup masuk akal
    • Pengeditan berbasis anchor perlu menyuntikkan anchor baru ke konteks, dan Dirac tampaknya menanganinya lewat diff, jadi aku kurang yakin apakah ini benar-benar lebih efisien daripada search and replace jika dilihat dari token
      Walaupun hash-nya hanya satu token, kode lebih sering dibaca daripada ditulis, jadi biaya akumulasinya juga besar
      Saat dulu bereksperimen dengan stable anchors yang lebih panjang, rasanya justru seperti mundur, dan efisiensi Dirac tampaknya lebih banyak datang dari hanya menampilkan kerangka file secara default
    • Aku tidak paham maksud Batches all operations, jadi aku melihat source-nya, dan tampaknya itu berarti tool API-nya sendiri dirancang agar menerima daftar banyak target, alih-alih berharap model akan pandai melakukan pemanggilan tool paralel
      Dari pengalamanku juga, model tidak terlalu mau melakukan banyak panggilan paralel sekaligus, dan kecenderungan itu makin kuat pada model yang lebih lemah
    • Kurasa akan lebih baik memakai model khusus yang sangat murah untuk edit file daripada membakar token di model SOTA
      Sepertinya juga memungkinkan agar model kelas atas hanya membuat lalu memanggil model edit yang lebih murah
    • Kalau konteks yang diambil ditentukan lewat AST bahasa, aku jadi penasaran apakah pada akhirnya arsitektur ini hanya bekerja untuk bahasa yang punya parser

  • Sangat menarik melihat seberapa besar pengaruh AI harness terhadap performa
    Naik dari 48% ke 65% dibanding hasil resmi Google adalah perbedaan yang sangat besar, tapi meskipun kita sering melihat perbandingan model, hasil yang membandingkan harness dengan model yang sama hampir tidak pernah terlihat
    Aku penasaran apakah ada leaderboard yang membandingkan performa harness dengan model yang sama

    • Mungkin memang harus membandingkan seluruh hasil kali Kartesius dari model+harness
    • Yang paling sering dikutip mungkin terminal bench 2.0, tapi di sini pun tetap tidak lolos dari dugaan cheating dan masalah benchmaxxing
      Cukup mengejutkan, di Opus 4.6 Claude Code justru berada di posisi terakhir, dan itu bisa berarti keterbatasan Claude Code atau memang sesuatu yang dikatakan benchmark itu sendiri
    • Aku juga jadi berpikir masa depan mungkin lebih dekat ke kecerdasan terdistribusi berbentuk gurita daripada kecerdasan terpusat yang humanoid
      Kalau begitu, inti utamanya jadi membuat harness itu sendiri lebih cerdas daripada sekadar modelnya
    • Bukankah itu pada akhirnya memang yang dilakukan terminal-bench?
    • Dari tes langsung selama beberapa bulan terakhir dengan model lokal yang sama, di lingkunganku Claude Code jelas lebih baik daripada OpenCode, dan OpenCode lebih baik daripada Codex

  • Kalau ini benchmark, setidaknya perlu memasukkan satu model dari keluarga lain supaya bisa tahu apakah hasilnya tergeneralisasi
    Kalau mempertimbangkan biaya, Minimax 2.7 tampak layak, dan sebelum itu sulit menilai apakah hasilnya overfit ke Gemini 3 Flash
    Di landing page juga perlu ditegaskan bahwa semua angka saat ini berbasis Gemini 3 Flash, dan kalau "lebih murah" pada model yang sama juga berarti "lebih cepat", mungkin waktu penyelesaian sebaiknya ikut dimasukkan ke benchmark
    Selain itu, dukungan untuk skills, AGENTS.md bertingkat, dan MCP juga penting bagi orang yang sedang mempertimbangkan migrasi

    • Aku sempat menjalankannya langsung dengan Minimax 2.7, dan model ini tampaknya sangat tidak suka tool edit, cepat sekali jatuh ke pola memodifikasi file dengan sed
      Rasanya wajar kalau model tidak bisa menggeneralisasi sempurna ke tool arbitrer, dan khusus untuk pekerjaan umum seperti edit file, bias terhadap tool yang ada di data latih tampaknya memang akan terasa
      Dalam arti itu, keluarga Gemini biasanya kurang kuat pada pekerjaan agen, jadi justru mungkin bias tool spesifiknya lebih kecil
    • Poin-poin yang bagus
      Aku juga mencoba benchmark model open-weights, tetapi inferensinya lambat sehingga terus kena timeout, dan di terminal bench timeout itu tidak bisa diubah
      Keluhan terkait juga kutulis di sini https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Penandaan Gemini sudah kuterapkan di GitHub README, dan waktu penyelesaian rata-ratanya memang lebih singkat, tetapi karena kecepatan output kadang melambat secara acak, aku tidak memasukkannya sebagai benchmark yang ketat
      Informasi skills / AGENTS.md / MCP juga sudah kutambahkan

  • Aku belum mencobanya langsung, tetapi aku penasaran kenapa tidak memilih menumpangkan ekstensi di atas pi saja daripada membangun harness baru dari nol
    API extension pi yang pernah kulihat cukup luas, dan hal seperti Hash anchored edits tampaknya cukup mungkin diimplementasikan
    Terima kasih sudah membuka proyeknya; nanti aku ingin melihatnya langsung

    • Beberapa bulan lalu, pada suatu sore, aku frustrasi karena Cline terlalu lambat, lalu mulai melihat ke dalamnya dan memperbaiki beberapa bagian
      Dari sana aku makin tersedot, dan setelah terkumpul sekitar 70 ribu baris perubahan serta 40 ribu baris penghapusan, dua bulan kemudian jadilah keadaan sekarang
    • Belakangan aku juga melihat local LLM dan harness-harness baru, jadi aku penasaran seberapa jauh Pi benar-benar lebih baik daripada OpenCode dalam praktik
      Aku juga ingin tahu kombinasi model dan kustomisasi seperti apa yang paling bagus untuk memaksimalkannya

  • Saat melihat kodenya, aku menemukan bahwa telemetry dikirim ke https://dirac.run/v1/event
    Tidak terlihat seperti mengirim informasi sensitif secara terang-terangan dan juga tidak tampak berniat jahat, tetapi karena error API juga ikut dikirim, tetap ada kemungkinan isi sensitif bocor dalam situasi tertentu
    Ditambah lagi ini endpoint yang dijalankan pengembang tunggal dan memakai model opt-out, jadi secara pribadi titik ini cukup menakutkan dan membuatku tidak bisa memakainya

    • Telemetry yang kukonfirmasi kira-kira seperti ini
      Ke dirac.run/v1/event, ia mengirim machine ID, penggunaan token, informasi model, event, 500 karakter pertama dari error, dan informasi platform
      Di dirac.run/v1/event/decide, ia mengambil feature flag setiap 60 menit bersama machine ID, dan ini selalu aktif terlepas dari telemetry opt-out serta tidak bisa dimatikan tanpa mengubah kode
      Tool pencarian web/web fetch mengirim isi permintaan dan header sistem melalui api.dirac.run
      Daftar model juga melakukan query ke OpenRouter, HuggingFace, Groq, dan lainnya meskipun memakai provider Anthropic
    • Terima kasih
      Ini adalah fork Cline, jadi ada bagian yang mewarisi mekanisme telemetry apa adanya, dan aku hanya membiarkannya karena mungkin membantu debugging
      Sama sekali tidak ada niat jahat, dan aku juga tidak membuat atau menyimpan PII

  • Seberapa penting harness itulah poin kuncinya, dan menurutku ini akan menjadi interpretasi yang bertahan lama
    Model bisa dipinjam, prompt juga bisa direplikasi dengan cukup mirip, tetapi sebagian besar angka benchmark ditentukan oleh harness di sekelilingnya
    Di bawah harness yang sama, mengganti Gemini menjadi Sonnet bisa jadi memberi perubahan lebih kecil daripada mengganti harness pada model yang sama
    Tulisan tentang cheating-agents yang kamu tautkan juga pada akhirnya bicara soal hal yang sama; yang benar-benar diukur adalah harness, sedangkan model lebih dekat ke bahan mentah dasarnya
    Hanya saja context management tampaknya bukan sifat universal, melainkan lebih seperti penopang kelemahan model generasi saat ini, jadi beberapa generasi lagi mungkin menghilang seperti tool yang menyingkirkan RAG berbasis embedding pertanyaan

    • Itulah sebabnya ARC-AGI-3 tidak mengizinkan penggunaan harness
      Model harus membuat harness-nya sendiri secara langsung

  • Selamat, kelihatannya ini dibuat dengan sangat baik
    Selama beberapa minggu terakhir, membuat harness juga menjadi side project paling menyenangkan bagiku, dan walaupun aku tidak pernah benar-benar menuntaskannya, ada dua pengalaman yang terutama ingin kutanyakan
    Dalam manajemen konteks, memangkas respons tool call lama, memotong output, dan compaction otomatis bekerja cukup baik, dan keuntungan dari memperkecil konteks lebih besar daripada keuntungan mengingat semuanya
    Sebagai gantinya, aku selalu menyisakan ringkasan singkat
    Lalu di sisi subagents, aku hampir tidak mengekspos tool ke agen utama dan hanya memberinya run_agent, lalu membiarkan agen bawahan memakai search/execute/fetch
    Kalau agen bawahan hanya mengembalikan ringkasan yang ringkas, konteks tingkat atas mestinya bisa tetap bersih lebih lama, tetapi desain prompt-nya masih terus kucoba

    • Terima kasih
      Jika mendukung API caching, sebaiknya pruning sebisa mungkin jangan disentuh, karena setiap kali prune dilakukan cache akan pecah dan keuntungan cache diskon 90% itu hilang
      Soal subagent, Dirac juga mewarisi peningkatan fitur Cline, tetapi tiap model punya variasi besar karena tidak semuanya terlatih mendelegasikan dengan baik
      Khususnya saat agen bawahan masuk loop atau tidak kembali, mekanisme agar agen utama bisa mengendalikan situasi itu memang wajib ada

  • Ini benar-benar menarik, dan sangat cocok dengan pengalamanku saat membuat harness
    Bahkan dengan model yang sama, menurutku masih ada potensi peningkatan yang besar
    Tahun lalu Anthropic mendorong narasi bahwa makin baru modelnya, harness makin menyerupai while loop sederhana yang membungkus tool, tetapi sekarang rasanya justru bergerak ke arah sebaliknya
    Masih terlalu banyak yang bisa dieksplorasi di sisi harness, dan dalam pekerjaanku rolling context window jauh lebih kuat daripada compaction
    Jika ditambah ringkasan tingkat atas yang persisten dan pipeline umpan balik otomatis yang rinci, hasilnya bisa lebih baik lagi, walau tentu ini lebih mudah diterapkan ketika tujuan agen jelas dan konsisten

  • Poin harness khususnya menarik bagiku
    Saat kredit hampir habis, kalau diturunkan ke model yang lebih kecil dan prompt dibuat lebih terstruktur, kadang gpt-5.4-mini justru bekerja lebih baik daripada gpt-5.4 yang mengandalkan insting
    Karena itu aku memulai skill distillery, yang memindahkan ide workflow agen yang bagus menjadi skills yang kecil, dapat diperiksa, dan dapat dipasang https://github.com/ouatu-ro/skill-distillery
    Yang pertama adalah dirac-workflow, berdasarkan workflow kode terstruktur Dirac, tetapi ini bukan replika Dirac karena tidak memiliki runtime, indeks AST persisten, mesin edit hash-anchor, atau benchmark harness
    Sebagai gantinya, aku hanya memindahkan helper AST kecil dan disiplin workflow ke dalam skill portabel, dan aku juga menyertakan laporan singkat saat menerapkannya pada repositori Dirac itu sendiri
    Dari sudut pandang penulis aslinya, aku ingin mendapat masukan apakah prompt dan tool-nya cukup representatif
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Aku sedang merombak basis kode Rust dengan Kimi 2.6 dan Dirac
    Arah pekerjaannya adalah memperkuat Clean Architecture, dan cakupan kerjanya sudah kurapikan dalam Beads epic serta issue-issue turunannya
    Perencanaannya dibuat dengan gpt5.5, dan verifikasi penyelesaiannya juga ditangani gpt5.5
    Untuk refaktor basis kode besar, Dirac lebih produktif daripada OpenCode, sedangkan OpenCode sempat merusak file .rs hingga harus dikembalikan

    • Aku penasaran apakah kamu juga memakai Dirac bersama gpt-5.5