Nex-N2.5 Explained: 1.6T Max, 397B Pro, 35B Mini and the Open-Weights Status

In September 2026, Nex AGI shipped Nex-N2.5, a three-tier family of agent-oriented Mixture-of-Experts models that spans roughly 35 billion to 1.6 trillion parameters, and almost every early write-up got at least one detail wrong. Some said all three tiers were downloadable on day one. Others said the mid-size model had no weights at all. Both claims were true at different moments, and a few secondary sources still repeat the stale version.

This matters because “open-weight agentic model” is now a procurement category, not a slogan. If you are deciding whether to self-host a model that drives a browser, a terminal or a codebase, you need the real parameter counts, the real licence, the real GPU bill and an honest read of which benchmark numbers anyone outside the vendor has reproduced.

This post pins those facts down, flags what is vendor-reported, and finishes with a small evaluation harness you can run on your own tasks.

What this covers: the family and its lineage, the architecture and sizing of each tier, the open-weights timeline, the agentic training claims, a serving and cost model, the benchmark picture with caveats, failure modes, a decision matrix against peers, and a practical eval harness in Python.

Context and Background

Through 2025 and into 2026 the open-weight frontier moved from chat quality to agent quality. The questions stopped being “how well does it answer MMLU-style questions” and became “can it finish a forty-step terminal task, repair a real GitHub issue, or click through a desktop application without losing the plot.” Benchmarks followed: Terminal-Bench, SWE-Bench Pro, BrowseComp, OSWorld and a growing zoo of harness-specific suites.

On the open side, the dominant pattern was sparse Mixture-of-Experts (MoE) with a large total parameter count and a small active count per token. That is the design behind the models we have already covered, including Kimi K2 and its architecture and benchmark profile and Ling 3.1 Flash and its pricing trade-offs. MoE lets a lab claim trillion-scale capacity while keeping per-token compute closer to a mid-size dense model, at the cost of a very large memory footprint.

Nex AGI, publishing on Hugging Face under the nex-agi organisation, is a newer name in that landscape. Its Nex-N2 line was multimodal; N2.5 extends that with a post-training effort aimed squarely at “long-horizon tasks in real-world environments,” which is the phrase on the model card. The family has three members:

Nex-N2.5-mini, a multimodal model of about 35 billion total parameters.
Nex-N2.5-Pro, a multimodal model of about 397 billion total parameters.
Nex-N2.5-Max, a text-only model of about 1.6 trillion total parameters.

Two points frame everything that follows. First, mini and Pro build on the multimodal Nex-N2 foundations, while Max uses a new, separate base model, and a third-party review reports that base as DeepSeek-V4-Pro-Base. Second, the vendor describes Max as its first complete post-training run at trillion-parameter scale, and says the experience is useful for training agent capabilities in even larger models. The family is therefore as much a statement about a training pipeline as about three checkpoints.

For readers building systems around agents rather than evaluating a single model, the orchestration layer matters as much as the weights. Our guide to multi-agent orchestration with MCP, A2A and LangGraph covers how a model like this slots into a larger control loop. For the primary source on each checkpoint, the Nex-N2.5-Pro model card on Hugging Face is the document to read first.

A note on sourcing

The model cards are the authoritative source for licence, architecture tags, serving commands and benchmark tables. Third-party coverage is useful for cross-checks but disagrees with the cards in places, so throughout this post every number is tagged. “Model card” means read from the Hugging Face repository. “Hub metadata” means read from the Hugging Face API for the repository. “Reported” means a secondary source we could not confirm against the card. Where a figure appears nowhere official, we say so rather than fill the gap.

The Nex-N2.5 Family: Reference Architecture and Sizing

The Nex-N2.5 family is three sparse MoE checkpoints sharing one post-training philosophy: mini (about 35B total, about 3B active, multimodal), Pro (about 397B total, about 17B active, multimodal) and Max (about 1.6T total, about 49B active, text-only). All three are listed under Apache-2.0 on Hugging Face. Active-parameter counts come from secondary sources, not the cards.

