# Claude Code는 프롬프트를 읽기 전 3.3만 토큰, OpenCode는 7천 토큰을 전송함

> Clean Markdown view of GeekNews topic #31373. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31373](https://news.hada.io/topic?id=31373)
- GeekNews Markdown: [https://news.hada.io/topic/31373.md](https://news.hada.io/topic/31373.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-13T09:55:24+09:00
- Updated: 2026-07-13T09:55:24+09:00
- Original source: [systima.ai](https://systima.ai/blog/claude-code-vs-opencode-token-overhead)
- Points: 3
- Comments: 1

## Topic Body

- 동일한 모델·머신·작업에서 API 경계를 측정한 결과, Sonnet 4.5 첫 요청의 고정 오버헤드는 **Claude Code 약 32,800토큰**, OpenCode 약 6,900토큰으로 4.7배 차이 났으며 Fable 5에서는 약 3.3배로 줄어듦
- 격차의 대부분은 **도구 스키마**에서 발생함. Claude Code는 27개 도구 정의에 약 24,000토큰, OpenCode는 10개 도구에 약 4,800토큰을 사용했고, 도구를 모두 꺼도 시스템 프롬프트가 각각 약 6,500토큰과 2,000토큰이었음
- 실제 설정에서는 72KB 명령 파일이 요청마다 약 20,000토큰, 소형 MCP 서버 하나가 약 1,000~1,400토큰을 추가해 첫 요청만 **75,000~90,817토큰**에 이를 수 있음
- Claude Code는 동일한 파일 요약 작업에서 OpenCode보다 **캐시 쓰기를 5.9~54배** 많이 발생시켰고, 두 하위 에이전트로 작업을 분산하자 직접 실행 시 121,000토큰이던 사용량이 513,000토큰으로 4.2배 늘어남
- 고정 오버헤드만으로 전체 비용을 판단할 수는 없음. 다단계 작업에서는 Claude Code가 도구 호출을 병렬 배치해 3회 요청으로 약 121,000토큰을 쓴 반면, OpenCode는 직렬 호출 9회로 약 132,000토큰을 사용함

---

### API 경계에서 측정한 방법
- Claude Code와 OpenCode 사이에 **로깅 프록시**를 배치해 하네스가 보낸 정확한 JSON 요청과 API가 반환한 사용량 블록을 기록함
  - 요청 본문에는 시스템 블록, 도구 스키마, 메시지가 포함됨
  - 사용량에는 입력 토큰, 캐시 쓰기·읽기, 출력 토큰이 포함됨
  - 캡처한 요청 본문은 실제 전송 내용, API 사용량 블록은 실제 과금량의 기준으로 사용함
- 기본 비교에는 Claude Code 2.1.207과 OpenCode 1.17.18을 사용하고, 둘 다 2026년 7월 기준 `claude-sonnet-4-5`에 고정함
  - 고정 오버헤드, 캐시 작업, 다단계 작업의 일부는 `claude-fable-5`로 다시 실행함
  - 새 설정 디렉터리, MCP 서버·사용자 설정·메모리가 없는 상태, 명령 파일이 없는 빈 작업 공간에서 기본값을 격리함
- 세 가지 작업으로 서로 다른 비용 구조를 측정함
  - T1은 `Reply with exactly: OK`로 고정 오버헤드를 분리했으며 하네스마다 3회 실행함
  - T2는 미리 준비한 파일을 읽고 요약하게 함
  - T3는 FizzBuzz와 검사 스크립트를 대상으로 작성·실행·테스트·수정 절차를 수행함
- 도구 스키마를 제외한 시스템 프롬프트를 비교하기 위해 Claude Code에는 `--tools ""`, OpenCode에는 `"tools": {"*": false}`를 적용함
- 로컬 LLM 게이트웨이가 요청마다 약 **6,200토큰의 고정 봉투**를 추가해 이를 보정한 뒤 계측값에서 제외함
  - 구성요소별 수치는 게이트웨이가 바꿀 수 없는 캡처 요청 본문에서 계산함
  - 문자·토큰 변환에는 콜드 캐시 기준으로 측정한 하네스별 4.1~4.4자당 1토큰 비율을 사용함

### 기본 오버헤드를 키우는 도구 스키마
- 22자짜리 T1 프롬프트의 첫 요청에서 Claude Code는 약 **32,800토큰**, OpenCode는 약 6,900토큰을 전송함
  - Claude Code 시스템 프롬프트는 3개 블록, 27,344자였고 OpenCode는 1개 블록, 9,324자였음
  - Claude Code의 27개 도구 스키마는 99,778자, OpenCode의 10개 도구는 20,856자였음
  - Claude Code는 실제 프롬프트 앞에 에이전트 유형, 사용 가능한 스킬, 사용자 컨텍스트를 담은 `<system-reminder>` 블록 7,997자를 삽입함
  - OpenCode는 별도의 첫 메시지 스캐폴딩 없이 시스템 블록, 10개 코딩 도구, 사용자 프롬프트를 보냄
- 양쪽 모두 **도구 정의**가 가장 큰 비중을 차지함
  - Claude Code의 약 33,000토큰 중 약 24,000토큰이 도구 정의임
  - OpenCode의 약 6,900토큰 중 약 4,800토큰이 도구 정의임
  - Claude Code 도구에는 코딩 기능뿐 아니라 `CronCreate`, `Monitor`, `Task` 계열, 작업 트리 관리, 푸시 알림 등 백그라운드 에이전트·오케스트레이션 기능이 포함됨
- 도구를 전부 제거하면 Claude Code 시스템 프롬프트는 26,891자, 약 6,500토큰이고 OpenCode는 8,811자, 약 2,000토큰임
  - 두 하네스 모두 도구가 비활성화되면 프롬프트가 조금 줄어듦
  - 남은 차이는 어조, 안전 지침, 작업 관리 규칙, 환경 정보 등 **행동 지침**에서 발생함
- Fable 5에서는 Claude Code가 모델에 따라 프롬프트를 줄여 격차가 약 3.3배로 축소됨
  - 시스템 지침은 Sonnet의 27,787자에서 Fable의 10,526자로 감소함
  - 같은 27개 도구를 유지하면서 스키마도 99,778자에서 82,283자로 줄어듦
  - OpenCode 요청은 두 모델에서 바이트 단위로 동일했음

### 작업 형태에 따라 달라지는 전체 사용량
- 파일 하나를 읽고 요약한 T2에서는 두 하네스 모두 정확한 결과를 냈지만 요청 구조가 달랐음
  - Claude Code는 HTTP 요청 6회와 누적 입력 약 **199,000토큰**을 사용함
  - OpenCode는 요청 4회와 약 41,000토큰을 사용하고 세션 제목 생성을 위한 Haiku 호출 1회를 추가함
  - 사용량 대부분은 입력 가격의 10분의 1로 과금되는 캐시 읽기였음
- 캐시 할인이 있어도 첫 요청의 캐시 쓰기, 매 턴의 캐시 읽기, 컨텍스트 창 점유는 페이로드 크기에 따라 증가함
  - 33,000토큰 기준선은 코드가 들어오기 전부터 200,000토큰 창의 약 6분의 1을 차지함
- 작성·실행·테스트·수정 작업인 T3에서는 **도구 호출 방식**이 기본 오버헤드 차이를 상쇄함
  - Claude Code는 파일 쓰기 2회와 스크립트 실행 2회를 하나의 병렬 도구 왕복으로 배치해 모델 요청 3회, 누적 입력 약 121,000토큰을 기록함
  - OpenCode는 턴마다 도구 하나만 호출해 9회 요청과 제목 호출 1회, 누적 입력 약 132,000토큰을 기록함
  - 전체 입력은 대략 요청당 기준선과 요청 횟수의 곱에 대화 증가분을 더한 값으로 결정됨
- 대화가 진행되면서 Claude Code는 `<system-reminder>`를 첫 턴의 3개에서 첫 도구 왕복 시점의 4개로 늘림
- OpenCode의 턴별 추가 페이로드는 약 400~2,200자로, 대화 내용만 증가함

### 실제 설정이 추가하는 토큰
- 프로덕션 저장소의 72KB `AGENTS.md`를 추가하자 두 하네스 모두 요청마다 **20,000토큰 이상** 증가함
  - OpenCode 계측값은 13,152토큰에서 33,336토큰으로 증가함
  - Claude Code는 39,005토큰에서 59,243토큰으로 늘어남
  - Claude Code 2.1.207은 `AGENTS.md`를 무시했으며, `CLAUDE.md`로 이름을 바꿔야 첫 사용자 메시지에 삽입함
  - OpenCode는 두 파일명을 모두 읽어 시스템 프롬프트에 삽입함
  - 하네스가 실제로 인식하는 파일명을 확인하지 않으면 명령 파일이 조용히 무시될 수 있음
- 공개형 소형 **MCP 서버**는 서버 하나당 요청마다 약 1,000~1,400토큰을 추가함
  - 서버 5개는 Claude Code 페이로드에 4,900토큰, OpenCode 계측값에 6,967토큰을 더함
  - 도구 수는 Claude Code에서 27개에서 69개, OpenCode에서 10개에서 52개로 늘어남
  - 풍부한 API를 가진 프로덕션 서버는 더 큰 스키마를 보낼 수 있음
  - Claude Code의 print 모드는 명시적인 `--mcp-config`가 없으면 프로젝트 범위 `.mcp.json`을 조용히 무시했으므로 API 경계에서 연결 여부를 확인해야 함
- BMAD 같은 스토리 기반 워크플로 프레임워크는 페르소나·프로토콜·체크리스트를 담은 큰 템플릿을 슬래시 명령으로 확장함
  - 실험의 8,405자 템플릿 자체는 약 2,100토큰이지만 대화 기록에 들어가 이후 모든 요청에서 다시 전송됨
  - 요청 9회인 세션에서는 같은 템플릿이 9회 실리므로 비용은 **템플릿 크기 × 요청 수**로 증가함
- 실제 구성의 첫 요청은 기본 오버헤드보다 훨씬 커졌음
  - OpenCode는 이메일·캘린더, 작업 관리, 참고문헌 관리, 제품 분석 등을 위한 MCP 서버 11개와 72KB 명령 파일을 사용해 179개 도구와 277KB 스키마, 콜드 캐시 쓰기 **90,817토큰**을 기록함
  - Claude Code는 MCP 서버 4개, 설치된 플러그인, 같은 명령 파일로 118개 도구와 311KB 페이로드, 약 75,000토큰을 기록함
  - OpenCode 구성은 게이트웨이 봉투를 제외하면 약 7,000토큰인 기본값의 약 12배였음

### 하위 에이전트와 확장 사고의 비용
- Claude Code가 작업을 두 하위 에이전트에 병렬 분산하자 직접 실행의 121,000토큰이 **513,000토큰**으로 늘어 4.2배가 됨
  - 주 세션, 하위 에이전트 호출 등 세 가지 요청 유형에서 총 9회의 모델 요청이 발생함
  - 하위 에이전트 호출 5회는 각각 3,554자 시스템 프롬프트와 기본 27개 중 24개 도구로 자체 부트스트랩함
  - 각 하위 에이전트가 초기 비용을 부담하고 그 실행 기록을 부모가 다시 읽는 구조임
- OpenCode 하위 에이전트는 1,379자 시스템 프롬프트와 도구 5개만 사용하는 축소 프로필을 전송함
  - 게이트웨이를 통한 실행이 정상 완료되지 않아 OpenCode의 전체 하위 에이전트 사용량은 수치화하지 않음
  - 캡처한 페이로드에서 확인된 설계 차이만 비교함
- **확장 사고** 출력은 입력 단가의 5배인 출력 단가로 과금되며, 추론 블록이 대화 기록에 포함돼 이후 요청에서 다시 전송됨
  - 게이트웨이 자체 사고 정책 때문에 두 하네스의 설정이 실제로 적용됐는지 확인할 수 없어 측정 수치는 공개하지 않음
  - 추론 블록이 기록에 합류하는 비용 구조만 확인 대상으로 남김

### 프롬프트 캐시의 경제성과 안정성
- 두 하네스 모두 캐시 중단점을 올바르게 설정함. 페이로드는 5분 TTL 기준 기본 입력 가격의 **1.25배**로 한 번 쓰이고 이후 10분의 1 가격으로 읽힘
- 캐시로 줄지 않는 비용은 세 가지임
  - 5분 이상 중단되면 전체 스택을 다시 써야 하므로 회의나 식사 같은 휴지 뒤에는 쓰기 비용이 재발함
  - 캐시 읽기도 요청 횟수만큼 반복되므로 직렬 도구 루프와 하위 에이전트 분산이 비용을 늘림
  - 컨텍스트 창 점유는 캐시 할인의 영향을 받지 않아 85,000토큰 부트스트랩이 200,000토큰 창의 40% 이상을 차지하고, 압축이 시작되면 요약 비용도 추가됨
- OpenCode는 캡처한 모든 요청과 실행에서 **바이트 단위로 동일한 접두부**를 유지함
  - 세 번의 T1 세션에서 도구, 시스템, 메시지 바이트가 동일했고 반복 실행의 캐시 쓰기는 0이었음
  - 9개 요청으로 구성된 T3 세션도 하나의 안정된 접두부를 유지함
- Claude Code는 세션마다 워밍업 탐색, 주 대화, 하위 에이전트 호출이라는 서로 다른 요청 유형과 캐시 항목을 만듦
  - 같은 작업 공간에서도 시스템 바이트와 첫 메시지 스캐폴딩이 실행별로 달라짐
  - 동일한 파일 요약 작업에서 5개 요청에 걸쳐 53,839 캐시 토큰을 썼고, 약 43,000토큰 접두부 전체를 작업 중간에 한 번 다시 씀
  - OpenCode의 같은 작업 캐시 쓰기는 1,003토큰이었음
- Claude Code의 대규모 중간 캐시 재쓰기는 반복 실험에서도 나타남
  - 첫 두 실행에서 각각 43,342토큰과 36,899토큰을 다시 썼고, 새로 예열한 캐시를 사용한 세 번째 실행에서는 거의 쓰지 않음
  - Fable 5에서도 캐시 읽기 없이 50,053토큰을 다시 써 Sonnet의 54배와 비슷한 52배 격차가 발생함
  - 캐시 온도에 따라 Claude Code의 캐시 쓰기량은 OpenCode의 **5.9~54배**였음
  - 캐시 쓰기 단가는 5분 계층에서 기본의 1.25배, 1시간 계층에서 2배임
- 단일 캐시 누락은 게이트웨이의 축출 때문일 수도 있으나, 여러 실행에서 재현됐고 요청 전 캡처 바이트에서도 접두부 불안정성이 확인됨
  - 접두부가 크고 종류가 많으며 재쓰기가 반복되고 하위 에이전트까지 더해지면 Claude Code 사용량 계기판이 더 빠르게 증가할 수 있음

### 결과 품질과 감사 로그
- 두 하네스는 평가 대상 작업을 모두 정확히 완료함
  - 파일 요약 결과는 모두 정확했음
  - 다단계 작업은 각 하네스가 작성한 검증 스크립트를 통과하고 정상 종료함
  - 이 범위에서는 같은 결과를 얻는 데 필요한 토큰 비용 차이를 비교할 수 있었음
- 더 어려운 실제 엔지니어링 작업에서 Claude Code의 백그라운드 에이전트, 스킬, 오케스트레이션이 추가 비용만큼 품질을 높이는지는 측정하지 않음
  - 이를 판단하려면 적절한 테스트 모음, 충분한 반복 실행, 통과율 평가가 별도로 필요함
- 품질과 무관한 낭비도 확인됨
  - 바이트가 같은 캐시 접두부를 세션 중간에 다시 쓰는 것은 같은 내용을 프리미엄 가격으로 재구매하는 셈임
  - 하네스가 명령 파일을 조용히 무시하면 해당 파일에서 어떤 효용도 얻을 수 없음
- 캡처한 요청·응답 **185개 기록**을 오픈소스 라이브러리 [`@systima/aiact-audit-log`](https://github.com/systima-ai/aiact-audit-log)로 SHA-256 해시 체인에 기록함
  - 체인은 중단 없이 끝까지 검증됐으며 무결성 결과는 `VALID`였음
  - 같은 구조로 전송·응답 내용을 재구성하고 제3자에게 무결성 자료를 제공할 수 있음
  - 이는 EU AI Act Article 12 로깅에 제공되는 구조화 기록 방식과 동일함

### 측정의 한계와 재현 방법
- 결과는 한 대의 머신, 두 하네스 버전, 작은 표본을 사용한 **2026년 7월 스냅샷**임
  - T1과 T2는 각각 3회, 각 구성 배수 조건은 1회 실행함
  - 기본값과 캐시 조건은 Sonnet 4.5와 Fable 5를 사용하고, 구성 배수 조건은 한 모델만 사용함
  - 하네스 프롬프트는 자주 바뀌므로 개별 수치보다 API 경계 측정 방법이 더 오래 유지됨
- 로컬 게이트웨이가 측정 경로에 있었음
  - 구성요소 수치는 게이트웨이가 바꿀 수 없는 요청 본문을 사용함
  - 계측값은 콜드 캐시 기준점으로 고정 봉투를 보정했으며, 원인을 구분할 수 없는 웜 실행 수치는 제외함
  - 게이트웨이가 고정한 모델보다 새로운 스냅샷으로 조용히 교체한 사례가 있어 실제 응답 모델도 경계에서 확인해야 함
  - Fable 경로에서는 오래된 서버 세션 재개와 호스트 측 도구 실행이 발생해 Claude Code의 Fable 다단계 결과를 제외함
- T3의 비용 수렴은 한 가지 작업 형태에서 나온 한 번의 관측임
  - 순차 실행이 필수인 작업에서는 Claude Code 요청 횟수와 전체 사용량이 다시 증가할 수 있음
  - OpenCode의 도구 제거 및 하위 에이전트 조건은 게이트웨이에서 잘못된 스트림을 반환해 캡처 페이로드 크기만 사용함
  - 실제 구성 수치는 한 사용자의 설정이며 다른 환경에서는 달라질 수 있음
- 재현 장치는 약 **200줄의 Node 코드**로 구성된 HTTP 프록시임
  - 모델 엔드포인트로 요청을 전달하면서 요청 본문과 응답 사용량 블록을 디스크와 감사 체인에 기록함
  - `ANTHROPIC_BASE_URL`을 프록시로 지정하고 새 설정 디렉터리와 빈 작업 공간에서 기본값을 측정한 뒤 명령 파일, MCP 서버, 워크플로를 하나씩 추가함
  - 게이트웨이를 사용한다면 먼저 최소 요청으로 자체 봉투를 측정하고 실제로 어떤 모델이 응답하는지 확인해야 함
  - 프로덕션 에이전트가 특정 시점에 모델로 보낸 정확한 내용을 재구성할 수 있도록 API 경계 로깅을 갖추면 토큰 회계도 함께 확보할 수 있음

## Comments



### Comment 61693

- Author: neo
- Created: 2026-07-13T09:55:25+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48883275) 
- 토큰을 정말 많이 태우는 건 **하위 에이전트**임. Claude Code에 큰 작업을 맡겼더니 곧바로 하위 에이전트 7개를 띄웠고, 하나도 끝나기 전에 예산을 소진함. 5시간 뒤 다시 시도해도 같았음  
  주 에이전트가 같은 작업을 순차적으로 수행하게 하면 전혀 문제없었음. 통신과 조율 비용 때문에 이렇게 비효율적인 건지, 아니면 하위 에이전트 사용자가 대개 대기업 계정으로 토큰당 비용을 내므로 Anthropic이 매출을 늘리려는 건지는 모르겠음
  - 반대로 복잡한 프로젝트의 탐색·계획 단계에서는 Fable의 **호기심 많은 동작**이 정확히 필요할 수 있음. 조율 에이전트가 프롬프트를 여러 탐색 관점으로 나누는 데 그치지 않고, 각 하위 에이전트가 해당 관점으로 코드베이스를 조사하며 새 단서를 재귀적으로 확장하게 하려면 모든 단계에서 Fable을 쓰는 게 합리적임  
    반면 잘 계획된 작업을 여러 대상에 병렬 적용하려는 것이라면, 하위 에이전트가 호기심이 덜한 모델로 **단계를 낮추도록** 명시해야 함. 결과물의 일관성도 더 좋아질 수 있음
  - 하위 에이전트마다 작업에 필요한 맥락을 얻으려고 코드베이스 일부를 다시 읽어야 함. 작업이 길어지면 조율 에이전트의 맥락도 캐시에서 사라져, 하위 에이전트가 끝난 뒤 다시 전체 비용을 내게 됨  
    순차 실행하면 파일을 대략 한 번씩만 읽고 모든 요청이 동일한 **접두사 캐시**를 활용함
  - 고객이 문제를 우회하려고 더 비싼 요금제를 택하게 된다면, 회사에는 그 문제를 고칠 **부정적 유인**이 생김. 해결책을 가진 엔지니어가 몇 명 있더라도 다수의 무관심, 일부의 방해, 때로는 관리 계층 어딘가의 적극적인 적대에 부딪힐 수 있음  
    이런 환경에서는 최상위 요금제에 새 기능을 먼저 넣고 비용을 회수한 뒤 하위 요금제로 내리거나, 경쟁사가 따라오기 어렵게 **사다리를 걷어차는 전략**이 최선일 수 있음
  - 하위 에이전트마다 약 **3만 토큰짜리 시스템 프롬프트**를 동일하게 전송함. Fable/Opus를 쓰면 7개가 작업을 시작하기도 전에 5시간 사용 한도의 30%를 쉽게 소비함
  - 이 요령을 익힌 뒤 Fable 하위 에이전트를 명시적으로 금지하고 있음. 어제 대규모 리팩터링 뒤 복잡한 코드를 검토하려고 먼저 검토 계획을 요청했더니, 첫 단계에서 Fable 에이전트 8개와 결과 검증용 1개를 제안해 승인함  
    그런데 검증 단계에서 **Fable 검증 에이전트 41개**를 띄우려 했음. 어떻게든 우회로를 찾아냄

- Claude Code가 토큰을 많이 쓰는 건 Anthropic이 더 많은 돈을 벌고 사용자를 구독제로 몰아넣기 위해서라고 봄. 구독 권한을 다른 코딩 에이전트에서 쓰지 못하게 하는 정책도 이를 뒷받침함. 나는 pi를 사용함
  - Anthropic을 **토큰 판매업자**로 보고 나니 여러 결정이 이해되기 시작함. 사용자가 반발하거나 안전장치를 요구하지 않는 한, 자사 경로로 더 많은 토큰을 쓰게 할 이유를 계속 만들어냄
  - 기업공개 관련 서류에 따르면 구독 매출은 약 5%로 매우 작다고 본 적이 있음. 다만 5%는 개인용 Claude 구독이고, Claude Code 구독 대부분은 기업 부문에 포함됐을 가능성이 큼  
    **API·엔터프라이즈는 전체 매출의 75~85%**, 기업 구독은 약 10~15%, 개인 구독은 약 5%임
  - 오히려 반대 논리임. 구독자는 고정 월정액을 내므로 Anthropic에는 Claude Code가 **토큰을 적게 쓰게 할 유인**이 있음
  - 반면 이런 동작은 정액 요금에 포함된 일반 구독자의 토큰 소비도 늘림. 악의라기보다 **무능에 가까워 보임**

- PUSH_AX의 타당한 비유처럼, 이는 시공업체 A가 3만3천 달러를 요구하고 B가 7천 달러를 요구한 상황과 같아서 우리가 올바른 대상을 측정하고 있는지 따져봐야 함  
  이에 따라 글에 **더 심층적인 작업**, 정성적 결과 비교, 가능한 한 빠른 입력·출력 재현 자료를 추가할 예정임
  - 3만3천 토큰 중 상당 부분이 최근 대화 같은 **맥락 데이터**인지 궁금함

- 큰 시스템 프롬프트만의 문제가 아님. 코딩 에이전트 실행 환경도 사소한 요청에조차 도구를 더 공격적으로 사용하고 있음. 테스트에서는 “Hey”나 “commit” 같은 프롬프트가 때때로 **30회가 넘는 도구 호출**을 일으켰음  
  [https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...](<https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-agent/>)  
  간단한 작업이 소비하는 토큰 수가 계속 늘어나는 **토큰 인플레이션**은 실제로 보임
  - Opus가 주석의 오타 하나를 고친 뒤 테스트와 린트 등 실행할 수 있는 모든 것을 돌리면 짜증남. 모든 테스트가 원래 통과했는지 선제적으로 확인하려고 현재 변경 사항부터 임시 보관하기도 함  
    규칙에 모든 변경을 테스트로 검증하라고 써둔 내 책임도 있지만, AI의 I를 그렇게 강조한다면 과일 샐러드에 토마토를 넣지 않을 정도의 판단력은 기대하게 됨
  - “Hey”나 “commit”처럼 모호한 프롬프트를 받으면 원하는 작업을 추론하려고 과거 대화와 다른 맥락을 뒤지느라 도구 호출이 늘어남. **더 명확한 프롬프트**가 나음
  - 커밋 정도는 LLM에 맡기지 않고 직접 할 수 있지 않나?

- Claude를 6개월 사용한 뒤 최근 Codex로 전환함. Codex가 더 개방적이고 모델의 작업 과정을 따라가기 쉬우며, 승인 흐름의 사용자 경험도 더 좋음. 전반적으로 **투명성이 높고**, 전환 비용은 거의 0이었음  
  Claude가 2월 무렵부터 시스템 프롬프트를 포함해 더 불투명해진 건 마음에 들지 않으며, **3만3천 토큰**은 지나치게 많아 보임
  - 지금은 둘 다 쓰는데 사실상 서로 바꿔 써도 될 정도임. Codex가 오픈 소스이고 OpenAI가 구독 권한을 다른 에이전트에서 써도 된다고 명시한 점도 좋음  
    최근 OpenAI가 훨씬 **소비자 친화적**으로 바뀜
  - 더 불투명해진 뒤 어떤 설정들을 시도했는지 궁금함. 지금은 설정 항목이 훨씬 많아짐

- pi 에이전트는 시스템 프롬프트가 더 작으며, 전체 내용은 여기서 볼 수 있음  
  [https://github.com/earendil-works/pi/blob/main/packages%2Fco...](<https://github.com/earendil-works/pi/blob/main/packages%2Fcoding-agent%2Fsrc%2Fcore%2Fsystem-prompt.ts>)
  - 이런 **미니멀리즘**과 관련이 있을 수 있지만, Pi에는 LLM이 효율적이고 효과적으로 작동하는 데 필요한 도구가 대부분 빠져 있음. 빈 바탕에 원하는 것을 추가하는 철학은 이해하지만, 내 기준에는 지나치게 비어 있음
  - 시스템 프롬프트를 호출할 때마다 날짜와 `cmd`를 설정하면 **캐시가 무효화**되는지 궁금함  
    날짜나 루트 디렉터리가 바뀔 때만 무효화된다면 실제로는 충분히 드문 일이긴 함
  - 대폭 맞춤화할 최소 에이전트가 필요하다면, “최소” pi-coder 패키지에 **전이 의존성 130개 이상**을 끌어오기보다 직접 만드는 편이 나음. 어렵지 않고 많이 배울 수 있으며, 시작 단계는 다른 LLM에 도움을 요청해도 됨

- 결국 중요한 건 원시 프롬프트 크기가 아님. 그렇다면 Pi와 그 변형들이 비용이 가장 낮아야 함. 핵심은 **프롬프트의 효율성**이며, 프롬프트 미니멀리즘과 효율성은 자주 혼동됨. 그래도 Claude Code는 하는 일에 비해 비대해 보임  
  그보다 더 중요한 건 도구의 품질임. 나쁘거나 버그가 있는 도구는 왕복 호출을 크게 늘려, 초기에 아끼려던 이점을 모두 지워버림  
  몇 달 전 8개 작업에서 에이전트 7개를 전체 벤치마크했으며, [https://github.com/dirac-run/dirac](<https://github.com/dirac-run/dirac>)에 데이터와 추적 기록이 있음. 그중 하나와 직접 연관돼 있어 중립성을 주장할 수는 없지만 재현 가능한 자료임. 작업 대부분이 리팩터링과 관련돼 있어 **해시 앵커링과 추상 구문 트리 분석**이 강점을 보이는 Dirac이 큰 차이로 이김
  - 경쟁자가 많고 경쟁이 매우 치열하므로 개선 여지가 있다면 누군가 실현할 것이고, 이후 다른 제품에도 **빠르게 확산될 가능성**이 큼

- 직장에서 Claude Code를 강제로 써야 하지만 `--system-prompt ""`를 사용하면 간단히 해결됨. 다른 실행 환경도 허용해 주면 좋겠음
  - `--system-prompt ""`로 비우면 모델이 사용 가능한 도구를 이해할 **기본 시스템 프롬프트**조차 없어지는 것 아닌가?
  - 오래전부터 이렇게 사용해 왔는데 왜 모두가 쓰지 않는지 모르겠음
  - 이 옵션을 몰랐음. 적용 전후의 실제 효율을 분석한 자료나 **현실 사용 환경의 성능 차트**가 있다면 보고 싶음
  - 이 옵션으로 Claude를 시작하는 건지, 아니면 프롬프트를 보낼 때마다 함께 전달하는 건지 궁금함

- 로컬 모델을 처음 실험할 때 Claude Code에 연결하니 매우 잘 작동했지만 속도가 느렸음  
  Claude의 도움을 받아 mitmproxy를 설정하고 Claude Code의 최초 시스템 프롬프트 전체를 캡처했더니, 재확인 결과 **JSON 162KB**였음. 이를 계기로 Pi, OpenCode, Hermes를 실험하기 시작함
  - 지금 Claude Code의 새 세션에서 `/context`를 실행하면 Opus 4.8의 100만 토큰 맥락 중 2만3천 토큰만 사용함. 시스템 프롬프트 3.9천, 시스템 도구 13.9천, 사용자 정의 에이전트 235, 메모리 파일 28, 기능 4.9천, 메시지 8, 압축 버퍼 3천 토큰으로 표시됨  
    **시스템 프롬프트 4천 토큰**은 약 15~20KB임. 캡처한 내용을 Gist에 올려달라고 하고 싶지만 민감한 데이터가 있을 수 있고, 보이는 162KB가 시스템 프롬프트만은 아닐 가능성이 큼

- 내가 만든 것은 더 적게 전송함: [https://maki.sh](<https://maki.sh>)
  - 맥락이 너무 길어지면 maki가 이미지와 추론 블록을 제거하고 이전 대화를 요약해 기록을 자동 압축한다고 함  
    하지만 이전 대화 요약은 사실상 **맥락 캐시를 무효화**해, 토큰은 덜 쓰더라도 더 비싼 토큰을 소비하게 되는 것 아닌가?