dirac – präziser und tokeneffizienter Open-Source-KI-Agent

 (github.com/dirac-run)
1 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Konzentriert sich auf dichte Kontext-Kuratierung und Leistungsoptimierung im Verhältnis zur Tool-Effizienz, um schwankende Inferenzleistung in langen Kontexten zu reduzieren
  • Erreichte mit gemini-3-flash-preview 65,2 % auf Terminal-Bench-2 und 8/8 Erfolge bei acht komplexen Refactoring-Aufgaben in öffentlichen GitHub-Repositories
  • Kombiniert Hash-Anchored Edits, Multi-File Batching und strukturaware Bearbeitung, um mehrere Dateien mit wenig Roundtrips zu bearbeiten und Änderungen unter Berücksichtigung der Syntaxstrukturen von Sprachen wie TypeScript, Python und C++ vorzunehmen
  • Unterstützt Datei-Lese- und Schreibzugriffe, Terminal-Befehle und einen Headless-Browser und bietet zugleich einen genehmigungsbasierten Workflow sowie CLI-Abläufe wie Plan Mode, Yolo Mode und das Fortsetzen des Aufgabenverlaufs
  • Hebt durchschnittliche Kosten von $0.18 und eine Kostenreduktion von 64,8 % gegenüber konkurrierenden Tools hervor; auffällig ist vor allem, dass Leistung und Kosten bei praxisnahen Aufgaben ohne benchmark-spezifische Informationen gemeinsam verbessert wurden

Kernleistung

  • Benchmark-Ergebnisse

    • Über alle 8 Aufgaben hinweg wurden 8/8 korrekte Ergebnisse erzielt; unter den Vergleichskandidaten erreichte nur Opencode ebenfalls 8/8
    • Die durchschnittlichen Kosten lagen bei $0.18, also niedriger als bei Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38 und Roo $0.60
    • Laut README ist Dirac im Vergleich zu konkurrierenden Tools 64,8 % günstiger und erzielt eine 2,8-fache Kostensenkung
    • Detaillierte Aufgabenbeschreibungen und die Methodik finden sich in evals/README.md

  • Kosteneigenschaften pro Aufgabe

    • Bei den einzelnen Refactoring-Aufgaben, darunter in den Repositories transformers, vscode und django, wurden meist die niedrigsten oder nahezu die niedrigsten Kosten erzielt
    • Beispielsweise lag die DynamicCache-Aufgabe in transformers bei $0.13, die datadict-Aufgabe in django bei $0.08 und die sendRequest-Aufgabe in vscode bei $0.25
    • Einige konkurrierende Tools verzeichneten Incomplete oder Failure, während Dirac bei allen 8 in der Tabelle aufgeführten Aufgaben als Success markiert ist

Ansatz und Design

  • Kontext- und Bearbeitungsstrategie

    • Mit Hash-Anchored Edits werden Änderungen anhand stabiler Zeilen-Hashes gezielt positioniert, wodurch das „lost in translation“-Problem klassischer zeilennummernbasierter Bearbeitung vermieden wird
    • Multi-File Batching ermöglicht das Lesen und Bearbeiten mehrerer Dateien in einem einzigen LLM-Roundtrip und reduziert so Latenz sowie API-Kosten
    • Die Optimierung für High-Bandwidth Context hält nur die relevantesten Informationen vor, reduziert Token-Verschwendung und hält den Agenten leichtgewichtig und schnell

  • Strukturaware Bearbeitung

    • Integriert AST-Native Precision, um mit Verständnis für die grammatikalische Struktur von Sprachen wie TypeScript, Python und C++ zu arbeiten
    • Gibt an, strukturelle Manipulationen wie das Extrahieren von Funktionen oder Klassen-Refactorings mit 100 % Genauigkeit ausführen zu können

  • Modell der Tool-Nutzung

    • Unterstützt das Lesen und Schreiben von Dateien, das Ausführen von Terminal-Befehlen sowie die Nutzung eines Headless-Browsers
    • Der Arbeitsablauf bleibt genehmigungsbasiert, damit Nutzer die Kontrolle behalten
    • Die Modellunterstützung ist auf Fälle beschränkt, in denen native Tool-Calls möglich sind, um Zuverlässigkeit und Leistung sicherzustellen
    • Laut README wird MCP nicht unterstützt

