dirac - un agent IA open source précis et très efficace en tokens

 (github.com/dirac-run)
1 points par GN⁺ 2 일 전 | 1 commentaires | Partager sur WhatsApp
  • Met l’accent sur une curation de contexte dense et une optimisation des performances par rapport à l’efficacité des outils afin de réduire les problèmes de dégradation des performances de raisonnement dans les contextes longs
  • Avec gemini-3-flash-preview, a obtenu 65,2 % sur Terminal-Bench-2 et a réussi 8/8 sur huit tâches complexes de refactorisation dans des dépôts GitHub publics
  • Combine Hash-Anchored Edits, Multi-File Batching et l’édition sensible à la structure pour traiter plusieurs fichiers avec peu d’allers-retours, en appliquant des modifications qui reflètent la structure syntaxique de langages comme TypeScript, Python et C++
  • Prend en charge la lecture/écriture de fichiers, les commandes terminal, un navigateur headless, ainsi qu’un flux CLI incluant workflow basé sur l’approbation, Plan Mode, Yolo Mode et reprise de l’historique des tâches
  • Met en avant un coût moyen de 0,18 $ et une réduction de coût de 64,8 % par rapport aux outils concurrents, avec une amélioration conjointe des performances et des coûts sur des tâches réelles sans informations spécifiques aux benchmarks

Performances clés

  • Résultats de benchmark

    • A obtenu 8/8 bonnes réponses sur l’ensemble des huit tâches ; parmi les outils comparés, seul Opencode atteint également 8/8
    • Le coût moyen est de 0,18 $, inférieur à Cline 0,49 $, Kilo 0,73 $, Ohmypi 0,51 $, Opencode 0,44 $, Pimono 0,38 $ et Roo 0,60 $
    • Le README indique que Dirac est 64,8 % moins cher que les outils concurrents et permet une réduction de coût de 2,8x
    • Des explications détaillées sur les tâches et la méthodologie sont disponibles dans evals/README.md

  • Caractéristiques de coût par tâche

    • Sur chaque tâche de refactorisation, y compris dans les dépôts transformers, vscode et django, enregistre le plus souvent le coût le plus bas ou parmi les plus bas
    • Par exemple, la tâche DynamicCache de transformers coûte 0,13 $, la tâche datadict de django 0,08 $ et la tâche sendRequest de vscode 0,25 $
    • Certains outils concurrents ont été marqués Incomplete ou Failure, alors que Dirac est indiqué Success sur les huit tâches du tableau

Approche et conception

  • Stratégie de contexte et d’édition

    • Les Hash-Anchored Edits ciblent les emplacements de modification à partir de hachages de lignes stables, évitant ainsi le problème de "lost in translation" des éditions classiques basées sur les numéros de ligne
    • Le Multi-File Batching permet de lire et modifier plusieurs fichiers en un seul aller-retour LLM, ce qui réduit la latence et le coût API
    • L’optimisation High-Bandwidth Context conserve uniquement les informations les plus pertinentes pour limiter le gaspillage de tokens et garder l’agent léger et rapide

  • Édition sensible à la structure

    • Intègre AST-Native Precision afin de travailler en comprenant la structure syntaxique de langages comme TypeScript, Python et C++
    • Indique pouvoir effectuer avec une précision de 100 % des manipulations structurelles comme l’extraction de fonctions ou le refactoring de classes

  • Modèle d’utilisation des outils

    • Prend en charge la lecture et l’écriture de fichiers, l’exécution de commandes terminal et l’utilisation d’un navigateur headless
    • Le flux de travail conserve un workflow basé sur l’approbation afin de laisser le contrôle à l’utilisateur
    • La prise en charge des modèles est limitée aux cas où l’appel d’outils natif est disponible, pour des raisons de fiabilité et de performances
    • D’après le README, MCP n’est pas pris en charge

Utilisation et personnalisation

  • Contrôle du comportement par projet

    • Le fichier AGENTS.md permet d’appliquer des instructions spécifiques au projet pour personnaliser le comportement
    • Lit automatiquement les répertoires .ai, .claude et .agents afin d’exploiter aussi les Claude skills

  • Flux d’utilisation en CLI

    • Après authentification avec dirac auth, il est possible d’exécuter une tâche comme dirac "Analyze the architecture of this project"
    • dirac -p "prompt" utilise le Plan Mode pour vérifier d’abord la stratégie
    • dirac -y "prompt" utilise le Yolo Mode pour approuver automatiquement toutes les actions
    • Il est possible de transmettre directement du contexte via une entrée pipe, comme dans git diff | dirac "Review these changes"
    • dirac history permet de consulter les tâches précédentes et de les reprendre

  • Intégration VS Code

    • L’extension peut être installée depuis le VS Code Marketplace
    • Le flux consiste à ouvrir la barre latérale VS Code, configurer son fournisseur d’IA préféré comme Anthropic, OpenAI ou OpenRouter, puis démarrer une nouvelle tâche

