Claude Fable 5.1 마이그레이션: 1M 컨텍스트와 thinking block 변경 대응법

요약: Claude Fable 5.1은 1M 토큰 컨텍스트, 128k 출력, 낮아진 prompt cache read 가격을 제공하지만 forced tool use 미지원, thinking block 호환성, 히스토리 수정 제한 같은 마이그레이션 이슈가 있습니다. 운영 중인 Claude API 앱이라면 모델명만 바꾸면 안 됩니다.

먼저 확인할 것: 이 모델을 써야 하는 workload인가

Anthropic의 Claude Fable 5.1은 장시간 agentic coding, 복잡한 연구, 문서·스프레드시트·슬라이드 작업처럼 긴 문맥과 강한 추론이 필요한 작업을 겨냥합니다. 기본 1M 토큰 컨텍스트와 128k max output token을 제공하고, adaptive thinking이 항상 켜져 있습니다. 가격은 Claude Fable 5와 같지만 cache read는 million token당 0.25달러로 낮아졌습니다.

하지만 모든 서비스가 바로 Fable 5.1로 갈 필요는 없습니다. 짧은 챗봇, 단순 분류, FAQ 답변, 고정 포맷 생성은 더 작은 모델이 비용과 지연시간 면에서 유리할 수 있습니다. Fable 5.1은 “비싼 모델을 쓰면 좋아지겠지”가 아니라, 긴 세션에서 컨텍스트를 유지하고 여러 단계의 reasoning을 안정적으로 이어가야 할 때 후보가 됩니다.

마이그레이션 전에 현재 사용량을 나눠보는 것이 먼저입니다. 평균 input token, p95 input token, output token, tool call 비율, prompt cache hit rate, 장시간 세션 비율을 확인합니다. 1M 컨텍스트가 필요 없는 workload에 1M 모델을 붙이면 성능보다 비용 관리 문제가 먼저 옵니다.

Breaking change 1: forced tool use가 막힌다

Claude Fable 5.1과 Mythos 5.1은 tool_choice의 any와 특정 tool 강제 호출을 지원하지 않습니다. 이 값을 보내면 400 에러가 납니다. 기존에 “무조건 이 도구를 호출하게 한다”는 방식으로 JSON 생성이나 함수 실행을 강제했다면 장애가 날 수 있습니다.

Anthropic은 schema-conformant tool input이 필요하면 strict tool use나 structured outputs를 쓰라고 안내합니다. 즉, 도구 호출 자체를 강제하기보다 도구가 필요한 조건을 프롬프트에 명확히 쓰고, 입력 스키마는 strict하게 검증하는 방향입니다.

운영 코드에서는 모델별 tool_choice 정책을 분리해야 합니다. 예를 들어 라우터가 Fable 5.1로 보낼 때는 auto 또는 none만 허용하고, legacy 모델에는 기존 정책을 유지합니다. SDK wrapper 안에서 모델명에 따라 허용 파라미터를 검사하면 배포 후 400 에러를 줄일 수 있습니다.

function normalizeToolChoice(model: string, toolChoice: unknown) {
  if (model === 'claude-fable-5-1') {
    return toolChoice === 'none' ? { type: 'none' } : { type: 'auto' };
  }
  return toolChoice;
}

이 코드는 완성형이 아니라 방어 계층의 예시입니다. 핵심은 모델별로 API 제약이 다르다는 사실을 런타임에서 검증하는 것입니다.

Breaking change 2: thinking block은 모델에 묶인다

Fable 5.1의 thinking block은 이전 모델이 읽을 수 없습니다. 대화가 Opus 5나 Fable 5에서 Fable 5.1로 올라가는 것은 가능하지만, Fable 5.1에서 이전 모델로 내려가면 해당 thinking block은 drop됩니다. beta header를 쓰면 drop 여부를 input_transformations에서 확인할 수 있고, 그렇지 않으면 조용히 사라질 수 있습니다.

