Claude Platform Docs
모범 사례프롬프트 엔지니어링

Claude Sonnet 5.5 프롬프팅

Claude Sonnet 5.5에 특화된 프롬프팅 패턴: effort, 주도성과 범위, 사전 사고 없이 실행하기, JSON 출력, 진행 상황 업데이트, 도구 사용, 턴 중간 메시지, 코딩 검증, 도구 호출, 시각적 입력, 거부.

이 가이드는 Claude Sonnet 5.5에 특화된 프롬프팅 패턴을 다룹니다. 모델의 API 변경 사항은 Claude Sonnet 5.5의 새로운 기능을 참조하세요. 현재의 모든 Claude 모델에 적용되는 기법은 프롬프팅 모범 사례를 참조하세요.

기존 Claude Sonnet 5 프롬프트는 변경 없이도 잘 작동하며, Claude Sonnet 5 프롬프팅의 패턴도 여전히 합리적인 출발점입니다. 가장 어려운 장기 작업에는 Opus 모델이 더 나은 선택입니다. 관찰한 현상에 해당하는 섹션부터 시작하세요:

Effort 보정

Effort(노력 수준)는 Claude Sonnet 5.5가 얼마나 많이 사고하는지, 그리고 그에 따라 품질, "latency"(지연 시간), 비용을 조절하는 주요 제어 수단입니다. 그 수준들은 재보정되었습니다. 즉, 같은 수준이라도 Claude Sonnet 5에서와 같은 양의 사고를 생성하지 않습니다. Claude Sonnet 5에서 사용하던 설정을 그대로 가져오지 말고, 자체 평가를 대상으로 새로 스윕을 실행하세요. 워크로드가 에이전트형이거나 지연 시간에 민감하지 않다면, Claude API의 기본값인 high로 시작하세요. 에이전트 코딩과 다단계 도구 사용의 경우, 명확하게 정의된 작업은 medium으로 시작하고 더 어렵거나 긴 작업은 high로 올리세요. 채팅 및 기타 지연 시간에 민감한 작업의 경우, effort가 높을수록 응답이 시작되기까지 더 오래 기다려야 하므로 medium 또는 low로 시작하세요. 품질이 필요하다면 effort를 높이세요.

낮은 effort는 모델이 에이전트 작업을 마무리하는 방식도 바꿉니다. low에서는 사고를 짧게 유지하며 변경 사항 검증을 건너뛸 수 있습니다. 코딩 작업에서의 검증을 참조하세요. low와 medium에서는 긴 에이전트 작업 중에 작업을 마치기 전에 멈추고 사용자에게 확인을 요청할 가능성이 더 높습니다. 주도성과 범위 조정을 참조하세요.

다음 세 가지 조정이 도움이 됩니다:

  • 사고와 예상되는 응답을 위한 여유를 두고 max_tokens를 설정하세요. 사고 내용이 반환되지 않더라도 사고는 max_tokens에 포함됩니다. 사고가 없는 요청에 맞춰 설정한 한도는 응답을 잘라낼 수 있습니다. 에이전트 코딩의 경우 max_tokens를 모델의 최대값인 128,000으로 설정하고 응답을 스트리밍하세요.
  • xhigh와 max는 품질 향상을 측정으로 확인한 작업에만 사용하세요. 이 수준에서는 사고와 응답이 훨씬 길어지기 때문입니다. 이 수준에서는 between_tools가 허용되지 않으므로 사전 사고를 끌 수 없습니다.
  • 사고를 줄이려면 effort 수준을 낮추세요. medium 이상에서는 모델이 인사말을 포함한 거의 모든 응답 전에 잠깐 사고하며, 이는 첫 번째로 보이는 토큰까지의 시간을 늘립니다. 시스템 프롬프트에서 사고를 줄이라고 요청해도 사고가 안정적으로 줄어들지는 않습니다. low에서는 대부분의 간단한 요청에서 사고를 건너뜁니다.

