5 Takeaways from the ClaudeCode Leak

2026-03-31 · 17m · 자막 —

01한국어 번역 · Korean

클로드 코드(Claude Code) 유출 사태에서 얻은 5가지 핵심 발견

원본: https://www.youtube.com/watch?v=Z8xARjBoBgk · 업로드: 2026-03-31 · 길이: 17m · 채널: Onchain AI Garage

들어가며: 무슨 일이 벌어졌나

오늘 아침, 많은 사람들이 이른바 “클로드 코드(Claude Code) 유출” 소식을 접했다. 이 사건의 발단은 보안 연구자 차오판 쇼우(Chaofan Shou)의 꽤 놀라운 발견이었다. 그는 공식 클로드 코드 NPM 패키지 최신 버전에 약 60MB 크기의 소스 맵(source map) 파일이 함께 배포되었고, 이 파일이 클로드 코드의 완전한 타입스크립트(TypeScript) 원본 소스를 참조하고 있다는 사실을 찾아냈다. 더 놀라운 것은 원본 소스가 앤트로픽(Anthropic) 자체 R2 클라우드 스토리지 버킷에 그대로 놓여 있어서, 누구든 접근만 할 수 있다면 ZIP 파일로 통째로 내려받을 수 있었다는 점이다.

이런 일이 처음도 아니다. 불과 얼마 전인 2월에도 동일한 성격의 사고가 앤트로픽에서 발생했고, 오늘 다시 같은 유형의 유출이 반복된 것이다.

나는 블로그 글이나 트위터 쓰레드, 자극적인 보도 대신 유출된 원본 코드를 직접 훑어봤다. 그리고 AI 연구·엔지니어링에 관심 있는 분들에게 가장 흥미로울 만한 다섯 가지 발견을 짧게 공유하려 한다. 다만 본격적인 다섯 가지 교훈으로 들어가기 전에, 가장 많은 사람들이 궁금해하는 주제인 “모델”에 관한 단서부터 짚어보자.

모델 관련 단서: 차세대 모델은 없었다

유출된 코드는 대략 1,900개 이상의 파일, 50만 줄이 넘는 타입스크립트로 구성돼 있었고, 런타임 도구와 게이팅 로직까지 포함되어 있었다. 모델 레지스트리는 configs.typescript라는 파일에 비교적 단순하게 정리돼 있었다. 시스템이 인지하는 모든 모델에 대해 설정 객체가 하나씩 있고, 퍼스트 파티·베드록(Bedrock)·버텍스(Vertex)·파운드리(Foundry)용 ID가 담겨 있었다.

현재 기본값은 맥스(Max) 구독자에게는 오푸스(Opus) 4.6, 그 외 사용자에게는 소넷(Sonnet) 4.6이었다. 작고 빠른 모델로는 하이쿠(Haiku) 4.5가 있다. 전반적으로 이미 공개된 것과 다르지 않다. 코드 어디에도 오푸스 4.7이나 5.0 같은 차세대 모델 ID는 보이지 않았다. 다만 “모델 출시(model launch)” 주석이 코드 곳곳에 수동 체크리스트처럼 흩어져 있을 뿐이었다.

카피바라(Capybara)의 정체

최근 SNS에서 “카피바라”라는 이름이 차세대 모델 혹은 사이버 보안 위협이라는 루머와 함께 크게 주목받았다. 그러나 코드를 보면 카피바라는 앤트로픽 내부 직원용 모델 별칭(alias) 으로 보인다. 아직 새로운 모델 패밀리로 확정된 것은 아니다.

앤트로픽 직원들은 스스로를 내부적으로 “앤트(ant)“라고 부르며, 사용자 타입 자체가 문자 그대로 ant다. 이들에게는 Tengu ant model override라는 그로스북(GrowthBook) 기능 플래그가 붙어 있는데, 이 플래그가 모델 별칭 목록을 동적으로 내려보내고 카피바라는 그중 하나로 런타임에 어떤 내부 모델 변형(variant)으로 해석(resolve)된다.

확실한 것은 카피바라가 오푸스나 소넷과는 구분되는 별개의 체크포인트라는 점이다. 심지어 오푸스와 호환되지 않는 독자적인 “사고(thinking) 포맷”을 갖고 있다. 사전 공개 모델인지, 실험적 변형인지, 파인튜닝 빌드인지는 코드만으로는 알 수 없다.

참고로 중요한 점은, 내부 코드네임 대부분이 유출된 NPM 패키지에는 포함되지 않았다는 것이다. 우리가 본 것은 주석과 변수 이름에 흘러나온 부스러기뿐이다. “텐구(Tengu)“라는 이름이 자주 등장하는데, 이것이 클로드 코드 자체의 내부 코드네임이다.

결론적으로 모델 측면에서 “클로드 5”나 충격적인 차세대 ID는 없었다. 그러나 앤트로픽 직원들이 실제로 사용 중인 카피바라라는 내부 별칭의 존재는 흥미롭고, 그 정체가 곧 드러나기를 기대해 본다.

핵심 발견 1. 드리밍(Dreaming) — 자율적 메모리 통합

이번 유출 코드베이스에서 가장 흥미로웠던 것은 단연 “드리밍” 개념, 정확히는 autoDream이라 불리는 백그라운드 프로세스였다. 이는 에이전트가 스스로 메모리를 통합하는 자율 프로세스다.

배경은 이렇다. 클로드 코드는 마크다운 파일들이 모인 디렉터리 형태의 지속 메모리 시스템을 갖고 있다. 세션을 거듭할수록 관찰 결과, 정정 사항, 사용자 선호 같은 원시 신호들이 누적된다. 문제는 그대로 두면 파일이 비대해지고, 시간이 지나며 모순되거나 낡은 정보가 쌓인다는 것이다.

이를 해결하기 위해 설계된 것이 드리밍 시스템이고, 게이트(gate) 방식으로 동작한다. 가장 값싼 체크부터 순서대로 통과해야 실행된다.

마지막 통합 이후 24시간이 지났는가? (타임스탬프 비교만 하면 된다)
그 이후 최소 5개 세션이 쌓였는가? (트랜스크립트 파일 스캔 필요)
락(lock)을 획득할 수 있는가? (다른 프로세스가 드리밍 중이면 안 된다)

세 게이트를 모두 통과하면, 이른바 “포크(fork)된 에이전트” 혹은 “스폰(spawn)된 에이전트”가 띄워진다. 읽기 전용 배시(bash) 권한만 가진 샌드박스 클로드 인스턴스다. 이 에이전트는 “통합 프롬프트(consolidation prompt)“라는 상세한 지시를 받고, 네 단계를 밟아 나간다.

Read — 기존 메모리 인덱스를 먼저 읽어 전체 지형을 파악한다.
Gather — 일일 로그와 세션 트랜스크립트에서 새로운 신호를 매우 좁은 범위로만 뽑는다. 파일 전체를 다 읽는 것이 아니다.
Consolidate — 새 정보를 관련 토픽 파일에 병합하고, 상대 날짜를 절대 날짜로 변환하며, 반박된 사실은 제거한다.
Prune — 인덱스를 200줄 미만으로 유지하도록 가지치기를 한다.

이 구조는 세션 중에는 빠른 “에피소드 메모리” 포착이, 세션 외에는 느린 “의미 기억” 통합이 이루어지는 이중 단계 메모리 아키텍처를 만든다. 앤트로픽이 이를 “드리밍”이라 부르는 이유는 명백하다. 수면 중 메모리 통합을 다루는 신경과학 모델과 직접적으로 닮았기 때문이다.