Nutzung und Anpassung

  • Steuerung des Verhaltens pro Projekt

    • Mit der Datei AGENTS.md lassen sich projektspezifische Anweisungen anwenden, um das Verhalten anzupassen
    • Die Verzeichnisse .ai, .claude und .agents werden automatisch eingelesen, sodass auch Claude skills genutzt werden

  • CLI-Nutzungsablauf

    • Nach der Authentifizierung mit dirac auth können Aufgaben etwa mit dirac "Analyze the architecture of this project" ausgeführt werden
    • dirac -p "prompt" verwendet den Plan Mode, um zuerst die Strategie zu prüfen
    • dirac -y "prompt" nutzt den Yolo Mode und genehmigt alle Aktionen automatisch
    • Kontext kann auch direkt per Pipe übergeben werden, etwa mit git diff | dirac "Review these changes"
    • Mit dirac history lassen sich frühere Aufgaben einsehen und fortsetzen

  • VS-Code-Integration

    • Die Erweiterung kann über den VS Code Marketplace installiert werden
    • Der Ablauf sieht vor, die VS-Code-Seitenleiste zu öffnen, einen bevorzugten KI-Anbieter wie Anthropic, OpenAI oder OpenRouter zu konfigurieren und dann eine neue Aufgabe zu starten

Laufzeitumgebung und Anbieterintegration

  • API-Schlüssel und Umgebungsvariablen

    • Um den Authentifizierungsschritt zu überspringen, können ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN und weitere als Umgebungsvariablen gesetzt werden
    • Die vollständige Liste steht in src/shared/storage/env-config.ts

  • Unterstützung für AWS Bedrock

    • Wenn AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN sowie AWS_BEDROCK_MODEL oder AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN gesetzt sind, wird automatisch auf den Bedrock provider umgeschaltet
    • Enthält ein Ausführungsbeispiel für die Nutzung mit aws-vault
    • Neuere Claude-Modelle wie Sonnet 4.6 und neuer benötigen ein cross-region inference profile prefix wie us., eu. oder ap.; für unterstützte Modell-IDs wird auf die AWS docs verwiesen