요청 간에 최상위 effort 값을 변경하면 프롬프트 캐시가 무효화됩니다. 개별 턴을 다른 수준으로 실행하려면 대신 캐시를 유지하는 메시지별 effort 변경(베타)을 사용하세요. 예를 들어, 대화형 세션을 low로 실행하다가 사용자가 어려운 문제를 제출하면 effort를 high로 올릴 수 있습니다. 메시지별 effort 변경에는 적응형 사고가 필요합니다. 사전 사고 없이 실행하기에서 설명하듯이, between_tools와 함께 사용하면 400 오류가 반환됩니다.

주도성과 범위 조정

Claude Sonnet 5.5가 스스로 얼마나 멀리 나아가는지는 effort 수준과 요청에 따라 달라집니다. 낮은 effort에서는 코딩 작업이 끝나기 전에 확인을 요청하는 경우가 있습니다. 높은 effort에서나 개방형 요청에서는 요청한 것보다 더 많은 작업을 할 수 있습니다. effort 수준과 시스템 프롬프트의 지시로 모델을 조정하세요.

작업을 끝까지 수행하기. low 및 medium effort의 에이전트 코딩 작업에서 모델은 작업이 끝나기 전에 확인을 요청하는 경우가 있습니다. 계획을 확인하기 위해 멈추거나, 스스로 답할 수 있는 질문을 하거나, 여러 부분으로 된 작업의 한 부분을 마친 후 계속할지 묻기 위해 멈출 수 있습니다. 먼저 더 높은 effort 수준을 시도해 보세요. effort를 변경하지 않고 모델이 계속 작업하도록 하려면 시스템 프롬프트에 다음을 추가하세요:

Keep working until everything the user asked for is done, and only stop to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for. If you think one would help, mention it at the end instead of doing it.

이 프롬프트를 사용하면 모델이 low 및 medium effort에서 더 많은 작업을 끝까지 수행하므로, 해당 수준의 세션이 더 오래 실행되고 비용이 더 많이 듭니다. 이 프롬프트는 위험하거나 되돌릴 수 없는 작업에 대한 자체 규칙을 대체하지 않습니다. 그러한 규칙은 시스템 프롬프트에 유지하세요.

코딩 시 요청하지 않은 추가 작업. 모델은 요청하지 않아도 저장소의 규칙에 맞는 테스트, 문서, 작은 보조 파일을 추가하는 경향이 있습니다. 이는 모든 effort 수준에서 나타나며, effort가 높을수록 더 많이 나타납니다. 요청된 변경 자체는 요청된 내용에 가깝게 유지됩니다. 대부분의 팀은 이를 환영할 것입니다. 명시적으로 요청된 내용으로만 변경을 제한하고 싶다면, 위 프롬프트에서 "When the work the user asked for is done"으로 시작하는 두 번째 단락만 추가하세요. xhigh 및 max effort에서 이 단락은 이러한 추가 작업을 줄이고 전반적으로 변경 규모를 작게 만듭니다.

xhigh 및 max effort에서의 철저함. 이 수준에서 모델은 특히 철저합니다. 작업을 마친 후 자체적으로 검토 및 검증 라운드를 시작할 수 있으며, "harness"(하네스)가 제공하는 경우 "subagent"(서브에이전트)를 사용하기도 합니다. 또한 작업 중에 발견한 관련 수정 사항을 적용할 수도 있습니다. 이는 더 많은 시간과 토큰을 소모하므로, 일상적인 작업은 이러한 동작이 드문 high 이하에서 실행하세요. 이러한 effort 수준의 추가적인 철저함을 원하지만 이를 작업 자체에 집중시키고 싶다면 시스템 프롬프트에 다음을 추가하세요:

When the work the user asked for is done and its checks pass, stop and report. Don't start extra rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user asked for a review. If you think a deeper review is worth doing, say so at the end.

max effort의 코딩 작업 테스트에서 이 프롬프트는 모델이 검토용 서브에이전트를 실행하는 것을 막았고, 품질 변화 없이 세션 비용을 약 3분의 1 줄였습니다. 메인 에이전트가 스스로 시작하는 검토 라운드의 빈도는 줄어들지만 완전히 없어지지는 않습니다.