Figure 1: The Nex-N2.5 family at a glance. Total parameters come from Hugging Face hub metadata; active parameters are reported by secondary sources and are not stated on the cards.

Figure 1 summarises the three tiers. The long-description version is this: the left branch is the multimodal line, mini and Pro, both inheriting from Nex-N2 and both accepting image and text input; the right branch is Max, a text-only model on a new base. Every tier routes each token through a small subset of experts, so memory scales with total parameters while compute per token scales with active parameters.

Verified sizing

The Hugging Face API reports the safetensors parameter totals directly, which is the most reliable number available. As of this writing:

Tier	Total parameters (hub metadata)	Active per token	Modality	Licence tag
mini	about 35.1B	about 3B (reported)	Text and image in, text out	Apache-2.0
Pro	about 396.8B	about 17B (reported)	Text and image in, text out	Apache-2.0
Max	about 1,600.8B	about 49B (reported)	Text only	Apache-2.0

The 397B and 1.6T headline numbers therefore match the metadata. The active counts of roughly 3B, 17B and 49B appear in a model-tracking changelog and in a mini-focused review, but the Pro card says “not stated” for active parameters and we could not find an official figure. Treat them as plausible and widely repeated, not as confirmed.

Context windows

The mini checkpoint ships with max_position_embeddings of 262,144 tokens in its released configuration, per a detailed third-party read of the repo. The Pro card does not state a context length, but its serving instructions for the Max tier pass --context-length 262144, and secondary deployment listings give 262,144 for both mini and Pro. One tracker lists a 1 million token window for Max. We could not verify that figure on the cards, and the only Max deployment example we found uses 262,144. For planning, assume 256K-class context for all tiers and treat a 1M claim for Max as unverified.

What the architecture tag tells you

Both the Pro and mini repositories carry an architecture tag of qwen3_5_moe, and mini’s config reportedly shows 40 layers, a hidden size of 2,048, grouped-query attention with 16 query heads and 2 key-value heads, 256 routed experts with 8 active per token plus a shared expert, and a vocabulary of 248,320 tokens. A separate analysis describes a hybrid layout of three linear-attention layers followed by one full-attention layer, repeated, plus one multi-token-prediction head.

Two consequences follow. The family is architecturally close to the Qwen3.5-MoE lineage rather than to a bespoke design, which means mainstream inference engines already understand the tensor layout. And the hybrid linear-attention design explains why serving flags mention a Mamba-style scheduler buffer: linear-attention layers keep recurrent state rather than a classical key-value cache, and the scheduler has to manage that state across requests.

Why MoE sizing drives the hardware story

A rule of thumb helps here. Weight memory is roughly total parameters times bytes per parameter. In BF16, mini’s 35.1B parameters occupy about 70 GB, which matches the roughly 70 GB of safetensors shards reported for the repo. Pro in BF16 would be near 800 GB, and Max would be near 3.2 TB. The model cards also list an F8_E4M3 tensor type for Pro, which means an FP8 variant roughly halves those figures.

That arithmetic is consistent with the vendor’s reference deployments: two H100s for mini, one eight-GPU H100 node for Pro, and two eight-GPU H200 nodes for Max. We return to cost and throughput in the serving section, but the headline is that active parameters set your latency while total parameters set your bill of materials.

Three thinking modes

All tiers expose a reasoning_effort control on the OpenAI-compatible chat endpoint. According to the Pro card, none produces no reasoning trace, medium is the default and lets the model decide whether and how much to think, and high always thinks. For agents this is a real knob, not decoration. Long chains of tool calls multiply any per-step reasoning cost, so the medium default is a sensible baseline and high should be reserved for steps where an error is expensive.

The vendor recommends sampling with temperature 0.7, top-p 0.95 and top-k 40 for evaluations, and the card reports that its own scores were produced with those settings. If you evaluate with greedy decoding you are measuring something different from what was published.

The Open-Weights Status: What Is Actually Downloadable

As of the Hugging Face API read for this post, all three Nex-N2.5 repositories contain safetensors weights under an Apache-2.0 tag: mini (28 files), Pro (134 files) and Max (654 files). Pro was the laggard at launch, with only a README and figures, and its weights landed later in September.

