에이전트용 Claude Fable 5: Tool call 거부와 GLM 5.2 대비 비용

평가에서 Claude Fable 5는 코딩 에이전트의 44개 turn 중 11개에서 tool call 도중 요청을 거부했다. 설정 기본값 수정처럼 평범한 작업에서도 발생했다. Tool 인자를 생성하다가 stop_reason: "refusal"로 중단되지만, 잘린 인자는 여전히 유효한 JSON으로 파싱된다. stop reason을 확인하지 않고 tool call을 실행하는 에이전트 루프라면 미완성 파일을 그대로 디스크에 쓴다. Fable 5를 에이전트에 적용할 때는 가격보다 이 동작부터 처리해야 한다.

TL;DR

• Claude Fable 5는 설정 기본값 수정이나 회의실 예약 같은 평범한 에이전트 작업에서도 tool call 도중 stop_reason: "refusal"을 반환했다. 잘린 write_file 인자도 파싱됐기 때문에 stop reason을 확인하지 않는 루프는 덜 작성된 파일을 실행한다.
• Fable 5의 thinking은 adaptive 방식이며 끌 수 없다. enabled와 disabled 모두 거부되고, output_config.effort로만 조절할 수 있다.
• Fable 5의 추가 비용은 워크로드 형태에 따라 달라진다. 4 turn 코딩 작업은 glm-5.2의 $0.003에 비해 $0.045로 15배였지만, warm batch 작업에서는 sonnet-5의 5배에 그쳤다.
• Fable 5는 30일간의 데이터 보관이 필수다.

아래 결과는 모두 2026-07-05에 Synthorai gateway와 소규모 시나리오 harness로 측정했다. Tool을 사용하는 코딩 루프, RAG 질의응답, tool 중심 orchestration, batch classification, 15 turn 대화까지 5가지 에이전트 워크로드 형태를 사용했다. claude-fable-5, claude-opus-4-8, claude-sonnet-5, glm-5.2를 대상으로 실행했으며, 편차가 중요한 작업은 각각 3회 측정했다. 작업은 의도적으로 단순하게 구성했다. 통과율은 정상 동작을 확인하기 위한 기준일 뿐, 성능 benchmark가 아니다. 비용은 gateway에서 청구한 usage.cost다.

Tool call을 실행하기 전에 stop_reason 확인하기

문서에 경고가 없지만 상태를 망가뜨릴 수 있는 실패 유형이다. 에이전트가 app.py를 읽고 수정 사항을 쓰기로 결정한 뒤 write_file call을 생성하기 시작한다. 파일 내용을 생성하던 중 stream이 멈춘다.

{
  "stop_reason": "refusal",
  "content": [{
    "type": "tool_use",
    "name": "write_file",
    "input": {
      "path": "app.py",
      "content": "DEFAULTS = {\n    \"timeout_s\": 30,\n    "
    }
  }]
}

input 객체는 완전하며 유효한 JSON으로 파싱된다. 조기에 중단됐다는 표시는 객체 어디에도 없다. 루프가 “tool call을 받으면 실행한다”는 방식이라면 app.py는 dictionary 중간에서 끝나는 38자짜리 조각으로 덮어써진다. 더 이상 Python으로 파싱되지 않는다. 다음 turn도 거부되므로 workspace가 손상된 상태로 루프가 종료된다.

데이터에서 확인한 사실은 세 가지다.

• 평범한 작업에서도 발생한다. 거부가 발생한 작업은 설정 조회의 KeyError 수정, slugify 함수 구현, 회의실 예약, draft invoice 생성이었다. 이중 용도나 민감한 작업은 없었다.
• 무작위 현상이 아니라 반복된다. 코딩 작업 하나는 streaming과 non-streaming 모두에서 3회 전부 거부됐다. 반면 다른 작업에서는 한 번도 발생하지 않았다. 조건별로 Fable 5의 단순 코딩 episode 통과율은 58-75%였고, claude-opus-4-8, claude-sonnet-5, glm-5.2는 100%였다. 모든 실패 원인은 잘못된 코드가 아니라 거부였다.
• 대화에 거부가 한 번 포함되면 해당 episode는 끝난다. 후속 turn은 빈 출력과 함께 stop_reason: "refusal"을 반환했다. 같은 context에서 재시도해도 복구되지 않았다.

