Cognition ra mắt SWE-2 vào ngày 10/9, model coding mới nhất cho Devin, và con số nổi bật có hình dạng quen thuộc: ngang bằng model lớn hơn trên benchmark chính, chi phí chỉ bằng một phần nhỏ. Điều thực sự thú vị không phải vị trí trên bảng xếp hạng — mà là phương pháp huấn luyện đằng sau đường cong chi phí đó, vì nó thay đổi cách tôi sẽ nghĩ về việc chọn mức effort cho một tác vụ cụ thể, thay vì chỉ chọn model.

Con số quan trọng không phải điểm số hàng đầu

SWE-2 được post-train từ Kimi K3, một model nền 2.8 nghìn tỷ tham số, thông qua reinforcement learning. Trên FrontierCode 1.1 Main — benchmark coding chính của Cognition — SWE-2 đạt 50.0%, gần như ngang với 50.9% của Fable 5.1 và thấp hơn 53.3% của GPT-6 Astra. Riêng con số này thì không có gì nổi bật, ở giữa bảng xếp hạng.

Con số thực sự quan trọng nằm ngay bên cạnh: SWE-2 đạt điểm đó với chi phí thấp hơn khoảng 64% so với Fable 5.1. Còn so với chính model tiền nhiệm SWE-1.7, mức effort trung bình (medium) cần ít hơn 58% số lượt thao tác và chi phí thấp hơn 81%, với số bước trung bình mỗi lần chạy giảm từ 127 xuống 53. Trên Terminal-Bench 2.1, nó thực sự dẫn đầu bảng với 92.8%, vượt cả Fable 5.1 (91.4%) và GPT-6 Astra (89.9%) — nhưng lại tụt khá xa so với cả hai trên Terminal-Bench 4 khó hơn (27.3% so với 55.8% và 57.9%), điều này cho thấy mức tăng hiệu quả không miễn phí ở mọi nơi; nó tập trung vào những tác vụ model được huấn luyện riêng để giải quyết hiệu quả, không phải những bài toán dài hơi khó nhất.

Sự bất đối xứng đó mới là câu chuyện thực sự. Đây không phải kiểu “model nhỏ hơn, kém hơn một chút, rẻ hơn” — mà là “chất lượng tương đương trên các tác vụ nó được tinh chỉnh cho, rẻ hơn nhờ huấn luyện model dừng lại đúng lúc thay vì tốn thêm lượt thao tác không cần thiết,” và yếu hơn rõ rệt trên các tác vụ nó không được tinh chỉnh cho. Đây là hai nhận định kỹ thuật khác nhau và cần được đối xử khác nhau khi bạn quyết định định tuyến công việc cho nó.

Cách họ thực sự làm: một lần RL, không phải ba model

Cơ chế này đáng để hiểu vì tôi kỳ vọng các nhà cung cấp coding model khác sẽ bắt chước theo. Thay vì huấn luyện các model riêng biệt cho “nhanh và rẻ” so với “chậm và kỹ lưỡng,” Cognition huấn luyện một lần RL duy nhất tối ưu đồng thời nhiều mức reasoning-effort có thể chọn — medium, high, max — sử dụng hàm reward phạt theo chi phí dạng R = S − λC, trong đó thành công (S) được đánh đổi với chi phí (C) bằng trọng số phạt riêng cho từng mức effort.

