Nex-N2.6: a 1.6% repetition rate, and a base model that was already at 6.0%

2026-11-12 · 23 min · agents · computer-use · tool-calling · benchmarks · glm · mixture-of-experts · multimodal

A 4:01 narrated explainer, drawn in code. Every number and picture in it is this article's own; the sources are below.

› transcript

An agent checks the same regex again, and again, and again, until its token budget runs out. How would you even count that? Hi, I'm Dorrit! Nex-N2.6 is an open agent model that says it loops far less, and never calls a tool that isn't there. Let's see what those claims measure. Chapter one. When reasoning loops. An agent gets a request, with the list of tools it may use, and starts to reason. It calls a tool. The harness runs it and hands back the output, and the model reasons again. A loop is when the reasoning folds back on itself. The same check, written again and again. The tool call never comes, and the episode times out. Take the looping trace from the article. Split it into words. Seventy-nine of them. Slide a window of six words along it. Any window that already appeared earlier is a repeat. Mark every word inside one. Thirty-nine words get marked. So the repeated share is forty-nine point four percent. Set the threshold at thirty percent, and this trace is flagged as a loop. Every choice moves this number: the window length, the threshold, and whether a repeated tool error counts. Nex has not published its choices. Do that for every trace in a test set, and count how many get flagged. Divide by the number of traces. That is a repetition rate. Why do models loop at all? The research names four pushes. Decoding for the likeliest text walks straight into cycles. Each copy of a sentence makes the next copy more likely. Reinforcement learning drains the policy's entropy, so it has fewer ways out. And if long traces earn reward, looping is the cheapest way to be long. Chapter two. Where the drop came from. The launch post says repetition fell from sixteen percent to one point six. But N2.6 is built on a different base. The base alone was already at six percent. Nex's own chart prints that base column. Most of the fall from sixteen to six is already there when Nex runs its suite on the base model. Nex's own training takes it from six to one point six. That step is real. Chapter three. Selection is not success. Every request lists the tools the harness provides. The model has to use only those. Nex's metric checks one gate: is the tool name on the list? Across nine hundred and fifty-six contexts, N2.6 passed every time. It does not check the gates after it. Was it the right tool for this step? Were the arguments right? And a task is many calls in a row. A model that always called the shell would still score a hundred percent. Chapter four. Reading the scoreboard. Nex's table puts DeepSeek V four point one Flash at eighty-two point seven, behind N2.6. DeepSeek's own card says ninety point six, and eighty-two point seven sits under its older model. Compare a harder benchmark. Google DeepMind's Multimodal Knowledge Agent hands the agent real files, like these spectrum plots from a chip design. The agent must classify each marked spur and decide whether the chip can tape out. Its rubric grades the answer, not the tool name. A repetition rate is only as good as its window and its threshold. And a valid tool name is a gate, not success. Read both against the base model. To recap. A loop is repeated windows past a threshold. The base was already at six percent, and Nex took it to one point six. And a valid tool name is a gate, not success. Every source is in the full article. I'm Dorrit. Bye!

Why read this

Solidtop 85%

Reads N2.6's config and shard headers, restores the GLM base column to Nex's claims, and finds a DeepSeek score its own card contradicts.

Original analysis
Concrete numbers to act on
Open code or weights

Agents & harnessesNeeds datacenter GPUsApache-2.0Practitioner model

How this was scored

Is it new?: 1 of 3: An incremental tweak
Can I trust it?: 2 of 3: Measures key facts from files, code or configs
Can I run it?: 2 of 3: Open code or weights with real limits
Will I understand it?: 2 of 3: Mechanism from first principles with figures
Can I act on it?: 2 of 3: A concrete recipe, numbers or comparison
Will it last?: 1 of 3: Relevant for months
Does it affect many?: 1 of 3: A specialist community
Only here?: 2 of 3: A teardown or measurement few others did

Score 59 of 100, ranked 477 of 740 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

Nex-N2.6 arrived on 10 November with three claims in the launch post. Reasoning repetition fell from 16.0% to 1.6% against the previous Nex-N2.5-Pro. Tool selection was valid in 100% of 956 tested contexts. And it scored 83.0 on OSWorld and 84.1 on Terminal-Bench 2.1, ahead of DeepSeek-V4.1-Flash at 71.7 and 82.7.

