dirac-run/dirac

 (github.com/dirac-run)
1 pontos por GN⁺ 1 일 전 | 1 comentários | Compartilhar no WhatsApp
  • É um agente de codificação open source focado em curadoria densa de contexto e otimização de desempenho em relação à eficiência de ferramentas para reduzir problemas de instabilidade no raciocínio em contextos longos
  • Com base no gemini-3-flash-preview, registrou 65,2% no Terminal-Bench-2 e alcançou 8/8 sucessos em 8 tarefas complexas de refatoração em repositórios públicos do GitHub
  • Combina Hash-Anchored Edits, Multi-File Batching e edição com reconhecimento estrutural para lidar com vários arquivos com poucas idas e vindas, refletindo a estrutura sintática de linguagens como TypeScript, Python e C++ nas modificações
  • Suporta leitura e escrita de arquivos, comandos de terminal e navegador headless, além de oferecer um fluxo de CLI com workflow baseado em aprovação, Plan Mode, Yolo Mode e retomada do histórico de tarefas
  • Destaca custo médio de $0.18 e 64,8% de redução de custo em relação a ferramentas concorrentes, chamando atenção por elevar ao mesmo tempo desempenho e custo-benefício em tarefas práticas, sem depender de informações exclusivas de benchmark

Desempenho principal

  • Resultados de benchmark

    • Registrou 8/8 respostas corretas no total das 8 tarefas, e entre os comparados apenas o Opencode também chegou aos mesmos 8/8
    • O custo médio é de $0.18, abaixo de Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38 e Roo $0.60
    • O README afirma que o Dirac é 64,8% mais barato que as ferramentas concorrentes e proporciona 2,8x de economia em custo
    • Mais detalhes sobre as tarefas e a metodologia estão em evals/README.md

  • Características de custo por tarefa

    • Em cada tarefa de refatoração, incluindo repositórios transformers, vscode e django, registra na maioria dos casos o menor ou um dos menores custos
    • Por exemplo, a tarefa DynamicCache em transformers custa $0.13, a tarefa datadict em django fica em $0.08 e a tarefa sendRequest em vscode fica em torno de $0.25
    • Algumas ferramentas concorrentes registraram Incomplete ou Failure, mas o Dirac aparece como Success em todas as 8 tarefas da tabela

Abordagem e design

  • Estratégia de contexto e edição

    • Com Hash-Anchored Edits, mira a posição de modificação com base em hashes de linha estáveis, evitando o problema de "lost in translation" da edição tradicional baseada em números de linha
    • Com Multi-File Batching, lê e modifica vários arquivos em uma única ida e volta com o LLM, reduzindo latência e custo de API
    • A otimização de High-Bandwidth Context mantém apenas as informações mais relevantes, reduzindo desperdício de tokens e mantendo o agente leve e rápido

  • Edição com reconhecimento estrutural

    • Incorpora AST-Native Precision para trabalhar entendendo a estrutura sintática de linguagens como TypeScript, Python e C++
    • Afirma conseguir realizar manipulações estruturais como extração de função ou refatoração de classes com 100% de precisão

  • Modelo de uso de ferramentas

    • Suporta leitura e escrita de arquivos, execução de comandos de terminal e uso de navegador headless
    • O fluxo de trabalho mantém um workflow baseado em aprovação, projetado para que o usuário mantenha o controle
    • O suporte a modelos é limitado aos casos em que há chamada nativa de ferramentas, por motivos de confiabilidade e desempenho
    • Segundo o README, MCP não é suportado

Forma de uso e customização

  • Controle de comportamento por projeto

    • É possível customizar o comportamento aplicando instruções por projeto com o arquivo AGENTS.md
    • Lê automaticamente os diretórios .ai, .claude e .agents, usando também Claude skills

  • Fluxo de uso da CLI

    • Após autenticar com dirac auth, é possível executar tarefas como dirac "Analyze the architecture of this project"
    • dirac -p "prompt" usa o Plan Mode para verificar primeiro a estratégia
    • dirac -y "prompt" usa o Yolo Mode para aprovar automaticamente todas as ações
    • É possível passar contexto diretamente por entrada via pipe, como em git diff | dirac "Review these changes"
    • Com dirac history, é possível ver tarefas anteriores e retomá-las

  • Integração com VS Code

    • É possível instalar a extensão no VS Code Marketplace
    • O fluxo consiste em abrir a barra lateral do VS Code, configurar o provedor de IA preferido, como Anthropic, OpenAI ou OpenRouter, e então iniciar uma nova tarefa

