Claude Fable 5.2 프롬프팅

TMT

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-2

이 가이드는 Claude Fable 5.2에 특화된 프롬프팅 패턴을 다룹니다. 모델의 역량과 API 변경 사항은 Claude Fable 5.2의 새로운 기능을 참고하십시오. 현재의 모든 Claude 모델에 두루 적용되는 기법은 프롬프팅 모범 사례를 참고하십시오.

Claude Fable 5.2는 몇 가지 면에서 이전 모델과 다르게 동작합니다. 여러분이 관찰한 현상에 해당하는 절부터 읽으십시오.

노력 수준 조정하기

Claude API의 기본값인 high에서 시작하십시오. 사용 사례에 따라 필요하다면 노력 수준을 올리거나 내리고, 바꿀 때마다 여러분의 평가(eval)로 시험하십시오. 노력 수준은 Claude Fable 5.2가 얼마나 많이 생각하는지, 한 턴에 시간이 얼마나 걸리는지, 토큰을 얼마나 쓰는지를 정합니다. 노력 수준에 따라 모델이 생각하는 방식과 도구를 호출하는 횟수도 달라지므로, 노력 수준은 프롬프트와 함께 조정하십시오.

일반적으로 노력 수준의 순서는 Claude 모델 전체에서 같지만, 각 수준에서 모델이 실제로 생각하는 양은 모델마다 다를 수 있습니다. 그러니 Claude Fable 5.1이나 Claude Opus 5.5에서 맞춰 둔 설정을 그대로 가져오지 말고, 노력 수준별 비교 실험을 다시 돌리십시오.

작업의 종류에 따라 수준을 고르십시오.

  • low는 빠르게 주고받는 대화, 명세가 분명한 작업, 그리고 빠르고 똑똑한 서브에이전트처럼 처리량이 많은 워크로드에 알맞습니다. Anthropic의 테스트에서 이 모델이 low에서 받은 점수는 Claude Fable 5.1이 더 높은 노력 수준에서 받은 점수에 가까웠습니다.
  • medium은 대화형 코딩, 채팅, 일상적인 지식 작업에 알맞습니다.
  • high는 어려운 코딩, 리서치, 에이전트 작업, 사람이 지켜보지 않는 긴 실행에 알맞습니다. 턴이 끝나기까지 medium보다 눈에 띄게 오래 걸립니다.
  • xhigh는 오래 실행되는 코딩과 에이전트 작업 가운데 가장 어려운 것에, 그것도 성능 향상을 직접 측정해 확인한 경우에 씁니다. Anthropic의 내부 코딩 평가에서는 점수가 조금 올랐고 토큰은 훨씬 많이 들었습니다.
  • max는 모델의 한계를 측정할 때, 또는 시간과 토큰이 문제가 되지 않는 드문 작업에 씁니다. 과학적 발견이나 수학처럼 답이 열려 있는 문제에 가장 잘 맞습니다. 턴이 느리고 xhigh보다 훨씬 많은 토큰을 씁니다.

역량 향상의 대부분은 high에서 이미 나타납니다. medium에서 high로 올리자 Anthropic이 추적하는 코딩과 지식 작업 평가 대부분에서 점수가 올랐습니다. 이렇게 올리면 토큰과 시간도 더 들기 때문에, 여러분의 평가에서 품질이 유지되는 곳이라면 medium으로 내리십시오. high를 넘어서면 향상 폭이 고르지 않고 작업에 따라 달라집니다.

수준을 고를 때는 세 가지 동작을 염두에 두십시오.

  • 노력 수준이 낮을수록 모델이 일찍 멈출 가능성이 높습니다. low나 medium으로 에이전트 작업을 한다면 작업을 끝까지 마치게 하기에 있는 텍스트를 추가하십시오.
  • high 이상에서는 모델이 거의 모든 답변 전에 생각하며, 인사에 답할 때도 마찬가지입니다. 쉬운 요청에 시간이나 비용이 너무 많이 든다면 그런 턴에는 더 낮은 노력 수준을 쓰십시오. Anthropic의 테스트에서는 숙고하지 말고 바로 답하라고 지시해도 medium 이상에서는 모델이 생각하는 것을 막지 못했습니다.
  • 노력 수준을 바꿔도 모델의 답변 길이는 거의 달라지지 않습니다. 답변의 길이와 어조를 바꾸려면 프롬프트를 쓰십시오.

