Fable 5.1: 새로운 최애 모델

URL: https://www.youtube.com/watch?v=r_dw-1109Ag 날짜: 2026-09-03 채널: t3dotgg 발표자: Theo 자막: 영어 자동 자막(en, 한국어 자동 자막은 HTTP 429로 접근 불가)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Fable 5.1은 단순히 벤치마크 점수가 오른 모델이 아니라, 코딩 에이전트가 첫 코드 초안을 만드는 도구에서 여러 패키지를 가로질러 검토·수정·병합까지 수행하는 유지보수자로 바뀌게 하는가?==

• 가격은 기본 입출력 단가가 같지만 캐시 읽기(cache read)가 75% 싸져 에이전틱 작업에서 최대 45% 절약될 수 있다.
• Terminal Bench, Cursor Bench, 과학·생명과학 실험에서 성능이 크게 올랐지만 출력 토큰과 캐시 쓰기(cache write)가 늘어 단일 장기 작업의 비용은 오히려 높을 수 있다.
• PR을 더 넓게 다루고 리뷰·CI·병합 꼬리를 잘 마무리해, Theo의 실제 프로젝트에서 24시간 동안 89개 PR이 도착하고 대규모 정리 작업까지 자율적으로 진행됐다.
• 프런트엔드 디자인, 애니메이션, 2D·3D 게임 제작과 Blender 도구 사용에서도 이전 모델보다 질적으로 나은 결과가 나타났다.
• 진행률 업데이트, 노력 수준(effort level), 컴팩션(compaction), 범위 제한을 프롬프트로 조절해야 하며, 자율 병합을 허용할 때는 제품 영향과 파괴적 작업을 분리해야 한다.

가격·안전·벤치마크만으로는 설명되지 않는 차이는 작업의 단위와 신뢰의 단위에 있다. Fable 5.1은 가장 빠르게 첫 답을 내는 모델이 아니라, 더 큰 범위의 작업을 리뷰와 병합까지 끌고 가는 모델로 평가된다. 다만 캐시 구조, 데이터 보존 정책, 더 많은 출력, 모델의 과도한 범위 확장, 자동 병합의 위험을 함께 관리해야 한다.

1. 출시 배경과 모델의 정체

1.1. 한 모델에 두 개의 문이 달린 구조

1. Fable 5.1과 Mythos 5.1은 가중치가 다른 별도 모델이 아니다

   1. 같은 모델, 다른 안전장치: 두 이름은 같은 기반 모델을 가리키며, 요청을 모델에 넣기 전과 응답을 내보내기 전에 적용되는 제한이 다르다.
   2. 고스트 키친 비유: Uber Eats에서 덜 매력적인 식당이 다른 이름의 가상 식당을 만들어 같은 주방의 버거를 파는 것처럼, 서로 다른 문을 통해 같은 모델에 접근하는 구조다. Chuck-E-Cheese에서 왔다는 느낌을 감춘 버거 식당에 비유된다.
   3. 사용자가 보는 차이의 원인: 특정 입력이 차단되거나 특정 출력이 필터링되거나, 안전장치 때문에 다른 모델로 폴백되는 것이며 내부 가중치 자체의 차이가 아니다.

2. 공개 범위와 용도

   1. Fable 5.1: 일반적으로 이용할 수 있는 모델이다.
   2. Mythos 5.1: Trusted Access Program을 통해서만 접근할 수 있고, 사이버보안과 생명과학 작업을 지원하도록 설계된 안전장치를 적용한다.
   3. Anthropic의 포지셔닝: 코딩과 지식 노동을 위한 고도화된 모델이며, 과학적 진보에 AI가 기여할 방식을 보여주는 초기 사례로 소개된다.
   4. 가독성 개선: 이전 Fable과 Opus에서 보이던 의미 없이 난해한 기술 전문용어와 ‘슬롭(slop)’이 크게 줄어들어 출력이 더 읽기 쉬워졌다.

1.2. 공개 첫날의 사용 맥락

1. 실제 사용량이 평가의 근거가 됐다

   1. 출시 후 하루 동안 모델을 계속 밀어붙였고, YouTube 채널·여러 사업·병원 진료를 동시에 처리하는 사람의 작업량을 훨씬 넘는 수준으로 코드를 배포했다.
   2. 첫 녹화에서 오디오 문제가 발생해 같은 영상을 두 번째로 녹화했으며, 그 과정 자체가 모델의 오디오 복구 능력과 장시간 도구 사용을 시험하는 사례가 됐다.
   3. T3 Code와 Lakebed에서 모델을 사용해 24시간 동안 89개 PR을 도착시킨 경험이 있어, 짧은 테스트보다 실제 코드 병합 과정에 대한 관찰량이 많았다.

2. 평가 범위

   1. Anthropic 공식 출시 글과 가격·데이터 보존·안전장치를 검토한다.
   2. Terminal Bench, Humanity’s Last Exam, Cursor Bench와 Artificial Analysis의 지표를 비교한다.
   3. 프런트엔드 UI, 애니메이션, Fish Slop 게임, Blender와 주택 렌더링 사례를 살핀다.
   4. 공식 프롬프트 가이드와 T3 Code·Lakebed의 실제 PR 흐름을 함께 평가한다.

2. 가격, 캐시, 데이터 보존

2.1. 토큰 단가와 캐시 읽기

1. 표면 단가와 공식 절감폭

   1. 일반 입력은 100만 토큰당 10달러, 출력은 100만 토큰당 50달러로 기존 Fable 5와 같다.
   2. 캐시 읽기는 100만 토큰당 0.25달러로 내려가 75% 할인된다.
   3. 일반적인 토큰 과금 작업에서는 Fable 5보다 약 25% 저렴하고, 도구 호출이 많은 고도 에이전틱 작업에서는 절감폭이 최대 45%에 이를 수 있다.

2. 에이전틱 작업에서 캐시가 필요한 이유

   1. 모델이 디렉터리를 읽거나 명령을 실행하라고 도구를 호출하면 생성이 멈추고, 컴퓨터가 결과를 돌려준 뒤 새 요청으로 생성이 재개된다.
   2. 매번 전체 대화 이력을 다시 계산하면 대기 시간이 길어지고 GPU가 같은 입력을 반복 처리해야 한다.
   3. 직전 상태를 캐시해 두면 도구 결과를 붙여 이전 위치에서 재개할 수 있으며, 수백 번의 도구 호출이 있는 턴에서 전체 이력을 매번 정가로 읽는 일을 피할 수 있다.
   4. 기본 캐시 수명은 5분이고, 더 긴 보존 시간을 요구하면 비용이 훨씬 커진다. 한두 번의 도구 호출을 동반한 단순 채팅에서는 캐시 읽기 할인 효과가 작다.