This is the most misreported part of the launch, so it is worth a careful timeline. The sequence below combines hub metadata with dated secondary coverage.

Timeline

8 September 2026: Nex AGI publishes the family. Mini and Max repositories show a last-modified timestamp on that day. Coverage the same day, from a runtime-focused news site, states that Pro’s weights were marked “coming soon” and were not in the repository.
9 September 2026: A review reports weights on Hugging Face and ModelScope for all three sizes and describes the family as open-weight, without naming a licence. A mini-focused write-up reports that the Pro repo contained only the README and figures, and that Max was available as 644 safetensors shards.
17 September 2026: Hub metadata shows the Pro repository last modified, with a total safetensors parameter count of about 396.8B and 134 files, which is consistent with weights having been uploaded.
At time of writing: The Pro model card still contains the sentence that weights “will be released as open source,” which is stale wording rather than a current limitation. We did not independently download and hash the Pro shards, so “downloadable” here rests on the hub file listing and the safetensors metadata, not on a full pull.

The practical lesson is general. Launch-day articles about open-weight models age quickly, and the only durable source is the repository itself. Before you plan around a checkpoint, query the hub API for file count and safetensors totals, and compare against the parameter figure in the announcement.

What “open” means here

The Apache-2.0 tag is the permissive end of the spectrum: commercial use, modification and redistribution are allowed with attribution and a patent grant, and there is no user-count threshold or acceptable-use carve-out of the kind that some “open” model licences add. The repositories are not gated.

Three caveats keep that from being the whole story:

Weights are not data or recipes. The cards describe post-training in general terms and publish no training corpus, no reward model, no environment definitions and no compute figure. You can run and fine-tune the model, but you cannot reproduce it.
The harnesses are not all open. Coding evaluations use an internal harness called NexAU, and computer-use evaluations use NexCUA, which the card says “will be open-sourced soon.” Until NexCUA ships, the OSWorld and WebArena numbers cannot be independently reproduced by outsiders.
Max inherits a base. A third-party review reports Max is built on DeepSeek-V4-Pro-Base. We could not confirm this on the Max card, so the lineage claim is reported, not verified. If it is accurate, the licence of the base model matters for your legal review, and the Apache-2.0 tag on the post-trained weights does not by itself settle it.

Hosted access

Hosted access is available through OpenRouter, where the reviews we read describe free, rate-limited endpoints for mini and Pro. Sources disagree on whether Max is hosted there, and no source we found gave a trustworthy paid per-token price. Rather than quote a number, we recommend checking the live listing before you build a cost model. Hugging Face’s own page notes that no Inference Provider was serving Pro when it was captured.

Community conversions

For mini, the community has already produced GGUF and MLX conversions. One Q4_K_M GGUF is reported at about 21 GB, which puts a 35B-total, 3B-active multimodal model within reach of a single high-memory workstation or a 24 GB to 32 GB GPU with some offloading. Quantised builds change quality and are not covered by the vendor’s benchmark table, so re-run your own checks.

How the Agentic Training Claims Break Down

Nex AGI attributes the N2.5 results to systematic post-training on expanded agent environments, task types and feedback signals, with vision used as a self-correction channel for computer use. The cards give no data sizes, compute or hyperparameters, so the mechanism is described, not documented.

Figure 2: The training story as the vendor tells it. Base model, post-training in expanded environments, then evaluation in two internal harnesses. Stages marked as reported are not documented in detail.

Figure 2 lays out the pipeline. The long-description version: a base model (the multimodal Nex-N2 foundation for mini and Pro, a new trillion-scale base for Max) feeds a post-training stage, which is run against agent environments for coding, terminal use, browsing and desktop control, and the resulting checkpoint is evaluated in NexAU for coding or NexCUA for computer use.

What the vendor actually says

The model card language is brief. It describes “systematic post-training,” expanded agent training environments, broader task types and richer feedback. For mini and Pro it emphasises improvements in computer use, web browsing and visually grounded agentic tasks. For Max, it frames the run as the first complete post-training effort at trillion-parameter scale and as practical experience for training agentic capabilities in even larger models.