개방형 요청. "이걸로 무엇을 할 수 있는지 보여줘"와 같은 개방형 요청의 경우, 아이디어만 원했는데도 모델이 프레젠테이션, 보고서 또는 동영상을 만들기 시작할 수 있습니다. 먼저 아이디어나 계획을 원한다면 요청에서 그렇게 말하거나 시스템 프롬프트에 다음을 추가하세요:

When the user asks for ideas, options or a plan, give them that and stop. Don't start building or changing anything until they say to go ahead.

사전 사고 없이 실행하기

Claude Sonnet 5.5를 "up-front thinking"(사전 사고) 없이 실행하려면 thinking: {"type": "between_tools"}를 보내세요. 이는 이 모델에서 가장 낮은 사고 설정이며, high effort 이하에서 허용됩니다. 현재 통합이 사고를 끈 상태로 실행된다면 between_tools로 전환하고 다음 사항을 확인하세요:

  • between_tools는 high effort 이하에서 보내세요. xhigh 또는 max effort에서 between_tools를 포함한 요청은 400 오류를 반환합니다. between_tools를 사용하면 대화 중간에 effort를 변경할 수도 없습니다. 현재 적용 중인 수준과 다른 메시지별 output_config.effort는 400 오류를 반환합니다. 턴마다 effort를 다르게 하려면 적응형 사고를 사용하세요. between_tools를 사용할 때는 모델에게 사고하지 말라고 지시하는 내용을 모두 제거하세요. 그러한 지시는 모델이 보이는 출력에 내부 XML 태그를 작성할 가능성을 높입니다.
  • 블록 유형별로 응답을 읽으세요. 적응형 사고를 사용하면 응답이 thinking 블록으로 시작할 수 있으며, 기본값인 display: "omitted"에서는 이 블록의 thinking 필드가 비어 있습니다. between_tools를 사용하면 응답이 진행 상황 업데이트 thinking 블록으로 시작할 수 있습니다. 첫 번째 콘텐츠 블록이 텍스트라고 가정하지 마세요.
  • thinking 블록을 변경 없이 다시 전달하세요. between_tools를 사용하더라도, 모델이 도구 호출 사이에 작성하는 메모가 한두 문장보다 길면 여전히 thinking 블록으로 반환됩니다. 각 블록에는 메모의 요약이 담겨 있습니다. 나머지 어시스턴트 턴과 함께 변경 없이 다시 전달하세요. 다시 보낸 블록은 모델에게 요약이 아닌 모델이 작성한 전체 메모를 제공합니다.
  • 도구가 없는 추론 작업에는 적응형 사고를 사용하세요. 도구가 없는 요청에서 between_tools는 모델이 먼저 사고하지 않고 답변한다는 의미입니다. 몇 단계의 풀이가 필요한 작업에는 대신 적응형 사고를 사용하세요. JSON 출력을 사용하는 추론 작업을 참조하세요.

JSON 출력을 사용하는 추론 작업

이 섹션은 몇 단계의 풀이가 필요한 작업에 대해 Claude Sonnet 5.5에 JSON 답변을 요청할 때 적용됩니다. 예를 들어 문서의 수치 합산, 규칙 적용, 항목 순위 매기기 등이 있습니다. 이러한 작업에서 모델은 특히 low 및 medium effort에서 먼저 사고하지 않고 답변하는 경우가 많습니다. 무엇이 도움이 되는지는 JSON을 요청하는 방식에 따라 다릅니다. 사용 가능한 경우 구조화된 출력을 사용하세요. 그러면 응답 텍스트가 스키마와 일치하는 JSON이 되므로 파싱할 것이 없습니다.

구조화된 출력을 사용하면 응답 텍스트에는 JSON만 담기므로, 모델은 사고 안에서만 문제를 풀 수 있습니다. 사고를 건너뛰면 이러한 작업에서 정확도가 떨어질 수 있습니다. 다음 변경 사항은 정확도를 높게 유지하는 데 도움이 됩니다.

모델에게 먼저 사고하도록 요청하세요. 적응형 사고를 사용할 때 시스템 프롬프트 끝에 다음 줄을 추가하세요:

Think the problem through before you answer.

이 줄을 추가하면 모델이 답변하기 전에 사고하는 경우가 더 많아집니다. high effort에서 이 줄은 출력 토큰을 약간만 늘리면서 정확도를 모델이 xhigh에서 도달하는 수준에 가깝게 끌어올립니다. low 및 medium effort에서는 정확도를 높이지만 모델이 high에서 도달하는 수준까지는 아니며, 출력 토큰 증가폭은 더 큽니다.

또는 xhigh effort를 사용하세요. 적응형 사고를 사용할 때 xhigh는 이 줄이 없어도 이러한 작업에서 가장 높은 정확도를 제공합니다. high보다 더 많은 출력 토큰을 사용합니다.

between_tools 대신 적응형 사고를 사용하세요. 도구가 없는 요청에서 between_tools를 사용하면 모델은 답변하기 전에 사고하지 않습니다. 이 경우 위의 줄은 효과가 없으며, 이러한 작업의 정확도가 낮아집니다. 이러한 요청에는 이 섹션의 단계와 함께 적응형 사고를 사용하세요. 테스트에서 요청을 두 개로 나누어 하나는 답변을, 다른 하나는 JSON을 요청하는 방식은 높은 답변 정확도와 JSON 준수율을 보였지만, 비용과 지연 시간이 매우 높았습니다.

low 및 medium effort에서 구조화된 출력을 사용하면 모델이 가끔 max_tokens에 도달할 때까지 계속 사고합니다. high effort 이상에서는 이런 일이 거의 발생하지 않습니다. stop_reason이 "max_tokens"인 응답은 텍스트에 유효한 JSON이 있더라도 실패로 처리하고 재시도하세요. Effort 보정에서 설명한 대로 사고와 JSON을 위해 max_tokens를 충분히 높게 설정하되, 한 번의 시도에 지출할 의향이 있는 수준보다 높게 설정하지는 마세요.

