Claude Fable 5.1 프롬프팅

모델의 기능, API 변경 사항, 가격 및 가용성에 대해서는 Claude Fable 5.1의 새로운 기능을 참조하세요. Claude 모델 전반에 적용되는 기법에 대해서는 프롬프팅 모범 사례를 참조하세요.

기존 Claude Fable 5 프롬프트는 변경 없이도 Claude Fable 5.1에서 잘 작동할 것이지만, 알아두면 좋은 몇 가지 동작 차이가 있습니다. 관찰한 현상과 일치하는 섹션부터 시작하세요:

• 어떤 effort 수준으로 실행해야 할지 확실하지 않거나, 작업에 비해 지연 시간과 비용이 높은 경우: 모든 effort 수준 고려하기
• 도구 호출 사이에 텍스트가 거의 또는 전혀 없는 경우: 사용자 대상 진행 상황 업데이트 요청하기
• 에이전트 루프에서 턴당 도구 호출이 하나뿐인 경우: 에이전트 루프에서 독립적인 도구 호출 일괄 처리하기
• 요청이 bound to a different conversation 오류로 실패하거나, 하네스가 요청 사이에 이전 턴을 편집하는 경우: 대화 기록을 추가 전용으로 유지하기
• 산문이 길고 밀도가 높은 경우: 작문 밀도
• 채팅 응답이 콘텐츠에 필요한 것보다 구조가 부족한 경우: 채팅에서의 서식
• 요약이 인용임을 표시하지 않고 출처의 문구를 그대로 재현하는 경우: 검색된 출처 인용하기
• 작업이 완료되기 전에 턴이 끝나거나, 이미 요청한 작업에 대해 모델이 허락을 구하는 경우: 전체 작업 완료하기
• 클라이언트 측 컴팩션 요약에서 제약 조건, 결정 사항 또는 정확한 세부 정보가 누락되는 경우: 컴팩션 요약에서 보존할 내용을 모델에 알려주기
• 요청하지 않은 수정이나 확장, 또는 작업에 필요한 것보다 많은 테스트 파일이 커밋되는 경우: 변경 사항과 테스트를 작업이 요구하는 범위로 유지하기
• 낮은 effort에서 검색 대신 기억에 의존해 답변하는 경우: 낮은 effort에서의 검색 트리거
• 무해한 코딩 요청이 stop_reason: "refusal"을 반환하는 경우: 안전장치 오탐 줄이기
• 작은 변경에 파일 전체가 다시 작성되는 경우: 파일 전체 재작성보다 대상 지정 편집 선호하기
• xhigh 또는 max effort에서 긴 결과물이 오래 걸리거나 max_tokens에 도달하는 경우: xhigh 및 max effort에서 긴 출력을 위한 여유 남기기
• 서브에이전트가 실행되는 동안 리드 에이전트가 유휴 상태인 경우: 서브에이전트가 실행되는 동안 리드 에이전트가 계속 작업하도록 하기
• 차트와 밀도 높은 이미지에 대한 답변에서 세부 정보가 누락되는 경우: 비전 작업에 자르기 및 확대 도구 제공하기

모든 effort 수준 고려하기

기본 effort 수준인 high에서 시작한 다음, 다른 수준(low, medium, xhigh, max)을 자체 평가로 테스트하세요. Effort는 Claude Fable 5.1에서 지능, "latency"(지연 시간), 비용 간의 균형을 조절하는 주요 제어 수단입니다. Claude Fable 5에서 이미 스윕을 실행했더라도 다시 실행하세요. effort 수준 이름은 모델 간에 동일한 양의 사고에 대응하지 않습니다.

