클로드 코드, 프롬프트 읽기도 전에 3.3만 토큰을 쓴다는 벤치마크

• 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배 이상 차이남

• 파일 하나 읽고 요약하는 작업에서도 차이가 크게 벌어졌음

  • 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토큰으로 재현됐음

• 서브에이전트는 가장 빠르게 비용을 키운 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까지 다시 읽기 때문에 작은 작업에서는 오히려 토큰을 태우는 구조가 되기 쉬워요.