누군가가 두 코딩 에이전트와 모델 사이에 로깅 프록시(logging proxy)를 설치하고, 각각에게

그리고 그 도구들은 단순히 read_file의 열 가지 변형이 아닙니다. 소스에 따르면 Claude Code는 코딩 코어(coding core)와 더불어 오케스트레이션 스위트(orchestration suite) — 크론 잡(cron jobs), 모니터링, 서브에이전트(subagents)에게 위임하기 위한 Task 제품군, 워크트리(worktree) 관리, 푸시 알림 등을 함께 제공합니다. 이것은 단순한 코딩 어시스턴트가 아닙니다. 이것은 우연히 코드도 편집할 수 있는 플랫폼 부트스트랩(platform bootstrap)입니다. 주입된 리마인더 블록(reminder blocks)이 이를 확인해 줍니다. 즉, 위임할 에이전트 유형의 카탈로그, 기술(skills)의 카탈로그, 그리고 사용자 컨텍스트(user context)가 포함되어 있습니다. Claude Code는 런타임(runtime)을 로드하고 있는 것입니다. OpenCode는 입이 달린 에디터를 로드하고 있는 것이고요.

이것은 비교의 틀 자체를 재구성합니다. 27개의 도구가 10개보다 비용이 더 많이 드는지에 대해 혼란스러워하는 사람은 아무도 없습니다. 질문은 당신이 그 추가적인 17개를 _사용할 것인가_입니다.

명확하게 기술된 도박

하네스 페이로드(harness payload)의 모든 토큰은 실제 코드에 사용할 수 없는 토큰이며, 매 턴마다 함께 따라옵니다 — 매번 다시 전송되거나 캐시(cache)에서 다시 읽힙니다. 이것이 비용 측면이며, 이는 실재하는 문제입니다.

역량(capability) 측면은 내기입니다. 컨텍스트 내의 도구 스키마(tool schema)는 모델이 허용된 작업에 대해 가질 수 있는 전체 메뉴입니다. 모델에게 Task 도구와 서브에이전트 유형 디렉토리를 제공하면, 모델은 스스로 팬아웃(fan-out)을 계획할 수 있습니다. 제공하지 않으면 모델은 할 수 없습니다 — 인터페이스가 컨텍스트에 없는 역량은 아무리 영리한 프롬프팅(prompting)을 해도 불러낼 수 없습니다. 33k 토큰은 Claude Code가 거는 도박입니다. 즉, 자신이 위임(delegate), 모니터링, 워크트리 관리를 _할 수 있음_을 아는 모델이, 그러한 동작이 필요한 작업에서 더 나은 궤적(trajectories)을 생성할 것이라는 도박입니다.

소스는 이 도박이 때로는 보상을 주고, 때로는 예산을 태워버린다는 증거를 발견했습니다:

• 다단계 작업(multi-step task)에서 Claude Code의 전체 작업(whole-task) 총비용은 OpenCode보다 낮게 나타났습니다. Claude Code는 도구 호출(tool calls)을 더 적은 요청으로 배치(batch)합니다. 반면 OpenCode는 더 작은 베이스라인(baseline)을 매 턴마다 계속해서 다시 지불합니다. 계량기는 더 높게 시작하지만, 세션은 더 저렴하게 끝납니다.
• 동일한 작은 작업을 두 개의 서브에이전트에게 팬아웃(fan-out)하면, 직접 수행했을 때의 약 121,000 토큰에서 약 513,000 토큰으로 늘어났습니다 — 각 서브에이전트가 자체적인 부트스트랩 비용을 지불하고, 그 후 부모 에이전트가 그 기록(transcript) 비용을 부담하기 때문입니다.

동일한 성능입니다. 한 사례에서는 비용을 절감했고, 다른 사례에서는 비용이 4배로 뛰었습니다. 이것은 모순이 아닙니다. 이것이 바로 도박(bet)의 모습입니다.

실제로 이를 결정짓는 요소: 캐시 (cache)

헤드라인을 읽는 방식을 바꿔야 할 발견이 여기 있습니다. 최저 비용(floor number)은 정상 상태(steady-state) 비용에 대해 거의 아무것도 알려주지 않습니다. 왜냐하면 이 에이전트들은 서로 다르게 캐시(cache)를 사용하며, 한쪽이 훨씬 더 잘하기 때문입니다.

출처에 따르면, OpenCode는 모든 캡처된 실행에서 바이트 단위로 완전히 동일하게(byte-for-byte identical) 돌아오는 요청 접두사(request prefix)를 보냈습니다. 변하지 않는 접두사는 매 턴마다 프롬프트 캐시(prompt cache)가 적용됨을 의미합니다. 즉, 처음 한 번만 전체 비용을 지불하고, 그 이후에는 저렴하게 다시 읽어옵니다. Claude Code는 정반대였습니다. 세션 중간에 수만 개의 캐시된 토큰을 다시 작성(rewrite)했으며, 한 작업에서는 캐시 쓰기(cache-write) 볼륨이 OpenCode가 기록한 것보다 약 54배에 달했습니다. 캐시 쓰기는 읽기보다 더 높은 비용(premium)이 발생하며, 이것이 바로 사용량 대시보드의 수치가 계속 올라가는 정확한 이유입니다.

