Fable 5를 비용 효율적으로 쓰는 방법에 관심이 큽니다. 에이전트 하네스는 언제 최첨단 지능을 써야 하는지 점점 더 잘 판단하게 될 것입니다. Fable 5를 언제, 어떻게 써야 하는지 더 잘 이해하려고 진행한 몇 가지 실험을 공유합니다.
작업의 형태
많은 작업은 토큰을 처리하는 구간마다 필요한 지능 수준이 다릅니다. 하네스는 이를 알아보고 언제 Fable 5를 쓸지 고를 수 있습니다. 이미 몇 가지 방식이 나타났지만, 앞으로 더 많이 나올 것입니다.
- Fable 5를 값싼 작업자에게 일을 나눠 주는 오케스트레이터로 씁니다.
- Fable 5를 값싼 실행자가 조언을 구하는 조언자로 씁니다.
- Fable 5를 작업 결과를 확인하는 검증자로 씁니다. 예를 들어 /goal이나 Outcomes 루프에 넣습니다.
예를 들어 @mitchellh는 오케스트레이터와 검증자를 함께 쓰는 방식을 짚었습니다.
저는 이를 Parameter Golf에서 살펴봤습니다. Parameter Golf는 @karpathy의 autoresearch와 비슷한 기계 학습 공학 과제입니다. 에이전트가 학습 코드를 고치고, 학습을 시작하고, 결과를 본 뒤 다음 실험을 정합니다.
목표는 H100 8개에서 10분 안에 16MB 결과물에 들어가는 가장 좋은 모델을 학습하는 것입니다. 저는 전에 Fable 5가 이 과제를 잘 푼다는 것을 보여줬습니다. 그래서 Fable 5는 실험 설계에만 쓰고 Sonnet 5가 구현에 필요한 토큰을 맡게 할 수 있는지 알아보고 싶었습니다.
Claude Managed Agents에 @modal에서 직접 운영하는 H100 8개짜리 샌드박스를 연결했습니다. Fable 5를 호출할 수 있는 Sonnet 5 실행자도 붙였습니다. Sonnet 5에게 첫 계획을 세울 때 Fable 5의 조언을 구하고, 실험 20번을 진행하는 동안 두 지점에서 다시 조언을 구하라고 지시했습니다.
아래 결과는 세 가지 구성의 검증 손실을 바이트당 비트로 보여줍니다. 낮을수록 좋습니다. Fable 5와 Sonnet 5를 함께 쓰자 Fable 5만 썼을 때 얻은 개선의 약 90%를 토큰 비용 약 34%로 달성했습니다.
처음에 조언을 받은 단계가 주된 이점은 아니었습니다. Fable 5가 처음 매긴 순위는 실제로 효과가 있었던 결과와 오히려 반대였습니다.
가치는 중간에 둔 조언 확인 지점에서 나왔습니다. Sonnet 5는 한 걸음 물러나 우선순위를 다시 매기지 못한 채 작은 개선만 좇는 경향이 있습니다. Fable 5는 확인 지점마다 방향을 잡고 우선순위를 다시 정해 줬습니다.
이 사례에서는 판단을 어디에 배치하느냐가 중요했습니다. 처음에 계획만 세우는 것으로는 부족했습니다. 작업을 진행하는 동안 정해진 지점마다 Fable 5를 조언자로 넣자 더 유망한 방향으로 이끌 수 있었습니다.
돌이켜 보면 작업의 형태와 맞아떨어집니다. 이런 실험은 탐색적이며 결과가 나올 때마다 다음에 시도할 가치가 있는 일이 달라집니다. 판단을 앞에 몰아넣지 말고 작업 전체에 흩어 놓아야 합니다.
위임 비용
하네스가 작업에 필요한 지능의 비대칭성을 활용할 수 있어도, 일을 넘기는 것이 언제나 이득은 아닙니다. 위임에는 조율 비용이 들기 때문에 그냥 직접 처리하는 때도 있습니다.
@brada와 저는 Fable 5로 BrowseComp를 시험하면서 이를 확인했습니다. BrowseComp는 여러 조건을 만족해야 하는 웹 검색 평가입니다. Fable 5가 계획을 세우고 Sonnet 5 작업자에게 일을 나누기 좋은 형태입니다. 작업자들은 조건으로 답 하나를 특정할 때까지 검색하고, 페이지를 열고, 정보를 교차 확인합니다.
문제마다 읽어야 할 토큰이 약 37만 개인 쉬운 하위 집합 BrowseComp200에서는 Fable 5만 쓰는 편이 Fable 5와 Sonnet 5를 섞는 것보다 저렴했습니다. 오케스트레이션은 성능을 높이지 못하면서 비용만 60% 늘렸습니다.
하지만 문제마다 읽어야 할 토큰이 약 3,100만 개인 전체 BrowseComp 평가에서는 오케스트레이션이 이득이었습니다. Fable 5 오케스트레이터와 Sonnet 5 작업자를 함께 쓰자 Fable 5만 썼을 때의 점수 96%를 비용 46%로 얻었습니다.
Deep Dive: 위임 비용은 택시 기본요금과 비슷합니다. 리더가 지시를 쓰고 결과를 읽는 조율 비용은 작업 크기와 상관없이 거의 고정으로 듭니다. 그래서 읽을 양이 적으면 아낀 비용보다 기본요금이 큽니다. 읽을 양이 많으면 같은 기본요금으로 더 많은 토큰을 값싼 작업자에게 넘겨 이득을 볼 수 있습니다.
값싼 작업자에게 위임해 아낀 토큰 비용은 조율 비용보다 커야 합니다. 이 사례에서 조율 비용은 몇 부분으로 나뉩니다.
- 경계 중복: 모델 사이를 오가는 모든 토큰에는 적어도 두 번 비용이 붙습니다. 리더가 업무 내용을 쓰면 작업자가 읽습니다. 작업자가 보고서를 쓰면 리더가 읽습니다.
- 작업 분산 중복: 많은 하네스에서는 작업자끼리 소통하지 않습니다. 여러 작업자가 조사할 내용을 일부씩 겹쳐서 처리합니다. @walden_yan은 지난해 이 문제를 다룬 좋은 글을 썼습니다.
따라서 값싼 작업자가 아끼는 비용이 위임할 때마다 거의 고정으로 드는 조율 비용보다 커야 합니다. 이 사례에서 작업자를 쓸 때 얻는 이익은 각 작업자가 맡는 토큰 수에 따라 커집니다.
비용 효율적인 하네스
저는 여러 작업에 맞춰 비용 효율적인 하네스를 만들 때 Fable 5에 다음과 같이 안내합니다. 이런 안내를 주면 Fable 5는 자기 지능을 언제, 어떻게 써야 하는지 잘 이해합니다.
1. 작업의 형태를 살핍니다. 작업 전체에서 필요한 지능 수준을 따져 봅니다. Parameter Golf처럼 판단이 작업 전체에 흩어져 있다면 값싼 실행자와 Fable 5 조언자를 함께 쓰는 것이 좋습니다. 판단이 처음에 필요하거나 결과를 검토할 때 필요하다면 Fable 5를 오케스트레이터나 검증자로 쓸 수 있습니다.
2. 위임 판단 기준을 씁니다. 때로는 Claude에게 어떤 작업자에게 맡길지 판단할 사전 기준을 줄 수 있습니다. @theo는 모델의 "취향"과 "지능"에 따라 순위를 매긴 사례를 보여줬습니다. 하네스는 이런 기준을 보고 각 모델을 언제 투입할지 정할 수 있습니다.
3. 조율 비용을 따집니다. 위임에는 비용이 듭니다. BrowseComp에서 본 것처럼 조율 비용을 상쇄할 만큼 많은 토큰을 맡겨야 합니다. Fable 5는 토큰당 가격이 더 낮은 모델보다 토큰을 더 효율적으로 쓸 수 있습니다. 따라서 위임의 이점을 신중하게 따져야 합니다.
4. 프롬프트 캐시를 보장합니다. 모델은 저마다 프롬프트 캐시를 유지합니다. 이 부분을 잘못 다루면 위임 비용이 쉽게 크게 늘어납니다. @cognition이 지적했듯이, 하위 에이전트는 여러 번 호출해도 같은 프롬프트 캐시를 유지해야 합니다. 요청할 때마다 새 작업자를 만들고 문맥 쓰기 비용을 다시 내지 말아야 합니다. 같은 작업자에게 호출을 보내 캐시를 쌓습니다. 제 실험에서 Claude Managed Agents의 하위 에이전트는 이를 기본으로 지원했습니다. 하지만 프롬프트 캐시 적중률이 낮아서 토큰당 가격이 낮은 작업자를 쓴 이점이 사라지는 사례도 봤습니다.
@trq212가 공유했듯이, Claude는 작업에 맞는 하네스를 그 자리에서 직접 만들 수 있습니다. 이 글에서 살펴본 요소를 활용하면 Claude가 최첨단 지능을 골라 쓰는 비용 효율적인 하네스를 만드는 데 도움이 됩니다.
Deep Dive
2026-07-16
비싼 판단은 방향을 바꿀 순간에 쓴다
처음에는 값싼 모델이 일을 제대로 처리하지 못해서 중간에 Fable 5가 필요하다고 이해하기 쉽습니다. 더 정확한 문제는 실행 실패가 아니라 방향 수정 실패입니다. Sonnet 5는 구현을 계속할 수 있지만 작은 개선만 좇다가 한 걸음 물러서 우선순위를 바꾸지 못할 수 있습니다. 따라서 비싼 모델을 내내 켜 두기보다 결과가 다음 선택을 바꾸는 확인 지점에 넣습니다.
위임으로 아끼는 비용이 조율 비용을 넘어야 한다
위임 자체가 비용을 줄이는 것은 아닙니다. 리더와 작업자가 지시와 결과를 주고받는 비용은 택시 기본요금처럼 먼저 듭니다. 짧은 작업은 아낀 토큰보다 이 기본요금이 크므로 직접 처리하는 편이 쌍니다. 긴 작업은 조율 비용은 거의 그대로인 채 값싼 작업자가 더 많은 토큰을 맡으므로 비용 절감 효과가 커집니다.
캐시가 작업자의 실제 가격을 결정한다
같은 작업자를 계속 호출하면 이미 읽은 문맥이 프롬프트 캐시에 남습니다. 요청할 때마다 새 작업자를 만들면 같은 문맥을 다시 쓰고 읽는 비용을 내야 합니다. 그러면 토큰당 가격이 낮은 모델을 써도 비용 이점이 사라질 수 있습니다.
Key Insight
비용 효율적인 하네스는 비싼 모델을 덜 쓰는 구성이 아닙니다. 비싼 판단을 방향 전환 지점에 배치하고 값싼 작업자가 캐시를 유지하면서 충분한 토큰을 처리하게 만드는 구성입니다.