dirac-run/dirac

 (github.com/dirac-run)
1 puntos por GN⁺ 2 일 전 | 1 comentarios | Compartir por WhatsApp
  • Es un agente de codificación de código abierto enfocado en la curación densa de contexto y en la optimización del rendimiento frente a la eficiencia de herramientas para reducir los problemas de inestabilidad en el razonamiento con contextos largos
  • Con gemini-3-flash-preview registró 65.2% en Terminal-Bench-2 y logró 8/8 éxitos en ocho tareas complejas de refactorización sobre repositorios públicos de GitHub
  • Combina Hash-Anchored Edits, Multi-File Batching y edición con reconocimiento de estructura para trabajar sobre varios archivos con pocos intercambios, reflejando la estructura sintáctica de lenguajes como TypeScript, Python y C++ al aplicar cambios
  • Soporta lectura y escritura de archivos, comandos de terminal y navegador sin interfaz gráfica, y además ofrece un flujo CLI con aprobaciones, Plan Mode, Yolo Mode y reanudación del historial de trabajo
  • Destaca por un costo promedio de $0.18 y una reducción de costos del 64.8% frente a herramientas competidoras, sobresaliendo por mejorar tanto rendimiento como costo en tareas orientadas al uso real sin información exclusiva del benchmark

Rendimiento clave

  • Resultados de benchmark

    • Registró 8/8 respuestas correctas en el total de las 8 tareas, y entre los comparados solo Opencode alcanzó también 8/8
    • El costo promedio fue de $0.18, por debajo de Cline $0.49, Kilo $0.73, Ohmypi $0.51, Opencode $0.44, Pimono $0.38 y Roo $0.60
    • El README afirma que Dirac es 64.8% más barato que las herramientas competidoras y que logra una reducción de 2.8 veces en costos
    • La descripción detallada de las tareas y la metodología puede consultarse en evals/README.md

  • Características de costo por tarea

    • En cada tarea de refactorización, incluyendo repositorios como transformers, vscode y django, registró en la mayoría de los casos el costo más bajo o entre los más bajos
    • Por ejemplo, la tarea DynamicCache de transformers tuvo un costo de $0.13, la tarea datadict de django fue de $0.08, y la tarea sendRequest de vscode estuvo en $0.25
    • Aunque algunas herramientas competidoras registraron Incomplete o Failure, Dirac aparece como Success en las 8 tareas mostradas en la tabla

Enfoque y diseño

  • Estrategia de contexto y edición

    • Con Hash-Anchored Edits apunta a la ubicación de modificación usando hashes de línea estables, evitando el problema de "lost in translation" de la edición tradicional basada en números de línea
    • Con Multi-File Batching lee y modifica varios archivos en un solo intercambio con el LLM para reducir latencia y costo de API
    • La optimización de High-Bandwidth Context mantiene solo la información más relevante para reducir desperdicio de tokens y conservar al agente ligero y rápido

  • Edición con reconocimiento de estructura

    • Integra AST-Native Precision para trabajar entendiendo la estructura sintáctica de lenguajes como TypeScript, Python y C++
    • Afirma poder realizar manipulaciones estructurales como extracción de funciones o refactorización de clases con 100% de precisión

  • Modelo de uso de herramientas

    • Soporta lectura y escritura de archivos, ejecución de comandos de terminal y uso de navegador sin interfaz gráfica
    • El flujo de trabajo mantiene un workflow basado en aprobaciones para que el usuario conserve el control
    • El soporte de modelos se limita a casos con llamadas nativas a herramientas, por motivos de confiabilidad y rendimiento
    • Según el README, no soporta MCP

Forma de uso y personalización

  • Control de comportamiento por proyecto

    • El archivo AGENTS.md permite aplicar instrucciones por proyecto para personalizar el comportamiento
    • También lee automáticamente los directorios .ai, .claude y .agents para aprovechar junto con ello las Claude skills

  • Flujo de uso en CLI

    • Tras autenticarse con dirac auth, se puede ejecutar una tarea como dirac "Analyze the architecture of this project"
    • dirac -p "prompt" usa Plan Mode para revisar primero la estrategia
    • dirac -y "prompt" usa Yolo Mode para aprobar automáticamente todas las acciones
    • También se puede pasar contexto por entrada estándar, como en git diff | dirac "Review these changes"
    • Con dirac history se pueden ver tareas previas y retomarlas

  • Integración con VS Code

    • La extensión puede instalarse desde VS Code Marketplace
    • El flujo consiste en abrir la barra lateral de VS Code, configurar el proveedor de IA preferido como Anthropic, OpenAI u OpenRouter, y luego iniciar una nueva tarea

