Muse Wonder Full qua sáu project KingBench 4: kiểm từng app, điểm, token và chi phí

1. Muse Wonder Full và sáu project của KingBench 4

AICodeKing chào người xem rồi vào chủ đề. Theo video đăng ngày 13/10/2026, Meta vừa ra mắt Muse Wonder và Muse Wonder Full, và trong video này anh cho bản Full chạy qua đúng sáu project của KingBench 4 mà anh đã dùng cho bản Wonder thường (Standard Wonder). KingBench là bộ benchmark do chính anh tự dựng và tự chấm. Sáu project gồm: một emulator, một Docker alternative, một trình thiết kế nội thất 3D, một công cụ cấu hình bàn phím, một game Pokemon và một app desktop cho Fitbit. Sau khi model làm xong, anh mở từng kết quả ra và kiểm xem cái gì thật sự chạy được.

Điểm mốc để so sánh, theo số đo của AICodeKing (video đăng ngày 13/10/2026): Standard Wonder kết thúc bộ này ở 45.8%. Ở lần đó, trình thiết kế phòng và game Pokemon của Standard Wonder có những luồng chạy được và hữu ích, còn các task về hệ thống và tích hợp thiết bị thì bỏ dở nhiều yêu cầu lớn. Theo anh, Full cho một cơ hội để xem kết quả thay đổi bao nhiêu khi giữ nguyên yêu cầu và công cụ coding, chỉ đổi sang model kia.

2. Muse Wonder Full là gì và lần chạy được cấu hình ra sao

Theo AICodeKing (video đăng ngày 13/10/2026), Muse Wonder là họ model reasoning độc quyền của Meta, được công bố ngày 12/10/2026. Tính đến video đăng ngày 13/10/2026, Wonder có context window hơn một triệu token một chút, nhận nhiều loại input và sinh ra text. Qua Muse Code, model có thể dùng tool để xem xét một project, ghi file, chạy lệnh và tự test phần việc của mình. Weights không được công khai, nên đây không phải model bạn tải về chạy local (theo video đăng ngày 13/10/2026).

Full là một biến thể riêng (theo video đăng ngày 13/10/2026). Chọn mức reasoning tối đa trên Standard Wonder không chuyển bạn sang Full. Trong lần chạy này, anh chọn rõ Muse Wonder Full 1.0 trong Muse CLI gốc, và các bản ghi model của những lần chạy đã hoàn tất xác nhận đúng danh tính đó. Cả hai lần chạy Wonder đều dùng reasoning mức high, cùng một phiên bản CLI, hai task chạy song song, và thư mục project mới tinh.

Về cách bán, theo video đăng ngày 13/10/2026: Full có trong hai gói subscription Power Usage và Maximum Usage, niêm yết $50 và $200 một tháng theo bảng giá lúc ra mắt. Standard Wonder thì có thêm truy cập API trả theo mức dùng (pay-as-you-go). Full không có bảng giá pay-as-you-go được công bố, nên theo anh, giá subscription và con số ước tính theo token mà anh tính ở phần sau trả lời hai câu hỏi khác nhau.

3. Full trên các benchmark công khai

Trên các benchmark công khai, theo video đăng ngày 13/10/2026, Full có vài kết quả nổi bật mạnh hơn. Trong bản chụp ngày 12/10/2026, Vals xếp Full thứ năm trên chỉ số tổng của họ với 64.57, so với Standard Wonder đứng thứ mười với 61.06. AICodeKing nhắc rằng chỉ số đó gộp nhiều nhóm task chuyên môn; nó không phải bảng xếp hạng cho mọi cách dùng một model AI.

Trên Terminal Bench 4, theo bảng Vals anh mở trong video đăng ngày 13/10/2026, Full đứng thứ năm với 58.08%. Fable có cùng điểm hiển thị đó và đứng trên một bậc, nên anh muốn giữ cho thế hoà này được nhìn thấy rõ. Trên Vibe Code Bench, Full đạt 86% và đứng thứ 12, còn Standard Wonder đạt 83.09% và đứng thứ 18. Nhưng mức cải thiện không có ở mọi dòng: ở Code Migration, điểm ước lượng của Full là 61.03%, của Standard Wonder là 62.55. Theo anh (video đăng ngày 13/10/2026), từng benchmark riêng lẻ đều có độ bất định, agent và task của chúng cũng khác nhau; chúng giúp đặt kỳ vọng nhưng không cho biết sáu ứng dụng này sẽ ra sao.

Artificial Analysis, theo video đăng ngày 13/10/2026, cho Full 56 điểm trên Intelligence Index, so với 52 cho Standard Wonder. Chỉ số Coding Agent riêng của họ cho Muse Code chạy với Full 68 điểm, so với 63 khi chạy với Standard Wonder. Anh lưu ý kết quả thứ hai đo coding agent cùng với model. Các cấu hình mà Artificial Analysis công bố dùng mức effort tối đa, còn các bản build KingBench của anh dùng mức high. Vals cũng ghi mức effort tối đa là mặc định, với thiết lập có thể khác nhau tuỳ benchmark (theo video đăng ngày 13/10/2026).