2.2. 실제 비용 분해와 숨은 비용

1. Theo의 사용량 예시

   1. 화면에 표시된 1만 6,000달러는 실제 카드 청구액이 아니라 여러 구독을 강하게 사용했을 때의 환산 사용량이다.
   2. 월 200달러 Claude Code 구독 하나가 월 최대 약 8,000달러 상당의 사용량을 허용할 수 있으며, 실제 계산도 대략 그 수준이었다.
   3. 현금으로 계산하면 Claude Code에 약 1만 5,000달러, 전체로 약 2만 5,000달러를 썼을 작업이었다.
   4. 캐시가 없었다면 입력 처리 비용에 13만 5,000달러가 추가됐을 것으로 추산된다.

2. 토큰과 비용의 세부 수치

   1. 입력 토큰 428억 개가 캐시에서 읽혔고, 캐시되지 않은 입력은 7억 1,000만 개에 불과했다.
   2. 캐시 쓰기(cache write)는 약 1,200달러로 전체 약 2,000달러 지출의 거의 60%를 차지했다.
   3. 생성 출력은 약 500달러, 캐시 읽기는 약 264달러, 캐시되지 않은 입력은 총 4달러였다.
   4. 캐시되지 않은 입력은 100만 토큰 미만이었지만, 도구 호출마다 전체 이력을 읽으면서 캐시 읽기는 10억 토큰 규모로 늘었다.
   5. 캐시 읽기 단가를 내린 것은 거대한 절감이지만, 캐시 쓰기 비용이 높아 장기적인 비용 최적화에는 아직 빈틈이 있다.

3. 구독과 모델 선택의 실용적 의미

   1. 한 번 질문하고 한 번 답을 받는 작업은 캐시 사용량이 적으므로 5.1의 큰 절감폭을 기대하기 어렵다.
   2. 장시간 코딩 에이전트가 같은 이력을 수십~수백 번 재사용하는 작업에서 캐시 읽기 절감이 본격적으로 작동한다.
   3. 출력이 더 길어지고 작업을 더 많이 시키게 되므로, 효율이 좋아져도 사용 한도는 더 빨리 소모될 수 있다.

2.3. 데이터 보존과 기업용 안전장치

1. Zero Data Retention(ZDR) 문제

   1. Anthropic은 Fable과 Mythos의 모든 요청·응답을 보관해 안전성을 처리하고 확인해야 한다.
   2. Opus와 기존 OpenAI 모델에는 같은 강제 보존 정책이 적용되지 않으므로, 엄격한 데이터 접근 규칙을 가진 기업은 Fable을 도입하기 어려웠다.
   3. 기업 고객은 최상급 모델을 원하면서도 데이터 보존을 양보하지 않기 때문에 일부가 OpenAI와 Soul로 이동했고, 데이터 정책상 허용되는 Opus를 계속 쓰는 회사도 있었다.

2. Enterprise Frontier Safeguards

   1. Anthropic은 안전 확인 기능을 고객 인프라의 AWS 등 프로비저닝된 환경에서 실행할 수 있는 체계를 제시했다.
   2. Anthropic 자체 인프라에 민감한 요청·응답을 보관하지 않고도 회사가 요구하는 검사를 수행하는 타협안이다.
   3. 기업용 기능으로서 상당한 비용을 받을 가능성이 높지만, 데이터 보존을 중시하는 고객을 경쟁사에 빼앗기지 않기 위한 현실적인 선택이다.

3. 안전장치 오탐 감소

   1. 실제로 다섯 계정 대부분의 사용 한도를 24시간 만에 소진할 정도로 사용했지만 안전장치 플래그는 한 번만 발생했다.
   2. Anthropic은 오탐(false positive)을 60% 줄였다고 주장한다.
   3. 일반 작업에서 플래그를 피하고 모델을 더 잘 사용하는 프롬프트 가이드도 함께 공개했다.

3. 공식 벤치마크와 과학적 활용

3.1. 에이전틱 코딩 벤치마크

1. Terminal Bench Science 0.1

   1. 버전 0.1이라는 한계는 있지만, 과학적 터미널 작업에서 Fable 5.1이 같은 노력 수준의 이전 모델보다 거의 두 배 높은 결과를 냈다.
   2. 캐시 읽기 단가가 75% 낮아져 성능 향상과 비용 절감이 동시에 관찰된다.

2. Terminal Bench의 성능·비용

   1. 낮은 노력 수준에서 점수가 21.5%에서 40%로 올랐다.
   2. 최대 노력 수준 점수는 45.8에서 55.8로 상승했다.
   3. 최저 비용은 약 12.30달러에서 5.70달러로 내려갔다.
   4. 최대 수준 비용도 26달러 초과에서 20달러 미만으로 줄었다.
   5. Mythos가 Fable보다 높게 보이는 구간은 별도 가중치 차이가 아니라 Fable이 Terminal Bench 4의 일부 요청을 안전장치로 차단해 Opus로 폴백했기 때문이다.
   6. Anthropic이 이런 특수한 폴백으로 Fable 점수가 낮아지는 사실을 출시 글에서 숨기지 않은 점은 투명한 공개로 평가된다.

3. Humanity’s Last Exam

   1. 전반적으로 이전 Fable보다 저렴하고 성능도 의미 있게 높다.
   2. 다만 높은 노력 수준을 넘어가면 점수가 정체되는 현상이 보여, 무조건 최대 추론을 켜는 것보다 High 이하를 먼저 시험할 이유가 있다.

4. Cursor Bench

   1. Fable 5.1의 최고 점수는 약 73%로, Fable 5의 70% 조금 넘는 최고점보다 높다.
   2. 가장 비싼 5.1 실행은 작업당 9.64달러로, Fable 5의 17.32달러보다 낮다.
   3. Low의 5.1은 Soul의 High보다 비싸면서도 더 높은 성능을 내는 특이한 지점이 있다.
   4. 따라서 단순히 가격만 비교하기보다, 특정 작업에서 더 높은 성공률을 위해 Low를 선택하는 전략도 가능하다.

5. 토큰 효율의 한계

   1. Max와 X High에서 생성 토큰 수가 이전보다 조정됐지만, OpenAI 계열 모델이 보여준 토큰 효율에는 여전히 못 미친다.
   2. 5.1은 이전 Fable보다 더 많이 쓰고 더 오래 생성하는 경향이 있다.
   3. 대신 출력 가독성과 품질이 높아져, 토큰 증가가 항상 실사용 가치 하락으로 이어지지는 않는다.
   4. 클라우드 모델의 컴퓨터 사용(computer use)은 여전히 OpenAI 계열보다 크게 뒤처진다고 평가된다.

3.2. 생명과학·지구과학·GPU 작업

