GitHub thử nghiệm HydraFusion, cho Copilot phối hợp nhiều AI model trong một tác vụ

GitHub đang thử nghiệm Project HydraFusion trong GitHub Copilot CLI, một lớp orchestration có thể tự chọn không chỉ model mà cả cách nhiều model phối hợp để xử lý cùng một tác vụ coding. Thay vì luôn giao toàn bộ yêu cầu cho một model cố định, HydraFusion có thể để một model xử lý trực tiếp, thử bằng model hiệu quả hơn rồi mới nâng cấp, hoặc dùng một model khác làm critic trước khi sửa lại kết quả.

GitHub công bố HydraFusion trên GitHub Blog ngày 4/9/2026 và hiện cung cấp dưới dạng research preview. Đây chưa phải tính năng GA, kết quả có thể thay đổi trong quá trình thử nghiệm và GitHub cũng nói rõ model, workflow, tên gọi, availability lẫn hành vi sản phẩm vẫn có thể được điều chỉnh.

GitHub đưa HydraFusion vào Copilot CLI dưới dạng research preview

HydraFusion hiện xuất hiện trong GitHub Copilot CLI qua chế độ thử nghiệm. Người dùng chọn HydraFusion như chọn một model, nhưng phía sau giao diện đó là một runtime có thể xây execution plan và gọi model từ nhiều nhà cung cấp khác nhau tùy từng yêu cầu.

Theo GitHub, preview này có trên tất cả các gói GitHub Copilot thông qua /experimental trong Copilot CLI. Với tài khoản do tổ chức quản lý, quyền dùng Copilot CLI và các tính năng experimental vẫn có thể phụ thuộc chính sách do admin thiết lập.

Điểm cần phân biệt là HydraFusion không phải một foundation model mới. Developer không nhận thêm một model kiểu Claude, Gemini hay GPT. Thứ GitHub đang thử nghiệm là một lớp điều phối đứng trên các model hiện có và quyết định đường đi của tác vụ.

Điểm mới không phải thêm một model, mà là để Copilot xây workflow nhiều model

GitHub trước đó đã có Auto model selection, cơ chế xem xét tác vụ rồi chọn một model phù hợp. HydraFusion đi xa hơn: runtime có thể chọn một chuỗi thực thi, trong đó nhiều model giữ vai trò khác nhau ở các bước khác nhau.

Sự khác biệt này quan trọng vì một tác vụ coding không chỉ có câu hỏi “model nào mạnh nhất?”. Một yêu cầu đơn giản có thể không cần model đắt nhất. Một yêu cầu khó có thể cần escalation. Một thay đổi dễ sai có thể hưởng lợi từ việc model thứ hai chỉ đọc và phản biện trước khi solver sửa lại.

GitHub mô tả HydraFusion như một bước trong chiến lược semantic routing giữa local model, cloud model và compound model. Với người dùng, phần phức tạp được giấu phía sau: họ chọn HydraFusion, còn runtime cố cân bằng chất lượng, chi phí và độ trễ.

HydraFusion hiện có ba execution pattern: Single, Cascade và Critique

Ở thời điểm công bố, HydraFusion chọn một trong ba pattern cho mỗi request. Đây là ba cách runtime tổ chức công việc, không phải ba chế độ mà người dùng tự buộc từng request phải chạy theo.

Single: một model được chọn và xử lý tác vụ trực tiếp. Đây là đường đi ít phức tạp nhất, phù hợp khi runtime đánh giá rằng thêm review hay escalation không tạo đủ giá trị để bù chi phí và latency.

Cascade: một model hiệu quả hơn làm bản đầu tiên, sau đó quality gate quyết định chấp nhận hay chuyển sang model mạnh hơn. Cơ chế này nhằm tránh dùng inference đắt tiền cho mọi request, nhưng vẫn giữ đường lui khi kết quả ban đầu không vượt qua ngưỡng chất lượng.

Critique: một model tạo bản nháp, một critic độc lập từ một model family khác xem xét trong môi trường read-only, sau đó model ban đầu sửa lại một lần dựa trên phản hồi. GitHub cho biết critic không có tool và không được sửa repository.

Ba pattern cùng giải một bài toán: không phải tác vụ nào cũng cần cùng mức intelligence, cùng số lượt model call hoặc cùng cơ chế kiểm tra. HydraFusion cố chọn workflow ít phức tạp nhất mà runtime cho rằng vẫn đủ đạt quality bar.

HydraFusion quyết định route dựa trên những tín hiệu nào?