따라서 진짜 축은 33k 대 7k가 아닙니다. 그것은 바로 _캐시 안정성(cache stability)_입니다. 바이트 단위로 안정적인 큰 서문(preamble)은 첫 번째 턴 이후에는 반올림 오차 수준에 불과합니다. 반면 매 턴마다 변하는 더 작은 서문은 비용을 서서히 갉아먹습니다. 최저 비용은 잘못된 것을 측정하고 있습니다. 캐시 쓰기율(cache write rate)이 바로 청구서에 나타나는 실질적인 요소를 측정합니다.

당장 내일부터 실행할 수 있는 프레임워크

기본 토큰(baseline tokens)에 대한 논쟁을 멈추십시오. 평가하려는 모든 에이전트에 대해 세 가지 수치를 측정하면, 해당 에이전트의 컨텍스트 예산(context budget)이 귀하의 워크로드에 걸만한 가치가 있는 도박인지 알 수 있습니다.

1. 고정 오버헤드 (최저 비용, the floor). 하네스(harness)와 엔드포인트(endpoint) 사이에 로깅 프록시(logging proxy)를 삽입하십시오. 가장 깔끔한 기준점은 아주 사소한 작업입니다. 예를 들어 한 단어로 대답하라고 요청한 뒤 요청 본문(request body)을 캡처하는 것입니다. 이것은 제가 실행한 것이 아니라 귀하의 설정에 따라 달라지는 실제 프록시이지만, 그 형태는 다음과 같이 수십 줄 정도입니다:

from mitmproxy import http
import json

...

페이로드(Payload) 수준의 카운트는 정확하며 어떤 게이트웨이도 이를 왜곡할 수 없습니다. 이것이 전송되는 데이터에 대한 귀하의 실측값(ground truth)입니다.

2. 캐시 쓰기 속도 (Cache write rate). 멀티 턴 (multi-turn) 작업을 실행하고 턴당 cache_creation_input_tokens를 관찰하세요. 첫 번째 턴 이후에 이 수치가 ~0에 가깝다면, 접두사 (prefix)가 안정적이며 바닥 비용 (floor)은 일회성 비용입니다. 만약 이 수치가 계속 상승한다면, 서문 (preamble)이 변형 (mutating)되고 있으며 귀하의 정상 상태 (steady-state) 비용은 바닥 비용이 시사하는 것보다 훨씬 높습니다. 이것이 실제로 청구 금액을 예측하는 수치입니다.

3. 턴당 비용이 아닌 전체 작업 총합 (Whole-task total, not per-turn). 매 턴마다 다시 비용을 지불하는 더 가벼운 베이스라인 (baseline)이, 배칭 (batching)을 수행하는 무거운 베이스라인에 패배할 수 있습니다. 오직 대표적인 작업에 대한 엔드 투 엔드 (end-to-end) 토큰 수만이 누가 더 저렴한지를 알려줍니다. 그리고 그 답은 작업에 따라 뒤바뀌므로, FizzBuzz가 아닌 귀하의 실제 업무와 유사한 작업을 사용하세요.

그다음 도박을 판단하십시오. 귀하의 워크로드 (workload)가 파일에 대한 단발성 (single-shot) 질의응답인가요? 그렇다면 33k 오케스트레이션 부트스트랩 (orchestration bootstrap)은 순전한 세금일 뿐입니다. 더 가벼운 에이전트 (agent)가 압도적으로 승리합니다. 계획 (planning)과 위임 (delegation)이 실제로 작동하는 길고 다단계인 리팩토링 (refactors)인가요? 그렇다면 해당 토큰들이 제공하는 능력이 비용을 뽑아낼 수도 있습니다 — 만약 캐시가 충분히 안정적이어서 비용을 한 번만 지불하면 되는 경우에 말입니다.

요점 (The takeaway)

"4.7배 더 많은 토큰"은 메뉴에 대한 사실이지, 식사에 대한 판결이 아닙니다. 무거운 서문은 모델이 도달할 수 있는 능력을 미리 가격을 매겨 제공하는 것이며, 가벼운 서문은 귀하가 사용하지 않을 수도 있는 옵션에 비용을 지불하기를 거부하는 것입니다. 추상적인 관점에서는 어느 쪽도 옳지 않습니다. 이를 결정 가능하게 만드는 것은 세 가지 측정값 — 바닥 비용 (floor), 캐시 쓰기 속도 (cache write rate), 전체 작업 총합 (whole-task total) — 그리고 귀하의 작업과 유사한 형태로 이를 실행하는 규율입니다.

함정 수치 (gotcha number)는 누가 더 무겁게 턴을 시작하는지를 알려줍니다. 귀하의 대리 지표 (proxy)는 누가 실제로 더 저렴한지를 알려줍니다. 이 둘은 동일한 에이전트가 아니며, 어느 쪽이 무엇인지 추측할 수 없습니다. 측정하십시오.