Claude Fable 5.1의 Claude Fable 5 대비 기능 향상은 effort 수준 전반에 걸쳐 나타나며 더 높은 설정에서 가장 큽니다. medium에서는 결과가 대략 Claude Fable 5와 일치하면서 비용이 더 낮으므로, 평가에서 품질이 유지되는 경우 medium 또는 low로 낮추세요. low에서 Claude Fable 5.1은 작업당 비용 면에서 Claude Opus 및 Claude Sonnet 모델과 경쟁력이 있으면서도 더 높은 점수를 받는 경우가 많으므로, 그렇지 않으면 더 작은 모델을 더 높은 effort 수준에서 실행할 상황이라면 비교에 포함하세요.

두 가지 effort별 동작은 별도의 섹션에서 다룹니다. low에서 Claude Fable 5.1은 검색 및 조회 도구를 덜 자주 호출하며(낮은 effort에서의 검색 트리거 참조), xhigh 및 max에서는 긴 결과물을 작성하기 전에 더 오래 사고할 수 있습니다(xhigh 및 max effort에서 긴 출력을 위한 여유 남기기 참조).

사용자 대상 진행 상황 업데이트 요청하기

Claude Fable 5.1은 긴 도구 호출 턴 동안 Claude Fable 5보다 사용자 대상 업데이트를 더 적게 작성할 수 있으며, 특히 높은 effort와 긴 도구 체인에서 그렇습니다. 사용자는 에이전트가 한 번에 몇 분씩 조용해지거나, 전체 작업이 아닌 마지막 단계만 다루는 최종 메시지를 보게 됩니다.

먼저, 클라이언트가 진행 상황 업데이트를 수신하고 있는지 확인하세요. 도구 호출 사이에 모델이 작성하는 짧은 메모, 즉 방금 발견한 것과 다음에 할 일은 진행 상황 업데이트 thinking 블록으로 반환되며, 이 블록은 기본 thinking.display 값인 "omitted"에서는 비어 있습니다. display: "updates"(베타, thinking-display-updates-2026-08-18 헤더)를 설정하고 비어 있지 않은 각 thinking 블록을 상태 줄로 렌더링하거나, "summarized"로 설정하여 요약된 추론과 함께 수신하세요. 이를 요청하지 않는다면 모델의 업데이트가 단순히 사용자에게 도달하지 않는 것일 수 있습니다.

둘째, 서술을 억제하는 지시가 있는지 프롬프트를 점검하세요. 일부 이전 모델은 작업 중에 업데이트를 제공하려는 경향이 강했고, 이로 인해 "모든 발견 사항은 최종 응답까지 보류하라"와 같은 시스템 프롬프트 문구가 생겼습니다. 무언가를 추가하기 전에 이런 문구를 먼저 제거하세요.

페어 프로그래밍이나 기타 사람이 개입하는 작업 등에서 여전히 더 많은 업데이트를 원한다면, 모델로부터 사용자 대상 텍스트를 언제 원하는지와 각 업데이트에 무엇이 포함되어야 하는지를 명시하는 짧은 시스템 프롬프트 문구를 추가하세요:

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.

제품이 도구 출력을 접거나 숨기는 경우, 모델에 알려주세요. 그렇지 않으면 UI가 표시하지 않는 출력을 사용자에게 "보여주기" 위해 명령을 실행할 수 있습니다. 이 메모는 턴 범위 시스템 메시지(clear_at: "next_user_message", 베타)로 전달하세요:

Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.

에이전트 루프에서 독립적인 도구 호출 일괄 처리하기

Claude Fable 5.1은 일반적으로 예상대로 병렬 도구 호출을 실행합니다. 요청에서 가져올 여러 항목을 명시하면 해당 호출을 병렬로 실행합니다. 예외는 다음 독립 호출이 명시적으로 요청되지 않고 작업에 의해 암시되는 코딩 및 컴퓨터 사용 루프(커스텀 코딩 에이전트, bash 및 편집기 하네스, 컴퓨터 사용)입니다. 이 경우 턴당 하나씩 실행할 수 있습니다. 이는 답변 품질에 영향을 주지 않지만, 추가 턴마다 토큰, 왕복, 실제 경과 시간이 소요됩니다. 현재 요청 끝에 한 문장의 넛지를 추가하면 해결됩니다:

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

