Axocoatl
코딩 에이전트를 원격으로 실행하고, 호스트가 완료 시점을 결정하도록 하세요.
에이전트가 코드를 작성합니다. Axocoatl은 그 기록(receipt)을 작성합니다.
Claude Code, Codex 또는 로컬 모델이 샌드박스 내에서 작동하며, 해당 모델의 자격 증명(credential)은 절대 외부로 나가지 않습니다. 에이전트가 완료했다고 알리면, 호스트가 최종 파일에 대해 테스트를 실행하고 다른 모델이 변경 사항을 검토합니다. 사용자는 CI용 종료 코드(exit code), 모든 단계가 체크섬 처리된 기록, 그리고 해당 실행이 변경한 파일과 호스트가 강제한 내용을 담은 컴퓨터 서명 방식의 기록을 얻게 됩니다. 오픈 소스 Rust 실행 파일 하나로 구성되어 있으며, Axocoatl 계정이나 원격 측정 기능(telemetry)이 없습니다.
CI crates.io License
curl -fsSL https://axocoatl.ai/install.sh | sh
axocoatl onboard
axocoatl doctor
...
온보딩 과정에서 선택한 작성자에 맞는 로드아웃(loadout)을 실행하세요: 로컬 또는 OpenRouter 작성자의 경우 axocoatl run fix를 사용하고, Claude Code 또는 Codex의 경우 axocoatl run fix-claude-code 또는 axocoatl run fix-codex를 사용하며, 이때 동일한 플래그를 사용합니다. 각 명령어는 온보딩 과정에서 설정된 검토자를 사용합니다. --model writer=… 또는 --model reviewer=…을 사용하여 한 번의 실행에 다른 모델을 선택할 수 있습니다. 이 실행은 package.json, pyproject.toml 또는 requirements*.txt, go.mod 또는 Cargo.toml에서 저장소의 언어를 감지하고, 해당 언어의 공식 이미지 내에서 작동하며, 그 단계에만 해당 생태계의 패키지 레지스트리(package registry)가 열린 상태로 npm ci나 pip install -e '.[test]'와 같은 종속성 설치를 수행합니다. 그런 다음 작성자가 작업을 수행하고, 호스트는 npm test, pytest 또는 go test ./...와 같은 검사를 실행합니다. (저장소 툴체인 참조).
메모리 48GB의 Mac에서, Ollama 0.40.6 또는 그 이후 버전의 0.x 릴리스를 사용하여 qwen3-coder:30b (19 GB)을 작성용으로, gpt-oss:20b (14 GB)을 검토용으로 온보딩할 수 있습니다. 이 조합은 메모리 48GB의 Mac에서 엔드투엔드로 실행되었으며, 검토자로서의 gpt-oss:20b는 측정되지 않았습니다. 아래 측정에 사용된 검토자인 gpt-oss:120b (65 GB)는 약 96 GB 이상의 메모리가 필요합니다. 메모리가 부족하다면, OpenRouter를 검토자(또는 작성자 모두)로 사용하거나 Claude Code 또는 Codex를 작성자로 사용하십시오. 각 경로가 필요한 것과 다운로드하는 내용은 설치 페이지에서 확인할 수 있습니다.
표준 출력에 요약된 실제 실행 결과(진행 상황은 표준 에러로 전송됨):
axocoatl run fix를 1.5.0 릴리스 후보 버전으로, 상기 페이지 버그가 있는 작은 Go 리포지토리에서(go test ./... 검사 사용), qwen3-coder:30b 작성 및 gpt-oss:20b 검토를 Ollama 0.40.6에서 수행하고, axocoatl onboard로 설정된 메모리 48GB Mac에서 실행했습니다. 그 결과는 axocoatl receipt verify … --repo .으로 확인되었습니다. 이는 측정값이 아니라 형식을 보여줍니다.
Verdict: pass (exit 0)
Loadout: fix@1 sha256:54394b32ef032e2d879b089d8f049733119e6b04f54da026bcb7ecc2e2c94223
Checks:
...
- Claude Code 또는 Codex를 작성자로 한 번의 명령으로.
axocoatl run fix-claude-code --task "..." (또는 fix-codex)는 빌트인 fix 기능을 사용하며, 이 기능은 핀된 Claude Code CLI 또는 Codex CLI를 작성자(writer)로 사용하여 Session 컨테이너 내부의 비루트 사용자 권한으로 실행됩니다. 호스트 시스템은 동일한 검사 및 리뷰어 온보딩 설정을 통해 결과를 확인합니다. Claude Code는 Claude Pro 또는 Max 플랜과 컴퓨터에 설치된 claude CLI가 필요하며, Codex는 ChatGPT 플랜으로 로그인합니다. axocoatl onboard가 코드를 누가 작성할지 물을 때 둘 중 하나를 선택하면, 프로그램 이미지를 빌드하고 브라우저를 통해 사용자에게 로그인하게 합니다 (axocoatl connect claude-code는 claude setup-token을 실행하고; axocoatl connect codex는 ChatGPT 로그인 과정을 거칩니다). 그리고 이 자격 증명(credential)은 화면에 표시되지 않은 채 컴퓨터에 저장됩니다. 데몬은 이를 호스트의 모든 모델 요청에 추가하며, 컨테이너에는 플레이스홀더가 유지됩니다. 둘 다 프로그램이 레포지토리의 툴체인에 추가되고 그 의존성이 먼저 설치되는 이미지를 사용하여 실행되므로, npm test, pytest 또는 go test ./...와 같은 레포지토리 자체 검사가 fix를 위해 실행될 때와 동일하게 실행됩니다. 모델이나 검사, 예산 등을 변경하려면 사용자만의 로드아웃을 작성하세요.
<p align="center">
<img src="https://raw.githubusercontent.com/axocoatl/axocoatl/HEAD/sites/marketing/assets/og-home.png" alt="Axocoatl: 코딩 에이전트를 원격으로 실행합니다. 샌드박스 내에서 Claude Code, Codex 또는 로컬 모델 사용; 호스트는 최종 파일에 대한 검사를 실행하고; 다른 모델이 변경 사항을 리뷰하며; CI용 종료 코드와 체크섬 기록을 제공합니다." width="760">
</p>
실행(run)의 작동 방식
로드아웃(loadout)은 한 번의 실행을 위한 YAML 레시피입니다. 여기에는 에이전트(모델 기반 워커)와 그들의 모델, 타임아웃과 함께 필요한 검사 항목들, 필수 리뷰어, 네트워크 정보, 예산, 그리고 프롬프트가 포함됩니다. axocoatl run은 이 로드아웃을 실행 중인 데몬에 전달하며, 데몬은 이를 **세션(Session)**에서 실행합니다. 세션이란 대화 내용, 도구가 실행되는 샌드박스, 그리고 기록이 있는 지속적인 작업 항목입니다.
- 다섯 가지 내장 로드아웃.
fix는 한 명의 라이터와 필수 검사 항목으로 지정된 사용자님의 검사 명령을 실행하고, 최대 3라운드 동안 다른 모델에 의한 필수 리뷰를 수행합니다. 이 라이터는 발견된 모든 사항에 대해 수락 또는 거부 및 이유를 답변해야 합니다. fix-claude-code와 fix-codex는 라이터를 Claude Code 또는 Codex로 사용하는 fix입니다. qa는 브라우저 탐색기 하나를 실행하며, 이 탐색기가 발견한 사항에는 Playwright 재현 기록이 포함되어 호스트가 다시 실행합니다. audit(선택적: 이름으로 지정될 때만 실행)은 영역을 계획하고, 병렬 읽기 전용 워커로 이를 읽어와 발견된 사항들을 병합합니다. 사용자만의 로드아웃은 설정 파일 옆의 loadouts/ 디렉토리에 있는 YAML 파일입니다.
- 직접적인 네트워크가 없는 샌드박스. 로드아웃의 세션은 항상 네트워크 이그레스(또는 없음)와 비루트 워크로드 사용자로 실행됩니다. 컨테이너는 직접적인 네트워크 접근이 불가능하며, 외부로는 데몬의 이그레스 프록시 및 라우트를 통해서만 도달할 수 있고, 이들이 모든 연결을 결정하고 기록합니다. 기본적으로 모델 API로 가는 경로는 호출이 나가는 전에 각 모델 호출을 읽고, 제공자에게 URL 가져오기, 웹 검색, 자체 도구 실행 또는 MCP 서버에 연결하도록 요청하는 것은 거부하고 기록합니다. 사용자님의 전역 기본 설정은 변경되지 않습니다.
- 호스트가 결정합니다. 필수 검사 항목은 호스트에 의해 정확한 최종 파일에서 실행됩니다. 라이터의 모델에 대한 리뷰어는 경고를 받지만, 거부되지는 않습니다. 답변되지 않은 발견 사항, 실행되지 않은 검사 항목, 또는 다뤄지지 않은 모든 것은 해당 실행이 주의를 요하게 만듭니다. 기본적으로 아무것도 통과하지 않습니다.
- CI용 판결. 종료 코드: 0은 통과, 1은 검사 실패, 2는 주의 필요, 3은 사용량 관련, 4는 데몬 이용 불가, 5는 인프라 문제, 6은 중단됨, 7은 바쁨.
--junit은 검사(checks), 검토(review), 판정(adjudications), 발견 사항(findings) 및 커버리지에 대한 JUnit을 작성합니다. --record는 전체 실행 결과를 하나의 JSON Lines 파일로 작성하며, 이 파일에는 라인 수와 SHA-256이 포함되어 있으며, 이는 axocoatl record verify가 검사합니다. 이 기록은 서명되는 것이 아니라 체크섬(checksummed) 처리됩니다.
- 서명된 영수증(A signed receipt). 완료된 모든
axocoatl run (성공 여부와 관계없이)에는 데이터 디렉터리에 보관된 Ed25519 키로 서명된 영수증이 생성됩니다 (workbench는 이를 얻지 못함): 이는 in-toto 명세서이며 DSSE(Digital Signature Service Envelope) 형식에 담겨 있으며, 실행 중 변경된 파일 목록과 해당 SHA-256 값 (요구되는 검사들이 판단했을 때의 값), 샌드박스 및 네트워크 정책, 검사 내용, 검토 결과, 모델, 그리고 최종 판정(verdict)을 나열합니다. --receipt는 이를 작성하며, axocoatl receipt verify는 신뢰하는 키들(axocoatl receipt key가 사용자 키를 출력함)과 오프라인으로 비교하고, --repo와 함께 체크아웃된 파일들과 비교합니다. 이는 어떤 키가 어떤 사실들을 서명했는지 증명할 뿐, 변경 자체가 올바른지는 증명하지 않습니다.
- PR로 유지(Keep as PR).
--keep branch는 사용자의 git을 사용하여 실행으로 인해 변경된 경로만을 새로운 브랜치에 커밋하며, 체크아웃은 건드리지 않고, Axocoatl-Run 및 Axocoatl-Receipt 트레일러를 추가합니다. 검사들이 판단한 이후 수정된 경로는 거부됩니다. --keep pr는 이를 푸시하고 gh을 사용하여 풀 리퀘스트(pull request)를 열며, 이 PR의 설명에는 영수증이 포함됩니다.
세부 정보: Loadouts,
axocoatl run,
Fix, QA and audit runs,
Signed receipts 및
Keep as PR.
우리가 측정한 것 (What we measured)
<!-- measured: axocoatl-1.1.0 2026-10-01 -->
Axocoatl 1.1.0을 통해 측정된 소규모 로컬 모델의 사전 등록 벤치마크와 비교를 위해 일반 에이전트 루프가 있습니다: 2026년 9월 22일 기준으로 고정된 6개의 Python 유지보수 작업에 대해, 에이전트들이 본 적 없는 25개의 보류 테스트(withheld tests)로 점수가 매겨졌습니다. 작성자는 로컬에서 실행되는 qwen3-coder 30B입니다; 작업당 한 번의 실행을 사용하며, 온도는 0입니다.
Axocoatl 1.1.0을 통해:
| 설정 | 보류된 테스트 통과 수 | 한 번의 실행 대비 토큰 사용량 |
|---|
| 에이전트 1개, 실행 1회 | 17 / 25 | 1× |
| 더 강력한 로컬 모델(gpt-oss 120B)의 필수 검토를 거친 동일 작가 | 19 / 25 | 2.6× |
검토자는 결함을 15개 보고했으며, 그중 14개가 실제였습니다. 작성자는 테스트 비용이 들었던 하나의 오경보(false alarm)를 포함하여 받은 모든 발견 사항을 적용했고, 6개의 실제 발견 사항은 두 번째이자 마지막 검토 라운드에서 나왔으며, 그 후 Axocoatl은 수정 작업을 중단합니다.
추가 토큰이 도움이 되는 경우 (동일한 작업, 일반 에이전트 루프를 통한 것이 아닌):
| 설정 | 보류된 테스트 통과 수 | 한 번의 실행 대비 토큰 사용량 |
|---|
| 동일 에이전트가 자신의 작업을 검토하는 경우 | 17 / 25 | 3.5× |
| ... | <!-- /measured --> | |
더 강력하고 다른 검토자가 작은 로컬 작가를 도왔지만, 같은 모델의 두 번째 확인은 그렇지 않았습니다. 즉, 추가 토큰은 더 많은 확인이 아니라 더 강력한 모델의 판단을 구매했을 때 도움이 되었습니다. 이것은 두 개의 로컬 모델을 사용한 하나의 작은 벤치마크일 뿐이며, Axocoatl이 에이전트를 더 좋게 만든다는 주장은 아닙니다. Axocoatl은 각 에이전트가 자체 모델을 사용할 수 있게 하므로, 로컬 작가는 다른 모델의 검토를 받을 수 있고 호스트는 여전히 사용자의 확인 작업을 실행하고 모든 단계를 기록합니다. 우리가 측정한 검토자는 로컬에서 실행되었으며, OpenRouter를 통한 검토자나 내장된 로드아웃은 측정되지 않았습니다. 기본 팀이 단일 에이전트보다 낫다고 주장하지 않으며, 여전히 하나의 에이전트가 작은 작업에 더 저렴한 선택지입니다.
내장된 로드아웃은 작가 1명 또는 탐험가 1명을 실행하며, audit는 Axocoatl을 통해 실행된 것이 아니라 Claude Code 서브에이전트를 사용해 진행된 연구를 따르는 옵트인(opt-in) 기능입니다. 방법과 한계는 What we measured에서, 그리고 모든 공개 수치와 그 증거는 docs/CLAIMS.md에 있습니다.
경계가 작동하는 방식
내장된 격리(Isolation built in)
- 모든 세션의 리포지토리 도구는 샌드박스에서 실행됩니다. 파일, 셸 및 터미널 도구는 기본적으로 사용자의 머신에 루트리스(rootless) Podman 컨테이너에서 실행됩니다. E2B Cloud는 호환성 경로 상의 명시적 원격 옵션입니다. 웹 및 MCP 도구는 호스트에서 실행되며, 브라우저 도구는 자체 컨테이너에서 실행됩니다. 인터랙티브 세션은 기본적으로 네트워크 접근 권한을 가집니다 (
sandbox.network: bridge); 신뢰하지 않는 리포지토리의 경우 sandbox.network: none으로 설정하세요. 로드아웃(loadout) 실행 컨테이너는 직접적인 네트워크 접근 권한이 없습니다 (위 참조).
- 읽기 전용 헬퍼는 파일을 쓰거나 TCP 연결을 열 수 없습니다. 이들은 파일 쓰기 도구를 받지 못하며, 커널은 리포지토리 파일에 대한 쓰기, 생성, 이름 변경 또는 삭제를 막고(Landlock, Linux 6.7 이상), TCP 연결을 여는 것을 차단합니다. 그렇지 않으면 셸도 받지 못합니다. root로 실행되는 헬퍼의 셸이나 macOS의 경우 어떤 셸이라도 권한 비트와 타임스탬프를 변경할 수 있습니다; UDP는 샌드박스의 네트워크 설정을 따르며; 웹 또는 브라우저 도구의 템플릿 목록은 여전히 외부로 연결됩니다. 보안 가이드를 참조하세요.
- 하나의 체크아웃 내에서 에이전트별 쓰기 범위(write scopes). 에이전트의 파일 도구는 자신의 범위를 벗어나는 경로를 거부하며, 에이전트가 만든 모든 변경 사항은 작업 전후 리포지토리의 완전하고 다이제스트 검증된 스냅샷과 비교됩니다. 셸을 가진 에이전트에게 그 확인 과정은 구속(confinement)이 아니라 검토 증거(review evidence)입니다.
완벽한 기록