Nace.AI Releases Drex 1.5 as Open Weights: 9B Decision Model Scores Options in a Single Forward Pass, Hits 93.4% on 128K Long Documents
According to a MarkTechPost report dated October 9, 2026, Nace.AI has released Drex 1.5, an 8.95B dense decision model, as open weights. It reads a state and a typed question, then returns probabilities for each option without generating text. The report says it scores 58.08 on Decision Index 0.3.1 and can run locally in bf16 on a single GPU or via a roughly 9.5 GB quantized version.
What changed
According to a MarkTechPost report dated October 9, 2026, Nace.AI has released Drex 1.5 as open weights, an 8.95B dense decision model aimed at agent and backend workflows. The model does not generate text: users pass in a state (text or JSON) and a named question, and the model returns probabilities for each option in a single forward pass. It supports three question types: choice, noul (yes/no), and ordinal score. Because no tokens are sampled, temperature and top_p do not apply. The source says its backbone is MiMo-V2.6-Distill-Qwen-9B, with 32 layers and hybrid attention (each full-attention layer paired with 3 linear-attention layers), plus a separate pointer head, head.pt, that scores hidden states. The interface is POST /v1/systemone, matching the request format of TypeSafe's closed-source model Jev; the source says existing Jev clients can migrate by changing a few environment variables. Context defaults to 16,384 tokens and maxes out at 131,072. Weights have been published on Hugging Face, a hosted version is live on OpenRouter, and compute is said to be provided by DeepInfra.
What it means for developers
The most direct change for developers is that decision tasks shift from 'have a chat model output structured text, then parse it' to 'get option probabilities in one forward pass.' That removes parsing and retry logic and makes decision latency more predictable. According to the report, long documents are where Drex 1.5 is strong: 93.4% accuracy and 2.0 seconds median latency at 32K to 128K tokens; when the same batch of requests was truncated to 8K tokens, accuracy fell to 76.5% and 78%. This shows a clear gap between long-context and short-context decision performance, which matters a lot for workflows like post-RAG adjudication or ranking multiple candidates. On the other hand, the report points out it is a decision layer, not a general model: it cannot generate text, code, or explanations; it is weak on knowledge-intensive tasks, with GPQA Diamond at 45.4% versus Jev's 78.6%, and MMLU-Pro at 58.7% versus Jev's 82.7%. On ACOS, sentiment analysis F1 on a single review is only 7.4%, versus 29.5% for Jev. Training used the official training sets of the indexed benchmarks, giving it an edge on common decision types, but the source also warns that results in new domains may differ. On deployment, the local path requires Nace's llama.cpp and Ollama forks rather than upstream mainline builds. The weights use the Open RAIL-M license, and the source explicitly says to confirm the terms before commercial use. This is where 'open weights' and 'open-source license' need to be viewed separately: weight availability does not equal permissive licensing.
Integration and evaluation
The following are suggestions and conditional analysis based on the source report, not independently verified facts. Decision one: whether to switch existing Jev call sites to Drex 1.5. The report says the two share the same request format and that the main migration cost is environment variables. So when the workload is mostly option scoring, yes/no decisions, and ordinal ranking, and the team wants to move decision traffic off a closed-source API, an initial shadow-traffic comparison is more prudent. A measurable acceptance criterion is to send the same batch of historical requests to both paths and track the option agreement rate and the share of cases where the top-option probability falls below a threshold. If the agreement rate is high and the share of low-confidence samples does not rise noticeably, scale up gradually. If the workload includes explanation generation or answers that require showing a reasoning process, do not switch, because the report says this model does not generate text. Decision two: whether to use the 128K tier directly for long-document scenarios rather than truncating first. The report shows 93.4% accuracy and 2.0 seconds median latency at the 32K to 128K tier, while truncating to 8K drops accuracy to 76.5% and 78%. So when the input really is a long document and the latency budget can absorb second-level overhead, keeping the long context may be the higher-return choice. When evaluating, bucket by length (under 8K, 8K to 32K, 32K to 128K) and measure accuracy and P95 latency. If the long-tier latency exceeds budget, then consider truncation, but accept the accuracy drop. Decision three: local versus hosted deployment. The report says bf16 is about 18 GB and can run on a single 24 GB A10G, while Q8_0 GGUF is about 9.5 GB and can run on Apple chips and CPUs, and the source says the two quantized paths give consistent answers. So local deployment is feasible when data cannot leave the internal network or offline inference is needed. The precondition is accepting a build from Nace's fork and accepting the terms of Open RAIL-M. Evaluation criteria are comparing answer consistency between local and hosted on the same eval set, and whether single-GPU throughput meets the required requests per second. Prices change; for hosting costs, refer to the current pricing pages on OpenRouter and Nace Console.
Limits and open questions
It should be clear that Drex 1.5 does not currently appear in KimiSeek's model list. The API availability in the report points to the vendor's own hosting service and is unrelated to this site's catalog. The benchmark scores in the source (58.08 on Decision Index 0.3.1, 86.2% on JevBench, 122 wins, 47 draws, and 87 losses on OpenSpiel, 93.4% on long documents, and so on) are reported results produced by Nace or the leaderboard operators, mostly by the vendor running official evaluation suites itself, and this site has not independently reproduced them. The report also notes that the model was trained on the official training sets of the indexed benchmarks, so performance in new decision domains may differ from leaderboard scores. The weak spots on ACOS sentiment analysis and knowledge tests are given in the report. In addition, the Ollama and llama.cpp paths depend on Nace's forks; upstream mainline may not support them in sync. Although the weights are open, the license is RAIL-M with usage restrictions, so commercial use requires checking the terms yourself. The $25 sign-up bonus and hosting prices mentioned in the report are point-in-time information from launch and may have changed; please check the current pricing pages.