Drex Max nhắm đến Mô hình Quyết định — và định giá mỗi lượt nhấp là $0.06

Một tác nhân sử dụng máy tính thực ra không phải chỉ là một quyết định. Đặt một chuyến bay là ba mươi quyết định: nhấp vào trường nào, mở kết quả nào, tiện ích lịch đã kết xuất xong chưa, và giá vé nó đang xem có phải giá nó muốn không. Mỗi quyết định như vậy là một lượt khứ hồi ảnh chụp màn hình, và nếu mô hình ở đầu bên kia là một mô hình trò chuyện tiên tiến, mỗi lượt tốn vài giây và một hóa đơn của mô hình tiên tiến. Drex Max, mà Nace.AI đã phát hành dưới dạng khả dụng chung vào ngày 19 tháng 10 năm 2026, là một nỗ lực nhằm thu gọn phép tính đó. Đây là một mô hình ra quyết định chứ không phải mô hình trò chuyện — bạn đưa cho nó một màn hình và một tập hợp các tùy chọn có kiểu, và một lượt truyền xuôi trả về xác suất cho từng tùy chọn. Nace niêm yết nó ở mức 0,06 USD cho mỗi triệu token đầu vào, độ trễ trung vị 183 ms, và không tính phí đầu ra nào cả, vì nó không ghi ra gì. Các thất bại AI và sự cố tác nhân được ghi nhận đằng sau những bản phát hành như bản này được tập hợp trong OrcaRouter AI Incident Archive trong đó mỗi mục đi kèm nguồn riêng, mức độ nghiêm trọng, cấp độ tin cậy và cờ tranh chấp.

Phép so sánh mà Nace đặt bên cạnh đó là TypeSafe J​ev 1.14, mô hình quyết định đã định hình nên dạng yêu cầu của hạng mục này, cùng các mô hình tiên phong đa dụng mà các agent sử dụng ngày nay. Trên bảng do chính Nace công bố, con số đó là 10,17 USD cho mỗi nghìn quyết định đối với Claude Opus 5.5 và khoảng 3,5 giây cho mỗi quyết định, so với 0,06 USD và 174 ms cho Drex Max trên cùng 243 câu hỏi ảnh chụp màn hình. Số liệu của nhà cung cấp, tự chạy, chưa được bất kỳ ai ngoài Nace kiểm toán — nhưng bậc độ lớn mới là điểm mấu chốt, và đó là lý do bản phát hành này quan trọng hơn cả dòng benchmark của nó.

Những gì thực sự đã được phát hành

Drex Max là mô hình đầu tiên trong dòng Drex có bộ mã hóa thị giác. Drex 2.0 và Drex 1.5 nhận văn bản đầu vào và xuất xác suất; Max đọc ảnh chụp màn hình, bản ghi màn hình, tài liệu quét, biểu đồ, ảnh và khung hình video, đồng thời trả lời cùng ba loại câu hỏi như các phiên bản tiền nhiệm.

• ID mô hình — drex-max, đã ghim. Không có trọng số mở; được lưu trữ qua API riêng của Nace, không có checkpoint nào có thể tải xuống.

• Dạng đầu vào — state là một chuỗi cùng với một đối tượng questions và một mảng images gồm tối đa 8 hình ảnh mỗi yêu cầu. Endpoint là POST /v1/systemone, cùng đường dẫn mà J​ev sử dụng.

• Các loại câu hỏi — choice (các tùy chọn có tên, trả về xác suất cho mỗi tùy chọn), noul (câu hỏi có/không, trả về P(true)), score (các mức có thứ tự, trả về một mức kỳ vọng và một phân phối). Nhiều câu hỏi về cùng một trạng thái dùng chung một lượt xử lý.

• Ngữ cảnh — 131.072 token mỗi câu hỏi, bao gồm cả token hình ảnh, theo hướng dẫn API. Bài đăng ra mắt lại nói riêng rằng "cửa sổ ngữ cảnh 262K token." Hai con số đó không khớp nhau, và đây là điều đầu tiên cần giải quyết trước khi bạn định kích thước bộ đệm ảnh chụp màn hình.

• Giá — $0.06 mỗi triệu token đầu vào; đầu ra không bị tính phí. Nace trích dẫn cùng con số là $0.06 mỗi nghìn quyết định, điều này ngụ ý khoảng một nghìn token mỗi lần gọi.

