Claude Fable 5 첫인상: 어느 운영자의 관점

목차

2026년 6월 업데이트.

TL;DR: Fable 5는 Anthropic의 가장 강력한 모델이며, 어렵고 장기 호흡이 필요한 에이전트 작업에서 그 진가가 드러난다 — 하지만 기본 업그레이드 대상은 아니다. 토큰당 비용이 더 비싸고, 토큰 수를 약 30% 부풀리는 새 tokenizer를 쓰며, 끌 수 없는 상시 thinking이 돌아가고, 분류기 단계에서 요청을 거부할 수 있다. 대부분의 워크로드에는 여전히 Opus 4.8이 정답이다. 작업이 정말로 어려울 때 Fable 5를 꺼내라.

[운영자의 시선] 나는 컨설팅 브랜드와 피클볼 시설에 걸쳐 30개 이상의 프로덕션 에이전트를 운영한다. 그래서 새 플래그십 모델은 나에게 벤치마크가 아니라 — 비용 항목이자 마이그레이션이다. 실제로 그중 몇 개에 Fable 5를 연결했을 때 무엇이 바뀌었는지, 그리고 어디에는 Opus 4.8을 그대로 남겨 두었는지 이야기해 보겠다.

Fable 5는 실제로 무엇인가

Claude Fable 5는 Anthropic이 폭넓게 출시한 가장 강력한 모델이다. 까다로운 영역의 끝단을 겨냥한다: 깊은 추론과 장기 호흡의 에이전트 작업 — 에이전트가 수십 번의 도구 호출에 걸쳐 흐름을 놓치지 않고 계획을 유지해야 하는 그런 실행들이다.

API 표면은 Opus 4.7/4.8과 거의 동일해서 테스트하기 쉬웠다. 기본 1M 토큰 컨텍스트 윈도우, 요청당 최대 128K 출력 토큰. 최근 Opus 라인에서 무언가를 만들어 본 적이 있다면 요청 형태는 익숙할 것이다. 차이는 세부에 있고, 그 세부에 돈과 의외의 함정이 숨어 있다.

혼동하지 않도록 작명에 관한 메모 하나: Mythos 5는 같은 모델이다 — 같은 성능, 같은 가격, 같은 동작 — Anthropic의 Project Glasswing 프로그램을 통해서만 제공된다. 그 프로그램에 속해 있지 않다면, 당신이 원하는 모델은 claude-fable-5다. 아래 내용은 둘 다에 적용된다.

진짜로 더 나은 지점

가장 어려운 에이전트 작업을 먼저 던졌다: 여러 출처를 읽고, 주장을 교차 검증하며, 인용을 단 브리프를 작성하는 다단계 리서치-종합 실행이다. 약한 모델이 표류하는 부류의 작업이다 — 열 번쯤 도구를 호출하고 나면 어떤 주장이 어느 출처에서 나왔는지 추적을 잃는다.

Fable 5는 흐름을 붙들었다. 종합이 더 탄탄했고, 인용은 올바른 주장에 계속 붙어 있었으며, 내 Opus 4.8 버전이 조용히 평균값으로 뭉개고 있던 출처 간 모순 두 건을 잡아냈다. 길고 구조화된 추론에서는 진짜 한 단계 도약이다 — 미미한 벤치마크 상승이 아니다.

이것이 솔직한 옹호의 근거다. 당신 에이전트의 실패 양상이 “어려운 10%에서 무너진다”라면, Fable 5는 그 격차를 좁혀 준다. 당신 에이전트가 뉴스레터를 요약하거나 소셜 게시물 초안을 쓰는 일을 한다면, 차이를 느끼지 못할 것이다 — 그리고 쓰지도 않을 성능에 비용을 치르게 된다.

아무도 경고해 주지 않는 비용 함정

릴리스 노트를 대충 훑었다면 발목을 잡힐 바로 그 지점이다. Fable 5는 새 tokenizer를 탑재했고, 같은 콘텐츠가 Opus 라인보다 대략 30% 더 많은 토큰으로 토큰화된다.

