Claude Fable 5.1 — 캐시 읽기 75% 인하와 breaking change 3건 대응

솔직히 새 모델 출시 소식을 보면 벤치마크 점수부터 훑게 되는데, 이번 Fable 5.1은 그쪽이 핵심이 아니다. 성능 자랑보다 운영비와 API 호환성 이야기가 개발자한테 훨씬 실질적이다. 나는 사내에서 장기 실행 에이전트 파이프라인을 굴리고 있어서, "캐시 읽기 75% 인하"라는 한 줄을 보자마자 우리 청구서의 어느 항목이 줄어드는지가 먼저 계산됐다. 이 글은 그 계산을 같이 해 보고, 딸려 온 breaking change 3건을 실제 코드 수준에서 어떻게 넘기는지 정리한 것이다. (출처는 아래 표기)

무슨 일이 있었나

요약하면, 앤트로픽이 9월 1일 Claude Fable 5.1과 Claude Mythos 5.1을 출시했다. Fable 5.1은 코딩·지식노동·장기 에이전트 작업에 쓰는 최상위 모델로 전체 공개됐고, Mythos 5.1은 사이버보안·생명과학 같은 민감 영역을 다루는 신뢰 접근(trusted-access) 프로그램에만 열렸다. 두 모델 모두 입력 100만 토큰, 출력 12만8천 토큰으로 Fable 5와 용량이 같다.

가격 정책이 이번의 진짜 포인트다. 토큰 단가는 입력 $10, 출력 $50로 Fable 5에서 그대로 동결됐다. 세대가 올라가면서 값이 안 오른 것만 해도 반가운데, 여기에 캐시 읽기 비용을 100만 토큰당 $1.00에서 $0.25로 75% 내렸다. 성능 개선은 조용히 넘어가더라도 이 두 줄은 운영하는 입장에서 흘려보낼 수가 없다.

캐시 읽기 75% 인하가 왜 큰 뉴스인가

결론부터. 프롬프트를 매번 새로 만드는 단발 호출이라면 이번 인하는 체감이 거의 없다. 반대로 같은 앞부분(프리픽스)을 계속 재사용하는 워크로드 — 에이전트 루프, 멀티턴 챗, RAG — 라면 이번 변화가 청구서의 가장 큰 항목을 직접 때린다. 왜냐하면 그런 워크로드에서 매 호출 비용의 대부분은 새로 생성하는 출력이 아니라, 매번 다시 읽어 들이는 고정 컨텍스트이기 때문이다.

프롬프트 캐싱은 tools → system → messages 순서로 렌더링된 프롬프트의 앞부분을 캐시에 넣어 두고, 다음 요청에서 그 접두부가 바이트 단위로 같으면 캐시에서 읽어 온다. 캐시에서 읽는 토큰은 정상 입력가의 약 1/10로 계산됐는데(그래서 $1.00였다), 이번에 그게 다시 1/4로 줄어 정상 입력가의 약 2.5%가 됐다. 캐시에 걸리는 부분은 이제 거의 공짜에 가깝다는 뜻이다.

에이전트를 돌려 본 사람은 안다. 도구 정의 수십 개, 긴 시스템 프롬프트, 그리고 턴이 쌓일수록 불어나는 대화 히스토리 — 이게 매 호출마다 통째로 다시 들어간다. 20턴짜리 세션이면 같은 20만 토큰짜리 접두부를 스무 번 다시 읽는 셈이다. 여기서 읽기 단가가 4배 싸졌다.

실제로 얼마나 줄어드나 — 숫자로

고정 접두부 20만 토큰을 20턴 동안 매 턴 다시 읽는 에이전트 세션을 가정하자. 접두부 재사용 비용만 따지면 이렇게 갈린다.

계산은 단순하다. 20만 토큰 ÷ 100만 × 단가. 캐시 읽기 단가가 $1.00일 때 턴당 $0.20이던 게, $0.25로 내려가면 턴당 $0.05다. 세션 하나에서 접두부 재사용 비용이 $4에서 $1로 떨어진다. 세션이 하루 수만 건이면 이 차이는 그냥 숫자가 아니라 인프라 예산 라인 하나가 통째로 바뀌는 규모다. 그리고 강조하고 싶은 건, 이 절감은 코드를 안 바꿔도 자동으로 적용된다는 점이다. 이미 캐싱을 켜 두고 있었다면 다음 청구서부터 그냥 싸진다.