• Các phiên bản tiền nhiệm — Drex 2.0 (tổng 35B, khoảng 3B hoạt động, xây dựng trên Qwen3.6-35B-A3B, trọng số mở) với giá 0,06 USD cho mỗi nghìn quyết định, và Drex 1.5 (9B, chỉ xử lý văn bản) với giá 0,04 USD.

• Triển khai — được quản lý trên GPU của Nace, dạng chuyên dụng, trong tài khoản AWS hoặc Azure của khách hàng, hoặc air-gapped, tất cả với cùng một hợp đồng yêu cầu. Không có trọng số nghĩa là không thể tự vận hành, nhưng không có nghĩa là chỉ SaaS.

Không có gì lạ thường trong giao diện. Đó là chủ ý: Nace đã xây dựng Drex Max để tương thích wire với J​ev SDK của TypeSafe, nên @typesafe-ai/sdk vẫn hoạt động khi thay đổi base URL, key và model mặc định. Việc tương thích không phải là sự ưu ái dành cho một đối thủ. Đó là cách một đơn vị mới tham gia được dùng thử — quá trình di chuyển rẻ nhất là quá trình chỉ cần đổi một giá trị cấu hình.

Phần thực sự khác biệt: một phân phối thay vì một câu.

Một mô hình trò chuyện trả lời câu hỏi về sử dụng máy tính bằng cách viết ra đường đi đến câu trả lời. “Nhìn vào trang, có vẻ như kết quả tìm kiếm đã tải xong, nên hành động tiếp theo là nhấp vào kết quả thứ hai” — và sau đó harness của bạn phân tích câu đó, hoặc một khối JSON, rồi hy vọng mô hình không chọn một tùy chọn mà bạn chưa từng đưa ra. Cái giá của thiết kế đó phải trả hai lần: một lần bằng token đầu ra, và một lần bằng trình phân tích cú pháp mà bạn phải duy trì vì mô hình có thể ảo giác ra một nút không có trên màn hình.

Drex Max không thể làm điều đó. Nó chỉ trả về một xác suất trên các tùy chọn bạn đã cung cấp và không gì khác. Nếu bạn đưa ra năm ứng viên có thể nhấp, bạn sẽ nhận được năm con số có tổng bằng một. Đó là một năng lực hẹp hơn và phù hợp hơn nhiều với một vòng lặp, vì ba lý do quan trọng hơn trong môi trường sản xuất so với trong một bản demo.

Đầu tiên là đặt ngưỡng. Một phân phối xác suất cho phép bạn viết ra quy tắc mà bạn thực sự muốn: hành động khi lựa chọn hàng đầu vượt ngưỡng 0,9; chuyển sang một mô hình chậm hơn hoặc con người khi nó không đạt. Một mô hình sinh cho bạn một câu và một trường độ tin cậy mang ý nghĩa hoàn toàn khác — thường là phân phối token tập trung nhọn đến mức nào, chứ không phải khả năng câu trả lời đúng đến đâu.

Điều thứ hai là hành vi khi thất bại. Một agent chỉ có thể trả lời bằng các tùy chọn đã khai báo thì không thể tự phát minh ra nút thứ sáu. Nó có thể sai và có thể bị hiệu chỉnh kém, nhưng không thể tạo ra một hành động mà harness của bạn không biết cách thực thi.

Điều thứ ba là khía cạnh kinh tế. Vì không có token đầu ra, chi phí chấm điểm mười lựa chọn bằng với chi phí chấm điểm hai lựa chọn. Cách Nace diễn giải là điều này khiến nó đủ rẻ để gọi ở mọi bước, và với $0.06 mỗi nghìn lần gọi thì phép tính vẫn đúng: ngay cả một tác vụ cẩu thả gồm ba mươi bước cũng chỉ tốn dưới hai phần mười xu cho các quyết định. Cùng tác vụ đó so với Opus 5.5, theo con số mỗi quyết định của Nace, sẽ vào khoảng ba mươi xu — không đến mức chí mạng, nhưng gấp ba mươi lần giá của thứ nó đang làm.

Bảng benchmark, và những con số này là của ai

Mọi số liệu dưới đây đều đến từ bài đăng ra mắt của Nace. Decision Index 0.3.2 là một bảng xếp hạng công khai gồm các benchmark kiểu ra quyết định, nhưng lượt chạy Drex Max trên đó là của chính Nace, dùng bộ công cụ chính thức, và chưa có ai ngoài Nace tái lập được nó. Điểm "Full" của bảng cũng pha trộn các bài kiểm tra riêng tư không thuộc lượt chạy này. Hãy coi hình dạng của các kết quả là mang tính thông tin và các chữ số thập phân là chiêu tiếp thị.