가격과 복리로 맞물리니 다시 한번 읽어 보라. Fable 5는 애초에 Opus 등급보다 높게 책정돼 있다(입력 토큰 100만 개당 $10, 출력 100만 개당 $50). 이제 모든 프롬프트와 완성 결과 위에 약 30%의 토큰 인플레이션을 얹는다. 변하지 않은 워크로드 — 같은 프롬프트, 같은 출력 — 라도 에이전트가 하는 일을 단 하나도 바꾸기 전에, 마이그레이션 후 의미 있게 더 비싸질 수 있다.

그러니 예전 수치를 재사용하지 마라. 당신의 max_tokens 설정, 컨텍스트 윈도우 예산, 실행당 비용 추정치 — 모두 다른 tokenizer로 측정된 것이다. 좋은 소식: model: "claude-fable-5"를 넘기면 토큰 카운팅 엔드포인트가 두 tokenizer 모두에서의 카운트를 반환하므로, 무언가를 바꾸기 전에 실제 프롬프트에서 그 차이를 측정할 수 있다.

# Measure the tokenizer delta on YOUR prompt before migrating.
# The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old).
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":"<your real prompt>"}] }'

나는 가장 무거운 프롬프트부터 이걸 돌려 봤다. 차이는 균일하지 않았다 — 콘텐츠에 따라 달라진다 — 하지만 “약 30% 더 잡고, 거기에 가격 프리미엄을 더하라”가 올바른 사고 모델이었다.

thinking은 상시 켜져 있다 — 그리고 끌 수 없다

Fable 5에서는 적응형 thinking이 항상 돌아간다. Opus 라인 대비 새로 생긴 단 하나의 호환성 깨짐: 명시적으로 thinking: {type: "disabled"}를 보내면 400을 받는다. 해법은 간단하다 — thinking 파라미터를 통째로 생략하면 된다 — 하지만 저렴하고 빠른 호출을 위해 thinking을 명시적으로 비활성화하던 코드가 있었다면, 그 코드는 이제 오류를 낸다.

원시 사고 사슬(chain of thought)도 그대로 돌려받지 못한다. Fable 5는 그것을 보호한다: 정상적인 thinking 블록을 받고, display: "summarized"로 읽기 좋은 요약을 요청할 수 있지만, 필터링되지 않은 추론은 결코 노출되지 않는다. 대부분의 앱에는 문제가 되지 않는다 — 가시성이 필요하면 요약을 읽으면 된다. 중요해지는 곳은 멀티턴 에이전트다: 같은 모델에서 대화를 이어 갈 때 thinking 블록을 변경 없이 그대로 다시 넘겨야 한다. 그걸 빠뜨리거나 편집하면 해당 턴이 깨진다. 에이전트 루프를 만든다면 thinking 블록을 그대로 들고 가는 불투명 토큰으로 취급하라.

거부(refusal)는 이제 제어 흐름의 문제다

모델 주변에 코드를 어떻게 작성하는지에 가장 큰 영향을 주는 변화다. Fable 5는 들어오는 요청에 안전 분류기를 돌리는데, 주로 연구용 생물학과 대부분의 사이버보안 콘텐츠를 겨냥한다. 요청이 거절되면 stop_reason: "refusal"과 함께 성공적인 HTTP 200을 받는다 — 오류도, 예외도 아니다. content 배열은 비어 있을 수 있다.

당신의 코드가 stop_reason을 먼저 확인하지 않고 response.content[0].text를 한다면, 요청이 거부되는 날 충돌할 것이다. 그리고 인접한 무해한 작업 — 정당한 보안 도구, 생명과학 작업 — 이 가끔 오탐을 일으킬 수 있으니, 이건 수상한 짓을 하는 사람만의 문제가 아니다.

규칙은 이렇다: stop_reason으로 분기하고, 절대 stop_details로 분기하지 마라.

const res = await client.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
});

if (res.stop_reason === "refusal") {
  // classifiers declined — content is empty or partial. Don't read content[0].
  await handleRefusal(res);
} else {
  console.log(res.content[0].text);
}