이 드리밍 프로세스는 카이로스(Kairos)라 불리는 “상시 가동(always-on)” 모드와 연결되어 있다. 카이로스는 사실상 영구적으로 유지되는 세션이다. 기존 대화형 클로드 코드와 달리 에이전트가 실시간으로 메모리를 정리하지 않고, 일단 일일 로그(append-only)에 받아쓰기만 한다. 그런 다음 드리밍 프로세스가 이 로그들을 토픽 파일로 증류하고 인덱스를 갱신한다.

또 한 가지 흥미로운 것은 UI 통합이다. 드리밍은 자체 태스크 트래킹을 갖고 있어서 사용자는 “7개 세션 리뷰 중” 같은 백그라운드 작업을 UI에서 확인할 수 있고, 원한다면 직접 중단할 수도 있다.

핵심 발견 2. LLM 기반 메모리 검색

두 번째 발견은 메모리 시스템과 연결된 LLM 기반 검색이다. 수십 개의 토픽 파일이 쌓였을 때, 현재 대화에 어떤 파일을 끌어올지 결정해야 한다. 2026년 기준 가장 뻔한 답은 벡터 임베딩(embedding)이다. 질의와 메모리를 임베딩해 코사인 유사도로 비교하는 고전적 RAG 방식이다.

그러나 클로드 코드는 그렇게 하지 않는다. 언어 모델 자체를 검색 엔진으로 쓴다. 사용자의 질의가 들어오면 시스템은 모든 메모리 파일을 스캔해 각 파일의 프런트매터(name, description, type 필드)만 뽑는다. 이를 매니페스트(manifest) 형태로 정리한 뒤 “사이드 쿼리(side query)“를 소넷에 날린다. 별도의 가볍고 병렬적인 API 호출이며, 시스템 프롬프트는 대략 “클로드 코드에 유용할 메모리를 고르고, 최대 5개 파일명을 반환하라”는 내용이다. 응답은 JSON으로 돌아온다.

구현에는 흥미로운 디테일이 있다. 시스템은 최근 어떤 도구가 사용됐는지를 추적한다. 예컨대 사용자가 배시 도구를 자주 쓰고 있다면, 선택자(selector)에게 “배시 참고 문서는 건너뛰라”고 알려준다. 이미 대화에 작동 중인 사용 예가 들어있으니 레퍼런스를 다시 띄우는 것은 노이즈가 되기 때문이다. 다만 해당 도구의 경고, 함정, 알려진 이슈는 여전히 띄워준다. 이것이 이들의 “안티 노이즈(anti-noise)” 장치다.

이 접근이 가진 명백한 장점은 LLM이 의미적 연관성을 추론할 수 있다는 점이다. 키워드가 하나도 겹치지 않아도 두 문서가 관련 있음을 이해할 수 있다. API 호출이 늘어 비용이 올라가는 단점이 있지만, 오푸스가 아니라 소넷을 쓰는 것으로 일부를 상쇄하고 있다.

핵심 발견 3. 언더커버(Undercover) 모드

세 번째는 다소 논란이 된 기능이다. 언더커버 모드는 클로드가 공개 저장소에 기여할 때 자신이 AI라는 사실을 드러내지 않도록 막는 시스템이다.

중요한 맥락이 있다. 이 기능의 모든 코드는 환경 변수와 내부 직원 사용자 변수로 게이팅되어 있다. 즉 앤트로픽 내부 빌드에만 존재하고, 공개 NPM 패키지에서는 모든 관련 함수가 no-op(아무 것도 하지 않는 빈 함수)로 치환된다.

파일 헤더에는 목적이 명시돼 있다. “공개 오픈소스 저장소에 기여하기 위한 안전 유틸리티”다. 이 모드가 활성화되면 클로드 코드는 커밋과 PR에서 모든 귀속(attribution) 정보를 제거해 내부 정보가 새지 않게 한다. 여기서 한 발 더 나아간다. 주입되는 시스템 프롬프트는 매우 직설적으로 이렇게 말한다. “당신은 지금 공개 저장소에서 잠입 활동 중이다. 커밋에 앤트로픽 내부 정보를 포함해서는 안 된다. 정체가 탄로나선 안 된다. 모델 코드네임이나 버전 번호, 내부 프로젝트명, ‘클로드 코드’라는 표현, AI임을 드러내거나 Co-authored-by 라인을 포함하지 말라. 인간 개발자가 쓸 법한 커밋 메시지를 써라.”

보안 명분은 분명하다. 앤트로픽 입장에서는 내부 코드네임이 공개 커밋 이력에 남는 것을 원치 않는다. 지식재산의 한 부분이기 때문이다. 그러나 이 모드는 AI 투명성, 코드 출처(provenance), 오픈소스 규범과 관련해 정당한 질문들을 야기한다. AI 회사가 스스로 만든 AI를 “인간 개발자처럼 행동하라”고 지시하는 도구를 내부에서 쓰고 있다면, 오픈소스 커뮤니티는 어떤 메시지를 받게 될까? 보안상 합당한 이유와 투명성에 대한 우려가 모두 존재한다.

핵심 발견 4. 코디네이터(Coordinator) 모드

네 번째는 기능 플래그 뒤에 숨겨진 완전한 다중 에이전트 오케스트레이션 시스템이다. 이 모드가 켜지면 클로드 코드는 단일 에이전트에서 코드를 직접 건드리지 않는 코디네이터(조율자) 로 탈바꿈한다. 코디네이터는 워커 에이전트를 스폰·지속·중단할 뿐이다.

코디네이터는 방대한 시스템 프롬프트를 갖고 있고, 워크플로는 네 단계로 구성된다.

연구(Research) — 워커들이 병렬로 파견돼 다양한 각도에서 코드베이스를 조사한다.
종합(Synthesis) — 코디네이터가 직접 워커들의 조사 결과를 본인이 이해해야 한다. 프롬프트는 “based on your findings(당신의 조사 결과에 따르면)” 같은 표현을 문자 그대로 금지한다. 대신 코디네이터는 구체적인 파일 경로, 라인 번호, 정확한 수정 내용이 담긴 구현 스펙을 써야 한다.
구현(Implementation) — 같은 파일 집합에 두 워커가 동시에 손대지 않도록 직렬로 나눠 할당한다.
검증(Verification) — 구현한 워커와 다른 워커가 반드시 검증한다. 동일 워커는 자신의 전제를 그대로 끌고 가기 때문이다. 검증 기준도 높다. “검증이란 코드가 존재함을 확인하는 것이 아니라, 동작함을 증명하는 것이다. 대충 도장만 찍는 검증자는 모든 것을 망친다.” 워커들은 기능 플래그를 켠 상태로 테스트를 돌려야 하고, 타입 오류를 “무관한 것”이라 넘기지 않고 실제로 조사해야 하며, 회의적인 태도를 유지해야 한다.

또 흥미로운 장치는 “스크래치패드(scratchpad)“다. 워커들이 권한 프롬프트 없이 읽고 쓸 수 있는 공유 디렉터리로, 크로스 워커 지식 공유가 가능하다. 코디네이터는 워커들에게 “크로스 워커 지식을 위해 이 디렉터리를 쓰고, 필요한 만큼 자유롭게 구조화하라”고 지시한다.

