Drex Max Puts Eyes on the Decision Model — and Prices Every Click at $0.06

A computer-use agent is not really one decision. Booking a flight is thirty of them: which field to click, which result to open, whether the calendar widget has finished rendering, whether the fare it is looking at is the one it wants. Each of those is a screenshot round trip, and if the model on the other end is a frontier chat model, each one costs seconds and a frontier-model bill. Drex Max, which Nace.AI shipped as generally available on October 19, 2026, is an attempt to collapse that arithmetic. It is a decision model rather than a chat model — you hand it a screen and a set of typed options, and one forward pass returns a probability for each option. Nace lists it at $0.06 per million input tokens, a median latency of 183 ms, and no output charge at all, because it writes nothing. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

The comparison Nace puts next to that is TypeSafe J​ev 1.14, the decision model that defined the category's request shape, and the general-purpose frontier models that agents use today. On Nace's own published table, that is $10.17 per thousand decisions for Claude Opus 5.5 and roughly 3.5 seconds per decision, against $0.06 and 174 ms for Drex Max on the same 243 screenshot questions. Vendor numbers, self-run, unaudited by anyone outside Nace — but the order of magnitude is the point, and it is the reason this release matters more than its benchmark row does.

What actually shipped

Drex Max is the first model in the Drex line with a vision encoder. Drex 2.0 and Drex 1.5 were text-in, probability-out; Max reads screenshots, screencasts, scanned documents, charts, photos and video frames, and answers the same three question types as its predecessors.

• Model id — drex-max, pinned. No open weights; hosted through Nace's own API, with no downloadable checkpoint.

• Input shape — a state string plus a questions object, and an images array of up to 8 images per request. Endpoint is POST /v1/systemone, the same path J​ev uses.

• Question types — choice (named options, returns a probability per option), noul (a yes/no question, returns P(true)), score (ordered levels, returns an expected level and a distribution). Several questions about one state share a single pass.

• Context — 131,072 tokens per question including image tokens, per the API guide. The launch post separately says "262K-token context window." Those two numbers do not agree, and it is the first thing to resolve before you size a screenshot buffer.

• Price — $0.06 per million input tokens; output is not billed. Nace quotes the same figure as $0.06 per thousand decisions, which implies roughly a thousand tokens per call.

• Predecessors — Drex 2.0 (35B total, about 3B active, built on Qwen3.6-35B-A3B, open weights) at $0.06 per thousand decisions, and Drex 1.5 (9B, text only) at $0.04.

• Deployment — managed on Nace's GPUs, dedicated, inside a customer AWS or Azure account, or air-gapped, all with the same request contract. No weights means no self-hosting, but it does not mean SaaS-only.

There is nothing exotic in the interface. That is deliberate: Nace built Drex Max to be wire-compatible with TypeSafe's J​ev SDK, so @typesafe-ai/sdk keeps working with a changed base URL, key and default model. The compatibility is not a courtesy to a rival. It is how a new entrant gets tried — the cheapest migration is the one that is a config value.

The part that is genuinely different: a distribution instead of a sentence

A chat model answers a computer-use question by writing its way to an answer. "Looking at the page, the search results appear to have loaded, so the next action should be to click the second result" — and then your harness parses that sentence, or a JSON blob, and hopes the model did not pick an option you never offered. The cost of that design is paid twice: once in output tokens, and once in the parser you have to maintain because the model can hallucinate a button that is not on the screen.

Drex Max cannot do that. It returns a probability over the options you supplied and nothing else. If you offer five clickable candidates, you get five numbers that sum to one. That is a narrower capability and a much better fit for a loop, for three reasons that matter more in production than in a demo.

The first is thresholding. A probability distribution lets you write the rule you actually want: act when the top option clears 0.9, escalate to a slower model or a human when it does not. A generative model gives you a sentence and a confidence field that means something else entirely — usually how peaked the token distribution was, not how likely the answer is to be right.

The second is failure behaviour. An agent that can only answer with declared options cannot invent a sixth button. It can be wrong, and it can be badly calibrated, but it cannot produce an action your harness does not know how to execute.

