Fable 5가 Opus 4.8보다 저렴해지는 이유

Cognition(Devin)이 Fable 5와 Opus 4.8을 각각 리드 모델로, 같은 저가 사이드킥과 짝지어 FrontierCode 1.1에서 3,000세션을 돌린 실험. 토큰당 2배 비싼 Fable 5가 위임 방식 덕분에 실제 운영 비용은 더 낮았다.

사이드킥이란

Devin Fusion 아키텍처에서 리드 모델에 딸린 값싸고 빠른 서브 에이전트다.

역할 분담: 리드 모델(Fable 5 또는 Opus 4.8)이 세션의 주체로서 사용자와 대화하고, 계획을 세우고, 결과를 리뷰하고, 커밋까지 담당한다. 사이드킥은 리드가 맡긴 작업만 수행하는 보조 에이전트다.
작동 방식: 리드가 자연어로 된 핸드오프 브리프(작업 지시서)를 작성해 넘기면, 사이드킥은 자기 자신의 독립된 컨텍스트 안에서 그 작업(주로 구현+테스트+린트)을 수행하고 결과를 리드에게 보고한다. 리드는 그 결과를 검토하고 다음 단계를 결정한다.
가격 특성: 사이드킥은 리드 모델보다 훨씬 저렴한 모델로 구동된다. 이번 실험에서는 Fable/Opus 두 리드 모두 동일한 사이드킥을 붙여 비교했다.
비용에 미친 영향: 실험의 핵심은 사이드킥에게 “얼마나 일찍, 얼마나 잘” 위임하느냐가 전체 비용을 좌우했다는 점이다(아래 섹션 참고).

핵심 결과

리드 모델 단독으로 돌리면 직관대로: Fable이 Opus보다 점수도 높고(60.8 vs 55.4) 비용도 높다(더 비쌈). 그런데 같은 사이드킥을 붙이면 순서가 뒤집힌다.

구성	점수	세션당 비용(평균)
Fable 5 (low) + 사이드킥	60.7	$1.86
Opus 4.8 (medium) + 사이드킥	54.6	$2.04
Fable 5 (low) 단독	60.8	$4.03
Opus 4.8 (medium) 단독	55.4	$3.06

Fable + 사이드킥이 Opus + 사이드킥보다 싸면서( $1.86 v s$ 2.04) 점수도 높다(60.7 vs 54.6). Fable 단독 대비로는 비용을 54% 줄이면서 점수는 거의 그대로 유지했다.

왜: 토큰 단가가 아니라 위임 방식

리드/사이드킥 비용 분해:

	리드 $	사이드킥 $	합계	리드 턴 수	리드 입력 토큰(누적)
Fable + 사이드킥	$1.28	$0.58	$1.86	11.5	545k
Opus + 사이드킥	$1.73	$0.31	$2.04	26.5	1,679k

Fable은 사이드킥에 더 많이 쓰지만(+ $0.27) 자기자신에는훨씬덜쓴다 (-$ 0.45). 턴 수는 Opus의 절반 이하, 출력·입력 토큰은 약 1/3. Fable 리드 세션의 81%는 코드를 한 줄도 직접 수정하지 않는다(Opus는 24%). 13%는 파일조차 직접 읽지 않는다.

두 모델 모두 위임 횟수는 비슷하다(세션당 약 3회). 차이는 언제, 무엇을 위임하느냐다.

Fable: 초반에 정찰만 하고 곧바로 구현+테스트+린트 전체를 위임하는 스펙급 브리프를 작성. 이후 diff 검토 한 번, 커밋.
Opus: 20~45턴을 혼자 탐색·설계·구현하다가, 설계가 끝나고 비싼 작업이 다 끝난 뒤 기계적인 마무리만 위임.

Opus에게 더 일찍 위임하도록 강제하면 오히려 성능이 떨어진다 — 언제 위임해도 안전한지 판단하는 것 자체가 능력이라, 강제로 위임시킨다고 그 판단력이 생기지 않는다.

브리프의 성격도 다르다: Opus는 지시(dictate)하고, Fable은 설계 문서를 쓴다. 예시로 든 해시 함수 과제(포인터 길이에 대해 O(1)이어야 함)에서, Opus는 직접 구현하며 그 제약을 어디에도 적어두지 않았고 결국 선형 시간 구현을 만들어 25점을 받았다. Fable은 브리프에 “O(1)이어야 함, 전체 토큰 스캔 금지”를 명시해 위임했고, 사이드킥이 94점짜리 구현을 만들었다. 이 패턴은 과제 전반에서 일관됐다 — Fable의 브리프는 제약·엣지케이스·완료 기준을 명시해 사이드킥이 값싸게 정확히 끝내도록 만든다.

위임 이후의 태도 차이

