Claude Code는 프롬프트 읽기 전에 33k 토큰을 전송한다; OpenCode는 7k
Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
TL;DR Highlight
동일한 모델과 작업 환경에서 Claude Code와 OpenCode의 실제 토큰 사용량을 API 레벨에서 측정한 결과, Claude Code가 시스템 프롬프트 오버헤드만으로 OpenCode 대비 4.7배 더 많은 토큰을 소비한다는 것을 확인했다.
Who Should Read
Claude Code나 OpenCode 같은 AI 코딩 에이전트를 업무에 활용 중인 개발자 중 토큰 비용이 예상보다 빠르게 소진되는 이유를 파악하고 싶은 사람. 특히 프로덕션 환경에서 agentic AI를 운영하며 비용을 최적화해야 하는 백엔드/플랫폼 엔지니어.
Core Mechanics
- Claude Code는 사용자 프롬프트가 도달하기도 전에 시스템 프롬프트, 툴 스키마, 스캐폴딩 코드로만 약 33,000 토큰을 소비한다. OpenCode는 같은 조건에서 약 7,000 토큰을 사용해 약 4.7배 차이가 난다.
- 이 측정은 Sonnet 4.5 기준이며, Claude Fable 5(최신 모델)에서 다시 측정했을 때 Claude Code가 더 작은 시스템 프롬프트를 전송해 격차가 약 3.3배로 줄었다. 즉 모델마다 오버헤드 비율이 다르다.
- 캐시 효율성에서도 큰 차이가 있다. OpenCode는 매 요청의 prefix(앞부분)가 바이트 단위로 동일해서 세션당 한 번만 캐시 비용을 내고 이후엔 저렴하게 읽어온다. 반면 Claude Code는 세션 중간에 수만 토큰 규모의 프롬프트 캐시를 재작성하며, 같은 작업에서 OpenCode 대비 최대 54배 더 많은 캐시 쓰기(cache write) 비용을 발생시켰다.
- 프로덕션 환경에서는 오버헤드가 더 크게 불어난다. 72KB짜리 AGENTS.md 또는 CLAUDE.md 파일이 있으면 모든 요청에 평균 20,000 토큰이 추가되고, MCP 서버 5개를 연결하면 5,000~7,000 토큰이 더 붙는다. 실제 작업 환경에서 첫 번째 요청을 보내기도 전에 이미 75,000~85,000 토큰이 소비된다.
- 서브에이전트(subagent)를 사용하면 비용이 폭발적으로 늘어난다. 직접 처리하면 121,000 토큰이면 되는 작업을 두 개의 서브에이전트로 분산시켰더니 513,000 토큰이 소요됐다. 각 서브에이전트마다 자체 부트스트랩 비용이 있고, 부모 에이전트가 전체 트랜스크립트를 다시 소비하기 때문이다.
- Claude Code가 유리한 경우도 있다. 여러 단계로 구성된 멀티스텝 작업에서는 Claude Code가 툴 호출을 하나의 요청에 묶어서 처리(batch)하기 때문에, 매 턴마다 기본 오버헤드를 다시 내는 OpenCode보다 전체 작업 토큰 합계가 낮게 나왔다. 즉 '미터기가 높게 시작하지만 세션이 어떻게 전개되느냐'가 최종 비용을 결정한다.
- 측정 방법은 harness와 모델 엔드포인트 사이에 로깅 프록시를 삽입하는 방식이다. 프록시가 각 요청의 정확한 JSON 페이로드(시스템 블록, 툴 스키마, 메시지)와 API가 반환하는 usage 블록(input tokens, cache writes, cache reads, output tokens)을 기록해 ground truth를 확보했다.
Evidence
- 서브에이전트 비효율성을 직접 경험한 사례가 있었다. 큰 작업을 주었더니 Claude Code가 즉시 7개의 서브에이전트를 실행해 하나도 완료되기 전에 예산을 소진했다는 댓글이 있었다. 같은 작업을 메인 에이전트가 순차적으로 처리했을 때는 문제없이 완료됐다고 한다.
- 캐시 적중(cache hit)을 고려하면 33k 토큰이 생각만큼 나쁘지 않을 수도 있다는 반론이 있었다. 첫 번째 요청 이후에는 캐시 히트가 발생하면 일반 토큰 가격의 1/10로 과금되므로, 큰 시스템 프롬프트가 자율성을 높여 연속 캐시 히트를 유도한다면 빠르게 손익분기점을 넘을 수 있다는 주장이다.
- '토큰 수가 많다'는 것 자체가 문제인지에 대한 메타 논쟁이 있었다. 한 댓글에서 "계약자 A가 $33,000을 요구하고 B가 $7,000을 요구했다면, 우리는 올바른 것을 측정하고 있는 건가?"라는 질문을 제기했다. 원문 작성자는 이 지적을 수용해 더 심층적인 작업 비교와 정성적 결과 비교를 추가하겠다고 업데이트를 예고했다.
- 단순 요청에도 툴 호출이 폭발적으로 늘어나는 '토큰 인플레이션' 현상이 실제로 관찰됐다는 의견이 있었다. "Hey"나 "commit" 같은 짧은 프롬프트가 30개 이상의 툴 호출을 트리거하는 경우도 있었으며, 이 현상이 Claude Code만의 문제가 아니라 코딩 에이전트 전반의 추세라는 지적이 있었다.
- Claude Code 대신 Codex, Pi, OpenCode, Cline 등으로 전환한 개발자들의 경험담이 다수 공유됐다. Pi 에이전트의 경우 시스템 프롬프트가 1k 토큰 이하로 오픈소스로 공개되어 있고, $20 구독으로 GPT 5.6을 사용 시 Pi를 쓰면 몇 시간씩 사용 가능하다는 구체적인 비교가 있었다. 반면 Claude Code가 병렬 작업/서브에이전트 오케스트레이션에서는 여전히 최고 수준이라는 반론도 있었다.
How to Apply
- Claude Code의 시스템 프롬프트 오버헤드를 줄이고 싶다면 CLI 옵션 `--system-prompt ""`를 사용해 기본 시스템 프롬프트를 비워서 실행할 수 있다. 댓글에서 이 방법을 실제로 사용 중이라는 사례가 있었으나, 에이전트의 일부 기능이 제한될 수 있다는 점은 감안해야 한다.
- 프로덕션 환경에서 AI 코딩 에이전트 비용을 모니터링하려면, harness와 모델 API 엔드포인트 사이에 로깅 프록시(mitmproxy 등)를 삽입해 실제로 전송되는 JSON 페이로드와 usage 블록을 캡처하라. 대시보드의 숫자가 아닌 API 레벨 ground truth로 토큰이 어디에 쓰이는지 확인할 수 있다.
- 서브에이전트 사용 시 비용이 예산을 초과한다면, 같은 작업을 메인 에이전트가 순차적으로 처리하는 방식으로 전환하는 것을 고려하라. 측정 결과 직접 처리 시 121k 토큰이던 작업이 서브에이전트 2개로 분산 시 513k 토큰으로 4배 이상 늘었기 때문에, 병렬화 이점이 명확한 작업에만 서브에이전트를 선택적으로 사용해야 한다.
- AGENTS.md 또는 CLAUDE.md 파일이 크다면(예: 72KB) 모든 요청에 20,000 토큰이 추가된다는 점을 인지하고, 실제로 에이전트가 매 턴 참조해야 하는 내용만 남기고 나머지는 별도 문서로 분리하라. MCP 서버도 실제로 사용하는 것만 연결하면 요청당 5,000~7,000 토큰을 절약할 수 있다.
Code Example
# harness와 모델 API 사이에 로깅 프록시를 삽입하는 구조
# harness (Claude Code / OpenCode) → logging proxy → model endpoint
# Claude Code 시스템 프롬프트 오버헤드를 제거하는 CLI 옵션
claude --system-prompt ""
# mitmproxy를 이용한 토큰 캡처 예시 (댓글에서 언급)
# mitmproxy를 설치하고 Claude Code의 API 트래픽을 인터셉트
mitmproxy --mode regular --listen-port 8080
# 환경변수로 프록시 설정
export HTTPS_PROXY=http://localhost:8080Terminology
관련 논문
Mesh LLM: iroh 기반 분산 AI 컴퓨팅
사무실, 집, 클라우드에 흩어진 GPU들을 하나의 OpenAI 호환 API로 묶어주는 분산 LLM 실행 시스템으로, 비싼 API 비용 없이 큰 모델을 직접 운영할 수 있다.
Frugon – LLM API 호출 로그를 분석해서 더 싼 모델로 대체 가능한 구간을 찾아주는 로컬 도구
내 LLM API 비용이 어디서 새는지 로컬에서 분석해주는 오픈소스 CLI 도구로, 비싼 모델 대신 저렴한 모델로 전환 가능한 호출을 골라낸다.
로컬에서 SOTA LLM 실행하기 완전 가이드 (하드웨어부터 설정까지)
2천 달러짜리 RTX 3090 한 장부터 4만 달러짜리 RTX PRO 6000 4장 셋업까지, 로컬에서 최신 LLM을 직접 돌리는 방법을 하드웨어 선택·구성·실행 설정까지 통째로 정리한 실전 가이드다.
Manticore Search에서 ONNX 경로를 재설계해 임베딩 속도를 14배 높인 방법
Manticore Search가 기존 SentenceTransformers/Candle 백엔드를 ONNX Runtime으로 교체해 텍스트 임베딩 생성 속도를 평균 14배 향상시켰다. 별도 모델 서비스 없이 DB 내부에서 직접 임베딩을 처리하는 구조에서 INSERT 속도가 곧 임베딩 속도이기 때문에 이 개선은 실질적인 ingest 처리량 향상으로 직결된다.
Asymmetric Quantization: 97% 스토리지 절감으로 Late Interaction 검색 품질 유지하기
멀티벡터 검색 모델의 문서 벡터를 1비트 이진값으로 압축하고 쿼리 벡터만 int8로 유지하는 비대칭 양자화 기법으로, 스토리지를 97% 줄이면서 검색 품질 손실을 0.61점(NDCG@10 기준)에 그치게 만든 실제 프로덕션 적용 사례다.
Bash4LLM+ – 의존성 없는 경량 Bash LLM API 래퍼
Python이나 Node.js 없이 순수 Bash만으로 Groq 등 OpenAI 호환 LLM API를 호출할 수 있는 단일 스크립트 도구로, Termux(Android)를 포함한 모든 Unix 환경에서 동작한다.