Claude Fable 5·Mythos 5 운영 설계: 적응형 추론과 1M 컨텍스트

고정 사고 예산이 사라진 모델

Anthropic이 공개한 Claude Fable 5는 소프트웨어 엔지니어링, 과학 연구, 비전, 자율 에이전트 작업에서 거의 모든 주요 벤치마크의 SOTA(State Of The Art)를 달성한 모델이다. 1M 토큰 컨텍스트 윈도우와 128K 출력 토큰을 지원하며, Anthropic이 일반 출시한 모델 가운데 추론과 장기 에이전트 작업에 가장 강력한 모델로 소개됐다.

Claude Mythos 5의 모델 ID는 claude-mythos-5다. 기존 초청제 Mythos Preview의 후속 모델이며, 그동안 초청제로만 제공되던 Mythos 클래스가 일반 공개에 준하는 형태로 처음 개방됐다는 의미가 있다. 다만 접근 권한은 Project Glasswing 참여를 통해 제공된다. 성능과 가격, API 표면은 Fable 5와 같으므로 운영 관점에서 두 모델의 동작은 사실상 동일하게 다룰 수 있다.

변화의 중심에는 항상 활성화되는 적응형(adaptive) 사고가 있다. 이전 모델에서 쓰던 고정 토큰 예산 budget_tokens는 완전히 제거됐다. 모델이 요청의 난이도를 판단해 사고 깊이를 조절하고, 개발자는 output_config.effort의 low~xhigh, max 설정으로 추론 강도와 전체 토큰 소비를 제어한다.

⤢✕

이 구조는 적응형 사고와 일반 추론의 혼합, 1M 토큰 컨텍스트를 처리하는 KV 캐시, 128K 출력 토큰을 생성하는 파이프라인, 자율 에이전트의 지속 실행 메커니즘으로 이어진다.

사고 블록과 토크나이저가 바꾸는 API 처리

Fable 5와 Mythos 5는 사고를 수행하더라도 그 내용을 그대로 공개하지 않는다. 사고 표시(display)의 기본값은 omitted다. 이 상태에서도 사고는 실행되고 과금되지만, 반환되는 텍스트는 비어 있다. summarized를 지정하면 읽을 수 있는 요약을 받을 수 있으며, 원시 사고 사슬(raw chain of thought)은 어떤 모델에서도 노출되지 않는다.

같은 모델로 대화를 계속한다면 응답에서 받은 사고 블록을 빈 텍스트 블록까지 포함해 그대로 돌려보내야 한다. 도중에 다른 모델로 바꾸면 사고 블록은 조용히 무시된다. 그러나 입력 토큰에는 포함돼 과금되므로 모델을 전환할 때는 제거하는 편이 낫다.

토큰 계산 방식도 달라졌다. 신규 토크나이저는 같은 콘텐츠를 기존 Opus 계열보다 약 30% 많은 토큰으로 나눈다. 다른 모델에서 측정한 토큰 수나 max_tokens 값을 그대로 적용하지 말고, count_tokens API에 model: "claude-fable-5"를 전달해 다시 계산해야 한다.

⤢✕

기존 Opus 계열과 달라진 API 계약

Fable 5와 Mythos 5는 서로 같은 API 표면을 제공하지만 기존 Opus 계열과는 여러 지점에서 동작이 다르다.

항목	Claude Fable 5 / Mythos 5	비고
모델 ID	`claude-fable-5` / `claude-mythos-5`	Mythos 5는 Project Glasswing 전용
컨텍스트 윈도우	1M 토큰	최댓값이 곧 기본값
최대 출력 토큰	128K	큰 값은 스트리밍 필수
사고 메커니즘	적응형 전용	`budget_tokens` 완전 제거, `disabled` 명시 시 400
추론 강도 제어	`output_config.effort`	`low`~`xhigh`, `max` 지원
사고 표시 기본값	`omitted`	`summarized`로 요약 노출 가능
토크나이저	신규(약 30% 토큰 증가)	토큰 수 재측정 필요
어시스턴트 프리필	미지원	4.6+ 계열과 동일, 400 반환
데이터 보존	30일 보존 필수	ZDR 환경에서 400 반환
거부 처리	`refusal` stop_reason	HTTP 200으로 반환, content 점검 필요

운영 코드에서 가장 먼저 반영할 부분은 refusal 처리다. 안전 분류기가 요청을 거부해도 응답은 HTTP 200이며 stop_reason: "refusal"이 설정된다. 출력을 시작하기 전에 거부되면 content 배열은 비어 있고 과금되지 않는다. 스트리밍 도중 거부가 발생하면 이미 전송된 출력에는 과금되므로 부분 결과를 폐기해야 한다. content[0]부터 읽는 코드는 빈 배열에서 인덱스 오류를 일으킬 수 있으므로 stop_reason을 먼저 검사해야 한다.

장기 에이전트에는 Task Budgets가 제공된다. 베타 헤더는 task-budgets-2026-03-13이며, output_config.task_budget으로 에이전트 루프 전체의 허용 토큰을 전달한다. 모델은 남은 예산을 카운트다운으로 인지하고 소비를 조절한다. 모델이 알지 못하는 강제 상한인 max_tokens와는 목적이 다르다.