Cụ thể, điều này có nghĩa là bản thân model học được hành vi dừng lại khác nhau ở mỗi mức effort, thay vì một lớp sản phẩm gắn thêm giới hạn lượt thao tác lên một model vốn không biết mình đang bị cắt ngắn. Theo kinh nghiệm của tôi, sự khác biệt giữa hai cách tiếp cận này thể hiện đúng như bạn mong đợi: một model bị giới hạn lượt thao tác nhân tạo có xu hướng cho ra công việc bị cắt ngang, chưa kiểm chứng kỹ khi chạm giới hạn, trong khi một model được huấn luyện để biết ngân sách của mình có xu hướng ưu tiên các bước rẻ, có tín hiệu cao trước — đọc đúng file, lập kế hoạch — trước khi dùng lượt thao tác cho việc thực thi. Chính số liệu của Cognition gián tiếp xác nhận điều này: số bước trung vị đến lần sửa đầu tiên giảm từ 48 xuống 18, điều này cho thấy model đi đến hành động cụ thể nhanh hơn, chứ không chỉ đơn giản là làm ít việc hơn.

Ý nghĩa nếu bạn đang định tuyến công việc giữa các model

Nếu bạn đang chạy một pipeline coding agent định tuyến tác vụ theo độ phức tạp — và tính đến tháng 9/2026 hầu hết các thiết lập tooling nội bộ nghiêm túc mà tôi thấy đều làm điều này dưới một hình thức nào đó — mức effort medium của SWE-2 là một điểm chi phí thực sự khác biệt cho nhóm “được đặc tả rõ ràng, phạm vi giới hạn”: sửa lỗi có repro rõ ràng, refactor nhỏ, viết test theo pattern có sẵn. Đó là nhóm mà các tác vụ kiểu FrontierCode thuộc về, và con số rẻ hơn 64% là có thật ở đó.

Với nhóm “lớn, mơ hồ, nhiều file, cần phán đoán thực sự” — lãnh địa của Terminal-Bench 4 — dữ liệu cho thấy đừng lấy hiệu quả chi phí của SWE-2 làm tiêu chí lựa chọn chính. Hãy định tuyến những tác vụ đó tới model nào thắng trên benchmark khó hơn phù hợp với workload của bạn, và coi chi phí ở đó là thứ yếu. Một model tối ưu chi phí ở mức effort trung bình tiết kiệm lượt thao tác trên một tác vụ mà nó yếu về cấu trúc không giúp bạn tiết kiệm tiền; nó chỉ thất bại rẻ hơn và nhanh hơn, và bạn trả cái giá thực sự bằng thời gian review và làm lại.

Một lưu ý về khóa nhà cung cấp (vendor-lock) đáng nói với bất kỳ ai đang đánh giá công cụ này cho team: không có open weights và không có API độc lập — SWE-2 chỉ chạy bên trong Devin (Desktop và CLI khi ra mắt, Web và Fusion đang triển khai dần). Nếu tiêu chí đánh giá của bạn bao gồm “chúng ta có thể tự host cái này không” hay “chúng ta có thể gọi cái này từ lớp điều phối của riêng mình không,” nó không đạt tiêu chuẩn đó bất kể con số benchmark ra sao, và đây là quyết định cần làm rõ trước khi team của bạn bị cuốn theo đường cong chi phí.

Bài học thực tế

Mô hình đáng theo dõi, vượt ra ngoài bản phát hành cụ thể này: “một lần huấn luyện, nhiều mức effort với đánh đổi chi phí-hiệu năng khác nhau được tích hợp sẵn” là cách hiệu quả về vốn hơn để một nhà cung cấp phủ cả phân khúc thấp lẫn cao của sản phẩm, so với việc phát hành và duy trì các dòng model riêng biệt. Nếu bạn đang đánh giá coding agent cho một team, câu hỏi cần đặt ra với nhà cung cấp bây giờ không chỉ là “điểm benchmark tốt nhất của bạn là bao nhiêu” — mà là “cho tôi xem đường cong chi phí-hiệu năng qua các mức effort của bạn, và benchmark nào của bạn kiểm tra phần đỉnh của đường cong đó so với phần đáy.” Chính số liệu của SWE-2 là minh chứng rõ ràng nhất cho đến nay về lý do câu hỏi thứ hai đó quan trọng: model thắng về chi phí và model thắng về tác vụ khó, ngay lúc này, không phải là cùng một mức của cùng một model.