기능

확장된 사고로 구축하기

Claude의 확장된 사고 기능을 사용하여 복잡한 작업에 대한 향상된 추론 능력을 활용하는 방법을 알아봅니다.

확장된 사고는 Claude에게 복잡한 작업을 위한 향상된 추론 능력을 제공하며, 최종 답변을 제공하기 전에 단계별 사고 과정에 대한 다양한 수준의 투명성을 제공합니다.

지원되는 모델

확장된 사고는 다음 모델에서 지원됩니다:

Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Claude Sonnet 4 (claude-sonnet-4-20250514)
Claude Sonnet 3.7 (claude-3-7-sonnet-20250219) (deprecated)
Claude Haiku 4.5 (claude-haiku-4-5-20251001)
Claude Opus 4.5 (claude-opus-4-5-20251101)
Claude Opus 4.1 (claude-opus-4-1-20250805)
Claude Opus 4 (claude-opus-4-20250514)

API 동작은 Claude Sonnet 3.7과 Claude 4 모델 간에 다르지만, API 형태는 정확히 동일합니다.

자세한 내용은 모델 버전 간 사고의 차이점을 참조하세요.

확장된 사고의 작동 방식

확장된 사고가 켜지면 Claude는 내부 추론을 출력하는 thinking 콘텐츠 블록을 생성합니다. Claude는 최종 응답을 작성하기 전에 이 추론에서 얻은 통찰력을 통합합니다.

API 응답에는 thinking 콘텐츠 블록이 포함되고, 그 뒤에 text 콘텐츠 블록이 포함됩니다.

기본 응답 형식의 예는 다음과 같습니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

확장된 사고의 응답 형식에 대한 자세한 내용은 Messages API 참조를 참조하세요.

확장된 사고를 사용하는 방법

다음은 Messages API에서 확장된 사고를 사용하는 예입니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "Are there an infinite number of prime numbers such that n mod 4 == 3?"
        }
    ]
}'

확장된 사고를 켜려면 thinking 객체를 추가하고, type 매개변수를 enabled로 설정하고, budget_tokens를 확장된 사고를 위한 지정된 토큰 예산으로 설정합니다.

budget_tokens 매개변수는 Claude가 내부 추론 프로세스에 사용할 수 있는 최대 토큰 수를 결정합니다. Claude 4 모델에서 이 제한은 전체 사고 토큰에 적용되며, 요약된 출력에는 적용되지 않습니다. 더 큰 예산은 복잡한 문제에 대해 더 철저한 분석을 가능하게 하여 응답 품질을 개선할 수 있지만, Claude는 할당된 전체 예산을 사용하지 않을 수 있으며, 특히 32k 이상의 범위에서는 그렇습니다.

budget_tokens는 max_tokens보다 작은 값으로 설정해야 합니다. 그러나 도구를 사용한 인터리빙 사고를 사용할 때는 토큰 제한이 전체 컨텍스트 윈도우(200k 토큰)가 되므로 이 제한을 초과할 수 있습니다.

요약된 사고

확장된 사고가 활성화되면, Claude 4 모델의 Messages API는 Claude의 전체 사고 프로세스의 요약을 반환합니다. 요약된 사고는 확장된 사고의 전체 지능 이점을 제공하면서 오용을 방지합니다.

요약된 사고에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

요약 토큰이 아닌 원래 요청으로 생성된 전체 사고 토큰에 대해 청구됩니다.
청구된 출력 토큰 수는 응답에서 보이는 토큰 수와 일치하지 않습니다.
사고 출력의 처음 몇 줄은 더 자세하며, 프롬프트 엔지니어링 목적에 특히 유용한 상세한 추론을 제공합니다.
Anthropic이 확장된 사고 기능을 개선하려고 노력함에 따라 요약 동작은 변경될 수 있습니다.
요약은 Claude의 사고 프로세스의 핵심 아이디어를 최소한의 추가 지연으로 보존하여 스트리밍 가능한 사용자 경험과 Claude Sonnet 3.7에서 Claude 4 모델로의 쉬운 마이그레이션을 가능하게 합니다.
요약은 요청에서 대상으로 지정한 모델과 다른 모델에 의해 처리됩니다. 사고 모델은 요약된 출력을 보지 않습니다.

Claude Sonnet 3.7은 계속해서 전체 사고 출력을 반환합니다.

Claude 4 모델에 대한 전체 사고 출력에 액세스해야 하는 드문 경우, 영업팀에 문의하세요.

스트리밍 사고

서버 전송 이벤트(SSE)를 사용하여 확장된 사고 응답을 스트리밍할 수 있습니다.

확장된 사고에 대해 스트리밍이 활성화되면 thinking_delta 이벤트를 통해 사고 콘텐츠를 받습니다.

Messages API를 통한 스트리밍에 대한 자세한 설명서는 메시지 스트리밍을 참조하세요.

사고를 사용한 스트리밍을 처리하는 방법은 다음과 같습니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "What is 27 * 453?"
        }
    ]
}'

콘솔에서 시도해보기

스트리밍 출력 예:

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-sonnet-4-5", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "Let me solve this step by step:\n\n1. First break down 27 * 453"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n2. 453 = 400 + 50 + 3"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b3hGgxBdjrkzLoky3dl1pkiMOYds..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "27 * 453 = 12,231"}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

사고가 활성화된 상태에서 스트리밍을 사용할 때, 텍스트가 때때로 더 큰 청크로 도착한 후 더 작은 토큰 단위로 전달되는 것을 볼 수 있습니다. 이는 예상된 동작이며, 특히 사고 콘텐츠의 경우 그렇습니다.

스트리밍 시스템은 최적의 성능을 위해 배치로 콘텐츠를 처리해야 하므로, 이러한 "청크 형태의" 전달 패턴과 스트리밍 이벤트 간의 가능한 지연이 발생할 수 있습니다. 우리는 지속적으로 이 경험을 개선하기 위해 노력하고 있으며, 향후 업데이트는 사고 콘텐츠가 더 부드럽게 스트리밍되도록 하는 데 중점을 두고 있습니다.

Extended thinking은 Claude에게 복잡한 작업을 위한 향상된 추론 능력을 제공하며, 최종 답변을 제공하기 전에 단계별 사고 과정에 대한 다양한 수준의 투명성을 제공합니다.

지원되는 모델

Extended thinking은 다음 모델에서 지원됩니다:

Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Claude Sonnet 4 (claude-sonnet-4-20250514)
Claude Sonnet 3.7 (claude-3-7-sonnet-20250219) (deprecated)
Claude Haiku 4.5 (claude-haiku-4-5-20251001)
Claude Opus 4.5 (claude-opus-4-5-20251101)
Claude Opus 4.1 (claude-opus-4-1-20250805)
Claude Opus 4 (claude-opus-4-20250514)

API 동작은 Claude Sonnet 3.7과 Claude 4 모델 간에 다르지만, API 형태는 정확히 동일합니다.

자세한 내용은 모델 버전 간 thinking의 차이를 참조하세요.

Extended thinking 작동 방식

Extended thinking이 켜져 있으면 Claude는 내부 추론을 출력하는 thinking 콘텐츠 블록을 생성합니다. Claude는 이 추론의 통찰력을 최종 응답을 작성하기 전에 통합합니다.

API 응답에는 thinking 콘텐츠 블록이 포함되고, 그 뒤에 text 콘텐츠 블록이 포함됩니다.

기본 응답 형식의 예는 다음과 같습니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

Extended thinking의 응답 형식에 대한 자세한 내용은 Messages API 참조를 참조하세요.

Extended thinking 사용 방법

다음은 Messages API에서 extended thinking을 사용하는 예입니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "Are there an infinite number of prime numbers such that n mod 4 == 3?"
        }
    ]
}'

Extended thinking을 켜려면 type 매개변수를 enabled로 설정하고 budget_tokens를 extended thinking을 위한 지정된 토큰 예산으로 설정하여 thinking 객체를 추가합니다.

budget_tokens 매개변수는 Claude가 내부 추론 프로세스에 사용할 수 있는 최대 토큰 수를 결정합니다. Claude 4 모델에서 이 제한은 전체 thinking 토큰에 적용되며, 요약된 출력에는 적용되지 않습니다. 더 큰 예산은 복잡한 문제에 대해 더 철저한 분석을 가능하게 하여 응답 품질을 개선할 수 있지만, Claude는 특히 32k 이상의 범위에서 할당된 전체 예산을 사용하지 않을 수 있습니다.

budget_tokens는 max_tokens보다 작은 값으로 설정해야 합니다. 그러나 도구를 사용한 interleaved thinking을 사용할 때는 토큰 제한이 전체 컨텍스트 윈도우(200k 토큰)가 되므로 이 제한을 초과할 수 있습니다.

요약된 thinking

Extended thinking이 활성화되면 Claude 4 모델의 Messages API는 Claude의 전체 thinking 프로세스의 요약을 반환합니다. 요약된 thinking은 extended thinking의 모든 지능 이점을 제공하면서 오용을 방지합니다.

요약된 thinking에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

요약 토큰이 아닌 원래 요청에서 생성된 전체 thinking 토큰에 대해 요금이 청구됩니다.
청구된 출력 토큰 수는 응답에서 보이는 토큰 수와 일치하지 않습니다.
Thinking 출력의 처음 몇 줄은 더 자세하며, 프롬프트 엔지니어링 목적에 특히 유용한 상세한 추론을 제공합니다.
Anthropic이 extended thinking 기능을 개선하려고 노력함에 따라 요약 동작은 변경될 수 있습니다.
요약은 Claude의 thinking 프로세스의 핵심 아이디어를 최소한의 추가 지연으로 보존하여 스트리밍 가능한 사용자 경험과 Claude Sonnet 3.7에서 Claude 4 모델로의 쉬운 마이그레이션을 가능하게 합니다.
요약은 요청에서 대상으로 지정한 모델과 다른 모델에 의해 처리됩니다. Thinking 모델은 요약된 출력을 보지 않습니다.

Claude Sonnet 3.7은 계속해서 전체 thinking 출력을 반환합니다.

Claude 4 모델에 대한 전체 thinking 출력에 액세스해야 하는 드문 경우, 영업팀에 문의하세요.

Thinking 스트리밍

서버 전송 이벤트(SSE)를 사용하여 extended thinking 응답을 스트리밍할 수 있습니다.