핵심 발견 5. 버디(Buddy) — AI 컴패니언

다섯 번째는 즐거운 발견이다. 버디는 아직 출시되지 않은 기능으로, 결정론적 절차 생성(procedural generation)으로 만들어지는 다마고치 스타일의 ASCII 펫이다. 고양이, 유령, 카피바라, 버섯, 펭귄 등 18종이 존재한다.

기술적으로 흥미로운 점은, 모든 사용자가 자신의 유저 ID로부터 결정론적으로 도출된 컴패니언을 받는다는 것이다. 유저 ID를 특정 시드와 해시해서 종(species), 스타일, 모자, 희귀도까지 전부 시드에서 뽑아낸다. 각각 다른 애니메이션, 길이, 눈 스타일을 갖고 있고, 가챠 게임처럼 희귀도 체계도 있다. 60% 커먼, 1% 샤이니, 1% 레거시 같은 식이다.

아키텍처 결정이 영리한 부분은 “bones / soul” 분리다. Bones는 종·희귀도·스탯 같은 결정론적 물리 특성으로, 디스크에 저장되지 않고 매번 유저 ID의 시드에서 재생성된다. Soul은 이름과 성격처럼 모델이 생성하는 부분으로, 처음 부화될 때 만들어져 세션 간 영속화된다. 컴패니언은 작은 말풍선으로 사용자에게 말을 건다. 절차 생성 규칙이 시간이 지남에 따라 진화해야 하는 시스템에서, 즐겁고 영속적인 엔티티를 만드는 사례 연구로 훌륭하다.

마무리

원본 트윗의 주인공인 차오판 쇼우와, 누출 직후 빠르게 특정 기능을 파이썬으로 포팅해 공개한 사람들, 러스트로 리버스 엔지니어링 중인 사람들에게 공을 돌린다. 물론 원본을 단순 미러링한 사람들도 있다.

나는 이 영상을 가능한 한 빨리 내놓고 싶었다. 오늘 아침에 소식을 접했고, 코드베이스에서 어떤 교훈을 배울 수 있는지 공유하는 것이 흥미로웠기 때문이다. 한 가지 분명히 해둘 것이 있다. 클로드 코드와 클로드는 앤트로픽의 상표이고, 원본 소스 코드는 앤트로픽의 재산이다. 따라서 나는 원본을 미러링하거나 포팅하지 않는다. 우리는 거기 담긴 아이디어에서 배움을 얻을 수 있을 뿐이다.

02리서치 문서 · Document

클로드 코드(Claude Code) 소스 유출이 드러낸 차세대 AI 에이전트의 청사진

원본 영상: YouTube · 채널: Onchain AI Garage · 업로드: 2026-03-31

서론: 우연한 유출, 의도치 않은 로드맵 공개

2026년 3월 31일, 보안 연구자 차오판 쇼우(Chaofan Shou)는 공식 @anthropic-ai/claude-code NPM 패키지 버전 2.1.88에서 약 59.8MB 크기의 자바스크립트 소스 맵(.map) 파일을 발견했다. 이 파일은 앤트로픽(Anthropic) 자체 R2 클라우드 스토리지 버킷에 호스팅된 난독화되지 않은 타입스크립트 원본을 그대로 참조하고 있었다. 결과적으로 약 1,900여 개 파일에 걸친 51만 줄이 넘는 클라이언트 측 에이전트 하네스가 누구나 내려받을 수 있는 상태로 노출되었다(InfoQ 보도, The Hacker News).

앤트로픽은 CNBC를 통해 이를 “보안 침해가 아니라 사람의 실수로 인한 릴리스 패키징 문제”이며 고객 데이터나 자격 증명은 포함되지 않았다고 해명했다(VentureBeat). 그러나 보안 사고라는 측면을 잠시 제쳐두면, 이번 유출은 전례가 드문 형태의 “로드맵 공개”이기도 했다. 단순한 모델 성능 수치나 벤치마크가 아니라, 차세대 AI 에이전트가 어떻게 설계되고 운영되는가 를 드러냈기 때문이다.

Onchain AI Garage의 이 영상은 51만 줄의 코드 중 실무에 의미 있다고 판단한 다섯 가지를 추려 설명한다. 이 글에서는 그 다섯 가지를 더 넓은 맥락에서 풀어보고, 각 기능이 AI 엔지니어링 실무자에게 어떤 신호를 주는지 살펴본다.

본론

1. 유출이 일어난 방식: 번(Bun) 런타임과 사라진 `.npmignore`

이번 사고의 기술적 원인은 간단하다. 클로드 코드는 번(Bun) 런타임을 사용하는데, 번은 기본적으로 소스 맵을 생성한다. 개발자가 .npmignore에 *.map을 추가하거나 package.json의 files 필드에 화이트리스트를 두거나, 혹은 npm pack으로 사전 검증했다면 이번 노출은 발생하지 않았을 것이다(The Register).

눈여겨볼 것은, 이번이 2026년 들어 두 번째로 발생한 유사 사고라는 점이다. 2월에도 비슷한 유형의 노출이 있었다. 즉, 이것은 한 사람의 실수가 아니라 패키징 파이프라인 그 자체에 안전장치가 부족하다는 구조적 문제다. AI 도구를 만드는 회사가 스스로의 공급망(supply chain) 보안에서는 종종 취약하다는, 시스템 스미스 스티븐(Stephen Smith)의 지적과도 맞닿는다(Smith Stephen Newsletter).

2. 드리밍(Auto Dream) — 수면 의존 메모리 통합의 소프트웨어 구현

가장 주목할 만한 발견은 autoDream이라 명명된 백그라운드 메모리 통합 프로세스였다. 클로드 코드는 마크다운 파일로 구성된 영속 메모리 시스템을 갖고 있는데, 세션이 쌓일수록 관찰·정정·사용자 선호가 누적되며 파일이 비대해지고 모순이 발생한다. 드리밍은 이를 주기적으로 “증류”하는 프로세스다.

작동 방식은 세 단계 게이트(마지막 통합 이후 24시간 경과, 최소 5개 세션 누적, 락 획득)를 모두 통과한 뒤, 읽기 전용 배시 권한만 가진 샌드박스 클로드 인스턴스를 스폰해 Read → Gather → Consolidate → Prune의 네 단계를 실행한다. 인덱스 파일은 200줄 이하로 유지되며, 모순된 사실은 삭제되고, 상대 날짜는 절대 날짜로 변환된다. 이는 사실상 신경과학에서 말하는 수면 중 메모리 통합(sleep-dependent memory consolidation) 을 소프트웨어로 구현한 것이며, 앤트로픽 내부 코드에서도 이 이름을 차용했다(Claudefa.st 분석, Medium — Marc Bara).

실무적 함의는 분명하다. 에이전트의 장기 기억을 벡터 DB 하나에 밀어 넣는 대신, 세션 중에는 빠른 에피소드 포착, 세션 외에는 느린 의미 통합이라는 이중 아키텍처가 등장한 것이다. 이는 카이로스(Kairos)라는 “상시 가동 모드”와 결합되어 있어, 사용자가 유휴 상태일 때 에이전트가 조용히 컨텍스트를 정돈한다.

3. LLM을 검색 엔진으로 쓰는 메모리 리트리버

