Fable 5.2 업그레이드 후 400 오류: 대화 이력과 도구 호출 점검법

Fable 5.2로 업그레이드한 뒤 400이 반환되면 프롬프트부터 바꾸지 말고 전체 오류를 읽으세요. 대화 바인딩 오류는 이력을, 도구 강제 선택 오류는 요청을 수정해야 합니다. 데이터 보관 관련 거부는 계정 정책에 관한 결정이 필요합니다. 같은 요청을 반복해도 어느 문제도 해결되지 않습니다.

이 진단은 2026년 11월 10일 확인한 Fable 5.2 마이그레이션 문서를 따릅니다. “변경 전” 예제는 문서의 네이티브 규약에 맞지 않는 패턴입니다. Ofox 테스트에서는 thinking 비활성화나 도구 강제 선택에 대해 문서의 400 오류를 재현하지 못했습니다. 해당 경로는 200을 반환했습니다. 게이트웨이가 요청을 받으면서 의도한 동작을 적용하지 않을 수 있다는 점에서 아래 결과를 확인할 필요가 있습니다.

Ofox 테스트에서 실제 반환된 결과

정확한 ID anthropic/claude-fable-5.2, API 버전 2023-06-01, low effort, 4,096토큰 한도로 https://api.ofox.ai/anthropic/v1/messages에 작은 요청 세 개를 보냈습니다. 모두 개당 12 USD인 물건 세 개의 금액을 물었으며 합성 데이터만 사용했습니다.

강제 도구 테스트에서는 원래 프롬프트의 “Do not use tools”(도구를 사용하지 말 것) 지시를 의도적으로 유지했습니다. 그럴듯한 답변을 받았다는 것만으로 강제 선택 규약을 검증할 수 없습니다. 이 응답에는 tool_use 블록이 없었습니다. 게이트웨이나 상위 서비스 중 어느 계층이 호환되지 않는 설정을 처리했는지 확인하지 못했으므로, 이를 지원 기능이라 부르거나 원인을 규명했다고 주장하지 않습니다.

각각 단일 요청에서 관찰한 결과이며 안정적인 호환성 보장은 아닙니다. 이식성 있는 코드를 만들려면 문서의 규약을 따르고 호환되지 않는 제어를 생략한 뒤 정확한 사용 경로에서 결과를 검증하세요. 이후 본문은 공식 400 오류 분기와 애플리케이션 수정 방법을 다룹니다. 이번 작은 테스트에서는 서명된 프리픽스, 데이터 보관, computer tool, advisor 오류를 재현하지 않았습니다.

실제 API 응답을 넣어 로컬에서 표시한 테스트 기록의 영문 스크린샷입니다. Ofox 제품 인터페이스가 아닙니다.

먼저 어느 단계에서 실패했는지 확인하기

정확한 모델, 엔드포인트, API 버전, SDK 버전, 상태, 오류 본문, 요청 ID를 기록하고 처음 실패한 요청을 찾으세요. 공개 오류 보고에는 인증 정보와 비공개 대화 내용을 넣지 마세요.

합성 입력으로 정상 동작하는 요청 하나를 보관하세요. 복사본에서 선택 필드를 뺀 뒤 하나씩 다시 넣으면 모델 제약인지 래퍼가 몰래 추가하는 기본값인지 구별할 수 있습니다. 비교할 원본 요청은 수정하지 말고 그대로 남겨두세요.

대화 바인딩 오류 수정하기

Fable 5.2는 모든 계정에 프리픽스 검사를 적용합니다. 클라이언트가 이전 이력을 수정한다면 오래된 계정으로 Fable 5.1에서 성공하던 요청도 업그레이드 후 실패할 수 있습니다. 문서의 오류 메시지에는 The block is bound to a different conversation이 포함됩니다.

대표적인 원인은 새 타임스탬프로 시스템 프롬프트를 다시 만들거나, 턴 사이에 도구 스키마를 바꾸거나, 메시지 순서를 바꾸거나, 이전 내용을 로컬 요약으로 대체하는 경우입니다. 서명을 그대로 두었다고 수정된 프리픽스가 유효해지는 것은 아닙니다.

애플리케이션 차원에서는 다음과 같이 다릅니다.

# Before: rewriting history after the model has produced signed content.
system = base_system + " Current time: " + current_timestamp
messages[0] = {"role": "user", "content": shortened_original_request}

# After: freeze the original request prefix; add genuinely new instructions.
system = original_system
messages.append({"role": "user", "content": new_instruction})

“변경 후” 패턴은 새 정보를 추가하는 방법이지, 가득 찬 컨텍스트를 보편적으로 압축하는 방법은 아닙니다. 작업, 도구, 요약을 바꿔야 한다면 검증된 애플리케이션 체크포인트로 새 대화를 시작하거나 해당 경로가 지원하는 문서화된 컨텍스트 관리 기능을 사용하세요. 오래된 서명 블록을 남긴 채 수정된 이력이 동등할 것이라고 기대하면 안 됩니다.

