Drex Max v1: A Decision Model That Runs on Your Desk

Posted on by
Contents show
Drex Max v1

Most of what an AI agent does is not generation. It is routing a ticket, checking a policy, deciding whether a request is urgent, picking which tool to call. Those calls happen thousands of times a day, each one currently paid for in tokens, and each one carrying a small probability that a generative model, asked to answer in prose, phrases its way into the wrong choice. Drex Max v1 is a decision model built to replace exactly those calls.

Nace AI has released Drex Max v1 as open weights, and its design answers a different question: what if those calls were not generation at all? Drex Max is the company's most capable decision model, it now runs on hardware you own, and this article tests that claim. Drex Max is a 27B dense decision model. You pass it a state, text, JSON or images, plus named typed questions, and it returns a probability for every option in one forward pass. Nothing is generated. No tokens, no prose, no chance of a confident paragraph around a wrong answer.

The release ships bf16 weights, a Q8_0 GGUF, an affine Q4 checkpoint, and forks of llama.cpp and Ollama to run them. A 4-bit build runs on Apple silicon Macs with 24 GB of memory, which puts a top-ranked decision model in the same hardware class as a developer laptop.

This article explains how Drex Max differs from a language model, what the benchmarks show, why the quantization results matter more than they sound, and where the obvious limits of the release sit.

What a decision model actually is

The Drex Max interface is the architecture. Where a language model maps a prompt to the most likely next token, Drex Max maps a state plus typed questions to option probabilities through a 255-way readout head. Questions come in three types: choice among named options, yes or no, and an ordinal score with a defined legend. The response is a probability distribution over the options, with a confidence, in a single forward pass.

The Drex Max backbone is a dense 27B model with 64 layers, and its attention arrangement is unusual and purposeful. Forty-eight layers are Gated DeltaNet linear attention, running left to right, which is efficient for long contexts. Sixteen are full-attention layers, placed every fourth layer, and they are non-causal: every token can attend to the whole sequence, not just what came before. For a model whose job is to judge a complete state rather than continue it, bidirectional attention is the right call, and the Drex Max model card is explicit that a plain causal chat run does not reproduce the scores.

Images pass through Drex Max's native vision tower and are visible to every question in the request, so a receipt, a screenshot or a form can be part of the state the model judges.

The category Drex Max creates is worth naming. It is not a smaller language model with a system prompt. It is a classifier with the world knowledge of a 27B foundation model, exposed through a contract that returns calibrated probabilities instead of text. For agent routing, ticket triage, moderation checks and policy gates, that contract is easier to build on and cheaper to run than parsing generated prose.

One request, end to end

The model card's example is small enough to read completely, and it shows the contract better than any description.

The state is a support ticket: a customer reports being charged twice for the same order and asks for a refund of the extra payment. Three questions are attached to that state. A choice question asks which team should handle the ticket, with billing, technical and other as named options and one-line criteria for each. A yes-or-no question asks whether a refund applies. An ordinal score question asks urgency, with a legend mapping 0 to routine, 1 to soon, and 2 to urgent.

The response returns all three in one pass. The choice lands on billing with 99.88 percent probability and 99.82 percent confidence. The refund answer is yes at 99.74 percent. Urgency returns a score of 1.65 with the probability mass spread across the legend, 1.5 percent routine, 31.7 percent soon, 66.7 percent urgent, and a self-reported confidence of only 0.4783, which is the system correctly flagging that urgency is genuinely ambiguous in this state.

That last field is the part most teams will underestimate. A generative model asked about urgency produces a sentence; whether that sentence reflects certainty is anyone's reading. Drex Max returns its own confidence, and the example was chosen to show it doing so honestly. Routing on high-confidence answers and escalating low-confidence ones is a policy you can write in a line of code, which is the entire practical advantage Drex Max offers over prose.

Why the attention layout is a statement

The mixed attention design deserves a closer look, because it encodes a theory of what judging a state requires.

Generative models use causal attention because their job is to predict what comes next; seeing the future would be cheating. Drex Max's job has no future. The state arrives complete, and the questions are about it, so sixteen full-attention layers placed every fourth layer let any position consult any other position, including ones that would sit later in a generative reading. The 48 linear-attention layers keep the long-context efficiency that a 262,144-token window demands, and the interleaving gives the model both cheap broad context and exact bidirectional reference.

