Claude Opus 5.5 API 가이드: 모델 ID, 네 가지 호환성 파괴 변경 사항, 그리고 조용한 다섯 번째

모델 문자열을 claude-opus-5에서 claude-opus-5-5로 바꿔도, 코드는 여전히 컴파일되고, 여전히 타입 검사를 통과하며, 테스트 스위트랄 것도 여전히 통과합니다. 그러고 나서 프로덕션에서 400이 터집니다. Claude Opus 5가 받아들였던 네 가지 요청 형태는 Claude Opus 5.5에서 곧바로 거부되고, 다섯 번째 변경은 아무것도 깨뜨리지 않습니다. 바로 그렇기 때문에 그것이 사용자에게까지 도달하게 될 바로 그 변경입니다. 이 문서는 이 모델에 대한 통합 참조 자료입니다. 식별자, 이 모델을 제공하는 표면, 요청 계약, 네 가지 오류, 조용한 다섯 번째 변경, 그리고 이제 effort 파라미터가 작동하는 방식까지. 동작이 Claude Fable 5.1과 일치하는 부분에서는 이미 그쪽으로 마이그레이션한 팀이 작업의 일부를 해둔 셈이므로, 아래의 각 변경 사항은 해당 모델에도 적용되는지 여부를 밝힙니다.

여기 있는 모든 내용은 모델이 출시된 지 이틀 뒤인 2026-09-24에 Anthropic 자체 Claude 문서에서 읽은 것입니다. 벤더 주장은 벤더 주장으로, 독립적인 수치는 독립적인 수치로 표시되어 있으며, 그 둘은 마치 비교 가능한 것처럼 동일한 에포트 설정에서 제시되는 일이 결코 없습니다.

모델 ID와 그것이 제공되는 위치

식별자는 claude-opus-5-5입니다 — 날짜 접미사가 없는 고정 모델 ID로, 다음 모델과 동일한 체계를 따릅니다: claude-opus-5. 채택할 별도의 고정 스냅샷 형식은 없으며, 다른 무엇으로 해석되는 별칭도 없습니다.

Anthropic의 모델 개요에는 다섯 개의 서피스가 나열되어 있으며, 정확한 문자열은 다음과 같습니다:

• Claude API — claude-opus-5-5, 모든 고객이 이용할 수 있습니다.

• Amazon Bedrock — anthropic.claude-opus-5-5 (벤더를 접두사로 붙이는 유일한 표면).

• AWS의 Claude Platform — claude-opus-5-5, Bedrock 스타일 id 대신 Claude API id를 사용합니다.

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; 전송하는 값은 배포 이름이며, Foundry는 Claude API 수명 주기 일정을 따릅니다.

그 다섯 중 두 가지는 이 섹션의 나머지보다 더 중요합니다. Amazon Bedrock과 Google Cloud는 자체 수명 주기와 지원 종료 날짜를 정하며, 아래의 주요 변경 사항에서 보듯이 Bedrock은 예전 컴퓨터 사용 도구가 여전히 작동하는 유일한 플랫폼이기도 합니다. Bedrock을 사용 중이라면, 다른 모든 이들과 같은 마이그레이션을 진행하는 것이 아닙니다.

이제 모든 요청이 충족해야 하는 것

Anthropic의 마이그레이션 가이드는 계약 조건을 목록으로 제시하는데, 이 목록은 여러분의 클라이언트를 직접 검증해 볼 수 있을 만큼 짧습니다. 어떤 모델에서 넘어오든, claude-opus-5-5에 대한 요청은 반드시 다음을 충족해야 합니다:

• thinking 필드를 보내지 않거나 thinking: {"type": "adaptive"}를 보내세요 — 두 가지는 동일합니다. 왜냐하면 적응형 사고는 항상 켜져 있기 때문입니다.

• effort로 사고 깊이를 제어하세요. 이렇게 할 수 있는 유일한 요청 파라미터이며, 다섯 가지 수준이 모두 지원되고 기본값은 medium입니다.

• 사용: tool_choice를 {"type": "auto"}(기본값) 또는 {"type": "none"}으로. 도구를 강제하는 것은 거부됩니다.

• 생략: temperature, top_p 및 top_k, 또는 기본값으로 두세요. 다른 값은 Claude Opus 4.7 이후의 모든 모델에서와 마찬가지로 이 모델에서도 거부됩니다.