원인은 작업 내용이 아니며, 데이터에서도 분명하게 드러난다. 매번 거부된 작업은 설정 dictionary에서 발생하는 KeyError를 고치는 9줄짜리 수정이었다. 자격 증명도 exploit도 없었다. 반면 batch 시나리오는 cryptomining, 유출된 Stripe key, phishing page 관련 지원 ticket을 거부 없이 분류했다. RAG 시나리오도 AES-256-GCM secret과 침해 대응 절차로 가득한 문서를 대상으로 문제없이 답했다. 모든 거부는 여러 turn에 걸쳐 tool을 실행하는 두 시나리오에서 발생했다. 내용이 더 무거웠던 세 가지 single-shot 시나리오에서는 단 한 번도 거부되지 않았다. 패턴은 단어가 아니라 에이전트 루프의 형태와 관련돼 있으므로 입력을 정제해도 막을 수 없다.

Tool 실행 단계 전에 다음 한 줄을 추가하면 된다.

if response.stop_reason == "refusal":
    # do NOT execute tool calls from this turn: arguments may be truncated
    raise AgentInterrupted("model refused; restart episode or escalate")

Anthropic 문서에는 동작 방식이 설명돼 있다. 출력 전에 거부되면 빈 content 배열이 반환되며 과금되지 않는다. Streaming 도중 거부되면 이미 streaming된 출력은 과금되며, 부분 출력은 폐기해야 한다. 응답에는 category가 포함된 stop_details 객체도 들어간다. category는 cyber, bio, null 등이며, classifier에 의한 차단과 일반적인 거절을 구분할 수 있다. 하지만 문서에는 위와 같은 tool 사용과의 상호작용이 명시돼 있지 않다. 인자 생성 도중 거부가 발생할 수 있고, 부분 인자만 봐서는 완성된 인자와 구분할 수 없다.

공식 복구 방법도 있다. Claude API에서는 beta fallbacks parameter(betas: ["server-side-fallback-2026-06-01"], fallbacks: [{"model": "claude-opus-4-8"}])를 사용하면 거부된 요청을 같은 call 안에서 fallback model로 다시 실행할 수 있다. 출력 전에 거부됐다면 거부 자체에는 요금이 부과되지 않는다. Amazon Bedrock, Vertex AI, Microsoft Foundry에서는 사용할 수 없으며, 이들 SDK는 대신 client-side fallback middleware를 제공한다. 어떤 방식을 사용하든 위 guard가 먼저다. stop reason이 거부인 turn의 tool call은 절대 실행하면 안 된다.

5가지 에이전트 형태별 비용

동일한 prompt를 같은 날 실행한 완료 단위별 비용 중앙값이다. 단위는 task, query, item 또는 전체 conversation이다.

개별 수치보다 중요한 해석은 두 가지다.

• 가장 저렴한 model은 워크로드 형태에 따라 달라진다. 루프와 긴 대화에서는 glm-5.2가 가장 저렴하다. 하지만 이 조합에서 가장 저렴한 batch classifier는 claude-sonnet-5다. Scaffold prompt가 warm 상태가 되면 cache read 비율이 97%에 이르고, 출시 기념 가격이 적용돼 glm-5.2보다 저렴해진다.
• Fable 5의 추가 비용도 워크로드 형태에 따라 달라진다. 코딩 루프에서는 glm-5.2의 15배, 대화에서는 11배다. Prompt 대부분을 caching으로 처리하는 warm batch item에서는 sonnet-5의 5배다.

나머지 비용 문제는 이 수치를 제어하는 방법, 그리고 조용히 비용을 다시 끌어올리는 두 가지 요인에 관한 내용이다.

에이전트 비용 낮추기

가장 효과적인 방법은 caching이며, Fable 5의 동작 규칙은 그대로다. 에이전트 데이터에서도 효과가 확인됐다. cache_control marker를 제거하자 같은 코딩 작업의 비용은 2.0배, warm batch item은 6.8배로 늘었다. opus-4-8에서는 각각 3.8배와 6.9배였다. 루프에서 sliding-marker 패턴은 단순한 최적화가 아니다. 감당 가능한 비용을 만들 수 있는지를 좌우한다.

두 번째 방법은 prompt 순서이며, 실행한 모든 model에서 같은 결과가 나왔다. Query별 context보다 안정적인 규칙을 앞에 배치하면 반대 순서보다 네 model 모두에서 RAG query 비용이 26-37% 낮아졌다. Claude 계열에서는 순서가 잘못될 경우 call마다 1.25배의 cache write 추가 비용까지 발생한다. 동작 원리는 LangChain caching 글에 설명돼 있다. 여기서 측정한 수치는 Fable 5에도 동일하게 적용된다는 점을 확인해 준다.