캐시를 "제대로" 태우는 법

여기서 문서에 잘 안 나오는 함정을 하나 짚자. 캐싱은 접두부 완전 일치(prefix match)다. 앞부분이 단 1바이트라도 바뀌면 그 뒤 전부가 캐시 무효가 된다. 그래서 나는 예전에 시스템 프롬프트 헤더에 현재 시각: {now}를 박아 놓고 왜 캐시 적중률이 0인지 한참 헤맸다. 타임스탬프 한 줄이 매 요청 접두부를 바꿔서, 뒤에 붙은 20만 토큰이 통째로 캐시를 못 타고 있었던 거다.

규칙은 간단하다. 안 변하는 건 앞으로, 매번 변하는 건 뒤로. 시스템 프롬프트는 얼려 두고, 날짜·세션ID·랜덤 UUID 같은 건 뒤쪽 메시지로 밀어라. 그리고 캐시 브레이크포인트는 공유되는 부분의 끝에 찍어야지, 매번 달라지는 질문 뒤에 찍으면 요청마다 새 캐시만 쓰고 아무도 못 읽는다.

# 캐시가 잘 걸리는 배치: 고정 접두부 끝에 브레이크포인트
response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    system=[
        {
            "type": "text",
            "text": STABLE_SYSTEM_PROMPT,   # 절대 안 바뀌는 내용
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {"role": "user", "content": [
            {"type": "text", "text": SHARED_CONTEXT,   # 재사용되는 큰 맥락
             "cache_control": {"type": "ephemeral"}},
            {"type": "text", "text": user_question},   # 매번 다름 → 마커 없음
        ]},
    ],
)

# 캐시 적중 확인 — 이게 0이면 어딘가에서 접두부가 깨지고 있는 것
print(response.usage.cache_read_input_tokens)
print(response.usage.cache_creation_input_tokens)

확인은 반드시 usage.cache_read_input_tokens로 하자. 이 값이 동일 접두부 반복 요청에서 계속 0이면, 십중팔구 조용한 무효화범인이 있다 — 시스템 프롬프트 안의 datetime.now(), 정렬 안 된 JSON 직렬화, 요청마다 바뀌는 도구 목록 같은 것들. 두 요청의 렌더링된 프롬프트 바이트를 실제로 diff 떠 보면 대개 범인이 바로 나온다.

Breaking change 3건 — 한눈에

공짜 절감만 있으면 좋겠지만, 이번 릴리스는 API breaking change 3건을 요구한다. 문서 기준으로 정리하면 이렇다.

세 번째는 조건이 하나 붙는다. 자료에 따르면 히스토리 수정에 따른 thinking 무효화 규칙은 2026년 8월 31일 이후에 생성된 계정에 적용된다. 기존 계정이라면 당장은 예전 동작을 유지할 수 있지만, 새 계정으로 붙는 신규 프로젝트라면 처음부터 이 규칙 위에서 설계하는 게 맞다.

각 breaking change 대응법

세 개를 어떻게 넘기느냐가 실무의 전부다. 하나씩 코드로 보자.

1) 강제 도구 선택 제거. 그동안 특정 도구를 반드시 부르게 tool_choice를 강제하던 코드는 이제 통하지 않는다. 개인적으로는 애초에 강제 호출에 의존하는 설계를 별로 안 좋아했는데(모델이 판단할 여지를 뺏는 구조라), 이번 기회에 걷어내는 게 낫다. 대안은 두 갈래다. 출력 형식을 고정해야 했던 거라면 구조화 출력으로, 특정 함수 호출을 유도하고 싶었던 거라면 strict 도구 + 프롬프트로 유도다.

# 이제 안 됨: 특정 도구 강제
# tool_choice={"type": "tool", "name": "extract"}

# 대안 A) 출력 형식 고정이 목적이었다면 → 구조화 출력
response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    output_config={"format": {"type": "json_schema", "schema": SCHEMA}},
    messages=[{"role": "user", "content": "..."}],
)

# 대안 B) 특정 도구 호출 유도가 목적이었다면 → strict + 명확한 지시
tools = [{
    "name": "extract",
    "description": "사용자 입력에서 필드를 추출할 때 반드시 이 도구를 호출한다.",
    "strict": True,
    "input_schema": {"type": "object",
        "properties": {"name": {"type": "string"}},
        "required": ["name"], "additionalProperties": False},
}]

