에이전트 열 개가 클로드 코드 하나보다 가볍습니다, jcode의 숫자 전쟁

에이전트 열 개를 띄우는 데 117MB면 됩니다. 클로드 코드는 열 개에 2.3GB예요. 이 표 하나로 8개월 만에 깃허브 스타 1만 8천을 모은 하네스가 있습니다. jcode입니다.

README 첫 화면이 비교표입니다

올해 1월에 나온 러스트 오픈소스 하네스인데, 레포 자기소개부터 도발적입니다. "가장 램 효율적인 하네스. 가장 지능적인 하네스."

그리고 첫 화면에서 바로 표가 나옵니다.

램 (1세션): jcode 27.8MB. 클로드 코드 386.6MB(13.9배), 오픈코드 371.5MB(13.4배), 커서 에이전트 214.9MB(7.7배)

램 (10세션): jcode 117MB. 클로드 코드 2.3GB(19.7배), 오픈코드 3.2GB(27.7배)

첫 화면까지: jcode 14ms. 코덱스 CLI 63배, 커서 139배, 클로드 코드 245배 느림

측정 조건과 범위까지 다 적어놨습니다. 남의 벤치마크를 기다리지 않고 자기 레포 첫 화면을 전장으로 만든 거예요. 이 표들이 그대로 밈이 되면서 퍼졌습니다.

숫자는 미끼고, 본체는 스웜입니다

램 수치는 사람을 데려오는 미끼입니다. 잡아두는 건 스웜이에요.

같은 레포에서 도는 jcode 에이전트들은 서로를 압니다.

• 하나가 파일을 고치면, 그 파일을 읽고 있던 에이전트에게 알림이 갑니다
• 에이전트끼리 DM을 보내고, 레포 전체에 방송을 합니다
• 코디네이터가 일꾼 에이전트를 알아서 늘립니다
• 과제 그래프로 의존 관계를 관리합니다

격리된 병렬이 아니라 협업하는 무리입니다. jcode serve로 상주 서버를 띄우면 가벼운 클라이언트 여럿이 붙고, 클라이언트가 끊겨도 세션은 계속 돕니다.

램을 극단적으로 줄인 이유가 여기서 드러납니다. 에이전트를 떼로 굴리는 미래에 배팅한 설계예요. 무거우면 무리를 못 만드니까.

벤치마크까지 직접 만듭니다

제작자 @1jehuang은 이번 주에 Jcode Bench라는 벤치마크도 발표했습니다. 주장이 흥미로워요. "오염 불가능한 최초의 오픈 벤치마크."

기준 구현 하나를 주고 최대한 최적화하게 하는 방식입니다. 정답이 없는 과제라 훈련 데이터에 답이 못 들어가고, 오염이 의심되면 새 과제를 스펙에서 생성해 다시 돌리면 됩니다.

어제는 ratatui 메인테이너가 직접 소개 트윗을 올렸습니다. 러스트 터미널 UI 생태계의 공인을 받은 셈이에요. YC 런치 영상까지 레포에 걸려 있습니다.

남는 생각

하네스 경쟁의 무기가 바뀌는 중입니다.

작년의 경쟁이 기능 목록이었다면, 지금은 자원 효율이 전면에 나왔어요. 에이전트를 하나 쓰는 사람에겐 386MB도 27.8MB도 차이가 없습니다. 열 개, 스무 개를 굴리기 시작하면 그 차이가 곧 한계 대수가 되고요.

에이전트 하나 만들고 끝이 아니라 벤치까지 세트로 판을 짜는 8개월짜리 프로젝트. 숫자를 무기로 쓰는 법을 아는 물건입니다.

---

출처: 1jehuang/jcode 레포 실측(README 벤치마크 표·스타 18,534·생성일 2026-01-05), @orhundev 발표 트윗 전문(aside), Jcode Bench 발표(@1jehuang, 그록 회수 후 대조). 수치는 전부 레포 README 기준.