• 끝내지 마세요, 메시지를 미리 채워진 어시스턴트 턴으로; 이는 Opus 4.6 이상에서 이미 거부되었습니다.

• 컴퓨터 사용을 computer_toolset_20260801 도구 세트로 Claude API 및 Google Cloud에서 선언하세요.

• 컨텍스트 윈도우 베타 헤더를 보내지 마세요. 1M 컨텍스트 윈도우가 기본값이며, 이전 모델용으로 작성된 헤더는 아무 효과가 없습니다.

가이드에서 설정이 거부된다고 나오는 경우, API는 HTTP 400을 반환합니다. 이것이 이 모델로 전환할 때 발생하는 실패 양상의 전부입니다. 출력 저하도, 로그의 경고도 아닙니다. 결코 실행되지 않는 요청입니다.

네 가지 주요 변경 사항

1. 사고는 비활성화할 수 없습니다.

Adaptive thinking은 항상 켜져 있습니다. thinking: {"type": "disabled"}를 보내면 400이 반환되며, 수동 예산도 마찬가지입니다 — thinking: {"type": "enabled", "budget_tokens": N}. 오류 텍스트는 보낸 유형을 명시한 다음 대체 유형을 명시합니다:

• 이 모델에서는 "thinking.type.disabled"가 지원되지 않습니다. 사고 동작을 제어하려면 "thinking.type.adaptive"와 "output_config.effort"를 사용하세요.

• 이 모델에서는 "thinking.type.enabled"가 지원되지 않습니다. 사고 동작을 제어하려면 "thinking.type.adaptive"와 "output_config.effort"를 사용하세요.

실질적인 결과는 오류 자체가 아니라, 그것을 고친 뒤에 벌어지는 일이다. Claude Opus 4.8 및 그 이전 버전에서는 thinking 필드가 없는 요청은 thinking 없이 실행되었다. Claude Opus 5.5에서는 모든 요청이 thinking을 수행하며, max_tokens는 여전히 thinking과 응답 텍스트를 합친 범위에 적용되는 하드 한도로 남아 있다. thinking 토큰은 thinking 텍스트가 사용자에게 반환되지 않는 경우에도 출력 토큰으로 청구된다. 따라서 이전에는 thinking 없이 실행되던 엔드포인트가 "수정" 이후에는 요청당 더 많은 출력 토큰을 생성할 수 있다. Anthropic의 권장 사항은 이전에 thinking을 비활성화했던 곳에서는 effort를 낮추고, xhigh 또는 max effort에서는 max_tokens를 64k에서 시작해 그로부터 조정해 나가라는 것이다.

응답 형태도 바뀝니다. 응답은 첫 번째 텍스트 블록 앞에 하나 이상의 사고 블록으로 시작할 수 있으므로, 위치로 응답을 읽는 코드 — content[0].text, 또는 첫 번째 content_block_start를 텍스트로 처리하는 스트림 핸들러 — 는 요청이 성공했더라도 이러한 응답에서 깨집니다. 대신 type 필드로 블록을 선택하세요.

2. 강제 도구 사용은 오류를 반환합니다

tool_choice 유형 any와 tool은 400을 반환하며, 토큰 계산 엔드포인트에도 동일한 검증이 적용되므로 사전 점검 카운트는 실제 호출과 같은 방식으로 실패합니다:

• tool_choice: "tool" 및 "any" 유형은 이 모델에서 지원되지 않습니다.

auto와 none은 영향을 받지 않습니다. 문서화된 대체 방법은 tool_choice: {"type": "auto"}도구에 strict: true를 표시하여 스키마에 유효한 인자를 받도록 하거나, 스키마를 구조화된 출력으로 옮기는 것입니다 — 그리고 auto는 호출을 보장하지 않으므로 도구가 적용되는 시점을 프롬프트에 명시하세요. 엄격한 도구 사용은 JSON Schema의 하위 집합을 허용합니다: 도구의 input_schema에 있는 모든 객체는 additionalProperties: false를 설정해야 하므로, 플래그를 바꾸기 전에 각 스키마를 확인하세요. 그리고 이것이 남기는 간극에 유의하세요: 코드가 호출을 단지 허용하는 것이 아니라 강제하는 것에 의존했다면, auto는 허용은 복원하지만 보장은 복원하지 않습니다. tool_use 블록이 실제로 반환되었는지 확인하세요.