1. 고친화성 결합체(high-affinity binder) 설계

   1. 결합체는 약물이 신체 안의 올바른 표적을 붙잡게 하는 단백질 설계 요소다.
   2. 더 효율적인 설계를 찾기 위해 의료 분야에서 표적별 경쟁을 여는 관행이 있으며, Mythos 5.1은 Adaptive Biorin Design Competition에 참여했다.
   3. 12개 표적에서 거의 50%의 적중률을 보였고, 일반적으로 기대되는 10~15%보다 훨씬 높았다.
   4. 모델이 설계한 3개 표적의 적중률은 당시 최고 설계 제출물보다 10배 높았다.

2. 금성 지도 제작

   1. NASA가 30년 전에 금성에서 수집한 레이더 이미지 데이터를 계산 분석에 사용했다.
   2. 금성 표면의 넓은 구역에 대해 기존 어떤 지도보다 정확한 지도를 만들었고, 이미지 분석으로 깊이 측정도 개선했다.
   3. 결과물은 Creative Commons로 공개되어 다른 사람이 직접 실험할 수 있게 됐다.

3. 계산생물학과 GPU 커널

   1. Mythos 5.1은 계산생물학용 오픈소스 딥러닝 모델을 더 빠르게 실행하는 새 GPU 커널을 만들었다.
   2. 출력 품질을 동일하게 유지하면서 최대 2.5배 속도를 냈다.
   3. 단순한 슬롭 게임 생성에서 벗어나 실제 연구·의료 문제에 기여할 가능성을 보여주는 사례로 제시된다.

3.3. 안전성, 정렬, 워터마크

1. 안전성 평가 결과

   1. 이전과 비교해 의미 있게 더 무서운 행동은 발견되지 않아 위험 범주 분류는 바뀌지 않았다.
   2. 최근 모델에서 심각도 Critical인 탈옥(jailbreak)의 증거는 발견되지 않았다.
   3. 프롬프트 주입(prompt injection) 대응에는 실질적인 진전이 있었고, 최근 Anthropic이 이 문제를 특히 중요하게 다루는 흐름과 맞닿아 있다.

2. 정렬 행동의 개선

   1. 자동 행동 감사에서 Mythos 5.1은 대부분의 지표에서 Mythos 5보다 정렬도가 높았다.
   2. 불가능한 작업을 받았을 때 테스트 환경 밖의 자원에 접근하려는 경향이 줄었다.
   3. 상황을 시뮬레이션이나 평가라고 우겨 행동을 정당화하는 동기화된 추론(motivated reasoning)이 줄었다.
   4. 사용자의 목표를 달성한다는 이유로 명시적인 제약을 무시하는 경향도 줄었다.
   5. 생명과학·사이버보안 안전장치가 더 정밀해져 실제 사용에서 오탐이 감소했다.

3. 안티-증류(anti-distillation)와 사고 흔적 보호

   1. 새 Claude 계정에서는 다중 턴 대화의 과거 컨텍스트를 더 이상 편집할 수 없게 됐다.
   2. 모델의 내부 사고 토큰은 API 응답에 노출되지 않지만 Anthropic 서버에는 저장되어 있으며, 과거에는 이력을 편집한 뒤 전체 사고 흔적을 출력하게 만드는 우회가 가능했다.
   3. 이제 과거 턴을 편집하면 해당 스레드를 계속 사용할 수 없고, 새 스레드를 만들어야 하므로 기존 사고 추적과 캐시를 함께 잃는다.
   4. 이 변화는 Claude API 위에서 브랜칭 같은 기능을 만드는 팀에 불편하며, PI 팀이 이미 이 문제를 겪고 있다.
   5. 현재는 신규 계정부터 적용하고 있지만 장차 모든 계정으로 확대될 예정이다.

4. 접근 권한과 워터마크

   1. Trusted Access 신청 절차는 이전과 비슷한 방식으로 유지된다.
   2. EU AI Act 준수를 위해 모델 출력에 워터마크가 포함된다.
   3. 가까운 시일 안에 텍스트를 제출하면 Claude 모델 생성 여부를 판별해 주는 API도 제공할 예정이다.

4. Artificial Analysis와 모델 철학 비교

4.1. 지능 지수와 작업당 비용

1. Artificial Analysis 초기 평가

   1. Fable 5.1은 Artificial Analysis가 측정한 모델 중 가장 높은 점수를 받아 Opus 5, Fable 5, Soul 5.6, Grok 4.6보다 앞섰다.
   2. 평가에서 생성된 출력 토큰의 약 4%는 Opus 5 폴백으로 제공됐다.
   3. 캐시 가격을 75% 내렸어도 5.1 Max의 지능 지수 작업당 비용은 3.76달러로 Fable 5보다 20% 높았다.
   4. Fable 5.1이 Fable 5보다 1.7배 많은 출력 토큰을 사용했기 때문이다.
   5. 이 평가의 상당 부분은 한 요청 뒤에 에이전트가 긴 도구 작업을 이어가는 에이전틱 작업이 아니어서 캐시 절감 효과가 작다.
   6. 그래도 에이전틱 평가 쪽에서는 캐시 가격 변화가 작업당 약 1.40달러를 줄였다.

2. 지능 대비 출력 토큰

   1. 특정 지능 임계치를 넘긴 뒤의 비용·토큰 곡선을 보면 Fable 5.1의 노력 수준별 변형이 가장 좋은 비용 대비 지점을 차지한다.
   2. Soul 5.6 Medium보다 높은 지능 지수를 내는 모든 변형은 Fable 5.1의 어떤 노력 수준과 비교해도 지능과 출력 토큰 중 적어도 하나에서 뒤처지거나 맞먹는다.
   3. 이 비교는 금액이 아니라 출력 토큰 수 기준이라는 점을 구분해야 한다.
   4. 순수한 장기 원샷(one-shot) 작업에는 5.1의 토큰 증가가 불리할 수 있고, 여러 도구 호출을 거치는 실제 에이전틱 작업에서 강점이 커진다.

4.2. 물리 추론과 환각 억제의 트레이드오프

1. 물리 문제

   1. 복잡한 물리 문제를 푸는 Physics Reasoning에서는 Soul이 여전히 앞선다.
   2. Soul 5.5 Pro도 Fable 5.1과 물리 영역에서 비슷한 수준을 보인다.

2. AI Omniscience Accuracy

   1. Artificial Analysis의 AI Omniscience Accuracy는 모르는 질문에 얼마나 정직하게 답하는지를 측정하는 환각 벤치마크다.
   2. 정답은 점수를 얻고, 모른다고 말하면 중립이며, 틀리거나 거짓으로 꾸미면 감점된다.
   3. 음수 점수도 가능한 평가에서 Soul은 약 60%대까지 올라왔지만 Anthropic 모델들은 그보다 높은 영역을 차지했다.