Con số tiêu đề là Chỉ số Quyết định công khai ở mức 67,6, so với 61,3 của Drex 2.0, 58,1 của Drex 1.5, 60,7 của J​ev 1.14 và 47,8 của GPT-6 Luna Decisions. Ở Chỉ số Tầm nhìn đi kèm — con số quan trọng đối với một mô hình mà điểm bán hàng là khả năng nhìn — Drex Max đạt 74,5 so với 63,9 của Luna.

• Mind2Web — 88,6 so với 81,2 của GPT-6 Luna Decisions, hàng liên quan trực tiếp nhất đối với các tác nhân trình duyệt.

• OSWorld-Verified — 0,780 so với 0,756 của GPT-6 Sol và 0,790 của Claude Opus 5.5. Drex Max đánh bại mô hình đầu tiên và thua sát nút mô hình thứ hai.

• OSWorld-V2 — 0.737 so với 0.744 của Sol và 0.761 của Opus 5.5. Câu chuyện tương tự, khoảng cách hơi rộng hơn.

• BFCL tool calling — 98,2, vượt qua 96,4 của J​ev 1.14 và 97,3 của Claude Opus 5.5, chỉ đứng sau GPT-6 Sol.

• DecideBench — 98.5 về hạng mục và 97.0 về cặp, cả hai đều dẫn trước J​ev 1.14.

• Quyết định kinh doanh so với J​ev 1.14 — FinEntity 92.3 so với 81.9, BANKING77 90.0 so với 79.7, ContractNLI 75.9 so với 57.7.

Các dòng OSWorld cần một lưu ý mà bảng của Nace không nói rõ. Những điểm số đó mô tả một ngăn xếp tự động hóa đầy đủ, và không có tài liệu nào cho biết bao nhiêu phần trong vòng lặp quanh Drex Max cũng là harness của chính Nace. Một mô hình ra quyết định chọn hành động tiếp theo tốt vẫn phụ thuộc vào thứ đang chụp ảnh màn hình, chờ render, và quyết định khi nào tác vụ hoàn tất. Hãy đọc 0.780 như bằng chứng rằng các quyết định không phải là nút thắt cổ chai, chứ không phải như một lời hứa về agent của bạn.

Ở những điểm nó thua kém, nửa nào của bảng là nửa hữu ích hơn.

Những tổn thất không hề bị che giấu, nhưng rất dễ bị lướt qua, và hai trong số đó mô tả những giới hạn thực sự chứ không phải nhiễu do làm tròn.

Về kiến thức tổng quát và suy luận khó, các mô hình quyết định đơn giản là không cạnh tranh được với các mô hình trò chuyện tiên phong, và Drex Max không thay đổi điều đó. MMLU-Pro là 72,5, thấp hơn 82,1 của J​ev 1.14, 93,0 của Sol và 94,0 của Opus 5.5. HLE là 19,0 so với 19,4 của J​ev — dù sao cũng là hòa ở đáy khoảng. Đây là điều được kỳ vọng đối với một mô hình có nhiệm vụ chọn từ một danh sách ngắn khi có một màn hình, và đó là lý do một mô hình quyết định là một thành phần trong một agent, chứ không phải là sự thay thế cho mô hình lập kế hoạch.

Điều thú vị hơn là sự suy giảm so với chính phiên bản tiền nhiệm của nó. Trên When2Call, bài đánh giá đặt câu hỏi liệu một lệnh gọi công cụ có thực sự cần thiết hay không, Drex Max đạt 85.2 trong khi Drex 2.0 đạt 86.5 và Drex 1.5 cũ hơn, rẻ hơn đạt 89.7. Mô hình Drex mới nhất và đắt nhất là mô hình tệ nhất trong ba mô hình ở khả năng biết khi nào không nên hành động. Nếu quy trình làm việc của bạn phụ thuộc vào sự kiềm chế — một tác nhân hỗ trợ nên im lặng thay vì gọi công cụ hoàn tiền — thì năng lực thị giác không mang lại điều đó, và một mô hình văn bản rẻ hơn có thể vẫn là lựa chọn đúng.