A secondary write-up adds a useful interpretation: the team treats vision as the mechanism by which an agent checks and corrects its own work through visual feedback. That is a reasonable engineering idea. A computer-use agent that can see the result of a click can detect a failed action and retry, whereas a text-only agent relies on structured observations such as accessibility trees or terminal output.

Reading between the lines, carefully

What follows is analysis, not vendor disclosure. Agent post-training generally combines supervised fine-tuning on trajectories with reinforcement learning against verifiable outcomes, such as unit tests passing, a shell command producing the right file, or a page reaching a target state. The expansion of “environments, task types and feedback” is consistent with that recipe, and the ratio of verifiable to learned rewards is the lever that most affects how far scores generalise beyond the benchmark.

Three questions are worth asking of any such claim, and the Nex cards leave all three open:

Environment overlap. How similar are training environments to the evaluation tasks? Benchmarks like Terminal-Bench and SWE-Bench Pro are public, and any lab can build training tasks that resemble them without any intent to cheat.
Harness fit. A model post-trained in the same harness it is scored in, here NexAU and NexCUA, may do better there than in a third-party scaffold. The gap is an empirical question for your own stack.
Scale effects. Max is the largest model, but it is text-only. The family therefore splits capability: if you need a model that sees the screen, you are choosing Pro or mini, which are an order of magnitude smaller in active parameters.

Why the multimodal and text-only split exists

Putting vision into a 1.6T model adds a vision encoder, alignment data and a second post-training dimension. Releasing Max as text-only let the team spend its first trillion-scale run on coding, terminals and browsing, where text observations suffice. This is a plausible reading, but it is our inference, not a statement from the vendor.

Serving Max, Pro and Mini: Hardware, Software and Cost

Nex AGI’s reference deployments use a customised SGLang fork in Docker: two H100 GPUs for mini, one node of eight H100s for Pro, and two nodes of eight H200s for Max. These are reference minimums, not throughput-tuned production configurations.

Figure 3: Reference serving footprints. Mini fits on two GPUs with tensor parallelism 2, Pro on one eight-GPU node, and Max across two eight-GPU nodes with tensor and expert parallelism.

The long-description version of Figure 3: a client sends OpenAI-style chat requests to a gateway, which fronts one of three SGLang deployments. Each deployment shards the model across GPUs in the same node, except Max, which spans two nodes and therefore depends on a fast interconnect.

The reference commands

The Pro card documents the Docker image nexagi/sglang:v0.5.18-nex-patch, a patched SGLang build. Its key flags include --tp 8, --port 30000, --reasoning-parser qwen3, --tool-call-parser qwen3_coder and --mamba-scheduler-strategy extra_buffer, plus a chat-template file. Alternatives listed include vLLM, SGLang installed from pip, and Docker Model Runner. The Max example uses a different reasoning parser, deepseek-r1, consistent with the DeepSeek-style lineage reported by third parties, and passes a 262,144-token context length.

Two details deserve emphasis. The tool-call parser is qwen3_coder, so function calling follows that format; if you wrap the model in a framework expecting a different tool schema, test parsing first. And the patched SGLang image exists for a reason: stock builds may not handle the hybrid attention state correctly, so using the vendor image is the safe starting point.

A back-of-envelope cost model

The following is an illustration, not a benchmark. Suppose you rent GPUs at a blended hourly price you must substitute from your own provider. A mini deployment on 2 GPUs costs 2 times that price per hour. A Pro deployment on 8 GPUs costs 8 times it. A Max deployment on 16 GPUs costs 16 times it. At the same hourly rate per GPU, Max is eight times the fleet cost of mini before any throughput difference is counted.

What matters is cost per successful task, not cost per token. If Max resolves a larger share of your tasks in fewer steps, the 8x fleet can still be cheaper per resolved task, but only if utilisation is high. A lightly used 16-GPU deployment is the worst case in this family, because the weights occupy the memory whether or not requests arrive.