2) thinking을 모델이 고정. Fable 계열은 원래 추론(thinking)이 항상 켜진 방향으로 가고 있었는데, 5.1에서 그게 더 확실해졌다. thinking 방식은 모델이 잡고, 개발자는 켜고 끄는 스위치가 아니라 깊이 조절 손잡이만 쥔다. 즉 budget_tokens로 토큰 예산을 박거나 disabled로 끄려던 코드는 걷어내고, 대신 effort로 조절해야 한다.

# 이제 통하지 않는 패턴 (예산 지정 / 강제 비활성)
# thinking={"type": "enabled", "budget_tokens": 8000}
# thinking={"type": "disabled"}

# 깊이는 effort로 조절 (output_config 안, 최상위 아님)
response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    output_config={"effort": "high"},  # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": "..."}],
)

사용자에게 추론 과정을 보여 주고 있었다면 하나 더 챙기자. 원문 사고 과정(raw chain of thought)은 반환되지 않고, 요약본을 받으려면 display: "summarized"를 명시해야 한다. 기본값은 요약도 비워서 내보내기 때문에, 스트리밍 UI에서는 출력 전에 긴 정적처럼 보인다 — 처음 겪으면 버그로 오해하기 쉽다.

3) 히스토리 수정 시 thinking 무효화. 이게 이번 셋 중 제일 헷갈리는 지점이다. 컨텍스트 편집·압축(compaction)·수동 트리밍 등으로 대화 히스토리를 손대면, 캐시돼 있던 thinking이 무효가 된다. 같은 모델로 대화를 이어 갈 땐 받은 thinking 블록을 손대지 말고 그대로 되돌려 보내는 게 원칙이다. 편집이 불가피하면, 그 턴은 캐시 재작성과 재추론 비용을 감수해야 한다고 계산에 넣어라.

# 원칙: 같은 모델로 이어갈 땐 thinking 블록을 원형 그대로 append
messages.append({"role": "assistant", "content": response.content})
# response.content 전체를 넣는다 — 텍스트만 뽑아 넣으면 thinking이 사라지고
# 정렬/서명 검증에서 400이 날 수 있다.

# 히스토리를 편집(압축·트리밍)해야 한다면, 그 턴은
# 캐시된 thinking 무효 + 재추론 비용이 발생한다고 가정하고 예산을 잡는다.

안전·보안 쪽 변화도 같이 왔다

개발비 얘기만 하다 놓치기 쉬운데, 정책 변화도 붙어 있다. Fable 5.1은 이제 소프트웨어 취약점 식별을 허용한다 — 보안 도구를 만드는 입장에선 반가운 완화다. 다만 침투 테스트, 익스플로잇 생성, 바이너리 기반 취약점 스캐닝 같은 고위험 작업은 여전히 더 제한적인 Opus 계열로 우회시킨다. 즉 "취약점을 찾아 설명"까지는 열렸지만 "공격 코드를 만들어"는 여전히 막혀 있다고 보면 된다.

Mythos 5.1은 사이버·생명과학 등 민감 영역을 겨냥한 신뢰 접근 전용으로 남았고, 적대적 입력에 대한 거부율이 이전 세대와 대등하며 프롬프트 인젝션 벤치마크에서 최상위 성능을 보였다고 보고됐다. 여기에 앤트로픽은 Enterprise Frontier Safeguards(EFS)를 도입했다 — 제로 데이터 보존(ZDR)과 오남용 탐지를 결합하되, 데이터 처리 통제권은 조직에 주는 방식이다. 기업 환경에서 도입 심사를 통과시켜야 하는 사람이라면 이 항목이 실무적으로 쓸모 있다.

지금 당장 할 일

정리하면 우선순위는 이렇다. 위에서부터 순서대로 밟으면 된다.