Mô thức tương tự cũng xuất hiện ở hai hàng thị giác đi theo hướng ngược lại. KIE, tức trích xuất thông tin chính trên biểu mẫu quét, đạt 95,5 so với 97,5 của Luna. Kiểm duyệt Hateful Memes đạt 70,6 so với 71,2. Cả hai khoảng cách đều không lớn, và cả hai đều nằm trong những lĩnh vực mà lợi thế của Drex Max ở nơi khác rộng tới ba mươi điểm, điều này cho thấy bộ mã hóa thị giác được huấn luyện thiên về bố cục màn hình và biểu đồ hơn là biểu mẫu in hoặc meme.

Độ trễ cũng đi lùi. Mức trung vị 183 ms của Drex Max chậm hơn 32 ms so với Drex 2.0 và chậm hơn 38 ms so với Drex 1.5. Trong một vòng lặp chạy ba mươi lần mỗi tác vụ, điều đó cộng thêm khoảng một giây mỗi tác vụ, trong khi mỗi bước tiết kiệm được vài giây so với một mô hình tiên phong. Vẫn là một đánh đổi hợp lý, nhưng cần lưu ý rằng bộ mã hóa thị giác không hề miễn phí.

Có một con số cần được tách bạch trước khi nó bị đem ra trích dẫn với bạn. Con số 174 ms trong đoạn mở đầu là phép đo chỉ riêng ảnh chụp màn hình của Nace — 243 câu hỏi hình ảnh, mỗi lần một yêu cầu, so với 253 ms của J​ev 1.14 trên cùng bộ câu hỏi. Con số 183 ms là trung vị trên toàn bộ bộ benchmark trong bảng ra mắt. Cả hai đều là của Nace; chúng là những phép đo khác nhau, và con số trông có lợi hơn lại là con số có phạm vi hẹp hơn.

Hai cái bẫy trong API trước khi bạn kết nối bất cứ thứ gì

Tài liệu có một chi tiết sẽ khiến ai đó mất cả buổi chiều nếu chỉ đọc lướt qua. drex-latest không trỏ đến Drex Max. Đây là một checkpoint được ghim, và alias lại phân giải sang một thứ khác. Bất kỳ ai làm theo quickstart, thay bằng khóa của mình và đặt TYPESAFE_DEFAULT_MODEL=drex-latest — đúng như hướng dẫn tương thích J​ev bảo họ làm — sẽ đang gọi một mô hình chỉ văn bản và tự hỏi vì sao ảnh chụp màn hình của họ bị bỏ qua.

Cái bẫy thứ hai là kích thước. Hướng dẫn API giới hạn yêu cầu ở tám hình ảnh và 131.072 token cho mỗi câu hỏi, bao gồm cả token hình ảnh; bài đăng ra mắt lại quảng cáo 262K. Cho đến khi Nace dung hòa được hai con số này, hãy tính theo con số nhỏ hơn. Không có chi phí token trên mỗi hình ảnh nào được công bố, khiến việc tính toán trước về giới hạn này trở nên khó khăn: một ảnh chụp màn hình độ phân giải đầy đủ không tương ứng với một số token cố định, và tài liệu không nói cách hình ảnh được thay đổi kích thước hoặc chia thành ô.

Một điểm dễ hơn so với giải pháp hiện tại: Drex Max chấp nhận ảnh chụp màn hình ở mọi kích thước. API của J​ev 1.14 từ chối các hình ảnh có một cạnh dưới 280 px hoặc trên 1.568 px, đây là kiểu ràng buộc thường lộ ra dưới dạng lỗi âm thầm trong vòng lặp thử lại lúc 2 giờ sáng.

Điều này ảnh hưởng thế nào đến một quyết định định tuyến

Câu hỏi thực tế không phải là liệu Drex Max có tốt hơn một mô hình tiên phong hay không. Nó không tốt hơn, và nó cũng không cố gắng trở thành như vậy. Câu hỏi là trong ba mươi quyết định của một nhiệm vụ, quyết định nào đáng để dùng một mô hình tiên phong và quyết định nào đáng để dùng một phân phối xác suất 174 ms, và đó là một bài toán định tuyến trước khi là một bài toán mô hình.