Entorno de ejecución e integración con proveedores

  • API keys y variables de entorno

    • Para omitir el paso de autenticación, puede recibir por variables de entorno ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, XAI_API_KEY, HF_TOKEN y otras
    • La lista completa está en src/shared/storage/env-config.ts

  • Soporte para AWS Bedrock

    • Si se configuran AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN junto con AWS_BEDROCK_MODEL o AWS_BEDROCK_MODEL_ACT, AWS_BEDROCK_MODEL_PLAN, cambia automáticamente al proveedor Bedrock
    • Incluye un ejemplo de ejecución que puede usarse junto con aws-vault
    • Los modelos recientes de Claude, como Sonnet 4.6 o superior, requieren un prefijo de perfil de inferencia cross-region como us., eu., ap., y remite a los IDs de modelos compatibles en AWS docs

Contexto del proyecto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 일 전
Opiniones en Hacker News

  • Lo que me pareció interesante de Dirac fue esto
    Edita archivos con una versión optimizada de Hash-Anchored edits, y usa el AST del lenguaje para decidir qué código meter en el contexto, así que evita leer archivos de código grandes completos
    Agrupa todo el trabajo en lotes para procesar muchas lecturas/modificaciones al mismo tiempo, y si el modelo lo necesita, hace que ejecute directamente scripts de bash/python/perl para análisis sobre la marcha
    Además maneja el contexto con bastante cuidado, actualizándolo de forma que incluya por adelantado la información que casi seguro el modelo va a pedir después

    • Siempre me he preguntado por qué el AST no se usa más ampliamente para editar código o inferir el alcance de cambios
      Hace tiempo, en algún texto decían que grep también era igual de efectivo, y en ese contexto la verdad sí me pareció razonable
    • La edición basada en anclas necesita inyectar nuevas anclas en el contexto y, por lo que vi, Dirac también lo maneja así con diffs, así que no me queda claro si de verdad es más eficiente que search and replace en términos de tokens
      Incluso si el hash es de un solo token, el código se lee más de lo que se escribe, así que el costo acumulado también crece
      Antes probé con stable anchors más largos y hasta se sintió como un retroceso; da la impresión de que la eficiencia de Dirac viene más de mostrar solo el esqueleto básico del archivo
    • No entendía qué significaba Batches all operations, así que vi el código fuente, y me pareció que en vez de esperar que el modelo haga bien llamadas paralelas a herramientas, la propia tool API está diseñada para recibir listas de varios objetivos
      En mi experiencia, los modelos no suelen hacer bien muchas llamadas paralelas de golpe, y esa tendencia es todavía más fuerte en modelos débiles
    • Me da la impresión de que podría ser mejor usar un modelo muy barato y especializado solo para edición de archivos, en vez de quemar tokens en un modelo SOTA
      También parece posible hacer que un modelo de gama alta solo cree e invoque modelos de edición más baratos
    • Si el contexto que se trae se decide con el AST del lenguaje, me pregunto si al final esto solo funciona en lenguajes con parser

  • Es realmente interesante cuánto impacta el AI harness en el rendimiento
    Subir de 48% a 65% respecto al resultado oficial de Google es una diferencia enorme; comparaciones de modelos hay muchas, pero casi nunca veo comparaciones del mismo modelo cambiando solo el harness
    Me pregunto si existe algún leaderboard que compare el rendimiento del harness usando el mismo modelo

    • Probablemente habría que comparar todo el producto cartesiano de model+harness
    • Lo más citado suele ser terminal bench 2.0, pero tampoco se salva de sospechas de cheating ni del problema de benchmaxxing
      Bastante sorprendentemente, con Opus 4.6 Claude Code queda en último lugar, y eso podría hablar de una limitación de Claude Code o de lo que realmente está diciendo el propio benchmark
    • También me da la impresión de que el futuro podría parecerse más a una inteligencia distribuida tipo pulpo que a una inteligencia centralizada de tipo humano
      Entonces lo importante sería hacer más inteligente el propio harness, más que el modelo
    • También da la impresión de que eso es precisamente lo que hace terminal-bench
    • En estos últimos meses hice pruebas directas con el mismo modelo local, y en mi entorno Claude Code fue claramente mejor que OpenCode, y OpenCode mejor que Codex

  • Si es un benchmark, por lo menos habría que meter otro modelo de una familia distinta para ver si generaliza
    Pensando en costos, Minimax 2.7 se ve razonable, y mientras no esté eso es difícil saber si el resultado está sobreajustado a Gemini 3 Flash
    En la landing page también deberían indicar claramente que todos los números actuales están basados en Gemini 3 Flash, y si que sea más barato también significa que es más rápido con el mismo modelo, convendría incluir el tiempo de finalización en el benchmark
    Además, para quien esté pensando en migrar, también importan skills, AGENTS.md anidados y soporte para MCP

    • Lo corrí yo mismo con Minimax 2.7, y parecía odiar bastante las herramientas de edición; enseguida terminaba colapsando a modificar archivos con sed
      Parece natural que el modelo no generalice perfectamente a herramientas arbitrarias y que, sobre todo en tareas comunes como edición de archivos, herede sesgos hacia las herramientas presentes en sus datos de entrenamiento
      En ese sentido, la familia Gemini suele ser menos fuerte en tareas de agente, así que irónicamente podría tener menos sesgo hacia herramientas específicas
    • Son buenos puntos
      También intenté hacer benchmarks con modelos open-weights, pero la inferencia era tan lenta que seguían cayendo en timeout, y en terminal bench no se podía ajustar el timeout
      También dejé esa queja aquí https://www.reddit.com/r/LocalLLaMA/comments/1stgt39/the_frustrating_inference_capacity_issue_with/
      Ya reflejé lo de Gemini en el README de GitHub, y aunque el tiempo promedio de finalización era menor, a veces la velocidad de salida se volvía aleatoriamente lenta, así que no lo metí como benchmark riguroso
      También agregué la información de skills / AGENTS.md / MCP

  • Todavía no lo he usado directamente, pero me pregunto por qué no elegiste montarlo como una extensión sobre pi en vez de crear un harness nuevo completo
    La API de extensiones de pi que vi es bastante amplia, y algo como Hash anchored edits parecía totalmente implementable
    Gracias por liberar el proyecto; luego quiero revisarlo yo mismo

    • Hace unos meses, una tarde Cline estaba tan lento que me desesperó; me puse a ver el interior y empecé a arreglar algunas partes
      Luego me fui metiendo cada vez más, y después de acumular como 70 mil líneas modificadas y 40 mil eliminadas, dos meses después quedó en el estado actual
    • Últimamente he estado viendo LLM locales y nuevos harnesses, y me da curiosidad cuánto mejor es Pi en la práctica frente a OpenCode
      También quisiera saber qué combinación de modelo y personalización funciona mejor para sacarle el máximo provecho

  • Revisando el código vi que la telemetry se envía a https://dirac.run/v1/event
    No parece que esté mandando información explícitamente sensible ni se ve malicioso, pero también envía errores de API, así que según el caso sí podría haber filtraciones de contenido sensible
    Además, que sea opt-out y vaya a un endpoint operado por un desarrollador individual sí se siente bastante inquietante, y personalmente por eso no lo usaría

    • La telemetry que confirmé fue más o menos esta
      Envía a dirac.run/v1/event el machine ID, uso de tokens, información del modelo, eventos, los primeros 500 caracteres del error e información de la plataforma
      En dirac.run/v1/event/decide consulta feature flags cada 60 minutos junto con el machine ID; esto está siempre activo sin importar el opt-out de telemetry y no se puede desactivar sin modificar el código
      Las herramientas de búsqueda web/web fetch envían el contenido de la solicitud y headers del sistema pasando por api.dirac.run
      La lista de modelos también hace consultas a OpenRouter, HuggingFace, Groq, etc., incluso si usas el provider de Anthropic
    • Gracias
      Esto es un fork de Cline, así que heredó tal cual ese mecanismo de telemetry, y solo lo dejé por si ayudaba con el debugging
      No hay absolutamente ninguna intención maliciosa y tampoco genero ni almaceno PII

  • El punto central es qué tan importante es el harness, y creo que esa interpretación va a durar bastante
    Los modelos se pueden alquilar y los prompts también se pueden copiar más o menos, pero una parte importante de los números del benchmark la decide el harness de alrededor
    Bajo el mismo harness, cambiar de Gemini a Sonnet puede mover menos que cambiar de harness con el mismo modelo
    Ese texto sobre cheating-agents que enlazaste al final dice básicamente lo mismo: lo que realmente se mide es el harness, y el modelo se parece más a la materia prima
    Eso sí, context management parece menos una propiedad universal y más algo para compensar debilidades de la generación actual de modelos, así que en unas cuantas generaciones podría desaparecer, igual que las herramientas desplazaron al RAG basado en embeddings para preguntas

    • Por eso ARC-AGI-3 no permite usar harness
      Hace que el modelo tenga que construir su propio harness

  • Felicidades, de verdad se ve muy bien hecho
    Estas últimas semanas, hacer harnesses también ha sido el side project más divertido de mi lado, y aunque casi nunca logro terminarlos, me interesan especialmente dos experiencias
    En gestión de contexto, podar respuestas viejas de tool calls, recortar salidas y hacer compaction automática me funcionó bastante bien; el beneficio de reducir el contexto fue mayor que el de recordarlo todo
    Aun así, siempre dejo resúmenes cortos
    Y del lado de subagents, estoy probando exponerle casi ninguna herramienta al agente principal y darle solo run_agent, para que los agentes subordinados usen search/execute/fetch
    Si los agentes subordinados devuelven solo resúmenes concisos, el contexto superior debería mantenerse limpio por mucho más tiempo, aunque todavía sigo experimentando con el diseño de prompts

    • Gracias
      Si soportas caché de API, conviene no tocar pruning salvo que sea realmente necesario, porque cada poda rompe el caché y hace perder el beneficio del 90% de descuento por caching
      En cuanto a subagent, Dirac también heredó la mejora de la funcionalidad de Cline, pero como la delegación no está bien aprendida en todos los modelos, hay mucha variación
      Sobre todo hace falta un mecanismo para que el agente principal mantenga el control, especialmente cuando el agente subordinado cae en un loop o no regresa

  • Esto es realmente interesante, y encaja muy bien con lo que yo mismo he vivido construyendo harnesses
    Creo que todavía queda bastante margen de mejora incluso con el mismo modelo
    El año pasado Anthropic impulsaba la narrativa de que, con cada modelo nuevo, el harness se parecía cada vez más a un simple while loop con herramientas alrededor, pero ahora más bien se siente que vamos en la dirección contraria
    Hay demasiado por explorar del lado del harness, y en mi trabajo el rolling context window fue mucho más potente que la compaction
    Si además le agregas un resumen persistente de alto nivel y un pipeline detallado de retroalimentación automática, mejora todavía más, aunque claro, eso es más fácil de implementar cuanto más claro y consistente sea el objetivo del agente

  • En particular, el punto del harness me pareció interesante
    Cuando ya casi no me quedan créditos, si bajo a un modelo más pequeño y estructuro más el prompt, a veces gpt-5.4-mini rinde mejor que gpt-5.4 trabajando a puro instinto
    Por eso empecé skill distillery, para llevar buenas ideas de workflows de agentes a skills pequeñas, inspeccionables e instalables https://github.com/ouatu-ro/skill-distillery
    La primera es dirac-workflow, basada en el workflow estructurado de código de Dirac; no es una réplica de Dirac y no incluye runtime, ni índice AST persistente, ni motor de edición hash-anchor, ni harness de benchmark
    En cambio, empaqué pequeños helpers de AST y disciplina de workflow como una skill portable, y también dejé un reporte corto de aplicarlo al propio repositorio de Dirac
    Desde la perspectiva del autor original, me gustaría recibir feedback sobre si el prompt y las herramientas son representativos
    https://github.com/ouatu-ro/skill-distillery/blob/main/skills/dirac-workflow/scripts/ast_tool.py

  • Estoy refactorizando un codebase en Rust con Kimi 2.6 y Dirac
    Va en la dirección de reforzar más Clean Architecture, y el alcance del trabajo ya lo dejé organizado en un epic de Beads y sus issues hijos
    La planificación la hice con gpt5.5 y la verificación de finalización también la lleva gpt5.5
    En refactors de codebases grandes, Dirac me resultó más productivo que OpenCode, y OpenCode llegó a romper archivos .rs, así que tuve que revertirlos

    • Me da curiosidad si también usas Dirac junto con gpt-5.5