Environnement d’exécution et intégration des fournisseurs

  • Clés API et variables d’environnement

    • Pour ignorer l’étape d’authentification, il est possible d’utiliser des variables d’environnement comme ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN, etc.
    • La liste complète se trouve dans src/shared/storage/env-config.ts

  • Prise en charge d’AWS Bedrock

    • Si AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN ainsi que AWS_BEDROCK_MODEL ou AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN sont définis, le passage vers le provider Bedrock se fait automatiquement
    • Inclut un exemple d’exécution pouvant être utilisé avec aws-vault
    • Les modèles Claude récents comme Sonnet 4.6 ou supérieur nécessitent un préfixe de profil d’inférence cross-region tel que us., eu. ou ap., et renvoient vers les AWS docs pour les ID de modèles pris en charge

Contexte du projet

À lire aussi

1 commentaires

 
GN⁺ 2 일 전
Avis sur Hacker News

  • Ce qui m’a paru intéressant dans Dirac, c’est ce genre d’éléments
    Il édite les fichiers avec une version optimisée des Hash-Anchored edits, et utilise l’AST du langage pour décider quel code inclure dans le contexte, ce qui évite de lire l’intégralité des gros fichiers de code.
    Toutes les opérations sont regroupées par lots pour traiter en parallèle un grand volume de lectures/modifications, et si besoin le modèle peut exécuter directement des scripts bash/python/perl pour faire une analyse à la volée.
    Il gère aussi le contexte avec pas mal de soin, en le mettant à jour en y injectant à l’avance les informations que le modèle demandera presque certainement ensuite.

    • Je me suis toujours demandé pourquoi l’AST n’était pas plus largement utilisée pour l’édition de code ou l’inférence de portée des changements.
      J’avais lu autrefois un article disant que grep était lui aussi à peu près aussi efficace, et dans ce contexte ça me paraissait partiellement plausible.
    • Les éditions ancrées exigent d’injecter de nouvelles ancres dans le contexte, et Dirac semble aussi procéder ainsi via des diff, donc je ne suis pas certain que ce soit vraiment plus efficace en tokens qu’un search and replace.
      Même si le hash ne fait qu’un token, le code est davantage lu qu’écrit, donc le coût cumulé augmente.
      Quand j’avais expérimenté autrefois avec des stable anchors plus longues, j’avais plutôt eu l’impression d’une régression, et l’efficacité de Dirac semble surtout venir du fait qu’il ne montre que le squelette de base du fichier.
    • Je ne comprenais pas ce que voulait dire Batches all operations, alors j’ai regardé le code source, et il m’a semblé que cela signifiait que l’API d’outils elle-même est conçue pour accepter des listes de cibles, au lieu de compter sur le fait que le modèle fasse bien des appels d’outils en parallèle.
      D’après mon expérience aussi, les modèles ont du mal à lancer d’un coup un grand nombre d’appels parallèles, surtout les plus faibles.
    • Je me demande s’il ne vaudrait pas mieux utiliser, au lieu de brûler des tokens sur un modèle SOTA, un modèle spécialisé très bon marché dédié à l’édition de fichiers.
      On pourrait aussi imaginer que le modèle haut de gamme ne fasse qu’orchestrer et appeler un modèle d’édition moins cher.
    • Si le contexte à récupérer est déterminé via l’AST du langage, je me demande si au final l’architecture ne fonctionne que pour les langages disposant d’un parseur.

  • C’est vraiment intéressant de voir à quel point le AI harness peut influer sur les performances.
    Passer de 48 % à 65 % par rapport aux résultats officiels de Google, c’est un écart énorme ; on voit beaucoup de comparatifs entre modèles, mais presque jamais des comparatifs du seul harness à modèle identique.
    Je me demande s’il existe un leaderboard comparant les performances des harness à modèle constant.

    • Il faudrait sans doute comparer tout le produit cartésien modèle+harness.
    • La référence la plus souvent citée est terminal bench 2.0, mais même là on n’échappe ni aux soupçons de cheating, ni au problème du benchmaxxing.
      De façon assez surprenante, avec Opus 4.6, Claude Code arrive dernier ; ça peut révéler une limite de Claude Code, ou simplement quelque chose à propos du benchmark lui-même.
    • Je me dis aussi que l’avenir pourrait ressembler moins à une intelligence centralisée de type humain qu’à une intelligence distribuée de type poulpe.
      Dans ce cas, l’enjeu principal serait moins de rendre le modèle plus intelligent que de rendre le harness lui-même plus intelligent.
    • Au fond, n’est-ce pas justement ce que fait terminal-bench ?
    • Ces derniers mois, en testant moi-même le même modèle local, j’ai constaté que dans mon environnement Claude Code était nettement meilleur qu’OpenCode, et qu’OpenCode était meilleur que Codex.

  • Pour qu’un benchmark soit convaincant, il faudrait au minimum ajouter un autre modèle d’une famille différente pour voir si ça généralise.
    Vu le coût, Minimax 2.7 semble être un bon candidat ; jusque-là, il est difficile de savoir si les résultats ne sont pas simplement surajustés à Gemini 3 Flash.
    La landing page devrait aussi indiquer clairement que les chiffres actuels reposent tous sur Gemini 3 Flash, et si « moins cher » veut dire « plus rapide » à modèle égal, il serait bon d’ajouter aussi le temps d’exécution dans le benchmark.
    En outre, la prise en charge des skills, de AGENTS.md imbriqués et de MCP compte aussi pour ceux qui envisagent une migration.

    • Je l’ai essayé directement avec Minimax 2.7, et il n’aimait vraiment pas les outils d’édition ; il finissait très vite par basculer vers des modifications de fichiers au sed.
      Il est logique qu’un modèle ne généralise pas parfaitement à des outils arbitraires, et surtout pour des tâches courantes comme l’édition de fichiers, qu’il subisse le biais des outils présents dans ses données d’entraînement.
      De ce point de vue, la famille Gemini est généralement moins forte sur les tâches d’agents, donc elle est peut-être aussi moins biaisée vers des outils spécifiques.
    • Très bonnes remarques.
      J’ai aussi essayé de benchmarker des modèles open-weights, mais l’inférence était trop lente et cela finissait sans cesse en timeout, et terminal bench ne permettait pas de modifier les timeouts.
      J’ai aussi signalé cette frustration ici : https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      J’ai ajouté la mention de Gemini dans le README GitHub, et le temps moyen de complétion était plus court, mais comme la vitesse de sortie ralentissait parfois aléatoirement, je ne l’ai pas inclus comme benchmark strict.
      J’ai aussi ajouté les informations skills / AGENTS.md / MCP.

  • Je ne l’ai pas encore utilisé moi-même, mais je me demande pourquoi tu n’as pas choisi de construire ça comme une extension sur pi au lieu de recréer un nouveau harness complet.
    L’API d’extension de pi que j’ai vue semblait assez large, et des choses comme les Hash anchored edits paraissaient tout à fait implémentables.
    Merci d’avoir open sourcé le projet ; j’ai l’intention d’y regarder de plus près plus tard.

    • Il y a quelques mois, un après-midi, Cline était tellement lent que ça m’exaspérait ; j’ai regardé à l’intérieur et commencé à corriger quelques points.
      Puis je me suis laissé happer, et après avoir accumulé environ 70 000 lignes modifiées et 40 000 supprimées, deux mois plus tard on en est arrivé à l’état actuel.
    • En ce moment je regarde les LLM locaux et les nouveaux harness, et je me demande à quel point Pi est réellement meilleur qu’OpenCode.
      J’aimerais aussi savoir quelle combinaison de modèles et de personnalisations fonctionne le mieux pour en tirer le maximum.

  • En regardant le code, j’ai remarqué que la telemetry était envoyée vers https://dirac.run/v1/event.
    Cela ne semble pas envoyer explicitement d’informations sensibles ni paraître malveillant, mais comme les erreurs d’API sont aussi transmises, il y a selon les cas un risque de fuite de contenu sensible.
    En plus, comme c’est en opt-out vers un endpoint opéré par un développeur solo, cela me met assez mal à l’aise, et personnellement je ne pourrais pas l’utiliser à cause de ça.

    • Voici ce que j’ai constaté côté telemetry.
      Vers dirac.run/v1/event, sont envoyés l’ID machine, l’usage de tokens, les informations de modèle, les événements, les 500 premiers caractères des erreurs, ainsi que des informations de plateforme.
      dirac.run/v1/event/decide interroge les feature flags toutes les 60 minutes avec l’ID machine ; cela reste activé en permanence indépendamment de l’opt-out telemetry, et on ne peut pas le désactiver sans modifier le code.
      Les outils de recherche web / web fetch passent par api.dirac.run et lui envoient le contenu des requêtes ainsi que les en-têtes système.
      La liste des modèles effectue aussi des requêtes vers OpenRouter, HuggingFace, Groq, etc., même si l’on utilise le provider Anthropic.
    • Merci.
      C’est un fork de Cline, donc il a simplement hérité du mécanisme de telemetry, et je l’ai laissé en place car cela pouvait aider au débogage.
      Il n’y a absolument aucune intention malveillante, et je ne génère ni ne stocke de PII.

  • Le vrai point clé, c’est à quel point le harness est important, et je pense que cette lecture restera valable longtemps.
    Les modèles peuvent s’emprunter, les prompts peuvent se répliquer plus ou moins, mais une part importante des scores de benchmark vient du harness autour.
    À harness identique, remplacer Gemini par Sonnet peut produire moins d’effet que de changer de harness à modèle identique.
    L’article sur les cheating-agents que tu as lié dit d’ailleurs au fond la même chose : ce qu’on mesure réellement, c’est le harness, et le modèle est plus proche de la matière première.
    En revanche, la gestion du contexte me paraît moins relever d’une propriété universelle que d’un correctif aux faiblesses de la génération actuelle de modèles ; dans quelques générations, cela pourrait disparaître comme les outils ont évincé le RAG basé sur embeddings pour les questions.

    • C’est aussi pour cela que ARC-AGI-3 n’autorise pas l’usage d’un harness.
      Le modèle doit construire lui-même son propre harness.

  • Félicitations, ça a l’air vraiment très bien fait.
    Ces dernières semaines, construire un harness a aussi été chez moi le side project le plus amusant, même si je ne termine jamais vraiment, et il y a surtout deux aspects dont je suis curieux.
    Pour la gestion du contexte, l’élagage des anciennes réponses d’appels d’outils, la troncature des sorties et la compaction automatique ont plutôt bien marché ; le gain obtenu en réduisant le contexte dépassait le bénéfice de tout garder en mémoire.
    En revanche, je laissais toujours un court résumé.
    Côté subagents, j’expérimente en n’exposant presque aucun outil à l’agent principal, à part un unique run_agent, les agents secondaires utilisant eux-mêmes search/execute/fetch.
    Si les sous-agents ne renvoient que des résumés concis, le contexte supérieur devrait rester propre plus longtemps, mais je continue à expérimenter sur le prompt design.

    • Merci.
      Si tu prends en charge le caching API, il vaut mieux en général éviter de trop toucher au pruning, car chaque opération de prune casse le cache et fait perdre l’avantage du caching à -90 %.
      Le subagent est aussi repris dans Dirac à partir d’une fonctionnalité améliorée de Cline, mais selon les modèles la délégation s’apprend très inégalement.
      Il faut surtout que l’agent principal dispose d’un mécanisme de contrôle au cas où un sous-agent boucle ou ne rende jamais la main.

  • C’est vraiment passionnant, et cela correspond très bien à ce que j’ai observé en construisant mon propre harness.
    Je pense qu’il reste encore une marge de progression importante avec un même modèle.
    L’an dernier, Anthropic poussait le récit selon lequel, à mesure que de nouveaux modèles sortaient, le harness se rapprochait d’une simple boucle while avec des outils autour ; aujourd’hui, j’ai plutôt l’impression qu’on part dans la direction inverse.
    Il y a énormément de choses à explorer côté harness, et dans mon travail le rolling context window a été bien plus puissant que la compaction.
    En y ajoutant un résumé de haut niveau persistant et un pipeline détaillé d’auto-feedback, on obtient encore mieux, même si c’est naturellement plus facile à mettre en œuvre lorsque les objectifs de l’agent sont clairs et cohérents.

  • Le point sur le harness m’a particulièrement intéressé.
    Quand mon crédit touche presque à zéro, je descends sur un plus petit modèle et je structure davantage le prompt ; dans ces cas-là, gpt-5.4-mini fait parfois mieux qu’un gpt-5.4 utilisé à l’intuition.
    J’ai donc commencé skill distillery, qui vise à transformer de bonnes idées de workflow d’agent en skills petites, vérifiables et installables : https://github.com/ouatu-ro/skill-distillery
    Le premier, dirac-workflow, s’appuie sur le workflow de code structuré de Dirac, mais ce n’est pas un clone de Dirac : il n’y a ni runtime, ni index AST persistant, ni moteur d’édition hash-anchor, ni harness de benchmark.
    À la place, il ne reprend qu’un petit helper AST et une discipline de workflow sous forme de skill portable, et j’y ai aussi ajouté un court rapport sur son application au dépôt Dirac lui-même.
    En tant qu’auteur original, j’aimerais bien avoir ton retour pour savoir si le prompt et les outils sont représentatifs.
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Je suis en train de refactorer une codebase Rust avec Kimi 2.6 et Dirac.
    L’objectif est de renforcer davantage la Clean Architecture, et la portée du travail est organisée en epic Beads et sous-issues.
    Le plan a été élaboré avec gpt5.5, et la validation de fin est elle aussi assurée par gpt5.5.
    Pour les refactorings de grosses codebases, Dirac a été plus productif qu’OpenCode, et OpenCode a cassé des fichiers .rs, que j’ai dû restaurer.

    • Je me demande si tu utilises aussi Dirac avec gpt-5.5.