이 문제는 모델 라우팅을 쓰는 팀에서 특히 중요합니다. 비용 절감을 위해 쉬운 턴은 작은 모델, 어려운 턴은 큰 모델로 보내는 구조라면 중간에 reasoning 상태가 사라질 수 있습니다. 사용자는 같은 대화라고 느끼지만 모델은 이전 reasoning을 읽지 못할 수 있습니다.

해결책은 세션 정책을 분리하는 것입니다. thinking continuity가 중요한 세션은 한 모델 계열에 고정합니다. fallback이 필요하다면 thinking block이 drop될 수 있음을 로그에 남기고, 필요한 상태는 별도 memory나 요약 메시지로 보존합니다. 중요한 업무에서는 “라우팅 최적화”보다 “대화 상태 일관성”이 우선입니다.

Breaking change 3: 이전 턴 수정이 thinking block을 깨뜨린다

Fable 5.1에서는 thinking block 앞의 system prompt, tools, 이전 message가 수정되면 다음 요청에서 에러가 나거나 block이 drop될 수 있습니다. 새 계정은 2026년 8월 31일 이후부터 이 검사가 강하게 적용됩니다.

많은 앱은 매 요청마다 system prompt를 다시 조립합니다. 현재 날짜, 사용자 요금제, 실험 플래그, 최근 상태를 system prompt에 끼워 넣고 다음 턴에서 조금 다르게 보냅니다. 기존에는 문제가 덜 보였지만, preserved thinking을 쓰는 모델에서는 이런 방식이 prefix mismatch를 만들 수 있습니다.

운영 패턴을 바꿔야 합니다. 대화의 앞부분은 append-only로 취급합니다. 턴마다 달라지는 정보는 mid-conversation system message나 turn-scoped system message로 넣습니다. tools 배열도 매번 재정렬하지 말고 안정적으로 유지합니다. signed URL처럼 같은 URL이 다른 bytes를 반환하는 경우도 조심해야 합니다.

새 기능: per-message effort와 turn-scoped system message

Fable 5.1은 beta로 대화 중 effort를 바꿀 수 있습니다. 어려운 분석 턴은 high effort, 단순 요약 턴은 low effort로 낮추는 식입니다. 중요한 점은 이 방식이 prompt cache를 불필요하게 깨뜨리지 않도록 설계됐다는 것입니다.

turn-scoped system message도 유용합니다. “이번 턴에서만 JSON으로 답하라”, “이번 턴에서만 보수적으로 판단하라” 같은 지시가 히스토리에 계속 누적되면 컨텍스트와 캐시가 더러워집니다. clear_at: next_user_message 같은 방식을 쓰면 현재 턴에만 적용하고 이후에는 비용 없이 남길 수 있습니다.

다만 beta 기능은 운영 전 별도 feature flag를 두는 편이 안전합니다. SDK 버전, beta header, 모델 지원 범위가 맞지 않으면 장애가 날 수 있습니다.

마이그레이션 체크리스트

• 현재 workload를 token 길이, tool call 비율, 세션 길이 기준으로 분류합니다.
• Fable 5.1이 필요한 경로와 작은 모델로 충분한 경로를 분리합니다.
• tool_choice: any 또는 특정 tool 강제 호출을 쓰는 코드를 검색합니다.
• Fable 5.1 요청에서는 auto 또는 none만 보내도록 wrapper에서 검증합니다.
• 모델 라우팅 시 thinking block drop 여부를 로그로 남깁니다.
• 대화 히스토리는 append-only로 유지하고 이전 system/tools/message를 수정하지 않습니다.
• 매 턴 바뀌는 지시는 mid-conversation 또는 turn-scoped system message로 옮깁니다.
• prompt cache hit rate와 cache read 비용 변화를 배포 전후로 비교합니다.
• beta header는 feature flag 뒤에 두고 fallback 경로를 준비합니다.

Claude Fable 5.1 마이그레이션의 핵심은 모델명 교체가 아닙니다. 긴 컨텍스트, 보존된 thinking, 캐시, 도구 호출 정책이 서로 연결되어 있습니다. API wrapper와 대화 저장 구조를 먼저 정리한 뒤 일부 workload부터 옮기는 것이 안전합니다.