전송 직전에 직렬화된 값을 비교하세요. 원래 시스템 프롬프트, 도구 정의, 메시지 순서, assistant 블록 전체를 확인합니다. 읽기 편한 채팅 로그에는 중요한 필드가 빠질 수 있습니다. MCP 통합에서는 서버 도구 목록 변경이 프리픽스를 바꾸는지도 확인하세요. 로컬 도구 사전만 고정해서는 이 변경까지 막지 못할 수 있습니다.

Preserved thinking 안내는 thinking.block_binding.prefix_mismatch_behavior: "drop_block"과 thinking-binding-controls-2026-08-01 헤더를 사용하는 복구 베타 기능을 설명합니다. 이는 영향을 받은 추론을 복원하는 것이 아니라 버립니다. input_transformations 보고서로 변경 지점을 찾고 추가 재생성 가능성도 고려하세요. 의존하기 전에 선택한 경로의 베타 지원을 검증해야 합니다. 이 글은 Ofox Bedrock 경로가 해당 제어를 전달한다고 주장하지 않습니다.

불투명한 블록까지 assistant 메시지 전체 보존하기

UI에 표시한 텍스트만으로 다음 요청을 재구성하지 마세요. 네이티브 thinking 블록에는 불투명한 서명이 있고, redacted 블록에는 불투명한 데이터가 있습니다. 같은 대화를 계속할 때는 응답 블록 전체와 순서를 보존해야 합니다.

# response is a completed native SDK Message.
messages.append({
    "role": "assistant",
    "content": [block.model_dump(exclude_none=True)
                for block in response.content],
})

스트리밍에서는 완료를 기다리고 조립된 최종 메시지를 얻으세요. 텍스트 델타만 저장하는 수집기는 유용한 답변을 표시하면서도 이어갈 수 없는 이력을 저장할 수 있습니다. 대체 서명을 만들어서는 안 됩니다. 상태를 잃었다면 원래 메시지를 복구하거나 검증된 사실로 새 작업 세션을 시작하세요.

“Invalid signature”와 “different conversation”은 관련된 진단이지만 원인이 같지는 않습니다. 기존 Claude thinking 서명 글은 직렬화와 스트리밍 실수를 다룹니다. 이 5.2 안내는 더 엄격한 업그레이드 경계를 추가하며, 모든 과거 모델에 같은 적용 규칙이 있었다는 뜻은 아닙니다.

상속된 thinking·샘플링 설정 제거하기

Fable 5.2의 적응형 추론은 끌 수 없습니다. 수동 thinking 모델에서 가져온 래퍼가 고정 budget_tokens나 thinking: {"type":"disabled"}를 보낼 수 있습니다. 이를 제거하고 지원되는 effort 제어를 사용하세요.

{
  "model": "claude-fable-5-2",
  "max_tokens": 4096,
  "output_config": {"effort": "low"},
  "messages": [{"role": "user", "content": "Calculate 3 times 12."}]
}

이는 Claude API 요청 본문 템플릿입니다. Ofox에서는 API 안내의 ID와 엔드포인트를 사용하세요. 적응형 동작이 이미 모델 기본값이므로 thinking을 생략했습니다.

temperature, top_p, top_k 값을 임의로 바꾸지 말고 제거하세요. Thinking 호환성 문서는 API 버전을 구분합니다. 이 새 모델들은 오래된 버전에서 기본값이 아닌 샘플링 값을 거부하며, API 2026-10-21부터는 값과 무관하게 해당 필드가 들어 있으면 거부합니다. 마지막 assistant 메시지를 미리 채우는 prefill도 확인하세요. 여기서는 출력 형식을 강제하는 지원 우회 방법이 아닙니다.

항상 켜진 thinking과 도구 강제 선택 제약은 Fable 5.1에도 적용됩니다. 업그레이드 시 코드 경로 변화로 드러날 수 있는 기존 제약이지, 모두 5.2에서 새로 생긴 규칙은 아닙니다.

도구 강제 선택을 대체하되 실행을 보장한다고 생각하지 않기

문서에 명시된 네이티브 Claude 규약에서 다음 패턴은 Fable 5.2와 호환되지 않습니다. 위 Ofox 테스트처럼 모든 게이트웨이가 같은 오류를 반환한다고 가정하면 안 됩니다.

{"tool_choice": {"type": "any"}}

{"tool_choice": {"type": "tool", "name": "lookup_stock"}}

{"tool_choice":{"type":"auto"}}를 사용하고 조회가 필요한 조건을 설명하세요. 그런 다음 실제 응답을 검증합니다. 신뢰할 수 있는 재고 데이터가 필요한데 모델이 도구 없이 답하면 재고 확인 업무가 완료된 것으로 받아들이지 마세요.