Fable 5에는 자체적으로 사용할 수 있는 방법도 두 가지 추가됐다. 첫 번째는 cache 적용 최소 기준이 Opus 4.8의 4,096에서 절반인 2,048 token으로 낮아졌다는 점이다. 사소해 보이지만 에이전트의 비용 절감 구조를 생각하면 중요하다. 반복되는 scaffold, 즉 system prompt, tool definition, sliding conversation prefix가 cache 대상이며, 최소 기준을 넘어야 caching된다. Turn별 prefix가 2,048에서 4,096 token 사이인 tool 중심 에이전트는 Opus 4.8에서 caching을 전혀 활용하지 못했다. Fable 5에서는 caching이 시작되므로 전체 가격으로 처리되던 prefix가 이후 모든 turn에서 대략 정상 가격의 10%에 해당하는 cache read로 바뀐다. 반대 상황도 있다. 기존 4,096 token 기준을 넘기려고 padding한 prefix에는 이제 불필요한 내용이 남아 있을 수 있다. Fable 5에서는 할인 적용 시점이 빨라졌으므로 추측하지 말고 실제 응답의 cache_read_input_tokens를 확인해야 한다.

두 번째는 task budget(beta, header task-budgets-2026-03-13)이다. 이 비교에서 계속 드러나는 문제를 직접 해결한다. Fable 5 루프는 비용이 빠르게 늘며 max_tokens로는 막을 수 없다. max_tokens는 model이 알 수 없는 응답별 hard cap이다. Model은 공간이 무제한인 것처럼 계획하다가 추론 도중 잘린다. Task budget은 다르게 동작한다. 루프에 최소 20,000인 token 상한을 지정하면 model은 남은 budget을 countdown으로 확인하며 속도를 조절한다. 갑자기 잘리지 않고 자연스럽게 작업을 마무리한다. 각 요청마다 다시 보내는 전체 history가 아니라, model이 생성한 token과 해당 turn에서 읽은 tool 결과를 합산한다. 코딩 루프의 turn 비용이 glm-5.2의 15배인 model에서는 model이 스스로 맞추는 budget이 가장 저렴하게 추가할 수 있는 guardrail이다.

문서에서 알려주지 않는 두 가지 비용 변수

위 설정을 적용해도 문서에 설명되지 않은 두 가지 요인이 비용을 예상과 다른 방향으로 움직였다.

“Low” effort가 더 저렴하지 않았다. Fable 5의 thinking 깊이는 output_config.effort로 제어한다. 직관적으로는 low가 더 저렴할 것 같지만 실제 결과는 달랐다. effort: "low"를 설정한 코딩 루프는 task당 $0.0478이었고, 기본값은 $0.0451이었다. 출력 token도 줄지 않고 오히려 늘었다. GLM 5.2에서도 같은 패턴이 나타났다. Effort 이름과 token 수가 일치하지 않는다. 두 model 계열 모두에서 “low”가 “적은 비용”을 뜻한다고 가정하지 말고 실제 워크로드로 측정해야 한다. 예측이 어려운 이유 중 하나는 adaptive thinking이 출력 token에서 차지하는 비중이 크게 달라지기 때문이다. 같은 model을 같은 날 실행해도 코딩 루프에서는 2%, RAG 응답에서는 30%, batch classification에서는 52%였다. 출력 token budget은 model별이 아니라 워크로드 형태별로 잡아야 한다.

reasoning_content를 다시 보내면 안 된다. OpenAI-compatible model에서 reasoning field는 대화 history가 아니다. DeepSeek API에서는 반드시 제거해야 한다. GLM 5.2에서는 다시 보내는 것이 허용되지만 과금된다. Message history에 포함해 다시 전송했을 때 GLM 루프 비용이 약 28% 늘었고, 해당 내용을 제거하자 정상화됐다. Anthropic 자체 thinking block은 다르게 동작한다. 같은 model에서는 변경 없이 다시 보내야 한다. 다만 Fable 5의 thinking block을 다른 model로 보낼 경우, 예를 들어 Opus로 fallback하면 prompt에서 자동으로 제외되고 과금되지 않는다. 별도로 제거할 내용이 없다.

