Nanbeige, Flint and Bolt: Which Local Agent Model Fits?

If you run coding or voice agents on hardware you own, the last week of October 2026 handed you three new choices at once, and they do not compete on the same axis. Nanbeige4.3-33B, uploaded to Hugging Face on October 24, is a dense model: every one of its 33 billion parameters works on every token. Recursive Flint, released October 21, is a mixture of experts: 39.8 billion parameters on disk, roughly 2.5 billion in use per token. Nemotron 3.5 Bolt E4B, dated October 23 on its card, is a compact model from NVIDIA with 8 billion parameters stored and about 4 billion effective, aimed at spoken assistants rather than repositories.

Those three shapes mean three different bills for the same machine. A dense model pays in memory bandwidth on every token. A mixture of experts pays in memory capacity, because the inactive experts still have to live somewhere. A compact model targets a smaller storage and compute budget, leaving potential headroom for the speech models and applications that have to share the device with it. This post works through those bills using the numbers each vendor published: total and active weights, file sizes, context limits, hardware guidance, licence text and the tool-calling contract each card documents.

Two boundaries. We covered Recursive's claims about how Flint was built, and the evidence behind them, in our Flint research-and-access guide; this post treats Flint only as a deployable artefact. And this is a comparison of three newly available checkpoints, not a rewrite of our broader hardware-matching guide for open coding models, which still covers the older candidates these three now sit beside.

Dates matter here because two of the three had no launch post we could find. Nanbeige4.3-33B exists as a Hugging Face repository created on October 24, 2026 by the Nanbeige LLM Lab, with a card that calls it the flagship teacher model for a 4.3 series and promises a 3B distillation later. We found no separate dated announcement or hosted endpoint in the cited material, so October 24 identifies the weight-repository record rather than a verified announcement date. Flint has a card, a launch post and documentation, all dated October 21. Bolt's card gives October 23 for both Hugging Face and NVIDIA's own catalogue, although its repository was created on October 5.

One example of why that matters: Bolt's repository name promises a 4 GB quantised file, and the card calls it the Q4_K_M version. The repository listing we read on October 26 shows that file at about 6.2 GB. Neither figure is the runtime memory, but a buyer sizing a device from the repository name would be out by half. Read the file list, not the name.

A costly sizing mistake with mixture-of-experts models is reading the active count as the memory requirement. A mixture-of-experts layer holds many small expert networks and routes each token through a few of them. Flint's card spells this out: 47 of its 49 layers are mixture-of-experts layers, each with 256 routed experts of which 6 are selected per token plus one shared expert that always runs. The 2.5B active figure counts the parameters that participate in one token's forward pass, including the output head; the 39.8B total describes all stored parameters. A runtime may keep them resident or offload some of them, trading memory placement against transfer costs.

Nanbeige is the opposite case and the simpler one. Its configuration file describes a standard dense decoder: 52 layers, a 7,168-wide hidden state, 56 attention heads sharing 8 key-value heads, and a 166,912-token vocabulary. All 33.12 billion parameters work on every token. That is why a dense model of this size tends to be slower per token than a mixture of experts with a similar total, and why Recursive's blog can claim its model runs several times faster than dense models of 25 to 40 billion parameters. The speed claim is Recursive's; the structural reason behind it is in both cards.

Bolt uses a third convention. NVIDIA describes it as 8B total with 4B effective parameters, following the naming of Google's Gemma 4 E4B, the model it was post-trained from. The card does not define the convention, so we read it the way the benchmark table does: the BF16 safetensors in the repository total about 8 billion parameters, and NVIDIA compares the model against 4B-class alternatives. For memory, use 8B. For a sense of per-token work, use 4B.

The published artefacts give the floor directly. Nanbeige ships only BF16 safetensors, fourteen shards totalling about 66 GB in the repository listing; the card's serving examples split the model across four GPUs. Flint's BF16 download is described on its card as about 80 GB and needs one B300 or H200 per replica with the supplied SGLang kit, but Recursive also published an int4 safetensors checkpoint and two GGUF files, int4 at about 26 GB and NVFP4 at about 23 GB. Bolt's BF16 is about 16 GB by parameter count, and its Q4_K_M GGUF is about 6.2 GB.