The post leaves out one comparison. Nex-N2.6 is a post-train of Z.ai's GLM-5.3-Flash, and Nex-N2.5-Pro was built on a different base entirely. The README does print the GLM column, and once you read it, every headline moves. GLM-5.3-Flash on its own was already at 6.0% repetition. Z.ai's own Terminal-Bench 2.1 number for it, 84.3, is a shade above the 84.1 Nex reports for the fine-tune, though the two come from different setups.

None of that makes N2.6 a bad model. It makes the launch numbers a story about two changes at once: a new base, and Nex's training on top of it. This piece separates them where the published numbers allow, explains what each metric measures, and marks what I could not check.

A GLM-5.3-Flash with a different post-train

The weights say so before the README does. config.json declares Glm5NextForConditionalGeneration, model type glm5_next, and diffing it against zai-org/GLM-5.3-Flash-BF16's config, the only differences are the FP8 quantization_config, a few alias keys (a top-level dtype and hidden_size, four linear_* names that repeat values already in linear_attn_config) and a transformers version bump. Hugging Face's parameter count for both repos is 321,323,031,390, to the parameter.

I read all 129 safetensors headers by HTTP range request (76,108 tensors, no weights downloaded) to get the layout:

	Nex-N2.6 (from `config.json` and shard headers)
Base	GLM-5.3-Flash, identical shapes
Layers	45, plus one multi-token-prediction layer
Attention	34 KDA (Kimi Delta Attention) linear layers, 11 sparse MLA layers (every fourth), `index_topk` 2,048
MoE	288 routed experts of width 2,048, 8 per token, plus 1 shared; first 3 layers dense
Active per token	about 17.4B on the text path by my count from the headers (Z.ai says 18B)
Vision	24-layer ViT, patch 14, 0.56B parameters
Weights	FP8 E4M3 with 128×128 block scales; 328,333,456,248 bytes across 129 shards
Licence	Apache-2.0 (the base is MIT)

The architecture is GLM's, and the GLM-5.3-Flash teardown covers why only eleven of those layers keep a KV cache. What Nex changed is the post-training, and the chat template it ships is the base's with one block rewritten: 106 differing lines, all in the check that decides whether tool results can be re-ordered to match their call ids. Same macros, same tool format, same handling of deferred tools. reasoning_effort takes low, high or max and defaults to max, exactly as in GLM's template.

The predecessor was not GLM at all. Nex-N2.5-Pro's config is Qwen3_5MoeForConditionalGeneration: 60 layers, 512 experts with 10 active, 396.8B parameters. So "compared with Nex-N2.5-Pro" compares two different pretrained models with two different post-trains. That matters for every number below.

Two serving details disagree between Nex's own channels. OpenRouter lists input as text and image only, a 262,144-token context, reasoning mandatory with efforts high and medium, at $0.12 per million input tokens and $0.40 per million output. Nex's MOSS API page accepts video_url (MP4 or WebM) on Chat Completions and Responses, and is free for a limited time. The config's max_position_embeddings is 1,048,576. If you want video, use MOSS or self-host; someone in the launch thread asked the same question and had no answer when I read it.

What a reasoning loop looks like

A reasoning model writes a chain of thought before it answers or acts. Repetition is that chain folding back on itself: the same check, the same sentence, the same plan, written again and again until the token budget runs out. In an agent it is worse than wasted tokens. The model never emits the tool call, the episode times out, and the harness logs a failure that looks like a hard task.

The simplest way to measure it is lexical. Split a trace into tokens $w_1, \dots, w_T$ . Call the $n$ -gram starting at position $j$ a repeat if the same $n$ tokens already started somewhere earlier:

\text{rep}(j) = \mathbb{1}\big[\,\exists\, k < j : (w_k, \dots, w_{k+n-1}) = (w_j, \dots, w_{j+n-1})\,\big]

Mark every token covered by a repeated $n$ -gram, and let the repetition share $r$ be the fraction of tokens marked. A trace is flagged as looping when $r \ge \tau$ . Over a set $S$ of traces, the repetition rate is the share flagged:

R = \frac{1}{|S|}\sum_{i \in S} \mathbb{1}[\,r_i \ge \tau\,]

That is my definition, chosen to make the moving parts visible. The widget below implements it exactly. Pick a preset or paste a trace of your own.

repetition detector, n-gram toyflagged: looping

