Claude Opus 5.5 vs Opus 5: 같은 답, 출력 token은 절반

Claude Opus 5.5의 정가는 입력 token 100만 개당 $4, 출력 token 100만 개당 $20다. Claude Opus 5는 각각 $5와 $25다. 이 20% 차이는 모델의 동작과 무관하게 적용된다. 따라서 20%를 제외하고도 비용이 얼마나 줄어드는지가 핵심이다. 각 모델의 기본 설정으로 13개 단일 요청 작업을 실행한 결과, Opus 5.5의 청구 비용은 65% 적었다. 동일한 요금을 적용해도 56% 저렴했다. 여러 단계를 거치는 tool loop에서는 차이가 훨씬 작았다. 실제 청구액은 37%, 동일 요금 기준으로는 22% 줄었다.

TL;DR

• 채점한 468회 호출에서 Opus 5.5의 작업당 청구 비용은 $0.0072, Opus 5는 $0.0204였고 두 모델 모두 모든 작업을 맞혔다.
• 동일한 요금을 적용해도 Opus 5.5는 56% 저렴했다. 평균 출력 token은 341개로, Opus 5의 799개보다 적었다.
• 질문 4개로 구성된 tool loop에서는 동일 요금 기준 차이가 22%로 줄었다. 입력 token이 비용의 대부분을 차지하고 두 모델이 같은 파일을 읽기 때문이다.
• max effort에서 Opus 5.5는 이 loop의 자체 기본 설정보다 3.3x 많은 비용을 썼지만 추가로 해결한 문제는 없었다.
• 이제 tool_choice를 any나 특정 tool로 지정하면 HTTP 400이 반환된다. Opus 5는 둘 다 허용한다.

Anthropic은 2026-09-22에 Opus 5.5를 출시하면서 일반적인 workload에서 Opus 5보다 “실행 비용이 40% 낮다”고 밝혔다. 이 주장 중 모델 동작에 따라 달라지는 부분은 작업당 token 감소뿐이다. 실제로 측정할 가치가 있는 부분도 여기다.

Claude Opus 5.5에서 실제로 무엇이 바뀌었나?

가격 인하보다 더 큰 변화는 thinking을 끄는 옵션이 사라졌다는 점이다. Adaptive thinking에서는 답변 전에 얼마나 오래 추론할지 모델이 결정한다. API가 추론 내용을 보여 주지 않더라도 이 token은 출력으로 청구된다. Opus 5.5에서는 이 모드가 항상 켜져 있다. 사용자가 조정할 수 있는 항목은 effort뿐이다. low부터 max까지 5단계로 구성된 요청 parameter이며, 모델이 thinking에 사용할 수 있는 예산을 정한다.

Opus 5는 thinking: {"type": "disabled"}를 허용했다. Opus 5 비용 측정에서 청구액을 Opus 4.8과 같은 수준으로 낮춘 유일한 설정이었다. 이제 이 방법은 쓸 수 없다.

표 밖에서 짚어야 할 변화가 2가지 있다. 기본 effort가 high에서 medium으로 한 단계 낮아졌다. effort 필드를 보내지 않는 요청은 Opus 5에서 실행되던 것과 같은 깊이로 추론하지 않는다. 진행 상황 표시 방식도 아무런 알림 없이 바뀌었다. 이전에는 모델이 tool call 사이에 짧은 메시지를 작성했지만, 이제는 thinking block으로 전달된다. 별도로 요청하지 않으면 텍스트가 비어 있으므로 이런 메시지를 streaming하던 UI는 오류 없이 조용해진다.

출시 benchmark 결과는 어떤가?

Anthropic의 출시 자료에서 Opus 5.5는 모든 coding 및 지식 작업 benchmark에서 Fable 5.1보다 높은 점수를 기록했다. 대부분의 항목에서는 GPT-6 Astra도 앞섰다. 아래 수치는 Anthropic이 adaptive thinking과 max effort로 측정한 결과다. Terminal-Bench 항목에는 xhigh를 적용했다.

