Drex v2.0: Local Hosting or API for Agent Decisions?

Drex v2.0 gives agent builders another way to make a bounded choice without asking a chat model to write an answer. The publisher documents a model that scores supplied options, with a local runtime as well as an OpenRouter route observed on October 13, 2026. The useful decision is where to evaluate it: a hosted endpoint for a quick integration check, or local infrastructure when control over execution is part of the requirement.

That choice depends on more than the listed token price. Local memory requirements, request limits, the model-specific license, outcome quality and the work of operating a service all matter. This guide separates those questions and sets out a proposed evaluation. We have checked publisher documentation and catalogue fields; we have not downloaded the weights or benchmarked the model.

A decision model scores a defined set of answers. Instead of asking it to compose a paragraph, the application supplies a state and typed questions, then interprets the returned probabilities. The publisher repository describes yes/no, multiple-choice and rating-scale questions through a System One API. This can be useful for selecting a tool or routing a case when the allowed outcomes are already known.

The application still owns the meaning of those outcomes. Imagine routing a document to a specialist queue. If the available choices omit the correct specialist, a well-formed response can still send the document somewhere inappropriate. Include an explicit route for insufficient information or unsupported cases when the business process requires one. A fixed answer vocabulary prevents invented labels; it does not prevent a wrong choice.

Keep generated explanations separate from the scored decision. A chat model can summarize the supporting evidence later, but its narrative should not be treated as a faithful account of the decision model's internal reasoning. Our decision-model introduction explains the broader distinction between scoring supplied options and producing text.

• Define allowed outcomes before selecting a model.
• Preserve a route for cases the supplied options cannot resolve.

The Drex v2.0 model README describes a Qwen3.6-35B-A3B backbone: approximately 35 billion total parameters with about three billion active per token. It is a mixture-of-experts model, meaning a subset of its experts participates in each token's computation. The publisher states that the runtime uses the language component and drops the vision tower.

Active parameter count is not the same as the amount of memory needed to hold the model. Treat a small active count as an architectural property, not a shortcut to a laptop recommendation. The runtime, weight precision, request length and concurrent work all affect the machine you need. A buyer should require a working configuration and representative load measurements before promising local capacity.

This distinction also matters when comparing models that accept different inputs. The captured Drex route is text-to-decisions. An upstream application may extract text from an image or recording, but that creates a separate pipeline with its own errors. Do not describe the resulting application as evidence that the Drex endpoint directly understands those input modalities.

The October 13 OpenRouter capture lists nace-ai/drex-v2.0 at $0.06 per million input tokens, with a zero output-token charge and a 131,072-token context value. That establishes a listed route and observed price. It does not establish a free service, an unlimited request allowance or availability through every first-party endpoint. Decision output still requires billed input processing.

The hosted reference now lists drex-v2.0 and dates it October 6. Its summary table shows a 131,072-token state limit, but its detailed section limits v2.0 itself to 8,192 state tokens and 16,384 including the longest question; longer requests use v1.5. Confirm the returned model before comparing results, and do not assume this first-party fallback also describes OpenRouter routing.

For an evaluation, use a pinned version where the endpoint supports one and record the actual model returned. If a route silently changes or resolves through an alias, repeated requests may no longer test the same implementation. Our Microsoft/OpenAI decision-model comparison applies the same endpoint discipline to another pair of services.

The model README estimates roughly 70 GB for the bf16 weights and about 37 GB for a Q8_0 GGUF representation. These are publisher-stated weight sizes, not guarantees about total memory use or download sizes in every distribution. Runtime allocations and request processing require additional resources, so a machine whose memory merely matches the weight size is not automatically suitable.

The same documentation describes a 16,384-token default request limit, configurable up to 131,072. That default is distinct from the catalogue's maximum context. A local demonstration using the default cannot establish that a long-document workload fits or remains responsive. Start with the shortest realistic requests, then test the lengths and concurrency your service actually needs.