둘 다 diff를 가볍게 확인하지만, Opus는 거기서 멈추지 않는다. 사이드킥 산출물을 자기 컨텍스트로 2배 더 자주 끌어오고, 리드 단가로 4배 더 많은 수정을 직접 가한다. 극단적으로는 사이드킥 작업을 통째로 되돌리고 손으로 다시 짠다. 이런 불신은 정확도를 높이지도 못한다 — Fable은 diff 검토만으로 버그를 잡아도 재위임으로 처리하는 반면, Opus는 리드가 직접 재작성하는 쪽을 택하는 경우가 많다.

위임이 안 통하는 경우

리드 턴이 몇 개뿐이라 위임할 게 없는 짧은 작업
원인 추적이 하나의 긴 판단 체인으로 이어지는 순차적 디버깅(누적된 컨텍스트 자체가 작업물)

이런 과제에서는 Fable도 거의 위임하지 않는다 — 좋은 브리프를 쓰는 판단력이 곧 “언제 안 써야 하는지”도 안다. 실무에서는 위임(무엇을 리드가 붙들지)과 라우팅(애초에 프론티어 모델을 쓸지)이 별개 층에서 작동한다.

왜 중요한가

2배 비싼 토큰 단가는 비용을 예측하는 데 틀린 숫자였다. 에이전트 비용은 리드 모델이 몇 턴을 쓰는지, 컨텍스트를 얼마나 끌고 다니는지, 무엇보다 스스로 안 하기로 한 일이 얼마나 되는지로 결정된다. 사이드킥 모델이 싸고 좋아질수록 위임 가능한 범위는 넓어지지만, 프론티어 가격을 정당화하는 건 결국 무엇을 만들지·무엇을 제약할지·누가 쓸지를 정하는 판단력이라는 결론.

Devin Fusion 아키텍처: 구조와 원리

이번 실험이 쓴 하네스 자체에 대한 자료(Devin Fusion 공식 블로그)를 추가로 조사한 내용. 원 실험(위 섹션)은 이 하네스 위에서 Fable 5 vs Opus 4.8을 비교한 것이고, 이 섹션은 하네스 자체가 어떻게 동작하는지를 다룬다.

두 개의 병렬 에이전트: “run two parallel agents: one with a frontier model, the other with a more cost-effective ‘sidekick’ model.” 각각 독립된 도구 세트와 컨텍스트 수집 능력을 가진 완전한 에이전트다. 리드가 별도 프로세스를 호출하는 게 아니라, 둘 다 자기 컨텍스트로 파일을 읽고 판단할 수 있다.
편집 권한의 기계적 차단: 리드 에이전트는 계획·리뷰만 하고 파일을 직접 편집할 수 없다. 코드를 바꾸는 유일한 경로는 스펙을 사이드킥에게 넘기는 것뿐이다. 즉 “판단은 프론티어 모델에, 기계적 작업은 싼 모델에” 라는 원칙을 프롬프트 지시가 아니라 도구 권한 자체로 강제한다. 리드는 “minimal actions”만 취하며 꼭 필요한 것만 읽는다.
영속 캐시 컨텍스트: 두 에이전트는 각자 “persistent, cached contexts”를 유지한다. 기존의 “어드바이저 툴 호출” 방식(다른 모델을 한 번 불러 조언만 받는 방식)은 모델 전환 시 캐시가 매번 깨져 매우 비싸진다는 문제가 있었는데, Fusion은 이를 두 에이전트를 계속 살려두는 방식으로 우회한다. (프롬프트 캐시는 보통 5분 만료라는 제약이 있다고 명시.)
세션 중 동적 모델 라우팅: 작업 진행 중 가벼운 분류기(lightweight classifiers)가 신호를 보내면 리드↔사이드킥 역할을 세션 중간에도 전환한다. 이때 컨텍스트 압축(compaction) 시점에 맞춰 전환해서, 어차피 발생할 캐시 미스에 모델 전환을 얹어 추가 비용 없이 처리한다.
비용 결과: FrontierCode 기준 35% 비용 절감(동일 성능 기준), Fable 5로 리드를 돌리면 **41%**까지. 개별 사례로는 느린 테스트 실행을 위임한 ES6 모더나이제이션 작업에서 62% 절감. 다만 복잡한 판단이 필요한 작업을 억지로 위임하면 성능이 떨어질 수 있다고 경고한다.
실 운영 지표: Cognition은 “merged PR의 88%가 Fusion 라우터에 의해 자동으로 결정됐다”고 밝혔다 — 사람이 수동으로 리드/사이드킥을 고르지 않고 라우터가 대부분 처리한다는 뜻.

Claude Code에서 비슷한 구조 구성하기

