# Meta bắt kịp Anthropic: Theo dùng thử Muse Wonder Full

[Theo Browne](https://homus.dev/speakers/theo-browne) · [Theo - t3․gg](https://homus.dev/orgs/theo-t3-gg)

> Theo thử Muse Wonder và Wonder Full của Meta: điểm yếu 3D và UI, orchestration, review code, bench tự làm, token efficiency so với Opus và GPT.

Topics: Model Routing, Coding Agents, Evals

Canonical: https://homus.dev/talks/meta-just-caught-up-with-anthropic

## 1. Một lab ngoài OpenAI và Anthropic đã chạm tới hàng đầu

Theo mở đầu bằng câu "cuối cùng thì chuyện đó cũng xảy ra": theo anh (video đăng ngày 13/10/2026), một lab không mang tên OpenAI hay Anthropic đã ship một model cùng hạng với Fable và Astra. Anh biết nghe thì điên rồ, nhưng nó có thật. Meta đã quay lại theo cách anh chưa bao giờ nghĩ sẽ thấy. Anh từng khá hào hứng với Muse Spark 1.2; bản 1.3 thì anh không làm video riêng, nhưng đó là một model tạm được. Anh không ngờ Muse Wonder lại làm anh choáng theo những cách như vậy. Anh đã dùng model này vài ngày và thật sự ấn tượng. "Khi các bạn nhìn benchmark, các bạn sẽ hiểu. Ví dụ, đây..."

Rồi anh dừng lại, vì thứ hiện lên trên màn hình không phải benchmark: "Khoan. Đó là một cái UI vibe-code xấu tới mức tội lỗi mà Muse làm ra lúc tôi đang test nó. Không thể đúng được." Anh chuyển sang trang khác (video đăng ngày 13/10/2026), và lần này là một đống lời người ta nói về anh chỉ vì anh thích model này: "Theo bị mua chuộc rồi, hết uy tín", "khó tin là Meta không trả tiền cho anh để nói vậy", "sao gã này tweet như được Meta trả tiền vậy", "họ trả anh bao nhiêu". Anh không biết tài khoản viết câu cuối là ai, nhưng theo anh (video đăng ngày 13/10/2026), các con số thật thì trông khá ổn.

Theo những gì anh đọc lên (video đăng ngày 13/10/2026), không chỉ Muse Wonder và Wonder Full là một bước nhảy lớn so với Spark 1.3, mà lượt chạy Wonder Full ở mức Max còn có vẻ đã vượt mọi model của OpenAI trên Artificial Analysis, đưa Meta lên vị trí thứ ba tổng thể, theo anh là khá điên. Vậy model này có gì? Nó có thật sự đã hất OpenAI khỏi vị trí lab đứng thứ hai không? Nó có tốt như các bench gợi ý không? Anh có nói nhảm không, có bị mua chuộc để nói những điều này không? Anh trả lời: Meta không trả anh một xu nào. Anh may mắn được test kỹ model này, và anh sẽ kể cho người xem nghe.

![Theo Browne ngồi trước micro trong phòng tối, cạnh một chiếc laptop](https://homus.dev/photos/DbWL6Zs2j_g-0003.jpg)

Theo Browne mở đầu video về Muse Wonder, model mới của Meta mà anh đã dùng vài ngày trước khi quay.

## 2. Điểm trừ đầu tiên: hai model, một cái tên khó chịu

Lần này Theo làm hơi khác: anh bắt đầu bằng những điểm tiêu cực, cho xong một lượt rồi mới tới phần anh thích. Điều đầu tiên anh ghét ở đợt ra mắt này (video đăng ngày 13/10/2026) là nó không phải một model mà là hai: Muse Wonder và Muse Wonder Full. Đúng vậy, "Wonder Full" đọc lên như chữ "wonderful", một kiểu chơi chữ, nhưng được viết là Wonder, dấu cách, Full. Bình thường chuyện này không đáng gì, chỉ là đặt tên hơi "cringe", nhưng khoảng cách giữa hai model thì rất lớn.

Theo những gì Theo nói trong video (đăng ngày 13/10/2026), Muse Wonder chạy khoảng 120 token mỗi giây, còn bản Full chỉ khoảng 50, nên rõ ràng đó là một model khác, lớn hơn. Chuyện này cũng sẽ không đáng phàn nàn ngoài cái tên, nếu không vì một điều: tại thời điểm video đăng (13/10/2026), chỉ Muse Wonder có trên API và có giá. Bản Wonder Full chỉ dùng được qua gói đăng ký Muse Code. Theo anh, điều đó khiến model rất khó đo, nhất là đo giá so với hiệu năng: không có cách nào đặt bản Full lên trục giá, vì Meta chưa bao giờ đưa ra giá cho nó.

![Trang công bố của Meta: Muse Wonder có qua Meta Model API và Muse Code, Muse Wonder Full cho người đăng ký Muse Code](https://homus.dev/photos/DbWL6Zs2j_g-0301.jpg)

Trang công bố của Meta mà Theo mở trong video: Muse Wonder có qua Meta Model API và Muse Code, còn Muse Wonder Full chỉ dành cho người đăng ký Muse Code (tại thời điểm video đăng, 13/10/2026). Trang cũng nhắc tới Active Memory và Active Focus.

## 3. Không có giá cho bản Full, và bảng benchmark của Meta

Một điểm "cringe" khác theo Theo: Meta không đưa thông tin giá vào bất kỳ chỗ nào trong bài công bố. Họ thì có khoe các con số rất đẹp từ những lượt chạy Full ở mức Max, cho thấy theo bảng của Meta (công bố ngày 12/10/2026) bản này vượt Fable, Astra và Opus 5.5 ở khá nhiều bench. Memory có vẻ là một trong những trọng tâm chính của model. Meta kể họ đã huấn luyện nó hiểu cách memory vận hành ngay trong giai đoạn post-training, để những ý tưởng đó "ngấm" vào model; Theo thấy điều này hay, mới và thú vị, và tò mò về lâu dài nó sẽ ra sao.

Theo Theo đọc bảng của Meta (video đăng ngày 13/10/2026), điểm Terminal Bench "điên rồ": bỏ xa Fable 5.1 và tiến sát Astra và Opus 5.5. Bản Full đạt state-of-the-art trên DeepSWE và SWE-Marathon. Nhưng lại một lần nữa, không ai biết giá. Họ đơn giản là không công bố con số. Nghe nói Meta đang thiếu compute trầm trọng, nhưng theo anh ít nhất họ nên nói nó sẽ tốn bao nhiêu để mọi người có số mà tham chiếu. Thôi thì đành vậy.

![Bảng kết quả của Meta so sánh Muse Wonder Full, Muse Wonder, Claude Fable 5.1, GPT-6 Astra và một model khác](https://homus.dev/photos/DbWL6Zs2j_g-0403.jpg)

Bảng đánh giá trong bài công bố của Meta (12/10/2026): các cột Muse Wonder Full (max), Muse Wonder (max), Claude Fable 5.1 (max), GPT-6 Astra (max) và một cột bị che, trên các bench cho agent cá nhân và chuyên nghiệp như Personal Superintelligence Index, Harvey LAB-AA, Vals Finance Agent V2, HealthBench Pro.

May là có giá cho Muse Wonder bản thường. Theo trang giá Theo mở trong video (13/10/2026): 4 đô cho mỗi triệu token input, 20 đô cho mỗi triệu token output, và 0,20 đô cho cache read. Theo anh, mức đó rẻ hơn Opus một chút, và điều này khá tệ, vì đây không phải bản Full mà Meta khoe trong nhiều benchmark, cũng không phải bản anh đặc biệt thích; đây là bản nhỏ hơn nhiều. Từ đó anh suy ra (video đăng ngày 13/10/2026) rằng bản Wonder Full nhiều khả năng sẽ có giá cao hơn hẳn, có thể còn cao hơn Opus 5.5, và đó là thứ anh nghĩ hoàn toàn không đáng tiền.

Anh hứa phần còn lại sẽ đáng chờ: còn vài điểm trừ nữa, và khi nói xong hết, anh sẽ chuyển sang "chế độ khen" để giải thích mọi thứ anh thích ở model này, vì anh thật sự đang rất thích dùng nó (video đăng ngày 13/10/2026).

## 4. Điểm trừ thứ hai: 3D, từ chiếc máy kéo tới Fishslop

Vấn đề tiếp theo là khả năng 3D. Theo nói thẳng (video đăng ngày 13/10/2026): không tốt. Một demo so sánh Opus 5.5 với Muse Wonder Full dựng một chiếc máy kéo, và bản của Muse không đẹp. Anh cũng nhảy luôn tới phần thường để dành cho cuối video: bài test Fishslop, một game 3D dưới nước mà anh cho các model tự làm. Kết quả cũng không tốt.

Có tệ như Grok 4.7 không? Không, hoàn toàn không. Thật ra chuyển động và cơ chế chính khá ổn. Nó cũng có những animation anh chắc chắn đã thấy ở đâu đó. Theo nhận xét của anh (video đăng ngày 13/10/2026), có vẻ nhiều model đã nhận một bộ dữ liệu và harness giống nhau để huấn luyện 3D. Nếu Meta cũng có harness đó, thì họ dùng nó tệ nhất mà anh từng thấy, vì trớ trêu thay model này rất dở ở chính việc làm model 3D: những thứ nó dựng trong Blender là "rác". Cách nó xử lý màu sắc và ánh sáng ở hai bên cũng kém. Nhưng ít ra game chạy được và chuyển động có cảm giác tốt, điều mà Grok không làm được gần như vậy.

![Game Fishslop do Muse Wonder Full làm: một con cá máy giữa bể nước có san hô, thanh chọn cá ở dưới](https://homus.dev/photos/DbWL6Zs2j_g-0603.jpg)

Bản Fishslop của Muse Wonder Full, theo video đăng ngày 13/10/2026: cá đi lại và điều khiển được, có thanh mua cá ở dưới (Guppy, Star Guppy, Carnivore, Breeder, Egg piece), nhưng mô hình 3D, màu và ánh sáng thô.

Theo so sánh của Theo trong video (13/10/2026): bản này tốt hơn bản của Haiku, nhưng cả Sonnet và Opus đều "đè bẹp" nó. Fable dĩ nhiên cũng hơn hẳn, dù khả năng 3D của Fable không cao bằng. Anh lưu ý rằng chính Meta cũng thừa nhận điều này: tài liệu của model có một mục giới hạn, trong đó ghi rõ suy luận thị giác và không gian, đặc biệt là các tác vụ 3D, vẫn là một giới hạn đã biết.

## 5. Vì sao "thông minh" không đồng nghĩa với "giỏi 3D"

Theo đã đăng về chuyện này trên Twitter và nhiều người bực, nên anh "nói thêm cho rõ" ở đây (video đăng ngày 13/10/2026): model code thông minh nhất thế giới cũng sẽ không giỏi 3D nếu không được huấn luyện riêng cho nó. Anh muốn nhấn mạnh rằng bước nhảy gần đây về 3D ở các model không phải vì chúng bỗng giỏi tới mức tự làm được 3D. Những thứ như 3D, như computer use, rất nhiều khả năng mà mọi người thích và hào hứng, không tự nảy sinh khi model thông minh hơn. Chúng được huấn luyện riêng vào model trong post-training, bằng những môi trường được tạo ra cho đúng các tác vụ đó.

Theo quan sát của anh (video đăng ngày 13/10/2026), có vẻ có một môi trường huấn luyện 3D tốt do một công ty bên ngoài làm ra và bán cho các lab. Anh nhận ra điều này lần đầu với Kimi K3, khi anh bình luận rằng model đó giỏi 3D và Blender một cách bất ngờ. Từ đó, các model từ những lab frontier đều có bước nhảy tương tự.

Chỗ thấy rõ nhất, theo anh, là từ Fable 5.1 sang Opus 5.5. Opus 5.5 rõ ràng tốt hơn ở nhiều việc, rẻ hơn rất nhiều, và quan trọng nhất ở đây là mới hơn. Fable 5.1 có lúc thông minh hơn, có lúc hơi kém hơn, đắt hơn rất nhiều, nhưng không ai phản đối rằng Fable 5.1 là model lớn hơn và có thể có năng lực cao hơn. Vì vậy, dù hai model chỉ chênh nhau khoảng cộng trừ 5%, bước nhảy lớn về 3D của Opus 5.5 mới ấn tượng, và nó cũng cho thấy độ thông minh của model không ánh xạ thẳng sang khả năng 3D (nhận định của Theo, video đăng ngày 13/10/2026).

Ý anh là: nếu một model kém tổng thể mà giỏi 3D, thế là khá ấn tượng. Nếu một model giỏi tổng thể mà kém 3D, vẫn ấn tượng. Còn nếu một model kém tổng thể và kém cả 3D, thì model đó có lẽ dở thật. Người xem cứ gọi anh là mâu thuẫn, nhưng (video đăng ngày 13/10/2026) anh không nghĩ nên dùng model này cho bất cứ thứ gì liên quan tới 3D.

Nếu 3D là thứ bạn quan tâm, lời khuyên của anh là đăng ký gói Claude và đừng phàn nàn: theo anh (video đăng ngày 13/10/2026), đó là giá trị không thể tin được so với số tiền bỏ ra. Nếu bạn đang tìm cách tiêu tiền cho AI hiệu quả nhất lúc quay video, thì theo anh đó không phải GPU chạy local, không phải một gói giá rẻ kỳ lạ của một lab Trung Quốc nào đó, và chắc chắn không phải trả tiền token qua một dịch vụ API trung gian cho model. Gói Claude Code 200 đô, theo anh tại thời điểm video đăng (13/10/2026), là một giá trị tốt tới khó tin.

Câu hỏi cuối cùng anh cần trả lời: dùng được bao nhiêu với gói Muse Code 50 đô và 200 đô (mức giá theo video đăng ngày 13/10/2026)? Anh không biết, vì anh chưa đăng ký gói nào. Anh vẫn đang dùng API key mà Meta gửi cho. Đó là thứ anh muốn thử sau, nhưng hiện anh không có thời gian, và anh muốn ra video sớm để phản hồi những điều người ta đang nói về model này, vì theo anh phần lớn trong đó khá ngớ ngẩn, và anh muốn cho thấy vì sao anh thích nó tới vậy.

## 6. SkateBench: một điểm số lạ giống Gemini

Tới lúc phần tích cực bắt đầu. Điểm đầu tiên hơi ngớ ngẩn: Theo chạy model trên SkateBench, bench của anh mà lâu rồi anh không đưa vào video, vì nó thường cho ra những kết quả kỳ lạ. Ví dụ, theo bảng của anh (video đăng ngày 13/10/2026), Opus 5 Max được 84%, còn Opus 5.5 Max chỉ 79%. Anh để ý rằng RL thường làm model tệ đi trên bench này. Đây là một bench lạ, nhưng xem các model xử lý nó thế nào thì vui.

Theo anh (video đăng ngày 13/10/2026), dòng model duy nhất từng vượt 90% là Gemini: Gemini 3.1 Pro được 96%, Gemini 3.8 Flash High cũng 96%. Không model nào khác tới gần những con số đó, cho tới Muse Wonder Full với 95%.

![Terminal chạy SkateBench v2 với bảng điểm nhiều model: tỉ lệ đúng, chi phí, token trung bình, TPS](https://homus.dev/photos/DbWL6Zs2j_g-0915.jpg)

SkateBench v2 trong terminal của Theo (theo video đăng ngày 13/10/2026): muse-wonder-full 95%, muse-wonder 81%, muse-spark-1.3 82%, gemini-3.1-pro-preview 96%, gemini-3.8-flash-high 96%, claude-opus-5-max 84%, claude-opus-5.5-max 79%. Cột TPS ghi 120.1 cho muse-wonder và 34.8 cho muse-wonder-full.

Điều này có thể đáng lo nếu bạn biết anh nghĩ gì về các model Gemini, nhưng anh giải thích. Theo anh (video đăng ngày 13/10/2026), model Gemini có khả năng hiểu những ngữ pháp phức tạp và suy luận 3D một cách khó tin, không phải theo nghĩa làm game 3D, mà theo nghĩa hiểu các phép biến đổi 3D "trong đầu", nói vậy cho dễ hình dung. Chúng cũng giỏi gắn nhãn trong ảnh: đưa một bức ảnh và bảo gắn nhãn những thứ trong đó, chúng chọn đúng pixel và làm được loại việc ấy. Không hiểu vì sao, tất cả những thứ đó cộng lại khiến Gemini giỏi gọi tên các cú trick trượt ván. Muse có vẻ cũng mang chút "cái lạ" đó trong mình.

Và thật lòng điều này làm anh sợ. Anh lo (video đăng ngày 13/10/2026) rằng nếu Meta làm đúng cái gì đó mà Gemini đã làm để có khả năng này, thì có thể nó cũng làm model kém đi ở những chỗ khác. Nên anh định xem thử những chỗ khác đó.

## 7. Điểm trừ cuối: UI rất tệ

"Được rồi, tôi nói dối." Còn một điểm tiêu cực nữa trước khi đi sâu: theo Theo (video đăng ngày 13/10/2026), model này làm UI rất tệ. Không chỉ tệ, mà "kinh khủng". Nó không làm UI sai theo kiểu Grok hay làm, mà làm ra UI "slop" giống như Sonnet 3.7 từng làm.

Nên nếu bạn muốn một model toàn năng, làm được mọi thứ từ debug kernel tới làm UI đẹp tới xây game, thì theo anh (video đăng ngày 13/10/2026) hãy quay về Claude. Bạn sẽ tìm thấy điều đó ở đó, không phải ở đây. Vậy anh thích gì ở model này, sau khi vừa dành mười phút để chê nó? Anh sẽ cho xem.

## 8. Audit ThunderStore: một vị slop chưa từng nếm

Theo bắt đầu ở một chỗ hơi lạ. Dạo này anh chơi một game tên ReSkate: một wrapper open source cho bản EA Skate đang có trên Steam, chạy peer-to-peer, cho phép mod game và chơi lại các map cũ. Anh rất thích nó. Nhưng cửa hàng mod của nó, cụ thể là ThunderStore, anh để ý thấy (video đăng ngày 13/10/2026) index rất, rất chậm. Vì nó open source, anh nghĩ sẽ thú vị nếu ném model mới vào việc audit để tìm xem cái gì làm nó chậm.

Vậy anh ấn tượng ở điểm nào? Câu trả lời có chu đáo không? Nó có đưa ra một bộ thay đổi hay không? Có mở PR không? Không, không phải những thứ đó. Anh chỉ đọc nguyên văn những gì nó viết: audit xong, báo cáo đầy đủ nằm trong một file. Phát hiện chính: cấu hình CDN ổn; sự chậm đến từ dữ liệu không cache tốt. Bản thân ReSkate nhỏ: index của nó chỉ 0,48 MB và tải trong 0,78 giây trên một edge đã "ấm" (số do model đo, theo video đăng ngày 13/10/2026). Vấn đề xảy ra ở các đường đi "lạnh" và khi lên quy mô.

![T3 Code hiển thị báo cáo audit hiệu năng ThunderStore do Muse Wonder Full viết](https://homus.dev/photos/DbWL6Zs2j_g-1203.jpg)

Báo cáo audit "Mod Index and Download Performance Audit" do Muse Wonder Full viết trong T3 Code sau 5 phút 49 giây (theo video đăng ngày 13/10/2026): phát hiện chính, rồi năm vấn đề lớn nhất theo thứ tự (index chunk xếp theo lần cập nhật cuối, mỗi lượt tải đều chạm origin, API cũ trả cả payload qua Django worker, cache header yếu, icon PNG đầy kích thước).

Anh hỏi người xem có nhận ra điều anh nhận ra không: anh không ghét đọc đoạn này. Thậm chí anh gần như thích đọc. Anh nói rõ: không phải anh bảo đây không phải slop. Theo anh (video đăng ngày 13/10/2026), đây là một vị slop khác, một vị anh chưa từng nếm. Và nó không có vị của "thêm một bản chưng cất từ Claude nữa", điều hiếm và rất dễ chịu. Nhất là khi nghĩ tới khối lượng dữ liệu Claude khổng lồ gắn với hoá đơn rất lớn với Anthropic: anh từng nghĩ các model của Meta từ nay sẽ nói và hành xử như Claude vì họ có quá nhiều dữ liệu từ Claude. Model này thì không.

Anh cũng thấy người khác có trải nghiệm rất khác khi trò chuyện với model này. Nên anh làm một test rất ngắn: bỏ vài dòng dặn dò trong file agent MD của anh, những dòng như "tôi bị ADHD, hãy viết ngắn và dễ đọc, thay đổi độ dài câu một chút, dùng tiếng Anh kỹ thuật đơn giản khi hợp lý". Khi bỏ đi, model dài dòng hơn khá nhiều. Anh nghĩ mặc định của model này chưa hẳn là dễ chịu nhất khi tương tác. Nhưng khi anh chạy nó trên máy mình, không đổi gì, chỉ dùng agent MD bình thường của anh, nó ngay lập tức thành model anh thích làm việc cùng nhất, chỉ vì cách nó nói chuyện. Vậy anh có đánh đổi nhiều trí thông minh để có điều đó không? Tuỳ tác vụ, nhưng nhìn chung theo anh (video đăng ngày 13/10/2026) là không.

## 9. Dự án Lust: Muse và Opus làm cùng một việc

Một side project mới mà Theo thấy vui là Lust: một tập con của Rust mà anh muốn compile nhanh hơn 100 lần (mục tiêu anh nêu trong video đăng ngày 13/10/2026). Vì anh từng viết lại được compiler TypeScript bằng Rust, anh nghĩ sao không thử viết compiler riêng cho ngôn ngữ riêng của mình, rồi compile lại TS Rust bằng ngôn ngữ đó, cố hết sức tìm những thứ các model không làm được.

Thread này đã chạy khá lâu. Theo anh (video đăng ngày 13/10/2026), qua các lượt chạy nó đã sinh ra hơn 115 agent để chia nhỏ công việc. Có lúc anh yêu cầu nó bắt đầu chạy mọi task trên cả Muse lẫn Opus, rồi lập một hội đồng giám khảo để review thay đổi của cả hai, để anh có cái mà so sánh. Ở đây anh hỏi cập nhật: "Cho tôi cập nhật xem Muse so với Opus đang thế nào."

![Thread lust-lang trong T3 Code: bản tóm tắt so sánh Opus và Muse, kèm danh sách agent đang chạy](https://homus.dev/photos/DbWL6Zs2j_g-1443.jpg)

Thread "Rust-like Language With Faster Builds" chạy bằng Claude Opus 5.5 (theo video đăng ngày 13/10/2026): phần "Short version", "Head to head (T2 bake-off, cold-check speed)" và "Muse in daily work". Cột bên phải là danh sách agent đang chạy (Lineage, 9 running) với 105 agent trước đó.

Bản tóm tắt (do Opus viết, đọc lên trong video đăng ngày 13/10/2026): Opus làm việc đúng hơn, sâu hơn; Muse làm được nhiều việc hơn và nhanh hơn; Muse cũng là một reviewer tốt bất ngờ. Cả ba giám khảo "mù" đều chọn Opus. Điểm trung bình chênh khá phũ: 41 so với 30, trên thang 50. Bản build của Opus nhanh hơn khoảng 2,5 lần, và thay đổi của nó không làm đổi hành vi nào. Rồi Theo tự đính chính: đó chỉ là cho một task cụ thể, bản của Opus nhanh hơn, bản của Muse có bug, khá tệ.

Còn cảm giác tổng thể thì sao? Theo bản tóm tắt của Opus (video đăng ngày 13/10/2026), trong việc hằng ngày, Muse tạo ra phần lớn các thay đổi được merge, và một số kết quả rất tốt: nó sửa một loạt chỗ khiến chương trình được chấp nhận khi lẽ ra không, sửa nhiều thứ ở tầng driver, sửa bug về tên. Ở vai reviewer, nó kỹ và chính xác: nó viết 209 probe nhắm vào các bản sửa của Opus và đưa ra các nhóm sửa rõ ràng. Ở vai giám khảo, nó công bằng: nó tự xếp bài của chính mình thứ hai.

Nhiều lần Theo cho cả Opus và Muse cùng báo cáo về một việc, đào vào code, đề xuất hướng sửa một vấn đề, và anh ngạc nhiên vì Opus hay chọn kế hoạch của Muse. Công bằng mà nói, trong nhiều trường hợp đó Muse cũng chọn kế hoạch của Opus. Nhưng khi anh cho hai model nói chuyện với nhau (anh nói "không phải tự quảng cáo", đây là một tính năng anh thấy rất hay trong T3 Code tại thời điểm video đăng, 13/10/2026), mỗi bên tự làm phần mình rồi trao đổi, chúng thường thống nhất lấy kế hoạch của Muse làm nền, thêm góp ý của Opus. Điều đó khiến anh khá bất ngờ.

Sau nhiều qua lại, theo những gì Theo đọc trong video (đăng ngày 13/10/2026), Opus, model đang chạy thread này, kết luận rằng Muse hợp với phần lớn công việc: sửa lỗi, làm standard library, fuzzing và review. Opus làm những phần khó, nơi một thiết kế sai sẽ đắt, như việc merge T2 speed và các bản sửa trait system. Mỗi bên review việc của bên kia, và mọi review đều được biến thành bản sửa. Opus chấm Muse B+ và tự chấm mình A-, nói rằng nó chất lượng cao hơn nhưng chậm hơn và tốn hơn. Theo nhắc: thật ra chưa ai biết Muse tốn bao nhiêu, nên hãy hiểu nhận định đó theo cách bạn muốn.

## 10. Orchestration: Muse viết prompt cho subagent

Theo muốn nói thêm về cách model này giao việc và nói chuyện với các model khác, vì đó là điều làm anh rất ấn tượng. Trong video (đăng ngày 13/10/2026), anh vừa làm một test nhanh: bảo nó tạo ba delegate để khám phá và phân tích các phần khác nhau của codebase T3 Code, dùng slug hiện tại cho model alpha và Haiku 5.5. Trên màn hình, Muse Wonder Full chia ba phạm vi: server và orchestration (`apps/server`) giao cho model alpha `restful-walrus-ultra`; client web, desktop, mobile giao cho `claude-haiku-5-5`; contracts và provider adapter giao lại cho `restful-walrus-ultra`. Nó cũng dặn mỗi delegate phải đọc code thật trước khi kết luận, liệt kê file đã xem, nêu câu hỏi còn mở, và không delegate nào được sửa file.

Rồi anh mở một subagent để xem Muse tự viết prompt cho nó như thế nào. Đây là prompt nó gửi đi, nguyên văn trên màn hình:

```
Act as the research sub-agent for this task.

Explore and analyze the T3 Code contracts and provider and agent integration layer. Scope: packages/contracts, packages/shared, and how providers (Codex, Claude, Cursor, Grok, OpenCode, Antigravity) and MCP or agent tools connect to the server.

Requirements:
- Read actual implementation bodies for every claim you cite. Search results only locate candidates. Do not cite a file you did not open.
- Map: what crosses the wire, how contracts are defined and used by server and clients, and how a provider adapter translates a native protocol into orchestration events.
- Note where provider differences are handled, and any contract or adapter risks you find in the code.
- Keep the report compact. Use simple, clear English. End with: files inspected (list paths), open questions or unresolved items, and 3 to 5 key findings with file evidence for each.
- Do not edit any files. This is analysis only.
```

Theo đọc lướt: vai trò, phạm vi, yêu cầu "đọc phần thân implementation thật cho mọi khẳng định, kết quả search chỉ để tìm ứng viên, không trích file chưa mở", phần map, "vân vân", và "không sửa file nào, chỉ phân tích". Theo anh (video đăng ngày 13/10/2026), đây là một prompt rất tốt để một model gửi cho subagent, và điều đó khiến model này giỏi orchestration, cả khi điều phối chính nó lẫn khi điều phối model khác.

Anh thấy nó là một "chỉ huy" khá tốt: model đứng giữa chuyển tin nhắn qua lại với những thứ khác, xử lý việc steering tốt, và nói chung làm việc với các model khác rất ổn. Anh ngạc nhiên vì theo kinh nghiệm của anh (video đăng ngày 13/10/2026), đây là một trong những thứ mà các lab không mang tên Anthropic hay OpenAI thường gặp khó. Ở đây thì hoàn toàn không. Theo anh, model này thật sự giỏi khiến các model khác làm việc cho nó, và nó cũng xử lý được rất nhiều việc điều phối chạy cùng lúc, lại một kỹ năng hiếm.

## 11. Frontier vị thứ ba, thiên kiến của người review, và chuyện "ít ngu"

Tất cả những điều trên là lý do Theo nghĩ model này thật sự có cảm giác "gần frontier". Nó có những điểm kỳ quặc, không mạnh bằng ở vài chỗ mà anh hứa sẽ nói thêm. Nhưng theo anh (video đăng ngày 13/10/2026), đây là model đầu tiên không đến từ hai lab kia mà anh không nghi ngờ khả năng chạy các task dài, và là model đầu tiên từ một lab khác mà anh thấy điều phối subagent và workflow tốt như vậy. Ý anh là model này là một "vị frontier thứ ba": có ưu, có nhược, sẽ có một mức giá có lẽ không dễ chịu, nhưng nó khác. Và anh rất thích cái khác đó.

Anh nói (video đăng ngày 13/10/2026) đây là chỗ người xem nên tính tới thiên kiến của anh. Là người review model rất nhiều, một thứ khác biệt tự nhiên sẽ làm anh thích. Anh nhớ lại thời làm trong mảng audio: một người review nhiều loa có thể thích một chiếc loa mới hơn mức nên thích, chỉ vì nó khác. Thậm chí vì nó "sai" theo vài cách, bởi họ đã quá quen với việc mọi chiếc loa đều cố giống nhau, chỉ to hơn một chút hay nhỉnh hơn một chút ở vài mặt, nên một chiếc loa có âm thanh hoàn toàn khác khiến họ hào hứng. Anh biết đó là một phần lý do anh thích model này đến vậy: nó có cảm giác, cách nói và cách làm hơi khác, mà không ngu.

Và đó là điều khác anh rất thích: sự thiếu vắng những cái ngu. Theo anh, model này chưa làm điều gì ngu ngốc trắng trợn. Nghe khá lạ: trong bốn tới năm ngày anh đẩy nó tới giới hạn, anh gặp ít trải nghiệm ngớ ngẩn hơn so với ba mươi phút chuẩn bị video với Sol và Astra (trải nghiệm của Theo, video đăng ngày 13/10/2026). Chỉ trong một thread, anh gặp nhiều chuyện "điên" với Astra hơn tổng số lần với model này. Anh nói không hề phóng đại.

Nó đơn giản là không làm chuyện ngu. Anh còn nói (video đăng ngày 13/10/2026) nó hơi ít ngu hơn cả Opus. Nếu chấm độ ngu, anh cho Astra 10 trên 10, "ngu kinh khủng". Điều đó không có nghĩa là nó không thông minh: thông minh và ngu là hai đặc điểm khác nhau, có thể có cả hai. Astra rất thông minh và rất ngu. Opus còn thông minh hơn và ít ngu hơn nhiều; anh chấm Opus khoảng 3 trên 10 về độ ngu và 10 trên 10 về độ thông minh. Model này thì kém hơn ở phần thông minh, trần thấp hơn một chút, khoảng 8 hoặc 9 trên 10. Nhưng độ ngu thì còn thấp hơn, khoảng 1 hoặc 2 trên 10.

Thang chấm cảm tính của Theo (video đăng ngày 13/10/2026): Astra "rất thông minh và rất ngu" (ngu 10/10), Opus 10/10 thông minh và 3/10 ngu, Muse Wonder Full 8 đến 9/10 thông minh nhưng chỉ 1 đến 2/10 ngu.

Nó không làm chuyện ngu, nó làm chuyện xấu: dở front-end, dở 3D. Nhưng nó không làm điều ngớ ngẩn. Theo anh (video đăng ngày 13/10/2026), anh không nghĩ model này sẽ mắc những lỗi kiểu xoá một folder hay thư mục không được xoá, hay tự đưa mình vào trạng thái hỏng, như anh đã thấy mọi model khác làm vào lúc nào đó. Nó cư xử tốt. Rồi anh đưa ra một ví dụ "ngớ ngẩn" mà anh nghĩ sẽ cho thấy rõ vì sao anh thích dùng model này.

## 12. Bug cập nhật máy remote: Opus, Sol và Muse cùng một prompt

Không lâu trước khi quay video (đăng ngày 13/10/2026), Theo thêm vào T3 Code một tính năng cập nhật từ xa mọi máy và mọi provider của chúng chỉ với một cú bấm. Về kỹ thuật là hai cú bấm: bấm nút ở dưới, rồi bấm xác nhận. Anh để ý nó không cập nhật runtime T3 Code trên các máy remote. Nguyên nhân hoá ra là một bug khá lạ và ngách.

Đầu tiên anh cho xem lượt chạy với Opus (video đăng ngày 13/10/2026). Opus có lúc bối rối vì nó kiểm tra lịch sử và thấy instance đã được cập nhật. Nên khi nó đang chạy, anh gửi một câu steer ngắn: "Tôi đã chạy cập nhật bằng tay sau đó", để nó biết bản cập nhật đã được chạy, đó là lý do nó thấy bản mới. Không phải chạy trễ, mà anh chạy tay sau khi nó không chạy như lẽ ra phải chạy. Từ đó Opus làm đúng: tìm ra bug và sửa, bản sửa chưa commit trong worktree, nguyên nhân thế này thế kia. Theo anh, phần "log cho thấy gì" thì quá nhiều chữ: nó liệt kê mọi thứ đã xảy ra, bản sửa, các bước kiểm tra, rằng việc kiểm tra vẫn thất bại im lặng nếu không kết nối được npm, rồi hỏi có nên mở PR không. Anh trả lời "full stop" để gọi skill của anh cho việc này; nó cho Sol review, rồi mở PR. Mọi thứ trông khá ổn.

So với cách Sol xử lý: anh gửi đúng prompt đó. Theo anh (video đăng ngày 13/10/2026), Sol chạy quá nhiều thứ. Nó nói phần settings ở sidebar dùng quy tắc khác để chọn bản cập nhật cho máy remote. Nó có vẻ không nhận ra rằng anh vừa đổi đúng chỗ đó; anh còn ghi trong prompt rằng luồng "update everything" mới không cập nhật môi trường remote, nhưng nó không để ý chữ "mới". Theo anh, đây là một phần điều anh không thích ở các model OpenAI: có cảm giác nó đôi khi "đánh rơi" những từ quan trọng trong đầu và mất dấu rằng chính thay đổi mới là thứ quan trọng.

Sau đó, trong lượt chạy anh cho xem (video đăng ngày 13/10/2026), anh gặp lỗi vì công cụ async questions của họ không chạy đúng với proxy của anh. Theo anh, một phần lỗi do anh, một phần do họ, nhất là vì chính Sol đã sửa proxy để hỗ trợ việc này. Dù sao, anh bảo nó tiếp tục để thoát khỏi trạng thái hỏng. Nó báo đã sửa cục bộ: sidebar loại các server remote khi việc kiểm tra npm đang chờ hoặc thất bại, và nó bỏ luôn việc kiểm tra. Theo Theo, đó không phải lời giải. Lời giải là phải biết chính xác cần cập nhật máy remote lên phiên bản nào của app. Cách của Sol sẽ cập nhật app local của bạn, cập nhật Muse, Cursor, Claude và Codex trên các máy remote, rồi sau khi app được cập nhật, bắt bạn chạy lại một lần nữa để cập nhật mọi server remote; nó chỉ đẩy phiên bản hiện tại của app lên các server đó. Không tốt, thật ra khá tệ. Anh hỏi tiếp "cái này so với các PR khác đang sửa nó thì sao", rồi hỏi điều gì xảy ra nếu máy host cũng đang chậm phiên bản, và theo anh nó chỉ nói linh tinh.

Còn Muse thì sao? Theo câu trả lời anh đọc trong video (đăng ngày 13/10/2026), câu đầu tiên: luồng bị hỏng bởi đúng một web request thất bại; đã có một bản sửa đang mở và sẵn sàng; nó không đổi dòng code nào trong worktree. Với luồng ở sidebar cập nhật server remote, app hỏi npm "phiên bản này đã publish chưa"; việc kiểm tra nằm ở một file cụ thể. Việc kiểm tra dùng `HttpClient` của Effect; client đó thêm hai trace header vào request. Nó đã chạy code hiện tại với một test fetch và thấy cả hai header trong request.

![Câu trả lời của Muse Wonder Full trong thread Fix update all remote environments: phát hiện chính và phần Cause](https://homus.dev/photos/DbWL6Zs2j_g-2303.jpg)

Câu trả lời của Muse Wonder Full sau 9 phút 28 giây (theo video đăng ngày 13/10/2026) (47 lệnh, đổi 2 file): "Top finding" ngắn gọn, rồi phần "Cause" giải thích trace header `b3` và `traceparent` buộc trình duyệt gửi CORS preflight, npm trả 404 không kèm CORS header, nên việc kiểm tra luôn đọc thành "not published".

"Các bạn thấy cái này dễ đọc hơn bao nhiêu không? Các bạn hiểu không?" Theo hỏi. Nhưng đó chưa phải phần hay nhất. Kéo xuống một chút là phần "Fix status" trên màn hình (theo video đăng ngày 13/10/2026): hai PR đang mở sửa lỗi này với cùng một thay đổi một dòng, tắt trace header cho riêng request này. Có hai PR. Có phải của Opus và Sol không? Không. PR đầu tiên là của một người khác. PR thứ hai là của Opus.

Vậy không chỉ câu trả lời của Muse dễ hiểu hơn rất nhiều, nó còn tìm ra một PR nhỏ hơn, sạch hơn mà một người khác đã mở sẵn, sửa được vấn đề. Theo anh (video đăng ngày 13/10/2026), không model nào khác tìm ra PR đó, không model nào khác có output dễ đọc về vấn đề là gì, và không model nào khác đề xuất đơn giản là merge cái đã có sẵn. Anh mong người xem đồng ý rằng đây không nghi ngờ gì là câu trả lời tốt nhất trong ba, và anh không nghĩ benchmark nào đo được điều này đúng cách; loại việc này rất khó đo. Theo anh, model này dễ chịu hơn nhiều khi làm việc thật, và từ nay anh sẽ ném cho nó nhiều bug report, phòng khi anh muốn hiểu lỗi là gì và biết đâu đã có người mở PR.

## 13. Bench tự làm: kiến trúc T3 Code, Lakebed và TS Rust

Dù vậy, Theo vẫn phải phàn nàn thêm. Trước khi quay video (đăng ngày 13/10/2026), anh dựng vài bench, "bench" ở đây hiểu rất lỏng: anh cho các model đi qua những codebase lớn của anh, audit xem cái gì tốt, cái gì dở, cái gì xấu, và giúp anh ưu tiên việc cần làm tiếp. Ví dụ đầu tiên: các model đi qua kiến trúc của T3 Code và nhận xét.

Theo kết quả của Theo (video đăng ngày 13/10/2026), Opus thắng đậm ở đây, Opus 5.5 có điểm rất cao. Sonnet 5.5 cũng tốt bất ngờ. Rồi tới Sol và Astra, và Muse ngay bên dưới. Điều thú vị là Muse và Astra có điểm khá gần nhau. Nhưng Muse Wonder bản thường, không phải Full, tụt xuống gần một nửa điểm của Opus. Theo anh, đó là mức giảm hơn 30% về chất lượng phát hiện và phân tích giữa Muse Wonder thường và Muse Wonder Full.

Anh không nghĩ Muse Wonder có lý do gì để dùng với mức giá của nó; nó không hấp dẫn (nhận định của Theo, video đăng ngày 13/10/2026). Và anh nghĩ nhiều demo người ta đang khoe trên mạng là dùng Muse Wonder, vì họ lấy API, ném vào công cụ quen thuộc, rồi thấy kết quả kém. Anh hiểu: Muse Wonder có vẻ là một model dở. Còn Muse Wonder Full thì theo anh ngang ngửa Astra và Fable ở nhiều việc thực tế, và rất dễ chịu khi làm việc cùng.

Anh chạy một audit tương tự trên Lakebed, sản phẩm cloud của anh. Theo bảng kết quả (video đăng ngày 13/10/2026), GPT-6.1 Sol có phân tích tốt nhất với cách biệt lớn, 9 trên 10 từ mọi giám khảo. Theo lời Theo, Muse Wonder tụt khá nhiều ở đây, được 5.75; trên màn hình, 5.75 là điểm của Muse Wonder Full, còn Muse Wonder được 4.50. Opus 5.5, GPT-6 Astra và Sonnet có điểm khá gần nhau. Anh thấy hơi đáng ngờ, vì Sonnet 5.5 điểm cao hơn Opus gợi ý đây có thể không phải bench tốt nhất, nhưng một lần nữa, anh chỉ dựng những bench này nhanh để xem thử.

![Lakebed model eval: deep architecture analysis, bảng điểm sáu model với thời gian và token](https://homus.dev/photos/DbWL6Zs2j_g-2549.jpg)

"Lakebed model eval: deep architecture analysis" (12 tới 13/10/2026): sáu model review kiến trúc Lakebed, bốn giám khảo chấm mù trên 10 tiêu chí và kiểm 345 claim. GPT-6.1 Sol 9.00 (31 phút), Sonnet 5.5 8.50 (79 phút), GPT-6 Astra và Opus 5.5 cùng 8.25 (22 và 43 phút), Muse Wonder Full 5.75 (16 phút), Muse Wonder 4.50 (4 phút).

Ở đây lại thấy một xu hướng thú vị với Muse Wonder Full: thời gian và số token nó cần để ra kết quả. Theo số đo của Theo (video đăng ngày 13/10/2026), nó mất 16 phút, gần bằng một nửa thời gian của GPT-6.1 Sol và ít hơn một nửa thời gian của Opus nhiều. Sonnet mất khoảng 80 phút cho lượt này, không tốt.

Một lượt tương tự với TS Rust, một codebase khá lớn, cũng cho khoảng cách thời gian tương tự. Theo bảng "Which model understands a large Rust codebase best?" (video đăng ngày 13/10/2026), Muse Wonder Full được 6.69, gần như ngang Fable 5.1 (6.75), mất 17 phút 02 giây. Điểm không tốt so với các model khác, nhưng nó nhanh hơn trên 10 phút so với vài model, và mất gần một nửa thời gian so với Sonnet và Opus. Muse Wonder bản thường, lại một lần nữa điểm không tốt (4.53), nhưng chỉ mất 5 phút 9 giây. Điều anh muốn nói: theo các lượt chạy của anh, những model này nhanh và tương đối tiết kiệm token.

## 14. Token efficiency trên Slopalytics

Có thể thấy điều này trên Slopalytics, trang so sánh model với dữ liệu từ Artificial Analysis mà Theo mở trong video. Vì chưa có giá cho Muse Wonder Full, không thể vẽ chi phí so với trí thông minh; chỉ xem được số token output. Theo dữ liệu anh cho xem (video đăng ngày 13/10/2026), nó dùng ít token hơn Opus 5.5 ở mức xhigh mà đạt điểm gần như y hệt. Nghĩa là nếu loại các lượt Max ra (điều đáng tiếc là sẽ loại luôn hai model Muse Wonder, vì chúng được gắn nhãn Max, dù về kỹ thuật theo anh nhớ là xhigh), thì đây là model điểm cao nhất, chỉ trừ Opus 5.5 xhigh nhỉnh hơn một chút. Theo anh, model này đạt điểm rất cao.

![Biểu đồ cột Tokens per task trên Slopalytics: GPT-6 Astra, GPT-6.1 Sol, Muse Wonder Full, Muse Wonder, Gemini 4 Argon, Fable 5.1, Grok 4.7, Opus 5.5](https://homus.dev/photos/DbWL6Zs2j_g-2743.jpg)

Biểu đồ "Tokens per task" trên Slopalytics (dữ liệu từ Artificial Analysis, theo video đăng ngày 13/10/2026): Muse Wonder Full và Muse Wonder cùng khoảng 54k token output mỗi task, Gemini 4 Argon 62k, Fable 5.1 tới 78k, Grok 4.7 tới 81k, Opus 5.5 tới 119k ở mức cao nhất; hai model GPT thấp hơn hẳn.

Chuyển sang biểu đồ cột, theo những gì anh chỉ trên màn hình (video đăng ngày 13/10/2026), Gemini 4 Argon dùng nhiều token hơn một chút, nhưng mọi model khác, trừ các model OpenAI đáng kể lúc quay video, đều dùng nhiều token hơn khá nhiều, kể cả Opus và Fable. Bật Sonnet lên thì "mức dùng token cao kỷ lục, ấn tượng", anh nói. Muse còn hơn cả Grok về token efficiency. Anh không ngờ đợt ra mắt này lại tiết kiệm token đến vậy.

Anh cũng lưu ý rằng Wonder và Wonder Full có lượng token rất giống nhau: theo dữ liệu trong video (13/10/2026), 53,8 nghìn token mỗi task cho Wonder Full và 54,2 nghìn cho Muse Wonder bản thường. Lạ là hai model hành xử giống nhau như vậy, dù Muse Wonder kém hơn bản Full rất nhiều. "Trời ơi, tôi ghét mấy cái tên này quá."

## 15. Tám PR, ba reviewer

Để mọi thứ dễ hiểu hơn, Theo giải thích bài test tiếp theo. Anh cho Opus đi tìm tám PR ngẫu nhiên, độ phức tạp khác nhau, chưa được merge trong T3 Code, rồi cho cả ba model, GPT-6.1 Sol, Muse Wonder Full và Opus 5.5, review tất cả, so sánh các phát hiện, kiểm chứng chúng, và xem model nào có kết quả mới và chính xác nhất (bài test trong video đăng ngày 13/10/2026).

![Bảng Totals so sánh Opus 5.5, GPT-6.1 Sol và Muse: findings, valid, plausible, wrong, novel, nits](https://homus.dev/photos/DbWL6Zs2j_g-2903.jpg)

Bảng tổng kết do Opus 5.5 lập sau 24 lượt review (theo video đăng ngày 13/10/2026): Opus 5.5 có 23 phát hiện (21 hợp lệ, 1 có thể đúng, 1 sai, 8 nit), GPT-6.1 Sol 9 (7 hợp lệ, 2 có thể đúng), Muse 16 (14 hợp lệ, 2 có thể đúng, 1 nit). Điểm "novel" có trọng số: Opus 13, Sol 7, Muse 4.

Kết quả, theo bảng Theo đọc (video đăng ngày 13/10/2026): Opus 5.5 tìm ra 23 điểm qua các PR, 21 điểm hợp lệ, một điểm "có thể đúng" và một điểm sai; tám trong số đó là nit. GPT-6.1 Sol chỉ tìm ra 9 điểm, một khoảng cách lớn so với Opus; bảy điểm hợp lệ. Theo lời Theo, Sol có hai phát hiện không hợp lệ và điểm novel là bốn; trên màn hình, hai điểm còn lại được ghi là "có thể đúng", và cột Novel ghi 4 (2 hợp lệ cộng 2 có thể đúng). Rồi tới Muse: 16 phát hiện, nằm ngay giữa Opus và Sol, trong đó năm điểm mới.

Theo anh (video đăng ngày 13/10/2026), Opus vẫn tìm ra nhiều điểm mới nhất, nhưng nó cũng nhét rất nhiều nit vào phát hiện. Sol không nhét nit, nhưng cũng không tìm được nhiều như vậy, nên nếu Sol là reviewer duy nhất của bạn, anh nghĩ bạn nên kéo thêm thứ khác vào. Muse là một điểm giữa tốt một cách kỳ lạ. Bảng cũng chỉ ra Muse không tìm được nhiều phát hiện mức nghiêm trọng cao như Sol và Opus, nhưng anh thấy bảng này rất có ích.

Phần tóm tắt, anh đọc từ màn hình (video đăng ngày 13/10/2026): Opus tìm ra nhiều vấn đề nhất mà không model nào khác thấy, gồm bốn vấn đề mức trung bình; nó viết khoảng một nit mỗi PR, và ở một PR nó coi hành vi có chủ đích là bug. "Ôi, đúng kiểu Opus." GPT-6.1 Sol không viết nit nào, nên mỗi phát hiện đều có giá trị; nó không tìm ra gì ở ba trong bốn PR nhỏ, kể cả khi có nit thật. Các phát hiện riêng của nó đến từ việc đào sâu, như đọc source upstream của agent-device và tài liệu Hyperdrive.

Theo bảng tóm tắt (video đăng ngày 13/10/2026), Muse trùng nhiều nhất với các bug mà model khác cũng tìm ra, nên theo anh nếu chỉ dùng một model, nó có vẻ tốt ở điểm này. Nó tìm ra một lỗi thu hồi token khi mở lại (busy-reopen token revoke) mà Opus bỏ sót. Phần lớn phát hiện riêng của nó có mức nghiêm trọng thấp, và có lần nó yêu cầu sửa một khoảng trống mà mô tả PR đã liệt kê sẵn. Không tốt lắm, nhưng nhìn chung khá chắc.

## 16. Ưu tiên việc tiếp theo cho T3 Code: báo cáo của Opus và của Muse

Đây có thể là phép so sánh Theo thích nhất. Anh yêu cầu cả Opus và Muse Wonder Full làm một "deep dive cực kỳ sâu" vào codebase T3 Code, cùng với feedback nhận qua các kênh như GitHub issues, thảo luận trong PR và những chỗ khác: "Tôi muốn bạn giúp ưu tiên việc chúng tôi nên làm tiếp theo." Opus tạo ra rất nhiều agent và viết rất nhiều thứ. Anh gửi lúc 10:33 và nhận phản hồi lúc 11:04, tức khoảng 30 phút sau (theo các mốc giờ Theo đọc trong video đăng ngày 13/10/2026), với một báo cáo lớn.

Báo cáo "T3 Code: what to work on next" của Opus (video đăng ngày 13/10/2026): mười agent làm audit, chín agent đọc mọi issue đang mở, mọi PR, mọi thảo luận, cộng với codebase. Theo xin lỗi, anh cố hết sức, nhưng theo anh đây là quá nhiều chữ cho những thứ không thật sự quan trọng. Phần "short version" có bốn câu cho mỗi gạch đầu dòng: ship V2 lên stable an toàn và sớm; nút thắt là merge chứ không phải viết code, khoảng một nửa issue tháng Mười, vân vân; người dùng muốn độ ổn định chứ không phải tính năng, nỗi đau lớn nhất là các lượt chạy kẹt ở trạng thái "Running", việc server khởi động lại giết mọi agent, vân vân. Rồi "Week 1: merge và các bản sửa nhỏ". Nó phân loại khá ổn, chia thành các hàng, nhưng vẫn quá nhiều chữ. Tiếp theo là phần "ship gate" cho V2 stable; theo anh đây không phải thứ dễ đọc nhất, nó viết rất nhiều.

So với Muse: anh gửi lúc 9:19, để ý thấy nó như bị đơ, anh nghĩ nó bị reset cùng khoảng thời gian đó, nên tiếc là anh không biết tổng cộng mất bao lâu và không đưa ra được mốc thời gian chính xác. Anh gửi lại lúc 10:24 và nó xong lúc 10:31. Cộng bảy phút đó với phần trước, theo ước tính của Theo (video đăng ngày 13/10/2026) tổng cộng khoảng 17 phút, cỡ một nửa thời gian của Opus. Điều đó khớp với trải nghiệm chung của anh: nó nhanh, hiệu quả, không đốt nhiều token và không kiểm tra nhiều chỗ ngớ ngẩn trước khi đi tới đúng chỗ.

Cách tốt nhất anh mô tả được: nó có trực giác tốt. Nó biết tìm ở đâu và tìm ra thứ cần tìm khá nhanh. Anh không biết Meta làm thế nào; có thể họ huấn luyện trên codebase khổng lồ của Meta và có được nhiều dữ liệu tốt, anh không biết. Nhưng theo anh (video đăng ngày 13/10/2026), nó rất giỏi biết nên kiểm tra ở đâu và kiểm tra đúng chỗ trước. Nó có một câu ngớ ngẩn ở đầu: "đây là một kế hoạch, không phải một chế độ đặc biệt, tôi chưa bắt đầu implement". Có vẻ nó được huấn luyện với ý tưởng plan mode và tự nói ra điều đó; anh đã thấy vài lần khi xin nó lập kế hoạch.

Phần nội dung thật trong báo cáo của Muse (video đăng ngày 13/10/2026): mục tiêu, chọn việc tiếp theo cho T3 Code dựa trên bằng chứng thật; mười agent nghiên cứu audit GitHub issues, thảo luận PR và code; một "critic" cố bác bỏ các khẳng định hàng đầu; rồi nó tự chạy lại các con số GitHub chính và các lần kiểm code. Theo anh, phần đầu này dễ đọc hơn nhiều so với báo cáo trước. Phần "State in numbers" (issue đang mở, bug, tốc độ, review) thì vẫn hơi nhiều với khẩu vị của anh. Nhưng kéo xuống thì thấy thứ anh thích.

"Key decisions" trên màn hình (báo cáo của Muse, theo video đăng ngày 13/10/2026): một, đóng băng provider mới và các bề mặt mới cho tới khi danh sách P0 bên dưới ship xong, vì độ rộng provider đã là nguồn của các cụm issue hàng đầu (Claude 118 và Codex 76 lượt trong tiêu đề). Hai, bỏ sidebar cũ: hai sidebar làm mọi bản sửa nhân đôi, đừng giữ cả hai. Ba, coi Discussions là nhu cầu chưa đáng tin cho tới khi kiểm trạng thái đã ship, vì Discussions không bao giờ tự đóng. Bốn, lấy mẫu backlog PR trước khi đánh giá: chỉ đếm số lượng không chứng minh được việc thiếu người review. Theo anh, chưa hẳn tốt nhất nhưng rất dễ đọc.

![Phần Steps, P0 Next two weeks trong báo cáo của Muse Wonder Full: năm việc có size và số liệu cụ thể](https://homus.dev/photos/DbWL6Zs2j_g-3423.jpg)

Phần "P0. Next two weeks" trong báo cáo của Muse Wonder Full: mỗi mục mở đầu bằng một câu in đậm nói điều quan trọng, kèm size (S, M) và số liệu từ issue: SQLite transaction 1,98 giây, 2.795 lượt gọi Bitbucket trong 100 phút, 22.423 lượt gọi GitLab trong 12,5 giờ, snapshot thread 17 MB, OpenCode chỉ hiện 29 model có sẵn (theo video đăng ngày 13/10/2026).

Rồi tới những việc nó nghĩ anh nên làm; anh thấy chúng rất, rất rõ ràng và dễ đọc. Mục P0 cho hai tuần tới mở đầu bằng: sửa hai chỗ server bị treo, size M cộng M. Đây là một issue, nó nói điều gì quan trọng về issue đó; đây là một issue khác cho thấy một provider bị kẹt giữ cả bốn effect worker, pool size là bốn trong file này; thêm cách ly theo từng provider hoặc timeout cho worker bị kẹt. Tiếp theo: chặn việc đốt quota PR và payload, size S tới M. Issue này báo 2.800 lượt gọi Bitbucket trong 100 phút và 22.423 lượt gọi GitLab trong 12,5 giờ (số trong issue, theo video đăng ngày 13/10/2026). Ngừng fetch lại khi focus, cache theo PR, lùi lại khi gặp lỗi quota. Một issue khác cho thấy snapshot thread 17 MB.

"Tôi không biết có phải tôi chỉ đang chán slop kiểu Claude không", Theo nói, nhưng anh thấy cách viết này dễ đọc và rõ ràng hơn gấp trăm lần. Cách nó in đậm ở đầu mỗi mục để nói điều gì quan trọng. Sửa lần dùng provider đầu tiên: theo issue được trích (video đăng ngày 13/10/2026), OpenCode chỉ hiện 29 model có sẵn. Đây là vấn đề một số provider không gửi đúng danh sách model tới app kịp lúc, nên app hiện sai bộ model. Anh thấy rất tốt.

Sửa việc scope bị "mắc kẹt" ở gốc, không phải theo từng scope; size S cho bug, M cho cả hệ thống. Anh thừa nhận mục này không dễ đọc bằng các mục khác, có lẽ anh sẽ đi xem issue để hiểu lỗi là gì. Và anh mở issue luôn để xem nó rõ tới đâu (video đăng ngày 13/10/2026): provider account trên iOS thất bại khi thiếu quyền `providers:manage` trên token T3 Connect mới. Tức là trong một số trường hợp, việc kết nối qua app iOS bằng T3 Connect bị lỗi. Tốt khi thấy điều này.

Mục thứ năm trong báo cáo (theo video đăng ngày 13/10/2026): chạy một đợt quét một tuần về mất dữ liệu và billing. Các tiêu đề gần đây nói tới file env bị huỷ, chỉnh settings bị hoàn lại, subagent tiếp tục tính tiền sau khi huỷ. Số lượng thấp, mức nghiêm trọng cao, bằng chứng mỏng, nên hãy tái hiện từng cái trên bản nightly hiện tại. Theo anh, đó là cách gọi tên công bằng: nó nói rõ số lượng thấp nhưng mức nghiêm trọng cao, và bằng chứng rất ít nên cần tái hiện. Sau đó là mục ưu tiên một với những việc đơn giản hơn, và ưu tiên hai cho "để sau hoặc chưa làm bây giờ". Ít chữ hơn nhiều, và dễ đọc hơn nhiều.

## 17. Kết luận: một người chơi thứ ba

Điều Theo muốn nói về model này: nó có thể không phải thông minh nhất, có thể không tìm ra vấn đề giỏi nhất, nhưng theo anh (video đăng ngày 13/10/2026) nó vượt xa ngưỡng "dùng được và hữu ích" của anh, vượt xa những gì anh mong đợi từ một model Gemini hay Grok. Anh nói thật lòng đây là model đầu tiên kể từ Fable, ngoài Anthropic và OpenAI, mà anh có thể hình dung mình dùng hằng ngày, và anh đang dùng nó khá nhiều. Anh vẫn gọi Opus cho những việc "khó nhằn", và thường để model này gọi Opus để kiểm tra lại việc của nó.

Anh nói (video đăng ngày 13/10/2026) anh chấp nhận năng lực thấp hơn một chút vì anh thích cái "sàn" cao hơn về độ ngu, nơi nó không làm những điều ngớ ngẩn. Và anh rất thích "vị" mới trong câu trả lời của nó; cách nó nói chuyện với anh, theo anh, dễ đọc và dễ chịu hơn nhiều.

Có nên bỏ gói Claude Code để dùng cái này không? Theo anh (video đăng ngày 13/10/2026): tuyệt đối không. Anh còn không biết các gói đăng ký của Meta được trợ giá tới đâu, và cũng không thể biết, vì một lần nữa, họ chưa công bố giá cho model anh thích. Theo anh, đợt ra mắt này có rất nhiều chỗ "cringe", và có thể thấy Meta chưa quen với việc có một model đủ tốt để người ta quan tâm. Nhưng anh quan tâm. Anh thích model này. Anh sẽ tiếp tục dùng cho tới khi họ khoá API key của anh; rồi có lẽ anh sẽ thử gói đăng ký, thấy nó giới hạn quá, huỷ, và quay về Opus. Nhưng nếu giá đúng và mức dùng đúng, anh có thể thấy mình dùng model này rất nhiều.

Anh chúc mừng đội ngũ ở Meta (video đăng ngày 13/10/2026) đã làm được điều này. Anh thật sự không thấy trước. Sau những đợt ra mắt model nhỏ như dòng Spark, anh không nghĩ mình sẽ thật sự chọn nó thay cho những model frontier khác. Nhưng họ làm được, "họ nấu ngon thật".

Kể cả khi model này không làm bạn hào hứng, thì việc Meta bắt kịp nên làm bạn hào hứng, theo anh (video đăng ngày 13/10/2026). Nó khiến tương lai cạnh tranh hơn nhiều. Nếu bạn đã thấy các model của cả Anthropic và OpenAI tốt lên bao nhiêu, cả về trí thông minh lẫn chi phí, từ khi hai bên cạnh tranh gay gắt hơn, bạn sẽ hiểu một người chơi thứ ba có thể mạnh tới đâu.

Vậy chỉ còn lại câu hỏi: chuyện gì đang xảy ra ở DeepMind? Tại thời điểm video đăng (13/10/2026), anh nói Google đã tease Gemini 4 Argon bao lâu rồi, nó ở đâu, khi nào mọi người có nó, khi nào anh được nói về nó, được cho xem điểm mạnh điểm yếu. Anh nói danh sách những thứ ra mắt trước Gemini 4 Argon sắp dài hơn danh sách những thứ ra mắt trước GTA 6. Anh không biết chuyện gì đang xảy ra ở Google, nhưng anh biết chuyện gì đang xảy ra ở Meta, vì có vẻ nó khá tốt. Anh rất hào hứng với đợt ra mắt này và tò mò người xem nghĩ sao: anh có đang thổi phồng model này không, có phải anh bị "những người bạn ở Meta", những người làm ra React và giờ làm ra một model anh thích, mua chuộc không? Anh mời mọi người để lại ý kiến trong phần bình luận, và chào tạm biệt: "Peace nerds".

## Nguồn và liên kết

- Tên gốc: Meta just caught up with Anthropic
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=DbWL6Zs2j_g](https://www.youtube.com/watch?v=DbWL6Zs2j_g)

- Kênh YouTube Theo - t3․gg (Theo Browne): [youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA](https://www.youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA)

- Bài công bố của Meta, "Introducing Muse Wonder and Muse Wonder Full: Frontier Models for Agents" (đăng ngày 12/10/2026, đọc ngày 22/10/2026): [about.fb.com/news/2026/10/introducing-muse-wonder-models](https://about.fb.com/news/2026/10/introducing-muse-wonder-models/)

- Artificial Analysis, nơi Theo đọc thứ hạng tổng thể (đọc ngày 22/10/2026): [artificialanalysis.ai](https://artificialanalysis.ai/)

- Slopalytics, trang so sánh model theo trí thông minh, chi phí, tốc độ và lượng token mà Theo mở trong video (đọc ngày 22/10/2026): [slopalytics.com](https://slopalytics.com/)

- SkateBench, bench gọi tên trick trượt ván của Theo (đọc ngày 22/10/2026): [github.com/T3-Content/skatebench](https://github.com/T3-Content/skatebench)

- T3 Code, công cụ Theo dùng để chạy và điều phối các model trong video, tự mô tả là control plane open source cho coding agent (đọc ngày 22/10/2026): [t3.codes](https://t3.codes/) · [github.com/pingdotgg/t3code](https://github.com/pingdotgg/t3code)

- Thunderstore, cửa hàng mod mà Theo cho Muse audit (đọc ngày 22/10/2026): [thunderstore.io](https://thunderstore.io/)

Nguồn: https://homus.dev/talks/meta-just-caught-up-with-anthropic · cập nhật 2026-10-22