Projekthintergrund

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare

  • An Dirac fand ich vor allem diese Punkte interessant
    Es bearbeitet Dateien mit einer optimierten Variante von Hash-Anchored edits und nutzt den AST der Sprache, um zu entscheiden, welcher Code in den Kontext aufgenommen wird, sodass nicht ganze große Codedateien gelesen werden müssen.
    Alle Aufgaben werden zu Batches zusammengefasst, um viele Lese-/Änderungsoperationen gleichzeitig zu verarbeiten, und wenn das Modell es braucht, führt es direkt bash/python/perl-Skripte für spontane Analysen aus.
    Außerdem wird der Kontext ziemlich sorgfältig verwaltet und so aktualisiert, dass Informationen, die das Modell als Nächstes mit hoher Wahrscheinlichkeit anfordern wird, schon vorab enthalten sind.

    • Ich habe mich schon immer gefragt, warum AST nicht viel breiter für Codebearbeitung oder die Ableitung von Änderungsbereichen verwendet wird.
      In einem älteren Beitrag hieß es einmal, dass grep ähnlich effektiv sei, und in diesem Kontext konnte ich das durchaus teilweise nachvollziehen.
    • Anchor-basierte Bearbeitung erfordert, dass neue Anchors in den Kontext injiziert werden, und Dirac scheint das per Diff so zu handhaben; daher bin ich nicht sicher, ob das gemessen an Tokens wirklich effizienter ist als search and replace.
      Selbst wenn der Hash nur ein einzelnes Token ist, bleibt das Problem bestehen, und Code wird häufiger gelesen als geschrieben, wodurch die kumulierten Kosten steigen.
      Als ich früher mit längeren stable anchors experimentiert habe, fühlte es sich eher wie ein Rückschritt an, und Diracs Effizienz scheint im Kern stärker daher zu kommen, dass nur das Dateiskelett gezeigt wird.
    • Ich wusste nicht, was Batches all operations bedeutet, und habe deshalb in den Source Code geschaut; es wirkte auf mich so, als bedeute es, dass die tool API selbst so entworfen ist, dass sie Listen mehrerer Ziele annimmt, statt zu hoffen, dass das Modell Parallel-Tool-Aufrufe gut von allein macht.
      Meiner Erfahrung nach neigen Modelle ohnehin nicht dazu, viele parallele Aufrufe auf einmal gut auszuführen, und besonders schwächere Modelle zeigen diese Tendenz noch stärker.
    • Statt Tokens in ein SOTA-Modell zu verbrennen, scheint es womöglich besser zu sein, ein sehr günstiges spezialisiertes Modell nur für Dateibearbeitung zu verwenden.
      Ein stärkeres Modell könnte dann auch einfach ein günstigeres Editiermodell erzeugen und nur noch aufrufen.
    • Wenn der Kontext über den AST der Sprache bestimmt wird, frage ich mich, ob das letztlich nur für Sprachen mit Parser funktioniert.

  • Es ist wirklich interessant, wie stark der AI harness die Leistung beeinflussen kann.
    Von 48 % auf 65 % gegenüber den offiziellen Google-Ergebnissen zu kommen, ist ein enormer Unterschied, aber obwohl man viele Modellvergleiche sieht, sieht man fast nie Vergleiche desselben Modells nur mit unterschiedlichem Harness.
    Ich frage mich, ob es ein Leaderboard gibt, das die Harness-Leistung bei identischem Modell vergleicht.

    • Wahrscheinlich müsste man das gesamte kartesische Produkt aus Modell + Harness vergleichen.
    • Am häufigsten zitiert wird wohl terminal bench 2.0, aber auch dort entgeht man weder dem Verdacht auf cheating noch dem Problem des benchmaxxing.
      Ziemlich überraschend ist dort Claude Code mit Opus 4.6 Letzter, und das könnte entweder eine Grenze von Claude Code sein oder etwas über den Benchmark selbst aussagen.
    • Vielleicht ähnelt die Zukunft weniger einer menschlich wirkenden zentralisierten Intelligenz als eher einer oktupusartigen verteilten Intelligenz.
      Dann wäre der entscheidende Punkt eher, den Harness selbst intelligenter zu machen als das Modell.
    • Irgendwie fühlt es sich so an, als wäre genau das die Aufgabe von terminal-bench.
    • In den letzten Monaten habe ich selbst mit demselben lokalen Modell getestet, und in meiner Umgebung war Claude Code klar besser als OpenCode, und OpenCode war besser als Codex.

  • Für einen Benchmark sollte man mindestens noch ein weiteres Modell aus einer anderen Familie aufnehmen, damit man weiß, ob das verallgemeinert.
    Mit Blick auf die Kosten scheint Minimax 2.7 vernünftig, und bis dahin ist schwer zu sagen, ob die Ergebnisse auf Gemini 3 Flash überangepasst sind.
    Auf der Landingpage sollte auch klar stehen, dass die aktuellen Zahlen komplett auf Gemini 3 Flash basieren, und wenn „günstiger“ bei gleichem Modell auch „schneller“ bedeutet, sollte man die Abschlusszeit ebenfalls in den Benchmark aufnehmen.
    Außerdem sind skills, verschachtelte AGENTS.md und MCP-Support für Leute wichtig, die einen Umstieg prüfen.

    • Ich habe es direkt mit Minimax 2.7 ausprobiert, und es mochte die Editier-Tools offenbar überhaupt nicht; sehr schnell ist es dazu übergegangen, Dateien einfach mit sed zu ändern.
      Es wirkt nur natürlich, dass Modelle nicht perfekt auf beliebige Tools generalisieren und gerade bei häufigen Aufgaben wie Dateibearbeitung von Tool-Bias in den Trainingsdaten beeinflusst werden.
      In diesem Sinne sind Gemini-Modelle bei Agent-Aufgaben insgesamt tendenziell schwächer und könnten deshalb sogar weniger auf bestimmte Tool-Biases festgelegt sein.
    • Gute Punkte.
      Ich habe auch Benchmarks mit open-weights-Modellen versucht, aber die Inferenz war zu langsam und lief ständig in Timeouts, und bei terminal bench lassen sich die Timeouts nicht anpassen.
      Den entsprechenden Frust habe ich auch hier notiert: https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Den Hinweis auf Gemini habe ich im GitHub-README ergänzt, und die durchschnittliche Abschlusszeit war zwar kürzer, aber da die Ausgabegeschwindigkeit manchmal zufällig langsamer wurde, habe ich es nicht als strengen Benchmark aufgenommen.
      skills / AGENTS.md / MCP-Informationen habe ich ebenfalls ergänzt.

  • Ich habe es selbst noch nicht benutzt, aber ich frage mich, warum man nicht einfach auf pi als Erweiterung aufgesetzt hat, statt gleich einen komplett neuen harness zu bauen.
    Die Extension API von pi, die ich gesehen habe, ist ziemlich weitreichend, und auch Dinge wie Hash anchored edits scheinen sich dort gut umsetzen zu lassen.
    Danke, dass du das Projekt veröffentlicht hast; ich will es mir später selbst genauer ansehen.

    • Vor ein paar Monaten war ich an einem Nachmittag von Cline genervt, weil es so langsam war, habe ins Innenleben geschaut und an ein paar Stellen mit dem Fixen begonnen.
      Dann hat es mich immer weiter hineingezogen, und nachdem sich etwa 70.000 geänderte und 40.000 gelöschte Zeilen angesammelt hatten, ist es nun zwei Monate später im aktuellen Zustand angekommen.
    • Ich schaue mir derzeit local LLMs und neue Harnesses an und frage mich, wie viel besser Pi in der Praxis wirklich ist als OpenCode.
      Ich würde auch gern wissen, welche Kombination aus Modell und Customizing am besten funktioniert, wenn man das Maximum herausholen will.

  • Beim Durchsehen des Codes habe ich entdeckt, dass telemetry an https://dirac.run/v1/event gesendet wird.
    Es sieht nicht so aus, als würden dabei offensichtlich sensible Informationen gesendet, und es wirkt nicht böswillig, aber es werden auch API-Fehler verschickt, sodass je nach Fall sensible Inhalte nach außen gelangen könnten.
    Außerdem fühlt es sich ziemlich beängstigend an, dass das ein Opt-out-Endpunkt ist, der von einem Einzelentwickler betrieben wird; allein deshalb könnte ich es persönlich nicht verwenden.

    • Die Telemetry, die ich bestätigt habe, sah ungefähr so aus:
      An dirac.run/v1/event werden machine ID, Token-Nutzung, Modellinformationen, Events, die ersten 500 Zeichen von Fehlern und Plattforminformationen gesendet.
      Über dirac.run/v1/event/decide werden alle 60 Minuten zusammen mit der machine ID Feature-Flags abgefragt; das ist unabhängig vom Telemetry-Opt-out immer aktiviert und lässt sich ohne Codeänderung nicht abschalten.
      Das Web-Search-/Web-Fetch-Tool leitet Anfragen über api.dirac.run und sendet dabei den Request-Inhalt sowie System-Header.
      Auch Modelllisten lösen Anfragen an OpenRouter, HuggingFace, Groq usw. aus, selbst wenn man den Anthropic-Provider nutzt.
    • Danke.
      Das ist ein Cline-Fork, daher hat es den Telemetry-Mechanismus unverändert geerbt; ich habe ihn nur dringelassen, weil er womöglich beim Debugging hilft.
      Es gibt keinerlei böswillige Absicht, und es werden auch keine PII erzeugt oder gespeichert.

  • Der Kernpunkt ist, wie wichtig der Harness ist, und ich glaube, das ist eine Interpretation, die Bestand haben wird.
    Modelle kann man mieten, und Prompts lassen sich ähnlich leicht kopieren, aber ein erheblicher Teil der Benchmark-Zahlen wird durch den umgebenden Harness bestimmt.
    Unter demselben Harness könnte die Änderung von Gemini zu Sonnet kleiner sein als die Änderung des Harness bei demselben Modell.
    Auch der von dir verlinkte cheating-agents-Artikel sagt im Grunde dasselbe: Gemessen wird in der Praxis der Harness, während das Modell eher das Rohmaterial ist.
    Allerdings hat context management weniger den Charakter einer universellen Eigenschaft als den, Schwächen der aktuellen Modellgeneration auszugleichen; in ein paar Generationen könnte es genauso verschwinden, wie Tools einst embedding-basiertes RAG verdrängt haben.

    • Deshalb erlaubt ARC-AGI-3 keine Harness-Nutzung.
      Das Modell muss den Harness dort selbst bauen.

  • Glückwunsch, das wirkt wirklich sehr gut gemacht.
    In den letzten Wochen war auch bei mir der Bau von Harnesses das unterhaltsamste Side-Project, und obwohl ich nie ganz zum Abschluss komme, interessieren mich besonders zwei Erfahrungen.
    Beim Kontextmanagement haben das Beschneiden alter Tool-Call-Antworten, das Abschneiden von Ausgaben und automatische Compaction ziemlich gut funktioniert, und der Nutzen eines kleineren Kontexts war größer als der Nutzen, alles zu behalten.
    Allerdings lasse ich immer eine kurze Zusammenfassung stehen.
    Auf der Subagent-Seite experimentiere ich außerdem damit, dem Hauptagenten fast keine Tools direkt offenzulegen und ihm nur run_agent zu geben, während der Unteragent search/execute/fetch verwendet.
    Wenn der Unteragent nur kompakte Zusammenfassungen zurückgibt, dürfte der übergeordnete Kontext lange sauber bleiben, aber am Prompt-Design experimentiere ich noch weiter.

    • Danke.
      Wenn API-Caching unterstützt wird, sollte man Pruning nach Möglichkeit eher nicht anfassen, denn jedes Prune invalidiert den Cache und zerstört damit den Vorteil des 90-%-Discount-Cachings.
      Subagent hat Dirac ebenfalls von einer verbesserten Cline-Funktion übernommen, aber je nach Modell klappt das Delegieren sehr unterschiedlich gut.
      Vor allem für Fälle, in denen ein Unteragent in eine Schleife gerät oder nicht zurückkehrt, braucht man unbedingt einen Mechanismus, mit dem der Hauptagent die Kontrolle behält.

  • Das ist wirklich interessant und deckt sich stark mit meinen Erfahrungen beim Bau von Harnesses.
    Selbst mit demselben Modell gibt es offenbar noch erhebliches Potenzial nach oben.
    Letztes Jahr hat Anthropic die Erzählung forciert, dass Harnesses mit jeder neuen Modellgeneration eher zu einer simplen While-Loop um Tools herum würden, aber inzwischen wirkt es eher genau umgekehrt.
    Auf der Harness-Seite gibt es noch unglaublich viel zu erkunden, und in meiner Arbeit war ein rolling context window deutlich wirkungsvoller als Compaction.
    Wenn man das noch mit dauerhaften High-Level-Zusammenfassungen und einer detaillierten automatischen Feedback-Pipeline kombiniert, wird es noch besser, wobei sich das natürlich umso leichter umsetzen lässt, je klarer und konsistenter das Ziel des Agenten ist.

  • Besonders der harness-Punkt war interessant.
    Wenn meine Credits fast aufgebraucht waren, habe ich auf ein kleineres Modell heruntergeschaltet und die Prompts stärker strukturiert; dabei war gpt-5.4-mini manchmal besser als ein eher freilaufendes gpt-5.4.
    Deshalb habe ich skill distillery gestartet, um gute Ideen für Agent-Workflows in kleine, überprüfbare und installierbare skills zu überführen: https://github.com/ouatu-ro/skill-distillery
    Das erste davon ist dirac-workflow, basierend auf Diracs strukturiertem Code-Workflow; es ist jedoch kein Dirac-Klon und enthält weder Runtime noch persistenten AST-Index, Hash-Anchor-Editier-Engine oder den Benchmark-Harness.
    Stattdessen habe ich nur kleine AST-Helfer und Workflow-Disziplin in eine portable Skill gepackt und auch einen kurzen Bericht beigefügt, in dem ich sie auf das Dirac-Repository selbst angewandt habe.
    Aus Sicht des Originalautors würde ich gern Feedback dazu bekommen, ob Prompts und Tools repräsentativ sind.
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Ich refaktoriere gerade mit Kimi 2.6 und Dirac eine Rust-Codebasis.
    Dabei geht es darum, Clean Architecture noch stärker durchzusetzen, und den Arbeitsumfang habe ich in einem Beads-Epic mit Unter-Issues strukturiert.
    Die Planung habe ich mit gpt5.5 gemacht, und auch die Abschlussprüfung übernimmt gpt5.5.
    Bei Refactorings in großen Codebasen war Dirac produktiver als OpenCode, und OpenCode hat .rs-Dateien beschädigt, sodass ich sie zurückrollen musste.

    • Mich würde interessieren, ob du Dirac auch zusammen mit gpt-5.5 verwendest.