Extended thinking에 대해 스트리밍이 활성화되면 thinking_delta 이벤트를 통해 thinking 콘텐츠를 받습니다.

Messages API를 통한 스트리밍에 대한 자세한 설명서는 스트리밍 메시지를 참조하세요.

Thinking을 사용한 스트리밍을 처리하는 방법은 다음과 같습니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "What is 27 * 453?"
        }
    ]
}'

콘솔에서 시도해보기

예제 스트리밍 출력:

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-sonnet-4-5", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "Let me solve this step by step:\n\n1. First break down 27 * 453"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n2. 453 = 400 + 50 + 3"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b3hGgxBdjrkzLoky3dl1pkiMOYds..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "27 * 453 = 12,231"}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

Thinking이 활성화된 상태에서 스트리밍을 사용할 때 텍스트가 때때로 더 큰 청크로 도착한 후 더 작은 토큰 단위로 전달되는 것을 볼 수 있습니다. 이는 예상된 동작이며, 특히 thinking 콘텐츠의 경우 그렇습니다.

스트리밍 시스템은 최적의 성능을 위해 배치로 콘텐츠를 처리해야 하므로 이러한 "청크" 전달 패턴이 발생할 수 있으며, 스트리밍 이벤트 간에 지연이 발생할 수 있습니다. 우리는 지속적으로 이 경험을 개선하기 위해 노력하고 있으며, 향후 업데이트는 thinking 콘텐츠가 더 부드럽게 스트리밍되도록 하는 데 중점을 두고 있습니다.

도구 사용을 포함한 Extended thinking

Extended thinking은 도구 사용과 함께 사용할 수 있으며, Claude가 도구 선택 및 결과 처리를 통해 추론할 수 있습니다.

도구 사용과 함께 extended thinking을 사용할 때 다음 제한 사항을 주의하세요:

도구 선택 제한: Thinking을 포함한 도구 사용은 tool_choice: {"type": "auto"} (기본값) 또는 tool_choice: {"type": "none"}만 지원합니다. tool_choice: {"type": "any"} 또는 tool_choice: {"type": "tool", "name": "..."}를 사용하면 이러한 옵션이 도구 사용을 강제하므로 extended thinking과 호환되지 않아 오류가 발생합니다.
Thinking 블록 보존: 도구 사용 중에 마지막 어시스턴트 메시지에 대해 thinking 블록을 API로 다시 전달해야 합니다. 추론 연속성을 유지하기 위해 완전하고 수정되지 않은 블록을 API로 다시 전달하세요.

대화에서 thinking 모드 전환

어시스턴트 턴 중간에 thinking을 전환할 수 없으며, 도구 사용 루프 중에도 마찬가지입니다. 전체 어시스턴트 턴은 단일 thinking 모드로 작동해야 합니다:

Thinking이 활성화된 경우, 최종 어시스턴트 턴은 thinking 블록으로 시작해야 합니다.
Thinking이 비활성화된 경우, 최종 어시스턴트 턴에는 thinking 블록이 포함되어서는 안 됩니다.

모델의 관점에서 도구 사용 루프는 어시스턴트 턴의 일부입니다. 어시스턴트 턴은 Claude가 여러 도구 호출 및 결과를 포함할 수 있는 전체 응답을 완료할 때까지 완료되지 않습니다.

예를 들어, 이 시퀀스는 모두 단일 어시스턴트 턴의 일부입니다:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

여러 API 메시지가 있지만, 도구 사용 루프는 개념적으로 하나의 연속적인 어시스턴트 응답의 일부입니다.

일반적인 오류 시나리오

이 오류가 발생할 수 있습니다:

Expected `thinking` or `redacted_thinking`, but found `tool_use`.
When `thinking` is enabled, a final `assistant` message must start
with a thinking block (preceding the lastmost set of `tool_use` and
`tool_result` blocks).

이는 일반적으로 다음과 같은 경우에 발생합니다:

도구 사용 시퀀스 중에 thinking이 비활성화되었습니다.
Thinking을 다시 활성화하려고 합니다.
마지막 어시스턴트 메시지에 thinking 블록이 없는 도구 사용 블록이 포함되어 있습니다.

실용적인 지침

✗ 유효하지 않음: 도구 사용 직후 thinking 전환

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
// 여전히 같은 어시스턴트 턴에 있으므로 여기서 thinking을 활성화할 수 없습니다.

✓ 유효함: 먼저 어시스턴트 턴 완료

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"] 
User: "What about tomorrow?" (thinking disabled)
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

모범 사례: 턴 중간에 전환하려고 하기보다는 각 턴의 시작 부분에서 thinking 전략을 계획하세요.

Thinking 모드 전환은 메시지 기록에 대한 프롬프트 캐싱도 무효화합니다. 자세한 내용은 프롬프트 캐싱을 포함한 Extended thinking 섹션을 참조하세요.

대화에서 사고 모드 전환하기

어시스턴트 턴 중간에 사고를 전환할 수 없습니다. 도구 사용 루프 중에도 마찬가지입니다. 전체 어시스턴트 턴은 단일 사고 모드에서 작동해야 합니다:

사고가 활성화된 경우, 최종 어시스턴트 턴은 사고 블록으로 시작해야 합니다.
사고가 비활성화된 경우, 최종 어시스턴트 턴에는 사고 블록이 포함되어서는 안 됩니다.

모델의 관점에서 도구 사용 루프는 어시스턴트 턴의 일부입니다. 어시스턴트 턴은 Claude가 전체 응답을 완료할 때까지 완료되지 않으며, 여기에는 여러 도구 호출 및 결과가 포함될 수 있습니다.

예를 들어, 이 시퀀스는 모두 단일 어시스턴트 턴의 일부입니다:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

여러 API 메시지가 있지만, 도구 사용 루프는 개념적으로 하나의 연속적인 어시스턴트 응답의 일부입니다.

일반적인 오류 시나리오

다음과 같은 오류가 발생할 수 있습니다:

Expected `thinking` or `redacted_thinking`, but found `tool_use`.
When `thinking` is enabled, a final `assistant` message must start
with a thinking block (preceding the lastmost set of `tool_use` and
`tool_result` blocks).

이는 일반적으로 다음과 같은 경우에 발생합니다:

도구 사용 시퀀스 중에 사고가 비활성화되어 있었습니다.
사고를 다시 활성화하려고 합니다.
마지막 어시스턴트 메시지에 도구 사용 블록은 있지만 사고 블록이 없습니다.

실용적인 지침

✗ 유효하지 않음: 도구 사용 직후 사고 전환

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
// Cannot enable thinking here - still in the same assistant turn

✓ 유효함: 먼저 어시스턴트 턴 완료

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"] 
User: "What about tomorrow?" (thinking disabled)
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

모범 사례: 턴 중간에 전환하려고 하기보다는 각 턴의 시작 부분에서 사고 전략을 계획하세요.

사고 모드를 전환하면 메시지 기록에 대한 프롬프트 캐싱도 무효화됩니다. 자세한 내용은 프롬프트 캐싱을 사용한 확장 사고 섹션을 참조하세요.

사고 블록 보존하기

도구 사용 중에는 thinking 블록을 API에 다시 전달해야 하며, 완전하고 수정되지 않은 블록을 API에 포함해야 합니다. 이는 모델의 추론 흐름과 대화 무결성을 유지하는 데 중요합니다.

이전 assistant 역할 턴에서 thinking 블록을 생략할 수 있지만, 다중 턴 대화의 경우 항상 모든 사고 블록을 API에 다시 전달할 것을 권장합니다. API는 다음을 수행합니다:

제공된 사고 블록을 자동으로 필터링합니다.
모델의 추론을 보존하는 데 필요한 관련 사고 블록을 사용합니다.
Claude에게 표시되는 블록에 대한 입력 토큰만 청구합니다.

대화 중에 사고 모드를 전환할 때, 전체 어시스턴트 턴(도구 사용 루프 포함)이 단일 사고 모드에서 작동해야 한다는 점을 기억하세요. 자세한 내용은 대화에서 사고 모드 전환하기를 참조하세요.

Claude가 도구를 호출할 때, 응답 구성을 일시 중지하고 외부 정보를 기다립니다. 도구 결과가 반환되면 Claude는 기존 응답 구성을 계속합니다. 이는 도구 사용 중에 사고 블록을 보존해야 하는 몇 가지 이유가 있습니다:

추론 연속성: 사고 블록은 도구 요청으로 이어진 Claude의 단계별 추론을 캡처합니다. 도구 결과를 게시할 때 원본 사고를 포함하면 Claude가 중단된 지점에서 추론을 계속할 수 있습니다.
컨텍스트 유지: 도구 결과는 API 구조에서 사용자 메시지로 나타나지만, 연속적인 추론 흐름의 일부입니다. 사고 블록을 보존하면 여러 API 호출에 걸쳐 이 개념적 흐름을 유지합니다. 컨텍스트 관리에 대한 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

중요: thinking 블록을 제공할 때, 연속적인 thinking 블록의 전체 시퀀스는 원본 요청 중에 모델에서 생성한 출력과 일치해야 합니다. 이 블록의 시퀀스를 재배열하거나 수정할 수 없습니다.

인터리빙 사고

Claude 4 모델의 도구 사용을 포함한 확장 사고는 인터리빙 사고를 지원하며, 이를 통해 Claude는 도구 호출 사이에 생각하고 도구 결과를 받은 후 더 정교한 추론을 수행할 수 있습니다.

인터리빙 사고를 사용하면 Claude는 다음을 수행할 수 있습니다:

도구 호출의 결과에 대해 생각한 후 다음에 할 일을 결정
여러 도구 호출을 중간에 추론 단계와 함께 연결
중간 결과를 기반으로 더 미묘한 결정 내리기

인터리빙 사고를 활성화하려면 API 요청에 베타 헤더 interleaved-thinking-2025-05-14를 추가하세요.

인터리빙 사고에 대한 몇 가지 중요한 고려사항은 다음과 같습니다:

인터리빙 사고를 사용하면 budget_tokens이 max_tokens 매개변수를 초과할 수 있습니다. 이는 한 번의 어시스턴트 턴 내의 모든 사고 블록에 걸친 총 예산을 나타냅니다.
인터리빙 사고는 Messages API를 통해 사용되는 도구에만 지원됩니다.
인터리빙 사고는 Claude 4 모델에만 지원되며, 베타 헤더 interleaved-thinking-2025-05-14가 필요합니다.
Claude API에 대한 직접 호출을 통해 모든 모델에 대한 요청에서 interleaved-thinking-2025-05-14를 전달할 수 있으며, 효과가 없습니다.
3rd-party 플랫폼(예: Amazon Bedrock 및 Vertex AI)에서 Claude Opus 4.5, Claude Opus 4.1, Opus 4 또는 Sonnet 4 이외의 모델에 interleaved-thinking-2025-05-14를 전달하면 요청이 실패합니다.

프롬프트 캐싱을 포함한 확장 사고

프롬프트 캐싱과 사고는 몇 가지 중요한 고려사항이 있습니다:

확장 사고 작업은 종종 5분 이상 완료하는 데 걸립니다. 더 긴 사고 세션과 다단계 워크플로우에서 캐시 히트를 유지하기 위해 1시간 캐시 지속 시간을 사용하는 것을 고려하세요.

사고 블록 컨텍스트 제거

이전 턴의 사고 블록은 컨텍스트에서 제거되며, 이는 캐시 중단점에 영향을 미칠 수 있습니다
도구 사용으로 대화를 계속할 때 사고 블록은 캐시되고 캐시에서 읽을 때 입력 토큰으로 계산됩니다
이는 트레이드오프를 만듭니다: 사고 블록은 시각적으로 컨텍스트 윈도우 공간을 소비하지 않지만, 캐시되면 입력 토큰 사용량에 여전히 계산됩니다
사고가 비활성화되면 현재 도구 사용 턴에서 사고 콘텐츠를 전달하면 요청이 실패합니다. 다른 컨텍스트에서는 API에 전달된 사고 콘텐츠가 단순히 무시됩니다

캐시 무효화 패턴

사고 매개변수 변경(활성화/비활성화 또는 예산 할당)은 메시지 캐시 중단점을 무효화합니다
인터리빙 사고는 캐시 무효화를 증폭시킵니다. 사고 블록이 여러 도구 호출 사이에 발생할 수 있기 때문입니다
시스템 프롬프트와 도구는 사고 매개변수 변경이나 블록 제거에도 불구하고 캐시된 상태로 유지됩니다

사고 블록은 캐싱 및 컨텍스트 계산을 위해 제거되지만, 도구 사용으로 대화를 계속할 때, 특히 인터리빙 사고를 사용할 때는 보존되어야 합니다.

프롬프트 캐싱을 사용한 확장 사고

프롬프트 캐싱과 사고에는 여러 가지 중요한 고려사항이 있습니다:

확장 사고 작업은 종종 완료하는 데 5분 이상 걸립니다. 더 긴 사고 세션과 다단계 워크플로우에서 캐시 히트를 유지하기 위해 1시간 캐시 지속 시간을 사용하는 것을 고려하세요.

사고 블록 컨텍스트 제거

이전 턴의 사고 블록은 컨텍스트에서 제거되므로 캐시 중단점에 영향을 미칠 수 있습니다
도구 사용으로 대화를 계속할 때 사고 블록은 캐시되고 캐시에서 읽을 때 입력 토큰으로 계산됩니다
이는 트레이드오프를 만듭니다: 사고 블록이 시각적으로 컨텍스트 윈도우 공간을 소비하지 않지만, 캐시될 때 입력 토큰 사용량에 여전히 계산됩니다
사고가 비활성화되면 현재 도구 사용 턴에서 사고 콘텐츠를 전달하면 요청이 실패합니다. 다른 컨텍스트에서는 API에 전달된 사고 콘텐츠가 단순히 무시됩니다

캐시 무효화 패턴

사고 매개변수 변경(활성화/비활성화 또는 예산 할당)은 메시지 캐시 중단점을 무효화합니다
인터리브된 사고는 캐시 무효화를 증폭시킵니다. 사고 블록이 여러 도구 호출 사이에 발생할 수 있기 때문입니다
시스템 프롬프트와 도구는 사고 매개변수 변경이나 블록 제거에도 불구하고 캐시된 상태로 유지됩니다

사고 블록이 캐싱 및 컨텍스트 계산을 위해 제거되지만, 도구 사용으로 대화를 계속할 때, 특히 인터리브된 사고를 사용할 때는 보존되어야 합니다.

사고 블록 캐싱 동작 이해

도구 사용으로 확장 사고를 사용할 때 사고 블록은 토큰 계산에 영향을 미치는 특정 캐싱 동작을 나타냅니다:

작동 방식:

캐싱은 도구 결과를 포함하는 후속 요청을 할 때만 발생합니다
후속 요청이 이루어지면 이전 대화 기록(사고 블록 포함)을 캐시할 수 있습니다
이러한 캐시된 사고 블록은 캐시에서 읽을 때 사용 메트릭의 입력 토큰으로 계산됩니다
비도구 결과 사용자 블록이 포함되면 모든 이전 사고 블록이 무시되고 컨텍스트에서 제거됩니다

상세 예제 흐름:

요청 1:

User: "What's the weather in Paris?"

응답 1:

[thinking_block_1] + [tool_use block 1]

요청 2:

User: ["What's the weather in Paris?"], 
Assistant: [thinking_block_1] + [tool_use block 1], 
User: [tool_result_1, cache=True]

응답 2:

[thinking_block_2] + [text block 2]

요청 2는 요청 콘텐츠(응답이 아님)의 캐시를 작성합니다. 캐시에는 원본 사용자 메시지, 첫 번째 사고 블록, 도구 사용 블록 및 도구 결과가 포함됩니다.

요청 3:

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

Claude Opus 4.5 이상의 경우 모든 이전 사고 블록이 기본적으로 유지됩니다. 이전 모델의 경우 비도구 결과 사용자 블록이 포함되었으므로 모든 이전 사고 블록이 무시됩니다. 이 요청은 다음과 같이 처리됩니다:

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

핵심 포인트:

이 캐싱 동작은 명시적인 cache_control 마커 없이도 자동으로 발생합니다
이 동작은 일반 사고를 사용하든 인터리브된 사고를 사용하든 일관됩니다

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

이전 Claude 모델(Claude Sonnet 3.7 이전)에서는 프롬프트 토큰과 max_tokens의 합이 모델의 컨텍스트 윈도우를 초과하면 시스템이 자동으로 max_tokens를 조정하여 컨텍스트 제한 내에 맞췄습니다. 이는 큰 max_tokens 값을 설정할 수 있고 시스템이 필요에 따라 자동으로 줄인다는 의미였습니다.

Claude 3.7 및 4 모델에서는 max_tokens(사고가 활성화되면 사고 예산 포함)가 엄격한 제한으로 적용됩니다. 이제 프롬프트 토큰 + max_tokens이 컨텍스트 윈도우 크기를 초과하면 시스템이 검증 오류를 반환합니다.

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

도구 사용으로 확장 사고를 사용할 때 사고 블록은 명시적으로 보존되고 도구 결과와 함께 반환되어야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 도구 사용을 포함한 확장 사고의 토큰 관리를 보여줍니다:

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우 다이어그램

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

도구 사용으로 확장 사고를 사용할 때 사고 블록은 명시적으로 보존되고 도구 결과와 함께 반환되어야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 도구 사용을 포함한 확장 사고의 토큰 관리를 보여줍니다:

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우 다이어그램

확장 사고를 사용한 토큰 관리

확장 사고를 사용한 Claude 3.7 및 4 모델의 컨텍스트 윈도우 및 max_tokens 동작을 고려하면 다음을 수행해야 할 수 있습니다:

토큰 사용량을 더 적극적으로 모니터링하고 관리합니다
프롬프트 길이가 변함에 따라 max_tokens 값을 조정합니다
잠재적으로 토큰 계산 엔드포인트를 더 자주 사용합니다
이전 사고 블록이 컨텍스트 윈도우에 누적되지 않음을 인식합니다

이 변경은 특히 최대 토큰 제한이 크게 증가했으므로 더 예측 가능하고 투명한 동작을 제공하기 위해 이루어졌습니다.

최대 토큰 및 확장 사고를 포함한 컨텍스트 윈도우 크기

이전 Claude 모델(Claude Sonnet 3.7 이전)에서는 프롬프트 토큰과 max_tokens의 합이 모델의 컨텍스트 윈도우를 초과하면 시스템이 자동으로 max_tokens를 조정하여 컨텍스트 제한 내에 맞추었습니다. 이는 큰 max_tokens 값을 설정할 수 있었고 시스템이 필요에 따라 자동으로 줄였다는 의미입니다.

Claude 3.7 및 4 모델에서는 max_tokens(사고가 활성화되었을 때 사고 예산 포함)가 엄격한 제한으로 적용됩니다. 이제 프롬프트 토큰 + max_tokens이 컨텍스트 윈도우 크기를 초과하면 시스템이 검증 오류를 반환합니다.

더 자세한 내용은 컨텍스트 윈도우 가이드를 참고하세요.

확장 사고를 포함한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 사항이 있습니다:

이전 턴의 사고 블록은 제거되며 컨텍스트 윈도우에 포함되지 않습니다
현재 턴의 사고는 해당 턴의 max_tokens 제한에 포함됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 포함한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 개수를 얻기 위해 토큰 계산 API를 사용하는 것을 권장합니다.

확장 사고 및 도구 사용을 포함한 컨텍스트 윈도우

확장 사고와 도구 사용을 함께 사용할 때는 사고 블록을 명시적으로 보존하고 도구 결과와 함께 반환해야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같습니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 확장 사고 및 도구 사용을 포함한 토큰 관리를 보여줍니다:

확장 사고 및 도구 사용을 포함한 컨텍스트 윈도우 다이어그램

확장 사고를 포함한 토큰 관리

Claude 3.7 및 4 모델의 확장 사고를 포함한 컨텍스트 윈도우 및 max_tokens 동작을 고려하면 다음을 수행해야 할 수 있습니다:

토큰 사용량을 더 적극적으로 모니터링하고 관리합니다
프롬프트 길이가 변함에 따라 max_tokens 값을 조정합니다
토큰 계산 엔드포인트를 더 자주 사용할 수 있습니다
이전 사고 블록이 컨텍스트 윈도우에 누적되지 않음을 인식합니다

이 변경은 특히 최대 토큰 제한이 크게 증가했을 때 더 예측 가능하고 투명한 동작을 제공하기 위해 이루어졌습니다.

