Claude Fable 5.1, 생각 블록을 단일 대화에 바인딩 — 에이전트의 추론 능력을 잃게 만드는 4가지 편집 (2026)

이와 관련해 세 가지 공식 문서가 있으며, 각각 다른 측면을 설명합니다. 릴리스 노트는 이를 발표하고, What's new in Claude Fable 5.1 페이지는 주요 변경 사항을 요약하며, 전용 Preserved thinking 페이지는 전체 규칙과 마이그레이션 체크리스트를 제공합니다. 같은 날 업데이트된 일반 사용자용 헬프 센터 문서(네 번째 문서)는 API를 전혀 다루지 않을 때 이 메커니즘이 어떻게 작동하는지 보여줍니다.

생각 블록은 이제 모델 정보와 서명을 포함합니다

이 규칙은 단방향으로 적용됩니다. Anthropic의 설명에 따르면 다음과 같습니다. "모든 생각 블록은 어떤 모델이 이를 생성했는지 기록하며, 이는 단방향으로만 보존됩니다. Claude Fable 5.1은 이전 모델의 생각 블록을 읽을 수 있지만, 이전 모델은 Claude Fable 5.1의 생각 블록을 읽을 수 없습니다."

따라서 대화가 상위 모델로 이동하면 추론 과정이 유지됩니다. 대화가 하위 모델로 이동하면 해당 턴에서 추론 과정을 잃게 됩니다. Fable 5.1은 Opus 5, Fable 5, Mythos 5 및 이전 모델의 블록을 수용합니다. 그러나 이들 중 어떤 모델도 Fable 5.1의 블록을 읽을 수 없습니다.

대상 모델이 읽을 수 없는 블록이 요청에 포함된 경우, "API는 모델이 이를 보기 전에 블록을 삭제(drop)합니다." 삭제된 블록에 대해서는 비용이 청구되지 않습니다. 디버깅에 중요한 부분은 다음과 같습니다. thinking-binding-controls-2026-08-01 베타 헤더를 사용하면 최상위 input_transformations 배열에 삭제 사실이 보고됩니다. 문서에 따르면, 이 헤더가 없으면 "삭제는 자동으로(조용히) 처리됩니다."

모델 검사 외에도 두 가지 검사가 더 수행됩니다. API는 "블록 이전의 어떤 것도 변경되지 않았음"(최상위 system 프롬프트, tools 내의 도구 세트, 블록 이전의 모든 메시지)과 "이전 생각 블록의 체인이 끊어지지 않았음"("각 생각 블록은 여러 턴에 걸쳐 이전 블록을 기록하기 때문")을 확인합니다.

이후의 모든 것을 무효화하는 4가지 편집

릴리스 페이지에는 이러한 패턴이 명확하게 나열되어 있습니다. 다음 작업들은 이후의 모든 생각 블록을 무효화합니다.

• "이전 턴을 편집, 재정렬 또는 제거하면서 이후 턴은 유지하는 경우"
• "이전 턴에 요청별 텍스트(알림 또는 상태 표시줄)를 주입했다가 다음 요청에서 제거하는 경우"
• "동일한 대화 내에서 요청 사이에 최상위 system 프롬프트 또는 tools 배열을 다시 빌드하는 경우"
• "이후 요청에서 다른 바이트를 제공하는 이미지 또는 문서 URL (검사는 URL이 아니라 바이트를 대상으로 하므로, 동일한 파일에 대해 순환하는 서명된 URL은 괜찮습니다)"

이 4가지는 벤더의 요약일 뿐 전체는 아닙니다. Preserved thinking 페이지는 동일한 내용을 더 많은 행이 포함된 표로 확장하여 설명합니다. 도구 편집, 기록 중간에서 생각 블록 제거, 턴 범위 메시지의 문구 수정 등이 포함됩니다. 여러분의 하네스가 안전하다고 결론 내리기 전에 이 표를 먼저 읽어보세요.