3. Thinking 블록은 모델과 대화에 바인딩됩니다.

모든 사고 블록은 어떤 모델이 그것을 생성했는지 기록하며, 각 모델은 자신의 블록과 정의된 다른 모델들의 블록 집합을 읽습니다. 규칙은 양방향으로 작동합니다:

• Claude Opus 5.5는 Claude Opus 5 및 이전 Opus, Sonnet, Haiku 모델의 사고 블록을 읽지만, Claude Fable 또는 Claude Mythos 모델의 사고 블록은 읽지 않습니다.

• Claude API에서 Claude Fable 5.1과 Claude Mythos 5.1은 Claude Opus 5.5 블록을 읽습니다. 다른 모델은 읽지 않습니다.

• Claude Opus 5.5에서 그 두 가지가 아닌 다른 것으로 넘어가는 대화는 이전의 추론 없이 이후 턴을 실행합니다.

대화를 옮기는 라우터나 폴백은 이를 달성하는 명백한 방법입니다. 더 미묘한 부분은 그 블록이 대화 접두사에도 묶여 있다는 점입니다 — 시스템 프롬프트, 도구, 그리고 그 앞에 있는 모든 메시지에 말이죠. Anthropic은 2026-08-31 00:00 UTC 이후에 생성된 계정에 대해 Claude API와 클라우드 플랫폼에서 기본적으로 접두사 검사를 시행합니다. 시스템 프롬프트, 도구 목록 또는 이전 메시지를 편집한 뒤 블록을 재생하면 요청이 400을 반환합니다. 두 가지 탈출구가 있습니다. thinking-binding-controls-2026-08-01 베타 헤더를 보내고 thinking.block_binding.prefix_mismatch_behavior를 "drop_block"으로 설정해 요청을 실패시키는 대신 영향을 받는 블록을 삭제하는 것입니다. 또는 대화를 추가 전용으로 유지하고 편집 대신 대화 중간 시스템 메시지로 지침을 변경하는 것입니다 — Claude Code, claude.ai, Claude Managed Agents 및 Claude Agent SDK가 이미 그렇게 하고 있습니다.

놓치기 쉬운 좋은 소식이 하나 있습니다: 요청에 대상 모델이 읽을 수 없는 블록이 포함되어 있으면, API가 모델이 보기 전에 그 블록을 버립니다. 요청은 성공하고, 버려진 블록에는 요금이 청구되지 않습니다.

4. 구형 컴퓨터 사용 도구는 Claude API와 Google Cloud에서 거부됩니다

유형이 computer_20251124인 tools 항목은 Claude API와 Google Cloud에서 400을 반환합니다. 메시지는 거부된 유형을 명시한 다음 모델이 허용하는 유형을 나열합니다:

• 'claude-opus-5-5'은(는) computer_20251124 도구 유형을 지원하지 않습니다.

대체 항목은 computer_toolset_20260801 툴셋입니다: computer-use-2025-11-24 베타 헤더를 제거하고, tools 항목을 이름과 표시 크기 없이 보내세요. 이는 요청만 바뀌는 것이 아니라 에이전트 루프도 함께 바뀝니다. 액션은 단일 computer 도구가 아니라 멤버 tool_use 블록으로 도착하며, 한 턴에 여러 개가 있을 수 있고, 액션은 블록의 name이며 input.action이 아닙니다. 그리고 모든 결과는 toolset_name을 그대로 되돌려 보내야 합니다. Amazon Bedrock에서는 computer_20251124가 Claude Opus 5에서와 정확히 동일하게 계속 작동하므로 변경할 필요가 없습니다.

네 가지 중 Claude Fable 5.1에도 적용되는 것은 무엇인가요?

Anthropic은 처음 세 가지가 Claude Fable 5.1에도 적용된다고 밝힙니다 — 항상 켜져 있는 사고, 강제 도구 선택 없음, 그리고 모델 및 대화에 묶인 사고 블록. 컴퓨터 사용 변경은 그렇지 않습니다: 그 변경은 Claude API와 Google Cloud에서 이 모델에만 해당합니다. 따라서 이미 Claude Fable 5.1로 이전한 팀은 사고 비활성화 코드 경로와 강제 도구 선택을 폐기했고, 추가 전용 대화 패턴을 사용하고 있습니다; 남은 것은 모델 ID와 컴퓨터 사용 도구 세트뿐입니다. 팀이 Claude Opus 5에서 오는 경우에는 네 가지 모두를 한꺼번에 마주합니다. 그것이 일정에 넣을 가치가 있는 마이그레이션이며, 어디서 시작하느냐에 따라 작업량이 다릅니다.