Which tier for which workload

Mini suits interactive computer-use prototypes, on-premises pilots and cost-sensitive background agents. Its 3B-active compute is light, and its quantised builds fit prosumer hardware.
Pro is the sweet spot if you need vision and strong computer-use scores. Its self-reported OSWorld-Verified result of 82.2 is the headline number for the family, with the caveats we discuss below.
Max is the choice for text-only coding and browsing agents where you can justify two nodes. It leads the family on every coding benchmark in the vendor table.

Operational notes

Concurrency and context length interact. Long agent trajectories accumulate tokens, and even with linear-attention layers reducing cache growth, prefill for a 200K-token trajectory is expensive. Cache reuse across turns, supported by SGLang’s prefix caching, is usually the largest single saving for agent loops, because each step re-sends most of the prior transcript. Measure your own cache hit rate before committing to a GPU count.

Finally, FP8. The Pro card lists both BF16 and F8_E4M3 tensor types. If an FP8 checkpoint is available for the tier you want, it roughly halves weight memory. The vendor’s published scores are for the released checkpoints, so verify quality on your tasks after any quantisation.

Benchmarks: What the Numbers Say and What They Do Not

Nex AGI reports Max at 86.1 on Terminal-Bench 2.1, 65.7 on SWE-Bench Pro and 92.6 on BrowseComp, and Pro at 82.2 on OSWorld-Verified. All figures are vendor-reported with temperature 0.7, top-p 0.95, top-k 40, and several depend on harnesses that outsiders cannot yet run.

The table below reproduces the vendor-reported scores that appear consistently across the Pro model card and the secondary reviews we read. We have not re-run any of them.

Benchmark	mini	Pro	Max
Terminal-Bench 2.1	73.4	82.7	86.1
SWE-Bench Pro	43.8	61.2	65.7
DeepSWE v1.1	36.1	55.8	65.6
BrowseComp	83.4	89.7	92.6
Toolathlon Verified	54.6	68.5	76.5
AutomationBench	32.3	44.2	50.2
OSWorld-Verified	71.2	82.2	text-only
OSWorld-G (grounding)	82.9	87.4	text-only
WebArena-Verified	63.4	67.6	text-only

Source: Nex-N2.5 model cards and secondary reviews; all vendor-reported. Max has no computer-use scores because it is text-only.

Reading the table

The ordering is clean: Max beats Pro beats mini on every coding and browsing row, which is what a scaling-driven family should show. The more interesting question is how large the steps are. Between mini and Pro, SWE-Bench Pro moves from 43.8 to 61.2, a gain of 17.4 points for roughly 5x more active parameters on reported counts. Between Pro and Max it moves a further 4.5 points for roughly 3x more. Returns diminish, which is the usual shape, and it suggests Pro captures most of the value for many workloads.

Against closed frontier models the picture is mixed. In the comparison set the vendor chose, which includes Claude Opus 5, GPT-5.6 Sol, Kimi-K3, GLM-5.3, DeepSeek-V4-Pro-0813 and Qwen3.8-Max, a secondary review reports Opus 5 ahead of Max on Terminal-Bench (89.1 versus 86.1), SWE-Bench Pro (79.2 versus 65.7) and DeepSWE (73.7 versus 65.6). The same review reports Max at 92.6 on BrowseComp as the highest in the set, a near tie on AutomationBench (50.2 versus 50.3), and a three-way tie on Toolathlon Verified at 76.5. The 13.5-point SWE-Bench Pro gap is the figure to remember: browsing parity does not imply repository-repair parity.

Pro’s OSWorld-G grounding score of 87.4 is reported as the highest in its column, ahead of Qwen3.8-Max at 84.9. Grounding measures whether the model can map an instruction to the right screen element, and it is a component of computer use, not the whole of it. Mini’s OSWorld-2 score of 30.5 against a reported 68.3 for Opus 5 shows how large the gap remains on the harder, newer suite.

Methodology caveats

Several cautions apply before you cite these numbers.

