Nanbeige4.3-33B explained: a 512K-context open-weight model for coding and office agents

Nanbeige4.3-33B focuses on agent workflows that involve reasoning across multiple turns, calling tools and delivering working results. Its reported terminal, coding and office-automation results are interesting, but they do not establish a clean sweep across benchmarks or effortless 512K operation on a consumer GPU.

This article is based on the official model card and configuration available on October 26, 2026. All benchmark scores below are reported by the developer, not independently measured by TboxIO. Memory calculations are estimates, not hardware tests.

A teacher model first, smaller agents later

Nanbeige positions the 33B model as the flagship teacher for the Nanbeige4.3 series. The plan is to build a capable coding and professional cowork agent, then distill those capabilities into smaller models. Nanbeige4.3-3B is mentioned as a future direction; that does not mean it has shipped with this release, or that it will inherit the 33B model's scores.

The focus goes beyond answering questions: understanding a task, working with repositories, executing tools, reading feedback and revising a solution. That makes it a candidate for teams evaluating self-hosted coding and office assistants.

Item	Official information and interpretation
Model	Nanbeige4.3-33B
Size and architecture	Approximately 33B parameters; dense LlamaForCausalLM configuration
Maximum context	524,288 tokens, or 512K
Released weights	BF16
License	Apache 2.0
Main focus	Agentic coding, tool use and professional cowork tasks
Official runtime examples	Transformers, SGLang and vLLM
Thinking	Enabled by default; configurable in the chat template

This dense 33B model should not be budgeted as though it were an MoE model that activates only a small subset of experts per token. A 512K context limit describes capacity, not a guarantee of unchanged quality or speed at every length and on every device.

Benchmarks: strong agent results, with clear exceptions

The developer compares it with Qwen3.8-27B, Muse-Glimmer-30B and Gemma4-31B. The card says all models use their highest thinking effort, with the same inference hyperparameters and harness within each benchmark. These are selected original scores.

Benchmark	Nanbeige4.3-33B	Qwen3.8-27B	Muse-Glimmer-30B	Gemma4-31B
Terminal-Bench 2.1	80.9	73.0	61.8	47.2
Terminal-Bench 4.0	23.8	6.3	1.6	0.0
DeepSWE	65.5	42.5	4.4	2.7
SWE-Bench Pro	60.3	61.7	36.9	51.2
SWE-Atlas-QnA	50.8	41.9	17.7	3.3
NL2Repo	53.0	48.3	27.4	33.8
SkillsBench	61.1	56.4	39.7	28.9
Automation Bench	54.2	38.3	15.2	9.7
JobBench	44.8	34.5	16.6	9.0
GDPval	84.8	86.4	75.8	71.4
Claw-Eval pass^3	78.3	75.2	57.3	44.2
Toolathlon-Verified	70.4	68.5	47.2	27.8
GPQA Diamond	89.5	89.2	83.5	91.3
AIME 2026	95.2	94.5	94.7	89.2
AA-LCR	84.0	82.0	83.3	72.0

• Terminal and coding tasks stand out: Nanbeige exceeds Qwen3.8-27B by 7.9 points on Terminal-Bench 2.1 and 23.0 on DeepSWE. Its 23.8 on Terminal-Bench 4.0 also shows that difficult tasks remain far from solved.
• Office workflows look promising: the margins over Qwen are 15.9 points on Automation Bench and 10.3 on JobBench. These are results under a specific evaluation workflow, not predicted success rates for a company's production processes.
• Qwen still leads some tasks: Nanbeige scores 60.3 versus 61.7 on SWE-Bench Pro, and 84.8 versus 86.4 on GDPval.
• Reasoning is not a universal win: GPQA Diamond is 89.5, slightly above Qwen's 89.2 but below Gemma4-31B's 91.3. A 0.3-point difference should not be presented as a robust overall advantage.

These are score differences within this table, not gains over the previous Nanbeige generation. The cited card does not provide a complete, controlled previous-generation comparison. Comparisons with our DeepSeek, MiniMax, Kimi and Raon articles also require matching benchmark versions, agent harnesses and reasoning budgets.

The evaluation conditions matter

Agent results depend on the model, tools, execution environment, context strategy and retry budget. Several official footnotes materially affect interpretation:

1. Nanbeige is evaluated with preserve_thinking=true. Removing earlier reasoning during integration can change multi-turn agent behavior.
2. Terminal-Bench 2.1 uses Terminus 2. Terminal-Bench 4 and DeepSWE use mini-swe-agent v2.4.6. Scores from different Terminal-Bench versions should not become a single cross-article ranking.
3. SWE-Atlas-QnA uses mini-swe-agent v2.4.6, with GPT-6 Sol at medium reasoning effort judging against 1,304 task-specific rubrics. NL2Repo uses Claude Code; JobBench uses a Claude Code harness equipped with search.
4. Automation Bench v1.0.6 contains 600 public tasks. Claw-Eval covers only the General subset of 157 single-turn interaction tasks, and its metric is pass^3; retain that qualifier.
5. GDPval uses revised rubrics, so 84.8 is not an Elo score. Toolathlon-Verified imposes no per-request max_tokens limit; actual token consumption matters when comparing costs.

The developer also reports $1,025,437 on YC-bench. That is a dollar-denominated benchmark outcome, not API pricing, actual revenue or a promise of earnings. It should not be averaged with percentage-style scores.

Thinking and tool use: two different switches

The template exposes enable_thinking and preserve_thinking. The first controls reasoning for the current response; it is enabled by default and can be set to False for non-thinking mode. The second controls whether previous assistant reasoning is retained. The developer recommends False for general chat and Q&A, and True for multi-turn tool use, office tasks and coding agents.

For tool calls, the recommended format is tool_call_format="xml"; json is supported for compatibility. The chat template, tool parser and handling of historical reasoning must agree. Swapping the model name alone does not reproduce the reported setup.

Scenario	Temperature	Top_p	Recommended Max New Tokens
Agent and tool-use tasks	1.0	0.95	65,536
Reasoning and chat	0.6	0.95	262,144

Max New Tokens is an output budget, whereas 512K is the context limit. Inputs, retained reasoning, tool results and new output must fit the serving configuration. A large output allowance does not mean every request actually produces that many tokens.

Deployment: roughly 66GB of BF16 weights, plus cache

The official file list totals approximately 66.3GB and provides BF16 Safetensors weights. At two bytes per parameter, 33B parameters imply roughly 66GB in decimal units for weights alone. KV cache, runtime buffers and framework overhead come on top. Repository size is not total runtime VRAM demand.

The official configuration has 52 layers, eight KV heads and a head dimension of 128. A straightforward BF16 KV cache for one fully occupied 524,288-token sequence would require approximately 104GiB, counting both keys and values. This is a theoretical calculation from the configuration, not an official hardware measurement. Cache precision, tensor parallelism, offloading and runtime strategies affect the actual footprint.

Supporting 512K therefore does not establish easy full-context operation on a typical consumer card. Quantization can reduce weight memory, but conversion quality, runtime support and long-context behavior still need validation. We have not tested quantized variants, Mac performance or tokens per second on consumer GPUs.

The official SGLang and vLLM examples use four-way tensor parallelism, the qwen3 reasoning parser and qwen3_coder tool-call parser. That is an example, not a universal minimum GPU count. Size the deployment using your input length, concurrency, time to first token and output-speed requirements.

Who should evaluate it?

Teams building self-hosted coding agents, tool-driven office workflows or teacher-to-student distillation pipelines have a reason to include this model in their shortlist. Apache 2.0 provides a clear licensing basis, with distribution subject to its terms.

For everyday chat, low latency or limited VRAM, the cost of a dense 33B model deserves attention. The model card does not provide an official API unit price or a unified throughput test suitable for a production budget. Open weights do not remove GPU, storage or maintenance costs.

Use representative repositories and office tasks in a small evaluation, recording completion rates, tool errors, token consumption, latency and required human corrections. Test file-changing or business-system tools in an isolated environment first.

TboxIO's assessment: the appeal is capable coding and office-agent behavior in a self-hostable 33B model. The developer's results justify evaluation, not claims that it wins every task or always costs less to run.

Sources

• Official model card: positioning, results, footnotes and runtime guidance
• Official config.json: architecture, layers, KV heads and context
• Official file list: BF16 weights and repository size