한 워크플로 안에서 여러 수준을 섞어 쓸 수도 있습니다. 예를 들어 medium으로 모델과 계획을 세우고 다듬은 다음, 사람이 지켜보지 않는 긴 구간에서 노력 수준을 올릴 수 있습니다. 대화 도중에 프롬프트 캐시를 유지하면서 수준을 바꾸려면 메시지별 노력 수준 변경을 사용하십시오(베타, mid-conversation-output-config-2026-07-01 헤더). 이 기능을 쓸 수 있는 플랫폼은 해당 절에 나와 있습니다. 한번 바꾼 수준은 다른 변경으로 바뀔 때까지 유지됩니다. 메시지별 노력 수준을 쓸 수 없는 곳에서는 다음 요청에 최상위 effort 값을 새로 설정하십시오. 이렇게 하면 캐시가 처음부터 다시 쌓입니다.

작업을 끝까지 마치게 하기

단계가 많은 긴 작업에서 Claude Fable 5.2는 가끔 일이 끝나기 전에 턴을 끝냅니다. 남은 일의 목록을 적거나, 계속할지 묻거나, 타임아웃 같은 평범한 장애물 앞에서 멈추면서 턴을 마칩니다. 이런 일은 노력 수준이 low나 medium일 때 더 자주 일어납니다.

여러분의 에이전트가 이렇게 멈춘다면 시스템 프롬프트에 다음과 같은 텍스트를 추가하십시오.

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.

If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.

If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.

작업 마무리 사용자가 요청한 일이 아직 남아 있는 동안에는 멈추지 마십시오. 끈기 있게 계속하고, 꼭 필요한 경우가 아니면 멈추지 마십시오.

상황을 알리는 메모는 환영하고, 정해지지 않은 결정을 사용자에게 확인하는 것도 좋습니다. 다만 사용자의 답에 좌우되지 않는 일은 불필요하게 멈추지 말고 계속하십시오.

사용자에게 방향을 바꿔 달라고 청하거나 기다리겠다고 제안하려는 자신을 발견하면, 그러지 말고 작업의 다음 부분으로 넘어가십시오. 오류, 타임아웃, 잠긴 파일, 빈 결과, 실패하는 도구 같은 평범한 장애물을 만날 수 있습니다. 먼저 원인을 진단하고, 진짜로 막힌 것이 아니라면 불필요하게 멈추지 말고 지금 가진 권한으로 해결하십시오(기다렸다가 다시 시도하기, 요청 고치기, 다른 도구나 출처 쓰기).

건드리지 말라고 표시된 파일, 의도적으로 주지 않은 접근 권한, 안전 가드레일처럼 누군가가 분명히 막아 두기로 정한 것이라면 그대로 두고, 무엇을 발견했는지 분명히 말한 다음, 작업을 마칠 다른 안전한 방법을 찾으십시오. 작업이 끝나기 전에 멈추는 것이 정당한 경우는 매우 드뭅니다. 사용자의 입력 없이는 작업을 진행할 수 없을 때, 또는 의도적으로 막아 둔 것이어서 우회하면 안 될 때가 그런 경우입니다. 이 지침이 있더라도 위험하거나 파괴적인 행동은 여전히 확인을 받아야 합니다.

이 텍스트는 장애물을 두 종류로 나눕니다. 오류, 타임아웃, 실패하는 도구 같은 평범한 장애물은 진단해서 해결하라고 모델에게 말합니다. 건드리지 말라고 표시된 파일처럼 의도적으로 막아 둔 것은 그대로 두고 보고하라고 말합니다. 이 텍스트를 출발점으로 삼고, 여러분의 애플리케이션에 맞게 고칠 때도 이 구분은 유지하십시오.

Anthropic은 한 에이전트 코딩 제품에서 기록한 세션을 medium 노력 수준으로 다시 실행해 보았습니다. 이 텍스트의 한 버전을 넣자, 할 수 있는 일을 남긴 채 끝난 세션이 절반가량으로 줄었습니다. 이 텍스트는 허락을 구하거나 계속할지 묻고 끝나는 경우를 대부분 없앴지만, 남은 일을 나열하고 멈추는 경우는 없애지 못했습니다. 출력 토큰은 약 30퍼센트 늘었습니다.

이 텍스트를 넣으면 모델이 덜 묻게 되므로, 위험하거나 되돌릴 수 없는 행동에 대한 확인 단계는 여러분 쪽에서 따로 유지하십시오.

승인