Self-reported. Everything above comes from the vendor, and the card says scores mix official leaderboards with the authors’ own evaluations.
Harness dependence. NexAU and NexCUA are the vendor’s own scaffolds. A different scaffold, different tool schemas or a different retry policy can move results by many points on agent benchmarks.
Oracle settings. WebTest is reported in oracle mode, where the model is given a ground-truth checklist. That is not the setting you will deploy in.
Competitor numbers. Scores for other vendors’ models come from their own reports and may use different harnesses and sampling.
Contamination. Public benchmarks with fixed task sets can leak into training data. Newer or refreshed suites reduce but do not remove the risk.
Inconsistent commentary. One review claims mini does not beat a closed frontier model on any benchmark, yet its own table shows mini’s OSWorld-G score of 82.9 above Opus 5 at 76.8. Read tables, not summaries.

We did not find independent leaderboard entries for any Nex-N2.5 model at the time of writing. That absence is itself information: until a third party reproduces a score, treat it as a claim.

Evaluating an Agent Model on Your Own Tasks

The only benchmark that predicts your results is one built from your tasks, scored by programmatic checks, run several times per task at the vendor’s recommended sampling. A minimal harness needs a task list, a sandbox, a loop that calls the model with tools, and a verifier.

Figure 4: A minimal agent evaluation loop. Each task runs in a fresh sandbox, the model acts through tools, and a deterministic verifier produces pass or fail that rolls up into a scorecard.

The long-description version of Figure 4: a task suite feeds a runner, the runner provisions a clean sandbox, the model loop alternates between model calls and tool executions until it finishes or hits a step limit, a verifier inspects the final state, and results aggregate across repeats into pass rate, cost and step count.

Design principles

Use verifiable outcomes: a file exists with the right content, a test suite passes, a database row has changed. Avoid scoring by another model where a deterministic check is possible. Run each task at least three to five times, because agent runs are stochastic even at fixed sampling, and report pass rate with a spread, not a single run. Record steps, tokens and wall-clock time alongside success, since a model that passes in 40 steps may cost more than one that passes in 12.

Keep the harness identical across candidates. Same tools, same system prompt, same step limit, same timeout. Differences in scaffolding are the most common reason two teams reach opposite conclusions about the same model.

A small harness

The following Python is a compact starting point. It assumes an OpenAI-compatible endpoint, which SGLang and vLLM both provide, and uses the sampling the vendor recommends. The reasoning_effort field is passed through extra_body; confirm your server accepts it. Tool definitions and sandbox execution are left as stubs because they depend on your environment.

import json, time, statistics
from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="none")
MODEL = "nex-agi/Nex-N2.5-Pro"   # served model name on your endpoint
MAX_STEPS = 30
REPEATS = 5

TOOLS = [{
    "type": "function",
    "function": {
        "name": "run_shell",
        "description": "Run a shell command in the sandbox and return stdout.",
        "parameters": {"type": "object",
                       "properties": {"cmd": {"type": "string"}},
                       "required": ["cmd"]},
    },
}]

def run_tool(sandbox, name, args):
    if name == "run_shell":
        return sandbox.exec(args["cmd"])          # your sandbox wrapper
    return "unknown tool"

def run_task(task, effort="medium"):
    sandbox = task["make_sandbox"]()              # fresh state each run
    msgs = [{"role": "system", "content": task["system"]},
            {"role": "user", "content": task["prompt"]}]
    tokens, steps = 0, 0
    for steps in range(1, MAX_STEPS + 1):
        r = client.chat.completions.create(
            model=MODEL, messages=msgs, tools=TOOLS,
            temperature=0.7, top_p=0.95,
            extra_body={"top_k": 40, "reasoning_effort": effort},
        )
        tokens += r.usage.total_tokens
        m = r.choices[0].message
        msgs.append(m.model_dump(exclude_none=True))
        if not m.tool_calls:
            break
        for call in m.tool_calls:
            out = run_tool(sandbox, call.function.name,
                           json.loads(call.function.arguments))
            msgs.append({"role": "tool", "tool_call_id": call.id,
                         "content": out[:4000]})
    return {"passed": bool(task["verify"](sandbox)),
            "steps": steps, "tokens": tokens}