The test fails because parse_date returns None. Let me check the regex. The regex accepts an offset but not Z, so I should add Z to the regex. Wait, let me check the regex again. The regex accepts an offset but not Z, so I should add Z to the regex. Wait, let me check the regex again. The regex accepts an offset but not Z, so I should add Z to the regex. Actually, let me re-read the test first. The test fails because parse_date returns None. Let me check the regex.

n-gram length n = 6 wordsflag threshold tau = 30% of tokens

repeated share r

54.3% (51 of 94 tokens)

longest repeated run

39 tokens

set rate, three presets

1 of 3 flagged

steady: 0%loop: 54% flaggedtool retry: 22%

The article's own toy metric, not Nex's (which is unpublished). A token is marked when it sits inside an n-gram that already appeared earlier in the trace; a trace is flagged when the marked share reaches tau. The presets are illustrative traces written for this article, not model output. The tool-retry preset shows the false positive: a repeated command and its repeated error are not a reasoning loop.

With the defaults ( $n = 6$ , $\tau = 30\%$ ), the steady trace has no repeated 6-gram at all. The loop trace marks 39 of its 79 word tokens, a share of 49.4%, in one run of 39. The tool-retry trace marks 10 of 36, or 27.8%, and is not flagged. Drop $\tau$ to 25% and it is.

That last case is the reason a metric like this is harder than it looks. An agent that runs pytest twice and gets the same ModuleNotFoundError twice has a repeated span in its transcript, and it is not a loop: the repetition is in the tool output, and the model's reasoning moved on. A good detector has to separate the model's own reasoning from echoed observations, decide what length of repeat counts, and pick a threshold. Every one of those choices moves $R$ . One reply to the launch post asked exactly this: whether a model trained hard against repetition still retries a tool sensibly when the API returns the same error payload.

Nex has published none of these choices. The README describes the suite in two sentences: the evaluations are "built from issues encountered in real tasks by our team and partner teams", and "known-issue replay fixes the preceding conversation and tool outputs, then tests the model's next response". The highlights call it an "internal checkpoint-replay evaluation". No $n$ , no threshold, no trace count, no samples.

There is also a puzzle in the table. The two repetition rows do not add up to 100%:

Metric (Nex README)	Nex-N2.5-Pro	GLM-5.3-Flash	Nex-N2.6
Reasoning repetition rate, lower is better	16.0%	6.0%	1.6%
Overall non-repetition rate, higher is better	91.0%	96.2%	97.8%
Sum of the two	107.0	102.2	99.4

If "overall non-repetition" were the complement of "reasoning repetition" on the same set, each pair would sum to exactly 100. They don't, so the two rows must be computed over different denominators: perhaps reasoning spans only versus whole responses including tool calls and final text, or different subsets of the replay cases. Either reading is plausible. The README doesn't say which.

Why models loop

The mechanism has a long paper trail, and none of it is specific to Nex.

Likelihood rewards the loop. Holtzman et al. showed in 2019 that decoding by maximum likelihood produces text that is "bland and strangely repetitive", even from a model trained well on likelihood. Greedy and beam search walk straight into high-probability cycles.

Repetition feeds itself. Xu et al. measured the "self-reinforcement effect": the more times a sentence is already in the context, the higher the probability of generating it again, and sentences that start with high probability reinforce more strongly. Once a model has written "wait, let me check the regex again" twice, the third copy is the likeliest continuation. Their fix, DITTO, trains on synthetic repetitive data with a loss that penalises continuing the repeat.

Reinforcement learning makes it worse in specific ways. Two effects stack up in RL-trained reasoning models:

Entropy collapse. Cui et al. found that policy entropy drops sharply early in RL for reasoning, and derived why: under policy-gradient updates, entropy change follows the covariance between an action's probability and its advantage, which stays mostly positive, so entropy falls nearly monotonically. A low-entropy policy has fewer ways out of a cycle once it enters one.
Length. If long, careful traces earn more reward on average, the policy learns to keep going, and continuing a loop is the cheapest way to keep going. Truncated traces are the other side of it: a rollout that hits the length cap is either scored as a failure or dropped, and the choice shapes what the policy learns. DAPO answers both: its "Overlong Filtering" masks the loss of truncated samples, its "Soft Overlong Punishment" shapes the reward of responses that run past a length budget, and its "Clip-Higher" raises the upper clip bound to keep entropy from collapsing.