두 번째 인상적인 설계는 메모리 검색에 벡터 임베딩이 아닌 언어 모델 그 자체를 사용한다는 점이다. 사용자의 질의가 들어오면 시스템은 모든 메모리 파일의 프런트매터(name, description, type)만 뽑아 매니페스트를 만들고, 소넷(Sonnet)에게 “클로드 코드에 유용할 메모리를 최대 5개 골라 달라”는 사이드 쿼리를 날린다. 응답은 JSON으로 돌아온다.

주목할 만한 디테일은 “최근 사용된 도구”를 추적해, 이미 사용 예가 대화에 포함된 도구에 대한 레퍼런스 문서는 선택자에게 건너뛰라고 지시하는 반면, 경고·함정·이슈는 여전히 노출하는 “안티 노이즈” 정책을 내장한 것이다. 전형적인 RAG의 한계(키워드 불일치 시 관련 문서를 놓침)를 우회하기 위해, 오푸스가 아닌 소넷을 선택기로 써 비용을 낮췄다(WaveSpeed AI 분석).

4. 코디네이터 모드 — 실전에 투입된 다중 에이전트 오케스트레이션

코디네이터 모드는 클로드 코드를 “코드를 직접 건드리지 않는 조율자”로 바꾸는 다중 에이전트 아키텍처다. 워크플로는 연구(병렬 워커 파견) → 종합(코디네이터의 직접 이해) → 구현(파일 집합 단위 직렬 할당) → 검증(다른 워커가 수행)의 네 단계로 구성된다.

특히 시스템 프롬프트가 "based on your findings"라는 표현을 문자 그대로 금지하는 점이 흥미롭다. 코디네이터는 워커의 결과를 요약하는 중개자가 아니라, 실제로 이해하고 구체적인 파일 경로·라인 번호·수정 내용을 담은 구현 스펙을 직접 써야 한다는 것이다. 검증 워커는 구현 워커와 반드시 달라야 하며, “검증은 코드가 존재함이 아니라 동작함을 증명하는 것”이라는 원칙이 프롬프트에 박혀 있다(techsy.io — KAIROS, ULTRAPLAN, Buddy).

또 하나의 조각은 “스크래치패드”다. 권한 프롬프트 없이 워커들이 읽고 쓸 수 있는 공유 디렉터리를 두어, 크로스 워커 지식 공유를 가능하게 했다. 이는 다중 에이전트 시스템이 실패하는 가장 흔한 원인인 “워커 간 컨텍스트 단절”을 풀어보려는 실무적 시도다.

5. 언더커버 모드 — 투명성과 내부 정보 보호의 충돌

언더커버 모드는 내부 직원 사용자 변수와 환경 변수 두 겹으로 게이팅된 모드로, 외부 빌드에서는 관련 함수가 모두 no-op로 치환된다. 공개 NPM 패키지에는 빈 껍데기만 남는다는 의미다. 그럼에도 이 기능이 논란이 된 이유는 명확하다. 주입되는 시스템 프롬프트가 클로드에게 “공개 저장소에서 잠입 활동 중이니, 모델 코드네임·내부 프로젝트명·Co-authored-by 라인·AI임을 드러내는 표현을 일절 쓰지 말고, 인간 개발자가 쓸 법한 커밋 메시지를 작성하라”고 지시하기 때문이다.

내부 코드네임(카피바라·텐구·카이로스 등)을 공개 커밋 이력에 남기고 싶지 않다는 보안상 이유는 타당하다. 그러나 이 기능은 AI 투명성, 코드 출처(provenance), 오픈소스 기여의 윤리에 대한 진지한 질문을 남긴다. “조심스러운” AI 기업이 내부에 AI 저자 은폐 도구를 두고 있었다는 사실 자체가 신호라는 지적이 나온다(Bizrescuepro 분석).

6. 모델 힌트와 카피바라(Capybara) 미스터리

코드에는 오푸스 4.6(맥스 구독자 기본값), 소넷 4.6(일반 사용자 기본값), 하이쿠 4.5가 등록돼 있었다. 그러나 오푸스 4.7이나 5.0 같은 차세대 ID는 어디에도 없었다. 대신 “카피바라”라는 내부 별칭이 Tengu ant model override라는 그로스북 플래그를 통해 앤트로픽 직원(내부 유저 타입 ant)에게만 동적으로 전달되고 있었다. 카피바라는 오푸스와 호환되지 않는 독자적인 “사고(thinking) 포맷”을 가진 별개의 체크포인트이며, 차세대 모델의 내부 변형일 가능성이 언급되고 있다(Elliot Arledge 블로그).

핵심 인사이트

에이전트 메모리는 “쓰기와 통합의 분리”로 간다. 드리밍/카이로스 조합은 “언제나 받아쓰고, 주기적으로 증류한다”는 이중 구조를 보여준다. 실시간 정리를 포기함으로써 실시간 성능을 얻고, 유휴 시간에 품질을 회복한다.
RAG는 임베딩만의 게임이 아니다. 충분히 저렴한 모델(소넷)이 있다면, 메타데이터 매니페스트를 LLM이 직접 읽고 고르는 방식이 의미적으로 더 정확할 수 있다. 벡터 DB를 도입하기 전에 “LLM 선택기”를 먼저 시험해 볼 만하다.
다중 에이전트의 실패는 “종합” 단계에서 일어난다. 코디네이터 프롬프트가 “based on your findings” 같은 요약 관용구를 금지하는 것은, LLM이 중개자가 되는 순간 맥락을 잃는다는 경험적 관찰에 기반한다. 조율자가 직접 이해하고 구체적 스펙을 써야 한다.
내부 기능과 공개 기능 사이의 경계는 결국 드러난다. 언더커버 모드처럼 빌드 게이트로만 가려진 기능은, 패키징 실수 한 번이면 공개된다. 설계 단계에서 “새면 안 되는 것”은 코드 자체에 담기지 말아야 한다.
같은 사고가 두 번 일어났다는 사실이 가장 큰 교훈이다. AI를 만드는 회사도 자신의 소프트웨어 공급망에서는 여전히 취약할 수 있다. .npmignore와 files 화이트리스트는 지루하지만, 이 지루함이 유일한 방어선이다.

더 알아보기

03찬반 토론 · Debate

토론: “유출된 클로드 코드(Claude Code) 소스는 AI 업계 전체에 유익한 교보재다”

논제: 앤트로픽(Anthropic)의 클로드 코드 소스 유출은 사고이지만, 그 코드에서 드러난 설계(드리밍, LLM 메모리 리트리버, 코디네이터 모드, 언더커버 모드)는 공개적으로 논의·학습될 때 AI 엔지니어링 생태계 전체에 순이익을 가져다준다.

Round 1

🟢 Pro — “유출된 설계는 업계가 절박하게 필요로 하던 ‘실전 청사진’이다”

51만 줄의 프로덕션 에이전트 하네스를 실제로 볼 수 있는 기회는 그 동안 없었다. 연구 논문은 이상화된 프로토타입을 보여주고, 기업 블로그는 마케팅 포장을 벗기지 않으며, 오픈소스 에이전트 프레임워크는 장난감 수준에 머무른다. 이번 유출이 드러낸 것은 실제 결제 구독자 수백만 명을 감당하는 에이전트가 어떤 구조로 굴러가는가 이며, 이는 그 어떤 논문·블로그보다 교육적 가치가 크다.

