Claude Fable 5의 Opus 4.8 폴백 메커니즘 설명

Dora입니다. 약 일주일 동안 프로덕션 트래픽을 Claude Fable 5로 라우팅해 왔습니다. 폴백 동작이 실제로 발생하는 것을 목격하기에 충분한 시간이었고, 무엇이 놀라웠는지 아직 기억하기에 충분히 짧은 시간이기도 합니다. 이 글은 방금 Fable 5를 통합했는데 완전히 무해한 프롬프트에서 stop_reason: "refusal"이 반환되는 것을 본 분들, 혹은 곧 겪게 될 텐데 새벽 2시에 그 사실을 알고 싶지 않은 분들을 위한 것입니다.

요약: Claude Fable 5 폴백은 오류가 아닙니다. 이는 모델이 출시되는 방식의 문서화된 부분입니다. 안전 분류기가 요청을 거부하면 API는 refusal stop reason과 함께 HTTP 200을 반환하고, Anthropic은 사용자를 잃지 않고 Claude Opus 4.8에서 해당 요청을 재시도할 수 있는 세 가지 방법을 제공합니다. 이를 잡아야 할 예외로 처리하면 잘못 처리하게 됩니다. 라우팅 결정으로 처리하면 깔끔하게 맞아떨어집니다.

폴백을 유발하는 요인, API가 실제로 반환하는 것, 재시도 구현 방법, 그리고 청구에 미치는 영향에 대해 설명하겠습니다.

Fable 5 라우팅에서 Opus 4.8이 중요한 이유

Fable 5 안전장치와 폴백 동작

Fable 5는 Anthropic의 가장 널리 출시된 고성능 모델이며, 모델 앞단에 위치한 안전 분류기와 함께 출시됩니다. 분류기가 요청을 플래그로 표시하면 Fable 5는 응답하지 않습니다. 해당 요청은 Claude Opus 4.8에서 재실행될 수 있으며 사용자에게는 그 사실이 알려집니다. 이는 Anthropic의 Claude Fable 5 및 Mythos 5 발표에 문서화되어 있습니다.

Anthropic은 분류기가 평균적으로 세션의 5% 미만에서 작동한다고 밝히고 있습니다. 그 수치는 제가 지금까지 확인한 것과 일치합니다. 대부분의 경우 폴백 메커니즘이 있다는 것을 눈치채지 못합니다.

Mythos 5 제한된 접근 컨텍스트

Mythos 5는 Fable 5와 동일한 기본 모델이지만 분류기가 없습니다. 일반적으로 사용 가능하지 않습니다. 접근은 Project Glasswing을 통해 이루어지며, 현재 사이버보안 파트너와 별도의 신뢰 접근 프로그램 하에 소수의 생물학 연구자들로 제한되어 있습니다. 이미 접근 권한이 없다면 Fable 5를 기반으로 개발하는 것입니다. anthropic mythos 브랜딩이 여기서 혼란스러울 수 있는데 — Mythos는 모델 클래스이고 Fable 5는 해당 클래스의 공개적으로 이용 가능한 구성원입니다.

이 글의 나머지 부분에서는 코드가 Fable 5를 호출한다고 가정합니다.

폴백이 단순한 오류 경로가 아닌 제품 기능인 이유

이것이 제가 내면화하는 데 시간이 걸린 부분입니다. Opus 4.8은 저하된 경험이 아닙니다. 이전 세대 Opus 티어로 여전히 유능하며 동일한 분류기를 실행하지 않습니다. 따라서 라우팅 로직은 다음과 같습니다: 먼저 가장 강력한 모델을 시도하고, 분류기가 거부하면 두 달 전 플래그십이었던 모델로 폴스루합니다. 사용자는 어느 쪽이든 답변을 받습니다. 이것이 전체 설계입니다.

폴백은 버그 리포트가 아닙니다. 코드가 사용자를 대신해 내리는 라우팅 결정입니다.

폴백 또는 거부를 유발하는 요인

사이버보안, 생물학/화학, 그리고 증류 카테고리

stop_details.category 필드는 어떤 분류기가 작동했는지 알려줍니다. Fable 5에 게시된 카테고리에는 cyber, bio, reasoning_extraction이 포함됩니다 — 마지막 카테고리는 Anthropic의 서비스 약관에 따라 모델 출력을 역공학하거나 증류하려는 시도처럼 보이는 요청에 대한 것입니다. 현재 목록과 정확한 동작은 Claude API 문서의 거부 및 폴백 문서에 있습니다.