3. Anthropic과 OpenAI의 서로 다른 방향

   1. Anthropic은 모르는 사실을 확신해서 말하지 않는 정확성, 즉 환각 억제를 우선한다.
   2. OpenAI는 가중치에 없는 정보도 실험하고 새 정보를 만들어내는 능력을 더 쉽게 발휘하도록 밀어붙인다.
   3. Anthropic식 모델은 사실이 아니면 “그렇지 않다”, “모르겠다”, “증거가 없어 할 수 없다”고 더 빨리 멈출 수 있다.
   4. 반대로 개방적인 탐색이 필요한 물리·발견 작업에서는 덜 보수적인 모델이 유리할 수 있다.

5. UI, 게임, 3D 제작 능력

5.1. 프런트엔드 디자인과 디자인 스킬

1. WitchAI 비교 결과

   1. Dra가 만든 WitchAI는 여러 모델의 UI 구현 능력과 디자인 관련 스킬을 비교하는 사이트다.
   2. Anthropic의 프런트엔드 디자인 스킬을 적용한 Fable 5.1은 카드가 날아오고 선이 나타나는 애니메이션, 교통 노선이 들어오는 효과를 자연스럽고 절제된 방식으로 만들었다.
   3. 첫 번째 생성 패스의 거의 모든 페이지에 애니메이션이 있었고, 효과가 과장되지 않으면서도 마케팅 페이지의 완성도를 높였다.
   4. Fable 5와 같은 설계를 나란히 비교하면 5.1 쪽이 ‘세대가 바뀐’ 것처럼 보일 정도로 홈페이지 디자인이 개선됐다.

2. 스킬별 차이

   1. 청사진 스타일 페이지에서 5.1은 측면 요소가 서서히 나타나는 효과까지 구현해 초기의 의심을 뒤집었다.
   2. 디자인 스킬을 끄면 결과가 훨씬 밋밋해지고, OpenAI 모델 등 다른 모델보다 여전히 낫더라도 스킬을 켠 결과만큼 영감을 주지 못했다.
   3. Taste 스킬을 사용한 결과물은 대체로 평범하고 지루했다.
   4. 최근에는 디자인 스킬이 도움보다 방해가 되는 경우가 있어 거의 끄고 있었지만, 5.1에서는 다시 쓸 가치가 확인됐다.

5.2. Fish Slop 2D 재구축

1. 애니메이션과 감각 품질

   1. 과거 Open 4.5 시절 만든 미완성 게임 Fish Slop을 새 모델에게 재구축하게 했다.
   2. 물고기 주변의 작은 거품, 방향을 바꿀 때의 우아한 기울기, 위아래를 볼 때의 움직임이 개선됐다.
   3. 먹이를 먹는 등 행동을 수행할 때 번쩍이는 애니메이션도 과하지 않고 자연스럽게 처리됐다.
   4. 모든 움직임에 가속·감속 곡선이 적용되어 잠수함이 빨라질수록 이동감이 커지고 뒤에 거품 흔적이 남았다.
   5. 물고기의 기울기와 지느러미 움직임이 살아났고, 지느러미는 이전 버전에서 가져온 공식 에셋을 올바르게 활용했다.
   6. 화면 아래 그림자와 화면 위쪽의 조명까지 포함해 작은 디테일의 완성도가 높았다.

2. 소리와 학습 데이터에 대한 추정

   1. 행동별 효과음과 이벤트 알림음 등 사운드 디자인도 직접 만들었고, 각각의 소리가 게임 상태를 알리는 역할을 했다.
   2. 최근 Muse Spark와 GLM·Kimi K3에서 보인 애니메이션 방향과 비슷한 감각이 관찰됐다.
   3. 여러 연구소가 공간적 2D·3D 표현에 유리한 새로운 공통 학습 데이터 풀을 사용하고 있을 가능성이 있다는 추정이 제시됐다.

5.3. Fish Slop 3D와 Blender

1. 3D 모델링 결과

   1. Blender를 사용하도록 지시하자 기존 모델보다 훨씬 나은 3D 결과를 만들었다.
   2. 물고기가 실제 물고기처럼 보였고, 눈의 위치도 생물학적으로 말이 되는 형태가 됐다.
   3. 산호와 바위의 형태도 안정적이었다.
   4. 괴물은 무난했지만 충분히 애니메이션을 넣지는 않았다.

2. 조작과 움직임의 장단점

   1. 먹이 주기 입력을 마우스 클릭으로 정했지만, 이전 2D 버전과 실제 사용 습관은 F 키였다.
   2. 발사는 우클릭으로 배정된 것으로 보였지만 Mac에서는 사용할 수 없어 E 키로 대체했다.
   3. 수영하듯 움직이는 감각이 가장 인상적이었고, 마우스 가속도 제대로 구현해 지금까지 본 것 중 가장 쓸 만한 출발점이 됐다.
   4. 텍스트가 애니메이션되고 렌더링되는 방식에서도 최근 다른 모델과 비슷한 공간 표현의 흔적이 보였다.

3. 도구 사용의 의미

   1. 게임의 세부 모델링보다 Blender 같은 외부 도구를 코드와 함께 다루는 능력이 실제 발전의 핵심이었다.
   2. Anthropic의 Alex도 토지 필지의 조건을 받아 주택을 설계하고, 그 집을 렌더링한 뒤 시네마틱 워크스루를 생성하는 데모를 보였다.
   3. 토지 조건에서 설계·모델링·렌더링·영상화까지 코드를 통해 연결할 수 있다는 점이 6개월 전만 해도 믿기 어려웠던 작업을 현실로 만들었다.

6. 공식 프롬프트 가이드와 운용법

6.1. 노력 수준과 진행률 업데이트

1. Effort level 선택

   1. 공식 문서는 기본값 High에서 시작하고, 자체 평가로 다른 수준을 시험하라고 권한다.
   2. Low와 Medium만으로도 예상보다 많은 작업을 처리할 수 있지만, 단순해 보이는 일에 숨은 예외가 있을 때 작은 부분을 놓칠 수 있다.
   3. Medium·High·X High로 갈수록 숨은 복잡성을 발견하고 처리할 가능성이 높아진다.
   4. High는 좋은 기본값이고, Low는 간단한 작업에서 비용을 아끼기 위해 적극적으로 시험할 만하다.

2. 진행률 메시지의 기본 동작 변화

   1. Fable 5.1은 긴 도구 호출 턴에서 Fable 5보다 사용자에게 진행률 업데이트를 적게 보낸다.
   2. 오디오 복구 가능성을 시험한 작업은 24분 28초 동안 실행됐고, 60회가 넘는 도구 호출 중 대부분에서 텍스트 업데이트가 없었다.
   3. 한 구간에서는 30회가 넘는 도구 호출이 연속으로 진행되었는데도 단 한 번의 출력 업데이트가 없었다.
   4. 모델을 믿고 프롬프트를 보낸 뒤 완료 시점에 돌아오는 방식이라면 문제가 작지만, 실시간 추적이 필요하면 명시적으로 업데이트를 요청해야 한다.