def evaluate(tasks, effort="medium"):
    report = {}
    for t in tasks:
        runs = [run_task(t, effort) for _ in range(REPEATS)]
        report[t["id"]] = {
            "pass_rate": sum(r["passed"] for r in runs) / REPEATS,
            "median_steps": statistics.median(r["steps"] for r in runs),
            "median_tokens": statistics.median(r["tokens"] for r in runs),
        }
    return report

Using the harness well

Run the same suite against reasoning_effort set to none, medium and high and plot pass rate against median tokens. For many agent tasks the middle setting is the efficient point, but that is exactly the kind of claim you should test rather than assume. Then run the suite against a baseline from another family so that you are comparing, not only measuring.

Seed your suite with failures from production: tasks your current system got wrong, tasks where a human had to intervene, tasks with ambiguous instructions. A suite of 40 to 100 such tasks, each with a strict verifier, will tell you more than any public leaderboard. Include a handful of adversarial cases, such as a tool returning an error or a page that changes layout, to see whether the model recovers or loops.

Trade-offs, Gotchas, and What Goes Wrong

The main risks with Nex-N2.5 are stale information, unreproducible benchmarks, harness lock-in, large memory footprints and the usual agent failure modes of looping, over-confident completion and unsafe actions in live environments.

Documentation drift

The Pro card still says weights “will be released,” while hub metadata shows them present. Several launch articles say Pro is not downloadable. If your procurement or legal team reads the wrong page, they may reject or approve the wrong thing. Always pin a specific commit hash of the repository and record it.

Benchmark transfer

A model scoring 82.2 on OSWorld-Verified inside NexCUA may behave differently in your computer-use stack, because screenshot resolution, action space, and coordinate conventions differ between harnesses. Until the harness is released, plan on a pilot with your own scaffold and expect a gap.

Memory is the real cost

MoE hides the compute cost but not the memory cost. Max needs 16 H200 GPUs in the reference setup, and a node failure takes the whole replica down. High availability means doubling that fleet. For most teams, Pro on one node, or hosted access, is the realistic ceiling.

Agent failure modes

Long-horizon agents fail in recognisable ways. They loop on a failing command with small variations. They declare success without verifying. They exceed context and lose early constraints. They take destructive actions because a tool permitted them. None of this is specific to Nex-N2.5, and the cards do not publish safety evaluations, jailbreak or red-team results, or a hallucination profile. Absent that, apply defence in depth: least-privilege tools, sandboxed execution, human approval for irreversible actions, step limits and audit logs.

Provenance and licensing

Apache-2.0 on the checkpoint is clear. The reported dependence of Max on a third-party base, and the absence of published training data, mean you should have counsel confirm the upstream terms before shipping Max in a regulated product. This is a diligence step, not a finding of a problem.

Tooling quirks

The patched SGLang image, the qwen3_coder tool-call parser for Pro and the different deepseek-r1 reasoning parser for Max show that the tiers are not drop-in replacements for each other. Swapping tiers means re-testing parsing, stop tokens and template behaviour, not only changing a model name.

How Nex-N2.5 Compares

The matrix below is qualitative and based on the vendor-reported numbers above and the public descriptions of peers. It is a starting point for your own evaluation, not a ranking.

Use case	Nex-N2.5-mini	Nex-N2.5-Pro	Nex-N2.5-Max	Closed frontier model (for example the comparison-set leaders)
Self-hosted computer-use agent	Good fit, cheapest	Best fit in family	Not usable, text-only	Strongest on hard suites, no self-hosting
Repository-level bug fixing	Weak relative to others	Solid	Strongest in family	Leads on SWE-Bench Pro in reported tables
Web research and browsing	Good	Very good	Reported best in set on BrowseComp	Comparable
Cost per resolved task at low volume	Lowest hardware	Moderate	Highest fixed cost	Pay per token

Peers worth testing alongside it include the sparse open models we covered earlier, such as Kimi K2 and Ling 3.1 Flash, and the Qwen and DeepSeek families that the Nex cards themselves compare against.

