Claude 모델 출력 토큰 비용이 5배 비싼 이유

출력 토큰 비용이 입력 토큰보다 비싼 이유

현재 카탈로그에 있는 모든 Claude 모델에서 출력 토큰 비용은 입력 토큰 비용의 5배입니다. 그 이유는 연산의 형태 때문입니다. 프롬프트를 읽는 과정은 모델을 한 번 통과하는 작업입니다. 반면 응답을 작성하는 과정은 토큰당 한 번씩 통과해야 하며, 각 단계는 이전 단계가 완료될 때까지 기다려야 합니다.

이 비율은 가격표의 모든 항목에서 동일하므로, 어떤 모델을 선택하더라도 전체 비용에서 출력 토큰이 차지하는 비중은 변하지 않습니다. 이는 작업 부하의 형태에 따라 결정됩니다. 60,000개의 토큰을 읽고 800개의 토큰으로 답변하는 에이전트 작업은 출력 비용이 거의 발생하지 않습니다. 반대로 2,000개의 토큰을 읽고 12,000개의 토큰을 작성하는 초안 작성 작업은 입력 비용이 거의 발생하지 않습니다. 두 경우 모두 아래에서 Anthropic의 2026년 8월 공시 요금을 기준으로 계산합니다.

Prefill은 1회 실행, Decoding은 토큰당 1회 실행

추론 서버는 비용 구조가 매우 다른 두 단계로 요청을 처리합니다. Prefill은 프롬프트를 읽고, Decoding은 응답을 작성합니다.

Prefill은 전체 프롬프트를 한 번에 처리합니다. 모든 프롬프트 토큰이 동일한 순전파(forward pass) 과정에서 네트워크로 입력되므로, 어텐션과 피드포워드 작업은 한 번에 수천 개의 토큰을 처리하는 소수의 대규모 행렬 곱셈으로 이루어집니다. 모델 가중치를 메모리에서 한 번 읽는 것만으로 전체 프롬프트를 처리할 수 있습니다. 가속기의 행렬 연산 장치가 계속 작동하므로 Prefill은 연산 제한(compute-bound) 상태가 됩니다. 즉, 칩이 얼마나 빠르게 곱셈을 수행할 수 있는지가 성능을 결정합니다.

Decoding은 토큰 2가 토큰 1에 의존하기 때문에 이런 방식으로 작동할 수 없습니다. 모델이 방금 생성한 토큰이 다음 단계의 입력 일부가 되므로, 각 단계를 동시에 실행할 수 없습니다. 각 출력 토큰은 별도의 순전파 과정을 거치며, 이 과정마다 단 하나의 토큰을 생성하기 위해 전체 모델 가중치를 고대역폭 메모리에서 읽어와야 합니다. 이로 인해 Decoding은 메모리 제한(memory-bound) 상태가 됩니다. 즉, 가중치를 얼마나 빠르게 곱하느냐가 아니라 얼마나 빠르게 이동시킬 수 있는지가 성능을 결정합니다. Prefill 단계에서 전체 프롬프트를 처리했던 동일한 가중치 트래픽이 Decoding 단계에서는 단 하나의 토큰을 생성하는 데 사용됩니다.

