2026년 11월 8일(일, Asia/Seoul) GitHub Trending 전체 일간 목록 14위, TypeScript 일간 4위에 ranxianglei/billion-context가 올라와 있습니다. 오늘 하루 동안 붙은 스타는 해당 페이지 기준 +191입니다. 이 글을 쓰는 시점 GitHub API 기준 스타 4,759, forks 381, watchers 10, open_issues_count 910(이슈와 PR을 합친 값)입니다. 라이선스는 저장소 루트 LICENSE와 npm 모두 MIT입니다. GitHub API의 license.spdx_id는 NOASSERTION으로 나오지만, 파일 원문은 MIT입니다.
npm과 GitHub 릴리스의 현재 안정 버전은 v0.1.213입니다. 태그 커밋은 133f3525c628c4b959bb79ece82af6df82e131a3이고, 릴리스 시각은 2026-11-07T23:25:08Z, 곧 2026-11-08 08:25 KST입니다. 기본 브랜치 master의 얕은 클론 HEAD는 354e21e(2026-11-08 13:05 KST, “Merge pull request #5921 … dsh-lane-small-fixes-batch”)이며 package.json 버전 필드는 여전히 0.1.213입니다. 박스 스모크는 소스 HEAD가 아니라 npm에 올라온 0.1.213으로 돌렸고, bili --version은 0.1.213 (133f3525c)를 출력했습니다.
이 글은 같은 날 오전에 다룬 Neroued/ninfer(RTX 5090·DGX Spark 전용 C++/CUDA 추론 엔진)와는 문제 공간이 다릅니다. billion-context는 모델을 더 빨리 돌리는 엔진이 아니라, 이미 쓰고 있는 코딩 에이전트와 모델 API 사이에 끼어 대화 자체를 접는 컨텍스트 관리 계층입니다. 어제 오후 pipeshub-ai(엔터프라이즈 RAG·권한·MCP 지식층)와도 겹치지 않습니다. pipeshub는 회사 문서를 찾아 권한과 함께 넣는 쪽이고, billion-context는 지금 이 세션의 트랜스크립트를 계층적으로 접어 창 안에 남기는 쪽입니다.
한눈에 보는 핵심 사실
| 항목 | 값 (이 글에서 확인) |
|---|---|
| 저장소 | ranxianglei/billion-context (2026-08-06 17:27 KST 생성) |
| 버전 | npm/GitHub release v0.1.213 (tag 133f3525c628…, 2026-11-08 08:25 KST). 읽기용 클론 HEAD는 354e21e |
| 라이선스 | MIT (루트 LICENSE, npm license 필드, 커널 acp-kernel도 MIT). 논문 마크다운도 코드베이스의 일부로 MIT |
| 스타 / forks / watchers | 4,759 / 381 / 10 (GitHub API, 2026-11-08 약 16:55–16:58 KST) |
| 언어 비중 (GitHub Linguist 바이트) | TypeScript 97.9% · JavaScript 1.3% · Python 0.3% · HTML 0.3% |
| 패키지 | billion-context (engines: Node >= 20). 바이너리 bili, 별칭 bili-proxy |
| 런타임 의존성 | 배포 패키지 기준 mysql2, zod. optional jimp |
| 핵심 하위 패키지 | 저장소 kernel/의 acp-kernel 0.0.187 — “model-driven, 3-tier LSM”, 호스트 의존 없는 순수 코어 |
| 오늘 트렌딩 | 전체 일간 14위(+191), TypeScript 일간 4위(+191), 2026-11-08 재수집 |
| 슬로건과 실측의 간극 | README 상단은 “100K면 충분 · 토큰 5× 절감 · 월 단위 단일 세션”. 논문과 제3자 벤치는 상황별로 더 구체적인 숫자를 내놓으므로, 아래에서는 출처를 나눠 적습니다 |
무엇을 풀려는가: 창을 키우지 않고 세션을 늘리는 일
긴 코딩 세션은 도구 출력으로 창을 채웁니다. 공급자는 토큰을 과금하고, 창을 넘기면 세션은 끊기거나 한 번에 뭉개져 요약됩니다. README의 문장 그대로 billion-context는 “소비된 대화를 계층 요약으로 접어, 하나의 세션을 며칠 — 창 하나로 수십억 토큰 — 동안 돌리게” 합니다. 호스트 내장 요약기와 다른 점으로 문서는 증분적이고, 가역이며, prefix-cache 친화적이라고 말합니다. 요약을 작은 구간 단위로 쓰고, 필요할 때 되돌리며, 캐시 prefix는 그대로 둡니다.
압축 엔진의 역할 분담이 중요합니다. kernel/DESIGN.md는 zip과의 차이를 한 줄로 못 박습니다. zip은 바이트를 스스로 줄이지만, acp-kernel은 요약 문장을 쓰지 않습니다. 요약 텍스트는 모델이 만들고, 코어는 언제·어느 구간을 접을지 결정하고 상태를 추적하고 압축을 적용하고 필요하면 되돌리거나 검색합니다. “모델을 한 번도 호출하지 않는 순수 라이브러리”가 될 수 있는 이유입니다.
공식 docs/how-it-works.en.svg의 흐름은 이렇습니다. 에이전트의 base URL을 프록시로 향하게 하면, 프록시가 (1) Anthropic 또는 OpenAI 형태의 요청을 파싱하고 (2) acp-kernel으로 대화에 압축을 적용하고 (3) compress 도구와 압축 철학을 주입하고 (4) 실제 모델 API로 전달한 뒤 (5) 스트리밍 응답을 다시 씁니다. 모델이 컨텍스트가 커질 때 도구를 스스로 호출하고, 프록시는 compress를 서버 쪽에서 실행해 접힌 구간을 복원될 때까지 요약 상태로 유지합니다.
저장소 구조: 코드는 어디에 얼마나 있나
HEAD 354e21e를 얕게 클론해 확장자 기준(.ts .js .mjs .py .md 등)으로 줄 수를 셌습니다. 주석과 공백 줄이 포함된 대략치입니다.
| 디렉터리 | 역할 | 규모 (이 클론에서 센 값) |
|---|---|---|
src/ |
프록시·CLI·런처·클라이언트 어댑터(agent/, kimi/, zcode/, server/, storage/, loop/). TypeScript 파일 303개 |
파일 305 · 약 159,000줄 |
kernel/ |
acp-kernel 0.0.187. DESIGN.md가 순수 코어 계약. processTurn / compress / decompress / wire 어댑터 |
src 87파일 · 약 25,900줄 / tests 144파일 · 약 48,200줄 |
tests/ |
프록시·레인·프로토콜 회귀. 최상위 *.ts만 1,135개 |
파일 1,194 · 약 330,000줄 |
pi-subagents/, hermes-plugin/, plugins/ |
pi 내장 서브에이전트, Hermes Python 플러그인, Codex 쪽 보조 | 약 13,100 / 1,900 / 280줄 |
paper/, benchmarks/third-party-1500/ |
영·중 논문과 Figure 1–6, 1,500항 제3자 평가 보고서와 차트 PNG | 논문 md 2편 · 벤치 README 영/중 |
scripts/, docs/, website/ |
릴리스 게이트, how-it-works SVG, 웹 UI/블로그 자산 | scripts 약 7,800줄 |
의존성 경계도 눈여겨볼 만합니다. 루트 package.json의 runtime dependencies는 mysql2와 zod뿐이고, acp-kernel·tsx·node-forge 등은 devDependencies에 있습니다. npm에 올라가는 것은 빌드된 dist/입니다. README는 master를 “언제든 깨질 수 있는 개발 브랜치”로 경고하므로, 원본을 클론해 돌리기보다 릴리스를 쓰는 편이 맞습니다. 이 글의 스모크도 그 경고를 따랐습니다.
아키텍처 ①: 에이전트에 끼워 넣는 세 경로
Quickstart는 사용법을 셋으로 나눕니다. 메커니즘의 세부 — 플러그인 수명, 런타임 정보 프로토콜, 부착 게이트 — 는 TECHNICAL-NOTES.md로 밀어 두었습니다.
| 경로 | 명령 / 형태 | 무엇을 만지나 | 실무 함의 |
|---|---|---|---|
| Native plugin | bili plugin install <client> |
클라이언트가 프록시를 직접 띄우거나, 같은 코드 지문의 건강한 인스턴스에 붙음. 창 크기를 클라이언트의 실제 설정에서 읽어 프록시에 보고 | 평소처럼 클라이언트를 켜면 됨. 레거시 단독 확장(billion-context-pi, opencode-acp)과 동시에 쓰면 이중 압축 |
| Launcher | bili pi, bili claude, bili codex 등 |
설정 파일을 고치지 않고 프록시와 클라이언트를 함께 띄움. 클라이언트가 말하는 HTTPS 호스트만 화이트리스트 | base URL을 바꿀 수 있는 클라이언트는 /bili/ 재작성. 닫힌 바이너리는 문서가 말하는 로컬 cert-MITM 레인 |
| URL prefix | 프록시 기동 후 baseURL 앞에 http://localhost:8787/bili/ |
업스트림 URL을 경로에 심어 별도 설정 없이 전달 | 가장 보편적. 헬스체크는 GET /__bili/health |
포트 계약(#1660)은 단순합니다. 수동 bili start는 8787을 씁니다. 네이티브 훅이나 런처가 띄우는 레인은 18787부터 시작하는 별도 구역이고, 충돌 시 +1로 hop한 뒤 레인이 그 드리프트를 기억합니다. 서로 다른 선언 레인은 기본적으로 프록시를 공유하지 않습니다. 업그레이드 직후 이전 빌드가 같은 포트를 아직 쓰고 있으면 최대 5초 기다렸다가 같은 포트에 다시 붙습니다(#1723).
| 클라이언트 | 네이티브 플러그인 | 런처 | 끼워 넣는 방식 (문서 기준) |
|---|---|---|---|
| pi / omp / OpenCode / dsh / kimi / hermes / zcode | 있음 (bili plugin install …) |
있음 | 프로세스 안 훅이 프록시를 띄우고 도구를 등록. OpenCode는 호스트 자동 compaction을 꺼야 이중 압축을 피함 |
| Claude Code | 설정 블록 + SessionStart 훅 + MCP 셸 (#964) | bili claude |
ANTHROPIC_BASE_URL을 /bili/로 고정. Claude Desktop의 Code 탭은 자체 base URL이 관리 블록을 덮어 #2290으로 프록시를 우회 |
| Codex | MCP 도구만 (모델 트래픽은 못 꺾음) | bili codex가 완전한 자세 |
기본 ChatGPT 로그인 공급자는 설정 파일로 라우팅할 수 없음. 플러그인만 설치하면 프록시를 먼저 띄워야 함 |
| Gemini CLI / iFlow / Antigravity | 런처 전용(플러그인 이음새가 없거나 부족) | 있음 | 각각 GOOGLE_GEMINI_BASE_URL, IFLOW_BASE_URL, CLOUD_CODE_URL을 /bili/로 재작성 |
| Copilot CLI / Amp / Qoder / Trae / jcode / aider / crush / Zed | 없음 | 있음 | 닫힌 바이너리거나 플러그인 이음새가 없어, 문서가 로컬 HTTPS_PROXY + CA 주입(cert-MITM)으로 모델 호스트만 연다고 설명 |
| Goose | 없음 | 있음 | rustls가 CA 파일을 신뢰하지 않아 MITM 불가. OPENAI_HOST/ANTHROPIC_HOST와 설정 오버레이로 우회 |
닫힌 클라이언트 레인의 cert-MITM은 제품이 문서화한 로컬 TLS 종단입니다. 프록시는 클라이언트가 실제로 쓰는 모델 호스트만 화이트리스트에 넣고, 나머지 HTTPS는 blind tunnel로 통과시키며, HTTP/localhost는 직접 갑니다. 실무에서 이 말은 그 머신에서 모델 API의 평문을 로컬 프록시가 보게 된다는 뜻입니다. 단일 사용자 워크스테이션의 의도된 신뢰 경계로는 이해할 수 있지만, 공유 점프 호스트에 그대로 올리는 구성은 아닙니다. 구현 절차를 이 글에서 재현하지는 않습니다.
아키텍처 ②: Fold와 네 가지 도구, processTurn
프록시가 대화에 주입하는 컨텍스트 관리 도구는 넷입니다.
| 도구 | 역할 (README) |
|---|---|
compress |
메시지 구간을 상세 요약으로 접음. 프록시가 서버 쪽에서 실행 |
decompress |
정확한 원문이 다시 필요할 때 해당 구간을 복원 |
search_context |
접힌 요약과 아직 보이는 메시지를 키워드로 검색 |
acp_status |
창 사용량과 아직 접을 수 있는 구간 개요 |
논문은 이 레이아웃을 the fold라고 부릅니다. 접힌 내용은 버리지 않고 세션 머리쪽의 요약 블록으로 증류하며, 각 블록은 하나씩 되돌릴 수 있습니다. 최근 작업 영역(논문 서술은 약 50K 토큰)은 원문으로 남깁니다. 요약 블록 자신도 다음 압축의 입력이 되어 tier-2, tier-3으로 다시 접히는 “탑(pagoda)” 효과를 만듭니다. DESIGN.md의 블록 타입은 tier: 1 | 2 | 3에 generation: "young" | "old"를 두고, 나이로 지우는 GC는 없다고 명시합니다. 살아남은 횟수가 임계를 넘으면 young이 old로 승격되고, old 블록들은 한 요약으로 묶일 수 있습니다.
| processTurn 노드 (문서 순서) | 하는 일 |
|---|---|
| assign-refs | 원본 메시지 id와 짧은 참조(mNNNNN)를 대응 |
| sync-blocks | 압축 블록 상태를 현재 메시지와 맞춤 |
| merge-blocks | old-gen 블록을 모아 한 요약으로 합침 |
| prune | 더 이상 유효하지 않은 범위를 정리 |
| ccr-store | 콘텐츠 저장소(CCR)와 동기화 |
| filter | 보호 도구 등 필터 규칙 적용 |
| hide-compress-calls | 이미 소비된 compress 호출을 숨김 |
| nudge-inject | 창이 임계(예: minContextLimitPct 0.45)를 넘으면 모델에게 접을 후보를 권고. 주입문은 압축이 끝나면 제거 |
| emergency-truncate | 마지막 안전판. 도구 출력을 잘라 창을 지킴 |
| render-refs | 참조를 다시 렌더해 호스트/와이어 형태로 돌려줌 |
코어는 상태를 붙들지 않습니다. 매 호출에 상태를 넣고 꺼내가며, 어디에 저장할지는 호스트(여기선 bili 프록시)가 정합니다. 이 경계 덕분에 커널만 따로 테스트할 수 있었고, 실제로 이 박스의 단위 테스트도 그 계층에서 돌렸습니다.
아키텍처 ③: 창 크기 해석과 prefix-cache
네이티브 플러그인은 클라이언트가 실제로 쓸 모델 설정을 읽을 수 있습니다. 그 값을 프록시에 두 채널로 밀어, models.dev 레지스트리 추측보다 앞세웁니다(#955).
| 창 크기 해석 순서 (높은 우선순위부터) | 출처 |
|---|---|
1. anthropic-beta 협상 |
프로토콜이 알려 준 창 |
| 2. 요청마다 붙는 플러그인 헤더 | x-bili-plugin-context-window, x-bili-plugin-max-output, x-bili-plugin-model |
| 3. runtime-info | POST /__bili/plugin/runtime-info (루프백). 부트스트랩과 설정 변경 시 |
| 4. 런처 환경변수 | BILI_LAUNCHER_MODEL_WINDOWS / BILI_LAUNCHER_MODEL_MAX_OUTPUTS |
| 5. 라우트 설정 → models.dev → 내장 테이블 | 플러그인이 없는 순수 프록시 클라이언트의 폴백 |
prefix-cache를 깨지 않는 쪽이 이 시스템의 경제입니다. 논문은 히스토리가 append-only이고 압축이 접미사 구간만 비활성화하므로, 압축 자체가 KV-cache prefix를 무효화하지 않는다고 말합니다. 호출 간격이 2분 미만인 활성 템포(트래픽의 89%)에서 측정한 캐시 읽기 비중은 94.2%입니다. 캐시를 갖춘 호스트 두 대의 혼합값은 88.3–90.7%로 더 낮은데, 문서는 이를 레이아웃 문제가 아니라 유휴 중 공급자 쪽 캐시 만료 탓으로 돌립니다. README의 운영 경험 법칙은 건강한 세션의 prefix-cache 적중을 95–97%, 압축 자체 비용을 ≤2%로 적고, 지속해서 낮으면 /acp 또는 /acp-cache로 원인을 나누라고 합니다. 흔한 원인 순서는 업스트림 캐시 TTL 만료, 모델 교체, bili 버그, 그다음 기타/미상입니다.
디스크 쪽 경계도 같이 읽어야 합니다. 한 호스트의 모든 bili 인스턴스는 같은 XDG 데이터/상태 디렉터리(~/.local/share/billion-context/, ~/.local/state/billion-context/)를 씁니다. 컨트롤 플레인은 레인 단위로 갈라지지만 데이터 플레인은 갈라지지 않습니다(#394, #1724). 루프백으로 도달 가능한 인스턴스는 다른 레인·세션의 원문과 압축 블록을 나열할 수 있습니다. 문서는 단일 사용자 호스트에서는 충분하고, 다중 사용자 호스트에서는 충분하지 않다고 분명히 적습니다.
논문이 보고한 생산 기록 — 저자 종단 연구
저장소 paper/의 영문 초고 제목은 “Model-Driven Incremental Hierarchical Compression: Training-Free Multi-Generational Context Management for Long-Lived Coding Agents”(v0.2)입니다. 아래 숫자는 그 문서와 요약 표에서 옮긴 것이며, 이 박스가 재현한 벤치가 아닙니다.
| 항목 | 논문이 적은 값 | 메모 |
|---|---|---|
| 관측 기간 / 호스트 | 4.5개월, 호스트 3대 | 매일 생산 사용 |
| Fold를 쓴 세션 | 4,843개 (사용 기록이 남은 세션 917개) | §6.1 |
| 모델 호출 | 174,327회 | |
| 누적 입력 토큰 | 18.76B (신선 1.75B + 캐시 읽기 17.01B). 세 호스트 합계 ≈24.7B | 이름이 billion-context인 이유라고 문서가 적음 |
| 204,800 토큰 창 | 창 초과 0건. 평균 107.6K, 피크 198,628 | |
| 마라톤 세션 | 8,584–12,049 호출, 누적 약 1–1.5B 토큰 (1M급 창) | 평균 컨텍스트 약 120K |
| Pi 호스트 호출당 컨텍스트 | 평균 88K, 중앙값 72K, p99 218K | OpenCode 쪽 통계는 큰 정적 AGENTS.md 때문에 부풀어 있다고 주석 |
| 압축된 토큰 | 총 229M. 그중 62%가 메시지 1,000개 초과 세션에 몰림 (그런 세션은 전체의 1.3%) | “마라톤 현상” |
| 요약 길이 | 압축 출력 중앙값 185 토큰, 97.5%가 2K 이하 | |
| 고부하 세션의 standing fold | 평균 히스토리 ~900K (중앙값 ~530K)가 요약 ~13K로 남음 (약 70×) | |
| 재읽기 | 이미 접힌 내용을 다시 가져오는 호출 63% 감소 (2.7×) | 상당 부분은 압축 자체가 아니라 doctrine 텍스트+태그에서도 재현된다고 문서가 솔직히 적음 |
| 통제 실험의 과금 토큰 | BC 설정이 31–54% 절감 (메인 테이블 기준) | README 상단의 “5×”와는 다른 기준 |
| 1M 창의 모형 상한 | 106일에 28.6B (이산사건 시뮬레이션) | 관측된 최대 세션의 약 19× 외삽. 실측 코퍼스 18.76B/24.7B와 나란히 비교하지 말라고 문서가 못 박음 |
전통적인 임계값 일괄 압축과의 대비도 논문의 핵심입니다. 매 라운드 창의 약 80%를 다시 요약하면 초기 내용은 ρ^k로 기하 감쇠하고(ρ≈0.4–0.6이면 네 라운드 후 3–13%), Fold는 소비된 증분만 한 번 접은 뒤 그대로 상주시키므로 유지율이 라운드마다 다시 깎이지 않는다고 주장합니다. 생산에서 tier-2 재증류는 1,711개 블록 중 60개에만 닿았습니다.
제3자 1,500항 벤치 — v0.1.202, 이 박스 미재현
benchmarks/third-party-1500/README.md는 Billion Context v0.1.202를 full(원문 베이스라인) 및 RAG 3종(bm25, embedding, embedding-rerank)과 비교합니다. 벤치 세 개 × 500항 = 1,500항입니다. 공통 업스트림은 DeepSeek V4.1 Flash 1017, 임베딩 Qwen3-Embedding-8B, 리랭커 Qwen3-Reranker-4B, ContextBench 하네스는 Pi CLI v0.73.1입니다. 오늘 스모크한 0.1.213과 버전이 다르고, 이 박스에는 해당 벤치를 돌릴 GPU·데이터·과금이 없습니다. 숫자는 보고서에서 옮깁니다.
| LongMemEval-S (500항, ~110k) | Overall Acc | Multi-Session | Mean input | 독립 세션 과금 |
|---|---|---|---|---|
full |
83.20% | 84.21% | 106.0k | $7.97 (순차 평가의 캐시 적중을 걷어 낸 기준) |
bc |
79.20% (full의 95.2%) |
79.70% | 30.5k | $2.30 (−71.1%) |
best RAG (embedding-rerank) |
62.60% | 45.11% | 14.3k | $1.39 |
bm25 / embedding |
56.40% / 46.40% | 37.59% / 30.83% | 14.3k | $0.08 / $0.68 |
같은 건초 더미를 이어서 평가하면 full의 접두 캐시 적중이 98.1%라 청구액이 $0.42까지 내려갑니다. 보고서는 사용자 세션이 서로 캐시를 나누지 않는 쪽이 현실에 가깝다고 보고, 그 기준으로 −71.1%를 계산합니다. 다중 세션 추론에서 RAG가 45.1%까지 무너지는 동안 bc는 79.7%를 유지한 점이 이 벤치의 핵심 주장입니다.
| ContextBench (500항, 저장소 58개, Pi) | Utilized F1 | Evidence Precision | 청구 비용 |
|---|---|---|---|
bc |
0.3097 (1위) | 0.3358 (1위) | $4.61 (−58.3% vs full) |
full |
0.2928 | 0.3125 | $11.05 |
embedding-rerank |
0.2894 | 0.3095 | $6.35 |
bm25 / embedding |
0.2600 / 0.2584 | 0.2788 / 0.2757 | $6.31 / $6.91 |
보고서는 멀티턴 코딩에서 중간 grep/파일 읽기 출력이 창을 더럽힌다고 보고, 그 잡음을 접는 편이 최종 근거 정밀도와 비용을 동시에 개선했다고 해석합니다. Evidence Recall은 full(0.3712)이 bc(0.3694)보다 살짝 높습니다.
| MemoryAgentBench (500항) | Macro Avg | AR 197k EM (바늘) | TTL 1.48M Recall@10 | TTL 프롬프트 |
|---|---|---|---|---|
embedding-rerank |
55.21% | 66.33% | 21.19% | 42.3k |
bm25 |
53.70% | 59.00% | 22.08% | 42.3k |
full |
51.11%* | 69.00% | 0.00% (199/199 실패) | >1,000k (실패) |
embedding |
51.10% | 53.67% | 21.92% | 42.3k |
bc |
43.54% | 27.00% | 18.58% (100% 생존) | 평균 49.5k, 정상 상태 ~16k (약 30×) |
여기가 정직한 경계입니다. 1.48M 토큰 TTL에서 full은 전원 창 초과로 죽지만 bc는 살아남습니다. 반대로 197k 건초 더미의 문자 그대로 바늘(AR)은 의미 압축 때문에 69.0%에서 27.0%로 떨어집니다. 보고서는 이 지점을 “언제 BC를 쓰고 언제 인덱스 RAG를 쓸지”의 경계로 명시합니다. 진화하는 멀티턴 에이전트·시간/교차 세션 추론은 BC 쪽, 정적 원문 룩업은 RAG 쪽입니다.
비슷한 도구와 어디가 다른가
| 시스템 | 하는 일 | billion-context와의 관계 | 주의 |
|---|---|---|---|
| 호스트 내장 auto-compact (Claude/Codex/OpenCode 등) | 창이 차면 히스토리를 한 번에 요약하고 원문을 버림 | 같은 “세션을 계속 살리는” 목표. Fold는 증분·가역·prefix 유지를 차별점으로 내세움 | OpenCode는 네이티브 compaction을 끄지 않으면 이중 압축. Claude Desktop Code 탭은 bili를 우회하면서도 DISABLE_AUTO_COMPACT=1은 남을 수 있음(#2290) |
| 인덱스 RAG (bm25 / embedding / rerank) | 정적 코퍼스에서 청크를 검색 | 제3자 벤치의 직접 비교 대상. 바늘 찾기와 1.48M 추천에서는 RAG가 앞서거나 비슷 | LongMemEval의 다중 세션 추론에서 크게 뒤짐 (45.1% vs 79.7%) |
| pipeshub-ai | 권한 붙은 회사 지식을 에이전트에 연결하는 RAG/MCP 층 | 어제 오후 글(4563)의 주제. 외부 문서를 찾는 층 | 세션 트랜스크립트를 접는 계층이 아님. 둘을 같은 “컨텍스트 제품”으로 바꾸어 읽으면 안 됨 |
| vectorize-io/hindsight | retain · recall · reflect 기억 저장소 | 10/25 글(3561). 세션을 넘어 “배우는” 메모리 | 라이브 창을 접는 Fold와는 수명이 다름 |
| thedotmack/claude-mem | 세션을 압축해 다음 세션에 다시 주입 | 주간 트렌딩 1위. 다음 세션을 위한 기억 | 같은 세션 안에서 창을 유지하는 문제와는 축이 다름 |
| JuliusBrussee/caveman | 말을 짧게 만들어 토큰을 줄임 | 10/16 글(2866). 프롬프트 스타일 | 창 초과를 관리하지 않음. 게이트웨이 제품이 부가 기능으로 얹는 경우와 혼동하지 말 것 |
설치·실행과 박스 실측 (2026-11-08 16:57–16:58 KST)
문서의 권장 설치는 npm install -g billion-context --prefix=~/.local입니다. 이 박스는 홈을 더럽히지 않으려고 작업 디렉터리 prefix에 billion-context@0.1.213을 설치했습니다. 93개 패키지가 4초 만에 내려왔습니다. Node는 v20.19.2입니다.
| 명령 / 조건 | 결과 | 해석 |
|---|---|---|
bili --version |
0.1.213 (133f3525c) |
npm 배포본이 GitHub 태그 SHA 앞자리와 일치 |
bili --help |
시작, 20개 넘는 런처 레인, doctor, plugin, sessions, storage gc, pack, acp-cache diff 등을 출력 |
CLI 표면이 README와 맞음 |
bili doctor |
disk 0.1.213 = registry latest, verdict ok, 레인 9개 모두 absent, 프로세스 0 | 갓 설치한 전역 npm 카피의 기대 상태 |
bili plugin list |
pi/omp/claude/codex/opencode/kimi/hermes/zcode = not installed. dsh는 ~/.dsh/profiles가 없어 에러 |
호스트 클라이언트를 설치하지 않은 정직한 결과 |
bili pack list |
default 1.0.0 (builtin), lean 1.0.0 (builtin), chat 0.1.0 (shipped:chat) |
압축 프롬프트 팩이 실제로 나열됨 |
bili sessions ls (기본값) |
실패: [storage:node:sqlite] no SQLite engine available. 정책상 저하(degradation)를 거부 |
통합 스토리지는 SQLite를 요구. JSON만 쓰려면 문서/에러가 안내하는 BILI_STORAGE_UNIFIED=legacy |
BILI_STORAGE_UNIFIED=legacy bili start --port 18799 --passthrough --no-auto-update 후 GET /__bili/health |
{"ok":true,"upstream":"https://api.anthropic.com","version":"0.1.213","commit":"133f3525c",…} |
레거시 스토리지로 프록시는 기동됨. --passthrough라 이 인스턴스는 압축 없이 전달하는 자세 |
GET /__bili/status |
storage.requested/effective = legacy, stale: false, inFlight: 0, resolverWedge: null |
빈 세션의 정상 상태. 모델 API 키는 넣지 않았으므로 실제 턴은 돌리지 않음 |
kernel/에서 npm test (tsx, 144 파일) |
tests 1609 · suites 23 · pass 1607 / fail 2 · 9.47초 | 실패한 두 건은 모두 persist.test.ts의 Promise.withResolvers is not a function (Node 20). 엔진은 >=20을 선언하지만 해당 경로는 Node 22 API를 씀 |
하지 않은 것도 분명히 적습니다. 모델 API 호출이 필요한 실제 compress 라운드, ContextBench/LongMemEval 재실행, cert-MITM 레인으로 외부 클라이언트 붙이기는 돌리지 않았습니다. 커널 테스트 1,607건은 요약 문자열을 테스트 픽스처로 넣는 쪽이므로, “모델이 요약을 얼마나 잘 쓰는지”가 아니라 “접고 되돌리고 검색하는 오케스트레이션이 깨지지 않는지”를 검증합니다. 그 범위 안에서는 대부분의 계약이 이 박스의 Node 20에서도 성립했고, 실패한 2건은 지속성 재시도 헬퍼의 런타임 API 불일치입니다.
트레이드오프와 주의점
| 항목 | 내용 | 대응 |
|---|---|---|
| 손실 압축 | 의미 추상화는 문자 그대로 바늘(MAB AR 27% vs full 69%)을 깎음 | 원문 룩업이 주 업무면 인덱스 RAG가 맞음 |
| 벤치 버전 | 공개 1,500항 숫자는 v0.1.202 | 0.1.213 도입 판단을 그 표에만 맡기지 말 것 |
| 5× 슬로건 | README 상단 카피. 논문 통제 실험은 31–54%, ContextBench 독립 기준은 −58.3%, LME 독립 세션은 −71.1% | 워크로드를 다시 재어 읽어야 함 |
| 닫힌 클라이언트 레인 | 문서화된 로컬 cert-MITM. 모델 트래픽 평문이 프록시에 보임 | 단일 사용자 머신으로 한정하고, 공유 호스트에는 올리지 말 것 |
| 공유 상태 디렉터리 | 레인 간 세션이 디스크에서 격리되지 않음 (#1724) | 다중 계정 호스트는 디렉터리를 나눠야 함. 루트 수정은 문서가 아직 열린 결정으로 적음 |
| 스토리지 엔진 | 기본 통합 스토리지는 SQLite를 요구하며 저하를 거부 | 엔진을 갖추거나 BILI_STORAGE_UNIFIED=legacy를 명시 |
| 이중 압축 | 네이티브 플러그인과 레거시 단독 확장, 또는 호스트 auto-compact와의 중첩 | 설치기가 .bili-bak으로 갈아 끼우고, OpenCode는 compaction.auto: false |
| Claude 계정 종속 기능 | 커스텀 ANTHROPIC_BASE_URL이면 Remote Control 등이 빠짐 (#4693) |
그 기능이 필요하면 해당 세션은 bili 없이 실행 |
| Node 20 vs 22 | 커널 persist 경로가 Promise.withResolvers를 사용 |
이 박스(Node 20.19.2)에서 persist 테스트 2건 실패. 배포 CLI 헬스체크는 통과 |
| 이슈 규모 | open_issues_count 910 |
활발한 멀티 클라이언트 호환 작업의 반영이기도 하고, 표면이 넓다는 뜻이기도 함 |
누가 도입을 검토할 만한가
| 상황 | 판단 |
|---|---|
| 하루가 아닌 며칠·몇 주짜리 단일 코딩 세션을 같은 창에서 유지해야 하고, 호스트 일괄 요약 뒤 되돌릴 수 없어 답답한 경우 | 가장 잘 맞는 대상. pi/OpenCode/Claude/Codex처럼 문서가 레인을 명시한 클라이언트부터 |
| 접두 캐시 요금이 청구의 대부분인 공급자를 쓰며, 일괄 compact가 캐시를 자주 깨는 경우 | 검토할 만함. 다만 적중률은 /acp-cache로 직접 봐야 함 |
| 정적 코퍼스에서 문장을 그대로 찾아야 하는 검색·규정 업무 | 부적합에 가깝음. 제3자 벤치도 RAG를 더 나은 쪽으로 표시 |
| 회사 문서에 권한을 붙여 에이전트에 넣고 싶은 경우 | 이 제품의 문제가 아님. RAG/권한 층(예: 어제 다룬 pipeshub)을 따로 봐야 함 |
| 공유 서버에 여러 사용자가 같은 bili를 올려 쓰는 경우 | 지금 구조에서는 비권장. 세션 격리가 없음 |
| 추론 엔진 자체를 고르고 있는 경우 | 대상이 아님. 오늘 오전의 ninfer 같은 계층을 볼 일 |
정리하면 billion-context는 “더 큰 창”이나 “더 좋은 RAG”가 아니라, 모델에게 접을 자리를 고르게 하고 그 결정을 가역적인 블록으로 남기는 세션 계층입니다. 코어는 요약을 쓰지 않고, 프록시는 너무 많은 클라이언트 이음새를 받아 내기 위해 네이티브 훅·URL 재작성·문서화된 로컬 MITM을 나란히 둡니다. 생산 종단 기록과 1,500항 벤치는 방향은 보여 주지만 버전과 기준이 갈리므로, 도입 결정은 자기 클라이언트의 레인과 /acp-cache 숫자로 다시 읽어야 합니다. 이 박스에서 확인한 것은 그 전까지의 층 — CLI, 헬스체크, 레거시 스토리지 기동, 커널 오케스트레이션 테스트 1,607건 — 입니다.