Practical Recommendations

Treat Nex-N2.5 as a credible, permissively licensed option for agent workloads that you must evaluate yourself, not as a proven drop-in replacement for a closed frontier model. The strongest evidence in its favour is the Apache-2.0 licence, the availability of three sizes, and consistent scaling across tiers. The strongest evidence against complacency is the absence of independent reproduction and the unreleased computer-use harness.

Start small. Pull mini, run the harness above on 40 of your own tasks, and learn the failure shape cheaply. If the task set needs vision or stronger results, move to Pro on a single eight-GPU node and compare against a hosted baseline. Reach for Max only when text-only coding and browsing at the top of the family is worth a two-node deployment and you have the utilisation to pay for it.

Whatever you choose, pin versions, record the repository commit, and keep your evaluation suite as the contract. When the next checkpoint arrives, you will re-run the suite rather than re-read the marketing.

Checklist

[ ] Query the Hugging Face API for file count, safetensors total and commit hash of the exact repo you will deploy.
[ ] Confirm Apache-2.0 on the repo and have counsel review upstream base-model terms for Max.
[ ] Use the vendor’s patched SGLang image first, then test vLLM if you need it.
[ ] Evaluate at temperature 0.7, top-p 0.95, top-k 40 and compare all three reasoning_effort levels.
[ ] Build 40 to 100 verifiable tasks with five repeats each, and track cost per resolved task.
[ ] Sandbox every tool, gate irreversible actions, and log every step.
[ ] Re-check the model card and benchmarks after NexCUA is released.

Frequently Asked Questions

What is Nex-N2.5?

Nex-N2.5 is a family of agent-oriented Mixture-of-Experts language models from Nex AGI, released on 8 September 2026 in three sizes. Mini is about 35 billion parameters, Pro about 397 billion and Max about 1.6 trillion. Mini and Pro are multimodal and target computer use and browsing, while Max is text-only and targets coding, terminals and browsing. All three are listed under the Apache-2.0 licence on Hugging Face.

Is Nex-N2.5 open source or open weights?

It is open weights with a permissive licence. The Hugging Face repositories for all three sizes carry an Apache-2.0 tag and contain safetensors files, so you can download, run, fine-tune and commercially use the checkpoints. The training data, reward models, environments and full recipe are not published, and the computer-use harness NexCUA was still described as coming soon. That makes it open-weight, not fully open source in the research-reproducibility sense.

Can I download Nex-N2.5-Pro?

According to Hugging Face hub metadata read for this post, yes. The Pro repository lists 134 files and a safetensors total of about 396.8 billion parameters, last modified on 17 September 2026. At launch on 8 September it held only a README and figures, and some articles still say it is unavailable. The model card text also still says weights will be released, so verify the file listing yourself before relying on it.

How much hardware does Nex-N2.5 need?

The vendor’s reference deployments use a patched SGLang image. Mini runs on two H100 GPUs, Pro on one node of eight H100s, and Max on two nodes of eight H200s, which is 16 GPUs. Those are minimums, not tuned production setups. As rough arithmetic, BF16 weights are about 2 bytes per parameter, so mini is near 70 GB and Max would be over 3 TB, and FP8 builds roughly halve this.

How good is Nex-N2.5-Max compared with Claude Opus 5?

On the vendor-reported tables as relayed by a secondary review, Max trails Opus 5 on Terminal-Bench 2.1 (86.1 versus 89.1), SWE-Bench Pro (65.7 versus 79.2) and DeepSWE (65.6 versus 73.7), but leads on BrowseComp at 92.6 against 90.8 and roughly ties on AutomationBench. These are self-reported and use the vendor’s harness, so run your own evaluation before choosing.

What is the context window of Nex-N2.5?

Mini’s released configuration reports 262,144 tokens, and secondary listings give the same for Pro. The Max deployment example uses a 262,144-token context length. One model tracker lists 1 million tokens for Max, but we could not confirm that on the official cards, so treat it as unverified and plan for a 256K-class window.