GitHub cho biết HydraFusion xem workflow selection như một bài toán tối ưu. Runtime dùng các capability signal liên quan đến reasoning, code generation, debugging và tool use để chọn pattern thực thi.

GitHub không công bố một luật cố định kiểu “sửa ba file thì dùng Cascade” hay “debug thì luôn dùng Critique”. Công ty cũng không công bố một roster model cố định cho HydraFusion, vì lineup có thể thay đổi khi model mới được đưa vào Copilot và kết quả eval thay đổi.

Vì vậy, HydraFusion nên được hiểu là một policy layer động. Cùng một loại yêu cầu nhưng ở thời điểm khác, với model pool hoặc pricing khác, runtime có thể chọn đường đi khác.

Benchmark của GitHub: chi phí giảm mạnh, nhưng chất lượng không thắng Opus 5 ở mọi bài test

GitHub đánh giá các policy cố định của HydraFusion trên ba agentic coding benchmark: TerminalBench 2.1, DeepSWE và CheckpointBench. Baseline so sánh gồm Claude Opus 5 và GPT-5.6 Sol; bảng kết quả chính của GitHub trình bày chênh lệch so với Opus 5.

TerminalBench 2.1: HydraFusion đạt verified task quality cao hơn 4,9 điểm phần trăm, trong khi chi phí workflow ước tính thấp hơn 67% so với Opus 5.

DeepSWE: chất lượng thấp hơn Opus 5 khoảng 1,5 điểm phần trăm, đổi lại chi phí ước tính thấp hơn 36%.

CheckpointBench: chất lượng thấp hơn 0,1 điểm phần trăm, gần như ngang baseline, trong khi chi phí ước tính thấp hơn 65%. CheckpointBench là benchmark nội bộ của GitHub được xây từ các session Copilot thực và neo vào public repository cùng commit cố định để có thể replay.

Các con số này không nên được đọc thành “HydraFusion luôn tốt hơn Opus 5”. Trên hai trong ba benchmark, quality không cao hơn baseline. Giá trị mà GitHub đang cố chứng minh là quality-cost trade-off: có thể tiến gần chất lượng frontier hoặc vượt trong một số trường hợp mà không cần trả chi phí frontier cho toàn bộ workflow.

GitHub cũng giới hạn claim rất rõ. Đây là controlled offline evaluation, phụ thuộc revision benchmark, model pool, workflow configuration, pricing assumption và mức reasoning được dùng trong test. Research preview được mở ra chính để xem kết quả đó có chuyển thành lợi ích thật trên workload của developer hay không.

Chi phí được tính cho toàn bộ workflow, không chỉ model cuối cùng

Khi một request có thể đi qua draft, critique, revision, escalation, retry hoặc fallback, chi phí không còn tương đương với giá của một model duy nhất. GitHub nói HydraFusion dùng complete accounting, cộng cost và usage của tất cả các leg trong workflow.

Điều đó cũng áp dụng cho billing. GitHub Community cho biết HydraFusion không có một khoản phí riêng; người dùng trả theo token mà các model cấu thành thực sự tiêu thụ, với mức giá tiêu chuẩn của từng model.

Vì Cascade chỉ gọi model mạnh hơn khi quality gate yêu cầu, chi phí trung bình có thể giảm nếu nhiều tác vụ được chấp nhận ngay ở bước đầu. Nhưng một request bị escalation, retry hoặc đi qua Critique có thể tốn nhiều bước hơn và cũng có thể chậm hơn.

GitHub đặt năm guardrail cho việc nhiều model cùng đụng vào một repository

Multi-model orchestration làm tăng số trạng thái trung gian và số điểm có thể thất bại. GitHub vì thế mô tả năm nguyên tắc vận hành để kiểm soát workflow ở cấp repository.

Complete accounting: theo dõi đầy đủ usage và cost của draft, critique, revision, escalation, retry và fallback, thay vì chỉ nhìn model tạo câu trả lời cuối.

Bounded execution: mỗi leg có timeout và hành vi cancellation rõ ràng để tránh workflow kéo dài không giới hạn và làm chi phí vượt kiểm soát.

Isolated review: bước review chạy trong context cô lập, không tool; các solver step mới dùng shared workspace và permission-aware agent loop. Critic được quyền đánh giá, không được quyền tự thay đổi repository.

Fail-safe application: nếu workflow bị hủy hoặc không vượt validation, HydraFusion không apply patch. Mục tiêu là tránh để một thay đổi dở dang lọt vào repository chỉ vì một leg trước đó đã tạo được code.

