토큰 줄이기는 비용 줄이기가 아니다: API 기반 코딩 에이전트 실측
Token Reduction Is Not Cost Reduction
TL;DR Highlight
Claude Code 도구 출력을 38.4% 줄였더니 청구 비용은 오히려 6.8% 늘었다
Who Should Read
Claude Code 같은 코딩 에이전트에 토큰 압축 도구를 붙여 API 비용을 줄이려는 개발자
Core Mechanics
- 도구 출력 38.4% 줄여도 비용은 +6.8%
- RTK-ML은 도구 출력 토큰을 5.62M에서 3.46M으로 줄였다.
- 그런데 베이스라인 대비 청구 비용은 6.8% 올랐다.
- 비용 대부분은 캐시 트래픽이다
- 캐시 생성과 캐시 읽기가 실제 청구액의 약 80%였다.
- 생성 출력 토큰은 청구액의 10.4%뿐이었다.
- 건드릴 수 있는 비용은 6%뿐
- 시스템 프롬프트와 툴 정의, 숨은 thinking이 비용의 94.0%를 차지한다.
- 도구 출력은 비용의 3.3%라서 압축 효과의 상한이 작다.
- 줄인 만큼 에이전트가 다시 일한다
- 압축으로 맥락이 빠지면 재검색, 진단, 테스트 턴이 늘었다.
- 턴이 늘 때마다 전체 컨텍스트 prefix가 다시 전송되어 절감분이 상쇄됐다.
- 압축이 편집 앵커와 파이프를 깨뜨렸다
- SEARCH/REPLACE 편집은 코드 앵커를 바이트 단위로 맞춰야 하는데 압축이 그 부분을 바꿨다.
- 검색 요약이 grep 파이프라인으로 흘러가 에러 없이 틀린 답이 나왔다.
Evidence
- RTK-ML은 비용 +6.8%
- 베이스라인 Claude Code 대비 청구 비용 +6.8% [+2.8, +11.3], 103개 태스크, 암(arm)당 712회 실행 기준이다.
- 성공 1건당 비용(CPS) 비율은 1.051이었다.
- Headroom v0.27.0은 비용 +48.4%
- 베이스라인 대비 청구 비용 +48.4% [+42.3, +55.0], CPS 비율 1.464였다.
- 성공률 차이는 +1.4pp [-0.2, +3.1]로 유의하지 않았다.
- 도구 출력 감소율과 비용 변화는 거의 무상관
- Haiku 100개 태스크 기준 Pearson r=0.154 [-0.051, +0.356], Spearman ρ=0.013이었다.
- Go 편집 실험에서 패치 적용률 하락
- ContextBench-Go 40행에서 압축으로 billable 토큰 -73%, 비용 -59%였다.
- 패치 적용은 raw 27/40에서 compressed 15/40으로 떨어졌다.
How to Apply
- 토큰 절감 말고 성공당 비용으로 측정하기
- 오늘 쓰는 압축 도구 하나를 골라 같은 태스크 10개를 도구 켠 상태와 끈 상태로 돌려라.
- 청구 비용 합계를 성공한 실행 수로 나눠 비교하라.
- 캐시 읽기·쓰기 토큰 따로 로깅하기
- 응답 usage의 input_tokens, cache_creation_input_tokens, cache_read_input_tokens, output_tokens를 실행마다 기록하라.
- 비용에서 어느 항목이 큰지 먼저 확인하고 압축 대상을 정하라.
- 압축 제외 규칙 넣기
- traceback, 테스트 출력, 패치 앵커처럼 정확한 내용이 필요한 출력은 원문 그대로 통과시켜라.
- 다른 프로그램의 파이프로 넘어가는 stdout에는 압축을 적용하지 마라.
- 도입 전 턴 수와 성공률을 같이 비교하기
- 도구 적용 전후로 평균 턴 수, 재검색 횟수, 성공률을 함께 기록하라.
- 턴이 늘고 비용이 올랐다면 도구를 끄거나 적용 범위를 줄여라.
Try It
# Claude Code 또는 Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 성공당 비용 계산)
아래는 코딩 에이전트 실행 로그다. 각 실행은 arm(baseline/compressed), cost_usd, success(true/false), turns다.
{{실행 로그 CSV}}
다음을 계산해 표로 보여줘.
1. arm별 실행 수, 성공률, 평균 턴 수, 총 비용
2. arm별 성공당 비용 = 총 비용 / 성공 횟수 (실패한 실행도 총 비용에 포함)
3. compressed의 baseline 대비 비용 변화(%)와 성공당 비용 비율
토큰 절감률이 아니라 성공당 비용 기준으로 압축이 이득인지 한 줄로 결론 내려줘.
이어서 해 볼 것: 태스크별로 짝지어 비교하고, 턴이 늘어난 태스크만 따로 뽑아줘.Terminology
관련 논문
Mercury 3: 규모를 키운 diffusion LLM, 초당 1,000토큰 이상
Diffusion LLM을 40배 키웠더니 속도 4~8배, 품질은 속도 특화 모델 수준
Timestral: Mistral의 시계열 파운데이션 모델
209M 파라미터 시계열 모델이 3대 벤치마크 1위, CPU에서도 돌아간다
DeepSeek V4.1 Flash 1017 (Max) 성능·속도·가격 분석
DeepSeek V4.1 Flash 1017 Max는 지능 지수 45에 211 tok/s, 입력 $0.30
LLM 프록시를 직접 안 돌리면 무슨 일이 벌어지는지 어떻게 아나
자체 LLM 프록시를 세웠더니 키·모델·캐시 미스를 직접 볼 수 있다
DeepSeek V4.1 Flash 1017: 싼 가격에 1M 컨텍스트를 주는 에이전트용 모델
DeepSeek V4.1 Flash 1017은 입력 $0.05/M, 1M 컨텍스트의 에이전트용 모델
DeepSeek-V4.1-Flash-1017 공개: 더 짧게 생각하고 더 빠르게 일하는 에이전트용 모델
DeepSeek V4.1 Flash 마이너 업데이트로 코딩·에이전트 벤치 점수↑, 실행 시간·출력 길이↓
Llmspeed: 로컬 LLM 속도를 하드웨어 구매 전에 체감해 보는 시뮬레이터
GPU·모델을 고르면 로컬 LLM 속도를 미리 체감하게 해 주는 시뮬레이터
Related Resources
Original Abstract (Expand)
Token-reduction tools for coding agents are often evaluated by the number of tokens they remove, but token count alone does not determine end-to-end inference cost. We evaluate three token-reduction approaches against an unmodified Claude Code baseline across controlled coding tasks, measuring provider-billed cost, task success, cache traffic, and agent behavior. The largest compression setup reduced delivered tool-output tokens by 38.4% but increased billed cost by 6.8%, while lighter compression produced only small and statistically uncertain savings. Across tasks, token reduction was weakly correlated with cost reduction (Pearson r = 0.15). Cost decomposition shows that prompt-cache creation and reads dominate the measured input-side cost, leaving only a limited fraction of total spend directly addressable by tool-output compression. We also find that compression can alter agent trajectories through additional retrieval, diagnosis, testing, and turns, offsetting local token savings. On a SWE-bench Go subset, aggressive compression also reduced successful patch application. These results show that token reduction is not a reliable proxy for cost reduction in tool-heavy coding agents. Effective optimization should therefore be evaluated at the level of cost per successful task, including cache behavior, trajectory changes, and correctness rather than token counts alone.