특히 드리밍(autoDream)은 “장기 메모리를 어떻게 증류할 것인가”라는, 에이전트 엔지니어링의 가장 풀기 어려운 문제에 대해 실전적이고 재현 가능한 해법을 제시한다. 24시간/5세션/락이라는 세 겹 게이트, 샌드박스 워커를 스폰해 Read-Gather-Consolidate-Prune 네 단계를 밟는 구조, 인덱스 상한 200줄 등은 누구든 자신의 에이전트에 옮겨볼 수 있는 구체적인 레시피다. 코디네이터 모드의 시스템 프롬프트가 "based on your findings"라는 관용구를 문자 그대로 금지한다는 사실 한 가지만 해도, 다중 에이전트 시스템을 만드는 수많은 스타트업이 범하고 있는 오류를 교정하게 해 준다.

무엇보다 이 유출은 프론티어 연구소와 나머지 생태계 사이의 정보 비대칭을 일시적으로 해소한다. 2026년 현재 AI 에이전트 분야는 극소수 기업만이 진짜 실전 경험을 축적하고 있고, 이로 인해 생태계 전체가 비슷한 실수를 반복해 왔다. 이번 유출은 그 벽을 한 번 낮췄고, 이로 인한 업계 전체의 학습 가속은 개별 회사의 지식재산 손실을 웃도는 순이익을 만든다.

🔴 Con — “코드의 동의 없는 공개는 나쁜 선례이고, 설계만 떼어 ‘교보재’라고 부르는 것은 위선이다”

반대 입장은 단순하다. 이 유출은 엔지니어의 동의, 회사의 동의, 사용자의 동의 중 어느 것도 받지 않았다. 우리는 이것이 “AI 엔지니어링 생태계의 교보재”가 되는 순간, 동의 없이 유출된 소스를 학습하는 것이 정상화된 산업 규범이 되는 방향으로 한 걸음 더 간다. 이는 AI 회사들이 훗날 학습 데이터와 관련해 어떤 주장을 하든, 스스로 그 주장의 근거를 깎아먹는 행동이다.

기술적 가치 역시 과장돼 있다. 드리밍의 네 단계 구조나 코디네이터 워크플로는 아카데믹 에이전트 논문을 조금만 읽어본 사람이라면 이미 알고 있는 패턴의 재구성에 가깝다. 진짜 가치는 특정 하이퍼파라미터, 특정 시스템 프롬프트, 특정 실패 사례에 대응한 세부 조정에 있는데, 이 부분은 유출된 코드만으로는 절대 복원되지 않는다. 즉 사람들이 “배웠다”고 생각하는 것의 상당 부분은 피상적 모방이며, 오히려 잘못된 교훈을 퍼뜨릴 위험이 크다.

그리고 가장 불편한 현실은 언더커버 모드다. 이 기능은 유출 이전에는 존재조차 알려지지 않았고, 유출이 아니었다면 우리는 AI 회사가 공개 저장소에 “AI 저자임을 숨겨라”라고 지시하는 기능을 내부에 두고 있었다는 사실을 결코 몰랐을 것이다. 이는 유출에도 긍정적 측면이 있다는 뜻이 아니다. 오히려 회사의 내부 의사결정이 외부 감시를 받는 정당한 경로가 산업 전체에 없다는 뜻이고, 그 경로를 “우연한 유출”에 의존하는 구조 자체가 병들어 있다는 뜻이다.

Round 2

🟢 Pro (재반론) — Con의 논거를 하나씩 받아친다

Con의 첫째 주장은 “동의 없는 유출의 정상화”라는 우려다. 그러나 여기에는 중요한 혼동이 있다. 유출 자체를 옹호하는 것과, 이미 공개된 정보로부터 배우는 것 은 별개의 도덕적 사건이다. 정보가 이미 공공 영역에 진입한 이상, 이를 분석·학습하지 않는 것은 미덕이 아니라 낭비다. 오히려 업계가 공개적으로 분석·토론하는 쪽이, 유출 정보를 음지에서 특정 집단만이 독점적으로 활용하는 쪽보다 형평성 면에서 낫다. Con의 프레임은 “배우지 않는 것 = 윤리”라는 환상에 기대고 있다.

Con의 둘째 주장은 “드리밍과 코디네이터는 이미 논문에 있는 패턴의 재구성”이라는 것이다. 이는 사실의 일부를 잘라낸 주장이다. 논문에 개념이 있다는 것과 프로덕션에서 무엇이 작동하는지는 전혀 다른 문제다. 예를 들어 “LLM을 검색 엔진으로 쓴다”는 아이디어는 학계에서도 논의되어 왔지만, 소넷을 쓰며, 프런트매터만 매니페스트로 뽑고, 최근 사용 도구에 따라 참고 문서는 건너뛰되 경고는 유지한다는 구체성은 논문 어디에도 없었다. 이 구체성이야말로 생태계가 비어 있던 지점이고, Con이 말하는 “피상적 모방”은 사실 Con이 과소평가하는 구체적 엔지니어링 결정의 가치다.

Con의 셋째 주장인 언더커버 모드에 관해서는 Con이 역설적으로 Pro의 논지를 강화한다. 외부 감시 경로가 부실하기 때문에 우연한 유출이 유일한 점검 수단이 된 현실이라면, 이번 유출을 공개적으로 논의하는 것이야말로 그 점검을 실제 정책 변화로 전환할 유일한 지렛대 다. “유출을 학습 자원으로 삼지 말자”는 입장은 이 지렛대를 스스로 버리는 것이다.

🔴 Con (재반박) — Pro의 논거에 대한 정면 반박

Pro의 첫째 주장은 “프로덕션 수준 실전 청사진의 교육적 가치”다. 그러나 이 주장은 생존 편향(survivorship bias) 의 전형이다. 우리가 보는 것은 51만 줄 중 “흥미로워 보이는” 약 다섯 가지 패턴일 뿐이고, 실패해서 삭제된 패턴, 주석으로만 남은 시도들, 플래그로 꺼진 이전 버전들은 공개 담론에서 빠진다. 다시 말해 사람들이 “프로덕션이 이렇게 돌아간다”고 배우고 있는 것은 실제 프로덕션의 편집된 하이라이트이고, 이 편집은 우연적이며 검증되지 않았다. 논문보다 실전적이라는 말은 듣기 좋지만, 동료 평가(peer review) 없는 실전은 오히려 더 나쁠 수 있다.

Pro의 둘째 주장인 “드리밍은 재현 가능한 레시피”라는 말에는 Round 1에서 든 사례의 허점이 뚜렷하다. 24시간/5세션/락이라는 숫자가 공개됐다고 해서, 이 숫자를 그대로 가져다 쓰는 것이 자기 시스템에 옳다는 근거는 어디에도 없다. 앤트로픽이 이 값에 도달한 내부 A/B 실험, 실패 사례, 사용자 피드백 루프는 유출에 포함되지 않았다. 그 결과 업계 전체가 “앤트로픽이 이렇게 했으니까 맞겠지”라는 카고 컬트(cargo cult) 엔지니어링에 빠질 위험이 크다. Pro가 말하는 “학습 가속”은 종종 “실수의 가속”과 구분되지 않는다.