Ambiente de execução e integração com provedores

  • Chaves de API e variáveis de ambiente

    • Para pular a etapa de autenticação, é possível usar variáveis de ambiente como ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN e outras
    • A lista completa está em src/shared/storage/env-config.ts

  • Suporte ao AWS Bedrock

    • Se AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN e AWS_BEDROCK_MODEL ou AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN forem configurados, ele alterna automaticamente para o provider Bedrock
    • Inclui um exemplo de execução utilizável com aws-vault
    • Modelos Claude mais recentes, como Sonnet 4.6 ou superior, exigem um prefixo de perfil de inferência cross-region como us., eu. ou ap., e recomenda consultar os IDs de modelos suportados na documentação da AWS

Contexto do projeto

Leituras relacionadas

1 comentários

 
GN⁺ 1 일 전
Comentários no Hacker News

  • O que achei interessante no Dirac foi o seguinte
    Ele edita arquivos com uma versão otimizada de Hash-Anchored edits e usa a AST da linguagem para decidir que código colocar no contexto, então não precisa ler arquivos de código grandes por completo
    Todo o trabalho é agrupado em lotes para processar muitas leituras/modificações ao mesmo tempo, e, se o modelo precisar, ele também executa diretamente scripts bash/python/perl para fazer análises na hora
    Ele também gerencia o contexto com bastante cuidado, atualizando-o de forma a já incluir previamente informações que o modelo quase certamente vai pedir em seguida

    • Sempre me perguntei por que a AST não é mais usada em edição de código ou inferência de escopo de mudanças
      Em um texto antigo, alguém dizia que grep também era quase tão eficaz, e naquele contexto isso até parecia razoável
    • Edição baseada em âncoras exige injetar novas âncoras no contexto, e o Dirac aparentemente faz isso com diff, então não tenho certeza se isso é realmente mais eficiente em tokens do que search and replace
      Mesmo que o hash seja só um token, código é mais lido do que escrito, então o custo acumulado também cresce
      Quando experimentei antes com stable anchors mais longas, também pareceu mais um retrocesso, e a eficiência do Dirac parece vir mais de mostrar só o esqueleto do arquivo
    • Não entendi o que era Batches all operations, então fui olhar o código-fonte, e me pareceu que significa que, em vez de esperar que o modelo faça bem chamadas paralelas de ferramentas, a própria tool API foi desenhada para receber listas de vários alvos
      Pela minha experiência, os modelos também não gostam muito de fazer um grande volume de chamadas paralelas de uma vez, e essa tendência é ainda mais forte em modelos mais fracos
    • Em vez de gastar tokens com um modelo SOTA, talvez faça mais sentido usar um modelo especializado e muito barato só para edição de arquivos
      Também parece possível fazer o modelo de ponta apenas criar e chamar um modelo de edição mais barato
    • Se o contexto trazido é decidido pela AST da linguagem, fico curioso se isso acaba sendo uma estrutura que só funciona em linguagens com parser

  • É realmente interessante o quanto o AI harness afeta o desempenho
    Subir de 48% para 65% em relação ao resultado oficial do Google é uma diferença enorme, e, embora eu veja muitas comparações entre modelos, quase nunca vejo resultados comparando só o harness com o mesmo modelo
    Fico curioso se existe algum leaderboard que compare o desempenho de harnesses usando o mesmo modelo

    • Provavelmente seria preciso comparar todo o produto cartesiano de modelo+harness
    • O mais citado costuma ser o terminal bench 2.0, mas nem ele escapa de suspeitas de cheating e do problema de benchmaxxing
      Surpreendentemente, no Opus 4.6 o Claude Code fica em último, e isso tanto pode ser um limite do Claude Code quanto algo que o próprio benchmark esteja dizendo
    • Também me faz pensar que o futuro talvez se pareça menos com uma inteligência centralizada humanoide e mais com uma inteligência distribuída em forma de polvo
      Nesse caso, o ponto principal passa a ser tornar o próprio harness mais inteligente do que o modelo
    • No fim, isso não é justamente o que o terminal-bench faz?
    • Testando por conta própria nos últimos meses com o mesmo modelo local, no meu ambiente o Claude Code foi claramente melhor que o OpenCode, e o OpenCode foi melhor que o Codex

  • Em benchmark, pelo menos mais um modelo de outra família deveria entrar para saber se isso generaliza
    Pensando em custo, o Minimax 2.7 parece uma boa opção, e até lá fica difícil saber se os resultados não estão superajustados ao Gemini 3 Flash
    Na landing page também deveria ficar explícito que os números atuais são todos baseados no Gemini 3 Flash, e, se “mais barato” com o mesmo modelo também significar “mais rápido”, o tempo de conclusão também seria bom de incluir no benchmark
    Além disso, suporte a skills, AGENTS.md aninhado e MCP também é importante para quem está considerando migrar

    • Rodei diretamente com Minimax 2.7, e ele parecia não gostar muito da ferramenta de edição, logo acabando no caminho de modificar arquivos com sed
      Parece natural que o modelo não generalize perfeitamente para ferramentas arbitrárias e, especialmente em tarefas comuns como edição de arquivos, sofra influência das ferramentas presentes nos dados de treinamento
      Nesse sentido, a família Gemini costuma ser menos forte em tarefas de agente, então talvez tenha menos viés para ferramentas específicas
    • Bons pontos
      Também tentei benchmark com modelos open-weights, mas a inferência era lenta e seguia batendo em timeout, e no terminal bench não dava para ajustar o timeout
      Também deixei uma reclamação sobre isso aqui https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Já refleti a indicação do Gemini no README do GitHub, e o tempo médio de conclusão era menor, mas como a velocidade de saída às vezes ficava aleatoriamente lenta, não incluí isso como benchmark rigoroso
      Também adicionei as informações de skills / AGENTS.md / MCP

  • Ainda não usei diretamente, mas fico curioso por que você não escolheu colocar isso como uma extensão sobre o pi em vez de criar um harness novo do zero
    A extension API do pi que vi parecia bem ampla, e algo como Hash anchored edits parecia totalmente viável ali
    Obrigado por abrir o projeto; pretendo olhar com calma depois

    • Alguns meses atrás, em uma tarde, o Cline estava lento demais e isso me irritou; comecei a olhar por dentro e corrigir algumas coisas
      Aí fui sendo puxado cada vez mais, até chegar a algo como 70 mil linhas alteradas e 40 mil removidas, e dois meses depois virou o estado atual
    • Tenho acompanhado os LLMs locais e os novos harnesses ultimamente, e fico curioso para saber o quanto o Pi é realmente melhor que o OpenCode
      Também queria saber qual combinação de modelo e customização funciona melhor para tirar o máximo proveito

  • Olhando o código, notei que a telemetry é enviada para https://dirac.run/v1/event
    Não parece estar enviando informação explicitamente sensível nem parece malicioso, mas também manda erros de API, então dependendo do caso pode haver vazamento de conteúdo sensível
    Além disso, ser opt-out e ir para um endpoint operado por um desenvolvedor solo me pareceu bem assustador, então pessoalmente eu não conseguiria usar por causa disso

    • A telemetry que confirmei foi mais ou menos esta
      Envia para dirac.run/v1/event o machine ID, uso de tokens, informações do modelo, eventos, os primeiros 500 caracteres dos erros e informações da plataforma
      Em dirac.run/v1/event/decide, consulta feature flags a cada 60 minutos junto com o machine ID, e isso fica sempre ligado independentemente do opt-out de telemetry, sem como desativar sem alterar o código
      As ferramentas de busca na web/web fetch passam por api.dirac.run, enviando o conteúdo da requisição e headers do sistema
      A lista de modelos também consulta OpenRouter, HuggingFace, Groq etc., mesmo quando se usa o provider Anthropic
    • Obrigado
      Isso vem do fato de ser um fork do Cline; essa parte herdou o mecanismo de telemetry como estava, e só foi mantida porque poderia ajudar no debugging
      Não há absolutamente nenhuma intenção maliciosa, e eu também não gero nem armazeno PII

  • O ponto central é o quanto o harness importa, e acho que essa interpretação vai durar bastante
    Modelo dá para alugar, prompt dá para copiar mais ou menos, mas uma parte considerável dos números de benchmark é decidida pelo harness ao redor
    Sob o mesmo harness, trocar Gemini por Sonnet pode causar uma mudança menor do que trocar o harness mantendo o mesmo modelo
    O texto que você linkou sobre cheating-agents no fim diz a mesma coisa: o que está sendo medido na prática é o harness, e o modelo é mais o ingrediente base
    Dito isso, context management parece menos uma propriedade universal e mais uma forma de compensar fraquezas da geração atual de modelos, então talvez desapareça em algumas gerações, do mesmo jeito que ferramentas tomaram o lugar do RAG baseado em embeddings de perguntas

    • É por isso que o ARC-AGI-3 não permite uso de harness
      O modelo precisa criar o próprio harness por conta própria

  • Parabéns, parece muito bem feito
    Nas últimas semanas, aqui do meu lado, criar harnesses também foi o side project mais divertido, e embora eu nunca termine, especialmente fiquei curioso sobre duas experiências
    Em gerenciamento de contexto, podar respostas antigas de tool call, cortar saídas e fazer compaction automática funcionou bastante bem, e o ganho de reduzir o contexto foi maior do que o benefício de lembrar tudo
    Ainda assim, sempre deixo um resumo curto
    Já no lado de subagents, estou experimentando quase não expor ferramentas ao agente principal, dando só um run_agent, e deixando o agente secundário usar search/execute/fetch
    Se o agente secundário devolver apenas um resumo conciso, imagino que o contexto superior permaneça limpo por mais tempo, mas ainda estou experimentando mais no design dos prompts

    • Obrigado
      Se houver suporte a cache de API, é melhor evitar pruning sempre que possível, porque cada pruning quebra o cache e faz perder a vantagem do cache com 90% de desconto
      O subagent também foi herdado no Dirac como melhoria de um recurso do Cline, mas varia bastante porque alguns modelos não foram bem treinados para delegação
      Em especial, quando o agente secundário entra em loop ou não retorna, é essencial haver um mecanismo para o agente principal manter o controle

  • Isso é realmente muito interessante e bate bastante com a minha própria experiência criando harnesses
    Acho que ainda existe bastante espaço de melhora mesmo com o mesmo modelo
    No ano passado, a Anthropic empurrava a narrativa de que, a cada modelo novo, o harness ficava mais próximo de um simples while loop envolvendo ferramentas, mas agora parece que estamos indo na direção oposta
    Há coisa demais para explorar do lado do harness, e no meu trabalho a rolling context window foi muito mais poderosa do que compaction
    Se somar a isso um resumo persistente de alto nível e um pipeline detalhado de feedback automático, fica melhor ainda, embora isso seja naturalmente mais fácil de implementar quando o objetivo do agente é claro e consistente

  • O ponto do harness me chamou especialmente a atenção
    Quando meus créditos estavam quase acabando, baixar para um modelo menor e estruturar mais o prompt às vezes fazia o gpt-5.4-mini ir melhor do que um gpt-5.4 no improviso
    Por isso comecei o skill distillery, para transformar boas ideias de workflow de agente em skills pequenas, inspecionáveis e instaláveis https://github.com/ouatu-ro/skill-distillery
    O primeiro é o dirac-workflow, baseado no workflow estruturado de código do Dirac; não é uma réplica do Dirac e não tem runtime, índice AST persistente, motor de edição por hash-anchor nem harness de benchmark
    Em vez disso, trouxe apenas pequenos helpers de AST e disciplina de workflow como uma skill portável, e também incluí um relatório curto aplicando isso ao próprio repositório do Dirac
    Gostaria de receber feedback do autor original sobre se os prompts e as ferramentas são representativos
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Estou refatorando uma base Rust com Kimi 2.6 e Dirac
    A direção é reforçar ainda mais a Clean Architecture, e o escopo do trabalho está organizado em um épico Beads e issues relacionadas
    O planejamento foi feito com gpt5.5, e a validação de conclusão também está sendo feita pelo gpt5.5
    Em refatorações de grandes codebases, o Dirac foi mais produtivo que o OpenCode, e o OpenCode quebrou arquivos .rs, então precisei reverter

    • Fiquei curioso se você também usa o Dirac junto com o gpt-5.5