LoopX

런타임은 그대로 두고 장시간 작업의 상태만 붙잡는 제공자 중립 컨트롤 플레인

curl -fsSL https://huangruiteng.github.io/loopx/install.sh | bash

오래 도는 에이전트 작업의 목표와 게이트, 할 일, 근거, 쿼터, 인계 상태를 한 층에 모아 두는 경량 상태 커널입니다. 일은 Codex 나 Claude Code, Cursor 같은 기존 런타임이 그대로 수행하고, LoopX 는 턴과 도구와 에이전트를 건너뛰며 그 상태가 이어지도록 관리합니다. 로컬 우선이고 파이썬 표준 라이브러리 밖 런타임 의존성이 없습니다.

판단

이럴 때 씁니다

여러 날에 걸친 엔지니어링이나 연구, 벤치마크 목표를 하나로 이어 가야 할 때
이슈와 PR 루프에서 범위와 근거와 리뷰 상태가 턴을 넘어 보존돼야 할 때
소유자 승인이나 안전, 공개 여부 같은 게이트가 작업 중간에 반복해서 필요할 때
여러 에이전트가 동료로 붙어 소유권과 리스와 인계가 중요해질 때
비개발 운영자에게도 진행 상황이 읽혀야 할 때

이럴 땐 쓰지 마세요

한 세션 안에서 끝나는 작업일 때. 지속 상태가 값을 못 합니다
무인 프로덕션 컨트롤러를 찾고 있을 때. 저장소가 그 용도가 아니라고 직접 밝힙니다
에이전트 프레임워크나 오케스트레이션 런타임 자체를 교체하려는 목적일 때
파이썬 3.11 이상을 두지 못하는 환경일 때

차별점

에이전트 프레임워크를 대체하지 않고 상태 층만 맡습니다. 실행 런타임은 쓰던 것을 그대로 둡니다.
모호한 대기 대신 구체적인 사용자 게이트를 세웁니다. 무엇을 물어보고 기다리는지가 상태로 남습니다.
쿼터가 다음 턴을 결정합니다. 유용한 전이가 없는데도 스케줄러가 계속 비용을 쓰는 상황을 막는 장치입니다.
등록된 에이전트는 동료 관계입니다. 점유와 리스와 능력으로 누가 다음에 움직일지 정하며 고정된 리더가 필요 없습니다.
Codex App 과 Codex CLI, Claude Code, OpenCode, Pi, 사용자 정의 러너까지 호스트별 진입 경로를 각각 문서화했습니다.

워크플로

01설치 스크립트로 loopx 를 올리고 loopx doctor 로 진단합니다.
02프로젝트 루트에서 loopx connect 로 연결하고 loopx status 로 현재 목표와 게이트와 다음 할 일을 확인합니다.
03상태가 없다고 나오면 loopx start-goal --guided 로 안내받으며 목표를 세웁니다.
04쓰는 호스트에 맞는 진입 방식을 고릅니다. Claude Code 는 옵트인 어댑터를 설치한 뒤 /loopx 로 시작해 /loop 로 돌리고, Codex CLI 는 프로젝트에서 연결한 뒤 $loopx 를 씁니다.
05루프가 도는 동안 핵심 틱은 다섯 개입니다. 지금 움직여도 되는지 묻고, 슬라이스를 점유하고, 바뀐 것을 적고, 다음 턴이 볼 상태를 갱신하고, 끝난 슬라이스를 쿼터에 기록합니다.

주요 명령

명령	설명
`curl -fsSL https://huangruiteng.github.io/loopx/install.sh \| bash`	클론 없이 설치합니다. 이후 ~/.local/bin 을 PATH 에 올립니다.
`loopx connect && loopx status`	프로젝트를 연결하고 현재 목표와 사용자 게이트와 다음 에이전트 할 일을 봅니다.
`loopx quota should-run`	이 등록된 에이전트가 지금 움직여야 하는지 판단합니다. 핵심 틱의 시작점입니다.
`loopx doctor`	설치와 연결 상태를 진단합니다. 연결 성공 판정의 기준입니다.
`loopx review-packet`	실행 이력과 검증, 블로커, 반영된 결과를 리뷰용으로 묶어 냅니다.

함정

설치 전에 확인하세요