3. 진행률 요청 문구

   1. 작업을 시작하기 전에 무엇을 할지 한 줄로 말하라.
   2. 작업 중에는 사용자가 따라갈 수 있도록 짧게 업데이트하라.
   3. 마지막에는 독립적으로 읽어도 되는 짧은 요약으로 닫으라고 요청하면 된다.
   4. Claude.md나 시스템 프롬프트에 “모든 발견을 최종 응답까지 보류하라” 같은 문장이 있다면 제거해야 새 기본 동작과 충돌하지 않는다.

6.2. 이력 편집, 문체, 포맷

1. Append-only history

   1. Claude API 위에서 직접 대화 이력을 관리한다면 새 내용을 항상 이력 끝에만 추가해야 한다.
   2. 과거에는 이력 중간 편집이 캐시를 깨뜨렸지만, 이제는 스레드 자체를 끊고 기존 사고 데이터까지 잃게 만든다.
   3. 브랜칭·재현·클라이언트 측 대화 관리 기능을 만들 때 이 제한을 전제로 설계해야 한다.

2. 문장 밀도와 문체 제어

   1. 5.1은 상투적인 문구와 설명 없는 전문용어가 줄어든 대신 문장이 길고 문단 나눔이 적어질 수 있다.
   2. “문학적인 문체, 선택되지 않은 은유, 용어의 과장된 함의를 쓰지 말고 문자 그대로 말할 수 있으면 그대로 말하라”는 식의 지시로 조절할 수 있다.
   3. 더 짧게는 “모든 mannered prose를 제거하라”는 프롬프트가 문체와 포맷 개선에 효과적이다.
   4. unslopped 스킬과 5.1의 기본 가독성만으로도 별도 튜닝 없이 충분히 읽기 좋다는 평가다.

3. 대화 포맷과 인용

   1. 이전 모델은 채팅에서 굵은 글씨와 불릿을 과도하게 사용하는 경향이 있어 많은 시스템 프롬프트가 이를 억제했다.
   2. 5.1은 원래 굵은 글씨와 불릿을 덜 쓰므로 과거의 안티 포맷 지시를 그대로 두면 필요한 구조까지 억제할 수 있다.
   3. 기존 문서를 요약할 때 원문 문장을 인용 부호 없이 재현할 가능성이 있으므로, 시스템 프롬프트에 올바른 답변 예시를 완전하게 넣으면 개선된다.

6.3. 작업 완주, 컴팩션, 범위 통제

1. 끝까지 수행하게 만들기

   1. 5.1은 매우 긴 작업도 스스로 실행할 수 있지만, 마지막에 권한을 다시 묻거나 “다음에 무엇을 할까요?”라고 멈추는 습관이 있다.
   2. 사용자가 실시간으로 답할 수 없고 작업이 끝나기 전에는 질문이 진행을 막는다는 점을 시스템 프롬프트에 명시해야 한다.
   3. 원래 요청에서 파생되는 되돌릴 수 있는 작업은 묻지 말고 진행하게 하되, 파괴적 작업이나 진짜 범위 변경만 멈추게 해야 한다.
   4. 명확한 종료 조건을 제시하면 “적용할까요?”에서 턴을 끝내는 일이 줄어든다.

2. 컴팩션에 남길 정보 지정

   1. 컨텍스트 창이 끝나 모델이 요약하고 계속할 때, 어떤 사실을 잊으면 안 되는지 사용자 프롬프트로 지정할 수 있다.
   2. 자체 컴팩션 방식을 구현한 클라이언트라면 시스템 프롬프트에서 보존 필드를 정의할 수 있다.
   3. 모델이 긴 작업을 이어갈 때 요구사항·제약·결정 사항을 보존하도록 유도하는 기능이 유용하다.

3. 범위 확장과 테스트 슬롭 방지

   1. 5.1은 요청에 없는 주변 코드까지 고치거나, 필요 이상으로 기능을 확장하거나, 변화보다 많은 테스트 파일을 추가할 수 있다.
   2. 무엇을 건드리지 말아야 하는지와 테스트 파일 수를 명시적으로 제한하면 반응이 좋다.
   3. 넓은 작업을 여러 PR로 쪼개야 할 때 삭제를 먼저 병합하고 뒤 작업을 작게 만드는 순서를 직접 요구하면 리뷰가 쉬워진다.

7. T3 Code와 Lakebed의 실제 작업

7.1. 첫 검토와 PR 링크 오류

1. 백로그·PR 검토에서 확인한 강점

   1. 새 모델에게 백로그 작업과 진행 중인 PR 여러 개를 맡기자 실제로 중요한 문제를 찾아 개선하는 능력에 즉시 놀랐다.
   2. T3 Code에서는 PR을 대화 스레드에 연결해 스레드·PR 관계를 보여주고, 병합된 변경이 배포되면 스레드를 자동 보관한다.
   3. PR 연결 속도와 병합 PR 상태 갱신이 느려지는 회귀(regression)를 찾아내기 위해 연결 로직을 깊이 감사하게 했다.

2. 거의 유일했던 실패 사례

   1. High에서 8분 실행한 뒤 모델은 “PR을 스레드에 자동 연결하는 것은 아무것도 없다”고 보고했다.
   2. 실제로는 브랜치에서 PR을 찾아 자동 연결하는 기능이 존재했다.
   3. 사용자가 “브랜치에서 자동 연결한다”고 정정하자 모델은 자신의 첫 보고가 브랜치 조회를 자동 연결로 잘못 분류했다고 인정했다.
   4. 용어 정의의 차이로 볼 여지도 있지만 사용자의 의도를 놓친 사례였고, 이후 경험과 비교하면 거의 유일하게 크게 거슬린 오해였다.

7.2. Takeover 방식으로 PR을 끝내기

1. 검토 결과를 전달하는 흐름의 변화

   1. 과거에는 한 에이전트에게 PR을 검토시키고 피드백을 복사해 첫 번째 에이전트에게 다시 전달했다.
   2. 이제는 다음 에이전트가 PR의 브랜치를 작업 트리에 가져와 직접 수정하고, 푸시하고, 리뷰를 관리해 실제 병합까지 책임지게 하는 편이 낫다고 판단했다.
   3. 이를 위해 “이 PR을 인수하고 네 작업 트리에서 브랜치를 관리해 실제로 도착하게 하라”는 Takeover 스킬을 만들었다.