모델에게 계속하라고 말할 때는 "계속"이라고만 보내지 말고 무엇을 원하는지 분명하게 말하십시오. 예를 들어 "진행"이라고 보내거나 엄지척을 보내던 자리에서 "네, 스테이징 데이터베이스에 마이그레이션을 실행하세요"라고 답하십시오.

시스템 프롬프트에 승인 규칙이 있다면 그 규칙이 적용되는 행동을 정확히 지목하십시오. 모델은 규칙을 적힌 그대로 적용하기 때문입니다. 승인해 줄 사람이 없는 모의 작업으로 Anthropic이 테스트했을 때, 한 규칙은 승인이 필요한 단계 가운데 하나로 "이 대화 밖의 사람들에게 메시지 보내기"를 들고 있었습니다. 그 규칙이 있자 모델은 동료와 다른 팀에 보내는 일상적인 요청의 절반가량을 보내지 않고 보류했습니다.

코드의 주인이 누구인지 밝히기

Claude Fable 5.2는 자신이 작업하는 코드의 주인이 누구인지에 관해 프롬프트가 하는 말에 민감하게 반응합니다. Anthropic이 작은 코딩 작업으로 테스트했을 때, 프롬프트가 소유권에 관해 아무 말도 하지 않거나 코드베이스를 다른 사람의 것으로 제시하면 모델은 기존 구조에 덧붙이는 경향을 보였고, 그 때문에 기존 코드가 중복되더라도 그렇게 했습니다. 주변의 문제도 고치기보다는 보고하는 경향이 있었습니다. 프롬프트가 코드베이스를 모델 자신의 것이라고 말하면, 모델은 요청받지 않아도 중복된 코드를 합치고 관련된 수정을 하는 경우가 많습니다.

모델이 일하면서 구조를 개선하기를 원한다면 코드가 모델 자신의 것이라고 말하십시오.

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

이 코드베이스는 당신의 것입니다. 무엇을 위한 것이고 어떻게 만들지는 당신이 정하며, 앞으로도 당신이 계속 만들어 갈 것입니다.

Anthropic이 작은 코딩 작업으로 테스트했을 때, 이 문장이 있으면 모델은 시도의 절반가량에서 중복된 코드를 합쳤고, 없으면 그 비율이 10분의 1에 못 미쳤습니다. 비율은 작업에 따라 달랐습니다. 이 문장이 긴 시스템 프롬프트 안에 있을 때도 결과는 같았습니다. 요청한 기능은 문장이 있든 없든 거의 모든 시도에서 동작했습니다.

같은 테스트에서 모델은 이 문장이 있을 때 출력 토큰을 약 1.5배 썼고, 아무도 요청하지 않은 변경을 여러 건 했는데 그중 상당수는 새 테스트와 문서였습니다. 버그 수정을 제외하면, 기존 기능의 동작 방식을 바꾼 것은 여섯 번에서 열 번에 한 번꼴이었고 노력 수준이 높을수록 더 잦았습니다. 모델이 마지막에 쓴 요약은 큰 변경은 언급했지만 작은 변경은 빠뜨리는 경우가 많았으니, 요약만 보지 말고 diff를 검토하십시오.

사용자가 코드의 주인이고 코드를 가능한 한 적게 바꾸기를 원하는 곳에서는 소유권 문장을 빼십시오. 프롬프트의 다른 곳에 범위를 제한하는 규칙이 있어도 소유권 문장의 효과가 사라지지는 않습니다. Anthropic의 테스트에서는 같은 프롬프트의 앞부분에 "지나가는 김에 하는 리팩터링, 이름 변경, 정리 금지(No drive-by refactors, renames or cleanups)"가 있었는데도 모델이 시도의 3분의 1가량에서 중복된 코드를 합쳤습니다.

긴 턴 동안 사용자에게 진행 상황 알리기

Claude Fable 5.2는 도구 호출이 길게 이어지는 동안 사용자에게 보이는 텍스트를 거의 쓰지 않을 때가 있습니다. 무엇을 하려는지 말하지 않고 첫 도구 호출을 할 수도 있습니다.

먼저 여러분의 클라이언트가 모델이 보내는 진행 상황 알림을 받고 있는지 확인하십시오. Claude Fable 5.2에서는 모델이 도구 호출 사이에 쓰는 알림이 진행 상황 알림 thinking 블록으로 돌아옵니다. 이 알림은 모델이 무엇을 발견했고 다음에 무엇을 할지 말해 줍니다. thinking.display의 기본값인 "omitted"에서는 이 블록의 텍스트가 비어 있습니다. 그래서 text 블록만 렌더링하는 클라이언트는 긴 에이전트 턴 동안 조용해 보일 수 있습니다. display: "updates"(베타, thinking-display-updates-2026-08-18 헤더)로 설정하면 알림마다 짧은 요약을 받고, "summarized"로 설정하면 알림과 함께 요약된 추론을 받습니다. 그런 다음 도구 호출 사이에 있는, 비어 있지 않은 thinking 블록을 렌더링하십시오.