Pro의 셋째 주장인 “정보 비대칭 해소”에 대해서는 더 근본적인 문제가 있다. Pro는 유출이 비대칭을 낮춘다고 말하지만, 이는 일회성 누수일 뿐이다. 내일이면 앤트로픽은 패키징 파이프라인을 고칠 것이고, 비대칭은 그대로 돌아온다. 근본적 해결은 유출에서 오지 않는다. 그것은 오픈소스 기여 규범, 연구 논문의 재현 코드 공개, 업계 표준의 수립 같은 지속 가능한 경로에서 온다. 유출을 이 문제의 해결책처럼 포장하는 것은, 실제로 필요한 제도적 노력을 가리는 역효과를 낳는다(Medium — Marc Bara 분석).

Round 3

🟢 Pro — Con의 재반박을 하나씩 해체한다

Con의 첫째 재반박인 “생존 편향” 논지는 중요한 지적이지만, Pro의 입장을 뒤집지는 못한다. Pro는 “유출 코드 = 완벽한 실전 기록”이라고 주장한 적이 없다. 기존 생태계가 가진 정보량에 비해 이번 유출이 더 구체적이고, 더 유용하다는 상대적 주장이다. 동료 평가가 없다는 Con의 우려에는 오히려 공개 논의가 답이다. 수만 명의 엔지니어가 이 코드를 읽고 서로 토론하는 것 자체가 분산된 형태의 동료 평가이고, 실제로 InfoQ, VentureBeat, 보안 블로그들이 서로 다른 해석을 내놓으며 합의를 만들어 가고 있다. 이것은 편향을 줄이는 정상적인 과정이다.

Con의 둘째 재반박인 “카고 컬트 엔지니어링” 우려는 역설적으로 유출된 정보가 아니라 정보 부족에서 오는 병이다. 지금 누군가가 24시간/5세션이라는 값을 맹목적으로 따라 쓴다면, 그것은 유출이 제공한 정보가 많아서가 아니라 그 값이 왜 그런지 설명할 맥락이 여전히 부족하기 때문 이다. 해답은 이 정보를 버리는 것이 아니라, 이를 출발점 삼아 공개 벤치마크와 재현 실험을 더 많이 만드는 것이다. Con은 맹신의 위험을 지적하면서도, 맹신을 깨는 유일한 수단인 “공개 논의”를 동시에 공격한다.

Con의 셋째 재반박인 “지속 가능한 경로” 논지에는 Pro도 동의한다. 오픈소스 기여 규범과 재현 코드 공개가 장기 해결책이라는 점은 맞다. 그러나 “유출을 학습 자원으로 삼는 것”과 “제도 개혁을 추진하는 것”은 양립 불가능한 선택지가 아니다. 오히려 이번 유출에서 업계가 배운 것이 많을수록, 앤트로픽 같은 프론티어 기업에 “차라리 일부를 공식적으로 공개하라”는 압력이 강해진다. 즉 유출로부터의 학습은 Con이 원하는 장기 목표로 가는 지렛대이지 장애물이 아니다.

🔴 Con — Pro의 재반론을 마지막으로 뒤집는다

Pro의 첫째 재반론인 “분산된 동료 평가”는 듣기에 그럴듯하지만 실제로는 그렇게 작동하지 않는다. 수만 명이 읽는다는 것은 합의를 뜻하지 않고, 오히려 빠른 속도의 합의 조작을 뜻한다. 실제로 이번 유출 보도에서 “카피바라는 차세대 오푸스 이상의 모델”이라는 과장된 해석이 하루 만에 SNS에서 정설처럼 퍼졌고, 코드의 실제 내용은 “내부 직원용 별칭으로, 정체는 불명”에 불과했다(Medium — Marc Bara). 분산된 동료 평가가 아니라 분산된 루머 제조기가 먼저 돌아갔다. Pro가 기대하는 자정 작용은 존재하지만, 그 속도는 오해의 속도보다 느리다.

Pro의 둘째 재반론은 “정보 부족이 카고 컬트의 원인이지 정보 과잉이 아니다”라는 주장이다. 이것은 절반만 옳다. 정보의 질이 문제다. 이번 유출이 공급한 것은 “특정 회사의 특정 시점 스냅샷”인데, 이는 다른 회사·다른 문제 맥락으로 옮겨지는 순간 의미가 크게 변한다. 정보의 질이 담보되지 않은 상태에서 “더 많이 배우자”는 방향은, 실제로는 적용 가능성이 보장되지 않은 패턴의 대량 유통을 뜻한다. 실제 해결책은 “이 정보를 공개 논의하자”가 아니라 “이 정보에 의존하지 말고 자체 실험을 설계하자”가 되어야 한다.

Pro의 셋째 재반론은 “유출 학습이 공식 공개 압력을 만드는 지렛대”라는 것이다. 그러나 이는 입증되지 않은 낙관이다. 실제로는 정반대가 일어날 가능성이 크다. 앤트로픽은 이번 사고 이후 더 강한 난독화·더 엄격한 패키징 통제·내부 빌드 분리로 움직일 것이고, 다른 프론티어 기업들도 그 방향을 따를 것이다. 즉 이번 유출은 장기적으로 정보 비대칭을 더 심화시키는 방향으로 작동한다. Pro가 기대한 지렛대는 실재하지 않고, 있는 것은 단기적 학습 이득과 장기적 개방성 후퇴의 트레이드오프뿐이다.

🧭 종합

합의 지점

양측이 명시적으로든 묵시적으로든 동의한 점은 적지 않다. 첫째, 이번 유출이 드러낸 개별 설계(드리밍, LLM 리트리버, 코디네이터, 언더커버)는 기술적으로 흥미로우며 업계 담론의 자산이 된다. 둘째, 유출 그 자체는 옹호될 일이 아니다. 셋째, 유출에만 의존하는 지식 전달은 지속 가능하지 않으며, 오픈소스 규범과 재현 코드 공개 같은 제도적 경로가 장기적 해법이다. 넷째, 언더커버 모드처럼 외부 감시가 필요한 기능이 내부에만 존재했다는 사실은, 산업 전체의 투명성 체계가 미성숙하다는 신호이며 이는 개선되어야 한다.

열린 질문

유출된 프로덕션 코드로부터 “배운 교훈”을 다른 시스템에 이식할 때, 어떤 기준으로 맥락 의존적 파라미터(24시간, 5세션, 200줄 등) 와 이식 가능한 구조(이중 단계 메모리, 검증 워커 분리 등) 를 구분할 것인가?
분산된 공개 논의는 피어 리뷰를 대체할 수 있는가, 아니면 Con의 말처럼 루머 제조기에 더 가까운가? 이 질문에 답하려면 이번 유출 보도의 사실 정확도를 2~3개월 뒤 재측정하는 실증 연구가 필요하다.
앤트로픽의 대응이 “더 강한 차단”으로 기울 때, 업계의 개방성은 실제로 후퇴하는가? 후퇴한다면 오픈소스 에이전트 프로젝트(OpenClaw 등)가 그 공백을 메울 수 있는가?
언더커버 모드 같은 “AI 저자 은폐” 기능은 보안 요구와 투명성 요구 사이에서 어떤 공개 정책으로 다뤄져야 정당화될 수 있는가? 내부 전용이라는 사실 자체만으로 충분한가?

더 나아간 관점

이 토론은 사실 “유출을 학습할 것인가”라는 질문으로 환원될 수 없다. 더 근본적인 질문은 프론티어 AI 기업의 내부 의사결정을 외부가 검증할 제도적 경로가 왜 이렇게 부실한가 이다. 이번 유출은 그 부실함의 증상이지 원인이 아니다.