4. Cách tính chi phí và cách chấm điểm

Về giá, AICodeKing áp cùng một biểu giá của Standard Wonder cho cả hai lần chạy (video đăng ngày 13/10/2026): $4 cho mỗi triệu input token mới và $0.20 cho mỗi triệu input token đã cache. Trên bảng giá anh mở, dòng Output ghi $20.00 cho mỗi triệu token. Vì vậy con số tiền của Full là một ước tính tương đương API dựa trên giả định. Nó không phải giá API chính thức của Full, và cũng không phải khoản phí phát sinh thêm được ghi trên subscription.

Về cách chạy, theo video đăng ngày 13/10/2026: cả sáu bản build đều được để chạy tới khi xong, không thêm hạn chót generate và không giới hạn số bước của model. Mỗi khi một bản build xong, anh đóng băng các file và test trên một bản sao. Điểm số đến từ các yêu cầu chạy được, độ đúng, phần trình bày và hiệu quả; tính năng thiếu hoặc chưa kiểm chứng được đều bị trừ vào điểm. Anh không sửa các app trước khi chấm.

Trên màn hình (video đăng ngày 13/10/2026), file RUBRIC.md của AICodeKing ghi các luật chấm: mỗi task có một sổ yêu cầu 10 điểm; tính năng NOT IMPLEMENTED được 0 điểm; phần tích hợp chỉ đọc source mà chưa từng chạy được tối đa 40% phần điểm tích hợp; một mock được chạy thực tế với các hợp đồng bên ngoài được kiểm độc lập được tối đa 75%, phần còn lại dành cho tích hợp thật. Rồi anh bảo: hãy mở kết quả ra.

5. Project 1: emulator Game Boy, DS và 3DS

Project đầu tiên trong bộ của AICodeKing (video đăng ngày 13/10/2026) là emulator cho Game Boy, DS và 3DS. Yêu cầu cố ý được viết rộng: build các hệ máy bằng Rust, thêm các tính năng thông thường cho người chơi, và làm cho phần lớn game chạy được. Prompt anh mở trên màn hình bắt đầu bằng "Build me a fully functional Game Boy,DS & 3DS All in one emulator in Rust". Theo cách chấm của anh, mỗi hệ máy phải tự kiếm điểm của mình: một bản Game Boy tốt không bù được phần DS và 3DS còn thiếu.

Theo đánh giá của AICodeKing (video đăng ngày 13/10/2026), Full tạo ra một project tên TriEmu, và ở đây có công việc thật. Nó có bộ xử lý Game Boy, code đồ hoạ và âm thanh, hai bộ xử lý ARM cho DS, và một đường ARM11 cho 3DS. Đây không chỉ là ba nút bấm cùng trỏ về một bản demo.

Phần mạnh nhất là Game Boy. Theo số đo của AICodeKing (video đăng ngày 13/10/2026), anh chạy 29 bài diagnostic công khai và 23 bài qua, trong đó có cả 11 bài test lệnh CPU. Một bài test input độc lập làm thay đổi các pixel được render. Code âm thanh sinh ra mẫu âm khác 0, và một bản battery save có dữ liệu thật vẫn còn nguyên sau một vòng ghi ra file rồi đọc lại. Khôi phục một state hợp lệ cũng chạy tiếp một cách tất định.