The model card's warning that a plain causal chat run does not reproduce the scores is the proof that this layout is load-bearing rather than decorative. It is also a deployment constraint in disguise: the bundled loader exists to apply non-causal masking, and using an unmodified inference stack silently degrades the model into something that was never benchmarked. The forks of llama.cpp and Ollama exist precisely so that the Apple and CPU paths preserve the layout.

What the Drex Max benchmarks show

All Drex Max figures are self-reported by Nace AI, and the results dataset covers 140,620 requests, with unanswered requests counted as wrong.

On the public Decision Index 0.4, Drex Max scores 67.52, ahead of the company's own Drex v2.0 at 61.25 and a competing decision model at 57.96. The index averages 37 benchmarks across five areas. The area breakdown is more informative than the headline: Tools reaches 81.9, Language 72.2, Retrieval 68.8, Knowledge and Reasoning 57.1, Arts 53.4. A decision model being strongest at tool selection and weakest at arts is exactly the profile you would hope for.

On the independent Artificial Analysis Decision Index, Drex Max scores 64, which the company says ranks fourth of 18, one point behind the leaders and ahead of Claude Haiku 5.5 at 61 and a GPT-6 model at 55. That is the strongest external validation in the release, because a third-party index is harder to tune for than a home suite. JevBench shows 92.2 percent and Decision Bench v4 shows 94.30 percent, both self-run.

The Drex Max vision numbers are uneven in a way that reads as honest. The public vision index is 73.92 across 11 benchmarks, with standout skill on InfographicVQA at 97.3 and key information extraction at 92.4, and weak spots on moderation at 40.6 and a reasoning-heavy vision benchmark at 38.6. Nobody tuning a Drex Max press release leaves those two rows in.

The quantization result is the quiet headline

The Drex Max claim that should reshape how teams think about local inference is not the index score. It is this: the Q8_0 GGUF running on an Apple M5 Pro matched H100 bf16 weights within 0.02 per probability, and the affine Q4 build stayed within 0.0329 of Q8_0 with no choice flips across the tests.

That matters because the entire value proposition of Drex Max is the reliability of its probabilities. If quantization moved those probabilities materially, local deployment would be a degraded mode, and the honest advice would be to run the big weights on real hardware. Instead, the measured result says the 24 GB laptop build and the datacenter build make the same decisions. A team can prototype on a Mac and deploy on a GPU with the numbers behaving identically, or keep the whole routing layer on an offline machine.

The Drex Max deployment matrix is broad by open-weight standards. Python on an NVIDIA GPU handles the full model including images, with bf16 at about 49 GB or 8-bit at about 26 GB. On Apple silicon, llama.cpp, Ollama, Kapitsa and MLX run the text backbone, with the affine Q4 targeting 24 GB machines and the Q8_0 GGUF needing 48 GB. CPU inference works through the same forks. All five runtimes serve the same API contract, which is the detail that makes the ecosystem feel designed rather than accumulated.

Two caveats attach to the local paths. They are text only for now, since images need the Python weights, and the Apple paths carry a default context of 16,384 tokens, extendable to the model's 262,144-token window at the cost of memory. On a 48 GB Mac the recommended context is 2048.

Where a decision model belongs in an agent stack

The useful mental model is that decision models and generative models solve different halves of an agent's work, and Drex Max is explicitly positioned for the half that has been over-served by prose.

Generators plan, write and explain. Decision models gate. Every agent loop contains dozens of gate questions: which tool, which route, is this request allowed, is this output acceptable, does this ticket go to billing or technical. Running those gates through a generative model instead of a decision model means paying generation prices for classification work and accepting prose as the interface to deterministic logic. Running them through a decision model returns probabilities, at local inference speed, with no sampling variance between identical requests.

That positioning also clarifies what Drex Max is not. It does not write, reason through novel problems, or hold a conversation, and none of those are regressions. Its Knowledge and Reasoning skill of 57.1 is not a flaw; it is a boundary. The correct architecture pairs it with a generative model for the open-ended work and uses the decision model where the answer space is known. Teams building that pairing will find the licensing accommodates it: the weights ship under the Nace.AI Open RAIL-M license, with the hosted version priced at $0.03 per thousand decisions at launch, down from earlier versions, which sets up the familiar build-versus-buy comparison at a price point where local hosting is competitive on much smaller volumes than frontier generation.