다섯 번째 변경: 아무 오류도 발생하지 않고, 진행 피드가 조용해집니다

Claude Opus 5에서는 모델이 도구 호출 사이에 작성하는 짧은 메모가 일반 텍스트 블록으로 반환됩니다. Claude Opus 5.5에서는 — Claude Fable 5.1에서처럼 — 그 내레이션이 진행 업데이트 thinking 블록으로 반환되며, 각 도구 호출 전에 최대 하나씩 옵니다. 그리고 thinking.display의 기본값은 "omitted"이므로, 해당 블록은 서명과 함께 빈 thinking 필드를 지닌 채 도착합니다.

요청이 실패하지도 않습니다. 오류가 기록되지도 않습니다. 도구 호출 사이의 텍스트를 진행 표시기로 사용자에게 스트리밍하는 애플리케이션은 도구 호출 사이에 진행 상황을 표시하다가 그만두고 아무것도 표시하지 않기 시작합니다. 눈에 보이는 증상은 사용자가 가장 안심하고 싶어 하는 바로 그 작업 구간 동안 UI가 멈춘 것처럼 보이는 것이며, 이는 성능 문제, 네트워크 문제 또는 멈춤으로 보고될 것입니다. 마이그레이션 버그로는 보고되지 않습니다. 이것이 프로덕션에 배포되는 변경입니다.

해결책은 디스플레이 설정과, 그에 맞는 읽기입니다:

• thinking.display을(를) "updates" — 베타, thinking-display-updates-2026-08-18 헤더 뒤에 있는 — 추론 자체는 숨겨진 채 진행 상황 업데이트를 다시 받기 위한 것입니다. 이것이 진행 피드가 원하는 설정입니다.

• 또는 이를 "summarized"로 설정하면 진행 상황 업데이트와 추론 요약을 같은 블록 안에서 함께 받을 수 있습니다.

• 그런 다음 텍스트 블록이 아니라 thinking 블록에서 텍스트를 읽고, 비어 있지 않은 각 thinking 블록을 그 블록이 앞서는 tool_use 블록보다 앞에 렌더링하며, 해당 블록들을 어시스턴트 턴의 나머지와 함께 변경 없이 그대로 다시 전달합니다.

이 점에 관한 Anthropic 자체의 메모는 그 취지를 인용할 만합니다: 도구 호출 사이의 텍스트를 렌더링하는 인터페이스는 기본값에 의존하기보다 표시 값을 설정하는 것이 기대됩니다. 오늘날 여러분의 통합이 사고 블록을 완전히 무시한다면, 바로 그 경우가 기본값이 안전한 유일한 곳입니다.

노력이 곧 API 표면이다

사고를 비활성화할 수 없게 되면서, output_config.effort는 모델이 얼마나 추론하는지를 조절하는 유일한 다이얼이 되고, 따라서 주어진 작업에서 비용과 지연 시간을 조절하는 유일한 다이얼이 됩니다. 이전 모델에서 설정을 그대로 복사해 오기 전에 이에 대해 알아 둘 만한 네 가지가 있습니다.

기본값이 바뀌었습니다. Claude Opus 5.5는 medium effort를 기본값으로 사용합니다, 반면 Claude Opus 5와 이전 Opus 모델은 high를 기본값으로 사용했습니다. effort를 생략한 요청은 이제 교체 이전보다 한 단계 낮게 실행됩니다. Anthropic은 또한 이 모델이 더 많이 주어진 effort 설정에서 Claude Opus 5보다 턴당 사고하는 경향이 있으며, 특히 xhigh와 max에서 그러하다고 문서화합니다. 이 두 효과는 서로 반대 방향으로 작용하는데, 바로 이것이 벤더가 설정을 그대로 옮기지 말고 자체 평가에서 새롭게 effort 스윕을 실행하라고 지시하는 이유입니다.