.loopx/ 와 .codex/goals/ 와 .local/ 은 커밋하지 말고 무시 목록에 두어야 합니다. 런타임 상태가 저장소에 섞이면 인계가 깨집니다.
connect 는 기존 상태를 덮어쓰지 않고 재사용해야 합니다. 상태가 없다는 안내가 나올 때만 안내형 경로로 새로 세웁니다.
저장소가 내세우는 200시간대 사례는 경과한 실제 시간이지 연속 모델 실행이 아닙니다. 무인 자율 운영을 입증한 값이 아니라고 저장소가 직접 한정합니다.
독립 사용자 사례로 소개된 4일 무인 실행이나 10억 토큰 규모는 사용자 보고이며 저장소가 검증한 값이 아닙니다.
위험한 권한과 게시, 프로덕션 쓰기, 최종 소유권은 사람에게 남깁니다. 이 경계를 옮기는 용도로 설계되지 않았습니다.
Reward Memory 는 실험 기능이고 기본이 꺼져 있습니다.

검토 메모

공식 문서·릴리스·공개 자료를 바탕으로 정리한 편집 메모입니다.

저는 이 도구의 위치 선정이 정확하다고 봅니다. 오래 도는 작업이 무너지는 지점은 대개 모델의 능력이 아니라 상태입니다. 목표가 슬쩍 바뀌고, 소유자 결정이 중간에 끼어들고, 근거가 낡고, 스케줄러는 더 할 일이 없는데도 계속 돕니다. LoopX 는 그 상태만 따로 떼어 관리하고 실행은 쓰던 런타임에 맡깁니다. 프레임워크를 갈아엎지 않아도 된다는 점이 도입 문턱을 크게 낮춥니다.

제가 특히 좋게 보는 설계는 게이트를 구체적인 질문으로 남기게 한 부분입니다. 소유자 대기 중이라는 모호한 상태 대신 무엇을 묻고 있는지가 상태에 적히면, 며칠 뒤에 돌아온 사람이 맥락을 복원하는 비용이 줄어듭니다. 쿼터가 다음 턴을 결정한다는 것도 같은 계열의 판단입니다. 유용한 전이가 없을 때 멈추는 장치를 처음부터 넣어 둔 셈입니다.

다만 저장소가 내세우는 사례는 읽는 법을 알고 봐야 합니다. 200시간대라는 숫자는 경과한 달력 시간이지 연속 실행이 아니고, 4일 무인 운영이나 10억 토큰 규모는 사용자 보고이며 검증된 값이 아니라고 저장소가 스스로 밝혔습니다. 이 한정을 붙여 읽으면 과장으로 느껴지지 않고 오히려 신뢰가 갑니다. 무인 프로덕션 컨트롤러를 찾는 분이라면 이 도구는 답이 아니라는 점도 같은 문단에 적혀 있습니다.

도입한다면 상태 파일을 어디에 둘지부터 정하시기 바랍니다. 저장소가 런타임 상태 디렉터리들을 커밋하지 말고 무시 목록에 두라고 명시했는데, 이것을 지키지 않으면 여러 사람이 같은 저장소에서 일할 때 상태가 서로를 덮어씁니다. 연결 단계에서도 기존 상태를 재사용해야 하고 새로 세우는 경로는 상태가 없다고 안내가 나올 때만 쓰는 것이 맞습니다. 인계를 목적으로 도입하는 도구인 만큼 이 두 가지를 어기면 도입 이유 자체가 사라집니다.

비교

일반적인 에이전트 프레임워크가 실행 방식을 정하고 그 안에 상태를 담는다면, LoopX 는 실행을 남의 것으로 두고 상태만 가져갑니다. 그래서 Claude Code 를 쓰다가 Codex 로 옮겨도 목표와 게이트와 근거가 그대로 남습니다. 반대로 한 세션에서 끝나는 작업에는 얹을 이유가 없습니다.

최근 변경

v0.5.3에서는 선택된 Todo와 배송 워크스페이스가 quota 가드·정산·기능 재진입·외부 대기·replan·heartbeat 재생 전 구간에서 끊기지 않게 하고, Todo 완료·quota 소비·스케줄러 커밋·task-lease 정산을 타입이 정해진 트랜잭션 소유자 뒤로 옮겼습니다. ZCode·Antigravity CLI용 관리형 Goal 화면과 근거 기반 Deep Research 원장, Pi 세션 안에서의 task-lease 획득·갱신·이전 기능도 새로 추가됐습니다.

공식 변경 내역