# Đội quân Haiku 5.5 subagent có thắng nổi Opus 5.5?

[Dubibubi](https://homus.dev/speakers/dubibubi) · [Dubibubi](https://homus.dev/orgs/dubibubi)

> Ba bài test Opus 5.5 solo đấu Opus chỉ huy đội Haiku 5.5 qua skill /delegate: game, phim samurai, săn bug; Opus thắng 10-2, Haiku chỉ rẻ khi việc tách gọn.

Topics: Coding Agents, Agents, Skills

Canonical: https://homus.dev/talks/can-an-army-of-claude-haiku-5-5-subagents-beat-opus-5-5

## 1. Haiku 5.5 rẻ hơn Opus 5.5 tới 40 lần

Dubibubi mở đầu bằng một con số: Haiku 5.5 vừa ra mắt và có giá rẻ hơn Opus 5.5 tới 40 lần. Anh nói điều này khá điên rồ nếu nghĩ kỹ, vì nó có nghĩa là cứ mỗi một đô Opus tiêu, Haiku chỉ tiêu 2,5 cent. Trên màn hình là một bài đăng trên subreddit r/ClaudeCode với tiêu đề kiểu "Haiku 5.5 rẻ hơn Opus 5.5 40 lần", nêu mức giá Haiku 5.5 là 0,10 đô và 0,50 đô cho mỗi triệu token (prompt và output), so với 4 đô và 20 đô của Opus 5.5; bài viết cũng nói Anthropic khuyến nghị dùng Haiku như một subagent cho Opus, và đây là bản Haiku đầu tiên có thiết lập effort. Đây là mức giá theo video đăng ngày 09/10/2026.

Nhưng model rẻ thường rẻ là có lý do, đúng không? Theo anh, khi chạy một mình, các model rẻ thì nhanh, nhưng chúng có xu hướng sụp đổ ngay khi bạn giao cho chúng một việc có ý nghĩa thật sự. Vì vậy hôm nay anh cho hai Opus đối đầu trực tiếp: một Opus làm việc solo, còn Opus kia chỉ huy cả một đội quân Haiku agent. Câu hỏi cần trả lời là: liệu chúng ta có thật sự nhận được cùng chất lượng công việc nhưng chỉ tốn một phần nhỏ chi phí hay không?

Hai thiết lập được đem ra so: bên trái Opus 5.5 tự làm toàn bộ, bên phải Opus 5.5 lên plan rồi giao việc cho nhiều Haiku 5.5 subagent.

## 2. Luật chơi: ba bài test, bốn điểm mỗi bài

Anh đã thiết kế ba bài test khác nhau để đẩy cả hai thiết lập tới giới hạn tuyệt đối của chúng. Mỗi bài test có 4 điểm để tranh: 2 điểm cho bên có chất lượng output tốt nhất, 1 điểm cho bên rẻ nhất và 1 điểm cho bên nhanh nhất. Nói cách khác, chất lượng nặng gấp đôi so với chi phí hay tốc độ.

![Thẻ luật chơi: 4 points per test, Best quality 2 pts, Cheapest 1 pt, Fastest 1 pt](https://homus.dev/photos/Ug3x37N6Z_E-0043.jpg)

Bảng luật chơi: mỗi bài test có 4 điểm, chia thành Best quality (2 điểm), Cheapest (1 điểm) và Fastest (1 điểm).

## 3. Test 1: một bản clone Angry Birds

Không vòng vo thêm, anh vào thẳng việc. Bài test đầu tiên là build một game mà gần như ai cũng đã chơi ít nhất một lần trong đời: đúng vậy, một bản clone Angry Birds. Theo anh, đây thật ra là một bài test đầu tiên rất tốt cho đội, vì một game như thế này là rất nhiều việc: có physics, có level, có menu, có điểm số. Nó sẽ cho thấy rõ Haiku thực thi được tới đâu với những việc phức tạp hơn.

Màn hình chia đôi: bên trái là Opus 5.5 chạy một mình, bên phải là đội quân Haiku chạy thông qua Opus. Cả hai đều được đặt ở mức effort cao nhất (extra high). Anh dán prompt cho bản clone Angry Birds và gửi đi. Phần cuối của prompt, hiện trong ô nhập ở cả hai bên, như sau:

```
- At least 3 playable levels with increasing difficulty.
- A scoring system, win/lose conditions, restart button, and level progression.
- Expressive characters, polished environments, smooth animations, particle effects, and satisfying destruction.
- Responsive gameplay with intuitive mouse controls.
Creative direction:
You have complete creative freedom over the characters, art direction, environments, and additional mechanics. Create original artwork rather than copying existing game assets.
Prioritize visual polish, satisfying physics, and genuinely enjoyable gameplay. Use appropriate JavaScript physics libraries if needed.
Final deliverable:
You MUST build and launch a fully working prototype running on localhost.
- Implement the complete project, not just a mockup.
- Start the local development server.
- Test the actual gameplay and fix any obvious bugs.
- Keep the server running so I can immediately play the game.
- Provide the exact localhost URL where I can access it.
Do not consider the task complete until I have a working, playable game accessible through my browser on localhost.
```

Hai bên nhận đúng cùng một prompt. Ở ô nhập, phía dưới có nhãn model Opus 5.5 và mức Extra; bên solo chạy trong một folder `build-1`, bên đội chạy trong `builds/team/build-1`.

Bốn mảng việc Dubibubi kể ra cho bài test đầu: physics, level, menu và điểm số.

## 4. Skill /delegate: biến Opus thành manager

Khác biệt duy nhất giữa hai bên là ở phía đội, anh thêm skill `/delegate`. Đây là custom skill của chính anh, biến Opus thành một manager: Opus làm toàn bộ phần suy nghĩ và lên plan, rồi giao phần build thật sự cho các Haiku sub-agent.

![Sơ đồ Opus 5.5 lên plan, nối tới năm ô Haiku 5.5 sub-agents làm phần build](https://homus.dev/photos/Ug3x37N6Z_E-0143.jpg)

Cách skill /delegate chia vai: Opus 5.5 lên plan (ô Plan có các mục đã đánh dấu), rồi giao việc xuống năm Haiku 5.5 sub-agent làm phần build.

Lý do anh dùng một skill thay vì chỉ ghi trong prompt: anh để ý rằng khi chỉ đơn giản yêu cầu Opus dùng Haiku sub-agent ngay trong prompt, Opus bắt đầu đi tắt (cut corners), và việc bàn giao (handoff) trở nên khá lộn xộn. Còn với skill, anh định nghĩa rõ được vai của Opus là manager và vai của Haiku là người thực thi (executor). Nhờ vậy kết quả cuối chặt chẽ hơn nhiều, mà chi phí vẫn y như cũ.

Anh nói bạn hoàn toàn có thể tự dựng phiên bản skill của riêng mình dựa trên những gì anh mô tả trong video; bản dựng sẵn của anh nằm trong cộng đồng trả phí của anh.

## 5. Dashboard theo dõi token, thời gian và chi phí

Như thường lệ, anh có một dashboard theo dõi usage để đo input token, output token, thời gian mỗi bản build và chi phí của nó. Ở phía đội, Opus và Haiku được theo dõi riêng, nên không có gì lọt qua được. Sau đó anh để hai model "nấu" (let them cook) và hẹn gặp lại sau một lúc.

Những gì dashboard của Dubibubi ghi lại cho mỗi bản build; ở phía đội, phần của Opus và phần của Haiku được tách riêng.

## 6. Chơi thử bản của Haiku team: Squawkpult

Một lúc sau, cả hai bản build đều xong. Anh bắt đầu với bản của Haiku team, một game tên Squawkpult. Level 1, "First Flight". Anh khen tiếng động khi bắn ("ồ, tôi thích tiếng này"), rồi bắn trúng: "Boom. Ồ, đã thật. Đã thật sự." Có một lúc anh ngạc nhiên vì một con đối thủ trúng đòn mà không chết ("Đùa à?"), nhưng rồi vẫn thắng màn đầu. Không được ba sao, nhưng anh chấp nhận.

Tiếp theo là màn "Canyon Clash" giữa sa mạc và xương rồng. Anh thích việc có cả thùng TNT ở đó, khá hay, và khá đã tay. Lần này anh được ba sao và reo lên ăn mừng. Sau đó là màn cuối, nơi anh nghĩ mình qua dễ thôi. Anh nói thật điên rồ khi nghĩ rằng Haiku build ra cái này: anh sẽ không bao giờ tin chuyện đó dù có một triệu năm.

![Game Squawkpult của Opus + Haiku team, level 5 Thorn King's Keep trên nền tuyết, dòng chữ Boom click to explode](https://homus.dev/photos/Ug3x37N6Z_E-0331.jpg)

Màn cuối trong game của Haiku team (nhãn "Built by Opus + Haiku team"): level 5 "Thorn King's Keep" trên nền tuyết, với lâu đài gỗ đá, con chim bom và gợi ý "Boom: click to explode!".

Sau vài lượt anh phá xong màn cuối. Kết luận của anh: khá vui, khá chắc tay. "Được đấy Haiku, không tệ, không tệ." Màn hình chọn level của game cho thấy năm màn: First Flight, Canyon Clash, Frozen Fortress, Bramble Bastion và Thorn King's Keep.

## 7. Chơi thử bản Opus solo và kết quả Test 1

Tiếp theo là bản Opus solo, một game tên Feather Fling. Ngay từ đầu anh thấy bản này có cảm giác 3D hơn hẳn. Có một animation nhỏ rất hay ở đây, khá đã mắt, ngay cả cách sợi dây ná đung đưa qua lại cũng rất đã. Anh có một cú bắn rất đẹp và đùa rằng người xem phải khen anh vì cú đó. Theo anh, xét về chất lượng output, bản Opus solo chắc chắn thắng ở bài này.

![Màn hình mở đầu game Feather Fling của Solo Opus với năm nhân vật và nút Play, Choose Level](https://homus.dev/photos/Ug3x37N6Z_E-0357.jpg)

Màn hình mở đầu Feather Fling, bản Opus solo build: dòng giới thiệu "The Gloops swiped the eggs. Time to fling some feathers.", năm nhân vật (Ember, Bolt, Trill, Kaboom và đối thủ Gloop), nút Play, Choose Level và hướng dẫn kéo, thả, click để dùng sức mạnh.

Rồi anh mở dashboard. "Thú vị đấy": khoản tiết kiệm không lớn, nhưng vẫn là tiết kiệm. Còn về thời gian thì Haiku mất lâu hơn đáng kể. Trên dashboard, bản Opus solo chạy 43 phút 20 giây với chi phí API ước tính 12,78 đô; bản Opus + Haiku chạy 1 giờ 29 phút với 11,62 đô, tức tiết kiệm 9,1% (số liệu trong video đăng ngày 09/10/2026).

Anh lưu ý một chi tiết: lúc đầu Haiku team thật ra đang thua về chi phí. Có vẻ đội này dồn phần lớn token ra phía đầu (front run), vì nó spawn một loạt sub-agent khác nhau để hoàn thành việc, nên lúc đó có một khoảng cách rõ trên biểu đồ. Nhưng tới cuối thì khác biệt đã rõ: token của Haiku chiếm 91% tổng của lane, còn Opus chỉ 9%. Trên màn hình, thanh token của lane đội ghi tổng 100.398.675 token, phần của Opus là 9.080.015 token (9,0%), trong khi lane Opus solo là 27.973.296 token.

Chấm điểm: Opus solo được 2 điểm chất lượng và thêm 1 điểm vì nhanh hơn, còn Haiku được 1 điểm vì rẻ hơn. Opus đang dẫn, và anh chờ xem Haiku có lấy lại được ở bài thứ hai không.

## 8. Test 2: phim ngắn samurai vẽ bằng JavaScript

Bài tiếp theo đi theo một hướng khác. Theo anh, build một game là một chuyện, nhưng một plan chỉ cho bạn biết cần build gì, nó không thể nói cho bạn biết sản phẩm nên tạo cảm giác thế nào. Vì vậy anh muốn xem Haiku có "gu" (taste) hay không.

Cảm hứng cho bài này đến từ Kevin Ngo, người hay cho Claude tạo những animation rất đẹp bằng code. Trên màn hình là một bài đăng của Kevin Ngo trên X: anh ấy làm một website là một thị trấn với 10 căn phòng có animation, trong mỗi phòng Claude giúp một người trong ngày của họ, làm bằng Claude Sonnet 5.5. Dubibubi sẽ làm đúng kiểu đó.

Đề bài là một phim ngắn hoạt hình về samurai dài 30 đến 60 giây, có đủ một cốt truyện theo vòng cung hành trình người hùng (hero's journey), và mọi khung hình đều được vẽ bằng JavaScript ngay trong browser. Hai bên được toàn quyền sáng tạo về câu chuyện. Prompt anh dùng, mở trong một Google Doc tên "Animation test":

![Google Doc chứa prompt phim ngắn samurai, phần Story requirements và Art direction Japanese ink painting](https://homus.dev/photos/Ug3x37N6Z_E-0543.jpg)

Prompt của Test 2 trong Google Doc: mở đầu bằng yêu cầu làm phim samurai 30 đến 60 giây chỉ bằng HTML, CSS và JavaScript, rồi tới các mục Story requirements và Art direction theo tranh mực Nhật Bản.

```
Create a cinematic 30–60 second animated short film about a samurai, built entirely using HTML, CSS, and JavaScript.
You are responsible for writing the story, designing the characters, directing the scenes, and implementing the animation.
Story requirements:
* Tell an original, emotionally compelling story about a samurai.
* Follow a recognizable hero's journey arc: introduction, challenge, struggle or transformation, and resolution.
* Make the story understandable primarily through visual storytelling rather than dialogue.
* Include multiple distinct scenes, meaningful character movement, and at least one visually impressive action sequence.
* Deliver a satisfying ending within 30–60 seconds.
Art direction - Japanese ink painting:
* The entire film should resemble traditional Japanese sumi-e ink wash painting brought to life.
* Use expressive black brush strokes on textured, off-white Japanese paper.
* Keep the palette predominantly black, white, and grey, with extremely limited accent colours if necessary.
* Incorporate ink bleeding, brush textures, flowing fabric, wind, ink splashes, and atmospheric effects.
* Emphasize strong silhouettes, dramatic compositions, negative space, and cinematic camera movement.
* Make the visuals feel hand-painted, artistic, and intentional rather than generic digital animation.
Animation requirements:
* Use HTML, CSS, JavaScript, Canvas, or SVG.
* Cinematic 16:9 widescreen presentation.
* Smooth character animations, environmental effects, camera movements, and scene transitions.
* Include Play and Replay controls.
* The film should automatically play from beginning to end in approximately 30–60 seconds.
* This must feel like an animated film, NOT a slideshow of static images.
* Do not use pre-rendered videos or external AI video-generation services. The animation must be rendered through code in the browser.
You have complete creative freedom over the story, characters, choreography, and ending.
Prioritize cinematic quality, emotional storytelling, and beautiful animation.
Final deliverable:
You MUST build and launch a fully working prototype running on localhost.
* Implement the complete animated film, not just a storyboard or mockup.
* Start the local development server.
* Test the entire animation from beginning to end, fixing broken scenes, transitions, or timing issues.
* Keep the server running so I can immediately watch the film.
* Provide the exact localhost URL where I can access it.
Do not consider the task complete until I can open the localhost URL in my browser, press Play, and watch the entire finished animated short film.
```

Bản prompt anh chia sẻ công khai có thêm một ghi chú ở đầu: bạn cần bảo Opus dùng ElevenLabs cho phần lồng tiếng (narration) và đưa nó API key ElevenLabs của bạn. Sau đó anh để hai bên chạy và hẹn gặp lại.

## 9. Một đội Haiku subagent đang chạy trông thế nào

Trong lúc chờ, anh cho xem cảnh khi bạn chạy một loạt sub-agent. Ở cột bên phải là một loạt Haiku 5.5 agent đang chạy. Bạn thấy được mỗi agent đang dùng bao nhiêu token, bao nhiêu tool call, và có thể bấm vào từng agent để xem nó đang làm cụ thể việc gì. Lúc đó có tổng cộng 13, 14 Haiku subagent chạy cùng lúc, tức là đang có rất nhiều việc được giao xuống.

![Phiên làm việc của Opus điều phối: tin nhắn từ subagent, 11 background commands completed, 13 running tasks](https://homus.dev/photos/Ug3x37N6Z_E-0623.jpg)

Opus đóng vai manager trong lúc làm phim: nó đọc kết quả render của subagent, nhận xét dáng samurai ổn nhưng tư thế quỳ làm ống quần hakama phồng lên và giáp của con quỷ oni trông thô, nên gửi một follow-up có mục tiêu; dưới cùng là 11 background command đã xong và 13 task đang chạy.

Trên màn hình còn thấy rõ cách Opus kiểm tra việc của Haiku: nó đọc file posesheet, ghi rằng "character agent" đang sửa phần vải khi quỳ và bộ giáp oni, đồng thời chờ các phần cảnh, cơn bão, các bản sửa cho cảnh S1 và phần chuyển cảnh.

## 10. Phim của Opus solo: The Red Thread

Cả hai model đều xong, và anh rất háo hức với bài này. Anh bắt đầu với Opus solo, một phim có tên "The Red Thread" (Sợi chỉ đỏ). Giọng kể mở đầu: người ta nói một sợi chỉ đỏ ràng buộc chúng ta với những người ta yêu thương. Con gái của người samurai buộc một sợi vào thanh kiếm của ông để ông luôn tìm được đường về nhà.

"Opus làm cái này á? Trời ơi, ấn tượng thật." Anh đùa rằng anh cũng tự thấy ấn tượng với chính mình. Anh cho biết phần lồng tiếng dùng ElevenLabs, phòng khi ai thắc mắc. Phim tiếp tục: rồi khói bốc lên phía sau dãy núi, và ông đi về phía nó. Sau cảnh giao đấu, giọng kể nói sợi chỉ đã nhớ thay cho ông, và nó dẫn ông về nhà. Phim kết thúc bằng chữ Hán 終 (hết) trong một vòng tròn mực, với con dấu đỏ.

![Cảnh phim The Red Thread của Solo Opus: samurai cầm kiếm có sợi chỉ đỏ, núi tranh mực và mặt trời đỏ](https://homus.dev/photos/Ug3x37N6Z_E-0733.jpg)

Một cảnh trong "The Red Thread" do Opus solo làm: người samurai đứng trên sườn đồi, chuôi kiếm buộc sợi chỉ đỏ, phía sau là dãy núi vẽ kiểu tranh mực sumi-e, mặt trời đỏ và cành mai trắng.

Anh thừa nhận mình thật sự ấn tượng, không ngờ output lại tốt tới mức đó. Anh không biết Haiku sẽ cạnh tranh nổi với cái này thế nào, nhưng giờ thì rất háo hức xem Haiku làm gì.

## 11. Phim của Haiku team: Ensō

Phim của Haiku team có tên "Ensō" (円相, vòng tròn thiền), màn hình mở đầu ghi "a sumi-e short film · 56 seconds · sound on". Phim mở bằng câu: "Every story begins... with a single drop of ink" (Mọi câu chuyện đều bắt đầu từ một giọt mực). Giọng kể tiếp tục: dưới gốc mận già, một người thầy trao lại thanh kiếm của mình, rồi gió mang ông đi, và bóng tối ập tới. Dubibubi nhận xét phim này mở tiếng hiệu ứng khá to. Trong bóng tối, lời của người thầy quay trở lại, và anh thấy đoạn đó khá hay. Phim kết lại khi vòng tròn khép kín.

![Cảnh phim Ensō của Opus + Haiku team: samurai lao tới chém một bóng quỷ mực đen giữa rừng tre](https://homus.dev/photos/Ug3x37N6Z_E-0834.jpg)

Cảnh giao đấu trong "Ensō" do Opus + Haiku team làm: người samurai lao kiếm vào một khối mực đen hình con quỷ, giữa rừng tre và mây mực.

Anh nói đừng hiểu lầm, bản của Haiku vẫn ấn tượng, nhưng bài test này khiến anh nhận ra Opus 5.5 giỏi tới mức nào. Bản Opus solo có cảm giác như một bộ phim thật: từ cách kể chuyện, âm thanh, tới mọi thứ khác đều làm anh choáng ngợp. Anh mở lại đoạn mở đầu của Opus để khen giọng đọc ("giọng hay cỡ nào chứ?"), và gọi đó là thứ tuyệt vời, tuyệt vời thật sự.

## 12. Kết quả Test 2: Opus thắng trọn cả ba hạng mục

Không cần bàn nhiều, anh cho Opus thắng về output ở bài này, 2 điểm. Rồi anh mở dashboard và nói trước rằng người xem sẽ không ấn tượng đâu: Haiku team tốn gần 80% chi phí hơn, mất thêm một tiếng, mà vẫn ra kết quả kém hơn. "Thôi nào."

![Dashboard so sánh Build 1 và Build 2 giữa Opus 5.5 solo và Opus + Haiku 5.5, với token, thời gian và chi phí](https://homus.dev/photos/Ug3x37N6Z_E-0945.jpg)

Dashboard sau Test 2: ở Build 2, Opus solo dùng 58.987.937 token trong 1 giờ 39 phút, chi phí ước tính 25,04 đô; Opus + Haiku dùng 471.990.314 token trong 2 giờ 38 phút, 44,79 đô, tức đắt hơn 78,9% (số liệu theo video ngày 09/10/2026). Build 3 khi đó chưa bắt đầu.

Theo anh, khoảng cách giữa cách để Haiku làm hết dưới sự quản lý của Opus, so với Opus tự lên plan rồi quản lý, thật ra không hiệu quả như anh nghĩ. Anh tò mò nếu đưa Sonnet vào thì sao: sẽ tốn hơn, hay Opus sẽ không phải đưa nhiều feedback như thế và cuối cùng lại rẻ hơn? Đó là điều anh muốn thử sau video này. Còn bài thứ hai thì Opus 5.5 solo thắng tuyệt đối: thắng chất lượng, thắng tốc độ và thắng cả chi phí. Haiku thật sự phải gỡ lại ở bài tiếp theo.

## 13. Test 3: review code và săn bug trong app ACE

Bài cuối đi theo hướng hoàn toàn ngược lại, vì một việc anh dùng các model này liên tục là review code. Đây là bài mà đội có thể sụp đổ, vì muốn tìm ra một bug thì phải hiểu cả app ăn khớp với nhau thế nào, và đó chính xác là kiểu suy nghĩ mà ta đã lấy đi khỏi Haiku. Trên màn hình là dòng chữ "Finding a bug means seeing the whole app. Exactly what we took away from Haiku."

Cách làm: anh cho hai bên truy cập app của mình tên ACE và xem chúng tìm và sửa được bao nhiêu bug. Opus solo tự làm toàn bộ. Ở phía đội, Opus chia app thành nhiều phần và giao mỗi phần cho một Haiku đi săn bug. Cuối cùng anh đưa bug report của hai bên cho GPT-6 Astra, mà theo anh là model review code tốt nhất tại thời điểm làm video (09/10/2026), để chấm điểm. Mỗi bug được xác nhận là thật được 1 điểm. Nhưng mỗi bug bịa ra hoặc ảo giác (hallucinate) thì bị trừ 1 điểm. Nên nếu Haiku chỉ bịa ra một đống bug cho có vẻ bận rộn, điều đó sẽ kéo tổng điểm xuống.

Luật chấm của Test 3: một model khác đọc bug report và chấm từng mục; bug được xác nhận cộng 1, bug bịa trừ 1, nên đoán bừa sẽ bị phạt.

Anh lại để các model chạy và hẹn gặp lại sau một lúc.

## 14. Kết quả Test 3: 89 điểm so với 122 điểm

Khi cả hai bên xong, lần này anh mở usage tracker trước, vì có một con số lớn: đội tiết kiệm tới 61% so với Opus. Trên dashboard, Build 3 của Opus solo dùng 493.369.933 token trong 38 phút 49 giây với chi phí ước tính 141,54 đô, còn Opus + Haiku dùng 788.080.275 token trong 49 phút 19 giây với 55,16 đô, tức tiết kiệm 61,0% (số liệu theo video ngày 09/10/2026; chú thích dưới dashboard ghi bảng giá Opus 5.5 là 4 / 0,20 / 20 đô và Haiku 5.5 là 0,10 / 0,01 / 0,50 đô cho mỗi triệu token input / cached / output với prompt tới 100k token, kiểm ngày 8/10/2026).

Anh thấy điều này thú vị, vì ở bài review code thì Haiku team mới thật sự tỏa sáng một chút, so với lúc làm animation. Thấy được điểm mạnh và điểm yếu của mỗi bên là điều đáng giá.

![Bảng chấm của Haiku team: 98 numbered bugs, 19 candidate bugs, tổng 103 confirmed, 14 rejected, điểm +89](https://homus.dev/photos/Ug3x37N6Z_E-1223.jpg)

Bảng điểm của Haiku team: 98 bug đánh số (95 xác nhận, 3 bị loại, +92) và 19 bug ứng viên (8 xác nhận, 11 bị loại, -3), tổng 103 xác nhận, 14 bị loại hoặc chưa xác nhận, điểm +89. Ghi chú bên dưới nói "unconfirmed" không có nghĩa là đã chứng minh là bịa.

Bảng điểm của Haiku cho thấy tổng cộng 103 bug, nhưng đó chỉ là số đã xác nhận. Đội này còn có 14 bug bị loại, tức là ảo giác hoặc bịa ra, nên điểm cuối còn 89. Theo anh, vẫn khá chắc. Để so sánh: khi giao việc này cho Fable, nó chỉ được khoảng 21 bug. Gần đây anh cũng giao việc này cho Sonnet 5.5, và nó tìm được tổng cộng 87 bug với điểm 85. Như vậy Haiku team với 89 điểm là không tệ, nó đã thắng Sonnet chạy một mình.

![Biểu đồ điểm: Haiku team 89, Sonnet 5.5 solo 85, Fable 5.1 solo khoảng 21, Opus 5.5 solo dấu hỏi](https://homus.dev/photos/Ug3x37N6Z_E-1303.jpg)

So sánh điểm review code trước khi lộ kết quả Opus: Haiku team (Opus + Haiku 5.5) 89, Sonnet 5.5 solo 85, Fable 5.1 solo khoảng 21, và Opus 5.5 solo còn là dấu hỏi.

Nhưng liệu nó có thắng Opus 5.5? Và đây: điểm cuối của Opus là 122 bug được xác nhận, không có một bug nào bị bịa. Trên màn hình, bảng của Opus ghi 117 bug đánh số và 5 lỗi tiềm ẩn (latent defects), tất cả đều được xác nhận, 0 bịa, tổng +122. Anh thấy điều này rất thú vị, vì cả hai bên đều có Opus, chỉ khác là một bên có thêm Haiku, và bên có Haiku có vẻ bị lạc trong mã nguồn một chút. Anh không chắc những bug bịa này đến từ đâu: từ chính các model Haiku, từ việc bàn giao, hay từ những lần qua lại. Nhưng một điều rõ ràng: Opus thắng bài này về chất lượng output.

Chấm điểm: 2 điểm cho Opus vì tìm được nhiều bug hơn và output tốt hơn; 1 điểm cho Haiku vì chi phí; và 1 điểm nữa cho Opus về tốc độ, vì nó xong sớm hơn 10 phút.

## 15. Tổng điểm 10-2 và bài học về handoff

Sau cả ba bài test, tỉ số là 10-2 nghiêng về Opus 5.5 solo. Anh thật lòng không ngờ nó lại một chiều như vậy. Opus thắng về chất lượng ở mọi bài. Hai điểm duy nhất của Haiku đến từ chi phí, và ở bài phim samurai thì Haiku còn không thắng nổi chi phí: đội tốn gần 80% hơn và mất thêm một tiếng.

Nhưng anh cũng nói đừng hiểu lầm: Haiku vẫn build được một game Angry Birds chơi được, và tìm ra hơn 100 bug thật trong app của anh. Theo anh, vấn đề nằm ở handoff. Mỗi lần Opus giao cho Haiku một việc rồi kiểm tra kết quả, những lần qua lại đó tốn token. Ở bài review code, nơi app tách được thành từng phần riêng, đội tiết kiệm được 61%. Còn ở bài phim, nơi mọi thứ phải ăn khớp với nhau, khoản tiết kiệm biến mất hoàn toàn.

![Hai thẻ so sánh: Code review 61% saved và Samurai film 0%](https://homus.dev/photos/Ug3x37N6Z_E-1443.jpg)

Khoản tiết kiệm của Haiku team theo loại việc: review code tiết kiệm 61%, phim samurai 0%.

Kết luận của anh: nếu một việc tách gọn được thành từng phần, như săn bug, hãy giao cho một đội Haiku. Nếu việc đó cần gu hoặc cần nhìn toàn cảnh, hãy để Opus tự làm. Bước tiếp theo, anh muốn chạy lại đúng thiết lập này với Sonnet 5.5 làm worker, để xem một worker thông minh hơn có khiến Opus phải can thiệp ít đi không.

Quy tắc Dubibubi rút ra sau ba bài test, kèm con số của chính anh theo video ngày 09/10/2026.

Anh mời người xem bình luận xem muốn anh thử những model nào tiếp theo, và chào tạm biệt.

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

- Tên gốc: Can an Army of Claude Haiku 5.5 Subagents Beat Opus 5.5?
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=Ug3x37N6Z_E](https://www.youtube.com/watch?v=Ug3x37N6Z_E)

- Kênh YouTube Dubibubi (Dubibubi): [youtube.com/channel/UC4SgqYQmdTCKXUoer2U-lcg](https://www.youtube.com/channel/UC4SgqYQmdTCKXUoer2U-lcg)

- Tài liệu Claude Code về subagent, cách định nghĩa subagent riêng và chọn model cho nó: [code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents)

- Tài liệu Claude Code về skill: [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

Nguồn: https://homus.dev/talks/can-an-army-of-claude-haiku-5-5-subagents-beat-opus-5-5 · cập nhật 2026-10-20