CLI 코딩 에이전트는 청구서가 도착하기 전까지는 자유롭게 느껴집니다. Claude Code 또는 Codex를 리포지토리에 연결하고 모듈 리팩터링을 요청하면 10분 후 에이전트는 40개의 파일을 읽고, 테스트 스위트를 세 번 실행하며, 필요하지도 않은 컨텍스트에 수십만 토큰을 소모합니다. 8명의 엔지니어 팀이 하루 종일 에이전트를 실행한다고 가정하면, 이 비용은 더 이상 반올림 오차가 아닙니다. 코딩 에이전트에 대한 토큰 지출은 대부분 낭비이며, 이 낭비의 대부분은 모델을 변경하거나 더 나쁜 출력을 받아들이지 않고도 명령줄에서 수정할 수 있습니다.
요약
모델에 도달하기 전에 컨텍스트를 잘라내어 에이전트 토큰 비용을 절감하세요: 작업 세트의 범위를 지정하고, 메모리 파일을 짧게 유지하며, 긴 세션을 압축합니다. 안정적인 접두사를 위해 프롬프트 캐싱을 켜세요(반복 읽기에서 약 90% 절감). 저렴한 하위 작업을 작은 모델로 라우팅하세요. 도구 출력을 제한하세요. 실제로 무엇이 바뀌었는지 알 수 있도록 실행당 비용을 측정하세요.
서론
문제는 두 가지 방식으로 나타납니다. 주간 또는 세션 한도를 초과하여 작업 도중에 갑자기 막히거나, 월별 API 청구서가 도착하고 누군가가 "AI 비서"가 주니어 계약자보다 더 비싼 이유를 묻는 경우입니다. 둘 다 동일한 근본 원인에서 비롯됩니다: CLI 에이전트는 기본적으로 토큰을 많이 소비합니다. 10줄만 필요한데도 전체 파일을 읽고, 매 턴마다 전체 대화를 반복하며, 원시 명령 출력을 컨텍스트에 덤프하고, 동일한 시스템 프롬프트와 리포지토리 맵을 하루에 수천 번 다시 보냅니다.
이 중 어느 것도 작업 본질에 내재된 것이 아닙니다. 코드 2,000 토큰에 대해 진정으로 추론해야 하는 리팩터링은 180,000 토큰의 컨텍스트를 필요로 하지 않습니다. 이 두 숫자 사이의 간격이 바로 여러분의 절감액이며, 거의 모든 것이 오늘 채택할 수 있는 플래그, 구성 파일, 습관으로 회수 가능합니다.
이 가이드는 CLI 에이전트 실행에서 토큰이 실제로 어디로 가는지 설명하고, 각 항목을 절감하기 위한 구체적인 전술을 제공합니다: 컨텍스트 관리 및 메모리 파일, 프롬프트 캐싱, 모델 라우팅, 도구 출력 및 검색 트리밍, 그리고 절감액이 추측이 아니라 실제가 되도록 실행당 비용 측정. 예시는 Claude Code와 Codex를 가정하지만, 이 메커니즘은 토큰 단위로 요금이 청구되는 API와 통신하는 모든 에이전트에 적용됩니다.
미리 언급할 가치가 있는 한 가지 관련 비용: 에이전트 토큰 지출의 많은 부분은 디버깅입니다. 불안정한 내부 API를 호출하는 에이전트는 재시도하고, 오류 본문을 읽고, 문서를 다시 읽고, 반복하며, 매 반복마다 전체 토큰 비용을 지불합니다.
CLI 에이전트 실행 시 토큰이 실제로 어디로 가는지
최적화하기 전에 청구서에 대한 정신 모델이 필요합니다. 단일 에이전트 "턴"은 모델에 입력 페이로드를 보내고 출력 페이로드를 다시 받습니다. 이 둘 모두에 대해 비용을 지불하며, 대부분의 공급자에서 출력 비용은 입력보다 토큰당 3배에서 6배 더 비쌉니다. 2026년 중반의 한 최신 모델 제품군에서는 입력이 100만 토큰당 약 3달러, 출력이 약 15달러입니다. 동일 제품군의 더 저렴한 모델은 대략 입력이 1달러, 출력이 5달러입니다. 이는 예시적인 것이며 견적이 아닙니다. 공급자가 요금을 개정하므로 실제 가격 페이지를 확인하세요. 정확한 숫자에 관계없이 구조적인 요점은 변함없습니다: 출력은 비싸고, 입력 볼륨이 크게 증가합니다.
일반적인 실행에서 입력 페이로드를 채우는 내용은 다음과 같습니다:
- 시스템 프롬프트 및 도구 정의. 에이전트의 지침과 각 도구의 JSON 스키마. 턴당 고정되며, 종종 5,000에서 15,000 토큰에 달하고 매 턴마다 다시 전송됩니다.
- 메모리 및 프로젝트 파일.
CLAUDE.md, 리포지토리 규칙, 영구 지침 등. 관련성 여부와 관계없이 매 턴마다 로드됩니다. - 대화 기록. 이전의 모든 사용자 메시지, 모델 응답, 도구 호출 및 도구 결과가 매 턴마다 전체적으로 다시 재생됩니다. 이는 무한히 증가하며 일반적으로 긴 세션에서 가장 큰 항목입니다.
- 검색된 파일 내용. 에이전트가 읽은 파일. 1,200줄 파일에 대한 단일
Read는 대략 12,000에서 18,000 토큰이며, 에이전트는 전체 파일을 읽는 것을 좋아합니다. - 도구 출력. 테스트 러너 로그,
npm install노이즈, 생성된 잠금 파일의git diff, 스택 트레이스. 기본적으로 원시적이고 장황합니다.
출력 페이로드는 모델의 추론, 코드 편집 및 설명입니다. 대부분의 실행에서 입력보다 작지만, 토큰당 가격이 가장 높으므로 "제 계획을 6단락으로 설명하겠습니다"와 같은 장황한 행동은 비용이 많이 듭니다.
가장 중요한 사실: 대화 기록은 매 턴마다 다시 재생됩니다. 30턴 세션은 1턴의 30배 비용이 들지 않습니다. 이는 성장하는 접두사의 합에 더 가깝기 때문에 나중 턴은 그 이전의 모든 것의 전체 가중치를 부담합니다. 이것이 길고 지루한 세션이 할 수 있는 가장 비싼 일인 이유이며, 아래 전술이 재전송되는 컨텍스트를 불균형적으로 목표로 하는 이유입니다.
세션 및 한도 계산이 실제로 어떻게 작동하는지에 대한 더 깊은 내용은 Claude Code 토큰 창이 재설정되는 방식에 대한 설명이 이 섹션의 유용한 동반자입니다. 이는 "짧게 느껴지는" 세션도 예산을 소진할 수 있는 이유를 설명합니다.
컨텍스트 관리 및 메모리 파일
가장 저렴한 토큰은 절대 보내지 않는 토큰입니다. 컨텍스트 관리는 세션의 나머지 기간 동안 매 턴마다 입력 페이로드를 줄여주기 때문에 가장 영향력 있는 습관입니다.
시작하기 전에 작업 세트의 범위를 지정하세요. 리포지토리 루트에서 에이전트를 열고 "청구 로직을 리팩터링하세요"라고 말하지 마세요. 에이전트가 탐색을 시작할 것입니다. 대신, 어떤 파일이 중요한지 정확히 알려주세요:
# 광범위한 탐색을 유발하는 모호한 프롬프트 대신:
claude "src/payments/retry.ts 및 해당 테스트 파일에서만 재시도 로직이 지수 백오프를 사용하도록 리팩터링하세요"
파일 이름을 지정하면 에이전트가 중요한 두 파일을 찾기 위해 20개의 후보를 읽는 것을 방지합니다. 탐색을 허용해야 한다면, 루트가 아닌 디렉터리를 가리키세요.
메모리 파일을 짧고 안정적으로 유지하세요. CLAUDE.md (또는 이에 상응하는 프로젝트 메모리 파일)는 매 턴마다 컨텍스트에 로드됩니다. 팀은 이를 위키처럼 취급하고 4,000 토큰의 온보딩 설명으로 늘립니다. 예를 들어, 8명의 엔지니어가 하루에 50턴을 수행한다면, 부풀려진 메모리 파일은 추가적인 이점 없이 매일 수백 번 재전송됩니다. 이를 감사하세요:
# 메모리 파일에 대한 대략적인 토큰 확인 (문자 수 / 4는 적절한 추정치):
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}'
밀집된 파일을 목표로 하세요: 빌드/테스트 명령, 엄격한 규칙, 그리고 더 깊은 문서가 있는 위치에 대한 포인터를 포함하되, 문서 자체는 포함하지 마세요. 한 달에 한 가지 작업에만 관련되는 섹션은 항상 로드되는 파일에 속해서는 안 됩니다. 에이전트가 필요할 때 읽는 문서로 옮기세요.
긴 세션을 압축하거나 재설정하세요. 세션이 역할을 마쳤고 관련 없는 작업으로 이동할 때, 동일한 컨텍스트에 계속 입력하지 마세요. 이제 모든 새로운 턴이 전체 이전 기록을 끌고 다닙니다. 에이전트의 압축 또는 지우기 명령을 사용하세요:
# Claude Code에서 대화가 길어질 때:
/compact # 기록을 짧은 요약으로 압축하고, 원시 기록은 삭제합니다
# 또는 새로운 작업에서 깔끔하게 시작하려면:
/clear # 새로 시작합니다; 이전 컨텍스트는 더 이상 재전송되지 않습니다
/compact는 일반적으로 수만 토큰의 원시 기록을 10분의 1 크기의 요약으로 대체하며, 이 더 작은 접두사가 이후의 모든 턴에 적용됩니다. 규칙은 간단합니다: 세션당 하나의 논리적 작업, 작업 사이에 압축 또는 지우기. Claude Code 워크플로우의 워크플로우 패턴은 이 범위 지정 습관에 크게 의존하며, 이를 전반적으로 채택할 가치가 있습니다.
프로젝트 무시 파일을 사용하세요. 생성된 아티팩트, 잠금 파일, 빌드 출력 및 벤더링된 종속성을 에이전트의 접근 범위 밖으로 유지하세요. 에이전트가 dist/ 또는 node_modules/를 보지 않으면, 이를 읽거나 비교하는 데 토큰을 소비하지 않습니다. 대부분의 에이전트는 무시 파일을 존중합니다. 한 번 구성하면 절감 효과는 영구적입니다.
프롬프트 캐싱: 동일한 접두사에 대해 전체 비용을 지불하지 마세요
이것은 반복 실행을 위한 가장 큰 지렛대이며, 행동적인 것보다는 기계적인 것입니다. 프롬프트 캐싱을 통해 공급자는 요청의 접두사(도구, 시스템 프롬프트, 안정적인 컨텍스트)를 저장할 수 있으므로, 해당 접두사를 공유하는 후속 요청은 재처리하는 대신 엄청난 할인된 가격으로 다시 읽을 수 있습니다.
Anthropic의 프롬프트 캐싱 문서에 따르면 경제성은 다음과 같습니다: 캐시 쓰기는 일반 입력 토큰보다 비용이 더 많이 들지만(기본 5분 캐시의 경우 기본 입력의 약 1.25배, 1시간 캐시의 경우 약 2배), 캐시 읽기는 기본 입력의 약 0.1배에 불과합니다. 이는 캐시된 부분에 대해 약 90% 할인입니다. 쓰기 프리미엄이 작고 읽기 할인이 크기 때문에, 단기 캐시에서 캐시 적중이 한 번 발생한 후, 장기 캐시에서는 약 두 번 적중한 후에 캐싱은 그 자체로 비용을 상환합니다. 기본 캐시 수명은 짧지만(약 5분, 적중할 때마다 새로 고침됨), 1시간 옵션도 사용할 수 있습니다. 캐시 가능한 최소 크기가 있습니다. 작은 모델과 가장 큰 모델은 접두사가 자격이 되기 전에 몇 천 토큰이 필요하므로, 캐싱은 가장 중요한 곳, 즉 크고 안정적인 접두사에서 가장 도움이 됩니다.
구조적 규칙은 안정적인 내용을 먼저, 변동적인 내용을 마지막에 배치한 다음 경계를 캐시하는 것입니다. 순서는 tools → system → messages이며, 어떤 것을 변경하면 해당 수준과 그 이후의 모든 것이 무효화됩니다. 따라서 타임스탬프, 사용자의 들어오는 메시지, 새로 검색된 파일 내용은 캐시 중단점 이후에 와야 하며, 이전에 오면 안 됩니다.
자체 CLI 래퍼에서 모델을 직접 구동하는 경우, 이를 명시적으로 설정합니다:
# 안정적인 접두사 (시스템 + 도구 정의 + 리포 규칙)를 캐시합니다.
# 변동적인 사용자 턴은 나중에 오며 캐시된 접두사의 일부가 아닙니다.
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system=[
{
"type": "text",
"text": SYSTEM_PROMPT + REPO_CONVENTIONS, # 실행 전반에 걸쳐 안정적임
"cache_control": {"type": "ephemeral"}, # 캐시 중단점 위치
}
],
messages=[{"role": "user", "content": user_task}], # 실행마다 변경됨
)
# 실제로 캐시된 내용을 검사합니다:
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens) # 이 토큰은 약 10% 청구됨
print("fresh input:", u.input_tokens)
매일 동일한 시스템 프롬프트와 8,000 토큰의 동일한 리포지토리 규칙 블록을 하루 60번 호출하는 일일 리팩터링 에이전트가 교과서적인 경우입니다. 캐싱 없이는 해당 8,000 토큰 블록에 대해 60번 전체 입력 비용을 지불합니다. 캐싱을 사용하면 쓰기 프리미엄을 한 번(또는 캐시 만료 시마다 한 번) 지불하고 다른 시간에는 약 10%의 읽기 비용을 지불합니다. 규칙 블록만으로도 약 90%의 절감 효과가 있으며, 이는 여기의 다른 모든 전술과 함께 쌓입니다.
두 가지 운영 참고 사항. 첫째, 접두사를 바이트 단위로 안정적으로 유지하세요. 중단점 전에 문자 하나만 변경되어도 캐시가 파괴되고 다시 쓰기 비용을 지불하게 됩니다. 시스템 프롬프트와 규칙을 고정하세요. 타임스탬프를 삽입하지 마세요. 둘째, 캐시는 기본적으로 단명하므로, 관련된 실행을 (하루 종일 분산하지 않고) 가까이 묶어 실행하면 따뜻한 캐시를 계속 적중할 수 있습니다. OpenAI의 API는 지원되는 모델에서 캐시된 입력에 유사한 할인을 자동으로 적용합니다. 조작 방식은 다르지만 원리는 동일합니다. Codex를 통해 GPT-5.5를 무료로 실행하는 무료 티어 및 라우팅 트릭은 캐싱만으로는 충분하지 않을 때 유용한 보완책입니다.
모델 라우팅: 저렴한 작업에는 저렴한 모델
모든 에이전트 작업에 최신 모델이 필요한 것은 아닙니다. 세 개의 파일에 걸쳐 변수 이름을 바꾸거나, 커밋 메시지를 작성하거나, diff를 요약하거나, 상용구 테스트를 생성하는 데 아키텍처를 설계하는 데 필요한 것과 동일한 모델이 필요하지 않습니다. 그러나 대부분의 CLI 에이전트의 기본 동작은 전체 세션 동안 모든 것을 하나의 비싼 모델을 통해 실행하는 것입니다.
라우팅은 중요도가 낮은 하위 작업을 의도적으로 더 작고 저렴한 모델로 보내고, 진정한 추론에는 비싼 모델을 예약하는 것을 의미합니다. 가격 차이는 큽니다. 주어진 제품군에서 작은 모델은 플래그십 모델보다 토큰당 3~5배 저렴할 수 있으며, 기계적인 작업의 경우 출력 품질 차이는 미미합니다.
CLI에서 라우팅하는 실용적인 방법:
# 1. 작업에 따라 호출별 모델을 선택합니다.
claude --model haiku "스테이지된 diff에 대한 컨벤션-커밋 메시지를 작성하세요"
claude --model sonnet "결제 서비스의 캐싱 계층을 재설계하세요"
# 2. 빈번하고 중요도가 낮은 루프에는 저렴한 모델을 사용하고
# (커밋 메시지, 변경 로그 항목, 빠른 린트 설명)
# 명시적으로 어려운 작업을 호출할 때만 강력한 모델을 사용합니다.
기본값을 저렴한 모델로 설정하고 의식적으로 에스컬레이션하는 것이 좋습니다. 비싼 모델을 기본으로 설정하고 절대로 낮추지 않는 것보다 말입니다. 대부분의 팀은 극성이 거꾸로 되어 있습니다. 그들은 "안전하게" 모든 것에 플래그십 모델을 사용하고 커밋 메시지에 대해 5배의 비용을 지불합니다.
두 번째 라우팅 축은 서브 에이전트입니다. 에이전트 프레임워크가 좁은 하위 작업을 하위 에이전트에게 위임하는 것을 지원한다면, 해당 하위 에이전트에게 저렴한 모델과 작은 컨텍스트를 제공하세요. 하위 에이전트는 저렴한 비용으로 단순 작업(검색, 요약, 초안 작성)을 수행하고 비싼 부모에게 짧은 결과를 보고합니다. 비싼 부모가 전체 컨텍스트로 전체 비용을 지불하며 단순 작업을 직접 수행하는 대신 말입니다. Codex 및 Claude Code 전반의 목표 명령에 있는 자율 루프 패턴은 비싼 모델이 정제된 결과만 볼 수 있도록 위임을 구성하는 방법을 보여줍니다.
단순히 비용뿐만 아니라 한도에 대한 참고 사항입니다. 순수한 종량제 방식이 아닌 사용량 제한 요금제를 사용하는 경우, 라우팅은 허용량이 얼마나 오래 지속될 수 있는지도 늘려줍니다. 프리미엄 모델 예산을 커밋 메시지에 소진하는 것은 팀이 목요일까지 한계에 부딪히는 방법입니다. 최근 Claude Code 주간 한도 증가는 도움이 되지만, 라우팅은 여전히 허용량이 지속되도록 하는 방법입니다.
도구 출력 및 검색 트리밍
도구 출력은 살펴보지 않으면 보이지 않기 때문에 조용한 예산 살인자입니다. 에이전트가 실행하는 모든 명령은 텍스트를 반환하며, 이 텍스트는 즉시 컨텍스트로 돌아가 후속 모든 턴에서 다시 재생됩니다. 단일 npm install은 수천 줄을 반환할 수 있습니다. 자세한 로깅이 있는 테스트 실행은 수만 토큰을 반환할 수 있습니다. 재생성된 잠금 파일이 포함된 git diff는 엄청날 수 있습니다. 에이전트는 거의 모든 것을 필요로 하지 않습니다. 통과/실패 여부와 관련된 실패만 필요합니다.
이를 깔끔하게 절감하는 전술:
소스에서 명령을 조용하게 만드세요. 에이전트는 명령이 출력하는 모든 것에 대해 비용을 지불합니다. 도구를 간결하게 구성하세요:
# 시끄러움 (에이전트는 모든 줄에 대해 비용을 지불합니다):
npm test
# 조용함 (실패 및 요약만 반환됩니다):
npm test --silent -- --reporter=dot
# 시끄러움:
npm install
# 조용함:
npm install --silent --no-audit --no-fund
에이전트가 보기 전에 필터링하세요. 에이전트가 실행하는 명령을 제어할 때, 노이즈를 걸러내어 신호만 반환되도록 파이프 처리하세요:
# 중요한 줄만 컨텍스트로 돌아옵니다:
pytest -q 2>&1 | tail -n 30
# 4,000줄 전체 diff 대신 diff 통계:
git diff --stat
# 전체 로그를 덤프하는 대신 실패를 grep 합니다:
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20
전체 파일 읽기보다 대상 지정 읽기를 선호하세요. 한 함수를 변경하기 위해 1,500줄 파일을 읽는 것은 순수한 낭비입니다. 에이전트가 심볼을 grep하고 전체 파일이 아닌 그 주위의 창을 읽도록 권장하세요. 많은 에이전트는 프롬프트가 이들을 유도할 때("전체 파일이 아니라 재시도 처리를 담당하는 함수만 찾아 읽으세요") 이렇게 합니다. 큰 파일의 경우 약 18,000 토큰과 약 800 토큰의 차이가 있습니다.
검색 범위를 제한하세요. 에이전트가 코드베이스 검색 또는 문서에 대한 RAG를 수행하는 경우, 가져오는 청크 수와 크기를 제한하세요. 질문에 답하는 10개의 200 토큰 스니펫은 이를 묻어버리는 50개의 800 토큰 스니펫보다 낫습니다. 모델이 사용하든 안 하든 검색된 모든 토큰에 대해 비용을 지불합니다.
이러한 변경 사항은 대부분 일회성 구성(테스트 리포터, 설치 플래그, 무시 파일)이며 영원히 모든 실행에서 비용을 절감하므로, 이 목록 전체에서 노력 대비 최고의 수익을 제공하는 일부입니다.
실행당 비용 측정 및 귀속
측정하지 않는 것은 관리할 수 없으며, "청구서가 줄었다"는 측정값이 아닙니다. 어떤 전술이 효과적이었는지 알기 위해서는 실행당, 이상적으로는 작업당 비용을 귀속해야 합니다.
API가 이미 제공하는 데이터부터 시작하세요. 모든 응답에는 사용량 객체가 포함됩니다. 이를 캡처하세요:
u = response.usage
# 달러 단위의 대략적인 비용; 모델의 실시간 요금으로 대체하세요.
INPUT_RATE = 3.00 / 1_000_000 # 기본 입력 $/토큰 (예시)
OUTPUT_RATE = 15.00 / 1_000_000 # 출력 $/토큰 (예시)
CACHE_READ = 0.30 / 1_000_000 # 기본 입력의 약 10%
CACHE_WRITE = 3.75 / 1_000_000 # 기본 입력의 약 1.25배 (5분 캐시)
cost = (
u.input_tokens * INPUT_RATE +
u.output_tokens * OUTPUT_RATE +
u.cache_read_input_tokens * CACHE_READ +
u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"run cost ≈ ${cost:.4f} "
f"(in={u.input_tokens} out={u.output_tokens} "
f"cr={u.cache_read_input_tokens})")
자체 래퍼 대신 에이전트 CLI를 사용하는 경우, 세 가지 접근 방식이 작동합니다:
# 1. 대부분의 에이전트 CLI는 세션에 대한 사용량/비용 명령을 노출합니다.
# 대표적인 작업을 마친 후 확인하고 숫자를 기록하세요.
claude /cost
# 2. 공급자 콘솔은 API 키별 지출을 보고합니다. 전용
# API 키를 에이전트 또는 프로젝트별로 발급하여 지출이
# 추적 불가능한 총액으로 합산되는 대신 귀속될 수 있도록 합니다.
# 3. 실행에 태그를 지정합니다. 에이전트 호출을 스크립트로 래핑하여
# 타임스탬프, 작업 레이블, 보고된 토큰 수를 CSV에 기록합니다.
# 일주일간의 CSV는 어떤 작업이 비싼지 알려줍니다.
큰 작업에 대해서는 실행하기 전에 추정하세요. 포함하려는 프롬프트와 파일을 토큰화 도구(OpenAI의 공개 토큰화 도구는 크기를 빠르게 확인하는 좋은 방법입니다)에 붙여넣고 개수를 확인하세요. 만약 "전체 모듈 포함"이 90,000 토큰이고 대상 지정 버전이 6,000 토큰이라면, 지불하기 전에 결정을 내린 것입니다.
시간이 지남에 따라 대표적인 작업당 하나의 숫자를 추적하세요: "일일 리팩터링 실행"당 비용, "PR 검토 실행"당 비용. 캐싱을 켜거나 하위 작업을 저렴한 모델로 전환할 때, 그 숫자는 움직여야 합니다. 움직이지 않는다면, 그 전술은 생각하는 대로 작동하지 않는 것이며, 한 달치 청구서 대신 한 번의 실행 비용으로 그것을 알게 된 것입니다.
전술 비교
| 전술 | 일반적인 토큰 절감 | 노력 |
|---|---|---|
| 작업 세트 범위 지정 (파일 이름 지정, 탐색 금지) | 실행당 입력에서 30–60% | 낮음 |
| 짧고 안정적인 메모리 파일 | 매 턴마다 5–15% | 낮음 |
작업 간 /compact 또는 /clear |
긴 세션에서 40–80% | 낮음 |
| 안정적인 접두사에 프롬프트 캐싱 | 캐시된 접두사에서 ~90% | 중간 |
| 모델 라우팅 (저렴한 작업에 저렴한 모델) | 라우팅된 하위 작업에서 50–80% | 중간 |
| 조용/필터링된 도구 출력 | 도구 사용량이 많은 실행에서 20–50% | 낮음 (일회성) |
| 전체 파일 읽기보다 대상 지정 읽기 | 대용량 파일 편집에서 70–95% | 낮음 |
| 제한된 검색 범위 | RAG 사용량이 많은 에이전트에서 30–60% | 중간 |
| 실행당 비용 측정 | 직접적으로 0%; 위 모든 것을 가능하게 함 | 낮음 |
절감 범위는 예시적이며 곱셈으로 누적됩니다. 특정 전술의 이득은 여러분의 기준 낭비에 따라 달라집니다.
결론
에이전트 토큰 비용은 대부분 자초한 것이며, 명령줄에서 해결할 수 있습니다. 낭비는 재전송하는 컨텍스트, 읽지 않는 출력, 그리고 당면한 작업에 비해 너무 비싼 모델에 있습니다. 이러한 문제들을 해결하면 작업의 품질에 영향을 주지 않으면서 비용이 절감될 것입니다.
노력이 적게 드는 항목부터 먼저 수행하세요. 범위 지정, 조용한 출력, 그리고 간결한 메모리 파일은 비용이 들지 않으며 지금부터 모든 실행에서 이득을 제공합니다. 그 위에 캐싱과 라우팅을 추가하면 예산에 포함할 수 있는 차이를 만들 수 있습니다.