도구 결과를 다시 보낼 때마다 해당 사용자 메시지 뒤에 턴 범위 시스템 메시지로 추가하세요. 즉, messages에 clear_at: "next_user_message"가 있는 role: "system" 항목입니다. 이후 사용자 메시지가 존재하면 API가 이전 사본을 지우므로 모델은 최신 사본만 읽습니다. 턴 범위 시스템 메시지는 베타이며 베타 헤더 mid-conversation-system-clear-at-2026-08-21이 필요합니다. 베타를 사용하지 않는 경우, 대신 같은 사용자 메시지의 tool_result 블록 뒤에 텍스트 블록으로 문장을 배치하세요.

매 턴마다 새 사본을 추가하고 이전 사본은 바이트 단위로 그대로 두세요. 이전 사본은 배열에 남아 있지만, 지워진 후에는 모델이 보지 않으며 입력 토큰 비용도 발생하지 않습니다. 이를 삭제하거나 다시 작성하는 것은 이전 턴에 대한 편집입니다. 해당 지점부터 프롬프트 캐시가 다시 시작되고 그 이후의 thinking 블록이 무효화됩니다(대화 기록을 추가 전용으로 유지하기 참조).

다음 루프는 이 배치를 보여줍니다. 각 어시스턴트 턴은 반환된 그대로 돌아가고, 각 사용자 턴은 도구 결과만 담으며, 그 뒤에 넛지의 새로운 턴 범위 사본이 따라옵니다.

import anthropic
from anthropic.types.beta import (
    BetaMessageParam,
    BetaToolParam,
    BetaToolResultBlockParam,
)

client = anthropic.Anthropic()

BATCH_NUDGE = (
    "First privately list what you need next; then request every item "
    "that doesn't depend on another's result in this one response."
)
# 인메모리 파일이 작업 디렉터리를 대신하므로 샘플을 어디서나 실행할 수 있습니다.
FILES = {
    "pyproject.toml": """\
[project]
name = "demo"
version = "0.1.0"
description = "Demo project for the batching example"
""",
    "README.md": """\
# demo

A small demo project. Run `demo --help` for usage.
""",
}
tools: list[BetaToolParam] = [
    {
        "name": "read_file",
        "description": "Read a UTF-8 text file from the working directory.",
        "input_schema": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    }
]
messages: list[BetaMessageParam] = [
    {"role": "user", "content": "Summarize pyproject.toml and README.md."}
]

while True:
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        betas=["mid-conversation-system-clear-at-2026-08-21"],
        tools=tools,
        messages=messages,
    )
    # thinking 블록을 포함하여 어시스턴트 턴을 반환된 그대로 추가합니다.
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results: list[BetaToolResultBlockParam] = []
    for block in response.content:
        if block.type == "tool_use":
            path = str(block.input["path"])
            if path in FILES:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": FILES[path],
                    }
                )
            else:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"File not found: {path}",
                        "is_error": True,
                    }
                )
    # 도구 결과를 사용자 턴으로 보낸 다음, 넛지의 새 사본을
    # 턴 범위 시스템 메시지로 보냅니다. 이전 사본은 그대로 둡니다. API가 이를 지우므로
    # 모델은 최신 사본만 보게 됩니다.
    messages.append({"role": "user", "content": tool_results})
    messages.append(
        {"role": "system", "content": BATCH_NUDGE, "clear_at": "next_user_message"}
    )

print(next((block.text for block in response.content if block.type == "text"), ""))

대화 기록을 추가 전용으로 유지하기