Pro의 관점을 따른다면, 유출로부터의 학습을 지렛대 삼아 “책임 있는 부분 공개(responsible partial disclosure)“라는 새로운 산업 규범을 요구할 수 있다. 예컨대 다음과 같은 것들이다. 에이전트 시스템의 핵심 시스템 프롬프트를 정기적으로 감사 기관에 공개하기, 메모리 통합·다중 에이전트 조율 같은 구조적 설계에 대해 공개 기술 리포트(화이트페이퍼)를 발행하기, 내부 전용 기능(언더커버 모드 등)의 존재를 사후 투명성 보고서로 고지하기.

Con의 관점을 따른다면, 이번 사고에서 우리가 집중해야 할 것은 “어떤 패턴이 멋있어 보이는가”가 아니라 “같은 사고가 왜 두 달 만에 반복됐는가”다. AI 회사들의 내부 릴리스 엔지니어링·공급망 보안·사고 사후 검토(postmortem) 문화가 얼마나 미성숙한지가 진짜 발견이다. 이 각도에서 보면 이번 유출의 교보재적 가치는 드리밍·코디네이터 같은 멋진 패턴이 아니라, “이런 사고가 반복되는 조직에서 나온 소프트웨어를 수백만 명이 매일 쓰고 있다”는 불편한 사실이다.

두 관점 모두에서 일치하는 결론은 이것이다. 유출된 소스 자체가 아니라, 유출이 드러낸 “공개성의 구조적 결핍”이 우리가 풀어야 할 진짜 문제다. 드리밍의 네 단계도, 코디네이터의 프롬프트 금칙어도 중요하지만, 가장 중요한 교훈은 이런 정보가 오직 사고를 통해서만 외부에 도달했다는 사실 그 자체다.

04영문 원본 · Transcript

