Companion · AI Models · Playbook phân vai

Model Routing

Không model nào “best overall”. Phân vai.

Fable suy nghĩ và thiết kế → Sol giải quyết engineering khó và kiểm tra → Luna “cook” phần implementation đã rõ → Terra đi khám phá khi chưa hiểu repo.

Mở bảng so sánh model

Đây là gì. Playbook routing thực dụng, tổng hợp từ 6 discussion (kể cả field report trên Reddit). Đây không phải benchmark có kiểm soát — các thread còn trái chiều. Dùng làm default, rồi override bằng eval của bạn. Tên model khớp trang AI Models: Claude Fable 5, GPT-5.6 Sol / Luna / Terra, Claude Opus 5 / 4.8.

01Bốn vai

Coi roster là một team, không phải bảng xếp hạng. Model đắt nằm ở đầu workflow — không phải mọi commit.

Kiến trúc

Fable 5

Tư duy · thiết kế · UI taste

Đặt ở đầu workflow. Phản biện requirement yếu, thiết kế hướng maintainability, đóng kiến trúc. Consensus mạnh nhất: UI mới.

Kỹ sư

GPT-5.6 Sol

Implementation khó · audit

Senior engineer cho backend, auth, payment, migration, refactor nhiều file, focused review. Auditor production mặc định.

Worker

GPT-5.6 Luna

Daily driver · task có biên

Khi đã có plan: CRUD, test, docs, wiring, feature nhỏ. Đừng phí Fable/Sol cho chỉnh spacing nút.

Thám tử

GPT-5.6 Terra

Khám phá · không phải coder mặc định

Repo lạ, trace dependency, impact map. Terra tìm đường; Sol implement. Bỏ qua Terra khi đã biết phạm vi ảnh hưởng.

Fable
brainstormPRD / speckiến trúc UX / redesignUI cần tastesecond opinion
Sol
backend / APIauth / paymentsmigrations bug khófocused reviewprod audit
Luna
CRUD / formstests / docsrename / wiring feature nhỏsub-agents
Terra
repo lạtrace dependency impact analysisdebug khám phá

Thanh là heuristic routing, không phải điểm benchmark. Ghép với dashboard so sánh khi cần peak đã công bố.

02Bộ định tuyến task

Trả lời bốn câu. Path bên dưới là default hằng ngày — chỉ tăng effort sau khi pass rẻ hơn thất bại.

Path tương tác

Task trên bàn thuộc loại nào?

1. Requirement đã rõ chưa?
Spec, mockup, hoặc PLAN.md tin được — không phải vibe.
2. Đã biết code nằm đâu chưa?
File, module, hoặc root cause — không phải “đâu đó trong repo”.
3. Phạm vi ảnh hưởng thế nào?
Thấp: một module, cơ học, hoàn lại được. Cao: auth, data, payment, thư viện dùng chung, nhiều file.
4. Thay đổi có rủi ro với production không?
Ship sai thì user hoặc tiền bị tổn. Đó là lúc Fable xem lại.
Path khuyến nghị

03Routing mình khuyên dùng hằng ngày

Nếu chỉ nhớ một sơ đồ, nhớ cái này. Spec yếu thì nghĩ trước. Rồi tách theo phạm vi ảnh hưởng. Luôn review. Luôn để người merge.

Routing mình khuyên bạn dùng hằng ngày
Fable — tư duy / second opinion Luna — phạm vi ảnh hưởng thấp Sol — phạm vi ảnh hưởng cao / review Người — merge

04Khi không biết code nằm đâu

Đừng implement trước. Map trước. Terra là thám tử; Sol là kỹ sư.

Và khi không biết code nằm đâu
Terra — explore / trace / map Sol — implement từ map

05Bảng task

Pick mặc định, effort, và reviewer. Hàng gắn đồng thuận là chỗ các discussion thống nhất mạnh nhất.

Task Model tốt nhất Effort Backup / reviewer

06Fable 5 — kiến trúc / product / designer

Đặt Fable ở đầu workflow. Không nhất thiết để nó viết hết code. Một developer 10+ năm trong discussion nói Fable nổi ở planning, UI, kiến trúc, chủ động phản biện requirement không hợp lý, và thiết kế hướng scale/maintainability thay vì mặc định coi mọi thứ là MVP. Khi Fable review code của Sol, thường bắt được vấn đề lớn hơn chiều ngược lại.

Dùng Fable cho: discovery → brainstorm → PRD → architecture → UX/UI → implementation plan.

Ví dụ đi một feature

“Add AI quotation feature vào furniture manufacturing system.” Route Fable 5 High trước để nó:

  • hiểu business problem và challenge requirement
  • tìm missing cases, domain, data model, workflow, state transition
  • vẽ integration boundary, UX flow, non-functional
  • để lại implementation plan cho model khác execute

Một pattern trong discussion: Fable tạo/validate work order, model khác implement, Fable đóng architectural close-out.

UI là chỗ Fable có consensus mạnh nhất. UI mới / dashboard / landing / redesign → Fable. Nếu design system đã có và chỉ cần implement trung thành, Sol hợp hơn — rồi Fable visual review.

07Sol — senior implementation engineer / auditor

Nếu Fable là architect thì Sol là senior engineer chịu implementation khó. Ladder thực dụng từ discussion, playbook này giữ:

Sol mạnh ở service layer, API, DB, concurrency, cache, integration, hạ tầng; việc phạm vi ảnh hưởng cao (auth, permission, payment, migration, security, deploy, shared library); và thay đổi nhiều module, refactor phức tạp, regression, glue legacy.