각 어시스턴트 턴을 thinking 블록을 포함하여 API가 반환한 그대로 기록에 추가하고, 요청 사이에 이전 턴을 편집하지 마세요. 2026년 8월 31일 이후에 생성된 신규 계정의 경우, Claude Fable 5.1의 thinking 블록은 해당 블록을 생성한 정확한 대화에서만 유효합니다. 접두사(시스템 프롬프트, 도구 목록 또는 이전 메시지)가 변경된 후 thinking 블록을 재전송하는 요청은 400을 반환하거나, thinking.block_binding.prefix_mismatch_behavior: "drop_block"(베타, thinking-binding-controls-2026-08-01 헤더)을 설정한 경우 영향받는 블록을 삭제합니다. 향후 모델은 모든 계정에 대해 이 검사를 적용할 것으로 예상되므로, 현재 적용되지 않더라도 지금 이 패턴을 채택하세요.

이 검사에 걸리는 기록 편집은 프롬프트 캐시를 다시 시작시키는 것과 동일합니다. 턴별 리마인더 삽입 및 제거, 이전 턴을 제자리에서 요약하기, 세션 중간에 시스템 프롬프트 변경하기 등입니다. 턴별 리마인더는 턴 범위 시스템 메시지로 보내고, system이나 tools를 다시 작성하는 대신 대화 중간 시스템 메시지로 지시나 도구를 변경하며, 트리밍은 서버 측 컴팩션 또는 컨텍스트 편집에 맡기세요. 클라이언트에서 컴팩션하는 경우, 가장 간단한 형태는 전체 기록을 하나의 요약 메시지와 새 사용자 턴으로 교체하고 다른 것은 재전송하지 않는 것입니다. thinking 블록이 이어지지 않으므로 실패할 것이 없고, 모델은 컴팩션된 대화에서 새로 사고합니다(클라이언트에서의 커스텀 컴팩션 참조).

하네스가 이미 수행하고 있는 편집을 찾으려면, 통합이 영향을 받는지 확인하는 방법에 설명된 대로 prefix_mismatch_behavior: "drop_block"으로 세션을 실행하고 input_transformations를 로깅하거나, 몇 번의 일반적인 턴에 걸쳐 전송되는 정확한 요청을 캡처하여 연속된 요청이 추가된 턴까지 바이트 단위로 동일한지 확인하세요.

작문 밀도

Claude Fable 5.1의 글쓰기는 일반적으로 이전 Claude 모델보다 한 단계 향상되어, 상투적인 문구가 적고 설명 없는 전문 용어도 적습니다. 그러나 일부 경우에는 Claude Fable 5보다 산문의 밀도가 높습니다. 문장이 더 길고 단락 구분이 적습니다. 안티패턴인 꾸민 산문(mannered prose)을 정의하는 지시가 도움이 됩니다. 사용자 메시지(권장) 또는 시스템 프롬프트에 추가하세요:

Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.

짧은 버전도 대체로 효과가 있습니다:

Please remove all mannered prose.

채팅에서의 서식

이전 모델은 채팅에서 글머리 기호와 굵은 글씨를 과도하게 사용했고, 많은 프롬프트에는 이를 억제하기 위해 작성된 서식 금지 규칙이 포함되어 있습니다. Claude Fable 5.1은 반대 방향으로 기웁니다. 굵은 글씨를 덜 사용하고 헤더, 목록 또는 인용 부호를 사용할 가능성이 낮습니다. 프롬프트에 서식 금지 문구가 포함되어 있다면 제거하거나, 다음과 같이 특정 서식이 언제 적절한지를 명시하는 규칙으로 교체하세요:

Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.

검색된 출처 인용하기

문서를 요약할 때 Claude Fable 5.1은 Claude Fable 5보다 출처 텍스트의 구절을 인용임을 표시하지 않고 재현할 가능성이 더 높습니다. 이를 해결하려면 시스템 프롬프트에 올바른 응답의 완전한 예시 하나를 추가하세요. 사용자의 요청, 응답, 그리고 해당 응답이 올바른 이유를 설명하는 문장입니다.