검사가 강제 적용되는 환경에서 무효화된 블록을 다시 재생하는 요청은 The block is bound to a different conversation이라는 메시지와 함께 400 에러를 반환합니다.

이 4가지 중 어떤 것이 함정인지 주목하십시오. 두 번째는 결코 특이한 코드가 아닙니다. 이전 메시지에 턴별 알림을 주입했다가 다음 요청에서 제거하는 것은 긴 도구 루프를 제어하기 위한 표준 트릭이며, 이로 인해 그 이후의 모든 생각 블록을 잃게 됩니다.

유효하게 유지되는 것과 현재 적용 대상

문서에는 편집으로 간주되지 않는 사항도 명확히 명시되어 있으며, 이 목록은 사람들이 생각하는 것보다 더 관대합니다. 끝에 메시지를 추가하는 것은 괜찮습니다. 기록의 시작 부분에서 생각 블록을 제거하거나, cache_control 마커를 이동하거나, max_tokens, output_config, tool_choice를 변경하는 것도 괜찮습니다. 서버 측 압축(compaction) 및 컨텍스트 편집은 명시적으로 허용됩니다. "검사는 서버의 편집된 사본이 아니라 사용자가 보낸 내용을 비교하기 때문"입니다.

적용은 단계적으로 진행되며, 날짜는 정확합니다. "신규 계정은 2026년 8월 31일 00:00 UTC 이후에 생성된 계정입니다." 이러한 계정에는 오늘부터 검사가 적용됩니다. 기존 계정은 불일치가 기록되기는 하지만, 요청에서 prefix_mismatch_behavior를 설정한 경우에만 조치가 취해집니다. 우리가 대비해야 할 미래 지향적인 문장은 다음과 같습니다. "향후 모델은 모든 사용자에게 이 검사를 강제 적용할 예정입니다."

이로 인해 문서 전체에서 가장 유용한 경고가 나옵니다. 다른 사람들이 자신의 API 키로 실행하는 도구나 프레임워크를 유지 관리하는 개발자를 겨냥한 경고입니다. "다른 사람들이 자신의 API 키로 실행하는 도구나 프레임워크를 유지 관리하는 경우, 신규 계정을 사용하는 사용자가 여러분보다 먼저 이 검사에 걸리게 됩니다. 여러분의 키는 기존 계정일 가능성이 높기 때문입니다."

사용자 측면: 메모리가 모델을 변경할 수 있는 곳

같은 날, Anthropic은 Claude Fable 5 및 Fable 5.1에서 대화 도중에 모델이 전환되는 이유에 대한 헬프 센터 문서를 업데이트했습니다. 이는 messages 배열을 본 적이 없는 일반 사용자를 위해 작성되었지만, 결국 동일한 결론에 도달합니다.

Fable 5.1은 모든 요청에 대해 안전 분류기(safety classifiers)를 실행하며, 차단된 요청은 폴백(fallback)됩니다. "요청이 폴백되면, Claude는 동일한 대화 내에서 차단된 Claude Fable 5 또는 Fable 5.1 요청을 Opus 모델에서 다시 실행합니다." 이어서 "전환된 후에는 대화의 나머지 부분 동안 모델 선택기가 Opus로 유지됩니다."

이것이 채팅 창에서 나타나는 단방향 규칙의 실제 작동 방식입니다. 여러분의 대화는 방금 Fable 5.1의 추론을 읽을 수 없는 모델로 이동한 것입니다.

해당 페이지의 두 문장은 깊이 생각해 볼 가치가 있습니다. 차단된 카테고리 중 하나는 "모델의 요약된 생각을 추출하려는 시도를 포함하여, Fable 5 및 Fable 5.1에 대한 증류 공격(Distillation attacks)"입니다. 이는 이 바인딩이 왜 존재하는지 그 이유를 말해줍니다. 그리고 분류기는 최신 메시지만 읽는 것이 아닙니다. "검사는 사용자가 입력한 최신 메시지뿐만 아니라 메모리, 커넥터의 콘텐츠, 웹 검색 결과, 파일 등 모델이 읽는 모든 내용을 검토하므로, 사용자가 입력하지 않은 콘텐츠에 의해서도 차단이 트리거될 수 있습니다."