서버 시스템은 배치(batching)를 통해 이를 해결합니다. 여러 요청을 함께 Decoding하면 가중치를 한 번 읽는 것으로 배치 내의 각 요청에 대해 토큰을 하나씩 생성할 수 있습니다. 이것이 Decoding을 현실적으로 운영할 수 있는 이유입니다. 여기서도 한계는 다시 메모리입니다. 진행 중인 모든 요청은 KV 캐시(key/value 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'

첫 번째 델타(delta)는 짧은 프롬프트보다 더 오랜 시간이 걸립니다. 읽어야 할 텍스트가 훨씬 많기 때문입니다. 첫 번째 토큰이 도착한 후에는 디코딩할 토큰이 거의 없으므로 응답이 즉시 종료됩니다. 수만 개의 토큰이 입력되었음에도 시간은 거의 흐르지 않았습니다. 반면 수백 개의 토큰이 출력되는 동안에는 전체 시간이 소요되었습니다.

스트리밍되지 않는 모든 응답은 과금 대상이 되는 수치와 함께 종료됩니다.

{
  "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}를 반환하며, 이 과정은 무료입니다. API에서 비용이 발생하지 않는 부분은 이것뿐만이 아니며, Claude API 중 과금되지 않는 부분을 확인하는 것은 첫 프로젝트 예산을 책정하기 전에 반드시 수행해야 합니다.

2026년 8월 기준 Claude의 백만 토큰당 비용

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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가 두 번 나열된 이유는 도입부 요금이 만료되기 때문입니다. 2026년 8월 31일까지는 입력 시 $2, 출력 시 $10가 청구됩니다. 2026년 9월 1일부터는 표준 요금인 입력 시 $3, 출력 시 $15가 적용되며, 이는 양쪽 모두 50% 인상된 금액입니다. 아래의 모든 작업 예시는 8월 요금을 기준으로 합니다.

요금은 변경될 수 있으며, 이 페이지는 요금 확인을 위한 공식 자료가 아닙니다. claude.com/pricing이 공식 정보원입니다. 가격 변동에도 변하지 않는 것은 계산 방법입니다.

가격표에 나타나지 않는 주의 사항이 하나 있습니다. 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 (Aug)",
    "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, 8월 요금 기준 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 (Aug)",
    "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는 즉시 결과가 나오는 대신 24시간 이내에 결과를 반환하므로, 야간 보고서 생성이나 대량 분류 작업에 적합합니다. 사람이 앉아서 기다려야 하는 작업에는 적합하지 않습니다.

모델 라우팅은 에이전트 단계에서는 결코 얻을 수 없는 방식의 이점을 여기서 제공합니다. 작업의 장황한 부분이 텍스트 재형식화나 이미 승인된 개요를 확장하는 것과 같은 기계적인 작업이라면, 저렴한 모델은 해당 토큰을 5분의 1 가격으로 생성합니다. Opus, Sonnet, Haiku 선택하기에서 품질의 기준선이 실제로 어디에 위치하는지 다룹니다.

입력에만 적용되는 캐싱 할인

프롬프트 캐싱은 프롬프트의 접두사를 서버에 저장하며, 이를 다시 읽을 때 기본 입력 요금의 일부만 청구합니다. 2026년 8월 기준으로 배율은 다음과 같습니다. 5분 캐시 작성 시 기본 입력 요금의 1.25배, 1시간 캐시 작성 시 2배가 적용되며, 캐시 적중 시 읽기 요금은 0.1배입니다.

출력은 이 혜택에 포함되지 않습니다. 캐시된 출력은 존재하지 않습니다. 프롬프트의 상당 부분이 캐시 적중으로 처리되더라도, 모델이 작성하는 모든 토큰은 매번 전체 출력 요금으로 청구됩니다.

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배이므로, 두 번의 적중이 필요합니다. 작성 및 읽기 배율과 캐싱의 손익 분기점에서 해당 계산 과정을 자세히 다룹니다.

제어 가능한 네 가지 레버

1. max_tokens를 모델 최대치가 아닌 p95 출력 길이에 맞춥니다.
2. 장황한 단계는 더 저렴한 모델로 라우팅합니다.
3. 아무도 기다리지 않는 작업은 배치(batch)로 처리합니다.
4. 응답을 부풀리는 지시 사항을 삭제합니다.

max_tokens은 엄격한 상한선이며, 이를 높게 설정한다고 해서 비용이 발생하는 것은 아닙니다. 요금은 생성된 토큰에 대해서만 부과되며 상한선 자체는 비용과 무관하기 때문입니다. 넉넉한 상한선은 응답이 잘못되었을 때 발생할 수 있는 제한을 제거해 줍니다. 로그에서 output_tokens 분포를 추출하여 상한선을 95번째 백분위수보다 약간 높게 설정하고, stop_reason: "max_tokens"은 응답을 이어가거나 재시도하는 방식으로 코드에서 처리하십시오. 감지된 잘림(truncation)은 비용을 지불하고 버려야 하는 4,000 토큰의 장황한 응답보다 저렴합니다. 확장된 사고(extended thinking) 역시 output_tokens에 포함되므로, 동일한 근거를 바탕으로 예산을 설정하십시오.

라우팅은 단계의 비용이 판단보다는 분량에서 발생할 때 효과적입니다. 강력한 모델은 의사결정에 유지하고, 타이핑 작업은 더 저렴한 모델에 맡기십시오. 저렴한 모델이 두 번의 시도를 필요로 하면 한 번의 비싼 시도보다 비용이 더 많이 들 수 있으므로, 먼저 자체 평가 세트로 라우팅 버전을 측정해야 합니다.

배치는 출력 비용을 할인받을 수 있는 유일한 레버입니다. 24시간 이내에 결과가 필요한 작업이나 일정에 따라 수행되는 모든 작업은 양쪽 모두 50% 할인 대상이 됩니다.

마지막 레버는 사람들이 간과하는 부분입니다. "철저하게 작성하라"나 "추론 과정을 설명하라"와 같은 문구는 모든 호출에서 출력 길이를 결정짓습니다. 이를 원하는 형태로 대체하십시오. 예를 들어 "최대 세 문장으로 답변하라"거나 "서론 없이 JSON 객체만 반환하라"와 같이 지시합니다. 모든 응답에 300 토큰을 추가하는 시스템 프롬프트는 프롬프트에 포함된 동일한 300 토큰보다 5배 더 많은 비용이 듭니다. 실행 중인 에이전트 비용 제어하기는 모니터링 측면을 다루며, 사용 패턴에 따라 API와 정액제 중 무엇이 더 저렴한지는 정액제로 해결할 수 있는 토큰당 비용을 일주일 동안 튜닝하기 전에 결정할 가치가 있습니다. 개발자 한 명의 경우, 이는 주로 Claude Pro의 월 20달러와 그에 따른 사용량 제한이 계량형 API를 사용했을 때의 작업량을 감당할 수 있는지에 달려 있습니다. 이미 세션 도중에 제한에 도달하고 있다면, 어떤 창(window)에서 대기 중인지 파악하는 것이 우선입니다. 해결책은 더 작은 모델 사용, 더 가벼운 컨텍스트, 추가 사용 크레딧 확보, 또는 해당 작업을 계량형 API로 옮기는 것이기 때문입니다. 계량형 API가 더 저렴한 선택지라면, 더 낮은 요금제로 변경하거나 해지하는 것으로 이미 지불한 달의 서비스는 그대로 유지되므로 전환에 따른 추가 비용은 없습니다. Pro 요금제와 비교하는 대상이 계량형 API가 아니라 ChatGPT라면, 두 구독 모델의 가격 비교를 통해 코딩 작업에 무엇이 더 저렴한지 확인할 수 있습니다. 개인 개발자가 아닌 팀 단위의 질문이라면, Claude Enterprise는 좌석당 요금과 동일한 API 요율의 토큰 계량을 결합함을 유의하십시오. 따라서 이 페이지의 모든 레버는 해당 청구서의 계량형 부분에도 동일하게 적용됩니다.

FAQ

출력 토큰이 입력 토큰보다 비싼 이유는 무엇입니까?

토큰당 가속기 사용 시간이 훨씬 더 많이 소요되기 때문입니다. 프롬프트는 전체 내용을 한 번의 순방향 패스(forward pass)로 처리하므로, 모델 가중치를 한 번 읽는 것만으로 수천 개의 토큰을 처리할 수 있으며 하드웨어는 곱셈 처리량(multiply throughput)에 의해 제한됩니다. 반면 응답은 토큰을 하나씩 생성하며, 각 토큰마다 전체 모델 가중치를 다시 읽는 순방향 패스가 필요하므로 하드웨어는 메모리 대역폭에 의해 제한됩니다. Anthropic은 현재 전체 카탈로그에서 출력 가격을 입력 가격의 5배로 책정하고 있으며, 이는 Haiku 4.5부터 Fable 5까지 동일합니다.

프롬프트 캐싱을 사용하면 출력 토큰이 저렴해집니까?

아니요. 프롬프트 캐싱은 입력에만 적용됩니다. 2026년 8월 기준으로 캐시 읽기 비용은 기본 입력 요금의 0.1배이며, 캐시 쓰기 비용은 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로 옮기십시오.