프로덕션에는 더 깔끔한 길이 있다: 거부된 요청을 같은 왕복 안에서 claude-opus-4-8로 자동 재시도하고, 크레딧 방식의 재가격 책정을 적용하는 서버 사이드 fallbacks 파라미터(베타)다. 에이전트를 무인으로 돌린다면, 단 한 번의 오탐 거부가 실행 전체를 막다른 골목으로 몰지 않도록 이걸 연결해 두라. 이것은 프로덕션에서 계속 실패하는 에이전트에 관해 내가 거듭 다시 배우는 바로 그 교훈이다: 모델이 똑똑해진다고 해서 엣지 케이스를 처리해야 할 필요가 사라지는 게 아니라 — 엣지 케이스의 위치를 옮길 뿐이다.

마이그레이션 세부 사항 둘 더

내 시간을 잡아먹었던 작은 것들 몇 가지, 당신의 시간은 잡아먹지 않도록 적어 둔다:

• 어시스턴트 프리필 없음. 마지막 어시스턴트 턴을 프리필해서 출력을 유도하고 있었다면, 그 패턴은 사라졌다. 대신 구조화된 출력(output_config.format)이나 시스템 프롬프트 지시를 사용하라.
• 30일 데이터 보존 필수. Fable 5는 제로 데이터 보존(zero-data-retention)으로 제공되지 않는다. 규정 준수 이유로 ZDR을 쓰고 있다면, Fable 5는 선택지에서 빠지고 Opus 4.8이 당신의 천장으로 남는다. 마이그레이션을 계획한 뒤가 아니라 전에 이것을 확인하라.

정말 갈아타야 할까?

함께 지내 본 뒤 내 운영자로서의 판단은 이렇다. Fable 5는 기본적인 “최신 모델로 업그레이드” 대상이 아니다 — Opus 4.8이 그렇다. 사람들이 놀라지만, 이게 올바른 틀이다. Opus 4.8은 4.7에서 새로운 호환성 깨짐 없이 모델 ID만 바꾸면 되고, 더 저렴하며, 압도적 다수의 에이전트 작업에서 출력 품질이 구별되지 않는다.

Fable 5는 정말로 어려운 작업에서 제값을 한다: 여러 단계에 걸쳐 일관성을 유지해야 하는 장기 호흡 에이전트, 깊은 다중 출처 추론, 죽이려는 실패가 미묘한 그런 실행들. 그런 경우 성능은 진짜이고 프리미엄을 치를 가치가 있다. 그 외 모든 것 — 콘텐츠 초안 작성, 분류, 라우팅, 요약 — 에서는 체감하지도 못할 품질에 더 많은 토큰을 더 높은 가격으로 치르는 셈이다.

결국 나는 둘 다 돌리게 됐다. 리서치-종합 에이전트는 Fable 5로 옮겼다. 나머지는 전부 Opus 4.8에 남았다. 그 분리가 바로 핵심이다: 유행이 아니라 작업별로 모델을 골라라. 에이전트 함대를 운영한다면, 내가 2026 운영자 스택에서 쓴 것과 같은 규율이 적용된다 — 어려운 일은 비싼 모델로 보내고, 쉬운 일에 과하게 지불하기를 멈춰라.

운영자의 결론

다른 무엇에 손대기 전에 가장 어려운 단 하나의 작업에서 Fable 5를 테스트하라 — 거기가 본전을 뽑는 지점이고, 거기서 바늘이 움직이지 않는다면 어디서도 움직이지 않는다. 실제 프롬프트에 토큰 카운터를 돌려서 약 30%의 tokenizer 인플레이션과 가격 프리미엄이 청구서에서 당신을 놀라게 하지 않도록 하라. Fable 5가 프로덕션에 닿는 모든 곳에 stop_reason: "refusal" 확인(또는 Opus 4.8로의 서버 사이드 폴백)을 추가하라. 그런 다음 의도적으로 라우팅하라: 어려운 10%에는 Fable 5, 나머지에는 Opus 4.8. 최고의 모델은 가장 강력한 모델이 아니라 — 작업에 맞춰진 모델이다.