토큰 낭비가 안 보이는 이유는 실패가 아니라 중복이라서입니다 같은 파일 두 번 읽기, 같은 인자로 재시도, 같은 도구 재호출. 그래서 끝난 트레이스를 읽어서 어느 스텝이 이미 한 일을 또 했는지 짚어주는 CLI를 만들었습니다!

[써보기]

pip install "clew-custos[detect]"

python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md

가입 없이 로컬에서 돌아갑니다. torch를 안 받아서 설치는 몇 초면 끝납니다. Python 3.12 이상. Claude Code 세션 파일은 ~/.claude/projects/ 아래에 있습니다.

공개 Claude Code 세션(258턴)에 돌린 실제 출력입니다:

Result: WASTE DETECTED

• category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified

1. requery — Read on .../boot.ts

• turns: turn 50 → re-run at turn 58 (of 258 total)
• state: No modification of this file in between — re-read output is unchanged.
• re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
• estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)

[어떻게 판정하나]

Langfuse나 Phoenix처럼 트레이스를 저장하고 시각화하지 않습니다. 이미 끝난 트레이스를 읽어서 낭비만 짚습니다.

2단계입니다. 먼저 같은 도구를 같은 인자로 부른 것끼리 묶고, 그다음 출력의 sha256이 완전히 같은지 봅니다. 출력이 다르면 상태가 바뀐 거라 안 잡습니다.

LLM 판정이 없습니다. 같은 트레이스를 넣으면 언제나 같은 결과가 나옵니다.

찾은 낭비는 네 종류로 분류합니다. 에러 반복(같은 에러를 원인 안 고치고 재시도), 부작용 재실행(상태를 바꾸는 도구를 같은 인자로 다시 호출), 회색지대(읽기 전용 반복 — 부작용은 없지만 토큰은 씀), 판정불가. Bash나 PowerShell처럼 인자 내용에 따라 효과가 완전히 달라지는 도구는 이름만으로 판정하지 않고 판정불가로 둡니다.

[공개 데이터에서 뭘 찾았나]

Toolathlon 벤치마크(22개 프론티어 모델 × 3회 실행, 6,780 트레이스, tool span 176,270개)에 그대로 돌렸더니 중복 호출 8,042건이 나왔습니다.

이 숫자를 그대로 쓰면 부풀린 겁니다. 47%는 회색지대(작업 완료 선언 반복, 이미 있는 디렉토리 재생성 같은 것)라서, 빼고 나면 4,251건입니다. tool span 대비 2.41%.

눈에 띈 건 상태를 바꾸는 도구의 중복 실행 1,343건이었고, 그중 같은 인자로 반복된 이메일 발송이 459건이었습니다. 다만 이건 "같은 도구가 같은 인자로 두 번 호출됐다"는 탐지고, 실제로 메일이 두 번 나갔는지는 트레이스만으론 확인할 수 없습니다.

[의외였던 것]

Claude Code 자체는 생각보다 효율적이었습니다. 파일 재읽기, 무의미한 재시도 같은 후보 패턴을 여섯 번 측정했는데 다섯 번은 CC 실세션에 사실상 존재하지 않았습니다. 캐싱과 컨텍스트 유지로 이미 막고 있더군요.

낭비가 두꺼운 쪽은 MCP 서버를 여러 개 붙인 환경이었습니다. 도구가 20개인 CC(0.80%)와 523개인 Toolathlon(2.41%)이 3배 차이였습니다.

[한계]

측정된 절감 사례는 아직 없습니다. 탐지하고 추정할 수는 있지만, 누가 이걸 보고 뭔가 고쳐서 청구서가 실제로 줄어든 데이터는 0건입니다.

회색지대 47%는 걸러내지 않고 분류만 해서 보여줍니다. 읽기 전용 반복이 실제 낭비인지는 실행 맥락에 따라 다르고, 그건 제가 판단할 수 없는 부분이라서요.

Cursor와 Codex는 아직 지원하지 않습니다.

검증에 실패한 탐지기는 폐기합니다. 파일 재읽기 탐지기를 만들었다가 30건 표본에서 정밀도가 70% 임계를 크게 밑돌아(관대하게 봐도 3.3%, 엄격하면 0%) 죽였고, 사전등록 문서에 예측과 결과를 함께 남겨뒀습니다.

[마무리...]

이 분야에 대해서 계속 연구와 검증 할 예정입니다!

readme가 영문인점은 죄송합니다.. ㅜ

만약 사용하시고 이런 부분은 개선 되었으면 좋겠고 추가 되었으면 좋겠다 라는 부분의 피드백을 받고 싶습니다!

앞으로 clew에게 많은 관심 부탁드립니다 감사합니다...!!