Those are file sizes, and Recursive's setup guide is blunt about the gap between a file and a running process: the download is only part of runtime memory, and you must leave room for the key-value cache, compute buffers, the operating system and whatever else is running. The key-value cache is the part people forget. It grows with every token in the context, and for a dense model with many layers it grows fast.

Our arithmetic from Nanbeige's configuration, for a worked example: 52 layers, 8 key-value heads, a head dimension of 128, keys and values both stored, two bytes per value in BF16. That is about 213 KB of cache per token. At 131,072 tokens of context the cache alone is roughly 28 GB; at the full 524,288 it is roughly 112 GB, more than the weights. Runtimes that quantise the cache or page it out change those numbers, which is exactly why the figure is an estimate and not a measurement. A failure case follows directly: a machine that loads Nanbeige comfortably at 4-bit can still run out of memory the first time an agent loop fills a long context.

Each card states a context limit, and each limit means something slightly different. Nanbeige supports up to 524,288 tokens, and its recommended settings tell you how the lab expects that to be used: agentic and tool-use tasks at temperature 1.0 with a 65,536 maximum output, reasoning and chat tasks at temperature 0.6 with a 262,144 maximum output. The model thinks by default, and a second template switch keeps earlier reasoning in the conversation, which the card recommends for multi-turn tool use and coding agents and discourages for ordinary chat.

Flint's documented configuration is 262,144 tokens including prompt and generated output, with the hosted configuration allowing up to 65,536 output tokens. The documentation adds a sentence worth keeping: the hosted limit is not a local memory guarantee. Locally, you use whatever your runtime is configured for, and the card's limitations section says the context configuration is a capacity limit, not a guarantee of uniform accuracy across lengths. Recursive's own blog recommends staying within 256K for best results even where 512K is reachable.

Bolt is 64K in and 64K out. That can accommodate substantial conversation history; repository work still needs context selection and evaluation rather than a verdict based on the window alone. It is also only the text stage of a voice system: the transcription and speech models that sit around it, such as the Voxtral 3 speech components we covered separately, have their own memory and latency budgets. The worked example here is a voice assistant that also has to run a transcription model and a speech model on the same device: Bolt's card describes it as designed for low memory and fast time to first token so that agents respond quickly while leaving headroom for adjacent model pipelines. Its stated target is conversational assistants; bounded coding tasks remain a separate evaluation question.

The three vendors give very different amounts of hardware guidance. Recursive gives the most. Its setup page lists eight starting points by environment: its own Mac engine, which needs an M4 Pro, M5 Pro or M5 Max with at least 48 GB of unified memory and configures a coding harness automatically; desktop runners such as Ollama and LM Studio; llama.cpp builds for Apple Silicon and for NVIDIA GPUs on Linux or WSL2; Transformers, SGLang and vLLM for GPU serving; and a partner endpoint for hosted access. The page asks you to keep model revision, runtime commit and configuration together when reporting results.

Nanbeige gives the least. The card's serving commands for SGLang and vLLM both use tensor parallelism across four GPUs and a reasoning parser borrowed from the Qwen3 family, which tells you the lab's own deployment target is a multi-GPU node rather than a laptop. Nothing on the card documents a 4-bit single-GPU build; a team using another quantisation on a workstation needs to check its source, runtime support and behaviour separately.

Bolt sits between them, as the smallest member of the same Nemotron 3.5 family whose Lightning 30B-A3B tier we covered in August. The BF16 card targets vLLM on a single H100 or A100 and says plainly that the full-precision release is intended for customisation and post-training rather than direct production inference; the quantised GGUF is the one meant for devices, and its card marks the llama.cpp recipe as pending as of the date we read it. Recursive's blog quotes more than 125 tokens per second on an M4 Pro MacBook Pro with its own engine at short contexts; that is a vendor measurement of the easy case.

Nanbeige4.3-33B and Flint are both released under Apache 2.0 according to their cards and repository metadata, which makes them the simplest case: commercial use, modification and redistribution are permitted with attribution and notice retention, and there is no revenue threshold. Flint's card adds one line worth repeating, that the hosted API's terms and data practices are separate from the weight licence. Running the weights yourself is governed by Apache 2.0; using Recursive's partner API is governed by whatever agreement that partner signed.

