Rihpig

Posted on Sep 2 Originally published at apidog.com

클로드 패이블 5.1 프롬프팅: 모든 행동 변화와 해결 방법

Anthropic은 기존 Fable 5 프롬프트가 Claude Fable 5.1에서도 변경 없이 작동한다고 설명합니다. 답변 품질에는 대체로 해당하지만, 도구 호출 배치 수, 진행 상황 설명, 문체 밀도, 채팅 서식, 파일 편집 방식, 작업 중 확인 요청 등 에이전트 동작은 달라졌습니다. 각 차이에는 Claude Fable 5.1 프롬프트 가이드에 맞는 수정 방법이 있습니다.

지금 Apidog을 사용해 보세요

이 글에서는 주요 변경 사항과 바로 적용할 수 있는 프롬프트 수정 방법을 정리합니다. 턴별 지시 사항의 배치가 사고 블록의 유효성, 프롬프트 캐시, 이후 처리 비용에 영향을 주는 이유도 다룹니다. 모델 개요는 Claude Fable 5.1이란 무엇인가를 참고하십시오.

프롬프트보다 먼저 노력 수준을 조정하라

노력(Effort)은 Fable 5.1에서 지능, 지연 시간, 비용을 조절하는 핵심 설정입니다. 프롬프트를 바꾸기 전에 기본값인 high에서 시작해 평가 데이터로 다른 네 가지 수준을 비교하십시오.

Fable 5에서 이미 스윕을 실행했더라도 다시 실행해야 합니다. 같은 수준 이름이라도 모델마다 사고량이 같다는 보장은 없습니다.

Anthropic의 테스트 결과에 따르면:

medium: Fable 5와 비슷한 결과를 더 낮은 비용으로 제공할 수 있습니다.
low: 작업당 비용에서 Opus 및 Sonnet과 경쟁력이 있으며 더 높은 점수를 보이는 경우가 있습니다.
xhigh, max: Fable 5.1의 가장 큰 개선 폭이 나타나는 수준입니다.

Fable 5.1에서는 캐시를 초기화하지 않고 대화 중간에 노력 수준을 변경할 수 있습니다. output_config와 베타 헤더 mid-conversation-output-config-2026-07-01을 사용하고, 내용이 없는 role: "system" 메시지를 보내십시오. 요청 형식은 API 사용법에서 확인할 수 있습니다.

문구보다 메시지 배치가 중요하다

Fable 5.1의 사고 블록은 이를 생성한 정확한 대화 기록에서만 유효합니다(보존된 사고).

이전 턴에 지시 사항을 삽입한 뒤 다음 요청에서 삭제하면 기록이 변경됩니다. 그 결과:

프롬프트 캐시가 다시 시작됩니다.
2026년 8월 31일 이후 생성된 계정에서는 이후 사고 블록이 무효화됩니다.

턴별 지시 사항은 다음 두 위치 중 하나에 추가하십시오.

베타 기능을 사용하는 경우

도구 결과 메시지 뒤에 턴 범위 시스템 메시지를 추가합니다.

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "..."
}

이전 사본은 배열에 그대로 유지하십시오. 이후 사용자 메시지가 도착하면 API가 이전 사본을 제거하므로 모델은 최신 사본만 읽고, 삭제된 사본에는 토큰 비용이 발생하지 않습니다.

베타 기능을 사용하지 않는 경우

동일한 사용자 메시지의 tool_result 블록 뒤 텍스트 블록에 지시 사항을 추가하고 이전 사본을 유지하십시오.

이미 전송한 사본은 삭제하거나 다시 작성하지 마십시오. 자세한 이유는 보존된 사고 가이드를 참고하십시오.

세션 전체에 적용되는 지시 사항은 시스템 프롬프트 또는 첫 사용자 턴에 넣습니다. Anthropic에 따르면 스타일 지시 사항은 시스템 프롬프트보다 첫 사용자 턴에 있을 때 더 잘 유지될 수 있습니다.

에이전트 루프에서는 턴당 도구 호출 수를 측정하라

변화

여러 항목을 가져오도록 요청하면 Fable 5.1은 호출을 병렬로 발행할 수 있습니다. 반면 코딩이나 컴퓨터 사용 루프에서 다음 독립 읽기를 암시하는 요청은 Fable 5가 한 번에 여러 개를 호출하던 상황에서도 턴당 하나만 호출할 수 있습니다.