척도는 low / medium / high / xhigh / max이며, 여기서는 다섯 가지 모두 지원됩니다. 명명된 레벨은 애초에 고정된 토큰 예산이 아닙니다 — Anthropic은 effort를 엄격한 예산이 아니라 행동 신호로 설명합니다 — 또한 각 레벨에 할당된 토큰은 모델마다 달라졌으므로, Claude Opus 5.5에서의 "high"는 Claude Opus 5에서의 "high"와 같지 않습니다. effort를 모델의 기본값으로 설정하는 것은 이를 생략하는 것과 동일합니다.

운영상의 세부 사항 두 가지입니다. 둘 다 놓치면 비용이 발생하기 때문입니다. 첫째, 요청 간에 최상위 effort 값을 변경하면 프롬프트 캐시가 무효화됩니다. 캐시 적중에 의존하는 대화에서는 한 수준을 선택해 일정하게 유지하고, 대신 워크로드 전반에 걸쳐 값을 바꾸세요. 둘째, 이 모델은 메시지별 effort(베타 헤더 mid-conversation-output-config-2026-07-01)를 지원하며, 이를 통해 캐시를 다시 시작하지 않고도 이후 턴에서 수준을 변경할 수 있습니다. 여기서 프롬프트 캐시 최솟값은 512토큰으로, 이전 세대의 1,024에서 줄어들었으므로, 이전에는 캐시하기에 너무 짧았던 프롬프트도 코드 변경 없이 이제 항목을 생성할 수 있습니다.

출력 상한: 동기 128K, Batch 300K

동기식 Messages API는 출력을 최대 128K 토큰으로 제한합니다. Message Batches API는 300K 출력 토큰을 사용하려면 output-300k-2026-03-24 베타 헤더가 필요합니다 — 바로 그 문자열입니다. 입력은 기본적으로 헤더가 필요 없으며 전체 1M 토큰 컨텍스트 윈도우를 사용합니다.

실무적 해석: 128K 상한은 Claude Opus 5에서 변하지 않았으므로, 동기식 통합에 대해 그 축 하나만 놓고 예산을 다시 책정할 필요는 없다. 다시 책정해야 하는 것은 그 안의 사고(thinking)다. 이제 모든 요청에서 max_tokens가 사고(thinking)와 텍스트를 모두 포괄하므로, Claude Opus 5에서 응답 텍스트에 딱 맞았던 값은 여기서 더 빠듯하다. 그리고 xhigh 또는 max effort에서는 공급업체가 64k에서 시작해 조정하라고 권장한다. 장시간 실행되는 작업을 128K 동기식 상한에 맞춰 산정했는데 이제 잘린다면, 움직인 것은 상한이 아니다.

Safeguard 라우팅은 명세의 일부입니다.

이것은 정책 각주가 아니라 통합 사실입니다: 일부 프롬프트에서는 보내는 모델 문자열이 실제로 응답한 대상을 설명하지 않습니다.

Claude Opus 5.5에는 안전 분류기가 탑재되어 있으며, 거부된 요청은 HTTP 200으로 반환되며, 여기에는 stop_reason: "refusal" 및 stop_details 객체가 있으며, 이 객체는 정책 영역을 명시합니다. 이 모델은 Claude Opus 5보다 더 많은 카테고리를 포괄합니다 — 다음을 예상하세요: bio, frontier_llm 및 reasoning_extraction을(를) 익숙한 cyber와 함께. reasoning_extraction 거부는 재시도되지 않고 즉시 차단됩니다: Anthropic의 서버 측 폴백은 이를 재시도하지 않으며, 거부는 사용자에게 반환됩니다.

재시도를 수행하는 범주의 경우, 메커니즘은 매개변수입니다. fallbacks를 "default"로 설정하고 server-side-fallback-2026-07-01 베타 헤더와 함께 사용하면 API는 해당 범주에 대해 Anthropic이 권장하는 모델에서 거부된 요청을 단일 호출 내에서 다시 실행하여 하나의 응답을 반환합니다. Anthropic의 도움말 센터는 이 모델의 라우팅을 직접 명시합니다: 플래그가 지정된 사이버보안 요청은 Claude Opus 4.8로 폴백되며, Anthropic의 생물학 분류기 — Fable-5 스타일 세트 — 는 Claude Opus 5로의 폴백을 유발합니다. 이는 이중 용도 생명과학 작업을 위한 폴백입니다. 좁은 범위의 프런티어 LLM 개발 역량도 Claude Opus 5로 라우팅됩니다. Anthropic은 또한 이 검사가 최신 메시지뿐만 아니라 모델이 읽는 모든 것을 검토한다고 언급합니다. 따라서 메모리, 커넥터 콘텐츠, 검색 결과 및 파일이 전환을 유발할 수 있습니다.

