advisor 도구: Sonnet은 일을 하고, Fable은 생각을 한다
Anthropic은 조용하지만 중대한 프리미티브를 베타로 출시했습니다. 바로 advisor 도구입니다. 빠른 실행자 모델(Sonnet, Haiku)이 턴을 주도하고, 결정 지점에서 전체 트랜스크립트를 더 강력한 자문 모델(Opus 5, Fable 5, Mythos 5)에 넘깁니다. 자문 모델이 계획을 반환하면 실행자는 다시 타이핑을 이어갑니다. 모두 서버 사이드에서, 단일 /v1/messages 호출 안에서 이루어집니다 — 여러분 쪽에서 추가 왕복 요청은 필요 없습니다.
수동으로 모델을 전환해왔다면 — 계획은 Opus로, 작성은 Sonnet으로 — advisor는 그 춤사위를 단일 요청으로 압축해줍니다. 또한 이는 하나의 응답 안에서 두 개의 모델 티어에 걸쳐 정기적으로 과금되는 최초의 주류 프로덕션 패턴이며, 2026년 3월 이전에 작성된 순진한 usage.output_tokens * price 방식의 비용 트래커를 모조리 무너뜨립니다.
- 베타 헤더 advisor-tool-2026-03-01, 실행자 모델, advisor 도구 정의를 포함한 요청을 전송
- usage.iterations를 올바르게 읽기 — 최상위 output_tokens는 실행자 전용이며, advisor 토큰은 type이 advisor_message인 iteration 항목 안에 존재
- 실행자/자문 페어를 선택 — 자문 모델은 실행자 이상으로 강력해야 하며, Opus 5 / Fable 5 / Mythos 5는 원문 그대로 왕복 전달해야 하는 암호화된 콘텐츠를 반환
- 도구 정의의 max_tokens(최소 1024)로 폭주하는 자문을 제한 — 최상위 max_tokens는 advisor에 적용되지 않음
- 3회 이상의 advisor 호출이 있는 대화에서는 advisor 측 캐싱을 활성화하고, clear_thinking의 기본값이 왜 그 캐시를 조용히 무력화하는지 이해
- 저장된 advisorModel과 함께 Claude Code에서 /advisor 활성화 — Fable 5 롤아웃 이슈 포함(현재 Fable 액세스를 가진 조직조차 자문 모델로 사용 비활성화 상태)
advisor가 존재하는 이유 (그리고 왜 단순히 "두 API를 호출"하는 것이 아닌지)
순진한 대안은 명백합니다: Opus를 호출해 계획을 받고, 그 계획을 시스템 프롬프트로 삼아 Sonnet을 호출하는 것. Anthropic 공식 문서는 advisor가 그것을 이기는 이유를 직설적으로 설명합니다:
- advisor는 실행자의 전체 트랜스크립트를 읽습니다 — 이전의 모든 턴, 모든 도구 호출, 모든 결과, 게다가 실행자가 현재 턴에서 지금까지 생성한 텍스트까지 전부. 여러분이 직접 하려면 이 모든 것을 직렬화하여 전달해야 합니다.
- 하나의
/v1/messages요청 안에서 실행됩니다. 여러분의 스트리밍 연결은 잠시 정지되고(약 30초마다 SSEpingkeepalive와 함께)advisor_tool_result블록이 하나의content_block_start이벤트로 완전히 형성되어 도착합니다 — 델타가 없습니다. 그 직후 실행자 출력이 스트리밍을 재개합니다. - 실행자가 언제 advisor를 호출할지 결정합니다. "항상 먼저 계획하라"고 하드코딩하지 않습니다. Claude는 접근 방식을 확정하기 전에, 같은 오류가 계속 재발할 때, 그리고 작업 완료를 선언하기 전에 advisor를 호출하는 경향이 있습니다.
advisor는 Anthropic이 제공하는 자체 시스템 프롬프트로, 도구 없이, 컨텍스트 관리 없이 실행되며, 결과가 반환되기 전에 thinking 블록이 제거됩니다. 오직 조언 텍스트(또는 암호화된 blob)만이 실행자에게 도달합니다.
빠른 시작 — 최소 실행 가능한 advisor 요청
Sonnet 5 실행자 + Fable 5 자문 (Python)
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-sonnet-5",
max_tokens=4096,
betas=["advisor-tool-2026-03-01"],
tools=[
{
"type": "advisor_20260301",
"name": "advisor",
"model": "claude-fable-5",
}
],
messages=[
{
"role": "user",
"content": "Build a concurrent worker pool in Go with graceful shutdown.",
}
],
)
print(response)주목할 세 가지:
type문자열은"advisor_20260301"이고name은 반드시"advisor"여야 합니다. 둘 다 문자 그대로 강제됩니다.betas=["advisor-tool-2026-03-01"]헤더가 도구를 여는 플래그입니다. cURL에서는-H "anthropic-beta: advisor-tool-2026-03-01"과 동일한 문자열입니다.- 실행자가 발행하는
server_tool_use블록의input은 항상 비어 있습니다. 여러분이 채우지 않습니다. 서버가 트랜스크립트로부터 advisor의 뷰를 자동으로 구성합니다.
페어링 규칙 (그리고 Fable 5에 관한 놀라운 사실)
자문 모델은 실행자 이상으로 강력해야 하며, Anthropic은 동등한 성능의 모델을 서로에 대한 자문 모델로 인정합니다(Opus 4.7과 Opus 4.8은 서로 자문 가능, Sonnet 5와 Opus 4.6도 마찬가지). 2026년 8월 기준 Claude API에서 승인된 전체 매트릭스는 다음과 같습니다:
| 실행자 | 승인된 자문 모델 |
|---|---|
claude-haiku-4-5 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6 |
claude-sonnet-4-6 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6 |
claude-sonnet-5 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7, Sonnet 5 |
claude-opus-4-6 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 |
claude-opus-4-7 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7 |
claude-opus-4-8 | Mythos 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7 |
claude-opus-5 | Mythos 5, Fable 5, Opus 5 |
claude-fable-5 | Fable 5, Opus 5 |
claude-mythos-5 | Mythos 5, Opus 5 |
유효하지 않은 페어는 지원되지 않는 조합을 지목하는 400 invalid_request_error를 반환합니다. 그리고 별도로 짚어둘 만한 Claude Code 관련 반전이 있습니다: Fable 5는 현재 Claude Code에서 자문 모델로 비활성화되어 있습니다 — Fable 5 액세스가 있는 조직에서도 마찬가지이며, 서버 사이드 롤아웃으로 제어됩니다. /advisor 피커에는 흐리게 표시된 Fable 5 (temporarily unavailable) 행이 보이고, /advisor fable은 거부됩니다. 이는 API에는 영향을 주지 않으며, 오늘도 API에서는 자문 모델로서 claude-fable-5가 작동합니다.
대부분의 통합 개발자가 걸어 들어가는 토큰 계산 함정
이것이 advisor에 대해 가장 놀라운 단 하나의 사실이며, 비용 트래커를 먼저 다시 쓰지 않고서는 advisor 통합을 배포해서는 안 되는 이유입니다.
최상위 usage.output_tokens는 실행자 토큰만을 반영합니다. advisor 토큰은 최상위 합계에 포함되지 않는데, 그 이유는 자문 모델의 요율로 과금되며 이는 거의 항상 다르기 때문입니다. 전체 그림을 보려면 Anthropic이 이 기능을 위해 특별히 추가한 usage.iterations[] 배열을 읽어야 합니다:
{
"usage": {
"input_tokens": 412,
"cache_read_input_tokens": 0,
"output_tokens": 531,
"iterations": [
{ "type": "message", "input_tokens": 412, "output_tokens": 89 },
{ "type": "advisor_message", "model": "claude-fable-5",
"input_tokens": 823, "output_tokens": 1612 },
{ "type": "message", "input_tokens": 1348, "cache_read_input_tokens": 412,
"output_tokens": 442 }
]
}
}
advisor_message로 태그된 iteration은 자문 모델의 요율로, message로 태그된 iteration은 실행자의 요율로 과금됩니다. 최상위 필드의 집계 규칙 또한 비대칭적입니다 — 최상위 output_tokens는 모든 실행자 iteration을 합산하지만, 최상위 input_tokens와 cache_read_input_tokens는 첫 번째 실행자 iteration만을 반영합니다(이후 실행자 iteration의 입력에는 이전 출력 토큰이 포함되어 있어 다시 합산하면 이중 계산이 되기 때문입니다).
- 비용을 usage.input_tokens * exec_input_price + usage.output_tokens * exec_output_price로 계산한다면, advisor의 전체 지출만큼 조용히 과소 보고됩니다 — advisor 호출은 일반적으로 thinking을 포함해 총 1,400~1,800 토큰을 방출하며, 훨씬 높은 토큰당 요율로 과금됩니다.
- advisor 토큰은 실행자에 적용된 어떤 태스크 예산에서도 차감되지 않습니다. task_budget에 절대적 지출 상한을 의존한다면, advisor는 그 바깥에 있습니다.
- Priority Tier는 모델별로 적용됩니다. 실행자에 대한 Priority Tier 약정이 자문 모델까지 확장되지 않습니다. advisor 호출은 조직이 자문 모델에도 약정을 보유한 경우에만 Priority Tier로 실행됩니다.
폭주하는 자문 제한하기 — max_tokens 함정
최상위 max_tokens는 실행자 출력만을 제한합니다. 호출당 advisor의 총 출력(thinking + 텍스트)을 제한하려면 도구 정의의 max_tokens를 설정해야 합니다:
advisor를 호출당 2048 토큰으로 제한
tools = [
{
"type": "advisor_20260301",
"name": "advisor",
"model": "claude-fable-5",
"max_tokens": 2048, # minimum is 1024; setting above the advisor's own output cap returns 400
"max_uses": 5 # optional per-request cap; extra calls return error_code max_uses_exceeded
}
]Anthropic의 자체 하드 리즈닝 벤치마크(구성당 n=40)는 실질적인 시작점으로 다음 수치를 보고합니다:
도구의 max_tokens | 평균 advisor 출력 | 잘린 호출 |
|---|---|---|
| 미설정 | 어려운 태스크에서 ~10k+ 토큰 | 0% |
| 2048 (권장) | 미설정 대비 ~7배 작음 | ~0% |
| 1024 (최소) | 미설정 대비 ~10배 작음 | ~10% |
해당 샘플 크기에서 세 구성 간 정확도 차이는 노이즈 수준이었습니다. advisor가 상한에 도달하면 결과 블록에 stop_reason: "max_tokens"가 실리고, 또한 Anthropic이 조언 텍스트에 [Advisor output truncated at max_tokens=2048.](실제 상한값을 명명)을 덧붙여 실행자가 자신의 컨텍스트에서 절단을 볼 수 있도록 합니다. 두 신호 모두 도구 정의에 max_tokens를 설정한 경우에만 나타납니다 — 생략하면 둘 다 얻을 수 없습니다.
모두가 놓치는 프롬프트 캐싱 계층
advisor 주변에는 두 개의 독립적인 캐싱 계층이 있으며, 어느 하나라도 잘못 설정하면 조용한 비용 회귀가 발생합니다.
- advisor_tool_result 블록은 다른 콘텐츠 블록과 마찬가지로 캐시 가능합니다. 후속 턴에서 그 뒤에 놓인 cache_control 브레이크포인트는 정상적으로 히트합니다. 클라이언트가 텍스트를 받았든 encrypted_content를 받았든 실행자의 프롬프트는 항상 평문 조언을 포함하므로, 두 결과 변형에 대한 캐싱 동작은 동일합니다.
- 도구 정의에 캐싱을 설정하면 — {"type": "ephemeral", "ttl": "5m" | "1h"} — advisor가 같은 대화 안에서 자체 트랜스크립트를 호출 간에 캐시합니다. N번째 advisor 호출은 (N-1)번째 호출의 프롬프트에 세그먼트 하나가 추가된 것이므로 접두사는 안정적이며, 두 번째 advisor_message부터 cache_read_input_tokens가 0이 아니게 됩니다. Anthropic의 원칙: 3회 이상의 advisor 호출이 예상되는 대화에서만 캐싱을 활성화하세요.
- 컨텍스트 편집 도구 clear_thinking은 keep 값이 'all'이 아닐 때 매 턴 advisor의 인용 트랜스크립트를 이동시켜, advisor 측 캐시 미스를 유발합니다. 확장 thinking이 활성화되어 있고 명시적인 clear_thinking 설정이 없으면, API는 이전 Opus/Sonnet 모델과 모든 Haiku 모델에서 keep: {type: 'thinking_turns', value: 1}을 기본값으로 사용하며, 이것이 그 동작을 촉발합니다. Opus 4.5+와 Sonnet 4.6+에서는 기본값이 keep: 'all'로, 캐시 안전합니다. Haiku 또는 이전 실행자에서 advisor 측 캐싱을 사용한다면 명시적으로 keep: 'all'을 설정하세요.
대화 도중에 caching을 켜고 끄는 것도 캐시를 무효화합니다. 한 번 설정하고 그대로 두세요.
두 가지 결과 변형과 그것들이 모두 괜찮은 이유
성공한 advisor 호출은 두 가지 content 형태 중 하나를 반환합니다:
text필드가 있는advisor_result— 사람이 읽을 수 있는 조언. Claude Opus 4.8과 기타 Opus 5 이전 세대 자문 모델이 반환합니다.encrypted_content필드가 있는advisor_redacted_result— 여러분이 읽을 수 없는 불투명한 blob. Claude Opus 5, Claude Fable 5, Claude Mythos 5 자문 모델이 반환합니다.
어느 것을 받든 후속 턴에서 원문 그대로 왕복 전달하세요. 다음 턴에서 서버가 blob을 복호화하여 평문을 실행자의 프롬프트에 렌더링합니다 — 실행자는 어느 쪽이든 동일한 콘텐츠를 봅니다. 대화 도중에 자문 모델을 전환한다면, content.type으로 분기하여 두 형태를 모두 처리하세요.
- redacted 변형은 제약이 아닙니다 — Opus 5 / Fable 5 / Mythos 5가 내부 추론을 여러분의 클라이언트에 노출하지 않으면서 실행자가 실행할 수 있는 조언을 방출하게 하는 메커니즘입니다. 로깅 계층에서 조언 텍스트가 필요하다면, 자문 모델로 Opus 4.8을 사용하세요.
- 두 변형 모두 도구 정의에 max_tokens를 설정하면 stop_reason을 실어 오고, 설정하지 않으면 생략합니다. 덧붙여진 문자열을 파싱하지 않고 절단을 감지하는 데 사용하세요.
멀티턴: 정확히 한 번 마주치게 될 보이지 않는 400
메시지 이력에 아직 advisor_tool_result 블록이 포함된 상태에서 후속 턴의 tools에서 advisor 도구를 생략하면, API는 400 invalid_request_error를 반환합니다. 두 가지 결과:
- advisor 상태는 끈적끈적합니다. 한 턴이 advisor를 사용했다면, 그 대화의 후속 턴은
tools에 도구를 유지하거나 이력에서 advisor 결과 블록을 제거해야 합니다. 내장된 대화 수준 상한은 없습니다. - 클라이언트 측 대화당 예산을 강제하려면, advisor 호출을 직접 카운트하세요. 상한에 도달하면
tools에서 advisor 도구를 제거하고 동시에 같은 요청에서 메시지 이력의 모든advisor_tool_result블록을 삭제하세요.
또한 마구잡이로 흉내 내지 않도록 이름을 붙여둘 만한 일시정지된 턴 재개 절차가 있습니다: advisor 호출이 아직 보류 중인 상태에서 응답이 stop_reason: "pause_turn"으로 끝날 수 있습니다(응답에는 server_tool_use 블록이 있지만 아직 advisor_tool_result는 없음). 재개하려면 그 어시스턴트 메시지를 server_tool_use 블록을 유지한 채 변경 없이 messages에 추가하고, 동일한 advisor 도구 + 베타 헤더로 재전송하세요. 사용자 메시지도, tool_result도 없습니다. API는 보류 중인 advisor 호출을 실행하고 실행자의 턴을 이어갑니다. 재개된 턴은 다시 일시정지될 수 있습니다 — 그저 반복하세요.
무시해야 할 오류 코드 vs 표면화해야 할 오류 코드
advisor 서브 호출의 실패는 요청을 실패시키지 않습니다. 실행자가 오류를 보고 추가 조언 없이 계속 진행합니다. 전체 오류 표:
error_code | 의미 | 실질적 대응 |
|---|---|---|
max_uses_exceeded | 요청당 max_uses 상한에 도달 | 예상된 것 — 여러분이 설정한 값. 디버그 레벨로 로깅. |
too_many_requests | advisor 서브 인퍼런스가 레이트 리밋됨(직접 호출과 동일한 모델별 버킷에서) | 반복 발생 시 알림 — 자문 모델의 레이트 리밋을 포화시키고 있음 |
overloaded | advisor 서브 인퍼런스가 용량 한계 | 품질이 중요하면 전체 턴을 재시도; 아니면 그냥 넘김 |
prompt_too_long | 트랜스크립트가 advisor의 컨텍스트 윈도우 초과 | 1M 컨텍스트 Opus 5 자문에서는 드묾; 작은 컨텍스트 자문 선택에서 더 가능성 있음 |
execution_time_exceeded | advisor 서브 인퍼런스가 타임아웃 | 도구 정의의 max_tokens를 제한하여 advisor 생성 길이를 줄임 |
unavailable | 그 외 무엇이든 | 일시적인 것으로 처리 |
핵심 비대칭성: 실행자에서의 레이트 리밋은 전체 요청을 HTTP 429로 실패시킵니다. 자문 모델에서의 레이트 리밋은 도구 결과 내부에 나타나고 요청은 여전히 성공합니다.
Claude Code: /advisor, --advisor, 그리고 advisorModel
CLI는 동일한 설정을 조작하는 세 가지 표면을 통해 advisor를 노출합니다:
Claude Code에서 advisor 활성화 — 세 가지 동등한 방법
# 1. Interactive picker or direct assignment (saves to your user settings)
/advisor
/advisor opus
/advisor sonnet
/advisor claude-opus-5 # full model ID also works
# 2. Persistent default in your settings file
# ~/.config/claude/settings.json (or equivalent)
{ "advisorModel": "opus" }
# 3. Per-session flag (overrides advisorModel for that launch, hidden from --help)
claude --advisor opus
# Turn off
/advisor off
# Or disable the tool entirely (all three surfaces become no-ops):
export CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1Claude Code의 메인 모델/자문 모델 페어링 매트릭스는 API 매트릭스의 부분집합입니다 — opus와 sonnet은 Claude Code의 내장 기본 버전으로 해석되며 릴리스에 따라 진화하는 별칭입니다. 주목할 규칙:
- Opus 4.7+ 메인은 Opus 4.7 이상만 자문으로 받아들입니다 — Opus 4.6 또는 Sonnet 5 자문을 가진 Opus 4.7 메인은 거부됩니다.
- Sonnet 5 메인은 Sonnet 4.6을 자문으로 거부합니다 — 하지만 Sonnet 5는 받아들입니다("두 번째 Sonnet이 첫 번째를 읽는" 저렴한 독립 검토).
- 서브에이전트는 구성된 advisor를 상속하며 자체 모델에 대해 동일한 페어링 검사를 적용합니다.
- 세션 도중에 advisor를 활성화하거나 비활성화해도 메인 모델의 프롬프트 캐시가 무효화되지 않습니다 — 모델이나 effort 레벨을 변경하는 것과 달리 그렇습니다. 이것이
/advisor를 태스크 도중에 토글해도 안전한 이유입니다.
호출이 진행 중일 때 트랜스크립트에서 advisor 모델 이름이 있는 Advising 줄을 지켜보세요. Ctrl+O를 눌러 확장하면 전체 안내를 읽을 수 있습니다. Claude는 일반적으로 조언을 따르지만 자체 증거가 특정 주장과 모순될 때는 조정합니다(시도 시 단계가 실패, 파일 내용이 조언과 모순) — 무조건 따르는 대신 충돌을 표면화합니다.
Anthropic이 실제로 배포하는 두 가지 프로덕션 프롬프트 패턴
공식 문서에는 Anthropic이 대규모로 테스트한 두 개의 시스템 프롬프트가 포함되어 있습니다. 복사할 가치가 있는데, "advisor가 무엇을 할지 안다"는 것은 기본값이 아니기 때문입니다 — 실행자는 언제 advisor를 호출할지에 대한 명시적 안내가 필요하고, advisor는 2인칭으로 작성된 프롬프트에서 이득을 봅니다(시스템 프롬프트를 인용된 컨텍스트로 보므로 "the executor is..."보다 "you are..."이 더 안정적으로 전달됩니다).
코딩 태스크용 제안 시스템 프롬프트 (Sonnet/Opus 실행자)
You have access to an advisor tool that consults a stronger model for strategic guidance. Call it when the plan matters more than the code: - Before committing to an approach on a non-trivial task. - When stuck — errors recurring, approach not converging, results that don't fit. - Before declaring the task complete, to independently check the work. Do NOT call it for routine turns where the next step is obvious. The advisor sees the full transcript, so state the specific decision you want reviewed in the turn where you invoke it.
Haiku 실행자를 위해 Anthropic은 더 많은 advisor 호출을 장려하는 약간 조정된 변형을 배포합니다(Haiku는 기본적으로 자문을 덜 구하는 경향):
Haiku 실행자용 대체 시스템 프롬프트
You have access to an advisor tool. Consult it whenever a decision requires judgment beyond mechanical execution: - Before committing to a non-trivial approach. - When stuck -- errors recurring, approach not converging, results that don't fit. - Before declaring the task complete. - When the user's request contains ambiguity you cannot resolve from context. Bias toward calling the advisor rather than guessing. The cost of a consult is small compared to the cost of a wrong direction on a long task.
프롬프팅을 통해 advisor 출력 길이를 다듬으려면(도구의 max_tokens의 대안 또는 보완), Anthropic이 테스트한 배치는 사용자 메시지의 한 줄입니다 — 시스템 프롬프트가 아닙니다 — advisor가 둘 다 인용된 것으로 보지만, 그것을 직접 지칭하는 사용자 메시지 지시가 3인칭 시스템 프롬프트보다 더 안정적으로 따라지기 때문입니다. 예: Advisor: keep guidance to 3-5 sentences.
특정 요청에 자문을 강제하려면, tool_choice를 {"type": "tool", "name": "advisor"}로 설정하세요. 한 가지 비호환성: 강제 도구 사용은 수동 확장 thinking(thinking: {type: "enabled"})과 결합할 수 없습니다 — 둘 다 활성화하면 API가 400 invalid_request_error를 반환합니다. 적응형 thinking은 강제 도구 사용을 지원합니다.
advisor가 대안을 이기는 곳 — 그리고 지는 곳
Claude Code에서 모델 강점을 결합하는 방법은 네 가지가 있습니다. 더 강한 모델이 언제 실행되기를 원하는지에 따라 선택하세요.
| 접근 방식 | 더 강한 모델이 실행되는 시점 | 시작하는 주체 |
|---|---|---|
| advisor 도구 | 결정 지점에서, 태스크 도중 | Claude가 안내가 필요할 때 호출 |
| opusplan | plan 모드 동안, 그 후 실행을 위해 Sonnet으로 전환 | 여러분이 plan 모드에 진입 |
model이 설정된 서브에이전트 | 위임된 서브태스크 전체 동안 | Claude가 위임하거나, 여러분이 호출 |
/model 전환 | 이후 모든 턴 동안 | 여러분이 수동으로 모델 전환 |
강한 모델을 Claude의 재량으로, 요구 시 실행하는 유일한 방식이 advisor입니다. opusplan은 결정론적(plan 모드 진입)이지만 계획으로 범위가 한정됩니다. 서브에이전트는 전체 서브태스크에 강한 모델을 커밋합니다. /model은 큰 망치입니다.
플랫폼 가용성 (당신이 걸려 넘어질 그 부분)
advisor 도구는 Anthropic API와 AWS의 Claude Platform에서 베타로 제공됩니다. 2026년 8월 현재 Amazon Bedrock, Google Cloud Vertex 또는 Microsoft Foundry에서는 사용할 수 없습니다. ANTHROPIC_BASE_URL로 구성된 LLM 게이트웨이를 통해서는 게이트웨이가 요청을 온전히 전달하는지에 따라 가용성이 달라집니다.
Anthropic 아웃에이지에서 살아남기 위해 Bedrock 또는 Vertex를 통해 요청을 통과시키는 멀티클라우드라면, 오늘 advisor는 그 페일오버 경로의 일부가 아닙니다.
Check yourself
0/5출처 및 추가 읽기
- Anthropic — Advisor tool (Claude API 문서) — 주요 출처; 이 페이지 전반에 걸쳐 인용된 필드 레퍼런스, 페어링 매트릭스, 스트리밍 동작, Anthropic이 테스트한 프롬프트와 절단 벤치마크
- Anthropic — Escalate hard decisions with the advisor tool (Claude Code 문서) — CLI 관련 표면:
/advisor,advisorModel,--advisor, Fable-5-자문-비활성화 롤아웃, 페어링 부분집합 - Anthropic — Server tools reference —
server_tool_use블록 형태와 advisor가 상속하는 "한 턴에서 서버 도구와 클라이언트 도구 혼합" 동작 - Anthropic — Prompt caching — 실행자 측
advisor_tool_result블록과 advisor 측caching옵트인 모두에 적용되는 캐시 시맨틱 - Anthropic — Context editing — 이전 실행자에서 advisor 측 캐싱을 조용히 죽이는
clear_thinking기본값 - AILmanac — Effort 튜닝: 5 레벨, 모델 기본값, 그리고 캐시 함정 — advisor와 짝이 되는 자매 기능; 둘 다 토큰 계산을 바꾸는 모델별 표면 노브
- AILmanac — 모델 선택하기 — 어떤 실행자/자문 페어가 유효한지 결정하는 모델 티어
- Anthropic Blog — The advisor strategy — Anthropic 블로그의 "빠른 실행자와 더 강한 자문이 왜 작동하는가" 프레이밍