---
title: "클로드 코드, 프롬프트 읽기도 전에 3.3만 토큰을 쓴다는 벤치마크"
published: 2026-07-12T18:25:51.000Z
canonical: https://jeff.news/article/4991
---
# 클로드 코드, 프롬프트 읽기도 전에 3.3만 토큰을 쓴다는 벤치마크

Systima가 Claude Code와 OpenCode를 같은 모델, 같은 머신, 같은 작업에 물려 API 경계에서 실제 요청/응답을 캡처한 토큰 사용량 비교를 공개했음. Claude Code는 기본 프롬프트와 도구 스키마가 훨씬 크고 캐시 재작성도 잦았지만, 멀티스텝 작업에서는 도구 호출을 묶어 요청 수를 줄이면서 격차가 좁아지는 결과도 나왔음.

- Claude Code와 OpenCode를 같은 모델, 같은 머신, 같은 작업에 놓고 보니 시작선부터 꽤 달랐음
  - 사용자가 `OK` 한 줄만 요청해도 Claude Code는 프롬프트가 도착하기 전 약 3.3만 토큰을 먼저 보냈음
  - OpenCode는 같은 조건에서 약 7천 토큰 수준이었고, Claude Code 쪽이 대략 4.7배 큰 출발선을 가진 셈임
  - Claude Fable 5로 다시 돌리면 격차는 약 3.3배로 줄었는데, Claude Code가 모델에 따라 시스템 프롬프트를 다르게 보내기 때문이라고 함

- 가장 큰 덩어리는 도구 스키마였음
  - Claude Code의 약 3.3만 토큰 중 약 2.4만 토큰이 도구 정의였음
  - OpenCode는 약 6,900토큰 중 약 4,800토큰이 도구 정의였음
  - 도구를 꺼도 Claude Code의 시스템 프롬프트는 약 6.5천 토큰, OpenCode는 약 2천 토큰이라 기본 지침 자체도 3배 이상 차이남

> [!IMPORTANT]
> 이 벤치마크에서 말하는 비용은 단순 과금만이 아님. 3.3만 토큰 baseline은 20만 컨텍스트 창의 6분의 1을 코드 한 줄 읽기 전에 이미 먹고 시작한다는 뜻임.

- 파일 하나 읽고 요약하는 작업에서도 차이가 크게 벌어졌음
  - Claude Code는 HTTP 요청 6번에 누적 metered input 약 19.9만 토큰을 썼음
  - OpenCode는 요청 4번에 약 4.1만 토큰, 여기에 세션 제목용 Haiku 호출 하나가 붙었음
  - 대부분은 cache read라 싸게 과금되지만, 첫 cache write와 매 턴 context window 점유는 사라지지 않음

- 그런데 멀티스텝 작업에서는 결과가 단순하지 않았음
  - FizzBuzz를 작성하고, 테스트를 돌리고, 실패를 고치는 작업에서 Claude Code는 파일 쓰기 2번과 스크립트 실행 2번을 한 번의 병렬 도구 라운드로 묶었음
  - OpenCode는 턴마다 도구 호출 하나씩 처리해서 총 9턴이 걸렸음
  - 그래서 OpenCode는 작은 baseline을 9번 냈고, Claude Code는 큰 baseline을 3번 내면서 전체 토큰이 꽤 가까워졌음

- 실전 설정을 붙이면 baseline보다 설정이 더 무서워짐
  - 72KB짜리 AGENTS.md 또는 CLAUDE.md는 두 하네스 모두 요청당 약 2만 토큰을 추가했음
  - 작은 MCP 서버 5개는 대략 5천~7천 토큰을 더 붙였고, 도구 수는 Claude Code 27개에서 69개, OpenCode 10개에서 52개로 늘었음
  - 실제 작업 환경에서는 OpenCode가 MCP 서버 11개와 72KB 지침 파일을 붙인 첫 요청에서 90,817토큰을 기록했음
  - Claude Code는 MCP 서버 4개, 플러그인, 같은 지침 파일 조합에서 약 7.5만 토큰짜리 payload가 나왔음

- 캐시는 만능 할인 쿠폰이 아니었음
  - 5분 TTL 캐시는 처음 쓸 때 1.25배 프리미엄으로 write하고, 이후 read는 0.1배 가격으로 읽음
  - 하지만 5분 넘게 멈추면 다시 write가 발생하고, 요청 수가 많으면 read 비용도 계속 누적됨
  - 무엇보다 캐싱은 context window 점유를 줄여주지 않아서 8.5만 토큰 bootstrap은 매 요청마다 20만 창의 40% 이상을 차지함