답변 내용은 같지만 추가 턴마다 토큰, 왕복 시간, 실제 실행 시간이 늘어납니다.

측정

도구 호출이 두 개 이상인 어시스턴트 턴의 비율을 추적하십시오. 비율이 낮아진 경우에만 다음 수정 사항을 적용합니다.

수정

각 도구 결과 메시지 뒤에 턴 범위 시스템 메시지로 다음 지시 사항을 추가합니다.

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

privately라는 단어를 유지하십시오. 이 단어가 없으면 모델이 사용자를 대신해 알림에 응답할 수 있습니다. 이 지시 사항은 요청의 마지막 부분에 있을 때 시스템 프롬프트에 같은 내용을 넣는 것보다 효과적입니다.

도구 호출 사이에는 짧게 진행 상황을 알리게 하라

변화

Fable 5.1은 Fable 5보다 긴 도구 호출 작업 중 사용자에게 표시되는 업데이트를 적게 작성합니다. 노력 수준이 높을수록 이 경향이 강해집니다.

기본 display: "omitted"에서는 도구 사이 메모가 비어 있는 thinking 블록으로 반환됩니다. 진행 상황을 표시하려면 베타 헤더 thinking-display-updates-2026-08-18과 함께 display: "updates"를 사용하고, 비어 있지 않은 사고 블록을 상태 줄로 렌더링하십시오.

적용 순서

이전 모델을 위해 추가했던 “모든 발견 사항을 최종 응답까지 보류하라” 같은 문장을 제거합니다.
그래도 업데이트가 부족하면 시스템 프롬프트에 다음 문장을 추가합니다.

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own, covering what you found, what you did, and what's next, so a reader who only sees the last message has the full picture.

제품이 도구 출력을 사용자에게 숨긴다면 턴 범위 시스템 메시지로 다음 사실을 알려야 합니다.

해당 명령의 출력은 당신만 봅니다. 사용자가 읽어야 할 부분이 있다면, 답변에 포함하십시오.

그렇지 않으면 모델이 사용자에게 보이지 않는 출력을 표시하기 위해 불필요한 명령을 실행할 수 있습니다.

작업이 끝나기 전에 턴이 종료되는 문제를 방지하라

변화

복잡한 비동기 작업에서 Fable 5.1은 작업을 계속하는 대신 다음 단계를 설명하거나, 이미 요청된 단계에 대해 허락을 구할 수 있습니다. 사용자가 “계속”이라고 답해야 하므로 장기 작업이 중단됩니다.

수정

다음 시스템 프롬프트 블록을 사용하십시오. 첫 문장이 특히 중요합니다.

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.

Anthropic은 이 블록과 함께 요청의 범위를 정의하는 두 번째 블록도 사용합니다. 작업 범위를 임의로 좁히거나 넓히거나 바꾸지 말고, 완료할 수 있는 부분은 모두 완료한 뒤 누락된 부분만 보고하도록 지시하십시오. 사용자가 요청하지 않았지만 발견한 사항은 변경하지 말고 후속 제안으로 남깁니다.

여전히 확인이 필요한 항목이 있다면 질문 목록을 추가하십시오. Opus 5와 달리, 보고 전에 작업을 확인하도록 요청하는 지시 사항은 Fable 5.1에서 유지하십시오. Opus 5의 검증 지시 사항 삭제 권고는 여기에 적용되지 않습니다.

요청하지 않은 수정과 테스트 파일을 제한하라

변화

개방형 기능 요청에서 Fable 5.1은 주변 버그 수정, 동작 확장, 필요 이상으로 큰 테스트 파일 커밋을 추가할 수 있습니다.

수정

다음 문장을 추가하십시오.

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

이 지시 사항은 요청된 기능을 줄이는 것이 아니라, 요청 범위를 벗어난 변경만 제한합니다.

작은 변경에는 전체 파일을 다시 작성하지 않게 하라

변화

Fable 5.1은 일부만 바꾸면 되는 경우에도 전체 파일을 다시 작성하는 경향이 있습니다. 결과는 같을 수 있지만 출력 토큰과 검토 비용이 증가합니다.

수정

시스템 프롬프트 또는 첫 사용자 메시지에 다음 문장을 추가하십시오.

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

문체가 지나치게 길고 밀도 높아지는 문제를 줄여라

