▲

dirac-run/dirac

 (github.com/dirac-run)
1P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • 긴 컨텍스트에서 추론 성능이 흔들리는 문제를 줄이기 위해 촘촘한 컨텍스트 큐레이션과 도구 효율 대비 성능 최적화에 초점을 맞춘 오픈소스 코딩 에이전트임
  • 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으로 여러 파일을 한 번의 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 참조를 안내함

프로젝트 배경

함께 보면 좋은 글 β

▲
GN⁺ 13시간전  [-]
Hacker News 의견들

  • Dirac에서 흥미로웠던 건 이런 부분들임
    Hash-Anchored edits의 최적화 버전으로 파일을 편집하고, 언어의 AST를 써서 어떤 코드를 컨텍스트에 넣을지 결정하니 큰 코드 파일 전체를 읽지 않게 됨
    작업은 전부 배치로 묶어서 대량의 읽기/수정을 동시에 처리하고, 모델이 필요하면 bash/python/perl 스크립트를 직접 실행해 즉석 분석도 하게 함
    또 컨텍스트를 꽤 세심하게 관리해서, 다음에 모델이 거의 확실히 요청할 정보는 미리 넣어두는 식으로 업데이트함

    • 왜 AST가 코드 편집이나 변경 범위 추론에 더 널리 쓰이지 않는지 늘 궁금했음
      예전에 어떤 글에서는 grep도 비슷하게 효과적이라고 했고, 그 맥락에서는 그 말도 어느 정도 납득되긴 했음
    • 앵커 기반 편집은 새 앵커를 컨텍스트에 주입해야 하고 Dirac도 diff로 그렇게 처리하던데, 그러면 토큰 기준으로 search and replace보다 정말 더 효율적인지 잘 모르겠음
      해시가 토큰 하나여도 그렇고, 코드는 쓰기보다 읽기가 더 많아서 누적 비용도 커짐
      예전에 더 긴 stable anchors로 실험했을 때도 오히려 퇴보처럼 느껴졌고, Dirac의 효율은 기본적으로 파일 스켈레톤만 보여주는 데서 더 많이 오는 듯함
    • Batches all operations가 뭔지 몰라서 소스를 봤는데, 모델이 병렬 툴 호출을 잘 해주길 기대하는 대신 tool API 자체가 여러 대상을 리스트로 받게 설계돼 있다는 뜻으로 보였음
      내 경험상도 모델은 대량의 병렬 호출을 한꺼번에 잘 안 하려 하고, 특히 약한 모델일수록 그 경향이 더 강함
    • SOTA 모델에 토큰을 태우기보다 파일 편집 전용의 매우 싼 특화 모델을 쓰는 쪽이 낫지 않나 싶음
      상위 모델은 더 저렴한 편집 모델을 만들어 호출만 하게 하는 방식도 가능해 보임
    • 언어의 AST로 가져올 컨텍스트를 정한다면, 결국 파서가 있는 언어에서만 동작하는 구조인지 궁금함

  • AI harness가 성능에 얼마나 큰 영향을 주는지 정말 흥미로움
    Google 공식 결과의 48%에서 65%로 올라간 건 엄청 큰 차이인데, 모델 비교는 많이 봐도 같은 모델로 harness만 비교한 결과는 거의 못 봄
    같은 모델 기준으로 harness 성능을 비교하는 리더보드가 있는지 궁금함

    • 아마 model+harness의 데카르트 곱 전체를 비교해야 할 듯함
    • 가장 많이 인용되는 건 terminal bench 2.0인데, 여기도 cheating 의혹과 benchmaxxing 문제를 피하진 못함
      꽤 놀랍게도 Opus 4.6에서 Claude Code가 꼴찌인데, 이게 Claude Code의 한계일 수도 있고 벤치마크 자체가 말해주는 바일 수도 있음
    • 미래는 인간형의 중앙집중 지능이 아니라, 문어형 분산 지능에 더 가까울 수도 있겠다는 생각도 듦
      그러면 핵심은 모델보다 harness 자체를 더 똑똑하게 만드는 쪽이 됨
    • 그게 결국 terminal-bench가 하는 일 아닌가 싶기도 함
    • 지난 몇 달간 같은 로컬 모델로 직접 테스트해보니, 내 환경에서는 Claude Code가 OpenCode보다 확실히 낫고 OpenCode가 Codex보다 나았음

  • 벤치마크라면 최소한 다른 계열 모델 하나는 더 넣어봐야 일반화되는지 알 수 있음
    비용을 생각하면 Minimax 2.7이 괜찮아 보이고, 그 전까지는 Gemini 3 Flash에 과적합된 결과인지 판단하기 어려움
    랜딩 페이지에도 현재 숫자가 전부 Gemini 3 Flash 기반이라는 걸 분명히 적어야 하고, 더 저렴한 게 같은 모델 기준으로 더 빠른 뜻이라면 완료 시간도 벤치마크에 넣는 편이 좋겠음
    아울러 skills, 중첩 AGENTS.md, MCP 지원 여부도 이주를 검토하는 사람에겐 중요함

    • Minimax 2.7로 직접 돌려봤는데 편집 툴을 꽤 싫어했고, 금방 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 같은 것도 충분히 구현 가능해 보였음
    프로젝트를 공개해줘서 고맙고 나중에 직접 살펴볼 생각임

    • 몇 달 전 어느 오후에 Cline이 너무 느려서 답답했고, 내부를 들여다보다가 몇 군데 고치기 시작했음
      그러다 점점 빨려 들어가서 변경 7만 줄, 삭제 4만 줄쯤 쌓인 뒤 두 달 지나 지금 상태가 됨
    • 요즘 local LLM과 새 harness들을 보고 있는데, Pi가 OpenCode보다 실제로 얼마나 나은지 궁금함
      최대로 활용하려면 어떤 모델과 커스터마이징 조합이 좋은지도 알고 싶음

  • 코드를 보다가 telemetry가 https://dirac.run/v1/event로 전송되는 걸 발견했음
    노골적으로 민감한 정보를 보내는 것 같진 않고 악의적으로 보이진 않지만, API 에러도 보내고 있어서 경우에 따라 민감한 내용이 새어 나갈 여지는 있음
    게다가 1인 개발자가 운영하는 엔드포인트로 opt-out 방식인 건 꽤 무섭게 느껴져서, 개인적으로는 이 지점 때문에 못 쓰겠음

    • 확인한 telemetry는 이 정도였음
      dirac.run/v1/event로 machine ID, 토큰 사용량, 모델 정보, 이벤트, 에러 앞 500자, 플랫폼 정보를 보냄
      dirac.run/v1/event/decide에서 기능 플래그를 60분마다 machine ID와 함께 조회하고, 이건 telemetry opt-out과 무관하게 항상 켜져 있으며 코드 수정 없이는 끌 수 없음
      웹 검색/웹 fetch 도구는 api.dirac.run을 경유해서 요청 내용과 시스템 헤더를 보냄
      모델 목록도 Anthropic provider를 쓰더라도 OpenRouter, HuggingFace, Groq 등에 조회를 날림
    • 고마움
      이건 Cline 포크라 telemetry 메커니즘을 그대로 물려받은 부분이고, 디버깅에 도움이 될까 해서 남겨둔 것뿐임
      악의적인 목적은 전혀 없고 PII를 생성하거나 저장하지도 않음

  • harness가 얼마나 중요한지가 핵심 포인트고, 이건 오래 남을 해석이라고 봄
    모델은 빌려 쓸 수 있고 프롬프트도 비슷하게 복제 가능하지만, 벤치 숫자의 상당 부분은 그 주변의 harness가 결정함
    같은 harness 아래서 Gemini를 Sonnet으로 바꾸는 변화보다, 같은 모델에서 harness를 바꾸는 변화가 더 클 수 있음
    네가 링크한 cheating-agents 글도 결국 같은 얘기고, 실제로 측정되는 건 harness이며 모델은 그 바탕 재료에 가까움
    다만 context management는 보편적 성질이라기보다 현재 세대 모델의 약점을 메우는 성격이 강해서, 몇 세대 지나면 도구가 질문 임베딩 기반 RAG를 밀어낸 것처럼 사라질 수도 있음

    • 그래서 ARC-AGI-3는 harness 사용을 허용하지 않음
      모델이 직접 harness를 만들어야 하게 해둠

  • 축하함, 정말 잘 만든 듯함
    지난 몇 주 동안 내 쪽에서도 harness를 만드는 일이 가장 재밌는 사이드 프로젝트였고, 늘 마무리는 못 하지만 특히 두 가지 경험이 궁금함
    컨텍스트 관리에서는 오래된 tool call 응답 가지치기, 출력 잘라내기, 자동 compaction이 꽤 잘 먹혔고, 모든 걸 기억하는 이득보다 컨텍스트를 줄이는 이득이 더 컸음
    대신 짧은 요약은 항상 남겨둠
    또 subagents 쪽은 메인 에이전트에 도구를 거의 노출하지 않고 run_agent 하나만 주며, 하위 에이전트가 search/execute/fetch를 쓰게 하는 식으로 실험 중임
    하위 에이전트가 간결한 요약만 돌려주면 상위 컨텍스트가 오래 깨끗하게 유지될 거라 보는데, 아직 프롬프트 설계는 더 실험 중임

    • 고마움
      API 캐싱을 지원한다면 pruning은 웬만하면 건드리지 않는 편이 낫고, prune 한 번 할 때마다 캐시가 깨져서 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과 하위 이슈로 정리해뒀음
    계획은 gpt5.5로 세웠고 완료 검증도 gpt5.5가 맡고 있음
    대규모 코드베이스 리팩터링에서는 Dirac이 OpenCode보다 생산적이었고, OpenCode는 .rs 파일을 망가뜨려서 되돌려야 했음

    • gpt-5.5에도 Dirac을 같이 쓰는지 궁금함
답변달기