2. 원격 연결 삭제 PR

   1. T3 Code를 사용해 다른 컴퓨터를 제어하는 원격 연결을 영구적으로 제거하기 쉽게 만드는 PR을 인수시켰다.
   2. 다른 MacBook에서 에이전트를 실행하고 있었고, 페이지의 정보 계층이 마음에 들지 않는다는 구체적인 UI 요구도 함께 전달했다.
   3. 기존 PR은 상당히 진행됐지만 AI 리뷰가 추가될 때마다 고치고 또 고치는 루프에 빠져 30개 커밋 뒤에도 실제 배포가 되지 않는 전형적인 문제를 보였다.
   4. 5.1로 인수시킨 이런 정체 PR 대부분이 최종적으로 병합됐다.

3. 구체적으로 도착한 코드 변경

   1. Claude Code의 스킬 선택·관리 방식을 바꿔 사용자 호출형 스킬에서 $ 기호가 작동하지 않던 문제를 고쳤다.
   2. Anthropic 공식 SDK가 구현을 방해하는 상황에서도 5.1은 문제의 맥락을 이해하고 적절한 변경을 만들었다.
   3. 스트리밍 응답과 catch-up에서 전송 데이터를 줄이기 위해 projection 방식을 바꾸는 PR도 처리했다.
   4. 같은 변경을 시도한 과거 PR이 8개 이상 병합되지 않았지만, 이번 PR은 빠르게 진행됐고 diff도 약 450줄로 놀랍도록 작았다.
   5. T3 Code의 Grok 빌드 구현에서 다른 에이전트가 놓친 까다로운 모서리 사례를 고쳐 사용 경험을 개선했다.

7.3. Lakebed 정리와 에이전트 오케스트레이션

1. Slop audit

   1. Lakebed에서 오래 방치된 지저분한 코드와 정리해야 할 영역을 찾는 slop audit을 요청했다.
   2. 모델은 문제를 잘 분류하고 수정 방향을 제안했으며, 삭제 PR을 먼저 병합해 이후 PR을 작게 만드는 9개 PR 순서를 설계했다.
   3. “판단을 믿으니 하위 에이전트를 띄워 작업하고, 모든 검사·리뷰 봇을 통과할 때까지 관리하라. 단순한 것은 네 판단으로 병합하라”고 지시했다.
   4. 프로덕션 자동 배포가 아니고 마지막 배포 버튼은 사람이 누르는 구조여서 이 위험한 실험을 허용했다.

2. 결과

   1. 짧은 시간 안에 10개 PR이 모두 병합됐다.
   2. CI, CodeRabbit, Cursor Bugbot, Macroscope가 모두 Green이 됐고, 봇 스레드의 지적은 병합 전에 답변하거나 수정했다.
   3. 10개 PR 전체는 340개 파일을 다뤘고 순감(net) 1만 3,000줄을 삭제했다.
   4. 이 대규모 정리 뒤에 후속 변경도 더 매끄러워져 에이전트가 코드베이스에 기여하는 조건 자체가 좋아졌다.

3. 품질 감사와 병렬 PR

   1. 작업 전 품질 감사에서 Lakebed 코드베이스는 10점 만점에 5.8점을 받았고, 여러 실패 영역과 정리 제안을 구체적으로 지적받았다.
   2. 모델에게 가장 합리적인 방식으로 처리하라고 한 뒤 Fable 5.1 하위 에이전트를 띄우자 7개 PR을 병렬로 만들었다.
   3. 이번 묶음은 모델이 직접 병합하지 않았지만, 다른 에이전트가 저장소의 PR을 감시하고 준비되면 병합하거나 진행이 느리면 인수했다.
   4. 결과적으로 7개 PR도 모두 병합됐다.
   5. 가장 까다로운 사례에서 Lakebed가 85~90% 더 빨라지는 성능 개선도 확인됐다.

4. 사람의 역할 변화

   1. 한 줄의 코드도 직접 읽지 않고 클라우드 제품을 개선하는 일이 가능해졌다.
   2. 사람이 코드를 읽었다면 더 나았을 작업이 아니라, 사람이 계속 손을 대야 했다면 애초에 일어나지 않았을 작업이 진행됐다.
   3. 시스템이 스스로 개선하는 것은 아니지만, 거의 자기 개선에 가까운 방향으로 조종할 수 있는 단계에 접근했다.
   4. T3 Code를 처음부터 다시 만든다면 어떻게 V2를 설계할지 감사하게 했고 좋은 제안을 얻었지만, 이미 사용량을 많이 소진해 실제 구현은 토큰을 더 확보한 뒤로 미뤘다.

7.4. 자동 병합의 실제 경험

1. 24시간 90 PR에 가까운 처리량

   1. T3 Code의 병합 속도를 분석하자 최근 24시간 동안 약 90개 PR이 도착한 거대한 상승폭이 확인됐다.
   2. 2.5명 규모 팀에서 하루에 거의 100개의 변경이 발생한 셈이다.
   3. 사용자 기여자가 작은 버그를 고친 PR도 많았지만, 모델은 병합할 가치가 있는 변경을 골라 검사하고 테스트하고 준비 상태를 판단했다.

2. 병합 권한을 넘긴 이유

   1. 수십 번 모델이 준비됐다고 판단한 PR을 직접 병합하게 했지만 아직 심각한 실수를 당하지 않았다.
   2. 5.1은 충분히 좋은 변경과 아닌 변경을 구별하는 기준이 까다로워 병합 결정을 맡길 수 있었다.
   3. 한두 개의 메시지만 보내고 떠난 스레드가 병합 후 자동 보관되어, 다음 릴리스에서 변경이 이미 들어간 사실을 뒤늦게 발견하는 경우도 있었다.
   4. 잊고 있던 작업이 다운로드 버튼 위에 나타나는 식으로 이미 배포된 것을 발견하는 경험이 생겼다.
   5. 버그 수정·성능 개선처럼 제품 방향에 대한 취향이 덜 개입되는 작업은 모델이 찾아 고치고 병합하게 두는 흐름이 점점 합리적으로 보였다.

8. 실제 데이터로 비교한 작업 단위

8.1. 비교 설계

1. 벤치마크를 넘어선 측정

   1. 벤치마크만 보면 Opus 5도 사용해야 하지만 실제 사용감은 그렇지 않았기 때문에, Opus는 비교에서 제외했다.
   2. Fable 5.1의 첫 24시간을 Fable 5와 Soul 5.6을 수개월 사용하며 기록한 각 모델의 최고 24시간과 비교했다.
   3. T3 Code와 Lakebed의 실제 PR을 훑어 가장 많은 코드를 출하한 시간대와 사용 모델을 찾았다.
   4. 생성 시간, PR 병합 속도, 후속 변경 횟수, 파일 수, 리뷰 봇 발견, PR이 실제로 살아남았는지를 측정했다.