So this morning, I think a lot of us saw this news about the cloud code leak.
And it started with this security researcher, Chow-Fon Cho, who made a pretty remarkable discovery.
He found that in the new version of the official cloud code NPM package, which shipped with a 60 megabyte source map file.
And that referenced the complete TypeScript source code for cloud code.
And the source was just sitting right there in Anthropic's own R2 cloud storage bucket.
Right. So downloadable as a zip for basically anyone who could get it.
And this is not the first time this has happened.
It happened recently in February, actually.
The same issue happened with Anthropic, but it happened again today.
So I've gone through the raw source code, not blog posts or reporting or Twitter threads or hyped, you know, Twitter posts, the actual code.
And I wanted to share with you what I thought were the five most interesting findings,
especially for anyone working or interested in AI research or engineering.
And this will be a quick video.
I'm just going to run through what I thought was pretty interesting.
But first, before the takeaways, let's talk about the models a little bit, because that's what people are wondering.
What did the code leak tell us about the models?
And this is a little overview of what happened.
Nineteen hundred plus files over five hundred thousand lines of TypeScript were released.
A lot of the runtime tools and scale gating were also released.
So the models, the model registry.
And this is the in the file called configs.typescript, and it's pretty straightforward.
There's a config object for every model the system knows about with IDs for first party bedrock, Vertex, Foundry.
So the current defaults are Opus 4.6, which is the most recent model for Mac subscribers and Sonnet 4.6 for everybody else.
Haiku 4.5 is a small, fast model, as you know.
So it's everything you should expect.
And there was nothing in the code that showed, you know, Opus 4.7.
Or 5.0, no next generation model IDs anywhere in the code base.
They used this model launch comment scattered through the code as like a manual checklist for when new models eventually shipped.
But there was nothing preloaded in the code so far.
But what is Capybara?
So Capybara got a lot of attention recently on social media, people thinking it's a next gen model, thinking it's maybe this mythos crazy next gen model that's a cybersecurity threat.
So what we saw in the code, the term Capybara does appear, and it appears to be an internal and tropic employee model alias, not not confirmed as a new model family yet.
So the way it works is anthropic employees, and they call themselves ants internally.
User type is literally ant.
So they have a growth book feature flag.
Here, Tengu ant model override, and that delivers a list of model aliases dynamically and Capybara is one of those aliases.
So it results in a new model.
It resolves some internal model variant at runtime.
So basically, the employees are able to use whatever Capybara is.
So we do know that Capybara is some kind of distinct model checkpoint of some kind different from Opus or Sonnet.
It has its own thinking format that's incompatible with Opus.
So whether it's a pre-release model or an experimental variant or some fine tuned build, the code itself doesn't say, but it is interesting nonetheless.
Importantly, all of the internal codems was not included in the NPM.
Package, which was leaked.
So we're only seeing the ones that leaked through the code comments and the variable names itself.
Tengu appears a lot, and that's Claude code itself.
That's the code name for it.
So the bottom line on the models, there's no next gen model IDs, no Claude five or anything crazy.
But it was interesting to see Capybara as an internal model alias, which is used by anthropic employees.
And hopefully we'll find out soon what exactly Capybara is.
It would make sense that they're using some.
Like the latest cutting edge model internally, but nothing quite confirmed yet.
Okay, on to the five takeaways.
So takeaway number one is this concept of dreaming memory console consolidation.
And this is something I thought was the most interesting in the entire league code base.
It's called auto dream specifically.
And it's a background process that performs autonomous memory consolidation.
Really interesting idea.
So here's the setup over here.
Claude code has persistent memory system, a directory of markdown files.
And as you use Claude code across sessions, it accumulates observations, corrections, preferences.
So it's a lot of this kind of raw signal here.
So the problem is if you keep just accumulating these observations, you're going to get bloat.
You're going to get contradictions, obviously, over different over time, stale information that's no longer relevant.
So they built this dreaming system and it works on a gate system.
So the cheapest checks first.
First has it been at least 24 hours since the last consolidation.
That's just a time camp.
Uh, time.
Stamped comparison.
Secondly, have at least five sections sessions accumulated since then that requires scanning the transcript files.
Third, can we acquire a lock?
So no other processes dreaming at the same time.
So these are the gates, right?
So if all three of these gates pass, it spawns what they call a forked agent or spawned agent.
Um, and this is a sandbox Claude instance with read only bash access.
And this agent gets a detailed prompt called the consolidation pump, and it walks through these four phases.
Uh, so number one.
So it reads the existing memories right in index to get a grasp of the landscape based to gather.
It looks for new signal in the daily logs and session transcripts, but very narrowly.
It doesn't read the whole files or anything.
Phase three is consolidate, and this merges new information into existing topic files that are relevant, converts relative dates into absolute one, deletes, uh, contradicted files, contradicted facts and phase four prune it.
Make sure the index stays under 200 lines.
So it'll prune down the file.
So this creates a production two phase memory architecture, fast episodic capture during sessions, and then slow semantic consolidation offline.
So it directly mirrors neuroscience models of sleep dependent memory consolidation.
So that's why they call it dreaming or auto dream, whatever it'll end up actually being.
Uh, so this is Kairos is involved here.
Kairos is there always on persistent mode, those sessions that are effectively perpetual.
They just always stay on.
And this is different from the normal mode, which we're used to working with in cloud code and this, if you're familiar with open claw, kind of, kind of a similar idea, um, instead of the agent organizing memories in real time, it writes to append only daily log files, uh, which if you're using open claw, you know, it's supposed to do this as well.
Then the dream process, uh, which I described before is what distills those daily logs into organized topic files and updates the index.
So this is that sandbox agent I was talking about reviewing all these logs.
Okay.
The files and then pruning the stuff that's obsolete or not relevant anymore.
And in the code, we saw that the stream process has its own task tracking in the UI users can see dreaming, you know, reviewing seven sections sessions and their background task and they can kill it if they want.
Um, it's all.
Managed, uh, by the user.
If they want.
Takeaway number two is the LL, M powered memory retrieval, and this is kind of connected with the memory system.
Um,
because you have this memory system now with dozens of topic files. So how do you decide
which ones are relevant to the current conversation? And the obvious answer in 2026
would be vector embeddings, embed the query, embed the memories, co-assign similarity done.
So that's the usual traditional RAG system that we're used to with other kind of agent
frameworks. But this is not what Cloud Code was going to do. So they use a language model as the
retrieval engine itself. So when a user's query comes in, the system scans all memory files and
extracts their front matter. So just the name, description, and type fields from the header.
It formats these into a manifest, and then it fires what they call a side query to Sonnet.
And this is a lightweight parallel API call with a system prompt that says,
you are selecting memories that will be useful to Cloud Code, return up to five file names.
So the response comes back as a JSON. And there are some really interesting
details in how this is implemented. For one, it tracks which tools have been recently used
in the conversation. So if you're using the Bash tool a lot, this selector is told to skip
reference documentation about Bash, because the conversation already contains working usage
on this tool. So surfacing docs would just be noise. It's not needed.
But the system, and this is kind of clever, it still surfaces warnings, gotchas,
issues with those specific tools. So this is their anti-noise system.
So this is interesting, because it's a production system that uses this kind of LLM-powered
memory retrieval system using Sonnet, like I described, instead of your classic embedding
system. And it has a pretty clear advantage. The language model can always reason about semantic
relevance in ways that cosine similarity and the traditional RAG system can't do.
It can understand that a memory about a certain topic is relevant to a query, even if they don't
share any specific keywords. Now, obviously, this may cost more because you have more API calls. But
the framework itself, and they're using Sonnet for these instead of Opus to hope to counter some of
those costs. So takeaway three, undercover mode. This is a kind of controversial one that I saw
people talking about. So it's a system that prevents Claude from revealing it's an AI when
contributing to public repositories. But there's an important context here. So all the code in this
file for undercover mode is gated behind an environmental variable with a user variable for
internal employees. So this means it's only exist in Anthropix internal builds. So it's not part of
the public NPM package. In external builds, every function returns a no operation. So important to
keep in mind. So the purpose is clearly stated in the header. So it's safety you to utilities for
contributing to public public open source repos. When this mode is active, Claude code strips all
attribute attribution from commits and PRS to avoid leaking internal information. But it kind of
goes further that
the system
prompt injected in undercover mode is very explicit. And it basically says you're an operating
undercover in a public repository. Your commits must not contain any anthropic internal information
do not blow your cover. You know, never include model code names or version numbers, internal
project names, or the phrase Claude code. Any mentions that you're an AI or co authored by lines.
So you'd have to write commit message like a human developer would kind of interesting. So there's a
security purpose.
For this anthropic has a real reasons to not want in terminal code internal code names
showing up in public commit histories. That's part of their IP. So the main reason is that
main purpose of this mode is so it's designed for anthropic employees to contribute to public repos.
But it's sure to raise questions about AI transparency, transparency and code
providence and open source in the large open source community. So like,
what does it mean for code providence when AI companies build tooling to hide AI authorship,
right? And more broadly, if a company is building AI,
if a company building the AI is designing systems to conceal it,
it's used in public contributions. What message does this send about transparency, right?
And there are legitimate security reasons. But there are also valid questions about transparency,
when you're specifically telling an AI that it has to pretend it's a human developer.
Interesting takeaway. So takeaway number four, coordinator mode.
This was a complete multi agent orchestration system hidden behind a feature flag. So when
this is enabled, code code transforms from a single agent
into a coordinator that never touches the code directly, it only spawns continues and
stops worker agents. So the main cloud code itself is the orchestrator or coordinator, I suppose.
And the coordinator has a really massive system prompt in the code base that we saw.
And the workflow. In the system, this mode has four phases,
first, and this is workers are sent out in parallel to investigate the code base from
multiple angles. And then we have synthesis. And this is where most of the opinionated
decision lives. The coordinator must personally understand the research findings from the
workers before directing any implementation work. So the prompt literally bans the phrase
based on your findings. Instead, the coordinator must write implementation specs that include
specific file paths, line numbers and exactly what to change. Implementation is serial per
file set, you don't have two workers, right, editing the same files. And verification is
done by a different worker. Never the same worker that implemented the change, because
they'd carry implementation assumptions. So you need a fresh pair of eyes. And the verification
standards are pretty high to the prompt says verification means proving the code works,
not confirming it exists.
A verifier that rubber stance weak work undermines everything. So workers are told to run tests
with feature with the feature enabled, investigate type errors rather than dismissing them as
unrelated and to be genuinely skeptical. So important prompts to make sure this coordinator
mode system actually properly works. And they have this scratch pad system, which is interesting.
It's kind of a shared directory where the workers can read or write without permission
prompts. And this enables durable cross worker knowledge sharing.
So the coordinator tells workers use this for your cross worker knowledge structure
files however it fits to work. So workers are able to share knowledge needed to work
on the same code base. So takeaway five is buddy, which is kind of a fun idea. And this
is an AI companion. So buddy is an unreleased feature right now. It's a Tamagotchi style
ASCII pet with deterministic procedural generation.
So you can see here there's 18 species you have here different animals, cat, ghosts,
capybara, mushroom, penguin, kind of a fun idea. And what makes this kind of technically
interesting is that the procedural generation system, so every user gets a deterministic
companion drive from their user ID, the system hashes the user ID with a specific seed and
from that seed, it drives everything the species I style hats, rarity, everything.
So they each have different animations, different lengths and sizes, different eye styles.
And they also have this kind of rarity system, which is fun, similar to a gotcha, you know,
60% common chance 1% chance of a shiny variant, 1% chance of a legacy. And this is a really
clever architecture decision because it has a burns versus bones versus soul split. So
bones are the deterministic physical traits, species rarity. I'll just give you a quick
eyes stats they're never persisted to sort of storage they're regenerated from your user id
from that seed on every single read and then the soul is model generated part and this is the name
and the personality and it's created when it's first hatched and that's stored in the config
and persisted across sessions so the companion has little speech bubbles to talk to you it's a
small feature but it's kind of fun and it's a kind of a case study in building delightful persistent
procedurally generated entities in system where the generation rules need to evolve over time
so these are the credits to the people uh chalfon show like i said the original tweet that i saw
there may have been an earlier one some people were very quick to
copy or port over certain elements of the the leaked code
uh
this one here clock code is in python i believe and then he's working on it in rust right now
and this is a reverse engineered version that kind of rebuilt the different features of it
and there were those obviously who just mirrored the the source but that's it for today's video
i just wanted to put this out quickly because i just saw this news this morning i thought it was
interesting to see what kind of lessons we could learn from the code base i should be said that all
uh cloud coding clot are trademarks of anthropic uh the source code is property of anthropic
so i will not be brave enough to try to mirror or report over uh the cloud code
raw source material but we can learn some lessons from from what was in it so please leave a comment
leave a like subscribe we have a lot more videos coming up this week and thank you for watching