Bolt is governed by the OpenMDW License Agreement version 1.1, and we read the text rather than the badge. It grants permission to use the model materials without restriction under copyright, patent, database and trade-secret rights; requires distributors to keep the agreement and notices of origin; ends the grant for anyone who sues over the materials for patent or copyright infringement, unless responding to a suit; and places no restrictions on outputs. It disclaims all warranties and leaves third-party rights clearance to the user. NVIDIA's card says the model is ready for commercial or non-commercial use.

The clause people miss is the base model. Bolt's card states that it was post-trained on Google's Gemma 4 model and that use of the Gemma 4 model is governed by the Apache License, Version 2.0. That is NVIDIA's characterisation of the base licence, and we print it as such; a compliance team should confirm it against Google's own terms for the Gemma 4 E4B checkpoint before shipping. For how these terms compare with the rest of the open-weight field, our open-weight licence audit holds the longer table.

A local model is only an agent model if a harness can call tools through it reliably, and the three cards document three different contracts. Flint's is the most conventional: OpenAI-compatible tool calls through the checkpoint's chat template, reasoning always on, and an instruction to preserve the returned reasoning content in the conversation history. The card recommends an output budget of at least 32,768 tokens for hard problems because reasoning and answer share it, and warns that long reasoning can exhaust the budget before an answer appears. If a response ends with a length finish reason, the docs say, raise the budget or shorten the conversation.

Nanbeige's contract lives in template switches. Passing tools enables the tool-use template; the card recommends an XML tool-call format for best performance with JSON supported for compatibility. The thinking switch is on by default, and the preserve-thinking switch, which keeps earlier reasoning across turns, is the one the lab used in its own agent evaluations. A harness that strips reasoning between turns, as many do to save context, is running the model in a mode its vendor evaluated for chat rather than for agents.

Bolt's contract is the most specific, because it was written for interactive assistants. Tools go through the native tools array and actions come back in tool-call fields. The chat template does not accept a tool result that is not immediately preceded by the assistant's tool call, so the card documents a workaround for slow tools: acknowledge the call at once with a pending result, keep talking, then deliver the real result later as a labelled user message. There is a runtime thinking budget implemented as a two-step client, and a conversational mode that trims formatting for spoken replies. A team that does not need any of this should notice how much of Bolt's post-training went into exactly these behaviours.

All three cards carry benchmark tables, and all three are the vendor's own runs. That does not make them useless; it makes them evidence of intent rather than of rank. Nanbeige's table compares it with three models the lab chose at around 30 billion parameters, all at their highest thinking effort on one harness, and it is unusually honest: the model trails Qwen3.8-27B on SWE-Bench Pro and on GDPval and trails Gemma 4 31B on GPQA Diamond, while leading comfortably on terminal and automation tasks. Read as a profile, that says the lab optimised for long agentic loops in a shell and for office-style work, which matches its own description.

Flint's card reports 54.9% on Terminal-Bench 2.1, 89.7% on SWE-bench Pro v2 and 74.2% on SWE-bench Verified, with the footnote that Terminal-Bench solutions obtained through web retrieval were counted as failures and that other vendors' scores may not apply the same adjustment. Nanbeige's card reports 80.9% on Terminal-Bench 2.1. Both name the Terminus 2 harness, but Recursive reports an average over at least five attempts and counts retrieved solutions as failures, while Nanbeige's card states neither its attempt count nor how it treated web retrieval. Printing the two numbers side by side as a ranking would be exactly the mistake Recursive's footnote warns against.

Bolt's table is the most interesting failure case for anyone shopping by headline. NVIDIA measured four 4B-class models on one harness and bolded the best in each row; Bolt wins most of the instruction-following and role-play rows, but Qwen3.5 4B is well ahead on Tau2-Bench and on the long-context RULER row, and Gemma 4 E4B tops the EQ-Bench row and one quantised tool row. A voice assistant that needs multi-step tool reliability above all might read that table and pick a different model.