Record disk, memory and latency separately. A hypothetical workstation may store the weights comfortably while struggling to serve several long requests at once. Conversely, a dedicated server can be underused when the workflow is infrequent. The operating decision should include the cost of idle capacity, monitoring and support, as well as the attractive fact that the model can run locally.

The repository identifies its code as Apache-2.0 and the v2.0 weights under a separate Nace Open RAIL-M license. These labels apply to different things. The code's license cannot be used as a substitute for reading the terms attached to the weights, and the availability of a repository does not establish unrestricted use of the model.

Before a commercial deployment, collect the exact model-license file, runtime-license file and versions being used. Identify who is responsible for assessing the planned use against those terms. This is an implementation handoff requirement, not a legal conclusion that a particular use is permitted. If your organization cannot resolve the terms, keep the trial within an approved scope while that question is answered.

A hosted endpoint adds its own service agreement and handling of submitted information. Local execution changes that relationship but still leaves the team responsible for access, logs, backups and distribution of artifacts. Do not reduce the decision to a claim that one option is automatically private or compliant. The actual deployment and agreements determine those boundaries.

• Record licenses for code and weights independently.
• Retain the terms and versions reviewed for the intended use.

A returned probability is useful only if the team understands how to act on it. Choose an acceptance rule that matches the cost of the mistake. Misrouting a low-priority internal note and automatically approving a consequential action should not share a threshold merely because both return values between zero and one. Begin with recommendations or shadow decisions when outcomes are still uncertain.

Create a labelled set that includes ordinary cases, ambiguous cases and inputs missing essential facts. Review disagreements with a person who understands the task. Preserve the supplied options, labels and source evidence so that an apparent improvement cannot come from changing the question midway through the comparison. A confidence value alone does not establish that the system is well calibrated on your data.

The publisher reports results on a public Decision Index suite, including a 61.25 score for v2.0. That is a publisher-run result, not our measurement and not a universal ranking for your workload. Use it to motivate an evaluation, then measure the errors that your process can tolerate. A smaller model with fewer harmful errors on your task may be preferable to a higher public aggregate score.

A decision service needs a clear response when it times out, rejects an oversized request or becomes unavailable. The agent should know whether to wait, use a previously approved fallback or return the case for review. It should not convert missing output into the most convenient choice. A workflow that treats service failure as approval is unsafe even if its normal classification quality is excellent.

For a local trial, test the behavior around startup and restart. Send a harmless request before declaring the service ready, and confirm that your application handles an interrupted request without submitting the downstream action twice. For a hosted trial, keep the same application-level tests. Provider infrastructure can reduce operational work without removing the integration's responsibility for retries and ambiguous outcomes.

Separate the model decision from the operation that follows it. An application might decide that a document belongs in a queue, then fail while creating the queue entry. Recovery should inspect whether that entry already exists before repeating the write. The patterns in preventing duplicate agent work remain relevant whichever model or hosting route supplies the decision.

• Return an explicit unresolved state on missing or invalid output.
• Verify downstream effects independently of the model's answer.

Use the hosted route when you need a quick, bounded check of integration and decision quality, subject to approved data-handling terms. Consider local hosting when control over execution is a real requirement and the team can operate the runtime. Neither route wins automatically. The right choice depends on accepted decisions, resource use, service reliability and the effort of reviewing uncertain cases.

Write a short decision record after the trial. It should name the endpoint or pinned artifacts, input limits tested, actual resource observations, error categories and unresolved documentation questions. If you have not tested long inputs or concurrent requests, say so. A local success on one short example is not a capacity estimate, just as a catalogue entry is not a production-readiness certificate.

Our AI transformation work focuses on that transition from a promising component to a reliable process. For Drex v2.0, the next useful step is a small evaluation with an owner and a clear acceptance rule. Expand only after the team can explain how the scored answer becomes a correct, recoverable action.

• Choose hosting after defining the workload and its constraints.
• Keep source conflicts and untested capacity explicit in the handoff.