So sánh code-review: Sol → focused review, Terra → broad tracing, Luna → edge case riêng — Sol token-efficient nhất trong test đó. Production audit mặc định Sol High.

08Luna — worker / daily driver

Đừng phí Fable/Sol vào đổi copy nút, thêm field, rename, CSS spacing, CRUD, map DTO, test, docs, refactor cơ học. Luna là lựa chọn hằng ngày khi task rõ và có biên.

Escalation trong discussion: Luna XHigh → Terra Medium → Sol Medium. Loop production thực tế playbook này dùng:

Luna High → Luna XHigh → Sol Medium. Không nhất thiết đi qua Terra mỗi lần.

Luna cực hợp khi đã có PLAN.md. Ví dụ handoff:

Task 1: add CustomerDiscountPolicy
Task 2: migration X
Task 3: update quotation API
Task 4: add validation
Task 5: update tests

Cho Luna từng task một. Pattern liên quan: Sol XHigh planning → product.md → Luna implementation.

09Terra — explorer, không phải implementer mặc định

Với Terra khi câu là “chưa biết bug nằm đâu” hoặc “hiểu subsystem này trước.” Broad tracing là Terra; focused review là Sol. Có map rồi thì ngừng khám phá và bàn giao.

Terra hợp codebase lạ, trace dependency, tìm chỗ implement, debug khám phá, reverse-engineer flow, impact analysis, và “mọi nơi feature này đụng tới.”

10Opus 5 không phải coding model mặc định

Đây là phần tranh cãi nhất, và tín hiệu tiêu cực là có thật. Một report production: Opus 5 nghe rất tự tin dù sót chi tiết nhỏ quan trọng; Fable và Sol đáng tin hơn. Người khác: Opus 5 tốt khi one-shot, nhưng để lại nhiều open loop nếu làm daily driver. Một tổ chức rollback từ Opus 5 về Opus 4.8 + Fable trên codebase phức tạp sẵn có.

Không dùng Opus 5 làm implementer chính. Dùng tốt hơn: second opinion, adversarial review, lời giải độc lập, task one-shot, so reasoning với Sol/Fable.

Nên: Fable → architecture, Sol → implementation, Opus 5 → adversarial review, Sol → fix. Không: Opus 5 → làm tất cả.

Giữ Opus 4.8 và GPT-5.5 khi chúng đã chạy tốt

Đừng bỏ model chỉ vì số version tăng. Opus 4.8 có thể giữ làm reviewer ổn định, triage bug, fact-check, hoặc implementer nếu harness cũ đã tối ưu cho nó. GPT-5.5 giữ cho task quen, prompt/harness đã proven, việc không cần sức 5.6, hoặc reviewer độc lập từ family khác.

11Đừng dùng Ultra mặc định

Đây là chỗ nhiều developer sai nhất. Nghĩ nhiều hơn không phải lúc nào cũng tốt hơn.

Sol Ultra bị phản ánh scope-creep, over-engineer, biến analysis thành implementation không được hỏi, tự mở rộng task, và tạo docs/code thừa. Một case: Ultra thiết kế security/robustness quá mức so với context. Việc quan trọng không tự thành vé Ultra.

Medium

Default cho việc Sol/Luna quen và có biên.

Bắt đầu đây
High

Trần hằng ngày cho kiến trúc, auth, DB, và hầu hết việc production.

Trần ngày
XHigh

Sau khi High thất bại, hoặc nút thắt dài hạn / nhiều file thật sự.

Tăng cấp
Max / Ultra

Chỉ khi nói được vì sao High và XHigh chưa đủ.

Phương án cuối

Escalate Medium → High → XHigh → Max/Ultra chỉ khi cần. Không bao giờ task quan trọng → Ultra.

12Workflow full-stack production

Phase 1

Think

Brainstorm, challenge, PRD, architecture, UX, plan.

Fable 5 High
Phase 2

Verify plan

Feasibility, security, DB, API, race, integration.

Sol High
Phase 3

Build

Nhỏ → Luna High. Thường → Luna XHigh / Sol Medium. Khó → Sol High.

Luna hoặc Sol
Phase 4

Review

Sol High cho correctness. Fable High cho kiến trúc nếu feature quan trọng.

Sol, rồi Fable
Phase 5

Người

Diff, test, migration, tương thích API, UI, security, requirement.

Bạn merge

13Nếu chỉ được chọn 2 hoặc 3 model

Core 3 model

Fable 5 nghĩ (architect + product + UI). Sol engineering (implementation phức tạp, backend, audit, debug). Luna làm việc hằng ngày. Bỏ Terra khỏi core loop trừ khi cần khám phá.

Combo 2 model mạnh nhất

Fable 5 + GPT-5.6 Sol. Hai family tạo adversarial redundancy: một viết, một check. Nhiều discussion khuyên giải bằng Fable hoặc Sol rồi dùng model còn lại double-check.

Fable
Brainstorm · kiến trúc · PRD
Sol
Implement · test · audit
Fable
Review kiến trúc cuối

14Bảng vai

Cấu hình playbook này sẽ chạy với tư cách senior full-stack default.

Architect / UI / PRD
Fable 5 High
Repo explorer
Terra Medium
Main engineer
Sol Medium / High
Hard debugger
Sol High / XHigh
Security / auth / DB
Sol High
Code auditor
Sol High
Worker / routine code
Luna High / XHigh
Second opinion
Fable ↔ Sol
Reviewer thay thế
Opus 5 / GPT-5.5 / Opus 4.8
Ultra / Max
Chỉ khi escalate có lý do