사고 암호화

전체 사고 내용은 암호화되어 signature 필드에 반환됩니다. 이 필드는 사고 블록이 API로 다시 전달될 때 Claude에 의해 생성되었는지 확인하는 데 사용됩니다.

도구와 함께 확장 사고를 사용할 때만 사고 블록을 다시 보내는 것이 엄격히 필요합니다. 그 외에는 이전 턴의 사고 블록을 생략하거나 다시 전달할 때 API가 제거하도록 할 수 있습니다.

사고 블록을 다시 보내는 경우 일관성을 위해 그리고 잠재적인 문제를 피하기 위해 받은 그대로 모든 것을 다시 보내는 것을 권장합니다.

사고 암호화에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

응답을 스트리밍할 때, 서명은 content_block_stop 이벤트 직전에 content_block_delta 이벤트 내의 signature_delta를 통해 추가됩니다.
signature 값은 Claude 4 모델에서 이전 모델보다 훨씬 깁니다.
signature 필드는 불투명한 필드이며 해석하거나 파싱해서는 안 됩니다. 검증 목적으로만 존재합니다.
signature 값은 플랫폼 간에 호환됩니다(Claude API, Amazon Bedrock, Vertex AI). 한 플랫폼에서 생성된 값은 다른 플랫폼과 호환됩니다.

사고 편집

때때로 Claude의 내부 추론이 안전 시스템에 의해 플래그됩니다. 이 경우 thinking 블록의 일부 또는 전부를 암호화하고 redacted_thinking 블록으로 반환합니다. redacted_thinking 블록은 API로 다시 전달될 때 복호화되어 Claude가 컨텍스트를 잃지 않고 응답을 계속할 수 있습니다.

확장 사고를 사용하는 고객 대면 애플리케이션을 구축할 때:

편집된 사고 블록에는 인간이 읽을 수 없는 암호화된 내용이 포함되어 있음을 인식합니다
"Claude의 일부 내부 추론이 안전상의 이유로 자동으로 암호화되었습니다. 이는 응답의 품질에 영향을 주지 않습니다."와 같은 간단한 설명을 제공하는 것을 고려합니다
사고 블록을 사용자에게 표시하는 경우 편집된 블록을 필터링하면서 일반 사고 블록을 보존할 수 있습니다
확장 사고 기능을 사용하면 일부 추론이 암호화될 수 있음을 투명하게 공개합니다
편집된 사고를 우아하게 관리하고 UI를 손상시키지 않도록 적절한 오류 처리를 구현합니다

다음은 일반 사고 블록과 편집된 사고 블록을 모두 보여주는 예입니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "redacted_thinking",
      "data": "EmwKAhgBEgy3va3pzix/LafPsn4aDFIT2Xlxh0L5L8rLVyIwxtE3rAFBa8cr3qpPkNRj2YfWXGmKDxH4mPnZ5sQ7vB9URj2pLmN3kF8/dW5hR7xJ0aP1oLs9yTcMnKVf2wRpEGjH9XZaBt4UvDcPrQ..."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

응답에서 편집된 사고 블록을 보는 것은 예상된 동작입니다. 모델은 여전히 이 편집된 추론을 사용하여 응답에 정보를 제공하면서 안전 가드레일을 유지할 수 있습니다.

애플리케이션에서 편집된 사고 처리를 테스트해야 하는 경우 프롬프트로 이 특수 테스트 문자열을 사용할 수 있습니다: ANTHROPIC_MAGIC_STRING_TRIGGER_REDACTED_THINKING_46C9A13E193C177646C7398A98432ECCCE4C1253D5E2D82641AC0E52CC2876CB

다중 턴 대화에서 thinking 및 redacted_thinking 블록을 API로 다시 전달할 때는 마지막 어시스턴트 턴에 대해 완전하고 수정되지 않은 블록을 API로 다시 전달해야 합니다. 이는 모델의 추론 흐름을 유지하기 위해 중요합니다. 모든 사고 블록을 항상 API로 다시 보내는 것을 제안합니다. 자세한 내용은 위의 사고 블록 보존 섹션을 참고하세요.

모델 버전 간 사고의 차이점

Messages API는 Claude Sonnet 3.7 및 Claude 4 모델 간에 사고를 다르게 처리하며, 주로 편집 및 요약 동작에서 차이가 있습니다.

압축된 비교를 위해 아래 표를 참고하세요:

기능	Claude Sonnet 3.7	Claude 4 모델(Opus 4.5 이전)	Claude Opus 4.5 이상
사고 출력	전체 사고 출력 반환	요약된 사고 반환	요약된 사고 반환
인터리빙된 사고	지원되지 않음	`interleaved-thinking-2025-05-14` 베타 헤더로 지원	`interleaved-thinking-2025-05-14` 베타 헤더로 지원
사고 블록 보존	턴 간에 보존되지 않음	턴 간에 보존되지 않음	기본적으로 보존됨(캐시 최적화, 토큰 절감 가능)

Claude Opus 4.5의 사고 블록 보존

Claude Opus 4.5는 새로운 기본 동작을 도입합니다: 이전 어시스턴트 턴의 사고 블록이 기본적으로 모델 컨텍스트에 보존됩니다. 이는 이전 턴의 사고 블록을 제거하는 이전 모델과 다릅니다.

사고 블록 보존의 이점:

캐시 최적화: 도구 사용을 사용할 때 보존된 사고 블록은 도구 결과와 함께 다시 전달되고 어시스턴트 턴 전체에서 증분적으로 캐시되어 다중 단계 워크플로우에서 토큰 절감을 가능하게 합니다
지능에 미치는 영향 없음: 사고 블록을 보존해도 모델 성능에 부정적인 영향을 미치지 않습니다

중요한 고려 사항:

컨텍스트 사용: 사고 블록이 컨텍스트에 유지되므로 긴 대화는 더 많은 컨텍스트 공간을 소비합니다
자동 동작: 이는 Claude Opus 4.5의 기본 동작입니다. 코드 변경이나 베타 헤더가 필요하지 않습니다
역호환성: 이 기능을 활용하려면 도구 사용과 마찬가지로 완전하고 수정되지 않은 사고 블록을 API로 다시 전달하는 것을 계속합니다

이전 모델(Claude Sonnet 4.5, Opus 4.1 등)의 경우 이전 턴의 사고 블록은 계속 컨텍스트에서 제거됩니다. 프롬프트 캐싱을 포함한 확장 사고 섹션에 설명된 기존 동작이 해당 모델에 적용됩니다.

사고 편집

때때로 Claude의 내부 추론이 우리의 안전 시스템에 의해 플래그될 수 있습니다. 이런 경우가 발생하면, 우리는 thinking 블록의 일부 또는 전부를 암호화하고 이를 redacted_thinking 블록으로 반환합니다. redacted_thinking 블록은 API로 다시 전달될 때 복호화되어 Claude가 컨텍스트를 잃지 않고 응답을 계속할 수 있게 합니다.

확장 사고를 사용하는 고객 대면 애플리케이션을 구축할 때:

편집된 사고 블록에는 인간이 읽을 수 없는 암호화된 콘텐츠가 포함되어 있음을 인식하세요
"Claude의 일부 내부 추론이 안전상의 이유로 자동으로 암호화되었습니다. 이는 응답의 품질에 영향을 주지 않습니다."와 같은 간단한 설명을 제공하는 것을 고려하세요
사고 블록을 사용자에게 표시하는 경우, 일반 사고 블록을 유지하면서 편집된 블록을 필터링할 수 있습니다
확장 사고 기능을 사용하면 때때로 일부 추론이 암호화될 수 있다는 점을 투명하게 전달하세요
편집된 사고를 우아하게 관리하여 UI가 깨지지 않도록 적절한 오류 처리를 구현하세요

다음은 일반 사고 블록과 편집된 사고 블록을 모두 보여주는 예시입니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "redacted_thinking",
      "data": "EmwKAhgBEgy3va3pzix/LafPsn4aDFIT2Xlxh0L5L8rLVyIwxtE3rAFBa8cr3qpPkNRj2YfWXGmKDxH4mPnZ5sQ7vB9URj2pLmN3kF8/dW5hR7xJ0aP1oLs9yTcMnKVf2wRpEGjH9XZaBt4UvDcPrQ..."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

출력에서 편집된 사고 블록을 보는 것은 예상된 동작입니다. 모델은 여전히 이 편집된 추론을 사용하여 안전 가드레일을 유지하면서 응답에 정보를 제공할 수 있습니다.

애플리케이션에서 편집된 사고 처리를 테스트해야 하는 경우, 프롬프트로 다음 특수 테스트 문자열을 사용할 수 있습니다: ANTHROPIC_MAGIC_STRING_TRIGGER_REDACTED_THINKING_46C9A13E193C177646C7398A98432ECCCE4C1253D5E2D82641AC0E52CC2876CB

다중 턴 대화에서 thinking 및 redacted_thinking 블록을 API로 다시 전달할 때, 마지막 어시스턴트 턴에 대해 완전하고 수정되지 않은 블록을 API로 다시 전달해야 합니다. 이는 모델의 추론 흐름을 유지하기 위해 중요합니다. 우리는 항상 모든 사고 블록을 API로 다시 전달할 것을 제안합니다. 자세한 내용은 위의 사고 블록 보존 섹션을 참조하세요.

모델 버전 간 사고의 차이점

Messages API는 Claude Sonnet 3.7과 Claude 4 모델 간에 사고를 다르게 처리하며, 주로 편집 및 요약 동작에서 차이가 있습니다.

아래 표에서 압축된 비교를 참조하세요:

기능	Claude Sonnet 3.7	Claude 4 모델 (Opus 4.5 이전)	Claude Opus 4.5 이상
사고 출력	전체 사고 출력 반환	요약된 사고 반환	요약된 사고 반환
인터리브된 사고	지원되지 않음	`interleaved-thinking-2025-05-14` 베타 헤더로 지원	`interleaved-thinking-2025-05-14` 베타 헤더로 지원
사고 블록 보존	턴 간에 보존되지 않음	턴 간에 보존되지 않음	기본적으로 보존됨 (캐시 최적화, 토큰 절감 가능)

Claude Opus 4.5의 사고 블록 보존

사고 블록 보존의 이점:

캐시 최적화: 도구 사용 시, 보존된 사고 블록은 도구 결과와 함께 다시 전달되고 어시스턴트 턴 전체에서 증분적으로 캐시되어 다중 단계 워크플로우에서 토큰 절감을 가능하게 합니다
지능 영향 없음: 사고 블록을 보존해도 모델 성능에 부정적인 영향을 주지 않습니다

중요한 고려사항:

컨텍스트 사용: 사고 블록이 컨텍스트에 유지되므로 긴 대화는 더 많은 컨텍스트 공간을 소비합니다
자동 동작: 이는 Claude Opus 4.5의 기본 동작입니다—코드 변경이나 베타 헤더가 필요하지 않습니다
하위 호환성: 이 기능을 활용하려면, 도구 사용과 마찬가지로 완전하고 수정되지 않은 사고 블록을 API로 다시 전달하세요

이전 모델 (Claude Sonnet 4.5, Opus 4.1 등)의 경우, 이전 턴의 사고 블록은 계속 컨텍스트에서 제거됩니다. 확장 사고와 프롬프트 캐싱 섹션에 설명된 기존 동작이 해당 모델에 적용됩니다.

가격 책정

기본 요금, 캐시 쓰기, 캐시 히트 및 출력 토큰을 포함한 완전한 가격 책정 정보는 가격 책정 페이지를 참조하세요.

사고 프로세스는 다음에 대해 요금이 부과됩니다:

사고 중에 사용된 토큰 (출력 토큰)
후속 요청에 포함된 마지막 어시스턴트 턴의 사고 블록 (입력 토큰)
표준 텍스트 출력 토큰

확장 사고가 활성화되면, 이 기능을 지원하기 위해 특수 시스템 프롬프트가 자동으로 포함됩니다.

요약된 사고를 사용할 때:

입력 토큰: 원본 요청의 토큰 (이전 턴의 사고 토큰 제외)
출력 토큰 (청구됨): Claude가 내부적으로 생성한 원본 사고 토큰
출력 토큰 (표시됨): 응답에서 보이는 요약된 사고 토큰
요금 없음: 요약을 생성하는 데 사용된 토큰

청구된 출력 토큰 수는 응답의 표시된 토큰 수와 일치하지 않습니다. 보이는 요약이 아닌 전체 사고 프로세스에 대해 청구됩니다.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

사용 지침

작업 선택: 수학, 코딩 및 분석과 같이 단계별 추론의 이점을 얻는 특히 복잡한 작업에 확장 사고를 사용하세요.
컨텍스트 처리: 이전 사고 블록을 직접 제거할 필요가 없습니다. Claude API는 자동으로 이전 턴의 사고 블록을 무시하며 컨텍스트 사용량 계산에 포함되지 않습니다.
프롬프트 엔지니어링: Claude의 사고 기능을 최대화하려면 확장 사고 프롬프팅 팁을 검토하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

사용 지침

작업 선택: 수학, 코딩 및 분석과 같이 단계별 추론의 이점을 얻는 특히 복잡한 작업에 확장 사고를 사용하세요.
컨텍스트 처리: 이전 사고 블록을 직접 제거할 필요가 없습니다. Claude API는 자동으로 이전 턴의 사고 블록을 무시하며 컨텍스트 사용량 계산에 포함되지 않습니다.
프롬프트 엔지니어링: Claude의 사고 기능을 최대화하려면 확장 사고 프롬프팅 팁을 검토하세요.

다음 단계

확장 사고 쿡북 시도해보기

우리의 쿡북에서 사고의 실용적인 예시를 탐색하세요.

확장 사고 프롬프팅 팁

확장 사고를 위한 프롬프트 엔지니어링 모범 사례를 배우세요.

기능

확장된 사고로 구축하기

Claude의 확장된 사고 기능을 사용하여 복잡한 작업에 대한 향상된 추론 능력을 활용하는 방법을 알아봅니다.

지원되는 모델

확장된 사고는 다음 모델에서 지원됩니다:

Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Claude Sonnet 4 (claude-sonnet-4-20250514)
Claude Sonnet 3.7 (claude-3-7-sonnet-20250219) (deprecated)
Claude Haiku 4.5 (claude-haiku-4-5-20251001)
Claude Opus 4.5 (claude-opus-4-5-20251101)
Claude Opus 4.1 (claude-opus-4-1-20250805)
Claude Opus 4 (claude-opus-4-20250514)

API 동작은 Claude Sonnet 3.7과 Claude 4 모델 간에 다르지만, API 형태는 정확히 동일합니다.

자세한 내용은 모델 버전 간 사고의 차이점을 참조하세요.

확장된 사고의 작동 방식

API 응답에는 thinking 콘텐츠 블록이 포함되고, 그 뒤에 text 콘텐츠 블록이 포함됩니다.

기본 응답 형식의 예는 다음과 같습니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

확장된 사고의 응답 형식에 대한 자세한 내용은 Messages API 참조를 참조하세요.

확장된 사고를 사용하는 방법

다음은 Messages API에서 확장된 사고를 사용하는 예입니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "Are there an infinite number of prime numbers such that n mod 4 == 3?"
        }
    ]
}'

요약된 사고

요약된 사고에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

요약 토큰이 아닌 원래 요청으로 생성된 전체 사고 토큰에 대해 청구됩니다.
청구된 출력 토큰 수는 응답에서 보이는 토큰 수와 일치하지 않습니다.
사고 출력의 처음 몇 줄은 더 자세하며, 프롬프트 엔지니어링 목적에 특히 유용한 상세한 추론을 제공합니다.
Anthropic이 확장된 사고 기능을 개선하려고 노력함에 따라 요약 동작은 변경될 수 있습니다.
요약은 Claude의 사고 프로세스의 핵심 아이디어를 최소한의 추가 지연으로 보존하여 스트리밍 가능한 사용자 경험과 Claude Sonnet 3.7에서 Claude 4 모델로의 쉬운 마이그레이션을 가능하게 합니다.
요약은 요청에서 대상으로 지정한 모델과 다른 모델에 의해 처리됩니다. 사고 모델은 요약된 출력을 보지 않습니다.

Claude Sonnet 3.7은 계속해서 전체 사고 출력을 반환합니다.

Claude 4 모델에 대한 전체 사고 출력에 액세스해야 하는 드문 경우, 영업팀에 문의하세요.

스트리밍 사고

서버 전송 이벤트(SSE)를 사용하여 확장된 사고 응답을 스트리밍할 수 있습니다.

확장된 사고에 대해 스트리밍이 활성화되면 thinking_delta 이벤트를 통해 사고 콘텐츠를 받습니다.

Messages API를 통한 스트리밍에 대한 자세한 설명서는 메시지 스트리밍을 참조하세요.

사고를 사용한 스트리밍을 처리하는 방법은 다음과 같습니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "What is 27 * 453?"
        }
    ]
}'

콘솔에서 시도해보기

스트리밍 출력 예:

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-sonnet-4-5", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "Let me solve this step by step:\n\n1. First break down 27 * 453"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n2. 453 = 400 + 50 + 3"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b3hGgxBdjrkzLoky3dl1pkiMOYds..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "27 * 453 = 12,231"}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

지원되는 모델

Extended thinking은 다음 모델에서 지원됩니다:

Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
Claude Sonnet 4 (claude-sonnet-4-20250514)
Claude Sonnet 3.7 (claude-3-7-sonnet-20250219) (deprecated)
Claude Haiku 4.5 (claude-haiku-4-5-20251001)
Claude Opus 4.5 (claude-opus-4-5-20251101)
Claude Opus 4.1 (claude-opus-4-1-20250805)
Claude Opus 4 (claude-opus-4-20250514)

API 동작은 Claude Sonnet 3.7과 Claude 4 모델 간에 다르지만, API 형태는 정확히 동일합니다.

자세한 내용은 모델 버전 간 thinking의 차이를 참조하세요.

Extended thinking 작동 방식

API 응답에는 thinking 콘텐츠 블록이 포함되고, 그 뒤에 text 콘텐츠 블록이 포함됩니다.

기본 응답 형식의 예는 다음과 같습니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

Extended thinking의 응답 형식에 대한 자세한 내용은 Messages API 참조를 참조하세요.

Extended thinking 사용 방법

다음은 Messages API에서 extended thinking을 사용하는 예입니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "Are there an infinite number of prime numbers such that n mod 4 == 3?"
        }
    ]
}'

요약된 thinking

요약된 thinking에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

요약 토큰이 아닌 원래 요청에서 생성된 전체 thinking 토큰에 대해 요금이 청구됩니다.
청구된 출력 토큰 수는 응답에서 보이는 토큰 수와 일치하지 않습니다.
Thinking 출력의 처음 몇 줄은 더 자세하며, 프롬프트 엔지니어링 목적에 특히 유용한 상세한 추론을 제공합니다.
Anthropic이 extended thinking 기능을 개선하려고 노력함에 따라 요약 동작은 변경될 수 있습니다.
요약은 Claude의 thinking 프로세스의 핵심 아이디어를 최소한의 추가 지연으로 보존하여 스트리밍 가능한 사용자 경험과 Claude Sonnet 3.7에서 Claude 4 모델로의 쉬운 마이그레이션을 가능하게 합니다.
요약은 요청에서 대상으로 지정한 모델과 다른 모델에 의해 처리됩니다. Thinking 모델은 요약된 출력을 보지 않습니다.

Claude Sonnet 3.7은 계속해서 전체 thinking 출력을 반환합니다.

Claude 4 모델에 대한 전체 thinking 출력에 액세스해야 하는 드문 경우, 영업팀에 문의하세요.

Thinking 스트리밍

서버 전송 이벤트(SSE)를 사용하여 extended thinking 응답을 스트리밍할 수 있습니다.

Extended thinking에 대해 스트리밍이 활성화되면 thinking_delta 이벤트를 통해 thinking 콘텐츠를 받습니다.

Messages API를 통한 스트리밍에 대한 자세한 설명서는 스트리밍 메시지를 참조하세요.

Thinking을 사용한 스트리밍을 처리하는 방법은 다음과 같습니다:

curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": {
        "type": "enabled",
        "budget_tokens": 10000
    },
    "messages": [
        {
            "role": "user",
            "content": "What is 27 * 453?"
        }
    ]
}'

콘솔에서 시도해보기

예제 스트리밍 출력:

event: message_start
data: {"type": "message_start", "message": {"id": "msg_01...", "type": "message", "role": "assistant", "content": [], "model": "claude-sonnet-4-5", "stop_reason": null, "stop_sequence": null}}

event: content_block_start
data: {"type": "content_block_start", "index": 0, "content_block": {"type": "thinking", "thinking": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "Let me solve this step by step:\n\n1. First break down 27 * 453"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n2. 453 = 400 + 50 + 3"}}

// Additional thinking deltas...

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "signature_delta", "signature": "EqQBCgIYAhIM1gbcDa9GJwZA2b3hGgxBdjrkzLoky3dl1pkiMOYds..."}}

event: content_block_stop
data: {"type": "content_block_stop", "index": 0}

event: content_block_start
data: {"type": "content_block_start", "index": 1, "content_block": {"type": "text", "text": ""}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 1, "delta": {"type": "text_delta", "text": "27 * 453 = 12,231"}}

// Additional text deltas...

event: content_block_stop
data: {"type": "content_block_stop", "index": 1}

event: message_delta
data: {"type": "message_delta", "delta": {"stop_reason": "end_turn", "stop_sequence": null}}

event: message_stop
data: {"type": "message_stop"}

도구 사용을 포함한 Extended thinking

Extended thinking은 도구 사용과 함께 사용할 수 있으며, Claude가 도구 선택 및 결과 처리를 통해 추론할 수 있습니다.

도구 사용과 함께 extended thinking을 사용할 때 다음 제한 사항을 주의하세요:

도구 선택 제한: Thinking을 포함한 도구 사용은 tool_choice: {"type": "auto"} (기본값) 또는 tool_choice: {"type": "none"}만 지원합니다. tool_choice: {"type": "any"} 또는 tool_choice: {"type": "tool", "name": "..."}를 사용하면 이러한 옵션이 도구 사용을 강제하므로 extended thinking과 호환되지 않아 오류가 발생합니다.
Thinking 블록 보존: 도구 사용 중에 마지막 어시스턴트 메시지에 대해 thinking 블록을 API로 다시 전달해야 합니다. 추론 연속성을 유지하기 위해 완전하고 수정되지 않은 블록을 API로 다시 전달하세요.

대화에서 thinking 모드 전환

Thinking이 활성화된 경우, 최종 어시스턴트 턴은 thinking 블록으로 시작해야 합니다.
Thinking이 비활성화된 경우, 최종 어시스턴트 턴에는 thinking 블록이 포함되어서는 안 됩니다.

예를 들어, 이 시퀀스는 모두 단일 어시스턴트 턴의 일부입니다:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

여러 API 메시지가 있지만, 도구 사용 루프는 개념적으로 하나의 연속적인 어시스턴트 응답의 일부입니다.

일반적인 오류 시나리오

이 오류가 발생할 수 있습니다:

Expected `thinking` or `redacted_thinking`, but found `tool_use`.
When `thinking` is enabled, a final `assistant` message must start
with a thinking block (preceding the lastmost set of `tool_use` and
`tool_result` blocks).

이는 일반적으로 다음과 같은 경우에 발생합니다:

도구 사용 시퀀스 중에 thinking이 비활성화되었습니다.
Thinking을 다시 활성화하려고 합니다.
마지막 어시스턴트 메시지에 thinking 블록이 없는 도구 사용 블록이 포함되어 있습니다.

실용적인 지침

✗ 유효하지 않음: 도구 사용 직후 thinking 전환

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
// 여전히 같은 어시스턴트 턴에 있으므로 여기서 thinking을 활성화할 수 없습니다.

✓ 유효함: 먼저 어시스턴트 턴 완료

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"] 
User: "What about tomorrow?" (thinking disabled)
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

모범 사례: 턴 중간에 전환하려고 하기보다는 각 턴의 시작 부분에서 thinking 전략을 계획하세요.

Thinking 모드 전환은 메시지 기록에 대한 프롬프트 캐싱도 무효화합니다. 자세한 내용은 프롬프트 캐싱을 포함한 Extended thinking 섹션을 참조하세요.

대화에서 사고 모드 전환하기

사고가 활성화된 경우, 최종 어시스턴트 턴은 사고 블록으로 시작해야 합니다.
사고가 비활성화된 경우, 최종 어시스턴트 턴에는 사고 블록이 포함되어서는 안 됩니다.

예를 들어, 이 시퀀스는 모두 단일 어시스턴트 턴의 일부입니다:

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

여러 API 메시지가 있지만, 도구 사용 루프는 개념적으로 하나의 연속적인 어시스턴트 응답의 일부입니다.

일반적인 오류 시나리오

다음과 같은 오류가 발생할 수 있습니다:

Expected `thinking` or `redacted_thinking`, but found `tool_use`.
When `thinking` is enabled, a final `assistant` message must start
with a thinking block (preceding the lastmost set of `tool_use` and
`tool_result` blocks).

이는 일반적으로 다음과 같은 경우에 발생합니다:

도구 사용 시퀀스 중에 사고가 비활성화되어 있었습니다.
사고를 다시 활성화하려고 합니다.
마지막 어시스턴트 메시지에 도구 사용 블록은 있지만 사고 블록이 없습니다.

실용적인 지침

✗ 유효하지 않음: 도구 사용 직후 사고 전환

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
// Cannot enable thinking here - still in the same assistant turn

✓ 유효함: 먼저 어시스턴트 턴 완료

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"] 
User: "What about tomorrow?" (thinking disabled)
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

모범 사례: 턴 중간에 전환하려고 하기보다는 각 턴의 시작 부분에서 사고 전략을 계획하세요.

사고 모드를 전환하면 메시지 기록에 대한 프롬프트 캐싱도 무효화됩니다. 자세한 내용은 프롬프트 캐싱을 사용한 확장 사고 섹션을 참조하세요.

사고 블록 보존하기

제공된 사고 블록을 자동으로 필터링합니다.
모델의 추론을 보존하는 데 필요한 관련 사고 블록을 사용합니다.
Claude에게 표시되는 블록에 대한 입력 토큰만 청구합니다.

추론 연속성: 사고 블록은 도구 요청으로 이어진 Claude의 단계별 추론을 캡처합니다. 도구 결과를 게시할 때 원본 사고를 포함하면 Claude가 중단된 지점에서 추론을 계속할 수 있습니다.
컨텍스트 유지: 도구 결과는 API 구조에서 사용자 메시지로 나타나지만, 연속적인 추론 흐름의 일부입니다. 사고 블록을 보존하면 여러 API 호출에 걸쳐 이 개념적 흐름을 유지합니다. 컨텍스트 관리에 대한 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

인터리빙 사고

인터리빙 사고를 사용하면 Claude는 다음을 수행할 수 있습니다:

도구 호출의 결과에 대해 생각한 후 다음에 할 일을 결정
여러 도구 호출을 중간에 추론 단계와 함께 연결
중간 결과를 기반으로 더 미묘한 결정 내리기

인터리빙 사고를 활성화하려면 API 요청에 베타 헤더 interleaved-thinking-2025-05-14를 추가하세요.

인터리빙 사고에 대한 몇 가지 중요한 고려사항은 다음과 같습니다:

인터리빙 사고를 사용하면 budget_tokens이 max_tokens 매개변수를 초과할 수 있습니다. 이는 한 번의 어시스턴트 턴 내의 모든 사고 블록에 걸친 총 예산을 나타냅니다.
인터리빙 사고는 Messages API를 통해 사용되는 도구에만 지원됩니다.
인터리빙 사고는 Claude 4 모델에만 지원되며, 베타 헤더 interleaved-thinking-2025-05-14가 필요합니다.
Claude API에 대한 직접 호출을 통해 모든 모델에 대한 요청에서 interleaved-thinking-2025-05-14를 전달할 수 있으며, 효과가 없습니다.
3rd-party 플랫폼(예: Amazon Bedrock 및 Vertex AI)에서 Claude Opus 4.5, Claude Opus 4.1, Opus 4 또는 Sonnet 4 이외의 모델에 interleaved-thinking-2025-05-14를 전달하면 요청이 실패합니다.

프롬프트 캐싱을 포함한 확장 사고

프롬프트 캐싱과 사고는 몇 가지 중요한 고려사항이 있습니다:

사고 블록 컨텍스트 제거

이전 턴의 사고 블록은 컨텍스트에서 제거되며, 이는 캐시 중단점에 영향을 미칠 수 있습니다
도구 사용으로 대화를 계속할 때 사고 블록은 캐시되고 캐시에서 읽을 때 입력 토큰으로 계산됩니다
이는 트레이드오프를 만듭니다: 사고 블록은 시각적으로 컨텍스트 윈도우 공간을 소비하지 않지만, 캐시되면 입력 토큰 사용량에 여전히 계산됩니다
사고가 비활성화되면 현재 도구 사용 턴에서 사고 콘텐츠를 전달하면 요청이 실패합니다. 다른 컨텍스트에서는 API에 전달된 사고 콘텐츠가 단순히 무시됩니다

캐시 무효화 패턴

사고 매개변수 변경(활성화/비활성화 또는 예산 할당)은 메시지 캐시 중단점을 무효화합니다
인터리빙 사고는 캐시 무효화를 증폭시킵니다. 사고 블록이 여러 도구 호출 사이에 발생할 수 있기 때문입니다
시스템 프롬프트와 도구는 사고 매개변수 변경이나 블록 제거에도 불구하고 캐시된 상태로 유지됩니다

사고 블록은 캐싱 및 컨텍스트 계산을 위해 제거되지만, 도구 사용으로 대화를 계속할 때, 특히 인터리빙 사고를 사용할 때는 보존되어야 합니다.

프롬프트 캐싱을 사용한 확장 사고

프롬프트 캐싱과 사고에는 여러 가지 중요한 고려사항이 있습니다:

사고 블록 컨텍스트 제거

이전 턴의 사고 블록은 컨텍스트에서 제거되므로 캐시 중단점에 영향을 미칠 수 있습니다
도구 사용으로 대화를 계속할 때 사고 블록은 캐시되고 캐시에서 읽을 때 입력 토큰으로 계산됩니다
이는 트레이드오프를 만듭니다: 사고 블록이 시각적으로 컨텍스트 윈도우 공간을 소비하지 않지만, 캐시될 때 입력 토큰 사용량에 여전히 계산됩니다
사고가 비활성화되면 현재 도구 사용 턴에서 사고 콘텐츠를 전달하면 요청이 실패합니다. 다른 컨텍스트에서는 API에 전달된 사고 콘텐츠가 단순히 무시됩니다