The third is the economics. Because there are no output tokens, the cost of scoring ten options is the same as scoring two. Nace's framing is that this makes it cheap enough to call on every step, and at $0.06 per thousand calls the arithmetic holds: even a sloppy thirty-step task costs under two-tenths of a cent in decisions. The same task against Opus 5.5, on Nace's per-decision figure, would be about thirty cents — not fatal, but thirty times the price of the thing it is doing.

The benchmark table, and whose numbers these are

Every figure below comes from Nace's launch post. The Decision Index 0.3.2 is a public leaderboard of decision-style benchmarks, but the Drex Max run on it is Nace's own, using the official kit, and nobody outside Nace has reproduced it. The board's "Full" score also blends private tests that are not part of this run. Treat the shape of the results as informative and the decimal places as marketing.

The headline is a public Decision Index of 67.6, against 61.3 for Drex 2.0, 58.1 for Drex 1.5, 60.7 for J​ev 1.14 and 47.8 for GPT-6 Luna Decisions. On the companion Vision Index — the number that matters for a model whose selling point is seeing — Drex Max scores 74.5 against Luna's 63.9.

• Mind2Web — 88.6 vs 81.2 for GPT-6 Luna Decisions, the most directly relevant row for browser agents.

• OSWorld-Verified — 0.780 vs 0.756 for GPT-6 Sol and 0.790 for Claude Opus 5.5. Drex Max beats the first and loses narrowly to the second.

• OSWorld-V2 — 0.737 vs 0.744 for Sol and 0.761 for Opus 5.5. Same story, slightly wider gap.

• BFCL tool calling — 98.2, ahead of J​ev 1.14's 96.4 and of Claude Opus 5.5's 97.3, behind only GPT-6 Sol.

• DecideBench — 98.5 on items and 97.0 on pairs, both ahead of J​ev 1.14.

• Business decisions vs J​ev 1.14 — FinEntity 92.3 vs 81.9, BANKING77 90.0 vs 79.7, ContractNLI 75.9 vs 57.7.

The OSWorld rows deserve a caveat that Nace's table does not spell out. Those scores describe a full automation stack, and it is not documented how much of the loop around Drex Max was also Nace's own harness. A decision model that picks the next action well still depends on whatever is taking the screenshot, waiting for renders, and deciding when the task is done. Read 0.780 as evidence that the decisions are not the bottleneck, not as a promise about your agent.

Where it loses, which is the more useful half of the table

The losses are not buried, but they are easy to skim past, and two of them describe real limits rather than rounding noise.

On general knowledge and hard reasoning the decision models are simply not competitive with frontier chat models, and Drex Max does not change that. MMLU-Pro is 72.5, behind J​ev 1.14's 82.1, Sol's 93.0 and Opus 5.5's 94.0. HLE is 19.0 against J​ev's 19.4 — a tie at the bottom of the range either way. This is expected for a model whose job is to pick from a short list given a screen, and it is the reason a decision model is a component in an agent, not a replacement for the model that plans.

More interesting is the regression against its own predecessor. On When2Call, which asks whether a tool call is warranted at all, Drex Max scores 85.2 while Drex 2.0 manages 86.5 and the older, cheaper Drex 1.5 scores 89.7. The newest and most expensive Drex model is the worst of the three at knowing when not to act. If your workflow depends on restraint — a support agent that should stay silent rather than call a refund tool — the vision capability does not buy you that, and a cheaper text model may still be the right choice.

The same pattern shows in two vision rows that go the other way. KIE, key information extraction on scanned forms, is 95.5 against Luna's 97.5. Hateful Memes moderation is 70.6 against 71.2. Neither gap is large, and both sit in domains where Drex Max's advantage elsewhere is thirty points wide, which suggests the vision encoder is trained toward screen layouts and charts rather than printed forms or memes.

Latency also moved backwards. Drex Max's 183 ms median is 32 ms slower than Drex 2.0 and 38 ms slower than Drex 1.5. In a loop that runs thirty times per task, that is about a second per task added, against several seconds saved per step versus a frontier model. Still the right trade, but worth knowing that the vision encoder is not free.