Drex Max không có trong danh sách route của chúng tôi. Danh mục OrcaRouter không có nó, và không có gì ở đây nên được hiểu là tuyên bố về tính sẵn có từ phía chúng tôi — Nace bán nó qua API riêng và bảng điều khiển riêng của họ. Thứ chúng tôi có là mô hình hiện hành mà nó được đem ra so sánh. TypeSafe Jev 1.13 là một route được niêm yết với giá $0.042 mỗi triệu token đầu vào trên ngữ cảnh 65,536 token, được phục vụ qua cùng POST /v1/systemone thân yêu cầu, nên một phép A/B giữa mô hình ra quyết định và vòng lặp từ ảnh chụp màn hình đến frontier hiện tại của bạn chỉ là thay chuỗi mô hình chứ không phải viết lại. Cách rẻ để giải quyết chuyện này là giữ các lệnh gọi quyết định chỉ văn bản ở nguyên chỗ cũ, thêm một bước đọc màn hình bên cạnh chúng cho những tác vụ cần nhìn, và đối chiếu cả hai với log của chính bạn thay vì 140,178 yêu cầu đã được chấm điểm của Nace.

Kiểu tách đó chỉ hoạt động nếu các phần có thể được truy cập từ một nơi. Một khóa duy nhất xuyên suốt hơn 200 mô hình, giá niêm yết của nhà cung cấp được chuyển qua mà không cộng thêm phí theo token, và tự động chuyển đổi dự phòng giữa các nhà cung cấp chính là thứ ngăn thử nghiệm thoái hóa thành một nhánh cũ một khi người thiết lập nó chuyển sang nhóm khác. Điều này cũng quan trọng ở đây vì một lý do cụ thể: Drex Max là mới, chưa được kiểm toán và chỉ có API, và cách an toàn để áp dụng một thành phần chưa được chứng minh là đặt nó phía sau một thứ có thể dự phòng về một mô hình đã biết khi độ tin cậy của nó giảm hoặc endpoint hoạt động sai. Hãy định tuyến các quyết định có độ tin cậy cao đến mô hình rẻ và để cơ chế dự phòng xử lý phần còn lại.

Điều gì sẽ thay đổi cách đọc này?

Một lần chạy độc lập Decision Index là điều đầu tiên. Bộ đánh giá này là công khai, Nace nói rằng các đánh giá có thể tái lập, và cho đến khi ai đó bên ngoài công ty chạy Drex Max trên đó, con số 67.6 vẫn chỉ là con số của nhà cung cấp. Những ô cần theo dõi khi điều đó xảy ra là những ô chỉ về các hướng ngược nhau: mức dẫn trước 30 điểm trên Mind2Web nằm cạnh một sự suy giảm trên When2Call không phải là một đường cong năng lực mượt mà, nó mô tả một mô hình được huấn luyện kỹ trên câu hỏi "cái nào trong số này là lần nhấp tiếp theo" và ít kỹ hơn trên câu hỏi "tôi có nên nhấp vào bất cứ thứ gì không." Nếu điều đó đứng vững, thì đó là sự thật quan trọng nhất về mặt vận hành về Drex Max và nó không nằm trong phần nổi bật.

Độ trễ production dưới tải đồng thời là điểm thứ hai. Con số thông lượng của chính Nace — khoảng 25 yêu cầu mỗi giây trên một bản sao H100, không lỗi khi có tới 64 yêu cầu đang xử lý — là cho Drex nói chung, không riêng Max. Toàn bộ luận điểm chính của thiết kế là nó nằm trên hot path ở mọi bước, khiến p95 dưới tải trở nên liên quan hơn nhiều so với trung vị 183 ms, và không có gì được công bố đề cập đến điều đó.

Thứ ba, bảng giá cần một ví dụ tính toán cụ thể có kèm hình ảnh. $0.06 mỗi triệu token đầu vào chỉ hữu ích nếu bạn biết một ảnh chụp màn hình tốn bao nhiêu token, và không có con số công bố nào làm được điều đó. Một nhóm lập ngân sách cho vòng lặp 30 bước với màn hình 1440p mỗi bước thì chỉ đang đoán cho đến khi Nace công bố cách tính token cho hình ảnh hoặc có ai đó đo được nó.

Không điều nào trong số đó làm bản phát hành bớt thú vị hơn. Một mô hình ra quyết định biết nhìn là một thành phần thực sự khác biệt so với một mô hình trò chuyện bị yêu cầu nhìn vào ảnh chụp màn hình, và khoảng cách giá đủ lớn để thay đổi những gì một agent có thể đủ khả năng làm ở mỗi bước. Chỉ là nó vẫn chưa phải một con số mà bất kỳ ai ngoài Nace đã kiểm chứng — và phần của bảng trụ lại được khi tiếp xúc với một triển khai thực tế có lẽ sẽ là phần không ai đang trích dẫn.