Anthropic은 자체 표에 이례적인 단서를 붙였다. 이 수준에서는 “benchmark 점수 차이로 실제 환경의 차이를 판단하기가 예전보다 어려워졌다”는 설명이다. 실제 사용 환경에서 Fable 5.1과의 차이는 점수만큼 크지 않다고도 밝혔다. 이 수치를 인용하기 전에 확인할 각주도 2개 있다. AutomationBench는 Zapier가 fallback model 없이 실행했기 때문에 safeguard가 한 번이라도 개입하면 실패로 처리됐다. 전체 표는 production safeguard를 켠 상태에서 측정했다. Classifier가 개입하면 cybersecurity 작업은 Opus 4.8로, biology 작업은 Opus 5로 전달됐다.

이 결과만으로는 작업 비용을 알 수 없다. 그래서 직접 측정했다.

단일 요청 작업에서도 더 저렴한가?

그렇다. 절감액 대부분은 요금 인하가 아니라 실제 효율 개선에서 나온다. 단일 요청 작업은 tool 없이 요청 1번과 응답 1번으로 끝난다. 200단계 반복 규칙이나 막힌 cell이 있는 grid의 경로 수처럼 산술 및 counting 문제를 사용했다. 13개 작업을 각각 3회씩, 기본 설정과 5개 effort level에서 Opus 5.5와 Opus 5로 실행했다. 채점 대상 호출은 총 468회다. 실행 전에 모든 정답을 Python으로 전수 계산했다. 중간 계층이 cache된 중복 요청으로 답하지 못하도록 각 prompt에 고유한 random string도 넣었다. 작업당 비용은 응답에 포함된 값을 그대로 사용하지 않고, thinking을 포함해 각 호출에 청구된 token 수와 Anthropic의 정가로 계산했다.

기본 설정에서 두 모델 모두 정확도 100%를 기록했다. 다른 모든 level에서도 97% 이상이었다. 오답 3건은 낮은 level에 몰리지 않고 서로 다른 작업과 level에 흩어져 있었다. 이 작업군에서는 정확도가 급락하는 지점이 없었다. 차이는 전부 비용에서 나왔다.

Effort에 따른 변화는 두 모델에서 다르게 나타났다. Opus 5는 low부터 max까지 $0.0197-$0.0220으로 거의 일정했고, 차이는 12%였다. Opus 5.5는 $0.0060-$0.0240으로 4x 차이가 났다. Opus 5.5에서 effort는 비용을 실질적으로 조정하지만 Opus 5에서는 거의 no-op에 가깝다. Migration 과정에서 기존 설정을 그대로 복사하면 이전과 전혀 다른 결과가 나올 수 있다.

가장 어려운 5개 작업에서는 차이가 더 커졌다. 기본 설정의 Opus 5.5는 작업당 $0.0113, Opus 5는 $0.0375였다. 출력 token 중앙값은 각각 585개와 1,145개였다.

Agent 비용이 누적되는 tool loop에서는 어떻게 달라지나?

Tool loop에서도 비용은 줄었지만 배수는 작아졌다. Opus 5.5와 Opus 5를 제대로 비교하려면 tool loop를 봐야 한다. Turn 1회는 요청 1회다. 모델이 tool을 요청하면 코드가 이를 실행하고, 전체 대화 기록을 다시 보낸다. 따라서 5 turn짜리 대화에서는 계속 길어지는 대화 기록에 대해 5번 비용을 지불한다. 이 비용은 token당 가격보다 turn 수에 더 크게 좌우된다. 작은 synthetic service에 파일 목록 조회, 파일 읽기, 검색 등 3개 tool을 제공했다. 질문은 4개였으며, 답을 찾으려면 3개 또는 4개 파일에 걸친 call chain을 따라가야 했다. 같은 인터페이스에서 동일한 tool과 prompt를 사용해 각 조건을 12회 실행했다.

기본 설정의 Opus 5.5는 Opus 5보다 실행당 비용이 37% 적었다. Turn은 12%, 출력 token은 30% 줄었고 12회 모두 해결했다. 해결한 질문당 비용으로 계산하면 차이는 43%로 커진다. Opus 5가 1회 실패했기 때문이다. Vendor가 제시한 “실행 비용 40% 절감”과 비슷하며, 실제 청구서에 표시되는 수치이기도 하다.

이 workload에서는 요금 인하가 절감액의 대부분을 차지한다. 이유는 명확하다. Loop는 매 turn마다 대화 기록을 다시 보내고 두 모델은 같은 파일을 읽는다. 출력 token은 30% 줄었지만 전체 token은 19%만 줄었다. 비용이 가장 많이 드는 구간에서 출력 감소 효과가 가장 작다. 다음 절에서 이를 수치로 나눠 본다.