The economics of gates versus generation

The pricing table in the release tells the story of the category better than any benchmark, and it is worth reading as a cost model for agent pipelines.

The hosted Drex Max launches at $0.03 per thousand decisions. The previous Drex v2.0 ran $0.06, Drex v1.5 $0.04, and the closed hosted competitor charges $42 per million tasks, which is $0.042 per thousand, in the same band. Frontier generative models, by comparison, price per token with reasoning tokens included, and a routing call that makes a frontier model think can cost many times a dedicated decision call. Multiply the difference across the thousands of gate calls an agent pipeline makes daily, and the routing layer becomes one of the largest line items in the budget, or one of the smallest, depending entirely on what serves it.

Open weights change the shape of that decision rather than only its price. A team running Drex Max on hardware it already owns pays nothing marginal per decision, gains offline operation, and removes the data-flow question entirely, since states never leave the machine. For gate questions carrying customer content, ticket text, screenshots, internal documents, that last property is not a discount but a requirement in many organizations.

The open question is whether open decision weights erode the hosted business that funds them. The company's answer is the version ladder, a strong hosted API for teams that do not want to host, open weights for teams that do, and a license, Open RAIL-M, that permits most uses while carrying use restrictions. That is the same structure the open-model ecosystem has converged on, and it is becoming the standard contract between model builders and agent builders.

The version ladder, read as a product strategy

The comparison table across Drex versions is more revealing than a single-model review, because it shows the company iterating toward a specific product shape.

Drex v1.5 is a 9B model with a Q8_0 file of about 9.5 GB, the version that fits a laptop comfortably. Drex v2.0 moved to a 35B mixture-of-experts with roughly 3 billion active parameters and dropped the vision tower, optimizing for cheap text-only routing at 131K context. Drex Max consolidates: dense 27B, bidirectional attention layers restored, vision back, a 262K window, and the best scores of the line. Each version trades a different resource, memory, latency, modality, and the line now spans from a 9.5 GB file to a 49 GB one.

The lesson for adopters is that the ladder exists so the gate layer can be matched to the gate's importance. Not every routing call needs the top model; a triage between three teams is a v1.5 question, while a policy gate with legal consequences is a Drex Max question. Mixing versions across the gate hierarchy, all serving the same API contract, is the deployment pattern the product roadmap implies, and it mirrors how teams already mix model sizes on the generation side.

The honest limits

Several boundaries deserve plain statement before anyone rearchitects an agent around Drex Max.

The external evidence is one strong index. The Artificial Analysis ranking is genuinely independent, but one third-party index across four benchmarks is thinner evidence than the internal suite of 37 benchmarks that drives the headline number, and home-suite results are tunable by construction. The 255-option ceiling is a real constraint for problems with larger action spaces. The vision weaknesses on moderation and reasoning-heavy images mean image-based gates need testing on your own data rather than trusting the headline vision index. The Apple paths being text-only means document-heavy routing still needs a GPU or the hosted API. And the non-causal attention requirement means the bundled loader is mandatory; this model will not run correctly in an unmodified inference stack, which the forks exist to solve but which limits drop-in portability to the environments Nace supports.

The RAIL-M license deserves a specific reading before adoption, because use restrictions in model licenses are newer and less settled than the Apache and MIT licenses most of the open ecosystem ships under. Teams with unusual deployment profiles, embedded products, regulated industries, resale scenarios, should read the terms against their use case rather than assuming open means unrestricted.

None of these undermine the release. They define its envelope: a decision model for gate-shaped questions, strongest on tools and language, with local deployment that preserves its probabilities, awaiting the broader independent evaluation that its own benchmark transparency invites.

For teams assembling that envelope into an agent stack, the routing layer this model provides is the piece that sits underneath the orchestration patterns covered in our agent orchestration survey: before planners and workers divide labor, something has to decide which work goes where, and doing that with calibrated probabilities instead of prose is a structural upgrade. The local-first economics also pair naturally with persistent sandbox compute for the generation side, and with the cost discipline described in our model routing analysis, since every decision call moved off a hosted endpoint is margin recovered.

Sources
Subscription Form