알림이 잦아야 하는 때는 무엇보다 대화형 코딩처럼 사용자가 작업을 실시간으로 지켜볼 때입니다. 사용자가 작업을 지켜보는데도 알림이 여전히 너무 적다면 다음 방법 가운데 하나 이상을 쓰십시오.

하네스를 고칠 수 있다면, 사용자가 읽을 것이 하나도 없는 도구 호출 단계가 연속으로 몇 번 이어지는지를 하네스가 세게 하는 방법이 효과적입니다. 읽을 것이 없는 단계란 text 블록도 없고 텍스트가 든 thinking 블록도 없는 단계입니다. "omitted"에서는 모든 thinking 블록이 비어 있으므로, display를 "updates"나 "summarized"로 설정한 상태에서 세십시오. 이 방법은 플랫폼이 대화 중 시스템 메시지를 지원하는 곳에서 쓸 수 있습니다. 그런 단계가 여러 번 연속되면, 하네스가 가장 최근의 도구 결과 뒤에 다음 리마인더를 턴 범위 시스템 메시지로 덧붙이게 하십시오(clear_at: "next_user_message", 베타, mid-conversation-system-clear-at-2026-08-21 헤더).

The user hasn't heard from you in a while: say in a few words what you're doing, then continue.

사용자가 한동안 당신에게서 소식을 듣지 못했습니다. 지금 무엇을 하고 있는지 몇 마디로 말한 다음 계속하십시오.

Anthropic이 여러 턴에 걸친 코딩 작업으로 테스트했을 때, 이 리마인더는 가장 길게 침묵한 구간을 대략 절반으로 줄였고 토큰이나 시간은 눈에 띄게 늘지 않았습니다.

이후 요청에서도 각 리마인더를 messages에 그대로 두십시오. 리마인더를 지우거나 문구를 바꾸면 이전 턴을 수정하는 셈이 되고, 그러면 그 뒤에 오는 thinking 블록이 무효가 됩니다. 턴마다 보내는 리마인더를 턴 범위 시스템 메시지로 보내기를 참고하십시오.