Loop에서 Opus 5.5를 low로 낮춰도 비용은 줄지 않았다. 평균적으로 turn이 1회 늘었고, 대화 기록을 한 번 더 전송하면서 절약한 token을 모두 소모했다. 단일 요청 작업에서 효과가 분명했던 effort 조절이 loop에서는 비용을 줄이지 못한다. 비용을 결정하는 것은 추론 깊이가 아니라 turn 수이기 때문이다.

절감액 중 가격 인하가 차지하는 비중은 얼마인가?

작업 형태에 따라 7분의 1에서 5분의 2까지다. 아래 표의 가운데 열은 Opus 5.5에서 측정한 token에 Opus 5의 요금을 적용한 값이다. Opus 5와 동일한 요금으로 계산했을 때 Opus 5.5가 출력을 줄여 절감한 비용을 보여 준다.

단일 요청 작업의 절감은 실제 효율 개선에서 나온다. 전체 절감액 중 가격 인하가 차지하는 비중은 14%뿐이며, 나머지는 모델이 출력을 줄인 결과다. 운영 계획에서는 tool loop 결과를 기준으로 삼는 편이 낫다. Agent traffic 대부분이 이런 형태이기 때문이다. 여기서는 전체 절감폭의 41%가 가격 인하에서 나온다.

더 높은 effort 설정이 유리할 때가 있나?

이번 workload에서는 없었고 비용 부담도 컸다. Tool loop에서 max로 설정한 Opus 5.5는 실행당 $0.1087을 썼다. 자체 기본 설정의 3.3x지만 똑같이 12개 질문만 해결했다. 추가 예산은 tool call에 사용됐다. 중앙값 기준으로 기본 설정은 5회, max는 12회였다. 출력 token도 427개에서 3,124개로 늘었다. 단일 요청 작업에서 Opus 5보다 비쌌던 유일한 level도 max였다. 각각 $0.0240과 $0.0220이었다.

예산 대부분은 reasoning에 쓰인다. 이 단답형 작업에서 thinking은 Opus 5.5 출력 token의 98.4%를 차지했고, max에서는 99.6%였다. 모든 thinking token은 출력 요금으로 청구되며 기본 표시 설정에서는 내용을 볼 수도 없다. Anthropic도 max는 최고 난도 문제에만 사용하라고 안내한다. 측정 결과는 간단하다. 모델이 이미 해결하는 작업에서는 effort를 높일 때마다 비용만 늘어난다.

Model ID를 바꾸면 무엇이 깨지나?

Opus 5에서 동작하던 요청 형식 2개가 Opus 5.5에서는 400을 반환한다. 기존 코드에서도 흔히 사용하는 형식이다.

Tool 사용 강제는 거부된다. Chat model에서 구조화된 JSON을 얻기 위해 특정 tool call을 지정하는 client는 다음 오류를 받는다.

tool_choice: type "tool" and "any" are not supported for this model.

같은 오류는 OpenAI-compatible client에서도 발생한다. 여기서는 동일한 요청을 tool_choice: "required" 또는 특정 function으로 작성한다. auto와 none은 계속 동작한다. Migration할 때는 prompt에 tool의 사용 조건을 명시하고, schema에 맞는 JSON이 필요하면 strict tool schema나 structured output을 사용해야 한다.

Thinking도 끌 수 없다. thinking: {"type": "disabled"}와 수동 budget_tokens는 모두 실패한다. OpenAI-compatible 인터페이스의 대응 설정인 reasoning_effort: "none"도 거부된다. 대신 effort parameter를 사용해야 한다.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Summarize this incident report in five bullets."}],
    output_config={"effort": "low"},   # low | medium | high | xhigh | max; medium is the default
)

# Thinking is billed as output whether or not you can read it.
print(response.usage.input_tokens, response.usage.output_tokens)

low는 이전의 thinking 비활성화 동작과 가장 가깝다. 단일 요청 작업군에서는 가장 저렴하면서 정확했다. 하지만 thinking이 무료가 되는 것은 아니다. 모델은 계속 thinking을 사용하며 해당 token도 출력으로 청구된다.

Prompt 예산을 그대로 적용해도 되나?