제가 하는 어떤 것에서도 bio가 작동하는 것을 본 적이 없습니다. cyber는 두 번 작동하는 것을 보았습니다. 두 경우 모두 프롬프트는 보안과 관련이 있었지만 무해했습니다 — 하나는 특정 로그 형식이 어떻게 구조화되었는지에 관한 질문이었고, 다른 하나는 수년이 지나 완전히 패치된 CVE에 관한 것이었습니다. 어느 것도 무언가를 시도하려는 것이 아니었습니다. 분류기가 표면 패턴을 보고 거부했습니다.

거짓 양성과 보수적인 안전장치

Anthropic은 분류기가 보수적으로 조정되어 있다고 명시적으로 밝혔습니다 — 그들 자신의 표현으로, 이상적인 것보다 더 엄격하다고 합니다. 이것이 트레이드오프입니다. 그들은 무해한 사이버 질문을 거부하고 Opus 4.8로 라우팅하는 것을 선호하지, 실제 오용 사례를 놓치는 것을 원하지 않습니다. 폴백이 존재하는 이유는 바로 설계상 거짓 양성률이 0이 아니기 때문입니다.

이 가정을 바탕으로 개발하면 놀라운 일이 없어집니다. 거부가 드문 비상사태라고 가정하고 개발하면 첫 번째 거부가 무언가를 망가뜨립니다.

요청이 거부될 때 API가 반환하는 것

응답은 정상적인 HTTP 200입니다. 형태는 대략 다음과 같습니다:

{
  "role": "assistant",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "..."
  },
  "usage": { "input_tokens": 106, "output_tokens": 1 }
}

출력이 생성되기 전에 거부된 요청에 대해서는 청구되지 않습니다. 거부된 턴을 재설정하지 않고 동일한 대화를 계속하면 계속 거부가 발생합니다 — Anthropic의 스트리밍 거부 문서는 이를 구체적으로 다룹니다. 재시도 전에 해당 턴을 제거하거나 다시 작성하세요.

category 필드는 정보 제공용입니다. 이를 기반으로 사용자 대면 텍스트를 분기하지 마세요. 배치 결과를 포함한 일부 표면에서는 null일 수도 있으므로, stop_reason을 직접 확인하여 거부를 감지하세요.

개발자가 폴백을 구현하는 방법

세 가지 방법이 있습니다. 하나를 선택하세요. 중첩하지 마세요.

서버 사이드 폴백 파라미터

직접 Claude API 또는 AWS의 Claude Platform에서 가장 깔끔한 경로는 옵트인 fallbacks 파라미터입니다. 현재 베타 상태입니다. 요청에 폴백 모델 목록을 추가하면 Fable 5가 거부할 경우 Anthropic이 목록의 다음 모델(출시 시 Opus 4.8)에서 요청을 재실행하고 해당 응답을 반환합니다. 당신 측에서는 한 번의 라운드 트립입니다.

Message Batches API에서는 지원되지 않으며, 현재 Amazon Bedrock, Vertex AI, Microsoft Foundry에서는 사용할 수 없습니다. 해당 플랫폼에서는 SDK 미들웨어를 사용하세요.

클라이언트 사이드 SDK 미들웨어

Anthropic SDK는 refusal-fallback 미들웨어를 제공합니다. 폴백 모델 목록으로 클라이언트를 한 번 구성하면 재시도, 폴백 크레딧을 위한 베타 헤더, 대화 기록 처리를 담당합니다. 수락 모델은 후속 턴에 대해 고정되어 대화가 일관성을 유지합니다.

저는 미들웨어를 사용했습니다. 구성은 클라이언트 생성 시 한 블록이며, 그 이후 client.beta.messages.create는 일반 클라이언트와 정확히 동일하게 동작합니다 — 단, 거부가 자동으로 라우팅된다는 점이 다릅니다. Bedrock, Vertex 또는 Foundry를 사용 중이거나 모든 곳에서 동일한 코드 경로를 원한다면 제가 권장하는 방법입니다.

민감한 콘텐츠를 노출하지 않고 분류기 결과 로깅

거부가 발생하면 디버그에 충분한 정보를 로깅하세요 — 모델, 타임스탬프, 카테고리 — 하지만 민감할 수 있는 경우 전체 프롬프트를 애플리케이션 로그에 다시 기록하지 마세요. 분류기가 이미 플래그를 표시했습니다. 프롬프트를 처리해야 할 것으로 취급하되, 관찰 가능성 스택에 인덱싱하고 싶은 것으로 취급하지 마세요.

저는 stop_details.category에 카운터를 유지하고 개발 환경에서만 전체 페이로드에 대한 샘플 비율을 적용합니다. 이렇게 하면 콘텐츠를 노출하지 않고 거짓 양성 패턴을 파악할 수 있습니다.

청구 및 사용자 경험

지원되는 경우 중복 프롬프트 캐시 비용 방지