1. 캐싱을 이미 켜 뒀다면 아무것도 안 해도 다음 청구서부터 싸진다. 먼저 cache_read_input_tokens가 실제로 잡히는지부터 확인하라 — 0이면 절감을 통째로 놓치고 있는 것이다.
2. 강제 tool_choice 사용처를 grep으로 찾아 구조화 출력 또는 strict 도구로 교체한다.
3. budget_tokens·thinking:{disabled}를 제거하고 effort로 옮긴다. 추론을 사용자에게 보여 준다면 display:"summarized"를 켠다.
4. 히스토리를 편집·압축하는 로직이 있으면, 8월 31일 이후 생성 계정에서 thinking 캐시가 무효화된다는 점을 감안해 재추론 비용을 예산에 넣는다.
5. 모델 문자열을 바꾸기 전, 대표 요청 하나로 먼저 돌려 stop_reason·usage·thinking 동작을 눈으로 확인한 뒤 전체 롤아웃한다.

개인적인 감상 하나. 이번 릴리스는 "더 똑똑해졌다"보다 "돌리기 더 싸졌고 API가 정리됐다"에 방점이 찍혀 있다. 신모델 경쟁이 성숙기에 들어서면 결국 이런 운영 편의와 단가가 실무 채택을 가른다. 캐시 절감은 냉큼 챙기되, breaking change 3건은 미루지 말고 한 스프린트 잡아 정리해 두는 걸 권한다.

자주 묻는 질문

캐시 읽기 75% 인하는 코드를 바꿔야 적용되나요?

아니다. 이미 프롬프트 캐싱을 켜 두고 있었다면 코드 변경 없이 자동 적용된다. 캐시 읽기 단가가 100만 토큰당 $1.00에서 $0.25로 내려간 것이므로, cache_read_input_tokens로 계산되던 부분이 그대로 싸진다. 다만 캐싱을 안 쓰고 있었다면 이 인하의 혜택이 없으니, 재사용되는 접두부에 캐싱을 먼저 붙여야 한다.

Fable 5.1은 Fable 5보다 토큰 단가가 올랐나요?

아니다. 입력 $10, 출력 $50로 Fable 5에서 동결됐다. 세대가 올라가면서 단가가 유지된 데다 캐시 읽기는 오히려 내려갔으니, 전체 운영비는 같은 워크로드 기준으로 내려간다고 보면 된다.

강제 도구 선택이 사라졌는데 특정 도구를 반드시 부르게 하려면?

목적을 나눠서 접근한다. 출력 형식을 고정하고 싶었던 거라면 output_config.format의 구조화 출력을 쓰고, 특정 함수 호출을 유도하고 싶었던 거라면 strict:true 도구에 "언제 이 도구를 호출하라"는 트리거 조건을 설명으로 명확히 적어 유도한다. 최신 모델은 강제하지 않아도 명확한 지시에 잘 따른다.

thinking 예산(budget_tokens)을 못 쓰면 추론 깊이는 어떻게 조절하나요?

output_config.effort로 조절한다. low·medium·high·xhigh·max가 있고, 코딩·에이전트 작업은 xhigh, 지능이 중요한 일반 작업은 high를 기본으로 두는 게 무난하다. 고정 토큰 예산 개념 자체가 이제 이 effort 손잡이로 대체됐다고 이해하면 된다.

히스토리 수정 시 thinking 무효화는 모든 계정에 적용되나요?

자료 기준으로는 2026년 8월 31일 이후 생성된 계정에 적용된다. 기존 계정은 당장은 이전 동작을 유지할 수 있으나, 새 계정으로 시작하는 프로젝트라면 처음부터 "히스토리를 편집하면 thinking 캐시가 깨진다"는 전제로 컨텍스트 관리를 설계하는 편이 안전하다. 편집보다 덧붙이기 위주로 가면 캐시 접두부가 유지된다.

Fable 5.1로 취약점 분석 도구를 만들어도 되나요?

취약점 식별은 허용됐다. 다만 침투 테스트, 익스플로잇 생성, 바이너리 기반 취약점 스캐닝 같은 고위험 작업은 더 제한적인 Opus 계열로 우회되므로, "찾아서 설명"까지는 되지만 "공격 코드 생성"은 기대하기 어렵다. 보안 워크로드라면 안전 분류기에 의한 거부(refusal) 처리 경로도 함께 넣어 두는 게 좋다.

Mythos 5.1은 그냥 API 키로 쓸 수 있나요?

아니다. Mythos 5.1은 사이버보안·생명과학 등 민감 영역을 겨냥한 신뢰 접근(trusted-access) 프로그램에만 열려 있다. 일반 개발자가 바로 붙이는 건 전체 공개된 Fable 5.1이고, Mythos는 별도 승인 절차가 필요하다.