<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>

두 개의 [web_search: ...] 줄을 자체 도구 이름으로 교체하여, 모델이 이를 출력해야 할 리터럴 텍스트가 아닌 템플릿화된 도구 출력으로 읽도록 하세요.

전체 작업 완료하기

Claude 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.

Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.

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 ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.

Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.

사용자가 지켜보고 있지 않다고 모델에 알려주는 첫 문장이 효과의 상당 부분을 담당합니다. 작성된 그대로 유지하세요. 제품에서 모델이 특정 확인을 위해 멈춰야 한다면, 그 뒤에 해당 항목을 나열하는 문장을 추가하세요. 이 블록은 모델이 모호한 요청에 대해 질문할 가능성도 낮출 수 있으므로, 자체 작업에서 이 트레이드오프를 확인하세요.

두 번째는 사용자의 요청을 결과물의 범위로 정의합니다:

# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.

If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.

Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.

컴팩션 요약에서 보존할 내용을 모델에 알려주기

Claude Fable 5.1은 긴 대화가 컴팩션될 때 요약이 무엇을 유지해야 하는지 명시적으로 알려주면 잘 반응합니다. 서버 측 컴팩션은 이미 이를 수행합니다. 클라이언트 측에서 컴팩션하는 경우 다음 요약 지시를 사용하세요:

Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.

변경 사항과 테스트를 작업이 요구하는 범위로 유지하기

개방형 기능을 구현하도록 요청받으면 Claude 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. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. 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 — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.

낮은 effort에서의 검색 트리거

low effort에서 Claude Fable 5.1은 Claude Fable 5보다 검색 또는 조회 도구를 호출할 가능성이 낮고, 기억에서 답변할 가능성이 높습니다. 일부 경우에는 가장 간단한 해결책이 전체 대화가 아닌 영향을 받는 턴에 대해 effort를 높이는 것입니다. 대화 중간에 effort 변경을 참조하세요.

다른 경우에는 검증을 유도하는 프롬프트 넛지가 도움이 됩니다. 시스템 프롬프트에서 이름을 인식하는 것이 그 현재 상태를 아는 것과 같지 않으며, 그러한 이름은 사용자가 작성한 그대로 검색해야 한다고 명시하세요:

When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

안전장치 오탐 줄이기

Claude Fable 5.1의 안전 분류기는 출시 당시 Claude Fable 5보다 오탐이 적으며, 소스 코드에서 취약점을 찾는 것은 허용됩니다. 오탐은 여전히 발생하며, 차단된 요청은 stop_reason: "refusal"을 반환합니다(거부, 폴백 및 청구 참조). 세 가지 상황에서 오탐 가능성이 높아집니다:

• 컴파일 확인 문구: "이 프로그램이 오류 없이 컴파일됩니까?" 대신 "이 프로그램에 버그가 있습니까?"라고 물으세요.
• 잘 알려지지 않은 프로그래밍 언어: 예를 들어 해당 언어의 문서에 대한 접근 권한을 제공하는 등, 언어가 무엇이고 어떻게 작동하는지에 대한 컨텍스트를 모델에 제공하세요.
• 도구 출력의 Base64: base64로 인코딩된 데이터를 모델의 컨텍스트로 반환하는 도구는 오탐을 유발할 수 있으므로, 이를 제거하는 것이 권장되는 해결책입니다.

파일 전체 재작성보다 대상 지정 편집 선호하기

Claude Fable 5.1이 작은 변경에 파일 전체를 다시 작성한다면, 다음 지시를 시스템 프롬프트나 첫 번째 사용자 메시지에 추가하세요. Claude Fable 5.1은 Claude Fable 5보다 대상 지정 편집 대신 텍스트 파일 전체를 다시 작성할 가능성이 높습니다. 결과 파일은 대개 동일하지만, 파일이 짧거나 대부분이 변경되는 경우가 아니라면 재작성은 더 많은 출력 토큰과 시간을 소요합니다. 이 지시는 작은 변경과 중간 규모 변경에 대해 Claude Fable 5.1을 Claude Fable 5와 같은 수준으로 되돌립니다.

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.