The clearest public example is DeepSeek's own. The DeepSeek-R1 card says pure-RL R1-Zero "encounters challenges such as endless repetition, poor readability, and language mixing", and tells users to keep temperature between 0.5 and 0.7 "to prevent endless repetitions". Qwen3's card says not to use greedy decoding in thinking mode because it can lead to "endless repetitions", and offers presence_penalty with a warning that higher values cause language mixing.

So the known fixes come in three kinds: decoding (temperature, presence penalties, which are not training at all), loss-level penalties on repetition (DITTO), and RL recipe changes that manage length and entropy (DAPO). What Nex did is not in any source I found. The README says the release "focuses on reducing repetitive reasoning and improving adherence to the tools available", the release note on nex-agi.com says the same in one sentence, the OpenRouter and MOSS pages describe the API, and the X thread repeats the numbers. No method, no data, no paper. Whatever it was, it happened on top of a base that was already better at this than Nex's last model.

Where 14.4 points of repetition went

Put the three columns in a line and the repetition story splits in two:

Nex-N2.5-Pro (Qwen base, Nex post-train): 16.0%
GLM-5.3-Flash (Z.ai base, Z.ai post-train): 6.0%
Nex-N2.6 (Z.ai base, Nex post-train): 1.6%

Of the 14.4-point drop the launch post reports, 10.0 points are already there when Nex runs its suite on Z.ai's released model, before any Nex training. Nex's own contribution is the step from 6.0% to 1.6%, which is 4.4 points, or about a 73% relative cut. That is a real improvement on a model that was already good, and it's the number I would have led with.

Two cautions keep me from going further than that. The suite is built from failures Nex saw in real tasks, which presumably means mostly failures of Nex's own earlier models. A test set mined from model A's mistakes flatters any model that isn't A, so some of GLM's 6.0% may be that selection rather than a better base. And without sample sizes, the gap between 1.6% and 6.0% has no error bar. On a few hundred replays it would be clear; on fifty it would be a handful of traces.

Two bar charts from Nex's launch post. Overall non-repetition rate: Nex-N2.6 97.8%, Nex-N2.5-Mini 86.2%, Nex-N2.5-Pro 91.0%, GLM-5.3-Flash 96.2%. Reasoning repetition rate: Nex-N2.6 1.6%, Nex-N2.5-Mini 20.2%, Nex-N2.5-Pro 16.0%, GLM-5.3-Flash 6.0%. — Nex's repetition chart includes the GLM-5.3-Flash base at 6.0% and Nex-N2.5-Mini at 20.2%; the post's text cites only the Pro comparison. Internal checkpoint-replay suite, method unpublished (chart from @NexEcosystem's post on X, image 1).

What "100% valid tool selection" measures

The README defines it plainly: "Tool-list adherence checks whether generated calls use only the tools declared in the request." The thread's second post adds that "100% of its initiated tool calls avoided tools outside the available list", across 956 tested contexts.

So the test is this. A harness sends a request with a tools array: say read_file, bash, edit. The model emits a call. The call passes if its function name is one of those declared, and fails if the model invents str_replace_editor or computer because it remembers that tool from training on a different harness. Nex frames this as "harness cross-framework adaptation": the same model dropped into Claude Code, Codex or Cursor should call that harness's tools, not the ones it saw most during RL.

That failure is real and common. A model post-trained heavily inside one agent harness learns that harness's tool vocabulary, and in another harness it reaches for names that aren't there. The 82.2% for N2.5-Pro is a model that got the name wrong roughly once in every five or six contexts. Going to zero is worth having.

What the metric does not check is whether the call was any good. A model that answered every context with bash ls would score 100% wherever bash was declared. Right tool for the step, right arguments, and whether the episode finished are all outside it. The funnel below puts those gates after the one Nex measured.

selection vs success, 956 contextstask of 20 calls: 4.4% vs 0.2%

right tool, given a valid name: 90%arguments correct: 95%tool calls per task k = 20

top bar: Nex-N2.6, valid name 100.0%bottom bar: GLM-5.3-Flash, valid name 85.3%

Only the valid-name rates and the 956 contexts are Nex's numbers. The other gates are illustrative sliders, and the last row assumes calls fail independently with no retries, which overstates the damage of a bad tool name: a harness that rejects an unknown tool usually lets the model try again.