원래 Fable 5 요청이 긴 캐시된 프리픽스를 사용한 경우, Opus 4.8에서 재시도할 때 캐시 읽기 비용을 두 번 지불하고 싶지 않을 것입니다. 폴백 크레딧이 이를 처리합니다. 거부가 크레딧을 발급하면 응답에 불투명한 fallback_credit_token이 포함되며, 재시도 요청에서 이를 전달하면 중복 캐시 비용이 발생하지 않습니다. 메커니즘과 베타 헤더는 AWS Bedrock의 폴백 크레딧 가이드에 문서화되어 있으며, SDK 미들웨어가 헤더를 자동으로 전송합니다. 토큰은 5분 동안 유효합니다.

서버 사이드 fallbacks 파라미터나 미들웨어를 사용한 경우 이것은 자동으로 처리됩니다. 수동 재시도를 수행하는 경우 직접 연결해야 합니다.

최종 사용자에게 폴백 설명하기

폴백은 실패가 아닙니다. 하지만 사용자는 투명성을 위해, 그리고 Opus 4.8이 다르게 응답할 수 있기 때문에 응답이 다른 모델에서 나왔다는 것을 알아야 합니다. 저는 작은 인라인 메모를 표시합니다 — “폴백 모델로 답변되었습니다”와 같은 내용 — 그리고 이것이 무엇을 의미하는지 설명하는 도움말 페이지로 연결합니다. 사과가 아닙니다. 레이블입니다.

제가 하지 않는 것은 카테고리를 사용자에게 노출하는 것입니다. “cyber” 또는 “bio”는 맥락 없이 비난처럼 읽히며, 대부분 그렇지 않습니다.

안전 동작을 관찰 가능하게 유지하기

거부율을 일반 SLI로 추적하세요. 주 단위로 증가한다면 알고 싶을 것입니다 — 사용 패턴이 플래그된 카테고리 쪽으로 이동하고 있거나, 분류기가 재조정된 것입니다. 두 경우 모두 운영적으로 중요합니다. 두 경우 모두 측정하지 않으면 보이지 않습니다.

FAQ

Fable 5가 Opus 4.8으로 폴백하는 이유는 무엇인가요?

Fable 5는 특정 카테고리(사이버, 생물학, 화학, 증류)의 요청을 거부할 수 있는 안전 분류기와 함께 출시되기 때문입니다. 그런 일이 발생하면 Fable 5는 응답하지 않으며, 요청은 동일한 분류기를 실행하지 않는 Opus 4.8에서 재실행될 수 있어 사용자는 여전히 응답을 받습니다.

API 팀은 거부 응답을 어떻게 처리해야 하나요?

예외가 아닌 정상적인 API 결과로 처리하세요. stop_reason == "refusal"을 확인하세요. 서버 사이드 fallbacks 파라미터, SDK 미들웨어를 사용하거나 폴백 크레딧 토큰으로 수동 재시도를 구현하세요. 대화를 계속하기 전에 거부된 턴을 재설정하세요, 그렇지 않으면 계속 거부가 발생합니다.

폴백은 요청이 안전하지 않다는 의미인가요?

아닙니다. 분류기는 보수적으로 조정되어 있으므로 인접 카테고리의 무해한 요청도 때때로 트리거될 수 있습니다. Anthropic은 세션의 5% 미만이 폴백에 해당한다고 밝히고 있습니다. 거부를 사용자에 대한 판결이 아닌 라우팅 신호로 처리하세요.

Opus 4.8이 기본 모델이 되어야 하는 경우는 언제인가요?

Fable 5의 추론 한계가 필요하지 않고 라우팅 로직을 완전히 피하고 싶을 때입니다. Opus 4.8은 토큰당 비용이 약 절반이며 동일한 분류기를 실행하지 않습니다. 일상적인 작업의 경우 Opus 4.8이 더 합리적인 기본값인 경우가 많습니다. 장기 에이전틱 실행의 경우 폴백이 구성된 Fable 5가 적합합니다.

결론

Claude Fable 5 폴백은 오류가 아닌 라우팅 이벤트입니다. 분류기는 보수적으로 작동하고, API는 깔끔한 200을 반환하며, Anthropic은 많은 코드 없이 재시도, 캐시 청구, 대화 기록을 처리하는 서버 사이드 파라미터와 SDK 미들웨어를 제공합니다.

구현 작업은 작습니다. 프레이밍 전환이 더 어려운 부분입니다. 거부를 예외로 취급하는 것을 멈추면 나머지는 따라옵니다.

저는 사이버 분류기가 합법적인 질문에 얼마나 자주 작동하는지 계속 모니터링하고 있습니다. 한 주 더 데이터를 수집하면 제 측에서 무언가를 조정해야 하는지 알 수 있을 것입니다. 다음 주에 계속합니다.

이전 게시물: