본고는 어제 공개한 기사의 개정판이며, 전고의 내용을 모두 포함하고 있다.

2026년 6월 중순 이후, Claude Opus 4.8의 출력 품질이 눈에 띄게 떨어지는 상황을 마주할 때가 있다. 특히 Claude Code에서 근본적인 언어 능력의 저하나 과도한 선제적 대응(anticipation)이 늘어나는 경우가 있다. 하지만 이는 시간이 지나면 원래대로 돌아온다.

사용자 입장에서 보면, 이것은 일시적인 nerf(성능 저하)이다.

다만, 여기서 말하는 nerf는 "같은 모델 이름 뒤에서 다른 가중치(weights)를 가진 모델로 몰래 교체되었다"는 의미는 아니다. 그렇게 단정하기에는 증거가 부족하다. 오히려 Anthropic의 공식 문서를 보면, Claude API의 claude-opus-4-8이라는 동일한 model ID에 대해 weights/configuration이 기존 ID 그대로 업데이트되었다고 주장하기는 어렵다.

한편, 그것이 "사용자가 받는 Opus 4.8의 품질이 불변이다"라는 의미는 아니다. 동일한 model ID라도 추론(inference) 시의 거동을 좌우하는 주변 설정은 변할 수 있다. Anthropic의 용어로는 이 계층을 serving infrastructure라고 설명한다. 또한 Claude.ai에서는 system prompt가 정기적으로 업데이트된다. 나아가 Claude Code에서는 provider alias, Default 해결, fallback, effort, ultracode, dynamic workflows, tool runtime, subagent, context compaction, client version, rate limiting이 실효 거동에 관여한다.

따라서 본고에서는 nerf를 두 가지로 나눈다.

종류	의미	본고에서의 취급
모델 본체의 nerf	동일한 모델명 아래에서 weights/configuration이 능력 저하 방향으로 변경됨	직접적인 증거 없음. 단정하지 않음
실효 품질의 nerf	동일 모델이라도 실용 성능이 떨어짐	본고의 핵심 명제

본고의 결론은 다음과 같다.

Opus 4.8의 API model ID는 고정된 snapshot이며, weights/configuration이 동일한 ID인 상태에서 nerf되었다는 직접적인 증거는 없다. 하지만 2026년 6월 12일 Fable 5 / Mythos 5 중단 이후, Opus 4.8이 대체 수단으로 안내되는 사례, Opus 4.8의 공식 장애, Claude Code 상에서의 지시 외 작업·미검증 완료·가공의 사용자 발화·tool-call 파손·agent 폭주·rate limiting·token burn 보고가 다수 확인된다. serving infrastructure나 제품 계층의 거동을 변경할 수밖에 없는 상황이 발생했을 가능성이 있으며, 실제로 많은 사용자 보고도 올라오고 있다. 이는 Opus 4.8 표시 하에서의 실효 품질의 nerf이다. 다만, 그 원인은 모델의 교체가 아니라 여러 레이어의 합성으로 다루어야 한다.

이 기사에서는 확정 사실, 정황 증거, 추정을 구분한다.

1. 조사의 전제

1.1 「nerf」는 계층을 나누지 않으면 논의할 수 없다

"nerf되었다"는 표현은 체감을 나타내는 말로서는 편리하지만, 기술적으로는 모호하다. 적어도 다음의 계층들이 섞여 있다.

계층	구체적인 예	사용자의 관점
가중치 (모델 본체)	RLHF, SFT, 증류 (distillation), 양자화 (quantization), 체크포인트 교체	정말로 지능이 변함
...

사용자가 "Opus 4.8이 nerf되었다"고 느낄 때, 실제로는 가중치(모델 본체)가 아니라 제2계층 이하의 변화일 가능성이 있다.

이 점에 대해서는 선례가 있다. 2026년 4월, Anthropic은 Claude Code의 품질 저하 보고에 대해 모델을 의도적으로 저하시킨 것은 아니라고 하면서도, 실제로 품질 문제가 발생했음을 인정했다. 원인은 Claude Code의 기본 reasoning effort를 high에서 medium으로 변경한 것, thinking 이력 삭제 버그, 단문화된 system prompt의 부작용이었다. [1]

즉, Claude Code에서는 모델 본체가 동일하더라도 effort나 제품 계층의 변경만으로 "지능이 떨어졌다"고 느껴질 수 있다.

1.2 같은 「Opus 4.8」이라도, 무엇이 불변이고 무엇이 변할 수 있는가

이번 논의에서는 "같은 Opus 4.8을 사용하고 있다"라는 표현을 분해할 필요가 있다. 특히 Claude API, Claude.ai, Claude Code에서는 불변성의 보장 범위가 다르다.

1.2.1 Claude API의 동일 model ID는 무엇을 고정하는가

Anthropic은 model ID에 대해 다음과 같이 설명하고 있다.

“pinned version” / “underlying model remains constant” (고정된 버전 / 기반 모델은 일정하게 유지됨)

[2]

또한, Claude 4.6 세대 이후의 dateless ID에 대해서는 다음과 같은 설명이 있다.

“single, fixed model snapshot” (단일한 고정 모델 스냅샷)

[2:1]

나아가 기존 ID의 취급에 대해 Anthropic은 다음 취지의 내용을 명시하고 있다.

“does not update the weights or configuration” (가중치(weights)나 설정(configuration)을 업데이트하지 않음)

[2:2]

이 기술로부터 직접적으로 알 수 있는 것은, API에서 claude-opus-4-8을 명시하고 있는 경우, 해당 model ID의 weights/configuration은 고정된다는 점이다. 따라서 "같은 API model ID를 유지한 채, 모델 본체의 가중치나 설정이 몰래 교체되었다"라고 주장하는 것은 공식 문서(docs)와 일치하지 않는다.

다만, 동일한 페이지에서 model weights와 serving infrastructure(서빙 인프라)를 구분하고 있다.

“serving infrastructure ... can change over time” (서빙 인프라는 ... 시간이 지남에 따라 변할 수 있음)

[2:3]

여기서 말하는 infrastructure에는 request router(요청 라우터), safety classifiers(안전 분류기), sampling logic(샘플링 로직)이 포함된다고 설명되어 있다. 따라서 API의 동일한 model ID에 대해서도, "weights/configuration이 고정된다"는 것과 "관측되는 동작(behavior)이 완전히 불변이다"라는 것은 같은 의미가 아니다.

정리하면 다음과 같다.

명제	판정
claude-opus-4-8이라는 동일 API model ID의 weights/configuration은 고정인가	공식 문서상 고정
동일 API model ID의 관측 동작까지 완전히 불변인가	불변이라고 할 수 없음
동일 API model ID라도 serving infrastructure는 변할 수 있는가	공식 문서상 변할 수 있음
"같은 ID인 채로 모델 본체가 nerf(성능 저하)되었다"라고 쓸 수 있는가	쓰기 어려움. 공식 문서에 반함
"같은 ID라도 실효 동작은 변할 수 있다"라고 쓸 수 있는가	쓸 수 있음

1.2.2 Claude.ai / 웹 버전은 API와 동일한 고정성을 갖지 않는다

Claude.ai, 즉 웹 버전의 경우에는 API와 동일한 불변성이 나타나지 않는다. Anthropic은 Claude의 web interface와 mobile apps에 대해, 대화 시작 시 system prompt(시스템 프롬프트)를 사용한다고 설명한다. 나아가 해당 system prompt에 대해 다음과 같이 언급하고 있다.

“periodically updated” / “do not apply to the Claude API” (주기적으로 업데이트됨 / Claude API에는 적용되지 않음)

[3]

즉, 웹 버전의 "Opus 4.8"은 API의 claude-opus-4-8과 동일한 수준의 고정성을 갖는다고 말할 수 없다. 설령 기초 모델이 동일한 snapshot이라 하더라도, system prompt가 업데이트되면 사용자가 관측하는 출력 동작은 변할 수 있다.

여기서 중요한 점은 이것이 추측이 아니라, 공식 문서가 명시하고 있는 제품상의 차이라는 것이다. API model ID의 고정성으로부터 Claude.ai의 실효 동작의 고정성을 도출할 수는 없다.

1.2.3 Claude Code에서는 alias, Default, fallback, effort가 실효 동작을 변화시킨다

Claude Code는 더욱 복잡하다. Claude Code 문서에서는 model alias(모델 별칭)에 대해 다음과 같은 설명이 있다.

“update over time” (시간에 따라 업데이트됨)

[4]

이는 opus나 sonnet과 같은 alias가 고정된 model ID와는 다르다는 것을 의미한다. Claude Code 문서에 따르면, Anthropic API에서 opus는 Opus 4.8로 해결(resolve)되지만, provider(제공자)에 따라 해결되는 대상이 달라질 수 있다. 특정 버전에 고정하기 위해서는 claude-opus-4-8과 같은 full model name(전체 모델 이름)을 사용해야 한다. [4:1]

또한, Claude Code에는 fallback model chains(폴백 모델 체인)이 있다. 문서는 primary model(기본 모델)이 overloaded(과부하), unavailable(사용 불가), 또는 non-retryable server error(재시도 불가능한 서버 오류)를 반환할 경우, Claude Code가 fallback model(폴백 모델)로 전환될 수 있다고 설명한다. 여기서 중요한 점은, 동일하게 "Opus 4.8을 사용하고 있다"는 사용자 경험의 이면에서, availability(가용성)나 server error(서버 오류)를 계기로 model chain(모델 체인)이 개입할 수 있다는 점이다. [5]

Fable 5에서는 추가로, content-based fallback(콘텐츠 기반 폴백)이 존재한다. Claude Code 문서는 Fable 5의 safety classifier(안전 분류기)가 flag(플래그)한 request(요청)에 대해, Claude Code가 default Opus model(기본 Opus 모델)로 재실행한다고 설명한다. Anthropic API에서 이 fallback(폴백) 대상은 Opus 4.8이다. [5:1]

그리고 Claude Code에서는 effort(노력도) 또한 제품 계층의 중요한 변수이다. 문서는 high가 Opus 4.8의 default(기본값)라고 하면서도, xhigh, max, ultracode를 구분하고 있다. 특히 ultracode에 대해서는 다음과 같은 설명이 있다.

“rather than a model effort level” [6]

즉, ultracode는 모델에 전달하는 effort(노력도) 그 자체가 아니라, Claude Code 측에서 dynamic workflows(동적 워크플로우)를 추가하는 session-only(세션 전용) 설정이다.

따라서 Claude Code에 대해서는 다음과 같이 정리할 필요가 있다.

명제	판정
Claude Code에서 "Opus 4.8"이라고 표시되면, API의 claude-opus-4-8과 동일한 weights(가중치)가 사용될 가능성이 높은가	높다. 다만 표시 이름만으로는 실행 조건 전체를 알 수 없다
그 경우, API model ID의 weights/configuration(가중치/설정)은 고정인가	공식 docs(문서)상으로는 고정
Claude Code의 실효 동작은 고정인가	고정이라고 할 수 없다
변동 요인	Claude Code version, provider alias, Default 해결, effort, fallback, ultracode, dynamic workflows, tool runtime, subagent, context compaction, settings, environment variable, serving infrastructure
사용자에게 대화 단위의 명시적 설명 없이 실효 동작이 변할 수 있는가	변할 수 있다

이러한 구분은 중요하다. "API model ID의 가중치가 동일한 ID 상태에서 교체된다"는 가능성은 확실히 여러 번 고려해 볼 만하다. 하지만 이는 Anthropic의 공식 정보와는 일치하지 않는다.

반면, "동일한 Opus 4.8 표시라도, web(웹) 버전이나 Claude Code의 실효 품질은 변할 수 있다"라고 기술할 수는 있다. 오히려 공식 docs상에서도 API의 serving infrastructure(서빙 인프라), web 버전의 system prompt(시스템 프롬프트), Claude Code의 alias(별칭), Default, fallback, effort, dynamic workflows는 변화할 수 있는 계층으로 존재한다.

따라서 본고에서는 이후, "Opus 4.8의 가중치(모델 본체)가 동일한 ID 상태에서 nerf(성능 저하)되었다"는 주장은 채택하지 않는다. 대신, "동일한 Opus 4.8 하에서 hyperparameter(하이퍼파라미터, serving infrastructure)가 변화하여, 사용자가 관측하는 실효 품질이 저하되었을 가능성"을 검토한다.

1.3 코호트(Cohort)를 나누기

이번 초점은 2026년 6월 12일의 Fable 5 / Mythos 5 중단 이후이다. 따라서 보고는 시기에 따라 나눌 필요가 있다.

기간	의미
5/28~6/8	Opus 4.8 공개 직후. 4.8 고유의 선행 regression(회귀/성능 저하)을 확인하는 기간
...	6/12 이전의 보고는 Fable/Mythos 중단의 영향을 보여주는 증거로 사용하기 어렵다. 다만, "Opus 4.8에는 중단 전부터 Claude Code상의 regression 의혹이 있었다"는 기초선(baseline)으로서 중요하다.

6/12 이후의 보고는 「Fable/Mythos 중단 이후 Opus 4.8의 실효 품질이 불안정해졌을 가능성」의 후보 증거로 취급한다.

2. 확정된 공식 사실

2.1 Opus 4.8은 5월 28일에 공개되었다

Anthropic은 2026년 5월 28일에 Claude Opus 4.8을 공개했다. 공식 발표에서는 Opus 4.8이 Opus 4.7을 토대로 벤치마크(benchmark), 에이전트 태스크(agent task), 협업성(collaborative capability)을 개선한 모델이라고 설명하고 있다. [7]

공식 docs 상에서 Opus 4.8의 Claude API ID는 claude-opus-4-8이다.

모델 비교표에서는 Opus 4.8이 복잡한 추론(reasoning), 에이전트 코딩(agentic coding), 고도의 자율 작업에 적합한 Opus-tier 모델로 분류되어 있다. [8]

동시에 중요한 점은 Opus 4.8에서는 노력 제어(effort control)가 도입 및 강조되고 있다는 점이다. Claude Code docs에서 Opus 4.8의 기본 노력(default effort)은 high로 설정되어 있다. [6:1] 즉, Opus 4.8의 품질은 모델명뿐만 아니라 어떤 노력(effort) 수준으로 실행되었는지에 따라서도 의존한다.

2.2 Fable 5와 Mythos 5는 6월 9일에 공개되었고, 6월 12일에 중단되었다

Anthropic은 2026년 6월 9일에 Claude Fable 5와 Claude Mythos 5를 발표했다. 발표 기사에서는 Fable 5에 대해 일반 제공된 모델로서 매우 높은 능력을 갖추고 있다고 설명하면서도, 안전상의 이유로 일부 쿼리(query)에서는 Opus 4.8로 폴백(fallback)한다고 밝혔다. [9]

Fable 5와 Mythos 5는 6월 12일에 중단되었다. Anthropic의 성명은 미국 정부의 수출 관리 지침에 따라 Fable 5 / Mythos 5에 대한 액세스(access)를 중단해야 할 상황이 발생했다고 설명했다. 성명 중에서는 모든 고객을 대상으로 두 모델을 무효화하는 것을 다음과 같은 짧은 표현으로 설명하고 있다.

“abruptly disable” / “all our customers” [10]

동시에 Anthropic은 타 모델에 대한 액세스에 대해 다음과 같이 언급했다.

“will not be affected” [10:1]

따라서 「Fable/Mythos 중단으로 인해 Opus 4.8이 공식적으로 저하되었다」라고 읽을 수는 없다. 영향이 없다고 명시된 것은 액세스 가능 여부이며, 서빙 품질(serving quality), 혼잡도, 레이턴시(latency), 에러율(error rate)에 대한 간접적인 영향까지 부정된 것은 아니라는 정도로 한정해야 한다.

2.3 Fable 5에는 Opus 4.8로의 폴백(fallback) 설계가 있었다

Fable 5는 일부 리스크 영역을 Opus 4.8로 넘기는 설계를 가지고 있었다. Anthropic의 Fable 5 발표에서는 리스크 분류기(risk classifier)가 탐지한 일부 쿼리(query)에 대해 다음과 같이 설명하고 있다.

“response from our next-most-capable model” [9:1]

다른 부분에서는 Opus 4.8로의 폴백(fallback)을 더 직접적으로 설명하고 있다.

“fall back to Opus 4.8” [9:2]

이는 중요하다. Fable 5는 처음부터 「Fable이 답하지 못하는 영역을 Opus 4.8로 넘기는」 설계였다. 따라서 Fable 5 공개 시점에 Opus 4.8에는 기존의 Opus 4.8 이용에 더해 Fable 5로부터의 폴백(fallback) 부하가 가해지는 구조가 있었다.

다만, 이로부터 「Fable/Mythos 중단 후 Fable의 모든 트래픽이 Opus 4.8로 흘러 들어갔다」라고까지 단정할 수는 없다. 공식적으로 확인할 수 있는 것은 Fable 5가 일부 쿼리를 Opus 4.8로 폴백(fallback)하고 있었다는 점, Fable/Mythos가 6월 12일에 중단되었다는 점, 중단 후에 Opus 4.8이 대체 후보가 되기 쉽다는 점까지이다. 전체 물량 유입은 추정일 뿐이다.

2.4 effort UI의 일시적인 변동은 사양 변경이 아닌 관측 조건으로 취급한다

2026-06-15 시점에 사용자 환경에서는 Claude Code의 effort UI가 High → Extra → Max → Ultra로 보였다. 반면, 2026-06-18에는 일시적으로 High → Max와 같이 보이기도 했다. 그러나 이후 Claude Code 업데이트를 적용하자 원래의 표시 체계로 돌아왔다.

따라서 이 관찰은 "공식적으로 effort 체계가 축소되었다"는 증거가 아니다. 오히려 빈번한 Claude Code 업데이트에 따른 UI, 클라이언트 상태, 모델 eligibility(적격성) 판정, 또는 일시적인 표시 불일치로 취급해야 한다.

공식 docs상, Opus 4.8과 Opus 4.7은 low, medium, high, xhigh, max를 지원한다. Opus 4.8의 default effort는 high이다. ultracode는 model effort level이 아니라, 모델에는 xhigh를 보내고 Claude Code 측에서 dynamic workflows (동적 워크플로우)를 추가하는 session-only (세션 전용) 설정이다. [6:2]

따라서 본문에서는 다음과 같이 다룬다.

관찰	판단
6/18에 일시적으로 High → Max로 보였다	사용자 환경에서의 일시적 관찰
업데이트 후 원래 표시로 복귀	공식 사양 변경이 아닐 가능성이 높음
공식 docs에서는 xhigh, max, ultracode가 유지됨	effort 체계 축소의 공식적 근거 없음
본문에서의 취급	인과적 증거가 아닌, 6/17~6/18의 Claude Code 업데이트 빈도 및 UI 흔들림에 대한 보조 정보

이 점은 이번 논의에서 상당히 중요하다. High → Max를 "추론 비용(inference cost) 절감의 명백한 증거"라고 기술하면 과잉 단정이 된다.

3. 6/12 이전부터 존재했던 선행 regression (성능 퇴보)

6/12 중단 이후의 저하를 논하기 전에, Opus 4.8에는 공개 직후부터 Claude Code상에서 regression 보고가 있었다는 점을 확인해 둘 필요가 있다.