Token 예산은 그대로 적용할 수 있다. 동일한 입력 4개를 두 모델에서 측정한 결과도 같았다. 영어 문장은 1,277개와 1,275개, Python은 583개와 581개, JSON tool argument blob은 482개와 480개, 중국어 문장은 500개와 498개였다. 일정하게 발생한 2 token 차이는 텍스트가 아니라 요청 framing에서 나온다. Opus 5에 맞춰 조정한 context 예산이나 chunking 임계값을 Opus 5.5에서 다시 기준화할 필요는 없다.

언제 전환해야 하나?

비용이 기준이라면 위의 요청 형식 2개를 수정한 뒤 바로 Opus 5.5로 전환해도 된다. 가격 인하 효과를 제외해도 정확도는 같으면서 단일 요청 작업에서 56%, tool loop에서 22% 저렴했다. 무시할 수 있는 차이가 아니다. 실제 배포 환경 대부분에서 체감할 비교도 기본 설정 대 기본 설정이다.

Effort는 기존 설정을 그대로 옮기지 말고 다시 조정해야 한다. 기본값은 high에서 medium으로 바뀌었고, 조정 범위는 Opus 5보다 4배 넓어졌다. 최적 level은 작업 형태에 따라 달랐다. 단일 요청 작업에서는 low가 가장 저렴하면서 정확했고, tool loop에서는 기본값이 low와 max보다 나았다.

FAQ

Claude Opus 5.5는 정말 Opus 5보다 40% 저렴한가? 실제 청구액 기준으로는 비슷하다. Tool loop에서 Opus 5.5는 Opus 5보다 실행당 37%, 단일 요청 작업당 65% 저렴했다. 이 가운데 20%p는 모델 동작과 무관하게 적용되는 요금 인하다. 이를 제외한 효율 개선은 loop에서 22%, 단일 요청 작업에서 56%였다.

Opus 5.5에서도 thinking을 끌 수 있나? 아니다. thinking: {"type": "disabled"}와 수동 token 예산은 Opus 5.5에서 모두 400을 반환한다. 대신 output_config.effort를 사용해야 하며 low가 가장 저렴한 설정이다. 모든 level에서 thinking token은 출력으로 청구된다.

Tool 사용 강제를 무엇으로 대체해야 하나? tool_choice: {"type": "auto"}를 유지하고 prompt에 tool 실행 조건을 명확히 적어야 한다. Schema에 맞는 JSON이 필요하면 strict tool schema나 structured output을 사용한다. Opus 5.5는 any와 특정 tool 지정 형식을 조용히 낮은 단계로 처리하지 않고 400으로 거부한다. 잘못된 답이 아니라 요청 실패로 나타난다.

Prompt 크기를 다시 측정해야 하나? 아니다. 일반 문장, code, JSON, 중국어에서 동일한 텍스트는 Opus 5와 Opus 5.5에서 동일한 token 수로 청구됐다. Context 예산을 그대로 적용할 수 있다.

Opus 5.5는 Fable 5.1을 대체하나? Anthropic의 benchmark 표에서는 Opus 5.5가 모든 항목에서 Fable 5.1보다 높은 점수를 기록했고 token 가격은 40% 수준이다. Anthropic은 여전히 Fable 5.1을 고난도 reasoning과 장기간 agentic 작업용으로 배치하고 있다. 실제 환경의 차이는 점수만큼 크지 않다고도 밝혔다. 표만 보고 결정하지 말고 자체 eval을 다시 실행해야 한다.

관련 측정 결과: Claude Opus 5와 Opus 4.8 비교, GPT-6 Astra effort 단계별 비교, Vendor별 thinking 제어 방식.

출시 하루 뒤인 2026-09-23에 Claude API gateway와 OpenAI-compatible 인터페이스를 통해 측정했다. 채점한 단일 요청 호출은 468회였다. 정답을 로컬에서 전수 계산한 13개 작업을 3회씩 반복하고, effort 설정 6개와 model 2개를 조합했다. Tool loop는 총 48회 실행했다. 여러 단계를 거치는 질문 4개를 3회씩 반복하고 조건 4개를 적용했다. Prompt에는 salt를 추가했다. 각 model은 effort parameter를 지원하는 인터페이스로 호출했다. 비용은 응답에서 읽지 않고 Anthropic 정가로 계산했다.

← 블로그로 돌아가기