Validated routing: trước khi thực thi, hệ thống kiểm tra workflow definition, model binding, fallback behavior và model availability. Bên trong runtime còn ghi role, outcome, cost, latency và diagnostic của từng leg.

Developer có nhìn thấy model nào đang làm gì trong HydraFusion không?

Hiện tại, mức quan sát của người dùng vẫn khá hạn chế. HydraFusion hiển thị các stage của workflow nhưng không stream intermediate draft. GitHub giải thích rằng những bản nháp đó có thể bị review, sửa hoặc loại bỏ, nên hiển thị sớm dễ khiến người dùng hiểu nhầm nội dung chưa hoàn tất là kết quả cuối.

GitHub Community cũng xác nhận không có fixed roster công khai. Người dùng chọn HydraFusion chứ không tự chọn model A để draft, model B để critique cho từng request. Đây là cách GitHub giảm complexity ở bề mặt sản phẩm, nhưng đổi lại developer chưa có một route trace đầy đủ để biết vì sao hệ thống đã chuyển model hoặc workflow.

GitHub thừa nhận “chờ mà không đủ visibility” là một trade-off và đang thử nghiệm cách hiển thị progress tốt hơn. Với doanh nghiệp cần audit chi tiết, đây sẽ là điểm cần theo dõi nếu HydraFusion tiến từ research preview sang sản phẩm ổn định.

Cách thử HydraFusion trong GitHub Copilot CLI

GitHub hướng dẫn ba bước: chạy /update để lấy bản Copilot CLI mới nhất, chạy /experimental on, sau đó dùng /model và chọn HydraFusion (Research Preview).

GitHub khuyến nghị preview hiện tại phù hợp nhất với first-turn, single-prompt coding task, đặc biệt là tác vụ đủ lớn nhưng phạm vi rõ, có thể giao cho Copilot trong một prompt. Multi-turn dài và session lặp nhiều vòng vẫn là hướng công ty nói sẽ tập trung cải thiện tiếp.

Do đây là research preview, developer nên so sánh cùng một loại task với model họ đang dùng, theo dõi token usage, latency, độ đúng của patch và kết quả test thay vì chỉ nhìn benchmark công bố.

HydraFusion cho thấy AI coding đang chuyển từ “chọn model” sang “chọn đường thực thi”

Ý nghĩa lớn hơn của HydraFusion nằm ở kiến trúc sản phẩm. Trong vài năm đầu của generative AI, trải nghiệm thường xoay quanh việc chọn model tốt nhất. Với HydraFusion, GitHub thử đưa “intelligence” lên một lớp khác: runtime quyết định model nào làm gì, theo thứ tự nào và khi nào cần thêm inference.

Cách tiếp cận này gần với cách developer đã làm thủ công: dùng model nhanh để phác thảo, dùng model mạnh hơn khi task khó, hoặc nhờ một model khác review. HydraFusion biến chuỗi thao tác đó thành policy tự động trong Copilot.

Nếu bạn đang theo dõi cuộc đua AI coding, có thể đặt HydraFusion cạnh các model được tối ưu cho agent dài hạn như Gemini 3.8 Flash, Claude Fable 5.1 hay Qwen3.8-Max-0902. Các bài đó nói về năng lực của từng model; HydraFusion lại đặt câu hỏi khác: làm sao kết hợp nhiều model để hoàn thành một task với trade-off tốt hơn.

Những điều chưa nên kết luận từ lần ra mắt này

Thứ nhất, HydraFusion chưa chứng minh rằng multi-model orchestration luôn rẻ hơn. Cost saving trong blog là kết quả ước tính của workflow trên benchmark cụ thể. Workload thực có tỷ lệ escalation, retry, context size và latency khác.

Thứ hai, kết quả hiện tại không chứng minh HydraFusion luôn có quality cao hơn frontier model. DeepSWE và CheckpointBench đều thấp hơn Opus 5 một chút về verified task quality, dù giảm cost đáng kể.

Thứ ba, HydraFusion chưa phải một model ổn định để benchmark theo kiểu truyền thống. Model pool, route policy và workflow có thể thay đổi khi GitHub bổ sung model mới hoặc điều chỉnh eval. Một kết quả hôm nay không nhất thiết mô tả đúng cấu hình vài tháng sau.

Điểm đáng theo dõi nhất vì thế không phải câu hỏi HydraFusion “mạnh hơn model nào”, mà là liệu GitHub có biến orchestration thành một lớp đủ đáng tin để developer không cần tự quản lý việc chọn model, review chéo và escalation hay không.