With the sliders at their illustrative defaults (90% right tool given a valid name, 95% correct arguments), one call succeeds 85.5% of the time for N2.6 and 72.9% for the base, whose valid-name rate was 85.3%. Compound that over a task of 20 calls with no retries and the whole task succeeds 4.4% of the time against 0.2%. The ratio looks dramatic and the model is unrealistic: harnesses reject an unknown tool name with an error, and models usually try again with a declared one, so an invalid name costs a turn more often than it costs the task. What the toy does show is that once names are valid, everything left is decided by the gates the metric doesn't see.

Three more things about the number itself:

Zero failures in 956 still has an error bar. With no failures in $n$ trials, the one-sided 95% upper bound on the true failure rate is about $3/n$ , the "rule of three". For $n = 956$ that is 0.31%. "100%" means "fewer than about one invalid call in 300, on this set".

956 may not be the denominator for every column. The chart shows N2.5-Pro at 82.22%, N2.5-Mini at 81.53% and GLM-5.3-Flash at 85.25%. If those were counts out of 956 they would be whole numbers of contexts. 82.22% and 85.25% are (786 and 815 out of 956), but 81.53% is not: 779 gives 81.49% and 780 gives 81.59%. Across all three, no denominator between 50 and 1,450 fits. So at least one column is averaged over repeated runs, or computed on a different count, such as only the responses that made a call. The "when with tools" row (N2.6 at 100.0%, N2.5-Pro 80.5%, GLM 84.1%) is presumably the latter, and its denominator is not given either.

"On par with GPT-6-Sol" means both scored 100%. On a metric with a ceiling, two models at the ceiling are tied by construction.

Two bar charts from Nex's launch post. Valid tool selection rate overall: Nex-N2.6 100%, Nex-N2.5-Mini 81.53%, Nex-N2.5-Pro 82.22%, GLM-5.3-Flash 85.25%, GPT-6-Sol 100%. When with tools: Nex-N2.6 100%, 79.95%, 80.56%, 84.11%, GPT-6-Sol 100%. — Valid tool selection measures whether a call names a declared tool, not whether the call was right. Two decimals on the rival bars make it possible to test the 956 denominator, and one of them fails it (chart from @NexEcosystem's post on X, image 2).

OSWorld and Terminal-Bench 2.1, read against their sources

Both benchmarks are execution-based, which is why they carry weight.

OSWorld puts an agent in a real virtual machine (Ubuntu, with Chrome, LibreOffice, GIMP, VS Code, Thunderbird and VLC) and gives it 369 tasks. The agent sees screenshots, and optionally an accessibility tree, and acts with mouse and keyboard. When it stops, a per-task script inspects the machine's final state: was the cell formatted, was the file saved, was the setting changed. The score is the share of tasks the scripts pass. When the paper came out, humans solved 72.36% and the best model 12.24%. The project site describes the July 2025 cleanup, OSWorld-Verified, and allows running 361 tasks when eight Google Drive tasks can't be configured.

Terminal-Bench 2.0 is 89 tasks, each in its own container with a human-written solution and a test suite; the agent works in a shell and the task passes if the tests do. Terminal-Bench 2.1 is the same suite after an audit found problems in roughly 30% of tasks. The repairs raised accuracy by more than 10 points, and the same paper shows that wall-clock limits alone can open or close a 20-point gap between harnesses for one model.

Every number in Nex's table is self-reported. I found no Nex entry in the OSWorld-Verified results file (1,077 rows). The Terminal-Bench site served only its current 4.1 board to a plain fetch, so I could not check the 2.1 board for one. The N2.6 README names no harness, no OSWorld variant, no step limit and no number of runs. The N2.5 card did: OSWorld-Verified through Nex's own NexCUA harness, Terminal-Bench through NexAU, sampled at temperature 0.7. Its N2.5-Pro numbers (82.2 and 82.7) match the N2.6 table. Its GLM-5.3-Flash number does not: the N2.5 card lists GLM-5.3-Flash at 62.3 on OSWorld-Verified, and the N2.6 README lists it at 78.0. Both are Nex's own tables, two months apart, and neither says how the GLM run was done. I can't tell which is the current setup, or whether it is the same setup at all.

Here is the README's table with the column the post left out:

Benchmark (Nex README)	GLM-5.3-Flash	DeepSeek-V4.1-Flash	Nex-N2.5-Pro	Nex-N2.6
OSWorld	78.0	71.7	82.2	83.0
Terminal-Bench 2.1	84.3	82.7	82.7	84.1
AutomationBench	48.8	54.8	44.2	45.7

