확장된 사고를 통한 구축

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

지원되는 모델

수동 확장된 사고(thinking: {type: "enabled", budget_tokens: N})는 Claude Opus 4.7 이상 모델을 제외한 모든 현재 Claude 모델에서 지원되며, 여기서는 더 이상 허용되지 않고 400 오류를 반환합니다. 몇 가지 모델은 모드별 동작이 있습니다:

• Claude Opus 4.7(claude-opus-4-7) 이상 모델: 수동 확장된 사고는 더 이상 지원되지 않습니다. 대신 적응형 사고(thinking: {type: "adaptive"})를 노력 매개변수와 함께 사용하세요.
• Claude Mythos Preview: 적응형 사고가 기본값입니다. thinking: {type: "enabled", budget_tokens: N}도 허용됩니다. thinking: {type: "disabled"}는 지원되지 않으며, display는 사고 내용을 반환하는 대신 기본값이 "omitted"입니다. 요약을 받으려면 display: "summarized"를 전달하세요.
• Claude Opus 4.6(claude-opus-4-6): 적응형 사고 권장; 수동 모드(type: "enabled")는 더 이상 사용되지 않지만 여전히 작동합니다.
• Claude Sonnet 4.6(claude-sonnet-4-6): 적응형 사고 권장; 인터리브 모드를 사용한 수동 모드(type: "enabled")는 더 이상 사용되지 않지만 여전히 작동합니다.

확장된 사고의 작동 원리

확장된 사고가 켜지면, 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에서 확장된 사고를 사용하는 예입니다:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    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?",
        }
    ],
)

# The response contains summarized thinking blocks and text blocks
for block in response.content:
    if block.type == "thinking":
        print(f"\nThinking summary: {block.thinking}")
    elif block.type == "text":
        print(f"\nResponse: {block.text}")

확장된 사고를 켜려면, type 매개변수를 enabled로 설정하고 budget_tokens를 확장된 사고를 위한 지정된 토큰 예산으로 설정한 thinking 객체를 추가하세요. Claude Opus 4.6 및 Claude Sonnet 4.6의 경우, 대신 type: "adaptive"를 사용하세요. 자세한 내용은 적응형 사고를 참조하세요. type: "enabled"와 budget_tokens는 여전히 이 모델들에서 작동하지만 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

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

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

요약된 사고

With extended thinking enabled, the Messages API for Claude 4 models returns a summary of Claude's full thinking process. Summarized thinking provides the full intelligence benefits of extended thinking, while preventing misuse. This is the default behavior on Claude 4 models when the display field on the thinking configuration is unset or set to "summarized". On Claude Opus 4.7 and Claude Mythos Preview, display defaults to "omitted" instead, so you must set display: "summarized" explicitly to receive summarized thinking.

Here are some important considerations for summarized thinking:

• You're charged for the full thinking tokens generated by the original request, not the summary tokens.
• The billed output token count will not match the count of tokens you see in the response.
• On Claude 4 models, the first few lines of thinking output are more verbose, providing detailed reasoning that's particularly helpful for prompt engineering purposes. Claude Mythos Preview summarizes from the first token, so its thinking blocks do not show this verbose preamble.
• As Anthropic seeks to improve the extended thinking feature, summarization behavior is subject to change.
• Summarization preserves the key ideas of Claude's thinking process with minimal added latency, enabling a streamable user experience and easy migration from Claude Sonnet 3.7 to Claude 4 and later models.
• Summarization is processed by a different model than the one you target in your requests. The thinking model does not see the summarized output.

사고 표시 제어

The display field on the thinking configuration controls how thinking content is returned in API responses. It accepts two values:

• "summarized": Thinking blocks contain summarized thinking text. See Summarized thinking for details. This is the default on Claude Opus 4.6, Claude Sonnet 4.6, and earlier Claude 4 models.
• "omitted": Thinking blocks are returned with an empty thinking field. The signature field still carries the encrypted full thinking for multi-turn continuity (see Thinking encryption). This is the default on Claude Opus 4.7 and Claude Mythos Preview.

Setting display: "omitted" is useful when your application doesn't surface thinking content to users. The primary benefit is faster time-to-first-text-token when streaming: The server skips streaming thinking tokens entirely and delivers only the signature, so the final text response begins streaming sooner.