대용량 컨텍스트를 실제 배포에 연결하기

소프트웨어 엔지니어링이나 과학 연구에 특화된 작업에서는 effort를 high 또는 xhigh로 두고 전체 작업 명세를 처음부터 제공하는 방식이 권장된다. 장기 작업과 에이전트 작업에서는 이 설정에 따른 차이가 더 크게 나타난다.

1M 컨텍스트를 활용한다고 해서 입력 경계를 무시할 수 있는 것은 아니다. 대용량 문서를 임의로 잘라 넣기보다, 한도를 넘을 때 적용할 청킹이나 요약 방식을 미리 정해야 한다. 장기 대화가 1M 컨텍스트를 초과할 가능성이 있다면 서버 측 압축인 Compaction을 사용할 수 있다. 베타 헤더는 compact-2026-01-12이며, 약 150K 토큰 임계에 도달하면 이전 컨텍스트를 자동으로 요약한다. 압축 블록을 잃지 않으려면 매 턴 response.content 전체를 메시지에 추가해야 한다.

⤢✕

비용은 프롬프트 캐싱과 배치 처리를 함께 고려해 관리한다. 캐싱은 접두사 일치(prefix match)를 사용하므로 고정 시스템 프롬프트나 결정적인 도구 목록처럼 안정적인 내용은 앞쪽에 배치한다. 타임스탬프와 요청별 ID처럼 자주 변하는 값은 뒤로 보내야 한다. usage.cache_read_input_tokens가 0이라면 요청의 어떤 요소가 캐시 일치를 깨고 있는지 확인할 필요가 있다.

모델을 교체할 때는 신규 토크나이저를 기준으로 count_tokens를 다시 실행해 토큰 산정의 기준선을 새로 잡는다. 거부 폴백은 베타 fallbacks 파라미터나 SDK의 BetaRefusalFallbackMiddleware로 처리할 수 있다.

벤치마크보다 운영 조건을 함께 봐야 한다

Fable 5는 GPT-5.5, Gemini 3 등 동급 프런티어 모델과 소프트웨어 엔지니어링, 과학 연구, 비전, 자율 작업 벤치마크에서 경쟁한다. 선택 기준을 점수에만 두면 컨텍스트 길이, 추론 제어 방식, 안전과 거버넌스 요건을 놓치기 쉽다.

⤢✕

Fable 5의 운영상 차별점은 고정 사고 예산을 적응형 추론으로 바꾸고, Task Budgets로 자율 에이전트의 장기 실행 예산을 명시한다는 데 있다. 어려운 작업에서는 단일 요청이 수 분간 실행될 수 있다. 타임아웃과 스트리밍 처리뿐 아니라 진행 상태를 보여주는 UX까지 배포 전에 설계해야 한다. 이전 모델을 통제하려고 작성한 지나치게 규범적인 프롬프트가 오히려 출력 품질을 낮출 수 있다는 점도 함께 검토할 대상이다.

성능·비용·거버넌스를 한 구조에서 다루기

적응형 추론은 작업 난이도에 따른 동적 자원 할당과 성능·확장성 사이의 품질 속성 트레이드오프를 보여준다. 1M 컨텍스트를 뒷받침하는 KV 캐시는 캐시 메모리 계층과 성능 최적화 설계의 문제로 이어진다.

거버넌스 측면에서는 30일 데이터 보존 의무와 refusal 안전 분류기를 함께 봐야 한다. 전자는 데이터 보존 정책, 후자는 책임 있는 AI(Responsible AI)를 위한 통제와 연결된다. 시스템 통합에서는 모델 전환, 폴백 미들웨어, 프롬프트 캐싱이 가용성과 운영 효율을 결정한다.

이 관점에서 적응형 사고는 성능과 비용이라는 비기능 요구사항을 조절하는 수단이고, Task Budgets는 자원 거버넌스를 구현하는 통제 수단이다. Fable 5와 Mythos 5는 2026년 AI 시스템 아키텍처를 성능, 비용, 거버넌스의 결합 문제로 읽게 하는 사례다.

배포 전에 확인할 운영 경계

Fable 5와 Mythos 5를 기존 모델의 교체판으로만 다루면 API 경계에서 문제가 생긴다. budget_tokens에 의존하던 코드는 output_config.effort 중심으로 바꿔야 하고, 토큰 수는 신규 토크나이저로 다시 산정해야 한다. 128K 출력을 쓰는 경로에는 스트리밍이 필요하며, 응답 처리에서는 content보다 stop_reason을 먼저 확인해야 한다.

1M 컨텍스트는 긴 입력을 담는 공간인 동시에 청킹, Compaction, 캐싱 정책을 함께 요구한다. 여기에 30일 데이터 보존 요건과 수 분간 이어질 수 있는 에이전트 실행 UX까지 포함해야 실제 엔터프라이즈 배포 구성이 완성된다.