dirac-run/dirac
(github.com/dirac-run)- 長いコンテキストで推論性能がぶれやすい問題を減らすため、高密度なコンテキストキュレーションとツール効率に対する性能最適化に焦点を当てたオープンソースのコーディングエージェント
gemini-3-flash-preview基準でTerminal-Bench-2 65.2%を記録し、公開GitHubリポジトリの複雑なリファクタリング作業8件で8/8成功を達成- Hash-Anchored Edits、Multi-File Batching、構造認識編集を組み合わせ、複数ファイルを少ない往復で扱い、TypeScript・Python・C++のような言語の文法構造を反映して修正
- ファイルの読み書き、ターミナルコマンド、ヘッドレスブラウザをサポートし、承認ベースのワークフローとPlan Mode・Yolo Mode・作業履歴の再開といったCLIフローも提供
- 平均コスト**$0.18と競合ツール比64.8%のコスト削減**を打ち出しており、ベンチマーク専用の情報なしで実運用型タスクにおける性能とコストをともに引き上げた点が際立つ
コア性能
-
ベンチマーク結果
- 8件の作業すべてで8/8正答を記録し、比較対象では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は競合ツール比で64.8%安価、コスト面で2.8倍の削減を実現したとしている
- 詳細な作業説明と方法論はevals/README.mdで確認可能
-
作業別のコスト特性
transformers、vscode、djangoリポジトリを含む各リファクタリング作業で、ほとんどが最安値または最安値圏のコストを記録- たとえば
transformersのDynamicCache作業は**$0.13**、djangoのdatadict作業は**$0.08**、vscodeのsendRequest作業は**$0.25**程度 - 一部の競合ツールはIncompleteやFailureを記録したが、Diracは表にある8件の作業すべてでSuccessと表示
アプローチと設計
-
コンテキストと編集戦略
- Hash-Anchored Editsにより、安定した行ハッシュを基準に修正位置を狙うことで、従来の行番号ベース編集における"lost in translation"問題を回避
- Multi-File Batchingにより、複数ファイルを1回のLLM往復で読み取り・修正し、遅延時間とAPIコストを削減
- High-Bandwidth Context最適化により、最も関連性の高い情報だけを保持してトークンの無駄を減らし、エージェントを軽量かつ高速に維持
-
構造認識編集
- AST-Native Precisionを内蔵し、TypeScript、Python、C++など各言語の文法構造を理解した状態で作業
- 関数抽出やクラスのリファクタリングのような構造的操作を100%の正確性で実行できるとしている
-
ツール利用モデル
- ファイルの読み書き、ターミナルコマンドの実行、ヘッドレスブラウザの利用などをサポート
- 作業フローは承認ベースのワークフローを維持し、ユーザーが制御権を持てるよう設計
- モデル対応はネイティブツール呼び出しが可能な場合に限定し、信頼性と性能確保を理由としている
- READMEベースではMCPは非対応
使い方とカスタマイズ
-
プロジェクトごとの動作制御
AGENTS.mdファイルでプロジェクト別の指示を適用し、動作をカスタマイズ可能.ai、.claude、.agentsディレクトリを自動で読み取り、Claude skillsも活用
-
CLI利用フロー
dirac authで認証した後、dirac "Analyze the architecture of this project"のように作業を実行可能dirac -p "prompt"はPlan Modeとして戦略を先に確認する方式dirac -y "prompt"はYolo Modeとしてすべての動作を自動承認git diff | dirac "Review these changes"のように、パイプ入力でコンテキストを直接渡せるdirac historyで以前の作業を見て再開可能
-
VS Code統合
- VS Code Marketplaceから拡張機能をインストール可能
- VS Codeのサイドバーを開き、Anthropic、OpenAI、OpenRouterなど好みのAIプロバイダーを設定して新しい作業を開始する流れ
実行環境とプロバイダー連携
-
APIキーと環境変数
- 認証ステップをスキップするため、
ANTHROPIC_API_KEY、OPENAI_API_KEY、OPENROUTER_API_KEY、GEMINI_API_KEY、GROQ_API_KEY、MISTRAL_API_KEY、XAI_API_KEY、HF_TOKENなどを環境変数として受け取れる - 完全な一覧は
src/shared/storage/env-config.tsにある
- 認証ステップをスキップするため、
-
AWS Bedrock対応
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と一緒に使える実行例も含む
- Sonnet 4.6以降のような最新Claudeモデルでは、
us.、eu.、ap.のようなcross-region inference profile prefixが必要で、対応モデルIDはAWS docsを参照するよう案内している
プロジェクトの背景
-
オープンソースと系譜
- Apache License 2.0ベースのオープンソースプロジェクト
- Clineをフォークしたプロジェクトであると明記
-
参考リソース
1件のコメント
Hacker Newsの意見
Diracで興味深かったのはこういう点
Hash-Anchored editsの最適化版でファイルを編集し、言語のASTを使ってどのコードをコンテキストに入れるかを決めるので、大きなコードファイル全体を読まなくて済む
作業はすべてバッチにまとめて大量の読み取り・修正を同時に処理し、必要ならモデルがbash/python/perlスクリプトを直接実行してその場で分析も行う
さらにコンテキスト管理もかなり丁寧で、次にモデルがほぼ確実に要求する情報を先回りして入れておく形で更新している
以前ある記事では
grepも同じくらい効果的だとしていて、その文脈ではその意見もある程度もっともだとは思ったハッシュが1トークンでもそうだし、コードは書くより読む方が多いので累積コストも大きくなる
以前もっと長いstable anchorsで試したときもむしろ後退のように感じられ、Diracの効率は基本的にファイルのスケルトンだけを見せる点から来ている部分の方が大きい気がする
Batches all operationsが何を意味するのか分からずソースを見たが、モデルが並列ツール呼び出しをうまくやってくれることを期待する代わりに、tool API自体が複数対象をリストで受け取るよう設計されているという意味に見えた自分の経験でも、モデルは大量の並列呼び出しを一度にうまくやりたがらず、とくに弱いモデルほどその傾向が強い
上位モデルにもっと安い編集モデルを作らせて、それを呼び出す方式もありそうだ
AI harnessが性能にどれだけ大きく影響するのか本当に興味深い
Google公式結果の48%から65%に上がったのは非常に大きな差なのに、モデル比較はたくさん見ても同じモデルでharnessだけを比較した結果はほとんど見たことがない
同じモデルを基準にharness性能を比較するリーダーボードがあるのか気になる
かなり驚くことにOpus 4.6ではClaude Codeが最下位だが、これはClaude Codeの限界かもしれないし、ベンチマーク自体が示していることかもしれない
そうなると重要なのはモデルそのものよりharness自体をより賢くすることになる
ベンチマークなら少なくとも別系統のモデルをもう1つは入れないと汎化しているか分からない
コストを考えるとMinimax 2.7が良さそうで、それまではGemini 3 Flashに過剰適合した結果なのか判断しにくい
ランディングページにも現在の数値がすべてGemini 3 Flashベースであることを明記すべきだし、より安いことが同じモデル基準でより速いことを意味するなら、完了時間もベンチマークに入れた方がよい
あわせてskills、入れ子のAGENTS.md、MCP対応の有無も移行を検討する人には重要だ
sedでファイルを編集する方向に崩れていったモデルが任意のツールに完全には汎化せず、とくにファイル編集のような一般的作業では学習データにあったツールへのバイアスを受けるのは自然に見える
その点ではGemini系はエージェント作業で全体的にあまり強くないので、逆に特定ツールへのバイアスも弱いのかもしれない
open-weightsモデルのベンチマークも試したが、推論が遅くてずっとtimeoutに引っかかり、terminal benchではタイムアウトを調整できなかった
関連する不満はここにも書いてある https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
Gemini表記はGitHub READMEに反映し、平均完了時間はもっと短かったが、出力速度がランダムに遅くなることがあり厳密なベンチマークには入れなかった
skills / AGENTS.md / MCP情報も追加しておいた
まだ自分では使っていないが、わざわざ新しいharnessを丸ごと作るのではなく、piに拡張として載せる方向をなぜ選ばなかったのか気になる
自分が見たpiのextension APIはかなり広く、Hash anchored editsのようなものも十分実装できそうだった
プロジェクトを公開してくれてありがとう。あとで自分でも見てみるつもり
そのままどんどんのめり込み、変更7万行、削除4万行くらい積み上がったあと、2か月たって今の状態になった
最大限活用するには、どのモデルとカスタマイズの組み合わせが良いのかも知りたい
コードを見ていて、telemetryがhttps://dirac.run/v1/eventに送信されているのを見つけた
露骨に機密情報を送っているようには見えず悪意もなさそうだが、APIエラーも送っているのでケースによってはセンシティブな内容が漏れる余地はある
しかも個人開発者が運営するエンドポイントにopt-out方式なのはかなり怖く感じるので、個人的にはこの点だけで使えない
dirac.run/v1/eventにmachine ID、トークン使用量、モデル情報、イベント、エラー先頭500文字、プラットフォーム情報を送るdirac.run/v1/event/decideで機能フラグを60分ごとにmachine ID付きで取得し、これはtelemetry opt-outと無関係に常時有効で、コードを修正しない限り無効化できないWeb検索/Web fetchツールはapi.dirac.run経由でリクエスト内容とシステムヘッダーを送る
モデル一覧もAnthropic providerを使っていてもOpenRouter、HuggingFace、Groqなどに問い合わせを出す
これはClineフォークなのでtelemetryの仕組みをそのまま引き継いでいる部分で、デバッグの助けになるかと思って残していただけ
悪意ある目的はまったくなく、PIIを生成したり保存したりもしていない
harnessがどれほど重要かが核心で、これは長く残る解釈だと思う
モデルは借りられるしプロンプトも同じように複製できるが、ベンチの数値のかなりの部分はその周辺のharnessが決めている
同じharnessでGeminiをSonnetに替える変化より、同じモデルでharnessを替える変化の方が大きいことすらある
あなたがリンクしたcheating-agentsの記事も結局同じ話で、実際に測定されているのはharnessであり、モデルはその土台となる素材に近い
ただしcontext managementは普遍的性質というより現世代モデルの弱点を埋める性格が強く、数世代もすればツールが質問埋め込みベースのRAGを押しのけたように消えていくかもしれない
モデル自身がharnessを作る必要があるようになっている
おめでとう、本当によくできていると思う
ここ数週間、自分の方でもharnessを作るのがいちばん楽しいサイドプロジェクトで、いつも完成までは行かないのだが、とくに2つの経験が気になる
コンテキスト管理では古いtool call応答の枝刈り、出力の切り捨て、自動compactionがかなり効いていて、すべてを覚えておく利点よりコンテキストを減らす利点の方が大きかった
その代わり短い要約は常に残しておく
それとsubagentsについては、メインエージェントにはツールをほとんど見せず
run_agentだけを与え、下位エージェントにsearch/execute/fetchを使わせる形で実験している下位エージェントが簡潔な要約だけを返せば上位コンテキストを長くきれいに保てるはずだと見ているが、まだプロンプト設計はさらに実験中
APIキャッシングをサポートするなら、pruningはよほどでない限り触らない方がよく、pruneを1回するごとにキャッシュが壊れて90%割引のキャッシュの利点が失われる
subagentはCline機能を改善したものをDiracも引き継いでいるが、モデルごとに委譲の学習がうまくいかずばらつきが大きい
とくに下位エージェントがループに入ったり返ってこなかったりするときに備えて、メインエージェントが制御する仕組みは必須だ
これは本当に興味深く、自分がharnessを作りながら経験したこととも非常によく一致する
同じモデルでもまだかなり大きな伸びしろが残っていると思う
昨年はAnthropicが、新モデルが出るほどharnessはツールを包んだ単純なwhile loopに近づいていくという物語を押していたが、今はむしろ逆に向かっている感じがする
harness側で探索すべきことが多すぎ、自分の作業ではrolling context windowがcompactionよりはるかに強力だった
ここに継続的な上位要約と詳細な自動フィードバックパイプラインまで加えるとさらに良くなるが、もちろんこれはエージェントの目標が明確で一貫しているほど実装しやすい
とくにharnessの点が面白かった
クレジットがほとんど尽きたとき、小さめのモデルに落としてプロンプトをより構造化すると、しばしばgpt-5.4-miniが勘に頼ったgpt-5.4よりうまくやることがあった
そこで、良いエージェントワークフローのアイデアを小さく、検証可能で、インストール可能なskillsに移す
skill distilleryを始めた https://github.com/ouatu-ro/skill-distillery最初のものはDiracの構造化コードワークフローに基づく
dirac-workflowだが、Diracのクローンではなく、ランタイムや永続ASTインデックス、hash-anchor編集エンジン、ベンチharnessはないその代わり、小さなASTヘルパーとワークフロー規律だけを移植可能なskillとして詰め込み、Diracリポジトリ自体に適用してみた短いレポートも入れてある
原作者の立場から、プロンプトとツールが代表的かどうかフィードバックをもらえると嬉しい
https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py
Kimi 2.6とDiracでRustコードベースをリファクタリングしている
Clean Architectureをさらに強化する方向で、作業範囲はBeads epicとその配下のissueに整理してある
計画はgpt5.5で立て、完了検証もgpt5.5に任せている
大規模コードベースのリファクタリングではDiracの方がOpenCodeより生産的で、OpenCodeは
.rsファイルを壊してしまい、戻さなければならなかった