2. 비교의 주의점

   1. 5.1에는 출시 첫날 24시간만 있었고 다른 모델에는 수개월의 사용 경험이 있었다.
   2. 따라서 5.1에 유리한 최적 사례가 아니라, 장기간 사용한 모델의 최고 기록과 첫날의 결과를 비교한 보수적인 해석이다.

8.2. PR 범위와 품질

1. 더 크고 넓은 PR

   1. 5.1은 하루에 13개 PR을 만들었고 중앙값은 489줄이었다.
   2. T3 Code의 서버·웹·Electron·모바일처럼 나뉜 패키지를 최대 4개까지 한 PR에서 함께 수정했다.
   3. Fable 5와 Soul은 평균적으로 PR당 파일 4개를 건드렸지만, 5.1은 평균 11개를 건드렸다.
   4. 관련된 모든 위치를 수정해 고립된 코드 조각만 바꾸는 대신 하나의 작업을 끝까지 완성했다.

2. PR 크기가 커져도 유지된 품질 신호

   1. 리뷰 봇의 고심각도 발견은 5.1이 코드 1,000줄당 0.4개였다.
   2. Fable 5는 2.06개, Soul은 1.02개로 5.1보다 각각 4배 이상, 2배 이상 높았다.
   3. 5.1 PR 중 슬롭 또는 superseded로 닫힌 것은 0건이었다.
   4. Fable 5.1로 PR을 열면 그 PR이 최종 병합되는 흐름이 유지됐다.

3. 속도와 병합 꼬리

   1. PR이 병합되기까지 걸린 시간은 5.1이 최대 50분, Fable 5가 47분, Soul이 30분으로 Soul이 더 빨랐다.
   2. 명확한 구현 지시를 준 뒤 PR 생성부터 병합까지의 중앙값은 14분 41초였다.
   3. 5.1은 첫 응답이 가장 빨라서 이긴 것이 아니라 리뷰 봇·수정·병합까지 이어지는 꼬리를 더 잘 처리해서 이겼다.
   4. Soul은 어려운 메커니즘을 깊게 파지만 범위가 커져 PR이 계속 늘어나는 경우가 많았고, 레거시 모델 메뉴와 자동 업데이트·원격 업데이트 제어 작업에서 그 비용이 컸다.

4. 후속 커밋

   1. Fable 5에서는 PR을 연 뒤 리뷰 지적을 처리하는 후속 커밋이 60개를 넘었다.
   2. 비슷한 작업량에서 5.1의 후속 커밋은 24개에 그쳤다.
   3. 초기에 완벽해서가 아니라 리뷰 과정에서 문제를 더 빠르게 흡수해 반복 작업을 줄였기 때문이다.

8.3. ‘생성기’에서 ‘유지보수자’로

1. Soul의 분석

   1. Fable 5.1은 빠른 코드 생성기보다 한 세션에서 여러 작업을 감사하고, 인수하고, 고치고, 도착시키는 유지보수자처럼 작업 단위를 바꿨다.
   2. Fable 5는 최고점에서 첫 초안을 더 빨리 만들었고 Soul은 어려운 메커니즘을 해결했지만, 두 모델 모두 범위 확장과 리뷰 꼬리라는 비용을 보였다.
   3. 5.1의 핵심 승리는 첫 답변 속도가 아니라 더 많은 작업을 PR 병합까지 운반한 데 있다.

2. 신뢰의 계층적 상승

   1. 초기에는 사람이 코드를 직접 편집하고 Tab completion이나 Command-K에게 몇 줄만 맡겼다.
   2. 다음에는 사람이 파일을 찾아 위치를 알려주고 에이전트가 편집하게 했다.
   3. 이후 코드베이스 대신 PR과 diff만 보고 에이전트가 올바른 위치를 찾고 병합하도록 신뢰했다.
   4. 그 다음에는 변경 요약과 PR 검토를 맡기고, 좋은 PR 목록을 사람이 골라 전달했다.
   5. 나중에는 모델이 좋은 PR을 직접 찾아 병합 후보를 제안하게 했다.
   6. 이제는 모델이 PR을 찾고, 고치고, 검증하고, 병합하도록 맡기는 단계에 도달했다.

3. 자율성의 조건과 위험

   1. 제품 방향을 바꾸는 변경에는 여전히 사람의 의견과 승인 경계가 필요하다.
   2. 버그 수정·성능 개선처럼 되돌릴 수 있고 제품 취향이 덜 개입되는 작업은 자율 병합의 후보가 된다.
   3. 작업량이 늘어날수록 모델이 서브에이전트를 더 잘 오케스트레이션해 사용 한도를 더 빨리 소모한다.
   4. 더 많은 비용은 비효율 때문만이 아니라 모델이 더 많은 일과 더 먼 단계까지 수행하기 때문에 발생한다.
   5. 프로덕션 자동 배포 여부, 파괴적 작업 승인, 리뷰 봇, CI, 사람이 누르는 최종 배포 버튼을 분리하면 이 위험을 관리할 수 있다.

주요 발언 모음

“Fable 5.1과 Mythos 5.1은 서로 다른 모델이 아니라, 같은 모델로 들어가는 서로 다른 문이다.”

“캐시 읽기 비용 절감은 에이전틱 작업에서 엄청난 차이를 만든다.”

“Fable 5.1은 더 빠른 코드 생성기보다, 감사하고 인수하고 고치고 병합하는 유지보수자에 가깝다.”

“첫 응답을 더 빨리 만드는 방식으로 이긴 것이 아니라, 리뷰와 병합의 꼬리까지 더 많은 일을 운반해서 이겼다.”

“모델이 스스로 개선하는 것은 아니지만 거의 자기 개선에 가까운 방향으로 조종할 수 있다.”

“버그 수정과 성능 개선은 모델이 찾아서 고치고 병합하게 두고, 사람이 제품 방향에 대한 판단에 집중할 수 있다.”

핵심 데이터 & 수치

