Claude 청구 비용은 대부분 출력 토큰이 아닌 입력 토큰에 의해 발생합니다. API는 무상태(stateless)이므로, 매 턴마다 전체 대화 기록(시스템 프롬프트, 도구 정의, 붙여넣은 문서, 모든 이전 메시지)을 다시 보냅니다. 긴 에이전트 루프나 Claude Code 세션에서는 이렇게 다시 보내는 컨텍스트가 빠르게 쌓이고, 모든 요청에 대해 비용을 지불하게 됩니다. 출력은 청구서에서 작은 부분을 차지합니다.
따라서 실제로 청구 비용을 줄이는 방법은 전송하는 내용을 줄이거나, 토큰당 요율을 낮추거나, 더 이상 필요 없는 컨텍스트를 다시 보내지 않도록 하는 것입니다. 이 가이드에서는 구체적인 방법들을 소개합니다. 먼저 자체적인 기능들을 살펴보고, 다음으로 다른 접근 방식을 취하는 타사 프록시(pxpipe)를 소개하며, 마지막으로 아직 개발 중일 때 모의(mock) API를 활용하는 방법을 설명합니다.
가격 책정의 기본 사항(측정 방식, 토큰이란 무엇인지, 캐싱 및 일괄 처리가 어떻게 청구되는지)을 먼저 알고 싶다면, 저희 Claude API 비용 설명서를 참조하십시오. 이 게시물은 비용 절감에 중점을 두므로, 가격 책정 이론을 자세히 재설명하지는 않겠습니다.
방법 1: 프롬프트 캐싱
프롬프트 캐싱은 대부분의 에이전트 워크로드에서 가장 높은 수익을 창출하는 변경 사항입니다. 안정적인 접두사(시스템 프롬프트, 도구 정의, 긴 참조 문서)를 캐시 가능으로 표시하면 Claude가 이를 저장합니다. 동일한 바이트로 시작하는 다음 요청에서는 전체 입력 비용을 지불하고 다시 처리하는 대신 캐시에서 읽게 됩니다.
경제적 효과는 강력합니다. 캐시 읽기 비용은 기본 입력 요율의 약 0.1배이므로, 캐시된 부분에 대해 최대 ~90%를 절약할 수 있습니다. 캐시 쓰기 비용은 일반 입력 토큰보다 더 비쌉니다. 5분 TTL(Time-To-Live)의 경우 1.25배, 1시간 TTL의 경우 2배입니다. 이러한 쓰기 프리미엄 때문에 캐싱은 접두사를 재사용할 때만 이점을 제공합니다. 손익분기점은 5분 캐시의 경우 대략 2회 요청, 1시간 캐시의 경우 약 3회 요청입니다. 접두사가 한 번 호출되고 버려진다면 캐싱은 비용을 발생시키지만, 수십 번 호출된다면 첫 번째 쓰기 이후에는 거의 무료나 다름없습니다.
문제는 캐싱이 바이트 수준의 접두사 일치라는 점입니다. 캐시된 영역 내에서 어떤 변경이 발생하면 캐시가 무효화되고 새로 전체 비용으로 쓰기가 강제됩니다. 일반적인 원인은 "안정적인" 부분에 몰래 들어가는 변수입니다. 시스템 프롬프트의 타임스탬프, 세션 ID, 요청 카운터, 재정렬된 도구 목록 등이 그 예입니다. 사용자에게는 안정적으로 보이지만 캐시에게는 새로운 바이트로 읽힙니다.
캐싱이 실제로 작동하는지 확인하십시오. 응답에서 usage.cache_read_input_tokens를 확인하십시오. 동일한 접두사를 공유하는 반복 요청에서 이 숫자는 크고 0이 아니어야 합니다. 만약 0에 고정되어 있다면, 접두사 내의 무언가가 모든 호출에서 변경되고 있으며, 캐시되었다고 생각하면서도 전체 비용을 지불하고 있는 것입니다. 캐시 작동 방식에 대한 자세한 내용은 프롬프트 캐싱이란 무엇이며 어떻게 작동하는지를 참조하십시오.
방법 2: 모델 크기 적정화
가장 흔한 과소비는 작업에 필요한 것보다 더 큰 모델을 실행하는 것입니다. Claude는 명확한 가격 계층을 제공하며, 하나의 모델로 기본 설정하는 대신 작업별로 라우팅하는 것이 종종 가장 큰 비용 절감으로 이어질 수 있습니다.
다음은 100만 토큰당 현재 가격입니다:
| 모델 | 모델 ID | 입력 | 출력 | 컨텍스트 윈도우 |
|---|---|---|---|---|
| Fable 5 | claude-fable-5 |
$10 | $50 | 1M |
| Opus 4.8 | claude-opus-4-8 |
$5 | $25 | 1M |
| Sonnet 5 | claude-sonnet-5 |
$3 ($2 도입 할인) | $15 ($10 도입 할인) | 1M |
| Haiku 4.5 | claude-haiku-4-5 |
$1 | $5 | 200K |
이 표에서 몇 가지를 알 수 있습니다. Fable 5는 Opus 4.8보다 입력과 출력 모두에서 2배 비싸며, 이는 가장 비싼 광범위하게 출시된 모델입니다. Opus 4.8은 롱 컨텍스트 프리미엄 없이 전체 1M 토큰 컨텍스트 윈도우를 제공하므로, 대규모 코드베이스를 입력하는 데 추가 비용이 들지 않습니다. Sonnet 5는 2026년 8월 31일까지 도입 할인 가격인 $2/$10로 운영되며, 이후 $3/$15로 변경됩니다. Haiku 4.5는 $1/$5로 가장 낮은 가격이며, 더 작은 200K 윈도우를 가집니다.
작업에 맞는 모델을 선택하십시오:
- **Fable 5**: 추가 기능이 실제로 결과에 변화를 가져오는 가장 어려운 장기 추론 작업용. Opus로도 충분한데 Fable을 기본으로 사용하는 것은 팀이 불필요하게 비용을 두 배로 늘리는 가장 흔한 방법입니다.
- **Opus 4.8**: 대부분의 에이전트 및 코딩 작업용. Claude Code 및 도구 사용이 많은 루프에 합리적인 기본값입니다.
- **Sonnet 5**: 낮은 요율로 좋은 품질이 필요한 대규모 프로덕션 트래픽용.
- **Haiku 4.5**: 간단하거나 속도에 민감한 작업(분류, 추출, 라우팅, 짧은 답변)용.
Fable 5에 대한 한 가지 청구 세부 사항: 안전 분류기가 요청을 거부하는 경우, 베타 fallbacks 매개변수를 통해 해당 턴을 Opus 4.8로 재라우팅할 수 있으며, 재라우팅된 턴은 Opus 요율로 청구됩니다. 이는 일반적으로 예상치 못한 요금이 아니라 할인이며, Fable 트래픽에 Opus 가격으로 청구되는 라인이 나타날 수 있다는 점을 알아두는 것이 좋습니다.
두 가지 고가 계층에 대한 더 깊이 있는 비용 분석은 Opus 4.8 가격, Fable 5 가격, 그리고 2배의 가치가 있을 때를 위한 Fable 5 vs Opus 4.8 비교를 참조하십시오. 평가하는 동안 낮은 비용 또는 무료로 상위 계층을 사용해보고 싶다면, Opus 4.8 무료 사용 방법과 Fable 5 API 호출 방법을 다루고 있습니다.
방법 3: 배치 API (50% 할인)
작업이 실시간 답변을 필요로 하지 않는다면, 배치 API는 모든 토큰 비용을 절반으로 줄여줍니다. /v1/messages/batches로 작업을 보내면 비동기적으로 실행되며, 결과를 받을 수 있습니다. 대부분의 배치는 한 시간 이내에 완료되며, 최대 24시간의 제한이 있습니다. 50% 할인은 배치에 사용된 모든 토큰(입력 및 출력)에 적용됩니다.
적합한 상황은 제한적이지만 가치가 있습니다. 배치는 기다릴 수 있는 작업에 적합합니다:
- 테스트 세트 전반에 걸쳐 평가 실행.
- 백로그에 대한 대량 분류 또는 추출.
- 기존 기록에 대한 요약, 태그 또는 임베딩 관련 메타데이터 백필.
- 몇 분의 지연 시간이 비용을 발생시키지 않는 모든 대규모 오프라인 작업.
Claude 지출의 절반이 현재 동기 엔드포인트를 통해 실행되는 야간 처리라면, 이를 배치로 옮김으로써 품질 변화 없이 해당 절반에서 직접 50%를 절감할 수 있습니다. 이는 어차피 사용하지 않던 지연 시간만이 유일한 절충점이므로, 이 목록에서 가장 쉽게 이해할 수 있는 비용 절감 방법입니다.
방법 4: 노력(effort), max_tokens, count_tokens 조정
세 가지 설정이 단일 요청에 소비될 수 있는 비용을 제어하며, 이를 의도적으로 설정하면 비용이 불필요하게 증가하는 것을 방지할 수 있습니다.
**노력(Effort).** output_config.effort 매개변수는 low, medium, high, xhigh, 또는 max를 사용합니다. 이는 모델이 답변하기 전에 얼마나 생각하는지를 제어하며, 생각 토큰은 비용이 청구됩니다. 낮은 노력은 더 적은 생각 및 출력 토큰을 의미합니다. 습관적으로 high로 실행되는 많은 작업이 medium 또는 low에서 더 적은 비용으로 동일한 답변을 생성합니다. 한두 단계 낮춰서 품질이 유지되는지 확인해 보십시오.
**max_tokens.** 이는 출력에 대한 엄격한 상한선입니다. 짧을 예정이었던 응답의 비용을 낮추지는 않지만, 폭주하는 경우를 막아줍니다. 예를 들어, JSON 객체를 원했는데 모델이 4,000 토큰짜리 에세이를 출력하기로 결정하는 경우입니다. 작업에 대한 합리적인 한계를 설정하여 하나의 장황한 응답이 비용 항목을 폭주시킬 수 없도록 하십시오.
**count_tokens.** 전송 전에 비용을 추정하십시오. count_tokens 엔드포인트는 Claude 자체 토크나이저를 사용하여 요청이 얼마나 많은 입력 토큰을 청구할지 정확하게 알려줍니다. 이를 위해 tiktoken을 사용하지 마십시오. Tiktoken은 OpenAI의 토크나이저이며 Claude보다 약 15~20% 적게 토큰을 계산하므로, 이를 기준으로 예산을 책정하면 실제 청구서가 추정치보다 상당히 높아질 수 있습니다. 요청당 예산에 근접하여 실행 중이라면, count_tokens는 비용이 발생하기 전에 과도한 프롬프트를 잡아내는 방법입니다.
방법 5: 다시 보내는 컨텍스트 다듬기
API는 무상태이므로, 긴 에이전트 루프는 매 턴마다 전체 기록을 다시 보내며, 대부분의 기록은 30번째 턴에 이르러서는 더 이상 필요 없는 부분이 됩니다. 이미 처리한 도구 출력, 지나간 탐색, 한 번 읽은 파일 등이 그 예입니다. 사용자는 이 모든 것을 다시 보내는 데 전체 입력 비용을 계속 지불하게 됩니다.
두 가지 서버 측 기능이 이를 자동으로 정리해 줍니다:
- **컨텍스트 편집** (
clear_tool_uses_20250919)은 다시 보내지는 컨텍스트에서 오래된 도구 결과를 삭제하여, 이후 모든 턴에서 이전 도구 호출에 대한 비용이 청구되지 않도록 합니다. - **압축** (
compact_20260112)은 오래된 기록을 더 짧은 형태로 요약하여, 긴 대화가 전체 원본 기록을 계속 전달하지 않도록 합니다.
둘 다 서버 측에서 실행되므로, 사용자가 직접 요약기를 만들거나 메시지 배열을 수동으로 잘라낼 필요가 없습니다. 특히 장기 실행되는 Claude Code 세션의 경우, 이는 작업 중간에 컨텍스트 제한에 도달하는 것과 동일한 압력입니다. Claude Code 토큰 윈도우 및 재설정에 대한 저희 가이드에서 이것이 에디터에서 어떻게 작동하는지 다루고 있습니다. 청구에 대한 핵심은 간단합니다. 모델이 더 이상 필요로 하지 않는 컨텍스트를 다시 보내는 데 비용을 지불하지 마십시오.
더 나아가기: pxpipe로 컨텍스트를 이미지로 렌더링
자체적인 방법들은 모두 보내는 토큰을 줄이거나 재평가합니다. pxpipe는 다른 방향에서 동일한 입력 토큰 비용 문제를 해결합니다. 즉, 크고 안정적인 컨텍스트를 이미지로 렌더링하여 토큰화 비용을 절감합니다.
**무엇인가.** pxpipe는 클라이언트와 Anthropic API 사이에 위치하는 로컬 프록시(MIT 라이선스, TypeScript로 작성)입니다. ANTHROPIC_BASE_URL을 pxpipe로 설정하면, 요청이 나갈 때마다 이를 검사합니다.
**비용 절감 방식.** 밀도 높은 텍스트는 토큰당 비용이 비쌉니다. pxpipe는 요청의 크고 안정적인 부분(시스템 프롬프트, 도구 문서, 이전 기록)을 요청이 컴퓨터를 떠나기 전에 압축된 PNG 이미지로 재작성합니다. 밀도 높은 콘텐츠는 이미지-토큰당 약 3.1자의 문자를 처리하는 반면 텍스트-토큰당 약 1자의 문자를 처리하므로, 해당 콘텐츠를 이미지화하면 입력 토큰을 크게 절감할 수 있습니다. 프로젝트 보고서에 따르면 약 48k 문자 시스템 프롬프트 및 도구 문서 예시가 텍스트로는 약 25k 토큰이었으나 이미지로는 약 2.7k 이미지 토큰으로 줄어들었습니다. 중요한 점은 수익성 게이트를 사용한다는 것입니다. 즉, 토큰 계산에서 실제로 이득이 되는 콘텐츠만 이미지화하며, 희소한 산문은 텍스트로 변경 없이 통과됩니다.
**설치 및 실행.** 두 가지 명령:
npx pxpipe-proxy
이것은 127.0.0.1:47821에서 프록시를 시작합니다. 그런 다음 Claude Code를 이 프록시로 연결합니다:
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
**모델 지원.** 기본적으로 pxpipe는 claude-fable-5 및 GPT 5.6에 대한 요청을 이미지화합니다. Opus 4.7/4.8 및 GPT 5.5는 프로젝트에서 이미지화된 컨텍스트를 측정 가능한 수준으로 더 나쁘게 읽는다고 보고하기 때문에 옵트인 방식입니다. PXPIPE_MODELS 환경 변수(또는 프록시 URL의 대시보드)를 사용하여 이를 활성화할 수 있습니다. 그 외의 모든 것은 변경 없이 통과됩니다.
**보고된 절감 효과.** 이는 프로젝트 자체의 보고된 벤치마크 수치이며, 저희가 독립적으로 검증한 수치는 아닙니다. pxpipe는 프로덕션 스냅샷에서 59% 절감 효과, 13,709건의 요청에서 100달러 청구서가 약 41달러로 감소, SWE-bench Lite 파일럿에서 요청 크기가 -65% 감소했다고 보고했습니다. 이를 공급업체 벤치마크로 간주하고 자체 트래픽에서 확인하십시오.
**솔직한 절충점.** 이미지화는 공짜가 아닙니다.
- **프롬프트 캐싱과 상호 작용.** 이미지화는 요청 바이트를 변경하며, 캐시된 접두사는 바이트 일치입니다. 캐싱과 이미지화는 모두 동일한 입력 토큰 비용을 목표로 하므로 서로 충돌할 수 있습니다. 즉, 이미지화를 성공하게 만드는 변경이 캐시된 영역을 변경하는 원인이 될 수 있습니다. 어떤 접근 방식이 더 많은 절감 효과를 가져오는지는 특정 접두사 및 재사용 패턴에 따라 달라집니다. 둘이 중첩된다고 가정하기보다 자체 워크로드에서 둘 다 측정하십시오.
- **모델은 비전을 통해 이미지화된 컨텍스트를 읽습니다.** 프로젝트 자체에서 밀도 높은 문자열(긴 16진수 ID, 정확한 토큰)이 잘못 읽힐 수 있으며, 누락이 오류가 아니라 무음으로 발생할 수 있다고 경고합니다. 절감 효과를 신뢰하기 전에 자체 작업에서 출력 품질을 확인하십시오.
- **귀하의 트래픽을 처리하는 타사 프록시입니다.** 로컬에서 실행되므로 좋지만, 여전히 요청 경로에 위치합니다. 프로덕션 트래픽에 적용하기 전에 자체 보안 정책에 따라 평가하십시오.
컨텍스트가 크고 안정적이며 밀도 높은 블록으로 지배되고 품질을 검증할 수 있다면 pxpipe는 테스트할 가치가 있습니다. 희소하거나 캐시 친화적인 워크로드의 경우, 자체적인 방법들만으로도 대부분의 이득을 얻을 수 있습니다.
개발 중 낭비되는 개발 및 테스트 토큰 절감
위의 어떤 방법도 통합을 구축하는 동안 실제 유료 토큰을 소모한다는 사실을 바꾸지는 않습니다. Apidog는 프로덕션 Claude 청구 비용을 낮추지 않으며, 낮춘다고 주장하지도 않습니다. 비용을 절감하는 부분은 개발 및 테스트 루프입니다.
개발 중에 라이브 Anthropic API에 대해 통합을 실행할 때마다 각 반복은 실제 토큰 비용을 발생시킵니다. 실패한 실행, 재시도, 모든 푸시에서 실행되는 CI 작업 등이 그 예입니다. 프롬프트 형태, 파싱 로직, 오류 처리 등을 반복하는 동안 이러한 지출은 쌓이며, 이 중 어떤 것도 실제 모델을 통해 검증할 필요가 없습니다.
대신 Apidog에서 Anthropic 응답을 모의(Mock)하십시오. 호출하는 Claude 엔드포인트에 대한 요청 및 응답 계약을 정의한 다음, 테스트와 CI를 모의 API로 연결하십시오. 루프는 예상하는 형태를 반환하는 결정론적 가짜를 대상으로 실행되며, 파이프라인 검증에 토큰을 전혀 소비하지 않습니다. 또한 동일한 위치에서 요청/응답 계약을 설계하고 문서화할 수 있으므로, 팀원들이 토큰을 소비하기 전에 인터페이스에 동의할 수 있습니다. 이는 프로덕션 비용이 아니라 개발 중 낭비되는 개발 및 테스트 토큰을 절감합니다. 이것이 솔직한 범위입니다.
방법들을 조합하여 활용
이 방법들은 양자택일이 아닙니다. 가장 큰 절감 효과는 조합을 통해 얻을 수 있습니다:
- **안정적인 접두사(prefix)를 캐싱합니다.** 시스템 프롬프트, 도구, 문서.
cache_read_input_tokens가 0이 아닌지 확인하십시오. - **작업별로 모델을 라우팅합니다.** Opus 4.8을 기본값으로 사용하고, Fable 5는 결과가 실제로 달라지는 경우에만, Sonnet 5는 대량 처리용으로, Haiku 4.5는 간단한 작업용으로 사용합니다.
- **오프라인 작업을 배치 처리합니다.** 지연 시간에 민감하지 않은 모든 작업은 50% 할인된
/v1/messages/batches로 보냅니다. - **각 요청의 한계를 설정합니다.**
effort를 적정 크기로 조정하고,max_tokens에 상한선을 두며,count_tokens로 추정합니다. - **다시 보내는 컨텍스트를 다듬습니다.** 컨텍스트 편집 및 압축을 통해 긴 루프가 더 이상 필요 없는 기록에 비용을 지불하지 않도록 합니다.
- **이미지화가 도움이 되는지 테스트합니다.** 컨텍스트가 크고 밀도 높다면, 자체 접두사에서 pxpipe와 캐싱을 비교 벤치마킹하십시오.
- **개발 중에는 모의(mock) 기능을 사용합니다.** 개발 및 테스트 루프를 유료 사용량에서 제외하십시오.
대부분의 비용 절감은 캐싱과 모델 라우팅에서 발생하므로, 이 두 가지부터 시작하십시오. 각 변경 후에는 측정하십시오. 왜냐하면 실제로 중요한 숫자는 실제 청구서이기 때문입니다.
자주 묻는 질문
**Claude 청구서에서 입력 토큰과 출력 토큰 중 어느 것이 더 비쌉니까?** 토큰당 비용은 모든 모델에서 출력이 입력보다 더 비쌉니다. 그러나 에이전트 및 코딩 워크로드의 경우, 무상태 API가 매 턴마다 전체 대화 기록을 다시 보내도록 요구하므로 입력 측이 일반적으로 더 큰 비용을 차지합니다. 이것이 가장 큰 비용 절감 방법들이 입력 토큰을 목표로 하는 이유입니다.
**프롬프트 캐싱과 배치 API 중 어느 것이 더 큰 비용 절감 효과를 가져옵니까?** 워크로드에 따라 다릅니다. 캐싱은 대화형 트래픽의 반복되는 접두사에 대해 최대 ~90%를 절약하므로, 시스템 프롬프트를 재사용하는 채팅 및 에이전트 루프에 유리합니다. 배치는 모든 것에 50% 할인을 제공하지만, 비동기적으로 실행할 수 있는 작업에만 해당됩니다. 많은 팀이 둘 다 사용합니다. 대화형 경로는 캐시하고, 오프라인 작업은 배치 처리합니다.
**모든 것을 Fable 5로 기본 설정해야 합니까?** 아니요. Fable 5는 Opus 4.8보다 2배 비싸며 가장 어려운 장기 추론 작업용입니다. 대부분의 에이전트 및 코딩 작업에는 Opus 4.8이 절반의 입력 및 출력 요율로 동일한 결과를 제공합니다. Opus로도 충분한데 Fable을 기본으로 사용하는 것은 가장 흔한 과소비입니다.
**pxpipe는 프롬프트 캐싱과 함께 사용할 수 있습니까?** 깔끔하게 병용되지 않습니다. 이미지화는 요청 바이트를 변경하며, 캐싱은 바이트 수준의 접두사 일치이므로, 둘은 동일한 입력 토큰 비용을 목표로 하며 서로 충돌할 수 있습니다. 실제 접두사에서 둘 다 테스트하고 어떤 것이 더 많은 절감 효과를 가져오는지 측정하십시오. 둘이 중첩된다고 가정하지 마십시오.
**Apidog가 프로덕션 Claude 비용을 줄여줍니까?** 아니요. Apidog는 Anthropic API를 모의(mock)하여, 개발하는 동안 테스트 및 CI가 유료 토큰을 소모하는 대신 가짜 API를 사용하도록 합니다. 이는 프로덕션 비용이 아니라 개발 및 테스트 비용을 절감합니다.