이 부분을 주의 깊게 읽으십시오. 메모리 레이어에 있는 내용이 모델 전환을 트리거할 수 있으며, 모델 전환이 바로 추론 과정을 잃게 만드는 원인입니다.

이것이 Claude Fable 5.1의 기억 능력을 떨어뜨리는 것은 아닙니다. 여기서 다루는 내용은 기능으로서의 persistent memory를 건드리지 않으며, 두 모델이 기본적으로 제공하는 1M 토큰 컨텍스트 창을 줄이지도 않습니다.

또한 정책으로 포장된 성능 저하(nerf)도 아닙니다. Anthropic은 그 이유를 직접 밝히고 있습니다. 서명 검사가 존재하는 이유는 "한 세트의 지침 하에 생성된 추론이 잠재적으로 적대적인 다른 세트의 지침 하에 재실행되지 않도록 하기 위함"입니다. 이를 일반 사용자 측면의 차단된 증류 카테고리와 결합하면 두 개의 레이어에서 하나의 방어 체계가 작동하는 셈입니다. 이를 퇴보(regression)라고 부르는 것은 오해입니다.

실제로 바뀌는 것은 메시지 배열의 상태입니다. 지금까지 messages는 마음대로 다시 쓸 수 있는 작업 메모리였습니다. 오래된 턴을 즉석에서 요약하고, 알림을 끼워 넣고, 새로운 도구가 추가되면 시스템 프롬프트를 다시 빌드할 수 있었습니다. Fable 5.1에서 이 배열은 체크섬이 있는 추가 전용(append-only) 로그에 가깝습니다. 그렇지 않다고 가정했던 시스템의 구성 요소들은 이제 다른 곳에 위치해야 합니다.

그리고 폴백(fallback) 비용이 달라집니다. 이전에는 가격이나 가용성을 위해 모델을 섞어 쓰던 라우터가 약간의 품질 저하만 감수하면 되었습니다. 이제는 추론 체인 자체를 잃게 될 수 있으며, input_transformations를 명시적으로 선택하지 않았다면 사용자에게 알리지도 않고 조용히 삭제됩니다.

"Fable 5.1은 이제 기억력이 나빠졌다." 그렇지 않습니다. 바인딩은 추론 블록(reasoning blocks)이 요청에 재사용될 수 있는지 여부를 제어합니다. 이는 Claude가 대화 간에 사용자에 대해 기억하는 것과는 무관하며, 이는 별도의 제어 장치를 가진 독립된 시스템입니다.

"그렇다면 생각 블록을 다시 보내지 말아야겠네." 이 역시 틀렸으며, 대가가 큽니다. Fable 5.1은 이전 모델의 블록과 자신의 블록을 읽습니다. 긴 에이전트 턴에 걸쳐 이를 다시 보내는 것이 추론 체인을 온전히 유지하는 방법입니다. 해결책은 기록 전송을 중단하는 것이 아니라, 기록 편집을 중단하는 것입니다.

"이것은 직접 API 호출을 작성하는 사람들에게만 영향을 미친다." 예외는 있지만 대체로 사실입니다. 문서에 따르면 Claude Code, claude.ai, Claude Managed Agents, Claude Agent SDK는 접두사(prefix)를 온전히 유지해 줍니다. 래퍼, 프록시 또는 평가 하네스 내부를 포함하여 messages 배열을 직접 빌드하는 경우라면 직접 확인해야 합니다.

"400 에러가 최악의 상황이다." 400 에러는 문제를 인지할 수 있으므로 오히려 다행인 경우입니다. 조용히 처리되는 경우가 더 나쁩니다. 베타 헤더 없이 모델 다운그레이드로 인해 블록이 삭제되거나, 순환하는 문서 URL이 조용히 다른 바이트를 제공하는 경우입니다.