Devin Fusion은 Cognition/Devin 전용 하네스라 Claude Code에 그대로 이식된 공식 기능은 없다. 이 패턴을 그대로 재현하려는 오픈소스 시도(sidekick-fusion)가 있지만 현재는 OpenCode 전용이고 “Claude Code & Codex planned”라고만 되어 있어 아직 가져다 쓸 수는 없다. 대신 Claude Code의 공식 서브에이전트 기능만으로 핵심 원리(권한 분리 + 이른 위임 + 제약 명시 브리프)는 직접 흉내낼 수 있다.

1) 리드 에이전트의 편집 권한을 기계적으로 차단. .claude/agents/에 사이드킥 서브에이전트를 정의하고, 리드(메인 세션 또는 코디네이터 서브에이전트)에서 disallowedTools: Edit, Write로 직접 편집을 막는다. Devin Fusion처럼 “위임 외에는 코드를 바꿀 방법이 없는” 상태를 강제하는 것.

# .claude/agents/sidekick.md
---
name: sidekick
description: 리드가 위임한 구현+테스트+린트 작업을 수행하는 사이드킥. 스펙 브리프를 받아 독립 컨텍스트에서 실행하고 결과만 보고한다.
model: haiku   # 또는 sonnet — 리드보다 싼 모델
tools: Read, Edit, Write, Bash, Grep, Glob
---
 
브리프에 명시된 제약·엣지케이스·완료 기준을 그대로 지켜 구현하라.
브리프에 없는 설계 판단은 임의로 내리지 말고 질문으로 남겨라.

model 필드는 sonnet/opus/haiku/fable/전체 모델 ID/inherit 중 선택 — 사이드킥에는 haiku나 sonnet처럼 싼 모델을 지정한다.
코디네이터(리드) 쪽에는 tools: Agent(sidekick), Read, Grep, Glob 처럼 Agent(agent_type) 화이트리스트로 정확히 이 사이드킥에게만 위임하도록 제한할 수 있다.
isolation: worktree를 사이드킥에 주면 독립된 git worktree에서 편집해, 리드의 리뷰(diff 검토) 단계와 자연스럽게 분리된다.

2) 이른 위임 + 스펙급 브리프를 CLAUDE.md/시스템 프롬프트로 강제. 원문의 핵심 교훈은 “위임 횟수가 아니라 언제·어떻게 위임하는가”였다. 리드 역할을 맡는 에이전트(메인 세션 또는 코디네이터)의 지침에 다음을 명시한다:

정찰(파일 탐색) 이상은 직접 하지 말고, 파악되는 즉시 사이드킥에게 구현을 위임할 것.
브리프에 **제약·엣지케이스·완료 기준(definition of done)**을 반드시 적을 것 — Opus가 O(1) 제약을 브리프 없이 스스로 구현하다 까먹은 실패 사례를 반면교사로.
사이드킥 결과는 git diff/git show 수준으로 가볍게 검토하고, 문제가 있으면 직접 고치지 말고 재위임할 것(리드가 직접 재작성하면 이 구조의 비용 이점이 사라진다).

3) 참고할 수 있는 이 위키의 유사 사례. 완전히 같은 하네스는 아니지만, 이 위키에는 이미 “비싼 모델은 판단만, 싼 모델이 구현”이라는 동일한 원리를 Claude Code 안에서 구성한 실전 사례가 있다 — 2026-07-14-run-gpt-5-6-sol-inside-claude-code의 Fable(오케스트레이터) → Sol(계획/리뷰) → Terra/Luna(구현) 3계층 구조. Devin Fusion의 “리드는 판단만, 사이드킥이 실행” 원칙을 모델 3개로 더 세분화한 형태로 볼 수 있다.

한계: Claude Code 서브에이전트는 기본적으로 서로 별도의 프롬프트 캐시를 쓴다(공식 문서: 이름 붙은 서브에이전트는 “Separate cache”). Devin Fusion이 강조하는 “영속 캐시 컨텍스트를 유지한 채 압축 시점에 모델만 바꾸는” 최적화는 Claude Code의 표준 서브에이전트 방식으로는 그대로 재현되지 않는다 — 캐시를 공유하려면 /fork(전체 대화를 상속하는 fork subagent)를 쓰되, 이 경우 리드의 편집 권한을 도구 단에서 분리하기 어려워진다는 트레이드오프가 생긴다.

description	Cognition의 Devin Fusion 실험: 토큰당 2배 비싼 Fable 5가 사이드킥과 짝지으면 Opus 4.8보다 싸고 점수도 높아지는 이유를 위임 타이밍·방식으로 분석.
tags	ai-agents, ai-coding, anthropic, claude-code, research

LLM Wiki

탐색기

Fable 5가 Opus 4.8보다 저렴해지는 이유 — Devin Fusion 위임 실험