일시	보고	개요	의미
2026-05-30	Issue #63861	canonical build (표준 빌드)를 실행하지 않고 verified green / done이라고 주장. 사용자가 정식 빌드를 실행하자 다수의 failure (실패) 발생.	미검증 완료 보고의 선행 사례. [11]
2026-05-30	Issue #64065	tool (도구) 결과가 반환되기 전에 구체적인 검색 결과를 단정. 이후 실제 결과와 불일치.	tool output (도구 출력) 선취의 선행 사례. [12]
2026-05-30	Issue #64076	실제 작업 없이 작업 완료 및 결과를 날조했다고 보고.	fake tool execution (가짜 도구 실행) / hallucinated tool result (환각된 도구 결과)의 선행 사례. [13]
2026-06-02	Issue #64774	Opus 4.8에서만 약 1.5%의 tool-call parse failures (도구 호출 파싱 실패)가 발생한다고 보고.	tool-call (도구 호출) 손상의 선행 사례. [14]
2026-06-02	Issue #64961	Opus 4.7/4.8에서 token usage (토큰 사용량)가 2~3배 증가했다고 보고.	token burn (토큰 소모)의 선행 사례. [15]
2026-06-07	Issue #66023	Workflow tool이 46개의 Opus subagents를 spawn (생성)하여 약 3M tokens를 소비.	agent workflow (에이전트 워크플로우) 폭주의 선행 사례. [16]
2026-06-09	Issue #66539	2026-06-08 이후, CLAUDE.md 무시, permission bypass (권한 우회), unprompted file writes (요청되지 않은 파일 쓰기) 등 발생.	6/12 이전부터의 급락 보고. [17]
2026-06-10	Issue #66888	tool-call boundary token (도구 호출 경계 토큰)이 court / count / call 등으로 깨지며, raw XML이 유출됨.	6/18의 유사 보고로 이어지는 선행 사례. [18]
2026-06-11경	Issue #67606	장문맥(long-context) session에서 사용자 발화나 command history (명령 이력)를 confabulate (작작/날조).	대화 이력 날조의 선행 사례. [19]
2026-06-12경	Issue #67847	no tool_use (도구 사용 없음)임에도 불구하고, Opus 4.8이 도구를 실행했다고 믿고 fake results (가짜 결과)를 보고.	tool grounding (도구 근거 설정) 붕괴의 선행 사례. [20]

대표적인 사례로, Issue #64774는 Opus 4.8 고유의 tool-call parse failure (도구 호출 파싱 실패)를 통계적으로 보여주려 한 보고이다. 보고 본문은 Opus 4.8에 대해 다음과 같은 에러를 언급하고 있다.

“tool call could not be parsed”

[14:1]

동일한 Issue에서는 로컬 session logs (세션 로그)를 기반으로, Opus 4.8에서는 약 9,805건의 assistant turns (어시스턴트 턴) 중 148건의 parse failures (파싱 실패)가 발생한 반면, Sonnet 4.6이나 Opus 4.7에서는 0건이었다고 보고하고 있다. 이는 피어 리뷰 (peer-reviewed)를 거친 논문은 아니지만, 단순한 인상론보다는 강력한 관찰 결과이다. [14:2]

이 표를 통해 알 수 있는 것은, 6/12가 '제로(0)에서부터 열화가 시작된 날'은 아니라는 점이다. Opus 4.8에는 공개 직후부터 Claude Code 상에서 tool-use (도구 사용), token (토큰) 소비, agent (에이전트) 제어, 이력 관리와 관련된 문제 보고가 나오고 있었다.

따라서 Fable/Mythos 중단이 유일한 원인은 아니다. 더 정확하게는, 기존의 불안정성에 Fable/Mythos 중단, 대체 이용, 공식 장애, rate limiting (속도 제한), agent runtime (에이전트 런타임) 문제가 겹치면서, 6/12 이후로 더욱 관측되기 쉬워졌을 가능성이 있다.

4. Fable 공개 후, 중단 전부터 Opus 4.8로의 fallback (폴백)은 일어나고 있었다

Fable 5는 6월 9일에 공개되었으나, 중단 전부터 Fable이 Opus 4.8로 fallback 하는 보고가 여러 건 있었다.

