작성자 Claude API 비용: 출력 토큰이 입력보다 5배 비싼 이유
Claude 모델의 출력 토큰 비용이 입력 대비 5배 높은 기술적 원인을 분석합니다. Prefill과 Decoding 단계의 연산 차이로 발생하는 메모리 대역폭 한계와 이것이 실제 에이전트 운영 비용에 미치는 영향을 상세히 설명합니다.
출력 토큰 비용이 입력 토큰보다 비싼 이유
현재 카탈로그에 있는 모든 Claude 모델에서 출력 토큰 비용은 입력 토큰 비용의 5배입니다. 그 이유는 연산의 형태 때문입니다. 프롬프트를 읽는 과정은 모델을 한 번 통과하는 작업입니다. 반면 응답을 작성하는 과정은 토큰당 한 번씩 통과해야 하며, 각 단계는 이전 단계가 완료될 때까지 기다려야 합니다.
이 비율은 가격표의 모든 항목에서 동일하므로, 어떤 모델을 선택하더라도 전체 청구 금액에서 출력 비용이 차지하는 비중은 변하지 않습니다. 이는 작업 부하의 형태에 따라 결정됩니다. 60,000 토큰을 읽고 800 토큰으로 답변하는 에이전트 작업은 출력 비용이 거의 발생하지 않습니다. 반대로 2,000 토큰을 읽고 12,000 토큰을 작성하는 초안 작성 작업은 입력 비용이 거의 발생하지 않습니다. 두 사례 모두 2026년 10월 27일 기준으로 확인된 Anthropic의 공시 요금을 바탕으로 아래에서 계산되었습니다.
Prefill은 1회, Decoding은 토큰당 1회 실행
추론 서버는 비용 구조가 매우 다른 두 단계로 요청을 처리합니다. Prefill은 프롬프트를 읽고, Decoding은 응답을 작성합니다.
Prefill은 전체 프롬프트를 한 번에 처리합니다. 모든 프롬프트 토큰이 동일한 forward pass로 네트워크에 입력되므로, 어텐션(attention)과 피드포워드(feed-forward) 작업은 한 번에 수천 개의 토큰을 처리하는 소수의 대규모 행렬 곱셈이 됩니다. 모델 가중치를 메모리에서 한 번 읽는 것만으로 전체 프롬프트를 처리할 수 있습니다. 가속기의 행렬 연산 장치가 계속 작동하므로 Prefill은 일반적으로 연산 제한(compute-bound) 상태가 됩니다. 즉, 칩이 얼마나 빨리 곱셈을 수행할 수 있는지가 성능을 결정합니다. NVIDIA의 서빙 문서에서는 예외 상황을 언급합니다. 매우 짧은 Prefill이나 긴 접두사가 이미 캐시 히트(cache hit)인 경우에는 메모리 제한(memory-bound) 상태가 됩니다.
일반적인 Decoding은 이런 방식으로 작동할 수 없습니다. 두 번째 토큰은 첫 번째 토큰에 의존하기 때문입니다. 모델이 방금 생성한 토큰이 다음 단계의 입력 일부가 되므로, 각 단계는 순차적으로 실행되어야 합니다. 각 출력 토큰은 별도의 forward pass를 거치며, 각 pass마다 전체 모델 가중치와 KV cache(지금까지의 각 토큰에 대한 어텐션 상태를 저장한 key/value cache)를 고대역폭 메모리에서 읽어와 단 하나의 토큰을 생성합니다. 이로 인해 Decoding은 보통 메모리 제한 상태가 됩니다. 성능을 결정하는 것은 곱셈 속도가 아니라 가중치와 캐시된 상태를 얼마나 빨리 이동시킬 수 있는지이며, NVIDIA는 긴 컨텍스트에서 KV cache 읽기가 병목 현상을 일으킨다고 지적합니다. Prefill 단계에서 전체 프롬프트를 처리하는 데 사용되었던 동일한 가중치 트래픽이 Decoding 단계에서는 단 하나의 토큰을 얻는 데 사용됩니다.
Speculative decoding은 이 규칙을 깨지 않으면서 효율을 높입니다. 작은 초안 모델(draft model)이 여러 토큰을 미리 예측하면, 대규모 모델이 이를 한 번의 pass로 병렬 검증합니다. NVIDIA에 따르면 이 방식은 Decoding을 연산 제한 상태로 전환할 수 있습니다. 대규모 모델은 여전히 예측값을 순서대로 수락하고 틀린 첫 번째 지점에서 멈추므로, 긴 응답을 생성하려면 여전히 많은 pass가 필요합니다.
서빙 시스템은 배치(batching)를 통해 이에 대응합니다. 여러 요청을 함께 Decoding하면 가중치를 한 번 읽는 것으로 배치 내 각 요청에 대해 토큰 하나씩을 생성할 수 있습니다. 이것이 바로 Decoding을 경제적으로 수행할 수 있는 이유입니다. 여기서도 한계는 메모리입니다. 진행 중인 모든 요청은 각자의 KV cache를 유지하며, 이 캐시는 토큰이 생성될 때마다 커집니다. 캐시가 가속기를 가득 채우면 배치를 더 이상 늘릴 수 없습니다.
이 설명이 정확한 수치를 제공하는 것은 아니며, 5x라는 수치를 측정된 하드웨어 비율로 받아들여서는 안 됩니다. 이는 이러한 비대칭성을 고려하여 Anthropic이 책정한 가격입니다. 직접 확인할 수 있는 것은 방향성뿐이며, 확인하는 데는 약 1분 정도 소요됩니다.
입력과 출력 간의 격차를 직접 측정하기
Ubuntu 시스템에 도구를 설치합니다.
sudo apt update && sudo apt install -y curl jq moreutils이제 긴 답변을 요구하는 짧은 프롬프트를 스트리밍하고, 각 줄이 도착한 시간을 기록합니다.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s은 명령이 시작된 이후 경과된 시간을 각 줄 앞에 표시합니다. 출력에서 확인해야 할 두 가지 사항이 있습니다. 첫 번째 content_block_delta 줄은 첫 번째 토큰이 생성되기까지 걸린 시간이며, 이 시간 내에 모든 프리필(prefill) 과정이 완료됩니다. 그 이후의 모든 줄은 디코딩의 작은 단계이며, message_stop가 도착할 때까지 시간 기록은 계속 증가합니다.
이제 반대 상황을 확인해 봅니다. 프롬프트에 긴 문서를 넣고 답변을 몇 개의 토큰으로 제한합니다.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'첫 번째 델타는 짧은 프롬프트를 사용했을 때보다 더 오래 걸립니다. 읽어야 할 텍스트가 훨씬 많기 때문입니다. 첫 번째 토큰이 도착한 후에는 디코딩할 토큰이 몇 개 남지 않았으므로 응답이 거의 즉시 종료됩니다. 수만 개의 토큰이 입력되었지만 시계는 거의 움직이지 않았습니다. 수백 개의 토큰이 출력되는 동안 시계는 내내 작동했습니다.
모든 비스트리밍 응답은 청구 대상이 되는 숫자로 끝납니다.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}요청당 네 개의 필드를 모두 기록하십시오. output_tokens에는 사고 토큰이 포함되므로, 답변하기 전에 사고하는 모델은 해당 사고 과정을 출력 속도로 청구합니다. 프롬프트를 보내기 전에 가격을 책정하려면, POST /v1/messages/count_tokens을 사용하십시오. 대부분의 요청에 대해 동일한 요청 본문을 받아 모델을 실행하지 않고 추정치인 {"input_tokens": N}를 반환하며, 자체 속도 제한 내에서 무료로 제공됩니다. 이 도구는 Messages API가 허용하는 일부 본문을 거부합니다. 웹 검색, MCP 커넥터, url 또는 file 소스가 포함된 이미지나 문서 블록과 같은 대부분의 서버 도구가 이에 해당하므로, 이미지와 PDF를 계산할 때는 base64로 변환하여 보내야 합니다. API에서 비용이 발생하지 않는 부분은 이뿐만이 아니며, Claude API 중 청구되지 않는 부분을 확인하고 첫 프로젝트 예산을 책정하는 것이 좋습니다.
2026년 10월 기준 Claude의 백만 토큰당 요금
이 차트의 데이터
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]마지막 열은 출력 토큰을 입력 토큰으로 나눈 값이며, 모든 행에서 5로 표시됩니다. Haiku 4.5는 입력 시 $1, 출력 시 $5가 청구됩니다. Opus 5는 입력 시 $5, 출력 시 $25가 청구됩니다. 가장 고가인 Fable 5는 입력 시 $10, 출력 시 $50가 청구되며, Fable 5 요금의 가치에 관한 내용은 최상단 행을 무시하기 전에 읽어볼 가치가 있습니다. 제품군 내에서 상위 모델로 이동하면 양쪽 요금에 동일한 배수가 적용되므로, 총비용은 변하지만 입력과 출력의 비율은 그대로 유지됩니다.
Sonnet 5는 입력 시 $2, 출력 시 $10가 청구됩니다. Anthropic은 2026년 8월 31일까지 이 요금을 도입 가격으로 책정하고 9월 1일부터 각각 $3와 $15로 인상할 예정이었으나, 대신 $2와 $10를 표준 가격으로 확정했습니다. 인상안은 적용되지 않았으므로 아래의 모든 작업 예시에는 현재 적용되는 요금이 사용되었습니다.
이 페이지가 처음 게시된 이후 Anthropic은 더 새로운 모델들을 출시했으며, 현재 claude.com/pricing에는 위 네 가지 모델이 계속 이용 가능한 레거시 모델로 나열되어 있습니다. 새로운 모델들도 동일하게 5배 비율을 유지합니다. Opus 5.5는 $4와 $20, Sonnet 5.5는 $2와 $10, Fable 5.1은 $10와 $50가 청구됩니다. Haiku 5.5는 100,000 토큰까지는 $0.10와 $0.50가 청구되며, 그 이상은 $0.50와 $2.50로 인상됩니다. 아래에 나오는 60,000 토큰 에이전트 단계 비용은 이 기준선 아래에 있지만, 기록이 계속 늘어나는 에이전트는 결국 이 기준을 넘게 되며, Haiku 5.5의 두 가지 요금 체계가 실제 작업에 미치는 영향에서 이러한 비용 변화를 확인할 수 있습니다. Opus 5.5의 기본 입력 및 출력 요금은 Opus 5보다 20% 낮으므로, 아래의 모든 캐시되지 않은 Opus 5 수치는 Opus 5.5에서 20% 더 낮게 적용됩니다. 캐시된 수치는 더 크게 하락하는데, 이는 Opus 5.5가 캐시 적중 시 백만 토큰당 $0.20로 읽기 비용을 책정하여 Opus 5의 $0.50 대비 60% 절감되기 때문입니다. 아래에 나오는 Opus 5 기준 $0.0725인 캐시된 에이전트 단계 비용은 Opus 5.5에서 약 $0.047로, 약 35% 저렴합니다.
요금은 변동될 수 있으며, 이 페이지가 요금 확인의 기준이 되어서는 안 됩니다. claude.com/pricing이 공식 정보원입니다. 가격 변동에도 변하지 않는 것은 계산 방법입니다.
한 가지 주의 사항은 요금 자체가 아닌 Anthropic 요금표 하단의 주석에 있습니다. Anthropic의 요금 페이지에 따르면 Claude 4.7 이후 모델은 더 새로운 토크나이저를 사용하여 Sonnet 4.6 이전 모델보다 동일한 텍스트에 대해 약 30% 더 많은 토큰을 생성합니다. 백만 토큰당 가격만으로 두 모델을 비교하면 동일한 문서라도 새로운 모델에서 더 많은 토큰으로 계산되므로 새로운 모델이 더 불리해 보일 수 있습니다. 실제 완료된 작업당 비용으로 비교하고, 실제로 사용할 모델에 맞춰 실제 프롬프트를 계산하십시오. 토크나이저가 서로 다른 공급자 간에도 동일한 함정이 존재하므로, Claude와 ChatGPT 모두에서 실제 작업 비용 산정하기를 참고하는 것이 두 요금표를 나란히 놓고 비교하는 것보다 더 정확합니다. 백만 Claude 토큰이 실제 텍스트로 어느 정도 분량인지에 관한 내용은 해당 용량이 실제 환경에서 어떤 의미인지 설명합니다.
출력 비용이 청구서의 주된 비중을 차지하는 시점은 언제입니까?
출력 비용이 입력 비용의 5배로 책정되므로, 손익분기점을 머릿속으로 계산하기는 쉽습니다. 입력 토큰을 I, 출력 토큰을 O라고 합시다. 입력 비용은 I입니다. 출력 비용은 5 곱하기 O입니다. 5 곱하기 O가 I보다 클 때, 즉 입력 대 출력 토큰 비율이 5 대 1일 때 출력 비용이 전체 지출의 절반을 넘어서게 됩니다.
따라서 프롬프트가 응답보다 5배 이상 길다면 입력 비용이 더 큰 비중을 차지합니다. 그보다 짧다면 출력 비용이 더 큽니다.
이 차트의 데이터
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]비율이 100 대 1일 때 출력 비용은 지출의 4.8%를 차지하며, 이때는 프롬프트를 줄이는 작업만이 의미가 있습니다. 5 대 1일 때는 양쪽 비용이 동일합니다. 1 대 6일 때는 출력 비용이 96.8%를 차지하며 프롬프트 비용은 오차 범위 수준이 됩니다. 대부분의 사용자가 자신의 비율을 잘못 추측하므로, 최적화를 시작하기 전에 반드시 로그에서 실제 데이터를 확인하십시오.
에이전트 워크로드: 긴 컨텍스트 입력, 짧은 답변 출력
검색 에이전트 단계를 하나 수행한다고 가정해 보겠습니다. 검색된 문서와 대화 기록을 포함한 60,000 토큰의 입력과 800 토큰의 답변이 발생합니다. 이는 75 대 1의 비율로, 읽기 작업 후 쓰기 작업이 이어지는 모든 작업에서 일반적인 수치입니다.
이 차트의 데이터
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]모든 모델에서 출력 비용은 해당 호출의 6.25%를 차지하며, 이 비율은 전체 가격표에 걸쳐 고정되어 있습니다. 이 호출 비용은 Opus 5에서 $0.32, Sonnet 5에서 $0.128, Haiku 4.5에서 $0.064입니다. Opus 5로 하루에 이러한 단계를 200번 수행하면 하루 $64가 소요됩니다.
비용 구조를 분리해서 보면 절감 방안이 명확해집니다. 답변 길이를 800 토큰에서 400 토큰으로 줄여도 호출 비용의 약 3%만 절감됩니다. 반면, 프롬프트에서 불필요한 컨텍스트 20,000 토큰을 제거하면 전체 비용의 약 3분의 1을 절감할 수 있습니다. 읽기 작업 비중이 높은 에이전트에서 출력 길이를 줄이는 것은 거의 효과가 없는 노력입니다. 코딩 에이전트의 토큰이 실제로 소비되는 곳에서는 프롬프트를 채우는 요소들을 상세히 분석합니다.
생성 작업 부하: 짧은 프롬프트, 긴 초안
이제 반대의 경우를 살펴보겠습니다. 2,000 토큰의 브리핑과 12,000 토큰의 초안, 즉 1 대 6의 비율입니다.
이 차트의 데이터
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]출력 비용은 전체 청구액의 96.8%를 차지합니다. Opus 5는 초안당 $0.31의 비용이 발생하며, Haiku 4.5의 $0.062와 비교됩니다. 이 5배의 차이는 거의 전적으로 출력 측면에서 발생하며, 바로 이 지점이 저렴한 모델을 사용할 때 가장 큰 비용 절감 효과를 얻을 수 있는 부분입니다.
마지막 열은 Batch API를 통해 동일한 작업을 수행한 결과이며, 입력 및 출력 비용을 50% 절감합니다. Opus 5의 비용은 초안당 $0.155로 낮아집니다. Batch는 즉각적인 처리가 아닌 비동기 방식으로 작동합니다. Anthropic에 따르면 대부분의 배치는 1시간 이내에 완료되지만, 24시간이 지나도 처리 중인 배치는 만료됩니다. 이때까지 도달하지 못한 요청은 메시지 없이 만료 처리되며 비용도 청구되지 않습니다. 따라서 이 방식은 야간 보고서 생성이나 대량 분류 작업에는 적합하지만, 만료된 항목에 대한 재제출 단계가 필요합니다. 사용자가 실시간으로 대기해야 하는 작업에는 적합하지 않습니다.
모델 라우팅은 에이전트 단계에서보다 이러한 작업에서 훨씬 더 큰 비용 효율을 발휘합니다. 작업의 상세한 부분이 텍스트 재형식화나 이미 승인된 개요 확장과 같이 기계적인 성격이라면, 저렴한 모델은 해당 토큰을 5분의 1 가격으로 생성합니다. Opus, Sonnet, Haiku 선택하기에서 품질의 기준점이 실제로 어디에 있는지 다룹니다.
입력에만 적용되는 캐싱 할인
프롬프트 캐싱은 프롬프트의 접두사를 서버에 저장하며, 이를 다시 읽을 때 입력 요금의 일부만 부과합니다. 2026년 10월 27일 기준으로, 5분 캐시 작성 시 기본 입력 요금의 1.25배, 1시간 캐시 작성 시 2배, 그리고 이 페이지에 명시된 모델에서 캐시 적중 시 읽기 요금은 0.1배가 적용됩니다. 최신 모델의 경우 읽기 적중 요금이 더 저렴하여, Opus 5.5와 Sonnet 5.5는 0.05배, Fable 5.1은 0.025배가 적용됩니다.
출력은 이 할인 대상이 아닙니다. 캐시된 출력은 존재하지 않습니다. 프롬프트의 상당 부분이 캐시 적중으로 처리되더라도, 모델이 작성하는 모든 토큰은 매번 전체 출력 요금으로 청구됩니다.
Opus 5에서 60,000개의 입력 토큰 중 55,000개를 활성 캐시에서 불러오는 동일한 에이전트 단계를 예로 들어보겠습니다.
이 차트의 데이터
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]해당 호출 비용은 $0.32에서 $0.0725로 감소합니다. 출력 비용은 변하지 않아, 이전에는 $0.02였고 이후에도 $0.02입니다. 캐싱은 전체 청구 금액을 줄이고 비용 구조를 변화시킵니다. 해당 호출에서 출력 비용이 차지하는 비중은 6.25%였습니다. 이제는 그 비중이 4분의 1을 넘어서게 되어, 다음에 어떤 비용 절감 수단을 우선적으로 고려해야 할지가 달라집니다.
첫 번째 호출에서 작성 비용이 발생합니다. 5분 캐시 작성 비용은 기본 입력 요금의 1.25배이므로, 단 한 번의 적중만으로도 비용을 상쇄합니다. 1시간 캐시 작성 비용은 2배이므로 두 번의 적중이 필요합니다. 작성 및 읽기 배율과 캐싱의 손익 분기점에서 해당 계산 과정을 확인할 수 있습니다.
제어 가능한 네 가지 레버
max_tokens를 모델 최대치가 아닌 p95 출력 길이에 맞춥니다.- 장황한 단계는 더 저렴한 모델로 라우팅합니다.
- 즉각적인 응답이 필요 없는 작업은 배치(batch)로 처리합니다.
- 응답 길이를 늘리는 불필요한 지시사항을 삭제합니다.
max_tokens은 엄격한 상한선이며, 이를 높게 설정한다고 해서 그 자체로 비용이 발생하지는 않습니다. 요금은 생성된 토큰에 대해서만 부과되며 상한선 설정과는 무관하기 때문입니다. 관대한 상한선은 응답이 잘못되었을 때 발생하는 제한을 제거하는 역할을 합니다. 로그에서 output_tokens 분포를 추출하여 상한선을 95번째 백분위수보다 약간 높게 설정하고, stop_reason: "max_tokens"은 응답을 이어가거나 재시도하는 방식으로 코드에서 처리하십시오. 감지된 잘림(truncation)은 비용을 지불하고 버려야 하는 4,000 토큰 분량의 장황한 응답보다 저렴합니다. 사고 과정(thinking) 또한 output_tokens에 포함되어 max_tokens에 합산되므로, 동일한 근거를 바탕으로 상한선을 정하십시오. 적응형 사고 모델을 사용하는 경우, 사고 과정이 응답 길이를 계속 잠식한다면 노력 수준(effort level)을 낮추십시오.
라우팅은 단계의 비용이 판단력보다는 분량에서 발생할 때 효과적입니다. 중요한 결정은 강력한 모델에 맡기고, 단순 타이핑 작업은 더 저렴한 모델에 넘기십시오. 중요한 지표는 작업 완료당 비용이므로, 라우팅된 버전을 자체 평가 세트로 먼저 측정해야 합니다. 위 에이전트 단계의 경우, Haiku 4.5 모델로 두 번 시도하는 비용은 $0.128로, Opus 5 모델 한 번 시도 시 발생하는 $0.32보다 저렴하여 재시도 비용을 충분히 상쇄합니다. 단, 아무도 알아채지 못한 오답은 비용 절감의 대상이 될 수 없습니다.
배치는 출력 비용을 할인받을 수 있는 유일한 수단입니다. 양방향 모두 50% 할인이 적용되며, 대부분의 배치는 한 시간 이내에 완료됩니다. 24시간 제한 내에 만료되는 작업을 재제출할 수 있다면 예약된 모든 작업이 배치 대상이 됩니다.
마지막 레버는 사람들이 간과하는 부분입니다. "철저하게 작성하라"거나 "추론 과정을 설명하라"와 같은 문구는 모든 호출에서 출력 길이를 결정짓습니다. 이를 원하는 형태로 대체하십시오. 예를 들어 "최대 세 문장으로 답변하라"거나 "서론 없이 JSON 객체만 반환하라"와 같이 수정합니다. 모든 응답에 300 토큰을 추가하는 시스템 프롬프트는 프롬프트 자체에 포함된 300 토큰보다 5배 더 많은 비용이 듭니다. 실행 중인 에이전트의 비용 제어하기에서는 모니터링 측면을 다루며, 사용 패턴에 따라 API와 정액제 중 무엇이 더 저렴한지는 토큰당 비용을 일주일 내내 조정하기 전에 결정하는 것이 좋습니다. 개발자 한 명의 경우, 이는 주로 Claude Pro의 월 $20 요금제와 그에 따른 사용량 제한이 본인의 작업량을 감당할 수 있는지의 문제입니다. 세션 도중 이미 제한에 도달하고 있다면 어떤 작업이 병목 현상을 일으키는지 파악하는 것이 우선입니다. 해결책은 더 작은 모델 사용, 더 가벼운 컨텍스트, 추가 사용 크레딧 확보, 또는 해당 작업을 종량제 API로 옮기는 것입니다. 종량제 API가 더 저렴한 대안이라면 더 낮은 요금제로 변경하거나 해지하는 것을 고려하십시오. 이미 지불한 달의 서비스는 그대로 유지되므로 변경에 따른 추가 비용은 없습니다. Pro 요금제와 비교하는 대상이 API가 아닌 ChatGPT라면, 두 구독 모델의 가격 비교를 통해 코딩 작업에 무엇이 더 경제적인지 확인할 수 있습니다. 개발자 개인이 아닌 팀 단위의 질문이라면, Claude Enterprise는 사용자당 요금과 동일한 API 요율의 종량제 토큰 비용을 결합함을 유의하십시오. 이 페이지의 모든 레버는 해당 청구서의 종량제 부분에 동일하게 적용됩니다.
FAQ
출력 토큰이 입력 토큰보다 비싼 이유는 무엇입니까?
토큰당 가속기 사용 시간이 훨씬 더 많이 소요되기 때문입니다. 프롬프트는 전체 내용을 한 번의 순방향 패스(forward pass)로 처리하므로 모델 가중치를 한 번만 읽으면 수천 개의 토큰을 처리할 수 있으며, 하드웨어는 주로 곱셈 처리량(multiply throughput)에 의해 제한됩니다. 일반적인 디코딩 과정에서는 응답이 토큰 단위로 하나씩 생성되는데, 각 토큰마다 모델 가중치와 점점 커지는 KV 캐시를 다시 읽는 순방향 패스가 필요하므로 하드웨어는 주로 메모리 대역폭에 의해 제한됩니다. 추측 디코딩(speculative decoding)과 같은 기술이 이 격차를 줄여주기는 하지만 완전히 없애지는 못합니다. Anthropic은 현재 전체 카탈로그에 대해 Haiku 5.5부터 Fable 5.1까지 출력 비용을 입력 비용의 5배로 책정하고 있습니다.
프롬프트 캐싱을 사용하면 출력 토큰 비용이 저렴해집니까?
아니요. 프롬프트 캐싱은 입력에만 적용됩니다. 2026년 10월 27일 기준으로 대부분의 모델에서 캐시 읽기 비용은 기본 입력 요금의 0.1배(Opus 5.5 및 Sonnet 5.5는 0.05배, Fable 5.1은 0.025배)이며, 캐시 쓰기 비용은 5분 유지 시 1.25배, 1시간 유지 시 2배입니다. 출력은 캐시 사용 여부와 관계없이 모든 호출에서 정액 요금이 청구됩니다. 이것이 바로 캐싱이 청구서의 규모뿐만 아니라 구성까지 바꾸는 이유입니다. 입력 비용이 줄어들면 출력 비용이 전체 비용에서 차지하는 비중이 커지기 때문입니다.
max_tokens을 높게 설정하면 응답이 짧게 돌아올 경우 비용이 더 발생합니까?
아니요. 모델이 실제로 생성한 토큰에 대해서만 요금이 청구되므로 max_tokens는 예약이 아닌 상한선입니다. 하지만 응답이 무한정 길어지는 것을 막는 유일한 강제 제한이므로 여전히 중요합니다. 관찰된 output_tokens의 95번째 백분위수보다 약간 높게 설정한 다음, 응답이 조용히 잘리는 것을 방지하기 위해 stop_reason: "max_tokens"를 코드 수준에서 처리하십시오.
입력 대 출력 토큰 비율은 어떻게 확인합니까?
모든 응답의 usage 객체에서 input_tokens, output_tokens, cache_read_input_tokens, cache_creation_input_tokens을 로그로 기록한 뒤, 일주일 동안의 총합을 나누어 계산하십시오. 입력 대 출력 비율이 5:1을 넘는다면 비용의 대부분이 프롬프트에서 발생하므로 안정적인 부분을 캐싱하고 나머지를 줄이십시오. 그보다 낮다면 비용의 대부분이 응답에서 발생하므로 응답 길이를 제한하고, 응답을 많이 생성하는 단계를 더 저렴한 모델이나 Batch API로 옮기십시오.