One number needs separating before it gets quoted at you. The 174 ms in the opening paragraph is Nace's screenshot-only measurement — 243 image questions, one request at a time, against 253 ms for J​ev 1.14 on the same set. The 183 ms is the median across the whole benchmark suite in the launch table. Both are Nace's; they are different measurements, and the flattering one is the narrower one.

Two traps in the API before you wire anything up

The documentation contains a detail that will cost someone an afternoon if they skim it. drex-latest does not point at Drex Max. It is a pinned checkpoint, and the alias resolves to something else. Anyone who follows the quickstart, swaps in their key and sets TYPESAFE_DEFAULT_MODEL=drex-latest — which is exactly what the J​ev-compatibility instructions tell them to do — will be calling a text-only model and wondering why their screenshots are ignored.

The second trap is size. The API guide caps requests at eight images and 131,072 tokens per question including image tokens; the launch post advertises 262K. Until Nace reconciles the two, size for the smaller figure. There is no published per-image token cost, which makes the cap hard to reason about in advance: a full-resolution screenshot is not a fixed number of tokens, and the docs do not say how images are resized or tiled.

One thing that is easier than the incumbent: Drex Max accepts screenshots of any dimension. J​ev 1.14's API rejects images with a side under 280 px or over 1,568 px, which is the kind of constraint that surfaces as a silent failure in a retry loop at 2 a.m.

What this does to a routing decision

The practical question is not whether Drex Max is better than a frontier model. It is not, and it is not trying to be. The question is which of the thirty decisions in a task deserve a frontier model and which deserve a 174 ms probability distribution, and that is a routing problem before it is a model problem.

Drex Max is not on our route list. The OrcaRouter catalogue does not carry it, and nothing here should be read as an availability claim from us — Nace sells it through its own API and its own console. What we do carry is the incumbent it is measured against. TypeSafe Jev 1.13 is a listed route at $0.042 per million input tokens over a 65,536-token context, served through the same POST /v1/systemone body, so an A/B between a decision model and your current screenshot-to-frontier loop is a model string rather than a rewrite. The cheap way to settle this is to keep your text-only decision calls where they are, add a screen-reading step beside them for the tasks that need eyes, and measure both against your own logs rather than Nace's 140,178 scored requests.

That kind of split only works if the pieces are reachable from one place. One key across 200-plus models, provider list price passed through at no per-token markup, and automatic failover across providers is what stops the experiment from decaying into a stale branch once the person who set it up changes teams. It also matters here for a specific reason: Drex Max is new, unaudited and API-only, and the safe way to adopt an unproven component is to put it behind something that can fall back to a known model when its confidence drops or the endpoint misbehaves. Route the confident decisions to the cheap model and let failover handle the rest.

What would change this read

An independent run of the Decision Index is the first thing. The suite is public, Nace says the evals are reproducible, and until somebody outside the company runs Drex Max on it, the 67.6 is a supplier's number. The cells to watch when that happens are the ones pointing in opposite directions: a 30-point lead on Mind2Web next to a regression on When2Call is not a smooth capability curve, it describes a model trained hard on "which of these is the next click" and less hard on "should I click anything." If that holds up, it is the most operationally important fact about Drex Max and it is not in the highlights.

Production latency under concurrency is the second. Nace's own throughput figure — about 25 requests per second on one H100 replica, no errors up to 64 in flight — is for Drex generally, not Max specifically. The design's entire pitch is that it sits in a hot path on every step, which makes p95 at load far more relevant than a 183 ms median, and nothing published addresses it.

Third, the pricing needs a worked example with images in it. $0.06 per million input tokens is only useful if you know what a screenshot costs in tokens, and no published figure does that. A team budgeting a 30-step loop with a 1440p screen per step is guessing until Nace publishes the image accounting or someone measures it.

None of that makes the release less interesting. A decision model that sees is a genuinely different component from a chat model that is asked to look at a screenshot, and the price gap is large enough to change what an agent can afford to do on every step. It is just not yet a number anyone outside Nace has checked — and the part of the table that survives contact with a real deployment will probably be the part nobody is quoting.