xhigh 및 max effort에서 긴 출력을 위한 여유 남기기

xhigh 및 특히 max effort에서 Claude Fable 5.1은 응답 작성을 시작하기 전에 더 오래 사고할 수 있습니다. 단일 요청이 긴 문서의 전체 재작성과 같은 긴 결과물을 요구하면, 해당 결과물의 상당 부분을 사고 과정에서 초안으로 작성한 다음 응답으로 다시 작성할 수 있으며, 이는 더 긴 대기 시간과 더 많은 출력 토큰을 의미합니다. 가장 간단한 접근 방식은 이러한 요청을 권장 시작점인 high에서 실행하고, 품질 향상을 측정한 경우에만 xhigh 또는 max로 이동하는 것입니다(모든 effort 수준 고려하기 참조). xhigh 또는 max에서 실행한다면:

• 예상하는 응답 길이뿐만 아니라 사고와 응답 모두를 위한 여유를 남기도록 max_tokens를 설정하세요.
• 사용자 메시지 끝에 다음 메모를 추가하세요. 산문 및 코드 요청에서 사고를 훨씬 짧게 만듭니다. [max_tokens]를 요청의 실제 max_tokens 값(예: 64,000)으로 교체하세요.

Everything Claude produces in one reply, including any reasoning or drafting it does before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so Claude doesn't do that.

Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, Claude spends extra effort on understanding the request, checking the inputs Claude's answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. If Claude plans well then it should not need to draft its output multiple times (and Claude is pretty good at planning, so this should not be an issue).

서브에이전트가 실행되는 동안 리드 에이전트가 계속 작업하도록 하기

코딩 에이전트가 Claude Fable 5.1이 서브에이전트에 작업을 위임하도록 허용한다면, 리드 에이전트가 멈춰서 각 서브에이전트를 기다리도록 강제하지 마세요. 코딩 작업에서 서브에이전트가 실행되는 동안 리드가 계속 작업하도록 하면 유사한 품질, 토큰 사용량, 비용으로 평균 완료 시간이 줄어듭니다. 이를 설정하려면:

• 서브에이전트를 시작하는 도구가 즉시 반환하도록 하세요.
• 각 서브에이전트의 결과가 준비되면 이후 user 메시지로 리드에 전달하세요.
• 리드가 결과를 기다리고 싶을 때 호출할 수 있는 별도의 도구를 제공하세요.

모델은 여전히 기다리기를 선택하는 경우가 많습니다. 시간 절약은 다른 작업을 계속 진행하는 실행에서 발생합니다.

비전 작업에 자르기 및 확대 도구 제공하기

Claude Fable 5.1은 기본적으로 더 나은 비전 기능을 갖추고 있으며, 밀도 높은 차트와 같은 복잡한 시각적 입력에서는 보이는 것을 반복적으로 분석하고, 자르고, 시각적으로 검증할 수 있을 때 최상의 결과를 냅니다. 모든 이점을 얻으려면 원본 이미지나 비디오를 보관하고 기본 이미지 처리 라이브러리(PIL 및 OpenCV 등)가 사전 설치된 컨테이너에 접근할 수 있는 에이전트로 모델을 실행하세요. 컨테이너 실행이 너무 부담스럽다면 이미지 자르기 도구만으로도 향상의 대부분을 얻을 수 있습니다. 이미지의 선택된 영역을 잘라 확대하여 반환하는 도구는 모델이 특정 세부 사항을 더 깊이 검토할 수 있게 하고 이미지 토큰으로 테스트 시간 컴퓨팅을 확장합니다. 자르기 도구 레시피에 작동하는 정의가 있습니다.