첫 도구 호출 전의 첫마디, 간단한 알림, 마무리 요약까지 받으려면 시스템 프롬프트에 다음 텍스트를 추가하십시오.

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 (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.

시작하기 전에 무엇을 하려는지 한 줄로 말하십시오. 일하는 동안 간단히 상황을 알리면 사용자가 따라가기 쉽습니다. 마지막에는 그것만 읽어도 이해되는 짧은 요약(무엇을 발견했고, 무엇을 했고, 다음은 무엇인지)으로 마무리해서, 마지막 메시지만 보는 사람도 전체 상황을 알 수 있게 하십시오.

Anthropic이 코딩 작업으로 테스트했을 때, 이 텍스트가 있으면 모델은 매번 첫 도구 호출 전에 말을 했습니다. 이 텍스트는 작업당 출력 토큰도 대략 20퍼센트 늘렸습니다. 사람이 직접 지켜보며 개입하는 곳에 이 텍스트를 쓰십시오. 알림을 가장 많이 받으려면 하네스가 덧붙이는 리마인더와 함께 쓰십시오.

하네스를 고칠 수 없거나 플랫폼에 대화 중 시스템 메시지가 없다면 시스템 프롬프트에 다음 문장을 추가하십시오.

Every few tool calls, give the user a one-line update on where things stand.

도구를 몇 번 호출할 때마다 지금 상황이 어떤지 사용자에게 한 줄로 알리십시오.

Anthropic이 워크플로 자동화 작업으로 테스트했을 때, 이 문장은 길게 침묵하는 구간을 대부분 없앴습니다.

리마인더와 첫마디·요약 텍스트를 함께 쓰더라도, 알림과 알림 사이에 도구 호출이 여러 번 이어지는 구간은 있다고 생각하십시오. Claude Fable 5.2는 사용자가 단계마다 지켜보지 않고 나중에 결과를 보러 돌아오는, 오래 실행되는 비동기 작업을 잘 해냅니다. 그런 작업에서는 알림 사이의 공백이 덜 중요합니다.

서브에이전트에 대한 기대치 정하기

Claude Fable 5.2가 서브에이전트에 일을 얼마나 위임하는지는 여러분의 하네스와 작업에 달려 있습니다. Anthropic이 서브에이전트를 시작하는 최소한의 도구만 주고 짧은 작업으로 테스트했을 때는 서브에이전트를 거의 시작하지 않았습니다. 프롬프트가 위임을 권하는 에이전트 코딩 제품에서는 선뜻 위임합니다.

시스템 프롬프트, 스킬, 에이전트 파일이 모델에게 위임하라고 말하고 있다면 그 문장들부터 검토하십시오. 그러고도 Claude Fable 5.2가 작업에 필요한 것보다 많은 서브에이전트를 시작할 때에만 서브에이전트를 시작하는 도구의 설명을 바꾸십시오. 도구 설명이 평범하고 프롬프트의 다른 어디에서도 위임을 요청하지 않는다면 새 설명은 아마 필요 없을 것입니다.

새 설명에는 서브에이전트 하나가 세션 비용을 얼마나 늘리는지 밝히고, 언제 위임할 가치가 있고 언제 없는지 말하고, 모델이 자신이 시작하는 서브에이전트에게 작업을 어떻게 설명해 줘야 하는지 알려 주십시오. Anthropic이 테스트한 설명은 이 세 가지를 하면서 비용을 맨 앞에 둡니다. 이런 설명은 하네스가 이미 위임을 권하고 있고 서브에이전트가 토큰 사용량의 큰 몫을 차지할 때 가장 쓸모가 있습니다.

Anthropic이 짧은 작업으로 테스트했을 때, 위임할 이유를 주로 나열한 설명을 쓸 때보다 테스트한 설명을 쓸 때 모델이 3분의 1가량 덜 위임했습니다. 작업 성공률은 같았습니다.

테스트한 설명에서는 비용에 관한 첫 문장들이 위임을 억제합니다. 모델이 너무 적게 위임한다면 비용 이야기를 줄이십시오. 그래도 여전히 너무 많이 위임한다면 여러분의 하네스에서 서브에이전트에 드는 비용을 더 자세히 말하고, 그렇게 바꾼 결과를 테스트하십시오.

Anthropic은 한 에이전트 코딩 제품에서 Claude Fable 5.2가 xhigh나 max 같은 높은 노력 수준일 때 서브에이전트를 써서 자기 작업을 검토하는 것도 관찰했습니다. Claude Fable 5.1은 같은 작업에서 그렇게 하지 않았습니다. 초기 테스터들은 Claude Fable 5.2를 다른 모델들의 계획 담당이자 오케스트레이터로 써서 좋은 결과를 얻었습니다. 병렬로 잘 돌아가는 작업은 위임하면 빨라질 수 있습니다. 하지만 서브에이전트가 세션 비용의 큰 부분을 차지할 수 있으니, 여러분의 하네스가 서브에이전트를 기본으로 어떤 모델에서 실행하는지 확인하십시오.

조심성이 쌓이지 않게 하기

조심하라는 지시는 컨텍스트가 이어지는 곳이면 어디에나 쌓입니다. 메모리, 노트, 지시 파일, 에이전트끼리 주고받는 메시지가 그런 곳입니다. Claude Fable 5.2는 이런 지시를 충실히 따르기 때문에, 필요 없는 승인을 요청하거나 일상적인 작업을 하지 않고 미룰 수 있습니다. 초기 테스터 몇몇이 이런 동작을 보았고, 대부분 여러 에이전트가 함께 일하는 환경에서였습니다. 이전 모델들도 그런 지시를 따르지만, 여기서 설명하는 구성 가운데 하나에서는 Claude Fable 5.2만 일을 미뤘습니다.

이런 동작이 보이면 에이전트가 들고 다니는 것을 정리하십시오.

  • 더는 필요 없는 노트를 지우십시오. Anthropic이 모의 작업으로 테스트했을 때, 이전 세션에서 넘어온 노트 열두 개 가운데 하나가 절대 재시도하지 말라고 말하고 있었습니다. 그 노트들이 컨텍스트에 있고 프롬프트에 재시도를 허용하는 내용이 없을 때, 도구가 사용 중이어서 실패한 뒤에 모델이 재시도한 것은 열 번 중 네 번가량이었습니다. 그 노트들이 없을 때는 거의 매번 재시도했습니다.
  • 승인이 필요 없는 단계를 지목하십시오. Anthropic이 모의 작업으로 테스트했을 때, 컨텍스트에는 "절대 금지" 규칙, 노트, 리뷰어가 붙인 조건이 들어 있었습니다. 규칙 끝에 승인이 필요 없는 단계의 하나로 재시도를 든 한 줄을 넣자, 재시도가 거의 없던 수준에서 시도의 절반가량으로 늘었습니다. 같은 구성에서 더 자유롭게 행동하라는 일반적인 지시는 아무것도 바꾸지 못했습니다. 재시도는 반복해도 안전한 호출에 대해서만 지목하십시오.
  • 리뷰어 에이전트가 무엇을 덧붙이는지 확인하십시오. Anthropic이 모의 작업으로 테스트했을 때, 한 구성에서는 프롬프트에 승인이 필요 없는 단계의 하나로 재시도를 든 줄이 있었고, 컨텍스트에는 리뷰어가 쓴 "첫 오류에서 멈출 것"이 있었습니다. Claude Fable 5.2는 시도의 3분의 1가량에서 재시도하지 않았습니다. Claude Fable 5.1과 Claude Opus 5.5는 재시도했습니다.
  • 예외를 규칙 안에 써넣으십시오. Anthropic이 모의 작업으로 테스트했을 때, 책임자가 어떤 단계를 승인해 둔 상태였습니다. "절대 금지" 규칙 아래에서 모델이 그 단계를 실행한 것은 열 번에 한 번꼴이었습니다. 승인된 단계는 진행해도 된다고 따로 한 줄을 써 줘도 그 비율은 크게 달라지지 않았습니다. 규칙 자체가 먼저 진행 허락을 받으라고 말하게 하자, 모델은 열 번 중 아홉 번가량 그 단계를 실행했습니다. 승인을 참고하십시오.

위험하거나 되돌릴 수 없는 행동에 대한 확인 단계도 여러분 쪽에서 따로 유지하십시오.

이전 모델용으로 쓴 지시 검토하기

Claude Fable 5.2로 옮겨 갈 때는 프롬프트를 검토하십시오. Anthropic의 테스트에서, 이전 모델용으로 쓴 지시 가운데 일부는 비용을 높이거나, 부작용을 일으키거나, 더는 효과가 없었습니다. 다음 지시들을 다시 생각해 보십시오.

  • 항상 위임하라는 지시: 일을 서브에이전트에 넘기라는 문장이 시스템 프롬프트, 스킬, 에이전트 파일에 들어 있을 수 있습니다. 옮겨 가기 전에 그 파일들을 읽으십시오. 테스트해 보니 모델이 작업에 필요한 것보다 많은 서브에이전트를 시작한다면, 더는 필요 없는 문장을 지우십시오. 서브에이전트에 대한 기대치 정하기를 참고하십시오.
  • 하네스가 프롬프트에 써넣는 토큰 예산: 어떤 하네스는 작업에 토큰을 얼마나 쓸 수 있고 얼마나 남았는지를 프롬프트로 모델에게 알려 줍니다. Claude Fable 5.2가 토큰을 얼마나 쓰는지는 그 예산의 크기에 따라 달라집니다. Anthropic이 high와 xhigh 노력 수준에서 코딩 작업으로 테스트했을 때, 큰 예산을 지우자 성능은 그대로이면서 비용이 줄었습니다. 예산 없이 여러분의 작업을 테스트해 보십시오. 이 결과는 프롬프트에 들어가는 텍스트에 관한 것이고, API의 작업 예산에 관한 것이 아닙니다. 작업 예산은 베타 기능이며 이 테스트에서는 다루지 않았습니다.
  • 이전 턴을 수정하는 하네스 코드: Claude Fable 5.2는 보존된 사고(preserved thinking)를 사용합니다. 하네스가 요청과 요청 사이에 시스템 프롬프트나 도구, 이전 메시지를 바꾸면, 대화 기록에서 바뀐 지점 뒤에 오는 thinking 블록이 무효가 됩니다. 그러면 기본적으로 Messages API는 요청을 거부하고, Message Batches API는 그 블록들을 버립니다. 이 오류 없이 대화 기록을 줄이려면 컨텍스트 편집을 쓰거나, 요약 뒤에 이전 턴을 하나도 남기지 않는 컴팩션을 쓰십시오. Messages API도 블록을 버리게 하려면 thinking.block_binding.prefix_mismatch_behavior를 "drop_block"으로 설정하십시오(베타, thinking-binding-controls-2026-08-01 헤더). Anthropic의 테스트에서 매 턴마다 이전 사고가 버려지자 모델은 다시 생각했고 출력 토큰을 더 많이 썼습니다. 이것은 최악의 경우이고, 토큰이 얼마나 늘어나는지는 하네스가 이전 턴을 얼마나 자주 수정하는지에 달려 있습니다. 컴팩션과 컨텍스트 편집을 제외하면 대화 기록은 뒤에 덧붙이기만 하십시오. 그렇게 하면 캐시 적중률이 높게 유지되고 사고도 버려지지 않습니다. "drop_block"에 의존하기 전에 여러분의 작업에서 출력 토큰을 측정하십시오. 무효 블록을 API가 처리하는 방식과 접두부를 수정하지 않고 변경하기를 참고하십시오.
  • "그 답은 끝난 것으로 취급하라"는 문장: Claude Opus 5.5 프롬프팅은 채팅 시스템 프롬프트에 넣을 문장 두 개를 제안합니다. 이 문장들은 이전 답변을 끝난 것으로 취급하고 새 메시지에 사고를 집중하라고 모델에게 말합니다. Anthropic이 high 노력 수준에서 테스트했을 때, 이 문장들은 후속 질문에 대한 Claude Fable 5.2의 사고량을 줄였지만, 모델이 자신의 이전 답변에 있는 실수를 짚어 낼 가능성도 훨씬 낮아졌습니다. 모델이 이전 답변을 계속 다시 살펴보기를 원하는 곳에서는 이 문장들을 빼십시오. 그 밖의 곳에서는 이 문장들을 채택하기 전에 모델이 여전히 자기 실수를 짚어 내는지 테스트하십시오.
  • 덜 생각하라는 지시: Claude Fable 5.1은 "숙고하지 말고 바로 답하라" 같은 문장을 대체로 따릅니다. Anthropic의 테스트에서 그런 문장은 medium 이상에서 Claude Fable 5.2가 생각하는 것을 막지 못했습니다. 노력 수준 조정하기에서 설명한 대로, 이런 문장을 지우고 노력 수준을 낮추십시오.
  • 글쓰기 문체 규칙: Claude Fable 5.2는 문체 규칙을 충실히 따르기 때문에, "한 문장에 지시 하나, 20단어 이하" 같은 엄격한 제한이 있으면 글이 뚝뚝 끊길 수 있습니다. 보고서를 따라가기 쉽게 만들기의 텍스트를 추가하기 전에, 더는 필요 없는 규칙을 지우십시오.
  • 쌓여 온 규칙, 노트, 메모리: 메모리 파일, 노트, 지시 파일에는 시간이 지나면서 주의 사항이 쌓이고, 그중 일부는 모델이 직접 썼을 수도 있습니다. 옮겨 가기 전에, 이유가 더는 유효하지 않은 주의 사항을 지우고, 절대적인 규칙은 적용 범위와 이유를 밝히도록 다시 쓰십시오. 시스템이 이미 막혀서 움직이지 못한다면 메모리와 노트를 덜어 낸 상태로 다시 시작하는 것을 고려하고, 원본은 사본으로 남겨 두십시오. 조심성이 쌓이지 않게 하기를 참고하십시오.

보고서를 따라가기 쉽게 만들기

긴 에이전트 작업이 끝난 뒤 Claude Fable 5.2의 최종 보고서를 읽는 사람들은 대개 그 뒤에 있는 도구 호출이나 파일을 보지 못했습니다. 보고서는 그것만 읽어도 이해되어야 합니다.

Claude Fable 5.2에게 최종 보고서나 인수인계 문서를 쓰게 한다면 시스템 프롬프트에 다음 텍스트를 추가하고, 여러분의 독자와 제품에 맞게 고치십시오.

# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.

Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.

명확하게 전달하기 똑똑하지만 맥락을 잘 모르는 독자를 위해 쓰십시오. 읽는 사람은 당신의 도구 호출도, 추론도, 당신이 연 파일도 보지 못했고, 다른 일을 하다가 넘어왔을 수 있습니다. 메시지는 대체로 그것만으로 이해되어야 합니다. 독자가 다른 맥락을 찾아보지 않고도 무슨 뜻인지 알 수 있어야 합니다. 핵심은 처음 몇 문장 안에 두십시오. 문장 순서는 앞에서부터 차근차근 정보를 풀어 가도록 잡고, 12번째 줄에 가서야 이해되는, 정의되지 않은 지칭이나 개념을 첫 줄에 쓰지 마십시오.

쉬운 단어를 쓰고, 명확하고 이해하기 쉬운 완전한 문장으로 쓰십시오. 작업하다가 당신이 만들어 낸 용어나 약어는 쓰지 마십시오. 그것이 무엇인지 어떤 독자라도 이해할 수 있게 말하십시오. 대체로 ASD-STE100 Simplified Technical English의 문체로 쓰십시오. 짧은 문장, 한 문장에 생각 하나, 능동태, 같은 대상에는 일관되게 같은 단어를 씁니다. 생각이 서로 이어지는 곳에는 자연스럽게 흐르는 산문 단락을 쓰고, 불릿은 서로 별개인 항목을 나열할 때만 쓰십시오. 독자가 묻지 않는 한 불필요한 세부 사항은 빼고 간결하게 쓰되, 메시지에 핵심 맥락은 반드시 들어가게 하십시오. 사용자에게 보이는 글은 사람이 읽기에 가능한 한 쉽고 명확하게 쓰는 것을 목표로 하십시오.

Anthropic이 에이전트 작업으로 테스트했을 때, 이 텍스트가 있으면 최종 보고서가 덜 빽빽해졌고 세미콜론이 줄었습니다. 워크플로 자동화 작업에서는 문장도 짧아졌습니다. 길이에 관한 지시를 덧붙이거나, 특정 세부 사항을 포함하라고 모델에게 요청할 수도 있습니다.

안전장치에 의한 거부

Claude Fable 5.2에는 요청을 거절할 수 있는 안전 분류기가 돌아갑니다. 거절된 요청은 stop_reason: "refusal"을 반환하고, stop_details.category가 거부 범주를 알려 줍니다.

  • cyber: 요청이 악성코드나 익스플로잇 개발 같은 사이버 피해를 가능하게 할 수 있습니다.
  • bio: 요청이 위험한 실험 방법 같은 생물학적 피해를 가능하게 할 수 있습니다.
  • frontier_llm: 요청이 경쟁 AI 모델의 개발을 도울 수 있습니다.
  • reasoning_extraction: 요청이 모델에게 내부 추론을 응답 텍스트에 그대로 옮겨 쓰라고 합니다.
  • general_harms: 요청이 사용 정책의 다른 영역에 해당합니다.

무해한 사이버 보안 작업과 생명과학 작업도 cyber와 bio 분류기에 걸릴 수 있습니다. 분류기가 여러분 조직의 정당한 작업을 막는다면 Anthropic의 사이버 인증 프로그램(Cyber Verification Program)과 생명과학 인증 프로그램(Life Sciences Verification Program)을 참고하십시오. Claude Mythos 5.2는 Claude Fable 5.2와 같은 역량을 이 프로그램들로 인증받은 조직에만 제공합니다.

프롬프트, 스킬, 도구 설명이 모델에게 추론을 응답에 쓰라고 요청하고 있다면 그 지시를 지우십시오. 모델이 어떻게 추론했는지 보려면 display: "summarized"로 설정하고 thinking 블록을 읽으십시오. 추론은 thinking 블록 안에 두기를 참고하십시오.

거절된 요청을 다른 모델에서 다시 시도하는 방법은 거부, 폴백, 과금을 참고하십시오.

어디서부터 시작할까요

옮겨 갈 때는 다음 단계를 순서대로 밟으십시오.

  1. effort를 high로 명시적으로 설정한 다음, medium과 xhigh에서도 평가를 돌리십시오.
  2. 그대로 가져오는 시스템 프롬프트, 스킬, 에이전트 파일, 메모리 파일, 노트, 하네스 텍스트를 읽으십시오. 이전 모델용으로 쓴 지시 검토하기에 나열된 지시를 지우거나 테스트하십시오.
  3. 가장 긴 에이전트 작업을 실행하십시오. 모델이 어디에서 일찍 멈추는지, 필요 없는 승인을 요청하는지, 조용해지는지, 작업에 필요한 것보다 많이 위임하는지, 구조를 바꾸기를 원했던 곳에서 기존 코드에 덧붙이기만 하는지 기록하십시오.
  4. 관찰한 동작마다 해당하는 지침을 한 번에 하나씩 적용하고, 그 효과와 토큰 비용을 여러분의 작업으로 측정하십시오.
Edit this page

Search the archive

Find a page by title, or search the text inside one.