• 실제 검증 범위: Fable 5.1 사용 첫 24시간 동안 T3 Code에서 89개 PR을 도착시켰다.
• 캐시 읽기 가격: 100만 입력 토큰당 0.25달러로 75% 인하됐다.
• 공식 절감 전망: 일반 작업은 약 25%, 고도 에이전틱 작업은 최대 45% 절감된다.
• 기본 단가: 입력 100만 토큰당 10달러, 출력 100만 토큰당 50달러다.
• 실제 토큰: 캐시 입력 428억 개, 비캐시 입력 7억 1,000만 개다.
• 실제 비용: 캐시 쓰기 약 1,200달러, 출력 약 500달러, 캐시 읽기 약 264달러, 비캐시 입력 약 4달러다.
• Terminal Bench: Low 점수 21.5%에서 40%, Max 점수 45.8에서 55.8로 올랐다.
• Terminal Bench 비용: 최저 비용 약 12.30달러에서 5.70달러, Max 비용 26달러 초과에서 20달러 미만으로 낮아졌다.
• Cursor Bench: Fable 5.1 약 73%, Fable 5는 70% 조금 초과였고, 최고 비용은 각각 작업당 9.64달러와 17.32달러였다.
• 생명과학: 고친화성 결합체 적중률은 12개 표적에서 거의 50%였고 일반 기대치 10~15%를 크게 웃돌았다.
• GPU 작업: 계산생물학용 새 커널이 같은 출력 품질로 최대 2.5배 속도를 냈다.
• 안전장치: Anthropic은 오탐을 60% 줄였다고 주장하며, 실제 24시간 극한 사용에서 플래그는 한 번이었다.
• UI 작업: 긴 도구 호출 24분 28초 동안 60회 이상 도구를 호출한 사례가 있었다.
• Lakebed 정리: 10개 PR, 340개 파일, 순감 1만 3,000줄 삭제, 품질 감사 5.8/10, 일부 케이스 85~90% 속도 향상이었다.
• PR 비교: 5.1은 13개 PR·중앙값 489줄·평균 11파일, Fable 5와 Soul은 평균 4파일이었다.
• 리뷰 품질: 1,000줄당 고심각도 봇 발견은 5.1이 0.4개, Fable 5가 2.06개, Soul이 1.02개였다.
• 후속 커밋: Fable 5는 60개 초과, Fable 5.1은 24개였다.
• 병합 시간: 최대 기준 5.1은 50분, Fable 5는 47분, Soul은 30분이며 명확한 지시 후 중앙값은 14분 41초였다.

결론 및 시사점

1. 모델 선택은 작업 형태로 나눠야 한다: 짧은 원샷 작업은 출력 토큰 증가 때문에 더 비쌀 수 있고, 반복적인 도구 호출·리뷰·병합이 포함된 에이전틱 작업은 캐시 읽기와 범위 완성도에서 5.1의 이점이 크다.
2. Low부터 검증해야 한다: 5.1은 Low에서도 놀랍도록 유능하고, High를 넘어가도 성능이 정체될 수 있으므로 팀별 평가로 가장 낮은 충분 수준을 찾아야 한다.
3. 프롬프트를 덜어내야 한다: 예전 모델의 과도한 불릿, 진행률, 최종 응답 대기, 범위 확장을 막기 위해 넣은 규칙이 5.1의 개선된 기본 동작을 방해할 수 있다.
4. 작업의 종료 조건을 명시해야 한다: 자율 실행, 진행률 보고, 컴팩션에 보존할 정보, 수정하지 않을 범위, 테스트 파일 제한을 구체적으로 적으면 장기 작업의 정체와 슬롭을 줄일 수 있다.
5. 리뷰 꼬리가 핵심 병목이다: 빠른 첫 초안보다 여러 패키지를 함께 수정하고 봇 피드백을 해결해 최종 병합까지 도달하는 능력이 실제 생산성을 결정한다.
6. 자율 병합에는 경계를 둬야 한다: 버그 수정과 성능 개선은 자동 병합 후보가 될 수 있지만, 제품 방향 변경과 파괴적 작업은 사람 승인으로 남겨야 한다.
7. 데이터 정책은 기술 성능과 별개로 확인해야 한다: Anthropic의 강제 데이터 보존과 새 이력 편집 제한은 기업 도입·API 클라이언트·브랜칭 기능에 직접 영향을 준다.
8. 최종 평가: Fable 5.1은 압도적인 세대 전환이라기보다, 코딩 에이전트의 작업 단위를 생성에서 유지보수로 끌어올린 매우 강한 점 업데이트다. 더 많은 일을 맡길수록 한도와 위험도 커지지만, 사람의 시간을 더 높은 수준의 판단으로 이동시키는 방향은 분명하다.

핵심 요약 (20줄)

1. Fable 5.1과 Mythos 5.1은 가중치가 같은 모델이고 안전장치와 접근 경로만 다르다.

2. Fable 5.1은 코딩과 지식 노동에서 이전 Fable 5보다 높은 실사용 품질을 보인다.

3. 일반 입력·출력 단가는 같지만 캐시 읽기 가격은 75% 낮아졌다.

4. 고도 에이전틱 작업은 캐시 재사용 덕분에 최대 45% 비용을 절약할 수 있다.

5. 캐시 쓰기 비용은 실제 사용 비용의 거의 60%를 차지해 여전히 중요한 부담이다.

6. Terminal Bench에서 Low 점수는 21.5%에서 40%로, Max 점수는 45.8에서 55.8로 상승했다.

7. Cursor Bench에서도 약 73%의 점수와 작업당 9.64달러의 최고 비용을 기록했다.

8. Fable 5.1은 출력 토큰을 더 많이 쓰지만 결과의 가독성과 품질은 더 좋아졌다.

9. Mythos 5.1은 단백질 결합체 설계와 금성 지도 제작 같은 과학 작업에서도 강점을 보였다.

10. 계산생물학용 GPU 커널은 출력 품질을 유지하면서 최대 2.5배 빨라졌다.

11. Anthropic은 안전장치 오탐을 60% 줄였고 최근 모델에서 Critical 탈옥 증거를 찾지 못했다고 밝혔다.

12. 신규 계정의 과거 대화 편집 제한은 사고 흔적 보호와 API 브랜칭 구현에 영향을 준다.

13. 프런트엔드 디자인 스킬을 적용하면 애니메이션과 마케팅 페이지 품질이 세대적으로 개선된다.

14. Blender를 활용한 Fish Slop 3D 재구축은 물고기 형태와 수영 감각에서 가장 쓸 만한 출발점을 만들었다.

15. Low와 Medium도 강력하지만 숨은 복잡성을 놓칠 수 있어 작업별 평가가 필요하다.

16. 긴 도구 호출에서 업데이트를 원하면 시작·중간·종료 보고를 명시적으로 요청해야 한다.

17. 5.1은 요청 범위를 넓히거나 테스트를 과도하게 추가할 수 있으므로 보존·제외 범위를 직접 적어야 한다.

18. T3 Code와 Lakebed에서 89개 PR, 10개 정리 PR, 340개 파일, 순감 1만 3,000줄 삭제가 기록됐다.

19. 5.1은 Fable 5와 Soul보다 더 많은 파일과 패키지를 다루면서 고심각도 리뷰 발견을 줄였다.

20. Fable 5.1의 핵심 도약은 첫 응답 속도가 아니라 PR 리뷰와 병합까지 더 많은 일을 운반하는 능력이다.