사고 제어: thinking과 effort
Fable 5는 thinking을 끌 수 없다. 사고 깊이는 effort 5단계로만 조절하며, 기본값 high로 대부분의 작업이 충분하다.
1.프롬프트
목표·제약·성공 기준
2.Adaptive Thinking
항상 켜짐 — effort로 깊이 조절
3.행동
도구 호출·코드 작성 (수 분 지속 가능)
4.자기 검증
결과 대조 후 보고
Adaptive thinking은 항상 켜져 있다
Claude Opus 4.8까지는 thinking 필드를 생략하면 사고 없이 응답했다. Fable 5는 다르다 —
thinking 파라미터를 넣든 빼든 항상 적응형 사고(adaptive thinking, 응답 전 내부 사고)로
동작한다. "사고를 끈다"는 선택지 자체가 사라졌기 때문에, 끄려고 thinking: {"type": "disabled"}를
보내면 오류가 반환되고 수동 사고 예산(budget_tokens) 개념도 없다. 마이그레이션 시 할 일은
하나 — 아래처럼 API 요청에서 thinking 필드를 지우는 것이다.
한 가지 함정은 max_tokens의 의미 변화다. 이 값은 thinking과 응답 텍스트를 합친 총
출력의 하드 리밋이다. Opus 4.8에서 thinking 없이 돌던 워크로드를 그대로 옮기면 같은 한도
안에서 사고 토큰까지 소비되므로, 값을 반드시 재검토해야 한다.
Before
// Before (Claude Opus 4.8)
{
"model": "claude-opus-4-8",
"max_tokens": 16000,
"thinking": { "type": "adaptive" },
"output_config": { "effort": "high" },
"messages": [{ "role": "user", "content": "..." }]
}After
// After (Claude Fable 5)
{
"model": "claude-fable-5",
"max_tokens": 16000,
"output_config": { "effort": "high" },
"messages": [{ "role": "user", "content": "..." }]
}핵심 변경: thinking 파라미터를 아예 제거한다 — 항상 켜져 있으므로 명시할 필요도, 끌 방법도 없다.
DO
- thinking 파라미터를 생략한다 (항상 켜짐)
- 사고 깊이는 output_config.effort로 조절한다
- max_tokens를 thinking + 응답 합산 기준으로 재검토한다
DON'T
- thinking: {"type": "disabled"} 전송 — 400 오류
- budget_tokens로 사고 예산 지정 — 지원 안 됨
- temperature/top_p/top_k 샘플링 파라미터 전송 — 400 오류
- Claude Code에서 MAX_THINKING_TOKENS=0 등으로 끄기 시도 — 효과 없음
출처:
공식 마이그레이션 가이드
모든 effort 레벨을 재검토하라
effort는 모델이 얼마나 깊게 생각할지를 정하는 파라미터로, output_config.effort에 5단계
값 중 하나를 준다. Opus 4.8에서는 코딩·고자율 작업에 xhigh를 명시하는 것이 권장이었지만,
Fable 5에서는 high가 기본값이자 대부분의 작업에 적합한 선택이다. 공식 문서는 "낮은
effort 설정도 이전 모델의 xhigh 성능을 종종 능가한다"고 명시한다 — 즉 xhigh는 가장
난이도 높은 워크로드에만 예약하고, 루틴 작업은 medium/low로 내려서 비교해 보는
것이 올바른 방향이다.
high기본값. 대부분의 작업에 권장 — 단, 일상 작업에서는 과잉 맥락 수집으로 이어질 수 있어 범위 제한 스니펫 병용 권장.
단, 일상적인 작업에서 high effort는 과도한 맥락 수집·숙고로 이어질 수 있다. 공식 문서가
함께 제공하는 아래 범위 제한 스니펫을 시스템 프롬프트나 CLAUDE.md에 그대로 붙여넣으면,
요청 밖의 기능 추가·리팩터링·방어적 예외 처리 같은 과잉 설계가 억제된다:
Don't add features, refactor, or introduce abstractions beyond what the task requires.
A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't
need a helper. Don't design for hypothetical future requirements: do the simplest
thing that works well. Avoid premature abstraction and half-finished implementations.
Don't add error handling, fallbacks, or validation for scenarios that cannot happen.
Trust internal code and framework guarantees. Only validate at system boundaries
(user input, external APIs). Don't use feature flags or backwards-compatibility
shims when you can just change the code.