일시	보고	개요	의미
2026-06-09	Issue #66657	Fable 5 classifier (분류기)가 bare greeting (단순 인사)에도 Opus 4.8로 fallback 한다고 보고.	과도한 fallback의 선행 사례. [21]
2026-06-09	Issue #66671	Fable 5에서 hi만 입력해도 blocked / switched to Opus 4.8.	일반적인 입력에서도 fallback 하는 사례. [22]
2026-06-09	Issue #66696	code review (코드 리뷰) 중 Fable이 Opus 4.8로 fallback.	일반적인 개발 작업 중에도 fallback. [23]
2026-06-10	Issue #67009	Fable fallback 후, Opus 4.8에서 자동으로 복귀하지 않음.	한 번 fallback 하면 session (세션)이 Opus 4.8화 되는 경로. [24]
2026-06-10	Issue #67107	CVP 승인 상태임에도 security (보안) 관련 prompt (프롬프트)에서 Fable이 Opus 4.8로 fallback.	정규 사용자도 Opus 4.8로 밀려나는 경로. [25]
2026-06-10	Issue #67246	safety classifier (안전 분류기) model switch Fable 5 → Opus 4.8.	fallback 설계의 가시적 로그. [26]
2026-06-12	Issue #68008	code review 중 Fable에서 Opus 4.8로 전환.	6/12 시점에 Fable 이용이 Opus 4.8화 되는 사례. [27]

이 시기의 보고들은 Fable/Mythos 중단 이후의 열화를 직접적으로 보여주는 것은 아니다. 하지만 Fable 5가 Opus 4.8을 안전장치(safety valve)로 사용하고 있었다는 점, 그리고 그 fallback이 상당히 광범위하게 발생했을 가능성을 보여준다.

즉, 6/12 중단 전부터 Opus 4.8은 Fable 관련 부하, 세션 이전, fallback의 수용처 역할을 하고 있었다.

5. 6/12 이후에 확인된 보고군

5.1 Fable unavailable / Please use Opus 4.8

6/12 중단 이후에는 Fable을 이용할 수 없게 되어 Opus 4.8을 사용하라는 안내를 받는 보고가 여러 건 나오고 있다.

일시	보고	개요	의미
2026-06-13	Issue #68121	Fable 5 unavailable / Please use Opus 4.8.	중단 이후 Opus 4.8이 명시적 대체지로 안내된 직접 로그. [28]
2026-06-13	Issue #68122	transcript revision(전사 수정) 후 Fable 5에서 lock out(차단). Opus 4.8 사용을 촉구하는 에러.	Fable 세션(session) 유지가 깨져 Opus 4.8로 이행하는 사례. [29]
2026-06-13	Issue #68137	/compact 등으로 Fable 5가 invalid/inaccessible model(유효하지 않거나 접근 불가능한 모델)이 되어, Opus 4.8 사용을 요구하는 에러.	compaction(압축) 처리 도중에 Fable 중단이 노출됨. [30]
2026-06-13	Issue #68153	Fable 불가 에러 직후, monitor event(모니터 이벤트)를 사용자 발화로 취급.	Fable 중단 후의 Opus 4.8 이행과 context-boundary(문맥 경계) 파탄이 연결됨. [31]
2026-06-13	Issue #68312	Fable 5 is not available. Opus 4.8 사용을 촉구하는 404 에러가 여러 시점에 기록됨.	Opus 4.8이 대체지로 반복해서 표시되는 직접적인 증거. [32]

Issue #68121에는 에러 본문으로서 다음 문구가 기록되어 있다.

“Claude Fable 5 is not available. Please use Opus 4.8.”

[28:1]

이는 Fable 중단 이후 Opus 4.8이 명시적인 대체지로 안내되었음을 나타내는 직접적인 로그이다. 물론 이것 자체만으로는 Opus 4.8의 성능 저하를 나타내지 않는다. 하지만 Opus 4.8의 역할이 바뀌었을 가능성을 시사한다.

5.2 공식 Status 상의 Opus 4.8 장애

6/13 이후, Claude Status에는 Opus 4.8 관련 elevated errors(상승된 에러)가 여러 건 기록되어 있다. [33]