통합과 관련해 세 가지가 뒤따릅니다. 모든 응답에서 최상위 모델 필드를 읽으십시오. 이 필드는 메시지를 실제로 생성한 모델을 보고하며, 폴백 콘텐츠 블록은 각 핸드오프 지점을 표시합니다. 폴백 자체의 속도 제한을 확인하십시오. 속도 제한에 걸린 폴백은 시도되지 않고 대신 거부가 반환됩니다 — 부하가 걸리면 폴백은 거부로 저하됩니다. 그리고 안전장치가 활성화된 상태로 게시된 모든 벤치마크 실행은 Claude Opus 5.5 단독이 아니라 라우팅된 시스템에 대한 측정으로 취급하십시오. 이는 Anthropic이 아래에서 자체 수치에 대해 말하는 바와 정확히 일치합니다.

서버 측 폴백은 베타이며 Claude API 전용입니다: Message Batches API에서는 지원되지 않고, Amazon Bedrock, Google Cloud, Microsoft Foundry에서는 사용할 수 없으며, 이러한 환경에서는 SDK 미들웨어가 문서화된 경로입니다. 검증 측면에서는 두 범주 모두에 대한 접근 경로가 있습니다 — Cyber Verification Program과 Life Sciences Verification Program — 하지만 이 글을 작성하는 시점에 Anthropic의 헬프 센터가 문서화한 비대칭성에 주목하세요: Claude Opus 5.5는 현재 Cyber Verification Program에 등재되어 있지 않은 반면, 생명과학 프로그램은 검증된 조직에게 가장 강력한 모델에 대한 접근을 제공하는 것으로 설명되어 있습니다.

컨텍스트, 컷오프, 지원 종료 및 Fast 모드

모델 페이지와 사용 중단 표에서 가져온 나머지 엔벨로프:

• 컨텍스트 윈도우 — 1M 토큰, 기본값, 베타 헤더 없음.

• 지식 컷오프 — 2026년 6월, 이는 학습 데이터 컷오프이기도 합니다.

• 지원 종료 — Anthropic이 운영하는 플랫폼에서는 2027-09-22보다 빠르지 않으며, 최소 60일 전에 공지됩니다. Amazon Bedrock과 Google Cloud는 각자의 날짜를 정합니다. Claude Opus 5는 최소 2027-07-24까지 활성 상태이므로 강제 전환은 없습니다.

• 요금표 — 입력 100만 개당 $4.00, 출력 100만 개당 $20.00, 5분 캐시 쓰기 100만 개당 $5.00, 1시간 캐시 쓰기 100만 개당 $8.00, 캐시 읽기 100만 개당 $0.20. Batch는 입력과 출력 모두 절반 가격으로 $2.00 / $10.00입니다.

• 캐시 읽기는 주목할 만한 예외입니다: $0.20은 기본 입력의 5%인데, 대부분의 Claude 모델은 10%, Claude Fable 5.1은 2.5%입니다. 캐시 재사용이 많은 혼합 워크로드에서는 이를 실질적인 할인으로 체감합니다.

• 빠른 모드 — 여전히 리서치 프리뷰로 문서화되어 있으며, Claude API에서만 제공되고, 백만 토큰당 입력 $8.00 / 출력 $40.00으로 별도 책정됩니다. 다음으로 활성화하세요: speed: "fast" 및 fast-mode-2026-02-01 베타 헤더. Bedrock, AWS의 Claude Platform, Google Cloud 또는 Microsoft Foundry에서는 사용할 수 없고, Batch API와도, Priority Tier 약정과도 함께 사용할 수 없습니다. Claude Opus 5.5는 Priority Tier를 전혀 지원하지 않는다는 점에 유의하세요.

벤치마크가 말하는 것, 그리고 어떤 설정에서인지

에포트 설정 때문에 벤더 표와 독립 표를 행 단위로 비교할 수 없으며, 아래의 모든 수치가 각자의 설정을 함께 표기하는 이유이기도 합니다.

