Claude Opus 4.7 API 요금과 토큰 계산법

따라서 비용을 단순히 총 토큰 × 평균 단가로 계산하면 오차가 커질 수 있습니다. 특히 긴 system prompt, tool definition, 반복되는 문서 컨텍스트를 캐싱하는 애플리케이션이라면 cache write와 cache read를 별도 항목으로 잡아야 합니다.

기본 비용 공식: 캐싱이 없을 때

프롬프트 캐싱을 쓰지 않는 가장 단순한 경우에는 아래처럼 계산합니다.

예를 들어 한 번의 요청에서 입력 200,000 tokens, 출력 20,000 tokens가 발생했다면 비용은 다음과 같습니다.

이 계산은 Anthropic API의 입력·출력 단가만 반영한 예시입니다. 다른 제공 플랫폼을 거치거나 별도 서비스 요금이 붙는 구조라면 최종 청구 금액은 달라질 수 있습니다.

프롬프트 캐싱을 쓸 때의 공식

프롬프트 캐싱을 사용하면 입력 토큰을 하나의 항목으로만 보면 안 됩니다. 캐시를 새로 쓰는 토큰과 이미 캐시된 내용을 읽는 토큰의 단가가 다르기 때문입니다.

5분 TTL 캐시만 쓴다면 1시간 cache write 항목은 빼면 됩니다. 반대로 1시간 TTL만 쓴다면 5분 cache write 항목을 빼면 됩니다. Anthropic의 streaming 문서 예시는 usage에 input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens 같은 필드가 들어갈 수 있음을 보여주며, pricing 문서도 cache write와 cache hit를 별도 과금 항목으로 구분합니다.

호출 전 토큰 계산: 글자 수로 추정하지 말고 count_tokens

API 비용을 예상할 때 한글 글자 수, 영어 단어 수, 대략적인 character count로 계산하는 방식은 위험합니다. 실제 모델이 보는 것은 토큰이고, tool, image, PDF, system prompt까지 payload에 포함되면 사람이 보는 길이와 비용이 더 벌어질 수 있습니다.

Anthropic은 /v1/messages/count_tokens endpoint를 제공하며, 이 endpoint는 메시지를 보내기 전에 토큰 수를 계산하기 위한 용도입니다. 문서에 따르면 system prompts, tools, images, PDFs를 포함해 message 생성과 유사한 구조화 입력을 받을 수 있고, 응답으로 total input tokens를 반환합니다. 또한 모든 active models가 token counting을 지원합니다.

실무에서는 다음 순서가 가장 깔끔합니다.

1. 실제 Messages API에 보낼 payload를 준비합니다.
2. 같은 구조의 payload를 /v1/messages/count_tokens에 먼저 보냅니다.
3. 반환된 input token 수를 기준으로 예상 비용, 사용자별 한도, 워크플로별 예산 경고를 계산합니다.

핵심은 샘플 문자열만 따로 세지 않는 것입니다. system prompt, 대화 기록, tool definition, 이미지나 PDF가 실제 요청에 들어간다면 그것까지 함께 넣어 세야 비용 예측이 현실에 가까워집니다.

호출 후 정산: 최종 기록은 response usage로

요청이 끝난 뒤에는 생성된 텍스트 길이로 출력 토큰을 거꾸로 추정하지 말고, API response의 usage를 기록하는 편이 맞습니다. Anthropic의 Messages API 예시는 response usage에 input_tokens, output_tokens 등이 포함될 수 있음을 보여주고, streaming 문서도 cache 관련 필드인 cache_creation_input_tokens, cache_read_input_tokens를 보여줍니다.

streaming을 쓸 때는 특히 주의해야 합니다. Anthropic 문서에 따르면 message_delta 안의 usage token counts는 각 이벤트에서 새로 증가한 값이 아니라 누적값입니다. 따라서 delta 이벤트마다 usage를 전부 더하면 같은 토큰을 여러 번 계산하게 됩니다.

팀 단위 정산: Usage & Cost Admin API를 함께 쓰기

개별 request 로그는 실시간 모니터링과 제품 내 과금 제한에 유용합니다. 하지만 월별 정산, 팀별 비용 배분, workspace별 분석, 장기 추세 확인에는 Anthropic의 Usage & Cost Admin API를 함께 쓰는 것이 좋습니다.

공식 문서에 따르면 Usage & Cost Admin API는 조직의 과거 API 사용량과 비용 데이터에 programmatic하고 granular한 접근을 제공하며, usage report를 model, workspace, service tier 같은 기준으로 나눠 볼 수 있습니다.

즉, 애플리케이션 쪽에서는 매 요청의 usage를 저장해 즉시 예산을 통제하고, 공식 대조나 월말 정산에는 Usage & Cost Admin API의 historical usage/cost 데이터를 기준으로 삼는 구조가 적합합니다.

Opus 4.7로 업그레이드한다면 토큰 예산을 다시 봐야 하는 이유

Claude Opus 4.7에는 새 tokenizer가 도입됐습니다. Anthropic 문서는 이 tokenizer가 이전 모델과 비교해 텍스트 처리 시 대략 1x에서 1.35x 정도의 토큰을 사용할 수 있으며, 콘텐츠에 따라 최대 약 35% 더 많아질 수 있다고 설명합니다. 또한 같은 입력이라도 /v1/messages/count_tokens가 Claude Opus 4.7과 Claude Opus 4.6에서 서로 다른 token number를 반환할 수 있다고 안내합니다.

따라서 입력 $5/MTok, 출력 $25/MTok이라는 단가만 보고 기존 예산을 그대로 가져가면 안 됩니다. Opus 4.6 또는 더 오래된 Claude 모델에서 Opus 4.7로 옮긴다면, 적어도 아래 항목은 다시 측정하는 것이 좋습니다.

• 트래픽이 많은 대표 prompt
• 긴 context를 포함하는 workflow
• tool definitions가 큰 agent형 요청
• 반복 사용되는 system prompt와 문서 컨텍스트
• 비용 상위권에 있는 batch 또는 자동화 작업

이 과정을 거친 뒤 alert, rate limit, 사용자별 quota, workflow별 비용 상한을 다시 잡아야 예산 초과를 줄일 수 있습니다.

실무 체크리스트

• API model ID가 claude-opus-4-7인지 확인합니다.
• 주요 배포 전에는 대표 payload를 /v1/messages/count_tokens로 먼저 측정합니다.
• input_tokens, output_tokens, cache write, cache read를 분리해 저장합니다.
• streaming 사용 시 message_delta.usage는 누적값이므로 이벤트별로 단순 합산하지 않습니다.
• 월별 정산, workspace별 비용 배분, 장기 추세 분석에는 Usage & Cost Admin API를 사용합니다.
• 기존 Claude 모델에서 Opus 4.7로 이전할 때는 새 tokenizer가 실제 prompt에 미치는 영향을 다시 테스트합니다.

정리하면, Claude Opus 4.7의 기본 API 단가는 입력 $5/MTok, 출력 $25/MTok로 기억하기 쉽습니다. 하지만 비용을 정확히 맞추려면 호출 전 count_tokens, 호출 후 usage, 그리고 prompt caching과 새 tokenizer의 영향을 모두 비용 모델에 넣어야 합니다.