Evidence at a glance

67.59, Jev 1.14 60.7Decision Index
92.2, Jev 1.14 86.7JevBench
BFCL use 98.2; OSWorld-Verified 0.780Evidence
74.5, GPT-6 Luna Decisions 63.9Evidence
MMLU-Pro 72.5, Jev 1.14 82.1Evidence
HLE 19.0, Jev 1.14 19.4Evidence

Separating Screen Decisions from Text Generation

On October 19, 2026, Nace AI released Drex Max, a multimodal decision model aimed at agents that operate browsers and computers. It accepts contextual text and images, then answers questions defined in advance by the caller. The intended use is to help an agent choose its next action, such as which button to select on screen.

The launch matters to technical leads not simply because another model can read images, but because it separates screen interpretation from prose generation. Many agent workflows do not need a natural-language explanation. They need a choice that maps directly to a click. Drex Max aims to make that step a single API call with constrained answers and probabilities.

The Interface Constraint Is the Design Claim

The caller submits a state and questions in one of three forms: a yes-or-no judgment (noul), a choice among supplied labels, or a score on an ordered scale. The model returns a probability distribution over those answers and does not generate free-form text. For an agent, this removes the step of parsing prose back into an action and makes the action space explicit before the call.

The cost is that the caller must design the candidate answers. If the interface presents a situation that the options do not cover, the model has no suitable answer to express. A request can contain up to 16 questions, all of which share the same images. Images are passed in an array and can be referenced in text as “Image 1” and similar labels. This suits screen decisions with known task boundaries, but it does not mean the model can independently plan arbitrary operations.

The Scores Show Both Specialization and Limits

Nace reports a score of 67.59 for Drex Max on Decision Index 0.3.2, compared with 60.70 for Jev 1.14. On JevBench, Drex Max scores 92.2 against 86.7. Results on screen- and tool-related tasks are also strong: 74.5 on Decision Index Vision, 98.2 on BFCL tool calling, and 0.780 on OSWorld-Verified. Together, these figures suggest a specific strength in decision and operation tasks, not universal leadership.

Scores on broader knowledge tasks show the other side. Drex Max scores 72.5 on MMLU-Pro, below Jev 1.14’s 82.1, and 19.0 on HLE, compared with 19.4. Nace says Decision Index covers 37 public benchmarks and 140,178 scoring requests, and that unanswered questions count as incorrect. These are still vendor-reported results, with no independent reproduction mentioned in the available material. For model selection, the leaderboard can tell you what may be worth testing, but it cannot establish reliability on your own interfaces and task distribution.

Cost and Latency Depend on How You Call It

Drex Max’s API documentation lists a price of $0.06 per million input tokens, with no charge for output tokens. That may suit frequent decisions, but image costs cannot be estimated by screenshot count alone: each image can account for up to 1,602 tokens per question. If one screenshot is used to ask several detailed questions, image-related input grows with the number of questions rather than being charged only once. The documentation allows up to eight still PNG, JPEG, or WebP images per request, each no larger than 16 MiB, with a 32 MiB total request limit.

The latency figures should not be treated as interchangeable. Nace lists a 174-millisecond median for screenshot decisions and a 183-millisecond median API latency. Launch information separately cites 34 milliseconds per decision, but the public material does not align the test conditions behind these numbers. Before integration, measure end-to-end latency on the target device, with representative screenshot sizes and question counts, and calculate token costs when multiple questions reuse an image. The API is hosted by Nace, while parameter count remains undisclosed and no open weights or quantized builds have been announced. Those constraints make service dependence part of the deployment decision.

Validate It as One Component in the Agent Loop

A prudent trial would start with tasks that have a clear set of actions. Enumerate the clickable targets, then test whether the probability output can feed directly into action selection or a confidence gate. This shows whether the model reduces text parsing or failure rates for specific screen decisions, rather than assuming that image input alone solves computer use. If unexpected interface states are common, the closed option set may become the main failure point, so the agent needs another way to detect when none of the choices fits.

Treat “calibrated probabilities” as a property to verify, not a guarantee. Nace uses that description, but the public material provides no calibration error, calibration curve, or independent validation. Given the hosted API, undisclosed model details, and latency figures with different stated contexts, the sensible choice is not to replace a general model immediately. Instead, place Drex Max in a reversible part of the workflow and measure accuracy, fallback behavior, latency, and total cost on your own tasks. Whether its specialization pays off depends on those end-to-end results.