공급업체 보고, Anthropic 자체 하네스. Anthropic의 출시 노트에 따르면, 별도로 명시되지 않는 한 모든 Claude Opus 5.5 결과는 적응형 사고를최대 노력으로 사용합니다; 예외는 Terminal-Bench 4.0으로, Claude Opus 5.5에는 xhigh, GPT-6 Astra에는 high로 보고되었는데, 이는 각 모델의 최고 점수이기 때문입니다. 이를 기준으로 공급업체는 Terminal-Bench 4.0을 66.4%, FrontierCode v1.1 Main을 54.4%, CursorBench 4.0을 57.8%, GDPval-AA v2.1을 1,846 Elo, AutomationBench를 40.0%, 도구를 사용한 Humanity's Last Exam을 67.7%, Terminal-Bench-Science 0.1을 58.7%, OSWorld 2.0을 부분 점수 81.8%, 도구를 사용한 Chartography를 89.0%로 보고합니다. 모델의 기본값인 중간 노력 설정에서는 공급업체가 FrontierCode를 54.6%, CursorBench를 52.5%로 제시합니다. 같은 노트가 공개하는 점에 주목하세요: 평가는 프로덕션 안전장치가 활성화된 상태에서 실행되었으며, 그 안전장치가 작동했을 때 사이버보안 작업은 Claude Opus 4.8이, 생물학 및 프런티어 LLM 개발 작업은 Claude Opus 5가 완료했습니다 — Anthropic은 이로 인해 해당 벤치마크에서 Claude Opus 5.5의 성능이 낮아졌을 가능성이 있다고 말합니다. 따라서 영향을 받은 평가의 공개 점수는 이 모델에 대한 순수한 측정값이 아닙니다.

독립 기관, Artificial Analysis. Intelligence Index v4.3.2에서 Claude Opus 5.5는 Artificial Analysis가 "Adaptive Reasoning, Max Effort, Default Fallback"이라고 표기한 구성으로 58점을 기록했습니다. 이는 측정된 최고 점수로, 다른 점수들을 몇 점 차로 앞서며, 구성 평가 10개 중 6개에서 선두를 차지합니다. 같은 지수와 같은 하네스에서 Claude Fable 5.1은 53점, Claude Opus 5는 51점을 기록했습니다. Artificial Analysis는 전체 노력 사다리를 공개하는데, 이것이 여기서 가장 유용한 독립 산출물입니다. 즉 max 58, xhigh 56, high 54, medium 51, low 42입니다. 자체 측정에 따르면 Claude Opus 5.5는 max effort에서 지수 과제당 약 119,000 출력 토큰을 사용한 반면, Claude Opus 5는 약 73,000, Claude Fable 5.1은 78,000, GPT-6 Astra는 27,000을 사용했습니다. 이는 모두 출력 토큰으로 청구되는 토큰이며, 해당 페이지에는 지수 과제당 비용이 $5.98로 보고되어 있습니다. 또한 Terminal-Bench 4.0은 59.6%, Humanity's Last Exam은 61.4%로 측정했는데, 이는 다른 하네스에서 max effort 기준으로 벤더가 제시한 66.4% 및 67.7%와 대비됩니다.

그 두 문단을 서로 대조해 읽으면 정직한 결론은 좁습니다. 벤더의 66.4% Terminal-Bench와 독립적인 59.6%는 서로 다른 사람들이 일치한다고 보장되지 않는 설정에서 실행한 같은 벤치마크이며, 둘 중 어느 것도 당신의 워크로드에 대한 증거가 아닙니다. 전이 가능한 발견은 에포트 사다리입니다. 독립 지수에서 이 모델 자체의 설정들은 16포인트에 걸쳐 있는데, 이는 이 모델과 전임 모델 사이의 격차보다 더 넓은 폭입니다. 이 모델들 중에서 고르는 것보다 에포트 수준을 고르는 것이 더 중요하며, 그 레이블의 "Default Fallback" 조항은 벤치마크 부산물이 아니라 위에서 설명한 안전장치 라우팅입니다.