Here are some important considerations for omitted thinking:

• You're still charged for the full thinking tokens. Omitting reduces latency, not cost.
• If you pass thinking blocks back in multi-turn conversations, pass them unchanged. The server decrypts the signature to reconstruct the original thinking for prompt construction (see Preserving thinking blocks). Any text you place in the thinking field of a round-tripped omitted block is ignored.
• display is invalid with thinking.type: "disabled" (there is nothing to display).
• When using thinking.type: "adaptive" and the model skips thinking for a simple request, no thinking block is produced regardless of display.

최종 사용자에게 사고 콘텐츠를 표시하지 않는 자동화된 파이프라인은 사고 토큰을 네트워크를 통해 수신하는 오버헤드를 건너뛸 수 있습니다. 지연 시간에 민감한 애플리케이션은 최종 응답이 시작되기 전에 사고 텍스트가 스트리밍될 때까지 기다리지 않고도 동일한 추론 품질을 얻습니다.

display: "omitted"이 설정되면, 응답에는 빈 thinking 필드가 있는 thinking 블록이 포함됩니다:

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EosnCkYICxIMMb3LzNrMu..."
    },
    {
      "type": "text",
      "text": "The answer is 12,231."
    }
  ]
}

display: "omitted"으로 스트리밍할 때, thinking_delta 이벤트는 발생하지 않습니다. 아래의 사고 스트리밍에서 이벤트 시퀀스를 참조하세요.

스트리밍 사고

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

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

display: "omitted"가 설정되면 thinking_delta 이벤트가 발생하지 않습니다. 사고 표시 제어를 참조하세요.

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

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

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-sonnet-4-6",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
) as stream:
    thinking_started = False
    response_started = False

    for event in stream:
        if event.type == "content_block_start":
            print(f"\nStarting {event.content_block.type} block...")
            # Reset flags for each new block
            thinking_started = False
            response_started = False
        elif event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                if not thinking_started:
                    print("Thinking: ", end="", flush=True)
                    thinking_started = True
                print(event.delta.thinking, end="", flush=True)
            elif event.delta.type == "text_delta":
                if not response_started:
                    print("Response: ", end="", flush=True)
                    response_started = True
                print(event.delta.text, end="", flush=True)
        elif event.type == "content_block_stop":
            print("\nBlock complete.")

스트리밍 출력 예시:

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

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

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "I need to find the GCD of 1071 and 462 using the Euclidean algorithm.\n\n1071 = 2 × 462 + 147"}}

event: content_block_delta
data: {"type": "content_block_delta", "index": 0, "delta": {"type": "thinking_delta", "thinking": "\n462 = 3 × 147 + 21\n147 = 7 × 21 + 0\n\nSo GCD(1071, 462) = 21"}}

// 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": "The greatest common divisor of 1071 and 462 is **21**."}}

// 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"}

display: "omitted"가 설정되면 사고 블록이 열리고, 단일 signature_delta가 도착하며, thinking_delta 이벤트 없이 블록이 닫힙니다. 텍스트 스트리밍은 그 직후에 시작됩니다:

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

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

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":""}}

도구 사용과 함께 확장 사고

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

확장 사고와 함께 도구 사용을 사용할 때 다음 제한 사항을 주의하세요:

1. 도구 선택 제한: 사고를 사용한 도구 사용은 tool_choice: {"type": "auto"} (기본값) 또는 tool_choice: {"type": "none"}만 지원합니다. tool_choice: {"type": "any"} 또는 tool_choice: {"type": "tool", "name": "..."}를 사용하면 오류가 발생합니다. 이러한 옵션은 도구 사용을 강제하기 때문에 확장 사고와 호환되지 않습니다.

2. 사고 블록 보존: 도구 사용 중에 마지막 어시스턴트 메시지에 대해 thinking 블록을 API로 다시 전달해야 합니다. 추론 연속성을 유지하기 위해 완전하고 수정되지 않은 블록을 API로 다시 전달하세요.

대화에서 사고 모드 전환

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

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

모델의 관점에서 도구 사용 루프는 어시스턴트 턴의 일부입니다. 어시스턴트 턴은 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 메시지가 있지만, 도구 사용 루프는 개념적으로 하나의 연속적인 어시스턴트 응답의 일부입니다.