Nhưng sáu bài diagnostic thất bại, và các bài kiểm độc lập phơi ra lỗi về timing và state (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Có một chuỗi interrupt để interrupt ở trạng thái bật trong khi lẽ ra phải tắt. Hành vi của timer sai. Scanline đầu tiên của window bị lệch. Khôi phục đồng hồ thời gian thực (real-time clock) cho ra kết quả sai. Một state bị hỏng cũng có thể được chấp nhận rồi làm emulator crash khi dùng tới.

Anh nhấn mạnh (video đăng ngày 13/10/2026): 23 bài diagnostic qua không có nghĩa là 23 game chạy được. Diagnostic hỏi những câu hẹp về phần cứng, và lần chạy này không có một thư viện game đại diện. Vì vậy phần Game Boy được điểm thực thi hữu ích nhưng không được điểm cho yêu cầu "chạy được phần lớn game".

6. DS, 3DS, rewind và điểm của emulator

Ở phía DS, theo số đo của AICodeKing (video đăng ngày 13/10/2026), cả hai bộ xử lý chạy được một bài test độc lập rất nhỏ và tự ghi marker của mình vào bộ nhớ. Cũng có một đường render tile giới hạn. Nhưng các lệnh ARM bình thường dùng địa chỉ tương đối theo program counter lại đọc sai vị trí. Một số đường interrupt và giao tiếp thất bại, và bài test framebuffer chuẩn cho ra màn hình đen. Hệ đồ hoạ 3D và âm thanh thì không có.

Phía 3DS còn hẹp hơn (theo đánh giá của anh, video đăng ngày 13/10/2026). Một chương trình ELF nhỏ chạy tới được framebuffer, nhưng bài kiểm nạp định dạng homebrew chuẩn thất bại. Không có một bộ dịch vụ GPU, hệ điều hành và âm thanh chạy được để biến điều đó thành khả năng tương thích 3DS nói chung.

Rồi tới rewind. Theo số đo của AICodeKing (video đăng ngày 13/10/2026), một state 3DS nặng khoảng 141 megabyte, và lịch sử mặc định giữ tới 100 state. Tính ra khoảng 14.1 gigabyte chỉ cho phần dữ liệu state đã lưu. Anh không ép máy tới mức hết bộ nhớ; vấn đề nhìn thấy được từ kích thước state đo được và giới hạn lịch sử thật. Serialize một state cũng mất khoảng một phần mười giây trong bài test này.

Kết quả, theo số đo của AICodeKing (video đăng ngày 13/10/2026): Full được 3.1 trên 10 cho emulator, so với 2.4 của Standard Wonder. Có nhiều phần implement chạy được hơn, nhất là ở Game Boy. Các yêu cầu DS và 3DS vẫn chiếm phần lớn số điểm bị mất.

7. Project 2: litebox, một Docker alternative viết bằng Go

Task thứ hai trong bộ của AICodeKing (video đăng ngày 13/10/2026) là một Docker alternative. Theo yêu cầu của anh, nó phải nhận được image tương thích Docker, chạy được container, có các tính năng vòng đời và cấu hình đi kèm, và chứng minh được tuyên bố rằng nó hiệu quả hơn. Prompt trên màn hình bắt đầu bằng "Make me a full docker alternative that is still docker images compatible but is built to be more efficient than Docker", và cho phép chọn ngôn ngữ lập trình tuỳ ý nhưng không được dùng thư viện Docker hay chép code của họ.

Theo đánh giá của AICodeKing (video đăng ngày 13/10/2026), Full build ra litebox bằng Go. Giao diện của nó làm nhiều hơn hẳn việc khởi động một process: có các thao tác với image, lệnh build, cấu hình và các đường vòng đời container. Source cho Linux có namespaces và giới hạn tài nguyên, còn đường phát triển trên Mac thì được ghi rõ là khác. Biên dịch được code Linux đó không chứng minh được phần cô lập (isolation) chạy đúng, nên anh giữ phần kết quả này có điều kiện.

Phần xử lý image có một lỗi trực tiếp hơn (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Trong một fixture độc lập, việc import một image ghi xuyên qua một symbolic link và làm thay đổi một marker nằm ngoài thư mục lưu trữ mà litebox định dùng. Cả image lẫn marker đều thuộc về bài đánh giá, nên không có file nào không liên quan bị đụng tới. Kết quả này cho thấy một lỗi ranh giới lưu trữ thật.

Còn có một vấn đề về tính di động trong chính luồng export của nó (theo số đo của anh, video đăng ngày 13/10/2026). litebox thay đổi archive của layer khi lưu, nhưng vẫn giữ hash nội dung cũ trong cấu hình image. Khi load lại image đã export, nó từ chối vì hash không khớp. Theo anh, một tên file đúng định dạng là chưa đủ nếu image sinh ra không qua được bài kiểm toàn vẹn của chính nó. Và không có phép đo hiệu năng nào để so với Docker: một binary nhỏ hay một thiết kế ít process hơn có thể đáng chú ý, nhưng lợi thế hiệu quả được yêu cầu cần cùng một workload đo trên cả hai công cụ.

Các bài kiểm workflow thông thường tìm ra thêm hai lỗi (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Khởi động một container có sẵn với output gắn vào trả về mã thành công ngay cả khi payload bên trong thoát với lỗi. Chạy thêm một lệnh trong container đang sống thì ghi đè mã định danh process chính đã lưu, điều này có thể khiến các thao tác vòng đời sau đó trỏ sai process.

Cũng có những tính năng đáng ghi nhận (theo đánh giá của anh, video đăng ngày 13/10/2026): một image BusyBox thật tải về được và qua các bài kiểm hash độc lập, môi trường build native nhỏ, logging và các workflow dọn dẹp đều chạy. Kết quả cuối cùng là 3.0 trên 10, bằng đúng điểm của Standard Wonder. Lỗi ranh giới lưu trữ giữ điểm ở mức trần đó.

8. Project 3: Atelier, trình thiết kế phòng 3D

Task thứ ba là trình thiết kế nội thất 3D. Theo AICodeKing (video đăng ngày 13/10/2026), đây là chỗ Full cho ra một ứng dụng dùng được hơn hẳn, tên là Atelier. Căn phòng nằm ở giữa, catalog đồ nội thất ở bên trái, và các điều khiển chỉnh sửa ở bên phải. Giao diện tối có thứ bậc nhất quán, và cảnh có đồ nội thất nhận ra được, có bóng đổ và vật liệu procedural.

Phần chỉnh sửa cơ bản chạy được (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Đổi kích thước phòng làm thay đổi hình học thật. Anh tạo được hình hộp, hình trụ, hình cầu và hình nón, đặt kích thước và màu cụ thể cho chúng, rồi di chuyển chúng trong phòng. Kéo, xoay, nâng lên, nhân bản và xoá vật thể đều chạy trong các bài kiểm có mục tiêu. Các điều khiển ánh sáng cũng thay đổi nguồn sáng thật với hiệu ứng nhìn thấy được trên cảnh, nên ở đây có một điểm khởi đầu hữu ích.

Nhưng một số điều khiển hằng ngày làm đứt mối liên hệ giữa điều giao diện hứa và điều app thực sự làm (theo số đo của anh, video đăng ngày 13/10/2026). Chuyển đơn vị sang feet thì nhãn đổi, nhưng ô nhập số vẫn hiểu theo mét: nhập 10 cho bạn một căn phòng 10 mét. Undo có thể để nguyên chiều rộng phòng mới hoặc màu vật thể mới mà không hoàn tác.

Lỗi autosave dễ chứng minh (theo số đo của AICodeKing, video đăng ngày 13/10/2026): bắt đầu với một cảnh 18 món, thêm một hình hộp mặc định, rồi reload, bạn quay về 18 món. App lưu trước khi thêm vật thể. Cảnh trước đó vẫn còn, và hình hộp này có thể được thêm lại bằng đúng cú bấm catalog đó, nhưng tính năng autosave được quảng cáo vẫn bỏ sót thao tác cuối cùng của người dùng. Export và import thủ công thì chạy, và nếu chỉnh hình hộp mới trước khi reload thì trong bài kiểm tiếp theo nó được lưu.

Màu ánh nắng tuỳ chỉnh cũng được lưu nhưng không được khôi phục thành màu phát sáng (theo số đo của anh, video đăng ngày 13/10/2026). Đồ nội thất import vào chấp nhận kích thước không hợp lệ và định danh trùng lặp, và nhãn import vào bị hiểu như HTML. Đó là những vấn đề độ tin cậy riêng, dù vòng lưu rồi mở lại cảnh bình thường vẫn thành công.

9. Atelier: realism, rò rỉ tài nguyên và điểm số

Phần hình ảnh có điểm mạnh, nhưng yêu cầu là làm nó trông thật nhất có thể. Theo đánh giá của AICodeKing (video đăng ngày 13/10/2026), ở đây hiệu ứng bloom mặc định làm ánh sáng bị loá. Một mặt phẳng bầu trời sáng rất lớn hiện ra phía sau căn phòng, và bụi lơ lửng trông giống tuyết hơn. Đồ nội thất vẫn lộ rõ là ghép từ các khối cơ bản bo tròn. Theo anh, đây là một trình chỉnh phòng mang tính cách điệu, và nó không được trọn điểm realism chỉ vì có vật liệu physically based.

Chỉnh sửa lặp lại cũng để lại tài nguyên đồ hoạ (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Năm lần chỉnh phòng đưa số texture đã cấp phát từ 53 lên 83, trong khi cảnh vẫn chỉ dùng 14 texture. Sau khi xoá 19 vật thể, renderer vẫn giữ 629 geometry đã cấp phát cho chỉ 28 geometry đang dùng. Source xác nhận phần dọn dẹp bị thiếu. Theo anh, điều đó quan trọng trong một ứng dụng thiết kế, nơi thêm, đổi và xoá vật thể là workflow bình thường.

Atelier được 7.0 trên 10, còn Standard Wonder được 7.6 ở task này (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Theo anh, Full có một trình chỉnh sửa lớn và dùng được, nhưng các lỗi về chỉnh sửa và quản lý tài nguyên kéo kết quả này xuống dưới model thường.

10. Project 4: HiveKey, cấu hình bàn phím QMK

Task thứ tư là một bản thay thế cho VIA theo tông màu vàng, để cấu hình bàn phím QMK. Theo đánh giá của AICodeKing (video đăng ngày 13/10/2026), Full đặt tên app là HiveKey. Nó có một trình chỉnh bàn phím rõ ràng, một bảng keycode tìm kiếm được, layer, macro, ánh sáng, tuỳ chọn layout và một panel thiết bị. Tông vàng nhất quán, và phím đang chọn dễ nhận ra.

Theo anh (video đăng ngày 13/10/2026), ở đây cần nhìn xa hơn bàn phím demo. Một trình chỉnh bàn phím có thể hiển thị một phím đã đổi trong khi gửi sai giá trị xuống thiết bị, nên anh kiểm các message so với các hợp đồng thật của QMK và VIA. Các bài test trên trình duyệt dùng một fixture firmware độc lập. Không có bàn phím vật lý nào được lập trình, và điểm tích hợp phản ánh giới hạn đó.

Theo số đo của AICodeKing (video đăng ngày 13/10/2026), Full có implement việc phát hiện thiết bị, kết nối, đọc keymap và ghi keymap. Phím thường chạy được trong fixture, và một layout bàn phím tuỳ chỉnh import vào gửi thay đổi tới đúng vị trí trong ma trận. Ngắt kết nối rồi kết nối lại cũng chạy. Các bài test đó xác lập một luồng remap cơ bản chạy được trong fixture.

Nhưng một số chức năng nâng cao bị sai (theo số đo của anh, video đăng ngày 13/10/2026). Các phím chuyển layer thông dụng sinh ra mã số sai. Gán encoder theo chiều kim đồng hồ và ngược chiều bị đảo. Một macro lẽ ra phải bấm Enter lại gửi nguyên biểu thức trong ngoặc nhọn dưới dạng text thường, vì hành động đó không được mã hoá sang định dạng macro của firmware.

Ánh sáng là một ví dụ khác về việc giao diện tuyên bố nhiều hơn những gì thiết bị nhận được (theo số đo của AICodeKing, video đăng ngày 13/10/2026). App gửi sai định dạng địa chỉ. Fixture giữ nguyên độ sáng ban đầu, còn UI vẫn báo đã lưu ánh sáng. Một bàn phím báo có bốn layer cũng có thể bị thêm layer thứ năm trong trình chỉnh; app báo ghi thành công, nhưng đọc lại từ fixture thì layer không được hỗ trợ đó biến mất.

Phần phục hồi lỗi cũng cần làm thêm (theo số đo của anh, video đăng ngày 13/10/2026). Nếu một lần ghi phím bị từ chối, trình chỉnh có thể vẫn hiển thị phím chưa gửi mà không có dấu hiệu thay đổi đang chờ. File VIA mà nó export không khớp định dạng lưu của VIA, và reload thì mất định nghĩa bàn phím đã import khỏi ô chọn. Kết nối lặp lại làm tích tụ các input listener, còn quay về chế độ demo thì để thiết bị vẫn mở.

HiveKey được 5.5 trên 10, so với 3.5 của Standard Wonder (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Theo anh, Full chạy được nhiều hơn phần workflow có kết nối, nhưng anh vẫn sẽ cần sửa các lỗi giao thức và xử lý lỗi đó trước khi tin dùng nó cho cấu hình bàn phím hằng ngày.

11. Project 5: Pokemon Red từ Pallet Town tới gym của Brock

Task thứ năm là phần mở đầu của Pokemon Red, từ Pallet Town qua tới gym của Brock. Theo AICodeKing (video đăng ngày 13/10/2026), đây là một bài test tốt để xem các hệ thống riêng lẻ có thực sự ghép lại với nhau không: bạn cần nhiệm vụ, di chuyển, gặp Pokemon hoang dã, chiến đấu, tiến trình và lưu game cùng nâng đỡ một hành trình liền mạch. Prompt anh mở trên màn hình:

Build me a realistic re creation of pokemon red in html.. the pallet town and quests until rock gym should be working

Theo đánh giá của AICodeKing (video đăng ngày 13/10/2026), Full đưa ra một game chạy trên trình duyệt bên trong một khung máy kiểu Game Boy. Phần điều khiển được giải thích rõ, có nút bấm trên màn hình, và trang vừa với điện thoại được dùng để test. Khi mở ra, nó trông như một trang game nhỏ hoàn chỉnh.

Anh bắt đầu từ đầu và dùng điều khiển bình thường (theo lần chơi của AICodeKing, video đăng ngày 13/10/2026). Phần giới thiệu của Oak, chọn Pokemon khởi đầu và trận đấu với rival đều chạy. Lấy bưu kiện, quay về nhận Pokedex, mua đồ, bắt một Pokemon hoang dã, đổi đội hình và hồi máu ở Pokemon Center cũng chạy. Đường đi tiếp qua Viridian Forest tới Pewter City.

Brock cũng có kết quả thắng và thua chạy được (theo lần chơi của anh, video đăng ngày 13/10/2026). Lần đầu anh thua ở level 7: game đưa đội về Pokemon Center, hồi máu và trừ tiền mà không trao huy hiệu. Sau đó anh luyện qua các trận bình thường. Squirtle vào lần đấu Brock cuối ở level 10, lên 11 sau Geodude, lên 12 sau Onix, và giành Boulder Badge. Lưu game rồi chọn Continue giữ lại huy hiệu đã giành, đội hình, tiền và vị trí.

Theo anh (video đăng ngày 13/10/2026), bài smoke test của chính model dùng dịch chuyển tức thời và đổi level, nhưng kết quả này đến từ việc thật sự chơi qua lộ trình; sự khác biệt đó cho một bức tranh rõ hơn nhiều về những gì người chơi thực sự hoàn thành được.

Điểm yếu chính là độ trung thực (theo đánh giá của AICodeKing, video đăng ngày 13/10/2026). Phòng thí nghiệm của Oak dùng nền cỏ và một hàng cây ngoài trời cùng đồ đạc trông như thùng gỗ. Gym có vấn đề tương tự. Thị trấn và các tuyến đường bị đơn giản hoá thành những hành lang rộng, và Pokemon là những hình bóng vẽ thô. Khung trình duyệt được trau chuốt hơn thế giới bên trong nó.

Một số cơ chế cũng bị đơn giản hoá hoặc chưa đủ (theo đánh giá của anh, video đăng ngày 13/10/2026). Cổng chặn nhiệm vụ đi về phía bắc không có. PC cất được Pokemon nhưng không có workflow rút ra tương ứng. Vật phẩm chiêu thức được trao chỉ đóng vai một món kỷ niệm. Theo anh, những chi tiết đó quan trọng với một bản làm lại, dù chúng không chặn lộ trình cụ thể tới Brock này.

Game được 7.8 trên 10, tăng từ 7.2 của Standard Wonder (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Nó giành trọn điểm hoàn thành gym vì lộ trình và cả hai kết quả đều được chứng minh. Độ trung thực còn thiếu và các cơ chế phụ khiến nó không được chấm như một bản làm lại trung thực đã hoàn chỉnh.

12. Project 6: PulseBoard, app Fitbit với backend Rust

Task cuối là ứng dụng Fitbit. AICodeKing yêu cầu một app desktop có backend Rust, phân tích buổi tập, cardio load, và kiểu tính năng có kết nối như ở một sản phẩm theo dõi sức khoẻ khác mà anh nêu tên. Theo đánh giá của anh (video đăng ngày 13/10/2026), Full build ra PulseBoard với một server Rust, một database SQLite và một giao diện trình duyệt. Đây là một trong những kết quả trông đẹp hơn của nó: dashboard có các thẻ dễ đọc, biểu đồ và điều hướng, và layout vẫn vừa ở bề rộng điện thoại.

Theo số đo của AICodeKing (video đăng ngày 13/10/2026), bạn có thể ghi một buổi tập, lọc lịch sử, mở chi tiết, viết nhật ký, sửa hồ sơ và import dữ liệu local được hỗ trợ. Anh cũng tắt hẳn server rồi khởi động lại: hồ sơ, các buổi tập, bản ghi hằng ngày, giấc ngủ và nhật ký đều còn nguyên. Công thức training load cơ bản qua được một bài kiểm số học độc lập.

Nghe thì hứa hẹn, nhưng lần theo con số đó qua phần còn lại của app thì lộ ra vấn đề (theo số đo của anh, video đăng ngày 13/10/2026). Import một buổi tập làm đổi load nhưng để nguyên điểm strain đã lưu. Đổi hồ sơ nhịp tim cũng để các phép tính cũ vẫn dùng giá trị cũ. Một buổi tập vào ngày không có bản ghi hằng ngày riêng có thể biến mất hoàn toàn khỏi dashboard.

Các khung thời gian cũng có vấn đề tương tự (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Load theo tuần dùng bảy lần ghi nhận ngay cả khi chúng trải gần hai tuần. Trang giấc ngủ có thể tính "nợ ngủ" từ bảy đêm cũ nhất trong lịch sử trả về. Giấc ngủ bị thiếu có thể được thay bằng giả định bảy tiếng bên trong phép tính recovery, trong khi giao diện vẫn hiển thị giấc ngủ là chưa biết. Theo anh, những biểu đồ đó có thể trông thuyết phục trong khi đang mô tả sai khoảng thời gian hoặc dữ liệu chưa đủ.

Các bài kiểm import cũng tìm ra buổi tập trùng lặp và đơn vị thời lượng sai (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Một activity có hình dạng đúng như tài liệu Fitbit mô tả bị bỏ qua vì app chờ một trường ngày khác. Thêm trường đó vào thì lộ ra vấn đề thứ hai: thời lượng một giờ tính bằng mili giây biến thành 3.6 triệu phút. Anh nói rõ đó là một object test tổng hợp dựa theo tài liệu API, không phải dữ liệu tải từ một tài khoản cá nhân.

Có code OAuth và đồng bộ, và URL uỷ quyền local có cấu trúc challenge và redirect như mong đợi (theo đánh giá của anh, video đăng ngày 13/10/2026). Nhưng anh chưa kiểm được một lần đăng nhập Fitbit thật, trao đổi token hay đồng bộ thiết bị, nên các tính năng đó chỉ được điểm giới hạn. App giao ra cũng mở trên trình duyệt; không có gói desktop native. Ngay cả tài liệu của app cũng ghi sai về thiết bị: nó nói Fitbit Air không còn hiện hành, trong khi tài liệu thiết bị của Google có liệt kê nó (theo video đăng ngày 13/10/2026). Theo anh, lỗi đó không làm mọi tính năng local vô dụng, nhưng nó giúp giải thích vì sao anh sẽ kiểm phần tích hợp nhà cung cấp trước khi nhập dữ liệu của chính mình.

PulseBoard được 5.4 trên 10, so với 3.8 của Standard Wonder (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Theo anh, Full giao ra một ứng dụng local hữu ích hơn và phần lưu trữ bền vững chạy được đáng được ghi điểm; các phép tính sức khoẻ và phần nạp dữ liệu vẫn cần làm nhiều trước khi anh dựa vào các khuyến nghị của nó.

13. Bảng KingBench cuối cùng và bảy model

Rồi tới bảng KingBench cuối cùng, theo số đo của AICodeKing (video đăng ngày 13/10/2026): Full được 3.1 cho emulator, 3.0 cho container runtime, 7.0 cho trình thiết kế phòng, 5.5 cho công cụ cấu hình bàn phím, 7.8 cho Pokemon và 5.4 cho app Fitbit. Cộng lại là 31.8 trên 60, tức 53.0%. Standard Wonder kết thúc ở 45.8%, nên Full tăng khoảng 7.2 điểm phần trăm. Nó cải thiện bốn project, hoà một và thua ở trình thiết kế phòng. Mức cải thiện lớn nhất là ở công cụ cấu hình bàn phím và ứng dụng fitness: cả hai có nhiều chức năng chạy được hơn, dù phần kết nối tới giao thức thiết bị và dữ liệu được tính toán vẫn chưa đáng tin.

Trên bảy model đã ghi nhận, theo số đo của AICodeKing (video đăng ngày 13/10/2026), Opus 5.5 dẫn đầu với 57.8%, tiếp theo là GPT-6 Astra 56.5, GPT-6.1 Sol 55.0 và Haiku 5.5 54.2. Full đứng thứ năm với 53.0. Standard Wonder và GLM 5.3 cùng ở 45.8%.

Anh giải thích giới hạn của bảng (video đăng ngày 13/10/2026): đây là điểm cho một bộ sáu ứng dụng được generate từ mỗi model. Các lần chạy cũ hơn dùng Claude Code, Codex và OpenCode, với thiết lập reasoning riêng của từng công cụ và một watchdog giới hạn 60 phút generate. Cả hai lần chạy Muse dùng Muse CLI gốc và không có hạn chót thêm. Vì vậy bảng so sánh những kết quả anh thực sự thu được; nó không tách riêng được model khỏi mọi khác biệt về công cụ hay điều kiện chạy.

Theo anh, từng dòng riêng cũng nói nhiều hơn vị trí cuối cùng (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Opus thắng tổng điểm trong khi chỉ được 3.0 ở task Pokemon. Game của Full đạt 7.8, thấp hơn Sol và Astra nhưng cao hơn Opus. Anh nói mình sẽ nhìn vào loại việc cần làm trước khi coi chênh lệch một bậc là một khuyến nghị mua.

14. Token, chi phí và thời gian generate

Sang token và chi phí, theo số đo của AICodeKing (video đăng ngày 13/10/2026): trên cả sáu task, Full thực hiện 333 lần gọi model được ghi lại và dùng khoảng 30.54 triệu token. Standard Wonder thực hiện 248 lần gọi và dùng khoảng 17.56 triệu. Trong lần chạy này, Full dùng nhiều hơn khoảng 74% số token được đếm.

Con số 30.54 triệu đó bao gồm phần input được dùng lại qua các lần gọi (theo số đo của anh, video đăng ngày 13/10/2026). Full có khoảng 861.000 input token mới, 29.28 triệu input token đã cache và 397.000 output token. Input đã cache vốn là một phần của input, và reasoning vốn là một phần của output, nên không cái nào bị cộng hai lần. Điều này cũng có nghĩa tổng số là thước đo cho cả phiên agent, không phải 30 triệu token code mới được viết ra.

Tính theo cùng biểu giá Wonder, theo số đo của AICodeKing (video đăng ngày 13/10/2026), ước tính cho Full là $17.25 cho cả sáu project, so với $10.52 cho Standard Wonder: nhiều hơn khoảng $6.73, tức tăng 64%. Anh nhắc lại: Full đang được định giá theo biểu giá công bố của Standard Wonder cho phép so sánh này. Con số đó không cho biết Meta sẽ tính bao nhiêu cho một API của Full, và nó không thay thế giá subscription.

Project container chiếm phần ước tính lớn nhất của Full, khoảng $5.12, và vẫn chỉ được 3.0 (theo số đo của anh, video đăng ngày 13/10/2026). Emulator thì ngược lại: Full dùng ít token hơn và tốn khoảng $2.87, so với $3.97 của Standard Wonder, trong khi vẫn được thêm điểm. Theo anh, chi nhiều hơn không đem lại cùng một kiểu lợi ích ở mọi task.

Với các model trước, theo số đo của AICodeKing (video đăng ngày 13/10/2026), phần hạch toán chung đầy đủ chỉ phủ ba project: trình thiết kế phòng, công cụ cấu hình bàn phím và app Fitbit. Trên ba project đó, Full tốn khoảng $6.03 và Standard Wonder $3.11. Haiku khoảng $3.79 tới $3.95. Sol từ $3.42 tới $6.37. GLM là $6.59. Opus là $26.26. Astra từ $18.77 tới $35.66.

Theo anh (video đăng ngày 13/10/2026), các ước tính lịch sử đó giữ nguyên biểu giá tại thời điểm ghi và các khoảng nhạy cảm về giá, bao gồm cả phí tool đã xác nhận ở những chỗ có ghi lại. Con số của Muse ở đây chỉ gồm token của model. Có thể so các ước tính đã ghi trong phạm vi đó, nhưng không thể đặt một hoá đơn ba project cạnh một hoá đơn sáu project rồi gọi đó là bảng xếp hạng chi phí. Báo cáo anh lưu lại có tổng token chính xác và các giả định cho từng phép so sánh.

Full cũng chạy lâu hơn (theo số đo của AICodeKing, video đăng ngày 13/10/2026). Với hai task chạy song song, khoảng thời gian generate của nó là khoảng 58 phút 36 giây; Standard Wonder mất khoảng 15 phút 34 giây. Tức là khoảng 3.8 lần thời gian generate thực tế trong cặp lần chạy này. Con số đó gồm cả các lệnh và việc dùng tool của agent, nên nó không phải phép đo tốc độ phản hồi thô của model.

15. Kết luận của AICodeKing: có chọn Full không

Với AICodeKing (video đăng ngày 13/10/2026), kết quả thuyết phục nhất của Full là game Pokemon: anh có thể bắt đầu từ đầu, đi qua các nhiệm vụ, thua, luyện, đánh bại Brock, và giữ được kết quả sau khi reload. Trình chỉnh phòng cũng cho bạn rất nhiều thứ để tương tác, dù phần lưu, đơn vị và dọn dẹp đồ hoạ của nó cần được xử lý.

Các kết quả yếu hơn cho thấy anh sẽ dành thời gian review ở đâu (theo anh, video đăng ngày 13/10/2026). Trong app bàn phím, một thông báo thành công không đảm bảo cấu hình mong muốn đã tới thiết bị. Trong app fitness, một công thức chạy đúng không đảm bảo mọi biểu đồ đã được cập nhật. Trong emulator, chạy được một bài test nhỏ không xác lập được tương thích với những game người ta thực sự muốn chơi.

Vậy anh có chọn Full thay vì Standard Wonder không? Với sáu prompt này, theo AICodeKing (video đăng ngày 13/10/2026), Full tạo ra một bộ ứng dụng tổng thể tốt hơn, và phần chức năng thêm ở app bàn phím và app fitness nhìn thấy rõ. Nếu đã có quyền truy cập qua subscription và có thể chờ lâu hơn, anh sẽ dùng Full cho một lần thử nữa với các project đó. Anh vẫn sẽ giữ lại trình thiết kế phòng của model thường, vì đó là kết quả mạnh hơn ở task này.

Anh sẽ không mua gói này với kỳ vọng một prompt giao ra được một emulator hoàn chỉnh, một nền tảng container hay một app sức khoẻ đáng tin (theo anh, video đăng ngày 13/10/2026). Full đã tiến được một đoạn đáng kể, nhưng những phần tốt nhất của nó ở đây vẫn cần có người chơi thử game, đổi các thiết lập, reload dữ liệu và kiểm xem hành vi được hứa có giữ đúng không. Theo anh, đó là chỗ thấy được khác biệt giữa một bản demo thuyết phục và một ứng dụng anh sẽ tiếp tục dùng.

Tổng thể, theo AICodeKing (video đăng ngày 13/10/2026), Full khá hay. Anh mời người xem để lại ý kiến trong phần bình luận rồi chào tạm biệt.