공급업체가 보고한 효율성, 출처 명시. Anthropic은 Claude Opus 5.5가 대부분의 작업에서 Claude Fable 5.1 수준의 성능을 내면서 실행 비용은 약 40% 낮고, 일반적인 워크로드 비용은 Claude Opus 5 대비 약 40% 적으며 이는 20%의 정가 인하와 대비된다고 말한다. 출력 속도는 30% 이상 더 빠르다. 이는 공급업체가 선택한 워크로드 전반의 평균에 대한 공급업체 측 설명이다. 출시 당시 고객 발언도 같은 종류의 증거다: Box는 토큰 수가 3분의 1이고 답변이 약 40% 덜 장황하다고 보고하고, Kiro는 토큰 수가 대략 절반이며 호출이 약 40% 더 적다고 하며, Factory는 출력 토큰이 20–25% 더 적다고 하고, GitHub는 자사가 측정한 것 중 토큰과 단계가 가장 적은 편에 속한다고 한다. Anthropic은 또한 내부 팩트체킹 테스트에서 18개 보고서 중 16개가 Claude Fable 5.1과 Claude Opus 5 모두 어떤 시도에서도 넘지 못한 품질 기준을 통과했다고 보고한다. 이 모든 것은 공급업체가 보고한 것이며 어느 것도 감사되지 않았다. 공개된 한계는 이례적으로 솔직하며 기억할 가치가 있다: Anthropic은 Claude Opus 5.5가 "자주 자신이 평가받고 있다고 의심한다"고 말한다.

마지막으로, 형제 모델들입니다: Anthropic은 Claude Sonnet 5.5와 Claude Haiku 5.5가 "앞으로 몇 주 안에" 출시될 것이라고 말합니다. 둘 다 아직 출시되지 않았고, 가격도 책정되지 않았으며, 오늘 현재 어떤 서비스 환경에도 나타나 있지 않습니다.

전체 전환 없이 네 가지 변경 사항 테스트하기

여기서 마이그레이션 위험은 품질이 아닙니다 — 스테이징에서 한 번도 실행해 본 적 없는 코드 경로가 프로덕션에서 400을 반환하는 바로 그 경로라는 점입니다. 네 가지 호환성을 깨는 변경은 모두 요청 형태 변경이므로, 이들은 결정론적으로 그리고 즉시 실패합니다. 놓친 경로를 찾는 유일한 방법은 실제 트래픽을 그 경로들로 통과시켜 보는 것입니다.

Claude Opus 5.5는 OrcaRouter에서 anthropic/claude-opus-5.5로 제공되며, Anthropic 자체 정가에 0% 마크업이 적용됩니다 — 제공사 정가가 그대로 반영되므로, 공급사 가격이 변경되면 당일 바로 여기에 적용됩니다.

그러면 프로덕션 트래픽의 일정 비율을 해당 모델로 보내고 나머지는 여전히 Claude Opus 5에서 실행하면서, 어떤 요청이 왜 실패하는지 지켜보고 하나씩 수정할 수 있습니다. 네 가지 오류는 스스로를 설명합니다. 각각 거부된 매개변수의 이름을 알려주고, 네 가지 중 세 가지 경우에는 대체 매개변수까지 알려줍니다. 자동 페일오버는 경로가 아직 깨져 있는 동안 그 공백을 메워 줍니다. 아직 충분히 특성을 파악하지 못한 모델에 대해 실패한 요청은 사용자에게 400을 노출하는 대신, 이미 파악해 둔 모델로 폴백됩니다.

실용적인 작업 순서: 기본값이 medium으로 바뀌었으므로 먼저 model id를 바꾸고 effort를 명시적으로 설정하세요. 다음으로 thinking-disabled 및 forced-tool-choice 경로를 제거하세요. 그다음 streaming reader를 고치세요 — 유형별 블록 선택과 thinking.display 설정 — 이것은 크게 실패하기보다 조용히 실패하는 부분이기 때문입니다. 그리고 Bedrock을 사용 중이라면 computer-use toolset 마이그레이션은 마지막으로 미루세요. 거기에는 적용되지 않는 항목이기 때문입니다. 나머지 — 가격, 컨텍스트 창, 캐시 요율 및 1M-token 기본값 — 은 이미 두신 그대로입니다.

전체 전환 없이 실시간 트래픽의 일부를 새 모델로 라우팅하세요: OrcaRouter의 Claude Opus 5.5는 Anthropic의 정가로 실행되며, 이미 특성을 파악해 둔 모델로 자동 페일오버됩니다.