Fable 5.1은 일반적으로 문체가 개선되고 상투적인 표현이 줄었지만, 때때로 Fable 5보다 긴 문장과 적은 단락을 사용합니다.

이를 방지하려면 안티패턴을 직접 정의하십시오. Anthropic은 “꾸밈이 많은 문체(mannered prose)”를 직접적인 진술 대신 은유와 수사를 사용해 작가의 존재감을 드러내는 글쓰기로 설명합니다. 다음처럼 지시하십시오.

모든 꾸밈이 많은 문체를 제거하십시오.

의미를 직접 말하고 가능한 경우 문자 그대로의 표현을 사용하십시오.

필요한 구조를 유지하도록 채팅 서식을 조정하라

변화

이전 모델은 글머리 기호와 굵은 글씨를 과도하게 사용했기 때문에 많은 프롬프트에 서식 방지 규칙이 포함되어 있습니다. Fable 5.1은 반대로 굵은 글씨, 헤더, 목록을 지나치게 적게 사용할 수 있습니다.

오래된 서식 방지 규칙은 내용에 필요한 구조까지 억제합니다. 해당 규칙을 제거하거나 다음처럼 조건부 규칙으로 바꾸십시오.

요청받았을 때 또는 내용이 명확해질 만큼 다면적인 경우 목록을 사용하십시오. 최소한의 서식을 명시적으로 요청한 경우에는 그 요청을 따르십시오. 대화나 감정적인 교류에서는 평이한 문체를 유지하십시오.

요약에서 출처 문구를 인용 표시 없이 재현하지 않게 하라

Fable 5.1은 문서 요약 시 출처의 문장을 인용 표시 없이 재현하는 경향이 Fable 5보다 강합니다.

시스템 프롬프트에 올바른 응답의 완전한 예시를 하나 추가하십시오. 예시는 다음 요소를 포함해야 합니다.

사용자의 요청
어시스턴트 자신의 간접 화법으로 전달한 출처 내용
최대 하나의 짧은 표시된 인용구
인용 형식이 올바른 이유를 설명하는 한 문장 근거
실제 사용하는 도구 이름으로 바꾼 도구 호출 자리 표시자

낮은 노력 수준에서 검색 대신 기억으로 답하는 문제를 줄여라

변화

low 수준에서 Fable 5.1은 특히 최신 정보가 필요한 제품명이나 모델명을 다룰 때 검색 도구를 덜 호출하고 기억에 의존할 수 있습니다.

수정

다음 중 하나를 적용하십시오.

해당 턴의 메시지별 노력 수준을 높입니다.
시스템 프롬프트에 다음 내용을 지시합니다.

빠르게 변하는 분야에서 이름을 인식하는 것과 현재 상태를 아는 것은 다릅니다.
답변하기 전에 검색해야 합니다.
사용자가 입력한 이름을 그대로 하나 이상의 검색어에 포함해야 합니다.

`xhigh`와 `max`에서 긴 결과물을 오래 생성하는 문제

xhigh, 특히 max에서는 Fable 5.1이 긴 결과물 대부분을 사고 과정에서 작성한 뒤 최종 응답으로 다시 작성할 수 있습니다. 이 경우 대기 시간과 출력 토큰이 거의 두 배가 됩니다.

다음 순서로 조정하십시오.

해당 요청을 high에서 실행합니다.
측정 가능한 이득이 있을 때만 더 높은 수준으로 이동합니다.
xhigh나 max를 유지한다면 사고 과정과 답변을 모두 수용하도록 max_tokens를 설정합니다.

사용자 메시지에는 다음과 같은 메모를 추가할 수 있습니다.

생성된 모든 내용(추론 포함)은 실제 max_tokens 한도에 포함됩니다. 결과물을 추론에서 완전히 작성한 뒤 응답에서 다시 작성하면 턴과 토큰이 두 배가 되지만 품질은 개선되지 않습니다.

이후 요청에서는 이 메모의 이전 사본을 그대로 유지하십시오.

무해한 코딩 요청이 거부되는 문제

Fable 5.1의 출시 초기 분류기는 Fable 5보다 오탐이 적었지만, 여전히 오탐이 발생할 수 있습니다.

다음 세 가지를 적용하십시오.