"검사를 그냥 꺼버리면 된다." 불일치가 발생했을 때의 동작을 기본값인 "error" 대신 "drop_block"으로 선택할 수는 있지만, 삭제하는 것이 유지하는 것은 아닙니다. API는 "대화에서 해당 블록과 그 이후의 모든 생각 블록을 제거"합니다. 이는 합리적인 프로덕션 기본값일 뿐, 해결책이 아닙니다.

추가 전용(append-only) 규칙은 단 한 가지, 즉 단일 대화의 요청 본문에 대한 제약입니다. 프로젝트의 영구적인 지식이 어디에 저장되어야 하는지에 대해서는 아무런 제약이 없습니다. 이 차이를 이해하는 것이 핵심 해결책이며, 대화 기록 외부의 메모리 레이어에 규칙, 결정 사항, 선호도를 이미 보관하고 있던 팀들이 이번 릴리스의 영향을 거의 받지 않은 이유이기도 합니다.

메모리 레이어는 검사 메커니즘이 원하는 방식으로 작동합니다. 사실 정보가 이전 턴 내부에 존재한 적이 없기 때문에 이전 턴 내부에서 아무것도 다시 쓰이지 않습니다. 또한 저장소가 외부에 있기 때문에, 방금 추론 체인을 떨어뜨린 Opus로의 폴백 상황에서도 동일한 지식이 유지되며, 그 이후의 모델에서도 유지됩니다. MemoryLake는 세 단계로 작동합니다.

1단계: API 키 생성

로그인 후 대시보드에서 API 키를 생성합니다. 이 키는 에이전트, 하네스 또는 백엔드가 메모리를 읽고 쓰기 위해 사용하는 자격 증명이며, 현재 대화가 어떤 Claude 모델에서 실행 중인지와 무관합니다. 이 독립성이 핵심입니다. Fable 5.1에서 Opus로 폴백되면 생각 블록을 읽을 수 있는 대상은 바뀌지만, 메모리를 읽을 수 있는 대상은 전혀 바뀌지 않습니다.

2단계: 첫 번째 메모리 업로드

이전 턴에 주입하고 싶었던 내용들을 여기에 대신 넣으세요. 사내 규칙, 이미 내려진 결정과 그 배경 이유, 이름, 정의, 그리고 에이전트가 계속해서 다시 학습해야 했던 규칙들입니다. 프로젝트 세부 사항이 변경될 때마다 다시 빌드하는 긴 시스템 프롬프트를 유지해 왔다면, 이제 그 재빌드는 무효화를 유발하는 4가지 편집 중 하나가 됩니다. 변동성이 큰 절반은 메모리로 이동하고, 안정적인 절반은 system에 남겨두세요.

3단계: AI 및 에이전트 연결

하네스가 저장소를 가리키도록 설정하면, 기록의 뒷부분을 다시 쓰는 대신 턴의 시작 부분에서 검색이 수행됩니다. 실질적으로 이는 턴별 컨텍스트가 외부 소스에서 조립되어 추가됨을 의미하며, 6턴 전의 메시지에 패치되는 방식이 아닙니다. 이것이 서명 검사가 요구하는 형태이며, 프롬프트 캐시를 따뜻하게 유지하는 형태이기도 합니다.

긴 에이전트 실행의 경우, 즉각적인 변화는 제어(steering)가 대화의 끝으로 이동해야 한다는 점입니다. 알림은 추가된 턴이나 턴 범위의 시스템 메시지가 됩니다. 도구 변경은 다시 빌드된 tools 배열 대신 대화 중간 도구 변경 경로를 거치게 됩니다. 트리밍은 설계상 검사에서 무시되는 서버 측 압축 또는 컨텍스트 편집으로 처리됩니다.