캐시 무효화 패턴

사고 매개변수 변경(활성화/비활성화 또는 예산 할당)은 메시지 캐시 중단점을 무효화합니다
인터리브된 사고는 캐시 무효화를 증폭시킵니다. 사고 블록이 여러 도구 호출 사이에 발생할 수 있기 때문입니다
시스템 프롬프트와 도구는 사고 매개변수 변경이나 블록 제거에도 불구하고 캐시된 상태로 유지됩니다

사고 블록이 캐싱 및 컨텍스트 계산을 위해 제거되지만, 도구 사용으로 대화를 계속할 때, 특히 인터리브된 사고를 사용할 때는 보존되어야 합니다.

사고 블록 캐싱 동작 이해

도구 사용으로 확장 사고를 사용할 때 사고 블록은 토큰 계산에 영향을 미치는 특정 캐싱 동작을 나타냅니다:

작동 방식:

캐싱은 도구 결과를 포함하는 후속 요청을 할 때만 발생합니다
후속 요청이 이루어지면 이전 대화 기록(사고 블록 포함)을 캐시할 수 있습니다
이러한 캐시된 사고 블록은 캐시에서 읽을 때 사용 메트릭의 입력 토큰으로 계산됩니다
비도구 결과 사용자 블록이 포함되면 모든 이전 사고 블록이 무시되고 컨텍스트에서 제거됩니다

상세 예제 흐름:

요청 1:

User: "What's the weather in Paris?"

응답 1:

[thinking_block_1] + [tool_use block 1]

요청 2:

User: ["What's the weather in Paris?"], 
Assistant: [thinking_block_1] + [tool_use block 1], 
User: [tool_result_1, cache=True]

응답 2:

[thinking_block_2] + [text block 2]

요청 3:

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

핵심 포인트:

이 캐싱 동작은 명시적인 cache_control 마커 없이도 자동으로 발생합니다
이 동작은 일반 사고를 사용하든 인터리브된 사고를 사용하든 일관됩니다

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

도구 사용으로 확장 사고를 사용할 때 사고 블록은 명시적으로 보존되고 도구 결과와 함께 반환되어야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 도구 사용을 포함한 확장 사고의 토큰 관리를 보여줍니다:

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우 다이어그램

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

컨텍스트 윈도우에 대한 더 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

확장 사고를 사용한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 고려사항이 있습니다:

이전 턴의 사고 블록은 제거되고 컨텍스트 윈도우에 계산되지 않습니다
현재 턴 사고는 해당 턴의 max_tokens 제한에 계산됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 사용한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 계산을 위해 토큰 계산 API를 사용하는 것을 권장합니다.

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

도구 사용으로 확장 사고를 사용할 때 사고 블록은 명시적으로 보존되고 도구 결과와 함께 반환되어야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 도구 사용을 포함한 확장 사고의 토큰 관리를 보여줍니다:

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우 다이어그램

확장 사고를 사용한 토큰 관리

확장 사고를 사용한 Claude 3.7 및 4 모델의 컨텍스트 윈도우 및 max_tokens 동작을 고려하면 다음을 수행해야 할 수 있습니다:

토큰 사용량을 더 적극적으로 모니터링하고 관리합니다
프롬프트 길이가 변함에 따라 max_tokens 값을 조정합니다
잠재적으로 토큰 계산 엔드포인트를 더 자주 사용합니다
이전 사고 블록이 컨텍스트 윈도우에 누적되지 않음을 인식합니다

이 변경은 특히 최대 토큰 제한이 크게 증가했으므로 더 예측 가능하고 투명한 동작을 제공하기 위해 이루어졌습니다.

최대 토큰 및 확장 사고를 포함한 컨텍스트 윈도우 크기

더 자세한 내용은 컨텍스트 윈도우 가이드를 참고하세요.

확장 사고를 포함한 컨텍스트 윈도우

사고가 활성화된 상태에서 컨텍스트 윈도우 사용량을 계산할 때 주의해야 할 몇 가지 사항이 있습니다:

이전 턴의 사고 블록은 제거되며 컨텍스트 윈도우에 포함되지 않습니다
현재 턴의 사고는 해당 턴의 max_tokens 제한에 포함됩니다

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리를 보여줍니다:

확장 사고를 포함한 컨텍스트 윈도우 다이어그램

효과적인 컨텍스트 윈도우는 다음과 같이 계산됩니다:

context window =
  (current input tokens - previous thinking tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

특히 사고를 포함하는 다중 턴 대화로 작업할 때 정확한 토큰 개수를 얻기 위해 토큰 계산 API를 사용하는 것을 권장합니다.

확장 사고 및 도구 사용을 포함한 컨텍스트 윈도우

확장 사고와 도구 사용을 함께 사용할 때는 사고 블록을 명시적으로 보존하고 도구 결과와 함께 반환해야 합니다.

도구 사용을 포함한 확장 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같습니다:

context window =
  (current input tokens + previous thinking tokens + tool use tokens) +
  (thinking tokens + encrypted thinking tokens + text output tokens)

아래 다이어그램은 확장 사고 및 도구 사용을 포함한 토큰 관리를 보여줍니다:

확장 사고 및 도구 사용을 포함한 컨텍스트 윈도우 다이어그램

확장 사고를 포함한 토큰 관리

Claude 3.7 및 4 모델의 확장 사고를 포함한 컨텍스트 윈도우 및 max_tokens 동작을 고려하면 다음을 수행해야 할 수 있습니다:

토큰 사용량을 더 적극적으로 모니터링하고 관리합니다
프롬프트 길이가 변함에 따라 max_tokens 값을 조정합니다
토큰 계산 엔드포인트를 더 자주 사용할 수 있습니다
이전 사고 블록이 컨텍스트 윈도우에 누적되지 않음을 인식합니다

이 변경은 특히 최대 토큰 제한이 크게 증가했을 때 더 예측 가능하고 투명한 동작을 제공하기 위해 이루어졌습니다.

사고 암호화

사고 블록을 다시 보내는 경우 일관성을 위해 그리고 잠재적인 문제를 피하기 위해 받은 그대로 모든 것을 다시 보내는 것을 권장합니다.

사고 암호화에 대한 몇 가지 중요한 고려 사항은 다음과 같습니다:

응답을 스트리밍할 때, 서명은 content_block_stop 이벤트 직전에 content_block_delta 이벤트 내의 signature_delta를 통해 추가됩니다.
signature 값은 Claude 4 모델에서 이전 모델보다 훨씬 깁니다.
signature 필드는 불투명한 필드이며 해석하거나 파싱해서는 안 됩니다. 검증 목적으로만 존재합니다.
signature 값은 플랫폼 간에 호환됩니다(Claude API, Amazon Bedrock, Vertex AI). 한 플랫폼에서 생성된 값은 다른 플랫폼과 호환됩니다.

사고 편집

확장 사고를 사용하는 고객 대면 애플리케이션을 구축할 때:

편집된 사고 블록에는 인간이 읽을 수 없는 암호화된 내용이 포함되어 있음을 인식합니다
"Claude의 일부 내부 추론이 안전상의 이유로 자동으로 암호화되었습니다. 이는 응답의 품질에 영향을 주지 않습니다."와 같은 간단한 설명을 제공하는 것을 고려합니다
사고 블록을 사용자에게 표시하는 경우 편집된 블록을 필터링하면서 일반 사고 블록을 보존할 수 있습니다
확장 사고 기능을 사용하면 일부 추론이 암호화될 수 있음을 투명하게 공개합니다
편집된 사고를 우아하게 관리하고 UI를 손상시키지 않도록 적절한 오류 처리를 구현합니다

다음은 일반 사고 블록과 편집된 사고 블록을 모두 보여주는 예입니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "redacted_thinking",
      "data": "EmwKAhgBEgy3va3pzix/LafPsn4aDFIT2Xlxh0L5L8rLVyIwxtE3rAFBa8cr3qpPkNRj2YfWXGmKDxH4mPnZ5sQ7vB9URj2pLmN3kF8/dW5hR7xJ0aP1oLs9yTcMnKVf2wRpEGjH9XZaBt4UvDcPrQ..."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

모델 버전 간 사고의 차이점

Messages API는 Claude Sonnet 3.7 및 Claude 4 모델 간에 사고를 다르게 처리하며, 주로 편집 및 요약 동작에서 차이가 있습니다.

압축된 비교를 위해 아래 표를 참고하세요:

기능	Claude Sonnet 3.7	Claude 4 모델(Opus 4.5 이전)	Claude Opus 4.5 이상
사고 출력	전체 사고 출력 반환	요약된 사고 반환	요약된 사고 반환
인터리빙된 사고	지원되지 않음	`interleaved-thinking-2025-05-14` 베타 헤더로 지원	`interleaved-thinking-2025-05-14` 베타 헤더로 지원
사고 블록 보존	턴 간에 보존되지 않음	턴 간에 보존되지 않음	기본적으로 보존됨(캐시 최적화, 토큰 절감 가능)

Claude Opus 4.5의 사고 블록 보존

사고 블록 보존의 이점:

캐시 최적화: 도구 사용을 사용할 때 보존된 사고 블록은 도구 결과와 함께 다시 전달되고 어시스턴트 턴 전체에서 증분적으로 캐시되어 다중 단계 워크플로우에서 토큰 절감을 가능하게 합니다
지능에 미치는 영향 없음: 사고 블록을 보존해도 모델 성능에 부정적인 영향을 미치지 않습니다

중요한 고려 사항:

컨텍스트 사용: 사고 블록이 컨텍스트에 유지되므로 긴 대화는 더 많은 컨텍스트 공간을 소비합니다
자동 동작: 이는 Claude Opus 4.5의 기본 동작입니다. 코드 변경이나 베타 헤더가 필요하지 않습니다
역호환성: 이 기능을 활용하려면 도구 사용과 마찬가지로 완전하고 수정되지 않은 사고 블록을 API로 다시 전달하는 것을 계속합니다

사고 편집

확장 사고를 사용하는 고객 대면 애플리케이션을 구축할 때:

편집된 사고 블록에는 인간이 읽을 수 없는 암호화된 콘텐츠가 포함되어 있음을 인식하세요
"Claude의 일부 내부 추론이 안전상의 이유로 자동으로 암호화되었습니다. 이는 응답의 품질에 영향을 주지 않습니다."와 같은 간단한 설명을 제공하는 것을 고려하세요
사고 블록을 사용자에게 표시하는 경우, 일반 사고 블록을 유지하면서 편집된 블록을 필터링할 수 있습니다
확장 사고 기능을 사용하면 때때로 일부 추론이 암호화될 수 있다는 점을 투명하게 전달하세요
편집된 사고를 우아하게 관리하여 UI가 깨지지 않도록 적절한 오류 처리를 구현하세요

다음은 일반 사고 블록과 편집된 사고 블록을 모두 보여주는 예시입니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me analyze this step by step...",
      "signature": "WaUjzkypQ2mUEVM36O2TxuC06KN8xyfbJwyem2dw3URve/op91XWHOEBLLqIOMfFG/UvLEczmEsUjavL...."
    },
    {
      "type": "redacted_thinking",
      "data": "EmwKAhgBEgy3va3pzix/LafPsn4aDFIT2Xlxh0L5L8rLVyIwxtE3rAFBa8cr3qpPkNRj2YfWXGmKDxH4mPnZ5sQ7vB9URj2pLmN3kF8/dW5hR7xJ0aP1oLs9yTcMnKVf2wRpEGjH9XZaBt4UvDcPrQ..."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

모델 버전 간 사고의 차이점

Messages API는 Claude Sonnet 3.7과 Claude 4 모델 간에 사고를 다르게 처리하며, 주로 편집 및 요약 동작에서 차이가 있습니다.

아래 표에서 압축된 비교를 참조하세요:

기능	Claude Sonnet 3.7	Claude 4 모델 (Opus 4.5 이전)	Claude Opus 4.5 이상
사고 출력	전체 사고 출력 반환	요약된 사고 반환	요약된 사고 반환
인터리브된 사고	지원되지 않음	`interleaved-thinking-2025-05-14` 베타 헤더로 지원	`interleaved-thinking-2025-05-14` 베타 헤더로 지원
사고 블록 보존	턴 간에 보존되지 않음	턴 간에 보존되지 않음	기본적으로 보존됨 (캐시 최적화, 토큰 절감 가능)

Claude Opus 4.5의 사고 블록 보존

사고 블록 보존의 이점:

캐시 최적화: 도구 사용 시, 보존된 사고 블록은 도구 결과와 함께 다시 전달되고 어시스턴트 턴 전체에서 증분적으로 캐시되어 다중 단계 워크플로우에서 토큰 절감을 가능하게 합니다
지능 영향 없음: 사고 블록을 보존해도 모델 성능에 부정적인 영향을 주지 않습니다

중요한 고려사항:

컨텍스트 사용: 사고 블록이 컨텍스트에 유지되므로 긴 대화는 더 많은 컨텍스트 공간을 소비합니다
자동 동작: 이는 Claude Opus 4.5의 기본 동작입니다—코드 변경이나 베타 헤더가 필요하지 않습니다
하위 호환성: 이 기능을 활용하려면, 도구 사용과 마찬가지로 완전하고 수정되지 않은 사고 블록을 API로 다시 전달하세요

가격 책정

기본 요금, 캐시 쓰기, 캐시 히트 및 출력 토큰을 포함한 완전한 가격 책정 정보는 가격 책정 페이지를 참조하세요.

사고 프로세스는 다음에 대해 요금이 부과됩니다:

사고 중에 사용된 토큰 (출력 토큰)
후속 요청에 포함된 마지막 어시스턴트 턴의 사고 블록 (입력 토큰)
표준 텍스트 출력 토큰

확장 사고가 활성화되면, 이 기능을 지원하기 위해 특수 시스템 프롬프트가 자동으로 포함됩니다.

요약된 사고를 사용할 때:

입력 토큰: 원본 요청의 토큰 (이전 턴의 사고 토큰 제외)
출력 토큰 (청구됨): Claude가 내부적으로 생성한 원본 사고 토큰
출력 토큰 (표시됨): 응답에서 보이는 요약된 사고 토큰
요금 없음: 요약을 생성하는 데 사용된 토큰

청구된 출력 토큰 수는 응답의 표시된 토큰 수와 일치하지 않습니다. 보이는 요약이 아닌 전체 사고 프로세스에 대해 청구됩니다.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

사용 지침

작업 선택: 수학, 코딩 및 분석과 같이 단계별 추론의 이점을 얻는 특히 복잡한 작업에 확장 사고를 사용하세요.
컨텍스트 처리: 이전 사고 블록을 직접 제거할 필요가 없습니다. Claude API는 자동으로 이전 턴의 사고 블록을 무시하며 컨텍스트 사용량 계산에 포함되지 않습니다.
프롬프트 엔지니어링: Claude의 사고 기능을 최대화하려면 확장 사고 프롬프팅 팁을 검토하세요.

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

예산 최적화: 최소 예산은 1,024 토큰입니다. 최소값부터 시작하여 사용 사례에 최적의 범위를 찾기 위해 사고 예산을 증분적으로 늘릴 것을 제안합니다. 더 높은 토큰 수는 더 포괄적인 추론을 가능하게 하지만 작업에 따라 수익이 감소합니다. 예산을 늘리면 응답 품질이 향상될 수 있지만 지연 시간이 증가하는 대가가 있습니다. 중요한 작업의 경우, 최적의 균형을 찾기 위해 다양한 설정을 테스트하세요. 사고 예산은 엄격한 제한이 아니라 목표입니다—실제 토큰 사용량은 작업에 따라 달라질 수 있습니다.
시작점: 복잡한 작업의 경우 더 큰 사고 예산 (16k+ 토큰)으로 시작하고 필요에 따라 조정하세요.
큰 예산: 사고 예산이 32k 이상인 경우, 네트워킹 문제를 피하기 위해 배치 처리를 사용할 것을 권장합니다. 모델을 32k 토큰 이상으로 생각하도록 하는 요청은 시스템 타임아웃 및 열린 연결 제한에 걸릴 수 있는 장시간 실행 요청을 야기합니다.
토큰 사용량 추적: 비용과 성능을 최적화하기 위해 사고 토큰 사용량을 모니터링하세요.

성능 고려사항

응답 시간: 추론 프로세스에 필요한 추가 처리로 인해 잠재적으로 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가할 수 있다는 점을 고려하세요.
스트리밍 요구사항: max_tokens가 21,333보다 클 때 스트리밍이 필요합니다. 스트리밍할 때, 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.

기능 호환성

사고는 temperature 또는 top_k 수정뿐만 아니라 강제 도구 사용과 호환되지 않습니다.
사고가 활성화되면, top_p를 1과 0.95 사이의 값으로 설정할 수 있습니다.
사고가 활성화되면 응답을 미리 채울 수 없습니다.
사고 예산의 변경은 메시지를 포함하는 캐시된 프롬프트 접두사를 무효화합니다. 그러나 캐시된 시스템 프롬프트 및 도구 정의는 사고 매개변수가 변경될 때 계속 작동합니다.

사용 지침

작업 선택: 수학, 코딩 및 분석과 같이 단계별 추론의 이점을 얻는 특히 복잡한 작업에 확장 사고를 사용하세요.
컨텍스트 처리: 이전 사고 블록을 직접 제거할 필요가 없습니다. Claude API는 자동으로 이전 턴의 사고 블록을 무시하며 컨텍스트 사용량 계산에 포함되지 않습니다.
프롬프트 엔지니어링: Claude의 사고 기능을 최대화하려면 확장 사고 프롬프팅 팁을 검토하세요.

다음 단계

확장 사고 쿡북 시도해보기

우리의 쿡북에서 사고의 실용적인 예시를 탐색하세요.

확장 사고 프롬프팅 팁

확장 사고를 위한 프롬프트 엔지니어링 모범 사례를 배우세요.

지원되는 모델

확장된 사고의 작동 방식

확장된 사고를 사용하는 방법

요약된 사고

스트리밍 사고

지원되는 모델

Extended thinking 작동 방식

Extended thinking 사용 방법

요약된 thinking

Thinking 스트리밍

도구 사용을 포함한 Extended thinking

대화에서 thinking 모드 전환

일반적인 오류 시나리오

실용적인 지침

예제: 도구 결과와 함께 thinking 블록 전달

대화에서 사고 모드 전환하기

일반적인 오류 시나리오

실용적인 지침

예제: 도구 결과와 함께 사고 블록 전달

사고 블록 보존하기

인터리빙 사고

인터리빙 사고 없는 도구 사용

인터리빙 사고를 포함한 도구 사용

프롬프트 캐싱을 포함한 확장 사고

프롬프트 캐싱을 사용한 확장 사고

사고 블록 캐싱 동작 이해

시스템 프롬프트 캐싱(사고 변경 시 보존됨)

메시지 캐싱(사고 변경 시 무효화됨)

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

확장 사고를 사용한 컨텍스트 윈도우

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

확장 사고를 사용한 컨텍스트 윈도우

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

확장 사고를 사용한 최대 토큰 및 컨텍스트 윈도우 크기

확장 사고를 사용한 컨텍스트 윈도우

도구 사용을 포함한 확장 사고의 컨텍스트 윈도우

확장 사고를 사용한 토큰 관리

최대 토큰 및 확장 사고를 포함한 컨텍스트 윈도우 크기

확장 사고를 포함한 컨텍스트 윈도우

확장 사고 및 도구 사용을 포함한 컨텍스트 윈도우

확장 사고를 포함한 토큰 관리

사고 암호화

사고 편집

예: 편집된 사고 블록 작업

모델 버전 간 사고의 차이점

Claude Opus 4.5의 사고 블록 보존

사고 편집

예시: 편집된 사고 블록 작업하기

모델 버전 간 사고의 차이점

Claude Opus 4.5의 사고 블록 보존

가격 책정

확장 사고를 위한 모범 사례 및 고려사항

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

성능 고려사항

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

성능 고려사항

기능 호환성

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

성능 고려사항

기능 호환성

사용 지침

확장 사고를 위한 모범 사례 및 고려사항

사고 예산 작업

성능 고려사항

기능 호환성

사용 지침

다음 단계

지원되는 모델

확장된 사고의 작동 방식

확장된 사고를 사용하는 방법

요약된 사고

스트리밍 사고

지원되는 모델

Extended thinking 작동 방식