Read against the base column, there is no published gain over GLM-5.3-Flash on Terminal-Bench (84.1 against 84.3) or AutomationBench (45.7 against 48.8), but those base numbers are Z.ai's, and the N2.6 numbers are Nex's, in setups the README doesn't name: the same cross-harness problem as the OSWorld comparison below. The OSWorld base number is Nex's, and it is 78.0 in one Nex table and 62.3 in the other. Against N2.5-Pro, the OSWorld gain is 0.8 points. On 369 tasks that is about three tasks. The binomial standard error of a single run at 83% on 369 tasks is about 2.0 points, and on Terminal-Bench's 89 tasks at 84% it is about 3.9 points, where one task is worth 1.1 points. Neither the OSWorld nor the Terminal-Bench gain over N2.5-Pro is distinguishable from a re-run.

Two bar charts from Nex's launch post. OSWorld: Nex-N2.6 83.0, DeepSeek-V4.1-Flash 71.7, GLM-5.3-Flash 78.0, Nex-N2.5-Pro 82.2. Terminal-Bench 2.1: Nex-N2.6 84.1, Nex-N2.5-Pro 82.7, DeepSeek-V4.1-Flash 82.7, GLM-5.3-Flash 84.3. — The GLM-5.3-Flash bar is the tallest in the Terminal-Bench panel, at 84.3; the post's text compares only against DeepSeek and N2.5-Pro. Self-reported, harness not stated (chart from @NexEcosystem's post on X, image 3).

The DeepSeek column

I checked each rival cell against the rival's own card.

GLM-5.3-Flash's 84.3 on Terminal-Bench 2.1 and 48.8 on AutomationBench match Z.ai's benchmark chart; Z.ai ran Terminal-Bench in Claude Code and AutomationBench v1.0.6, where the N2.5 card says Nex used NexAU and the "Public version".
DeepSeek-V4.1-Flash's 54.8 on AutomationBench matches DeepSeek's card, in the V4.1-Flash column.
DeepSeek-V4.1-Flash's 82.7 on Terminal-Bench 2.1 does not. DeepSeek's card reports 90.6 for V4.1-Flash, and its scaffold table puts the same model at 84.1 in Codex, 85.0 in OpenCode, 86.1 in Pi and 88.0 in Claude Code. The 82.7 sits one column over, under the older DS-V4-Flash. (I covered the card's scaffold spread in the V4.1-Flash 1017 piece.)
OSWorld 78.0 for GLM-5.3-Flash and 71.7 for DeepSeek-V4.1-Flash appear on neither vendor's card, so they are Nex's own runs in a harness it doesn't name (and the GLM one disagrees with the 62.3 in Nex's previous card).

I can't tell from the outside whether the 82.7 is a column copied from the wrong place or Nex's own rerun that happened to land on the same value. Either way, "ahead of DeepSeek-V4.1-Flash on Terminal-Bench 2.1" is not what DeepSeek reports. By DeepSeek's numbers, V4.1-Flash scores 84.1 or higher in every scaffold on its card, and ties N2.6 at worst.

The OSWorld comparison is a different kind of weak. A cross-lab comparison on a computer-use benchmark where both sides ran in the challenger's own harness, with no harness named, is a comparison of the harness as much as the models. NexCUA is not open source yet; the N2.5 card says it "will be open-sourced soon".

A harder eval: Google DeepMind's Multimodal Knowledge Agent

The same week, Google DeepMind put up a dataset that shows what a multimodal agent eval looks like when it grades outcomes instead of call names. The Multimodal Knowledge Agent showcase is ten tasks, Apache-2.0, about 1 GB, one per professional domain: a GIS analyst siting rooftop solar from LiDAR rasters and GeoJSON, an architect auditing floor plans against sections and elevations, an RF engineer deciding whether a chip can tape out, a biochemist, an M&A analyst, a historian working from medieval settlement maps, and four more. Each task is a workspace of 3 to 12 input files (PDFs, spreadsheets, decks, images, rasters) and a prompt of 40 to 845 words. The card's point is that the visual files can't be bypassed: no OCR or text extraction of the attachments gets you the answer.

The RF task is a good one to look at. The agent gets a block diagram of an interleaved RF digital-to-analog converter, an input and output spectrum, and a chart of sign-off limits. It has to name every external signal, classify each marked spur in the output spectrum by its architectural origin (harmonic, interleaving spur, Nyquist image, clock feedthrough), compute the gating specifications, and recommend APPROVED or REJECTED.

A schematic block diagram of an RF DAC: a baseband data interface with four ADC phases, a clock generation block with flip-flops and muxes, an interleaver combining 0/180 and 90/270 data streams, an external 16 GHz clock input with a 1:1 transformer, an RF-DAC core of binary-weighted unit cells, and an output match driving RF_out into 50 ohms. — One input of MKA's RF engineering task: the converter's block diagram. The agent has to read the four-phase interleaver and the 16 GHz clock path off the drawing to explain the spurs (Google DeepMind's MKA dataset, RF task input file block_diagram.png).

Two spectrum plots. The input spectrum over 16 GHz shows a single tone at 12 GHz near -17 dB. The output spectrum over 32 GHz shows the fundamental at 12 GHz and marked spurs near 4, 10.5, 16, 20.2, 24, 28 and 32 GHz. — The second input: input and output spectra with marked tones. The rubric expects each marked tone classified by origin, the 16 GHz tone as clock feedthrough and the 24.06 GHz tone as second harmonic (Google DeepMind's MKA dataset, RF task input file validation_spectrum.jpg).

Scoring is by rubric, and the rubrics are published. I counted 835 criteria across the ten tasks, from 48 for the RF task to 134 for the policy deck. Each has a weight from 1 to 5 (236 at weight 1, 244 at 2, 194 at 3, 110 at 4, 51 at 5; 2,001 in total) and a grading target naming the deliverable to inspect: a slide deck for 452 of the criteria, a spreadsheet for 90, JSON for 85, a Word document for 62, the final message only for 98. The RF criteria include "Calculates, in Section 2, a single IRR value of 84.98 dBc (acceptable range 77.98 to 91.98…)" and "States, in Section 4, a tape-out recommendation of REJECTED", next to formatting checks like "Contains zero asterisk characters in the response".

Two limits. The card publishes no aggregation rule, no judge and no scores for any model, so this is a showcase of the format, not a leaderboard. And formatting criteria sit beside the engineering ones at weights of 1 or 2, so instruction-following counts for something in the total. Still, compare its unit of evidence with Nex's. MKA asks whether a 16 GHz spur was classified as clock feedthrough and whether the converter should tape out. Nex's tool metric asks whether the function name was on the list. The first is what you'd want to know before trusting an agent with a schematic; the second is a precondition for even being graded.

Running it

The weights are FP8, 328 GB on disk, and want an inference runtime with GLM-5.3-Flash support. The README points at SGLang's GLM-5.3-Flash cookbook with an FP8 configuration and the shipped tokenizer and template:

curl -N http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Nex-N2.6",
    "messages": [{"role": "user", "content": "Write a Python function that checks whether a string is a palindrome."}],
    "reasoning_effort": "max",
    "max_tokens": 8192,
    "stream": true
  }'

generation_config.json sets temperature 1.0 and top-p 0.95; OpenRouter's defaults are 0.7, 0.95 and top-k 40, matching the sampling the N2.5 card used for its evals. Given the repetition literature above, sampling settings are part of any repetition number, and the N2.6 README doesn't say which ones produced 1.6%.

If you already serve GLM-5.3-Flash, N2.6 is a weight swap behind the same runtime, and the honest way to evaluate it is in your own harness against the base. On OpenRouter the price is $0.12 in and $0.40 out per million tokens.

Use it for tool names, not for the benchmark gains

Nex-N2.6 is a reasonable agentic post-train of a strong base, released with open weights under Apache-2.0. The tool-name result is the most useful thing in the release: a model that never calls an undeclared tool is easier to move between Claude Code, Codex and a homegrown loop, and getting a GLM base from 85.3% to 100% on that is work someone had to do.

The launch post oversells it by choosing its comparisons. Most of the repetition headline was already in the base model's column; the step Nex can claim is 6.0% to 1.6%, on a suite nobody outside Nex can run. The benchmark headline leaves out that the base model's own published numbers on Terminal-Bench 2.1 and AutomationBench are at or above the fine-tune's, and quotes a DeepSeek Terminal-Bench score that DeepSeek's own card puts 7.9 points higher. Neither the OSWorld nor the Terminal-Bench gain over N2.5-Pro is larger than one run's noise.

If you run GLM-5.3-Flash in a harness where it calls tools that aren't there, try N2.6; that is the problem it was built for. If you want a better computer-use or terminal agent than GLM-5.3-Flash, nothing published shows this is one.