앞단에 라우터가 있는 시스템의 경우, 가시성(visibility) 확보가 필요하다는 변화가 있습니다. thinking-binding-controls-2026-08-01 베타 헤더를 전송하고 input_transformations를 로깅하면 조용한 삭제를 추적 가능한 로그로 바꿀 수 있습니다. Anthropic의 자체 감지 레시피는 다음과 같습니다. prefix_mismatch_behavior를 "drop_block"으로 설정하고 일반적인 다중 턴 세션을 실행한 뒤 반환되는 내용을 확인하는 것입니다.

그 외의 사람들, 즉 브라우저에서 Claude를 사용하는 사람들에게 실질적인 변화는 더 작고 기묘합니다. 안전 폴백으로 인해 대화가 Opus로 이동하는 경우, 이전 메시지를 편집하는 것이 공식적으로 권장되는 해결 방법입니다. "다시 시도하기 전에 이전 메시지를 편집하는 것이 도움이 되는 경우가 많습니다." 이는 API 측 권장 사항과 정반대이지만, 서로 다른 레이어를 다루고 있기 때문에 둘 다 맞습니다. "기록을 편집하지 말라"는 요청 본문(request bodies)에 대한 규칙이지, 채팅 창을 사용하는 방법에 대한 규칙이 아닙니다.

비용 측면의 한 가지 참고 사항도 같은 방향을 가리킵니다. 생각 블록을 무효화하는 패턴은 대체로 프롬프트 캐시를 무효화하는 패턴과 일치합니다. 하나를 해결하면 다른 하나도 해결됩니다.

• 어시스턴트 턴을 반환된 그대로 추가하세요. 빈 생각 블록과 그 서명을 포함하여 바이트 단위로 정확히 일치해야 합니다.
• 이전 턴을 절대 패치하지 마세요. 턴별 알림은 clear_at: "next_user_message"가 설정된 턴 범위 시스템 메시지에 포함되어야 합니다. 이는 토큰 비용 없이 messages에 유지되며 이후 블록을 유효하게 유지합니다.
• 대화 중간에 system 및 tools를 건드리지 마세요. 두 배열을 다시 빌드하는 대신 대화 중간 시스템 메시지와 도구 추가 및 제거 경로를 사용하세요.
• 서버에서 트리밍하세요. 압축 및 컨텍스트 편집은 편집으로 간주되지 않습니다. 클라이언트 측에서 이전 턴을 요약하는 것은 편집으로 간주됩니다.
• 파일은 ID로 참조하세요. 검사는 URL이 아니라 바이트를 대상으로 합니다.
• 필요하기 전에 가시성을 확보하세요. 베타 헤더를 전송하고 input_transformations를 로깅하여 삭제된 블록이 미스터리가 아닌 측정 가능한 지표가 되도록 하세요.
• 신규 계정처럼 테스트하세요. 여러분의 키는 기존 계정일 가능성이 높으므로 prefix_mismatch_behavior를 명시적으로 설정하세요.
• 영구적인 지식은 messages 외부에 보관하세요. 기록에 주입하려 했던 모든 것은 메모리 레이어에 속해야 하며, 작업하는 동안 what your agent actually reads를 감사해 볼 가치가 있습니다.

Claude Fable 5.1의 가장 중요한 변화는 캐시 읽기 비용이 아닙니다. 여러분이 보내는 대화가 서명되고 모델에 바인딩된 추가 전용(append-only) 객체가 되었다는 점이며, 평범한 4가지 편집 습관으로 인해 모델의 추론 능력을 잃게 된다는 점입니다. 그중 하나는 아무런 경고 없이 조용히 일어납니다.

제약 조건은 까다롭지만, 해결 방법은 모두 Anthropic이 함께 출시한 공식 기능들입니다. 더 좋은 소식은 사람들이 메시지 배열에 억지로 밀어 넣으려 했던 대부분의 내용이 원래 그곳에 있어서는 안 되는 것들이었다는 점입니다. 추론은 의도적으로 단일 대화에 바인딩됩니다. 그러나 프로젝트의 지식은 그 어디에도 얽매일 필요가 없습니다.