- OpenCode는 cache prefix가 안정적이었고, Claude Code는 그렇지 않았음
  - OpenCode는 여러 실행에서 tools/system/message bytes가 byte-identical로 유지됐고, 반복 실행에서는 cache write가 거의 없었음
  - Claude Code는 warmup probe, main conversation, subagent call 같은 서로 다른 request class를 만들었고, 같은 workspace에서도 system bytes와 첫 메시지 scaffolding이 달라졌음
  - 동일 파일 요약 작업에서 Claude Code는 cache token을 53,839개 썼고, OpenCode는 1,003개만 썼음
  - 다른 실행에서도 Claude Code의 mid-session rewrite가 43,342토큰, 36,899토큰, Fable 5에서 50,053토큰으로 재현됐음

> [!WARNING]
> 사용량 대시보드가 Claude Code에서만 갑자기 튄다면 서브에이전트보다 먼저 cache write 컬럼을 봐야 함. 같은 prefix를 다시 쓰는 것처럼 보여도 실제 byte가 흔들리면 프리미엄 write를 다시 낼 수 있음.

- 서브에이전트는 가장 빠르게 비용을 키운 multiplier였음
  - Claude Code에서 직접 수행하면 12.1만 토큰이던 작은 작업이 서브에이전트 2개로 나누자 51.3만 토큰까지 올라갔음
  - 4.2배 증가인데, 각 서브에이전트가 자기 bootstrap을 들고 시작하고 그 transcript를 부모가 다시 먹기 때문임
  - OpenCode의 서브에이전트 payload는 더 작았지만 gateway 문제로 완료 수치는 공개하지 않았음

- 이 실험은 품질 벤치마크가 아니라 비용 구조 벤치마크임
  - 테스트 작업에서는 두 하네스 모두 정답을 냈고, 파일 요약도 정확했음
  - 어려운 실제 엔지니어링 작업에서 Claude Code의 큰 오케스트레이션 표면이 품질로 보상되는지는 별도 실험이 필요하다고 선을 그었음
  - 그래도 byte-identical cache prefix를 중간에 다시 쓰거나, 지침 파일을 조용히 무시하는 건 품질과 무관한 낭비라고 못 박음

- 결론은 꽤 실무적임. 에이전트 비용을 진짜 관리하려면 모델 이름보다 API 경계에서 payload와 usage를 로깅해야 함
  - 저자는 약 200줄짜리 Node HTTP proxy로 요청 body와 response usage를 캡처했다고 함
  - 총 185개 request/response record를 SHA-256 hash chain audit trail로 남겼고, chain integrity도 검증했다고 함
  - 운영 환경에서 “지난 화요일에 우리 에이전트가 모델에 정확히 뭘 보냈지?”에 답하지 못하면, 토큰 최적화 이전에 관측성부터 비어 있는 셈임

---
## 기술 맥락

- 이 글에서 중요한 선택은 “에이전트 내부 로그”가 아니라 “모델 API 경계”를 본 거예요. 하네스가 알아서 최적화했겠지 하고 믿으면 시스템 프롬프트, 도구 스키마, cache write가 어디서 새는지 알기 어렵거든요.

- Prompt caching은 prefix가 안정적일 때만 제대로 돈값을 해요. OpenCode처럼 같은 bytes를 반복해서 보내면 한 번 쓰고 싸게 읽을 수 있지만, Claude Code처럼 request class나 scaffolding이 흔들리면 같은 일을 하면서도 비싼 write를 다시 내게 돼요.

- MCP 서버와 지침 파일은 기능을 늘리는 대신 매 요청의 고정비를 키워요. 특히 72KB 지침 파일이 요청당 약 2만 토큰을 추가했다는 건, “문서 좀 길게 써도 되겠지”가 에이전트 환경에서는 매 턴 과금과 컨텍스트 압박으로 돌아온다는 뜻이에요.

- 서브에이전트는 병렬화 도구지만 비용 모델은 별도 프로세스에 가까워요. 각 에이전트가 자기 도구와 지침을 들고 부팅하고, 부모가 결과 transcript까지 다시 읽기 때문에 작은 작업에서는 오히려 토큰을 태우는 구조가 되기 쉬워요.

## 핵심 포인트

- Claude Code는 단순히 'OK'만 답하는 작업에서도 사용자 프롬프트 전 약 3.3만 토큰을 보냈고 OpenCode는 약 7천 토큰 수준이었음
- 72KB짜리 AGENTS.md 또는 CLAUDE.md는 두 하네스 모두에 요청당 약 2만 토큰을 추가했음
- Claude Code는 동일 작업에서 OpenCode보다 최대 54배 많은 프롬프트 캐시 쓰기 토큰을 기록했음
- 서브에이전트 팬아웃은 작은 작업의 입력 토큰을 12.1만에서 51.3만으로 키워 4.2배 비용을 만들었음

## 인사이트

이 글의 핵심은 '어떤 코딩 에이전트가 똑똑하냐'보다 '내 에이전트가 모델에 뭘 얼마나 보내는지 알고 있냐'에 가까움. 팀에서 MCP, 긴 지침 파일, 서브에이전트를 붙여 쓰고 있다면 체감 비용 폭증의 원인이 모델이 아니라 하네스 구조일 수 있음.