Systima가 Claude Code와 OpenCode를 같은 모델·같은 기계·같은 작업에 올려놓고, 두 하네스와 Claude 엔드포인트 사이에 로깅 프록시를 끼웠습니다. 오가는 JSON 페이로드와 API가 돌려준 usage 블록을 통째로 캡처했는데요. 추정이 아니라 “하네스가 실제로 뭘 보냈나”의 원본 기록입니다.
- “OK라고만 답하라”는 22글자 작업에서, Claude Code는 프롬프트가 도착하기도 전에 약 32,800 토큰을 얹었다. OpenCode는 약 6,900. Sonnet 4.5 기준 4.7배
- 그 33k 중 약 24k가 도구 스키마 27개. OpenCode는 도구 10개에 4.8k뿐이다
- 여기에 곱셈이 붙는다 — 72KB 지시 파일은 요청당 +20k, MCP 서버 5개 +5~7k, 서브에이전트 2개 병렬은 121k → 513k로 4.2배
- 그런데 다단계 작업의 총량은 되레 Claude Code가 낮게 나왔다. 도구 호출을 한 번에 묶어 요청 수를 줄이기 때문
OK 한 마디에 32,800 토큰
22글자짜리 작업에 두 하네스가 첫 요청으로 딸려 보낸 짐은 이렇게 갈렸습니다.
| 구성 요소 | Claude Code | OpenCode |
|---|---|---|
| 시스템 프롬프트 | 27,344자, 3블록 | 9,324자, 1블록 |
| 도구 스키마 | 27개, 99,778자 | 10개, 20,856자 |
| 첫 메시지 스캐폴딩 | <system-reminder> 7,997자 | 없음 |
| 실제 프롬프트 | 22자 | 22자 |
| 첫 턴 페이로드(보정치) | 약 32,800 토큰 | 약 6,900 토큰 |
OpenCode의 요청은 거의 최소한입니다. “You are OpenCode, the best coding agent on the planet”로 시작하는 시스템 블록 하나, 고전적인 코딩 도구 열 개, 그리고 사용자 프롬프트. 반면 Claude Code의 요청은 플랫폼 부트스트랩에 가깝습니다. 27개 도구에는 코딩 코어뿐 아니라 CronCreate·Monitor부터 Task 계열, 워크트리 관리, 푸시 알림까지 백그라운드 에이전트·오케스트레이션 한 벌이 통째로 들어 있어요.
지배적인 항목은 양쪽 다 도구 스키마입니다. Claude Code의 약 33k 중 대략 24k가 도구 정의고, OpenCode는 약 6,900 중 4,800이 그렇습니다. 도구를 아예 떼어내면 순수 시스템 프롬프트만 남는데요. 그 상태에서도 Claude Code(26,891자, 약 6.5k)가 OpenCode(8,811자, 약 2.0k)의 세 배가 넘습니다. 나머지는 톤 규칙·안전 지침·작업 관리 지시 같은 행동 강령이고요.
한 가지, 이 격차는 모델에 따라 달라집니다. Claude Code의 시스템 프롬프트는 모델 조건부라 Sonnet엔 27,787자를 보내지만 Fable엔 10,526자만 보내죠. 같은 27개 도구인데 강령을 줄였습니다. 그래서 Fable 5에서 격차는 4.7배에서 3.3배로 좁혀지고요. OpenCode의 페이로드는 두 모델에서 바이트 단위로 동일했습니다.
기본값 위에 곱해지는 것들
낮게 시작해 짧게 끝나는 세션이라면 위 숫자가 전부입니다. 실제 세션은 둘 다 아니죠. Systima는 실사용이 얹는 층을 하나씩 쌓아 재봤습니다.
지시 파일부터가 큽니다. 프로덕션 저장소의 72KB AGENTS.md를 워크스페이스에 떨궜더니 두 하네스 모두 요청당 2만 토큰씩 불었어요. 대칭적이라는 게 함정인데요. 무거운 지시 파일은 그 저장소의 모든 세션, 모든 요청에 올라타죠. 게다가 Claude Code 2.1.207은 AGENTS.md를 통째로 무시하고 CLAUDE.md로 이름을 바꿔야만 읽었습니다. 무시된 지시 파일은 조용히 아무 일도 안 합니다.
| 항목 | 요청당 영향 |
|---|---|
| 72KB 지시 파일 | +약 20,000 토큰(양쪽 다) |
| MCP 서버(작은 것) | 서버당 1,000~1,400 토큰 |
| 프레임워크 템플릿(BMAD 등) | 세션 히스토리에 눌러앉아 매 요청 재전송 |
| 서브에이전트 2개 병렬 | 121,000 → 513,000, 4.2배 |
서브에이전트는 총량이 가장 빠르게 치솟는 지점입니다. Claude Code는 메인 세션의 33k 부트스트랩에, 서브에이전트마다 3,554자 시스템 프롬프트 + 27개 중 24개 도구를 따로 짊어집니다. 부모는 그 서브에이전트의 대화록을 다시 삼키고요. 원문의 표현이 정확합니다.
“위임은 강력하고 때로는 옳다. 동시에 우리가 측정한 것 중 가장 큰 토큰 배수이기도 하다.” (“Delegation is powerful and sometimes correct; it is also the single largest token multiplier we measured.”)
실사용 구성 전부를 얹은 “everything” 측정에선, OpenCode가 MCP 서버 11개 + 72KB 지시 파일로 첫 요청에 콜드 캐시 9만 토큰(도구 179개, 스키마 277KB)을, Claude Code가 MCP 4개 + 플러그인으로 약 75,000 토큰(도구 118개)을 사용자가 한 글자 치기도 전에 썼습니다. OpenCode의 7k 바닥 대비 약 12배죠. 하네스가 바닥을 정하고, 그 위는 설정이 정합니다.
진짜 승부는 캐시 프리픽스에서 갈린다
프롬프트 캐싱이 단위를 바꾸긴 해도 결론은 안 바꿉니다. 캐싱이 이득이 되려면 프리픽스가 안 변해야 하는데요. 여기서 두 하네스가 완전히 갈렸습니다.
OpenCode는 모든 요청, 모든 실행에서 프리픽스가 바이트 단위로 동일했습니다. 세 번의 T1 세션이 같은 도구 바이트, 같은 시스템 바이트, 같은 메시지 바이트를 냈고, 반복 실행은 캐시 쓰기 0으로 전부 읽기만 했고요. 9요청짜리 T3 세션도 프리픽스 하나를 끝까지 유지했습니다.
Claude Code는 세션마다 프리픽스가 다른 세 종류의 요청(워밍업 프로브·메인 대화·서브에이전트 호출)을 냈습니다. 시스템 바이트가 같은 워크스페이스의 세션 간에도 흔들렸고, 첫 메시지 스캐폴딩은 실행마다 달라졌어요. 결과는 캐시 쓰기 열에 그대로 찍혔습니다. 같은 파일 요약 작업에서 Claude Code는 5요청에 걸쳐 53,839 캐시 토큰을 썼는데, 여기엔 43k 프리픽스 전체를 작업 도중 한 번 통째로 재작성한 게 포함돼 있고요. OpenCode는 1,003이었습니다. 54배예요.
한 번의 우연이 아닌지 다시 돌려봤더니 재현됐습니다(1회차 43,342, 2회차 36,899, 갓 데운 캐시로 돌린 3회차는 거의 0). Fable 5에서도 거의 똑같이 5만 토큰짜리 중간 재작성이 나와 52배였고요. 두 모델 계열, 같은 패턴입니다.
캐시로 절대 못 지우는 비용도 있고요. 원문 표현으로, 85k 부트스트랩은 200k 윈도의 40퍼센트 넘게 차지해 실제 코드가 들어갈 자리를 줄이고, 그러면 곧 compaction이 돌아 요약에 또 토큰을 씁니다. 사용량 미터기가 Claude Code에선 치솟고 OpenCode에선 평평하게 유지되는 걸 본 적이 있다면, 이게 가장 유력한 메커니즘입니다. 더 큰 프리픽스, 세션당 더 많은 프리픽스, 그리고 그것들의 더 잦은 재작성.
Claude Code가 유일하게 이긴 한 판
바닥 숫자가 세운 예상을 뒤집은 게 다단계 작업(T3, write-run-test-fix 루프)입니다.
| 지표 | Claude Code | OpenCode |
|---|---|---|
| 모델 요청 수 | 3 | 9 (+제목용 1) |
| 도구 호출 방식 | 한 번에 병렬 배치 | 턴당 도구 1개 |
| 누적 계측 입력 | 약 121,000 토큰 | 약 132,000 토큰 |
Claude Code는 파일 쓰기 둘 + 스크립트 실행 둘을 한 번의 병렬 라운드트립에 몰아넣었고, OpenCode는 턴마다 도구를 딱 하나씩 호출해 아홉 번을 갔습니다. 바닥이 매 요청 재전송되니 요청 수가 곧 바닥의 배수죠. OpenCode는 7k 바닥을 아홉 번, Claude Code는 33k 바닥을 세 번 냈고, 총량이 수렴했습니다.
“미터기는 더 높은 데서 출발한다. 그다음 세션이 어떻게 굴러가느냐가 누가 더 쓰는지를 정한다.” (“The meter starts higher; how the session unfolds decides who spends more.”)
물론 이건 한 작업 형태의 한 관측입니다. 엄격히 순차적인 작업이라면 Claude Code의 요청 수, 따라서 총량은 다시 올라갑니다.
품질로는 설명 안 되는 낭비
당연한 반론이 하나 있습니다. 청구서는 결과물의 질을 말해주지 않죠. 더 내는 게 더 나은 산출을 산다면 합리적이니까요. 그래서 Systima는 품질이 변수가 될 수 없게 작업을 골랐습니다. 두 하네스는 채점된 작업을 전부 정확히 끝냈고, 다단계 작업은 각자 짜서 통과시킨 검증 스크립트로 확인됐으며, 파일 요약도 둘 다 맞았습니다. 같은 결과에 붙는 비용 차이라, 그래서 측정이 가능한 거고요. 그 프리미엄이 진짜 엔지니어링에서 품질을 사는지는 Systima가 재지 않았고, Claude Code의 백그라운드 에이전트·스킬·오케스트레이션이 더 어려운 작업에선 토큰값을 할지도 모른다고 열어뒀습니다.
품질로 변명이 안 되는 대목도 남습니다. 낭비는 둘이에요. 바이트 단위로 똑같은 캐시 프리픽스를 세션 도중 다시 쓰는 건 코드 품질을 조금도 못 삽니다. 같은 내용을 프리미엄 요금으로 또 결제하는 거죠. 하네스가 조용히 무시하는 지시 파일도 아무것도 사지 않고요. 더 큰 플랫폼을 옹호하는 어떤 논리를 들이대도, 이 둘은 어느 정의로 봐도 낭비입니다.
그러니 폴더가 아니라 페이로드를 봐야 합니다. 프로덕션에서 에이전트를 굴리면서 “지난 화요일에 모델로 정확히 뭘 보냈나”에 데이터로 답할 수 없다면, 원문 말대로 그게 먼저 메워야 할 구멍입니다. 토큰 회계는 그다음에 저절로 떨어지고요.
Loading comments...