우아한 사고 저하

턴 중간 사고 충돌이 발생하면(예: 도구 사용 루프 중에 사고를 켜거나 끌 때), API는 자동으로 해당 요청에 대해 사고를 비활성화합니다. 모델 품질을 보존하고 분포 내에 유지하기 위해 API는 다음을 수행할 수 있습니다:

• 잘못된 턴 구조를 만들 사고 블록을 대화에서 제거
• 대화 기록이 사고 활성화와 호환되지 않을 때 현재 요청에 대해 사고를 비활성화

이는 턴 중간에 사고를 전환하려고 시도해도 오류가 발생하지 않지만, 해당 요청에 대해 사고가 자동으로 비활성화된다는 의미입니다. 사고가 활성화되었는지 확인하려면 응답에서 thinking 블록의 존재 여부를 확인하세요.

실용적 지침

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

예: 턴 완료 후 사고 전환

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

어시스턴트 턴을 완료한 후 사고를 전환하면 새 요청에 대해 사고가 실제로 활성화됩니다.

사고 블록 보존

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

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

1. 추론 연속성: 사고 블록은 도구 요청으로 이어진 Claude의 단계별 추론을 캡처합니다. 도구 결과를 게시할 때, 원래 사고를 포함하면 Claude가 중단한 지점에서 추론을 계속할 수 있습니다.

2. 컨텍스트 유지: 도구 결과가 API 구조에서 사용자 메시지로 나타나지만, 이들은 연속적인 추론 흐름의 일부입니다. 사고 블록을 보존하면 여러 API 호출에 걸쳐 이 개념적 흐름을 유지합니다. 컨텍스트 관리에 대한 자세한 내용은 컨텍스트 윈도우 가이드를 참조하세요.

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

인터리브된 사고

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

인터리브된 사고를 통해 Claude는:

• 도구 호출의 결과에 대해 추론하고 다음에 할 일을 결정할 수 있습니다.
• 중간 추론 단계를 포함하여 여러 도구 호출을 연결할 수 있습니다.
• 중간 결과를 기반으로 더 미묘한 결정을 내릴 수 있습니다.

모델 지원:

• Claude Mythos Preview: 인터리브된 사고가 자동으로 발생합니다. 모든 도구 간 추론 단계는 일반 텍스트 대신 사고 블록으로 이동하며, 사고 블록은 기본적으로 턴 전체에 걸쳐 보존됩니다. 베타 헤더가 필요하거나 지원되지 않습니다.
• Claude Opus 4.7: 인터리브된 사고는 적응형 사고를 사용할 때 자동으로 활성화됩니다(Opus 4.7에서 지원되는 유일한 사고 모드). 베타 헤더가 필요하지 않습니다.
• Claude Opus 4.6: 인터리브된 사고는 적응형 사고를 사용할 때 자동으로 활성화됩니다. 베타 헤더가 필요하지 않습니다. interleaved-thinking-2025-05-14 베타 헤더는 Opus 4.6에서 더 이상 사용되지 않으며 포함된 경우 안전하게 무시됩니다.
• Claude Sonnet 4.6: 인터리브된 사고는 적응형 사고를 사용할 때 자동으로 활성화됩니다(권장). 수동 확장 사고(thinking: {type: "enabled"})를 포함한 interleaved-thinking-2025-05-14 베타 헤더는 여전히 기능하지만 더 이상 사용되지 않습니다.
• 기타 Claude 4 모델(Opus 4.5, Opus 4.1, Opus 4(더 이상 사용되지 않음), Sonnet 4.5, Sonnet 4(더 이상 사용되지 않음)): API 요청에 베타 헤더 interleaved-thinking-2025-05-14를 추가하여 인터리브된 사고를 활성화하세요.

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

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

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

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

사고 블록 컨텍스트 제거

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

캐시 무효화 패턴

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

사고 블록 캐싱 동작 이해

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

작동 방식:

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

상세한 예제 흐름:

요청 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 이상(Claude Opus 4.6 포함)의 경우, 모든 이전 사고 블록이 기본적으로 유지됩니다. 이전 모델의 경우, 도구 결과가 아닌 사용자 블록이 포함되었으므로 모든 이전 사고 블록이 무시됩니다. 이 요청은 다음과 같이 처리됩니다:

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를 사용하여 특히 사고를 포함하는 다중 턴 대화로 작업할 때 특정 사용 사례에 대한 정확한 토큰 수를 얻으세요.

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

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

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

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 값 조정
• 토큰 계산 엔드포인트를 더 자주 사용
• 이전 사고 블록이 컨텍스트 윈도우에 누적되지 않음을 인식

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

사고 암호화

Full thinking content is encrypted and returned in the signature field. This field is used to verify that thinking blocks were generated by Claude when passed back to the API.

Here are some important considerations on thinking encryption:

• When streaming responses, the signature is added via a signature_delta inside a content_block_delta event just before the content_block_stop event.
• signature values are significantly longer in Claude 4 models than in previous models.
• The signature field is an opaque field and should not be interpreted or parsed.
• signature values are compatible across platforms (Claude APIs, Amazon Bedrock, and Vertex AI). Values generated on one platform will be compatible with another.

편집된 사고 블록

일반 thinking 블록 외에도 API는 redacted_thinking 블록을 반환할 수 있습니다. redacted_thinking 블록은 data 필드에 암호화된 사고 내용을 포함하며 읽을 수 있는 요약이 없습니다:

{
  "type": "redacted_thinking",
  "data": "..."
}

data 필드는 불투명하고 암호화되어 있습니다. 일반 사고 블록의 signature 필드와 마찬가지로 도구를 사용하여 다중 턴 대화를 계속할 때 redacted_thinking 블록을 API에 변경되지 않은 상태로 전달해야 합니다.

모델 버전 간 사고의 차이점

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

아래 표에서 압축된 비교를 확인하세요:

Claude Opus 4.5 이상에서의 사고 블록 보존

Claude Opus 4.5부터(Claude Opus 4.6에서도 계속) 이전 어시스턴트 턴의 사고 블록이 기본적으로 모델 컨텍스트에 보존됩니다. 이는 이전 턴의 사고 블록을 제거하는 이전 모델과 다릅니다.

사고 블록 보존의 이점:

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

중요한 고려사항:

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

가격 책정

For complete pricing information including base rates, cache writes, cache hits, and output tokens, see the pricing page.

The thinking process incurs charges for:

• Tokens used during thinking (output tokens)
• Thinking blocks from prior assistant turns kept in context: only the last turn on earlier Opus/Sonnet models and all Haiku models; all turns by default on Opus 4.5+ and Sonnet 4.6+ (input tokens)
• Standard text output tokens

When using summarized thinking:

• Input tokens: Tokens in your original request (excludes thinking tokens from previous turns)
• Output tokens (billed): The original thinking tokens that Claude generated internally
• Output tokens (visible): The summarized thinking tokens you see in the response
• No charge: Tokens used to generate the summary

When using display: "omitted":

• Input tokens: Tokens in your original request (same as summarized)
• Output tokens (billed): The original thinking tokens that Claude generated internally (same as summarized)
• Output tokens (visible): Zero thinking tokens (the thinking field is empty)

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

사고 예산 작업

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

성능 고려사항

• 응답 시간: 추가 처리로 인한 더 긴 응답 시간에 대비하세요. 사고 블록을 생성하면 전체 응답 시간이 증가합니다.
• 스트리밍 요구사항: SDK는 max_tokens가 21,333보다 클 때 HTTP 타임아웃을 피하기 위해 스트리밍이 필요합니다. 이는 클라이언트 측 검증이지 API 제한이 아닙니다. 이벤트를 증분식으로 처리할 필요가 없으면 .stream()을 .get_final_message()(Python) 또는 .finalMessage()(TypeScript)와 함께 사용하여 개별 이벤트를 처리하지 않고 완전한 Message` 객체를 얻으세요. 자세한 내용은 메시지 스트리밍을 참조하세요. 스트리밍할 때 사고 및 텍스트 콘텐츠 블록이 도착할 때 모두 처리할 준비를 하세요.
• 지연 시간을 위해 사고 생략: 애플리케이션이 사고 콘텐츠를 표시하지 않으면 사고 구성에서 display: "omitted"를 설정하여 첫 번째 텍스트 토큰까지의 시간을 줄이세요. 사고 표시 제어를 참조하세요.

기능 호환성

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

사용 지침

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

다음 단계