Request interface에서 달라진 점

Fable 5는 request interface 대부분을 Opus 4.7/4.8 및 Sonnet 5와 공유한다. 문서상 제거된 항목은 다음과 같다.

• thinking: {type: "enabled", budget_tokens: N}은 400을 반환한다. Claude 3.7 Sonnet부터 4.5 계열까지 사용하던 token budget 방식의 extended thinking은 4.7+ 계열에서 중단되고 adaptive thinking으로 대체됐다.
• thinking: {type: "disabled"}도 400을 반환하며, 이 동작은 Fable 5에만 해당한다. Opus 4.7/4.8과 Sonnet 5에서는 thinking을 끌 수 있지만 Fable 5에서는 불가능하다.
• temperature, top_p, top_k를 기본값이 아닌 값으로 지정하면 거부된다.
• Assistant message prefill, 즉 마지막에 assistant turn을 넣으면 400을 반환한다.

기존 request를 옮길 때 가장 자주 문제가 되는 부분은 temperature/top_p/top_k와 prefill 제거다. Thinking과 데이터 보관 정책 변경은 위 내용과 데이터 30일 보관 글에서 다룬다.

결론

에이전트에서 Fable 5를 사용할 때는 비용보다 먼저 엔지니어링 문제를 해결해야 한다. Tool call을 실행하기 전에 stop_reason: "refusal"을 처리하지 않으면 설정 수정처럼 단순한 작업에서도 잘린 write가 상태를 손상시킨다. 그다음에는 비용 구조를 조정해야 한다. 가장 효과적인 방법은 caching이다. Cache 적용 기준이 2,048 token으로 낮아졌으므로 prefix를 다시 점검해야 한다. Task budget은 이 비교에서 turn당 비용이 가장 높은 루프가 과도한 비용을 발생시키는 것을 막는다. effort: "low"는 이름과 달리 할인 옵션이 아니다. Budget도 워크로드 형태별로 잡아야 한다. 같은 model이어도 코딩 루프에서는 glm-5.2의 15배, warm batch 작업에서는 sonnet-5의 5배다. 이 결과만으로 사용 여부를 결정할 수는 없다. 다만 기본값은 중립적이지 않으며, 비용과 실패 유형 모두 에이전트의 형태에 따라 달라진다.

FAQ

Fable 5는 tool call을 자주 거부하는가? 특정 작업에 집중됐다. 설정 수정 작업 하나는 실행할 때마다 거부됐지만 다른 작업에서는 한 번도 발생하지 않았다. 같은 작업에서 streaming과 non-streaming call 모두 동일하게 재현됐다. 재시도로 넘길 수 있는 드문 일시적 오류가 아니다. 실제 비율은 워크로드에 따라 달라진다. 대응 방법은 동일하다. Tool call을 실행하기 전에 stop_reason을 확인해야 한다.

Fable 5의 thinking을 끌 수 있는가? 불가능하다. thinking.type.disabled와 enabled 모두 거부된다. Thinking은 기본적으로 adaptive 방식이며 output_config.effort로만 제어할 수 있다. 측정한 루프에서는 low effort가 비용을 줄이지 못했다.

Fable 5가 저렴한 선택지가 되는 경우가 있는가? 이 조합에서는 없었다. 추가 비용이 가장 작은 경우는 warm cache 비중이 높은 batch 작업이었다. Warm cache가 prompt 대부분을 처리할 때 sonnet-5의 약 5배였다. 루프와 긴 대화에서는 측정한 model 중 가장 비쌌다.

검증: 모든 수치는 2026-07-05에 https://synthorai.io/를 대상으로 측정했다. Claude 계열에는 Anthropic-native /v1/messages, glm-5.2에는 /v1/chat/completions를 사용했다. 5가지 시나리오 형태에서 총 505개 episode와 1,022개 call을 실행했으며, 편차가 중요한 작업은 각각 3회 측정했다. 비용은 gateway가 보고한 usage.cost이며 중앙값을 표시했다. 작업은 의도적으로 단순하게 구성했으므로 통과율은 정상 동작 확인용 기준이지 성능 benchmark가 아니다. 직접 측정하지 않은 성능 주장은 공개하지 않는다. 거부 동작은 streaming과 non-streaming mode 모두에서 재현됐다. 실제 수치는 prompt, region, load에 따라 달라질 수 있다.

← 블로그로 돌아가기