정해진 스키마의 출력이 필요하면 지원되는 strict 도구 스키마나 structured output으로 형식 요구를 해결할 수 있습니다. 그렇다고 특정 도구가 반드시 실행되는 것은 아니며 모델·계정 제약도 그대로 적용됩니다. 특히 공식 마이그레이션 안내는 고객 관리 암호화 키를 사용하는 조직에서 structured output 호환성을 추가 확인해야 한다고 명시합니다.

안전한 앱 루프는 세 가지 판단을 분리합니다. 도구 호출이 요청됐는지, 인수가 유효하고 허가됐는지, 결과가 작업을 충족하는지입니다. 턴 수를 제한하고 실패·미완료 상태를 명시해야 합니다. 그렇지 않으면 강제 선택을 auto로 바꾸면서 눈에 보이는 400을 보이지 않는 실행 누락으로 바꿀 수 있습니다.

프로토콜에 맞게 누락된 도구 결과 복구하기

오류가 tool_use_id를 가리키면 직전 assistant 턴의 모든 도구 호출을 나열하고 각각 실제 결과와 연결하세요. Anthropic Messages에서는 user 메시지의 네이티브 tool_result 형식을, Chat Completions에서는 tool 메시지 형식을 사용합니다. 서로 다른 프로토콜입니다.

조회 실패에는 사실대로 오류 결과를 반환하세요. 프로세스가 죽기 전에 조회가 성공했다면 지속 저장된 결과를 가져옵니다. 새 tool-result 블록을 얻기 위해 결제, 이메일, 쓰기 작업을 다시 실행하면 안 됩니다. Tool-result 400 진단은 메시지 배치를, 체크포인트 튜토리얼은 재시작 사이에 필요한 지속 기록을 설명합니다.

Bedrock 예외와 advisor 조건 확인하기

이전 computer_20251124 도구는 문서에 나온 플랫폼에서 Fable 5.2와 함께 사용하면 오류가 나지만 Amazon Bedrock은 예외입니다. 다른 플랫폼에서는 새 computer_toolset_20260801 선언과 해당 에이전트 루프 변경이 필요합니다. 옛 인수를 그대로 두고 type 문자열만 바꾸는 것으로는 부족합니다.

Ofox에서는 이 예외가 중요합니다. 11월 10일 카탈로그에 Fable 5.2의 공급자로 aws_bedrock이 나옵니다. Claude API 예제만 보고 옛 computer tool이 Ofox에서 실제 실패했다고 보고하면 안 됩니다. 실제 경로, 지원 도구 범위, 전체 요청을 먼저 확인하세요.

Anthropic advisor 도구를 쓴다면 5.2 실행 모델에는 지원되는 5.2 advisor가 필요합니다. Advisor 선언을 바꾸면 도구 프리픽스가 달라지므로 기존 서명 세션을 수정하지 말고 새 대화에서 전환하세요. Advisor 베타의 가용성은 일반 텍스트나 함수 호출과 별도로 확인해야 합니다.

정책·용량 문제를 잘못된 프롬프트로 취급하지 않기

Anthropic은 Fable 5.2에 30일 보관 요구사항을 명시하며 예외에는 명시적 승인이 필요합니다. 호환되지 않는 ZDR 설정의 Claude API workspace는 400을 받을 수 있습니다. 요청 성공을 위해 고객의 보관 정책을 자동으로 완화하면 안 됩니다. 계정 소유자에게 결정을 맡기고 실제 플랫폼 약관을 확인하세요. 이 규칙이 Ofox 계정 설정의 증거는 아닙니다.

429나 529라면 용량과 재시도 안내를 확인하세요. 일시적인 과부하에는 제한된 백오프 재시도가 적절할 수 있지만, 잘못된 400 요청을 그대로 반복하는 것은 다릅니다. 529 과부하 안내 (영문)와 현재 Ofox 속도 제한 문서를 참고하세요.

실패했던 동일 워크플로에서 수정 검증하기

새 요청, 후속 요청, 읽기 전용 도구 왕복, 저장 세션 복원을 실행하세요. 새 요청이 성공했다고 이력 보존이 고쳐졌다고 볼 수는 없습니다. 별도 합성 테스트에서 프리픽스를 의도적으로 수정해 진단이 변형을 숨기지 않고 식별하는지 확인하세요.

수정 전후 요청 형태, 오류, 정확한 경로, 완료 결과를 보관합니다. 블록을 버리는 복구를 켰다면 삭제된 상태를 기록하고 최종 답변도 확인하세요. 실제 워크플로가 부수 효과를 재실행하지 않으면서 독립 검수를 통과했을 때 조사를 마칩니다.

관련 문서: Ofox 네이티브 Messages, 인증, 공식 마이그레이션 안내.