구조화된 출력을 사용할 수 없다면 대신 프롬프트에서 JSON을 요청하세요. 그러면 모델은 응답 텍스트에서 문제를 풀고 마지막에 JSON을 작성하는 경우가 많습니다. JSON에는 대개 올바른 답이 담겨 있지만, 응답 전체가 JSON일 것으로 예상하는 파서는 실패합니다. 다음 두 가지가 도움이 됩니다:

  • 응답의 마지막 JSON 값을 파싱하세요. text 블록만 읽고, stop_reason이 "max_tokens"인 응답은 실패로 처리하세요. 각 { 또는 [에서 시작하여 JSON 값 파싱을 시도하세요. 하나가 파싱되면 그 값의 끝에서부터 계속 진행하여, 그 안에 중첩된 값이 별도로 집계되지 않도록 하세요. 마지막으로 찾은 값을 유지하세요. 첫 번째 {부터 마지막 }까지 전부 가져오지 마세요. 모델은 가끔 최종 JSON 전에 초안을 작성하며, 그 범위에는 둘 다 포함됩니다. 답변이 한 줄에 하나의 레코드처럼 여러 JSON 값이 연속된 형태라면, 공백, 쉼표 또는 줄바꿈으로만 구분된 마지막 값들의 연속을 유지하세요. 결과에 예상한 필드가 있는지 확인하고, 없으면 한 번 재시도하세요. 테스트에서 이 방법은 정확도를 바꾸지 않으면서 거의 모든 응답을 사용 가능하게 만들었습니다.
  • 적응형 사고와 함께 xhigh effort도 고려하세요. 그러면 모델은 사고 안에서 문제를 풀고 거의 항상 JSON만 반환합니다. 풀이 과정이 응답 텍스트에서 사고로 옮겨가기 때문에 총 출력 토큰은 high와 거의 같게 유지됩니다.

사용자 대상 진행 상황 업데이트

도구 호출 사이에 Claude Sonnet 5.5는 방금 발견한 내용과 다음에 할 작업에 대해 사용자 대상 메모를 작성합니다. 한두 문장보다 긴 메모는 진행 상황 업데이트 thinking 블록으로 반환됩니다. 더 짧은 언급은 text로 유지됩니다. 기본 thinking.display에서는 진행 상황 업데이트 블록의 텍스트가 비어 있으므로, text 블록만 렌더링하는 클라이언트는 긴 에이전트 턴 동안 조용해 보일 수 있습니다. 이는 채팅 인터페이스나 사용자가 모델의 작업을 실시간으로 따라가는 기타 제품에서 가장 중요합니다.

이러한 메모를 표시하려면 display: "updates"(베타, thinking-display-updates-2026-08-18 헤더)를 설정하세요. between_tools를 사용하면 메모가 요약 텍스트와 함께 반환되므로 display 필드가 필요하지 않습니다. between_tools는 다른 필드를 받지 않습니다. 함께 보낸 display, budget_tokens 또는 block_binding은 400 오류를 반환합니다. 마이그레이션 가이드에서 메모를 렌더링하는 방법을 보여줍니다. 때로는 모델이 긴 턴 도중에 코드 스니펫이나 답변이 필요한 질문처럼 정확한 텍스트를 사용자에게 보여줘야 할 때가 있습니다. 이런 경우를 위해 사용자에게 메시지를 보내는 간단한 도구를 제공하세요. 모델에게 그러한 콘텐츠에만 이 도구를 사용하라고 지시하세요. tools 목록이 나중에 변경되지 않도록 세션의 첫 번째 요청에서 도구를 선언하세요.

다음으로, "모든 발견 사항을 최종 응답까지 보류하라"와 같은 이전 지시를 제거하세요. 그런 다음 예측 가능한 시점에 업데이트를 원한다면, 예를 들어 첫 번째 도구 호출 전에 모델이 무엇을 하려는지에 대한 한 줄과 마지막의 짧은 요약을 원한다면, 시스템 프롬프트에서 그렇게 말하세요. 모델은 이러한 지시를 따릅니다. 정해진 시점의 업데이트는 사람이 개입하는(human-in-the-loop) 작업에서 가장 도움이 됩니다.

긴 도구 호출 턴이 여전히 원하는 것보다 오래 조용하다면, 하네스가 업데이트를 유도할 수 있습니다. 사용자에게 텍스트나 진행 상황 업데이트를 보내지 않는 연속된 도구 호출 단계를 하네스가 세도록 하세요. 예를 들어 다섯 번처럼 여러 번 연속되면, 최신 도구 결과 뒤에 한 턴짜리 알림을 추가하세요. 다음과 같은 텍스트로 턴 범위 시스템 메시지(베타)로 보내세요:

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

턴이 계속 조용하다면 두 번째나 세 번째 이후에는 알림 보내기를 중단하세요. 턴 중간 사용자 메시지에서 설명하듯이, 도구 결과 뒤에 하네스 텍스트가 자주 나타나면 모델이 "prompt injection"(프롬프트 인젝션)을 의심할 수 있습니다. 이후 요청에서도 각 알림을 messages에 남겨 두세요. 알림은 삽입했다가 나중에 삭제하는 것이 아니라 추가되는 것이므로, 프롬프트 캐시와 보존된 사고가 그대로 유지됩니다. high effort에서 사용자에게 메시지를 보내는 도구를 사용할 수 있는 경우, 이 알림은 작업 품질에 측정 가능한 변화 없이 모델이 사용자에게 더 자주 업데이트하도록 하고 가장 긴 침묵 구간을 줄입니다.

채팅 및 지식 작업에서의 도구 사용

채팅 및 지식 작업에서 Claude Sonnet 5.5는 웹 검색으로 변경된 세부 사항을 파악할 수 있는데도 학습된 지식으로 답변하는 경우가 있습니다. 예를 들어 무엇이 허용되는지, 필요한지, 또는 요금이 부과되는지 등이 있습니다.

먼저 프롬프트에서 "꼭 필요한 경우에만 도구를 사용하라"나 "도구 호출을 최소화하라"처럼 도구 사용을 억제하는 표현이 있는지 확인하고 제거하세요. 그런 다음 제품이 모델에게 검색 도구를 제공한다면 시스템 프롬프트에 다음을 추가하세요:

Use the search tool to check specifics that may have changed since your training, such as what is allowed, required or charged, even when you feel confident. For researched work such as a report or a comparison, gather current sources rather than writing from your training knowledge.

이는 답변이 최신 세부 사항에 의존하는 리서치 및 지원 제품에서 가장 중요합니다.

턴 중간 사용자 메시지

Claude Sonnet 5.5는 간접 프롬프트 인젝션, 즉 작업 중에 읽는 도구 결과 및 기타 콘텐츠를 통해 들어오는 악의적인 지시에 저항하도록 학습되었습니다. 때때로 모델은 실제 사용자 메시지를 잠재적인 인젝션으로 취급합니다. 사용자가 작업 도중 입력한 메시지가 도구 결과 바로 뒤에 배치된 대화 중간 시스템 메시지로, 또는 tool_result 블록 안에 담겨 모델에 도달한다고 가정해 보세요. 그러면 모델은 도구 결과에 사용자의 메시지를 가장한 텍스트가 포함되어 있었다고 사용자에게 알리고, 메시지를 무시하거나 사용자에게 확인을 요청할 수 있습니다.

하네스가 모든 도구 결과 뒤에 추가하는 토큰 카운트다운이 이를 유발할 수 있습니다. 모델이 다단계 턴을 진행하는 도중에 사용자가 메시지를 보낼 수 있게 하거나, 하네스가 매 단계마다 도구 결과 뒤에 지시나 컨텍스트를 추가하는 경우도 마찬가지입니다. 각 경우 모두 도구 결과 바로 뒤에 텍스트가 도착합니다. 카운트다운이나 단계별 지시를 사용하면 이런 일이 모든 도구 호출에서 발생할 수 있습니다. 사용자 대상 진행 상황 업데이트에 나온 것과 같은 가끔씩의 한 턴짜리 알림은 훨씬 덜 자주 도착합니다. 자체 알림에 대해 이러한 반응이 나타난다면 알림을 덜 자주 보내세요. 오인을 피하려면:

  • 사용자 텍스트를 tool_result 블록 안에 절대 넣지 마세요. 모델은 이 배치를 가장 자주 오인합니다.
  • 턴 중간의 사용자 입력은 사용자 턴으로 전달하세요. tool_result 블록을 담은 사용자 메시지에서 마지막 tool_result 뒤에 사용자의 말을 텍스트 블록으로 추가하세요.
  • 알림과 같은 하네스 공지는 사용자의 말 뒤에 별도의 대화 중간 시스템 메시지로 유지하세요. 공지와 사용자의 말을 같은 블록에 절대 넣지 마세요.
  • 사용자가 턴 중간에 입력할 수 있는 대화형 세션에서는 도구 결과 뒤에 자체 토큰 또는 예산 카운트다운을 추가하지 마세요. 작업 예산(베타)도 비슷한 카운트다운을 추가하지만, 이러한 오인을 유발하는 것으로 관찰되지는 않았습니다. 작업 예산이 설정된 상태에서 오인이 나타난다면 작업 예산 없이 세션을 시도해 보세요.

코딩 작업에서의 검증

에이전트 코딩 작업에서 Claude Sonnet 5.5는 일반적으로 변경이 완료되었다고 보고하기 전에 작업을 확인합니다. 하지만 low effort에서는 변경 사항을 실제로 실행해 보는 확인 없이 완료되었다고 보고하는 경우가 있습니다. 예를 들어 프로젝트의 의존성이 설치되어 있지 않다는 이유로 프로젝트의 테스트를 건너뛸 수 있습니다.

트랜스크립트에 테스트나 빌드 출력 없이 변경이 완료되었다고 보고되는 것을 발견하면, 시스템 프롬프트에 다음 단락 또는 이와 유사한 단락을 추가하세요. low effort에서 이 단락은 작업 품질에 측정 가능한 변화 없이, 작업당 비용을 약간만 높이면서 확인을 건너뛰거나 피상적으로 확인하는 경우를 드물게 만듭니다:

When you change code that can be run, built, or type-checked, run a real check that exercises the change before reporting it done: the project's tests, type-checker, or build, or the changed command itself. A syntax-only check, or a check command that failed to start, does not count; if all that is missing is the project's declared dependencies, install them with its own package manager and lockfile (e.g. npm install, pip install -r requirements.txt), never via sudo or the system package manager, unless told not to. Only if no real check can run here, say which one you did not run and why instead of reporting the change as done.

관대한 도구 호출 처리

Claude Sonnet 5.5는 가끔 Bash 대신 bash처럼 대소문자만 다른 이름으로 선언된 도구를 호출합니다. 또한 알려진 매개변수를 약간 다른 이름으로 전달할 수도 있습니다. 이러한 호출을 치명적인 오류로 처리하는 대신, 하네스가 다음 두 가지 방법 중 하나로 처리하도록 하세요:

  • 대소문자가 틀리더라도 일치 여부가 명확하면 호출을 수락하세요.
  • 정확히 예상되는 이름을 명시한 is_error: true가 포함된 tool_result를 반환하세요. 모델은 대개 다음 턴에서 호출을 수정합니다. is_error로 오류 처리하기를 참조하세요.

복잡한 시각적 입력을 위한 도구

복잡한 차트와 기술 도면의 경우, Claude Sonnet 5.5에게 이미지를 자르거나, 확대하거나, 이미지에 대해 코드를 실행할 수 있는 방법을 제공하세요. 이러한 도구가 있으면 모델은 이러한 입력을 훨씬 더 정확하게 읽습니다. 차트의 경우 도구는 모든 effort 수준에서 도움이 됩니다. 기술 도면의 경우 high effort 이상에서만 도움이 되며, xhigh와 max에서 가장 도움이 됩니다. 차트의 경우 도구를 추가하는 것이 effort를 높이는 것보다 더 도움이 됩니다. 테스트에서 high effort에서 도구를 사용한 모델은 max effort에서 도구 없이 사용한 경우보다 훨씬 적은 비용으로 차트를 더 정확하게 읽었습니다. 자르기 도구 레시피에 작동하는 도구 정의가 있습니다.

안전장치 거부

Claude Sonnet 5.5는 요청을 거절할 수 있는 안전 분류기를 실행합니다. 거절은 stop_reason: "refusal"이 포함된 일반 응답으로 도착하며, stop_details.category가 거부 카테고리를 나타냅니다:

  • cyber: 요청이 악성코드나 익스플로잇 개발과 같은 사이버 피해를 가능하게 할 수 있습니다. 소스 코드에서 취약점을 찾는 것은 허용됩니다. 고위험 이중 용도 사이버 보안 작업은 허용되지 않습니다.
  • bio: 요청이 위험한 실험실 방법과 같은 생물학적 피해를 가능하게 할 수 있습니다. 일상적인 건강 및 교육 관련 질문은 영향을 받지 않습니다.
  • frontier_llm: 요청이 경쟁 AI 모델의 개발을 도울 수 있습니다.
  • reasoning_extraction: 요청이 모델에게 내부 추론을 응답 텍스트에 재현하도록 요구합니다.
  • general_harms: 요청이 다른 사용 정책 영역에 해당합니다. 무해한 작업도 이 카테고리를 유발할 수 있습니다.

bio 분류기가 조직의 생명과학 작업을 차단한다면 Life Sciences Verification Program에 신청할 수 있습니다.

서버 측 폴백(베타)을 켜면 cyber 및 frontier_llm 거절을 Claude Sonnet 5에서 재시도합니다. bio, reasoning_extraction 또는 general_harms 거절은 재시도하지 않습니다. 거부, 폴백 및 청구를 참조하세요.

프롬프트가 모델에게 응답에 추론을 포함하도록 요청한다면, 그러한 지시는 reasoning_extraction 거절을 유발하므로 제거하세요. 적응형 사고를 사용할 때는 대신 요약된 사고 블록(display: "summarized")에서 추론을 읽으세요.

Was this page helpful?