“Does this program compile without errors?” 대신 “Are there any bugs in this program?”이라고 질문합니다.
잘 알려지지 않은 언어를 사용할 경우 관련 문서를 컨텍스트에 제공합니다.
base64로 인코딩된 데이터를 컨텍스트로 반환하는 도구는 제거합니다.
fallbacks는 구성된 상태로 유지합니다.

자세한 내용은 거부 처리 가이드를 참고하십시오.

클라이언트 측 압축 요약에서 세부 정보 보존하기

Fable 5.1은 무엇을 보존해야 하는지 명확히 지시하면 압축 요약을 잘 따릅니다. 서버 측 압축은 이미 이 작업을 수행합니다.

클라이언트에서 압축할 때는 모델에 다음 순서로 보존하도록 지시하십시오.

발생한 문제와 해결 방법
제시되었거나 보류된 접근 방식과 그 이유
요청되거나 결정된 모든 사항
현재 상태
미해결 사항
이름, 숫자, 링크처럼 재구성하기 어려운 세부 정보

요약은 <summary> 태그 안에 작성하게 하고 다음 문장으로 끝내십시오.

이 요약을 작성하는 동안 도구를 호출하지 마십시오. 텍스트로만 응답하십시오.

요약 요청 시에도 대화에 도구가 포함되어 있다면 이 문장이 특히 중요합니다.

하위 에이전트와 비전 처리

다음 두 가지는 프롬프트보다 아키텍처에 가까운 수정입니다.

코딩 작업에서 하위 에이전트가 실행되는 동안 리드 에이전트도 계속 작업하도록 구성하십시오. 하위 에이전트를 시작하는 도구는 즉시 반환하고, 결과는 나중에 사용자 메시지로 전달합니다. 리드 에이전트가 필요할 때 결과를 기다릴 수 있는 별도 도구도 제공해야 합니다.

밀집된 차트나 중첩된 테이블을 처리할 때는 선택 영역을 확대해 반환하는 자르기 도구 또는 기본 이미지 라이브러리가 포함된 컨테이너를 제공하십시오. low 수준에서는 자르기를 건너뛸 수 있으므로 호출 로그를 확인해야 합니다.

Apidog에서 프롬프트 변경 사항 테스트하기

위 수정 사항은 모두 전후 테스트의 후보입니다. Apidog에서 에이전트 루프의 첫 세 턴을 요청 시퀀스로 저장하고 시스템 프롬프트를 매개변수화하십시오. 같은 노력 수준에서 각 스니펫을 적용한 경우와 적용하지 않은 경우를 비교합니다.

검증할 지표는 다음과 같습니다.

일괄 처리: 어시스턴트 턴당 tool_use 블록 수
파일 편집 및 문체 밀도: usage.output_tokens
자율성: "Next, I"로 시작하는 마지막 단락의 부재

Apidog 다운로드 후 테스트를 구성할 수 있습니다. Claude Code 가이드는 어떤 지시 사항을 CLAUDE.md에 넣어야 하는지 설명합니다.

자주 묻는 질문

Fable 5 프롬프트가 Fable 5.1에서도 작동하나요?

Anthropic은 변경 없이도 작동해야 한다고 말합니다. 다만 다음 동작은 달라질 수 있습니다.

도구 호출 배치 감소
진행 상황 업데이트 감소
더 밀도 높은 문체
채팅 서식 감소
전체 파일 재작성
개방형 작업에서의 범위 확장

어떤 노력 수준에서 프롬프트를 작성해야 하나요?

high에서 시작해 평가 데이터로 스윕하십시오. Anthropic은 medium이 Fable 5와 비슷한 결과를 더 낮은 비용으로 제공하고, low가 작업당 비용에서 Opus 및 Sonnet과 경쟁력이 있을 수 있다고 설명합니다.

턴별 지시 사항은 어디에 넣어야 하나요?

도구 결과 뒤에 clear_at: "next_user_message"를 사용하는 턴 범위 시스템 메시지로 넣으십시오. 이전 사본은 그대로 유지해야 합니다. 이전 턴의 텍스트를 삭제하거나 다시 작성하면 이후 사고 블록이 무효화되고 캐시가 다시 시작됩니다.

Opus 5처럼 “작업 확인” 지시 사항을 제거해야 하나요?

아닙니다. 해당 지시 사항은 Opus 5의 과도한 검증을 위한 별도 권고입니다. Fable 5.1에서는 유지하십시오.

전체 파일 재작성을 어떻게 막을 수 있나요?