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

• 동일한 모델·머신·작업에서 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로 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 경계 로깅을 갖추면 토큰 회계도 함께 확보할 수 있음