Unsloth v0.1.910-beta Released: Flint Coding Agent, MOSS-Image, and NVIDIA Bolt E4B Now Runnable Locally

Unsloth's latest release, v0.1.910-beta, bundles three notable new models alongside a batch of substantive improvements to local inference, fine-tuning, and the desktop experience. From a 40B coding-agent MoE to a 5.1B text-to-image model to NVIDIA's tool-calling fine-tune, this update pushes the boundary of "running frontier models on consumer hardware" a bit further.

Three New Models: From Code Agents to Image Generation

Flint: A 40B MoE Coding Agent That Runs on 24GB of VRAM

Recursive's Flint is a 40B MoE model aimed at coding agents, with only 2.5B activated parameters, support for reasoning, tool calling, and a 256K context. The official score on SWE-bench Pro v2 is 89.7, a clear advantage over Qwen 3.6's 73.8. Under 3-bit quantization in short-context scenarios, Flint fits into 24GB of VRAM—meaning a single consumer-grade GPU can host a genuinely usable coding agent.

For local development, the significance of this combination is that coding agents used to depend on cloud APIs; now the model, the tool-calling loop, and the context can all stay on the local machine, giving you more control over privacy and latency.

MoE (Mixture of Experts) is a sparsely activated model architecture: the model contains multiple parallel "expert" subnetworks, and on each forward pass a routing network selects only a few of them to participate. As a result, the total parameter count (e.g., 40B) and the actually activated parameter count (e.g., 2.5B) can differ by an order of magnitude, and inference compute cost is calculated based on activated parameters rather than total parameters. This is also the key to Flint running on consumer-grade GPUs—VRAM still needs to hold most of the weights (which can be compressed via quantization), but the compute consumed per generated token corresponds only to a 2.5B scale. The cost of MoE is high VRAM usage, sensitivity to bandwidth, and potentially degraded routing efficiency at small batch sizes or when the task distribution shifts.

3-bit quantization refers to compressing model weights from 16-bit floating point to roughly 3-bit precision for storage, reducing VRAM usage to about one-fifth of the original, at the cost of precision loss that is usually more pronounced on long-context and complex reasoning tasks. The article specifically emphasizes "short-context scenarios" precisely because the longer the context, the more extra VRAM overhead such as the KV cache eats into the space originally reserved for weights.

MOSS-Image: A 5.1B Text-to-Image Model with Chinese and English Text Rendering

OpenMOSS's MOSS-Image is a 5.1B image model focused on high-quality generation, available in both SFT and Base versions. It can render English or Chinese text within generated images, a weak spot for many open-source image models. On resource requirements, it runs on a 16GB GPU, and the team has also released a GGUF version so Macs and machines without a supported GPU can run it too.

Combined with the multi-GPU splitting capability in this update, image and video models that previously didn't fit on a single card can now be split across multiple NVIDIA GPUs instead of falling back to system-memory streaming. In addition, the new Hires fix implements one-step upscaling and refinement for SDXL, FLUX.1, Qwen-Image, and Z-Image.

GGUF is the model file format used by the llama.cpp ecosystem, packaging weights, quantization parameters, and metadata into a single file and optimized for non-CUDA environments such as CPUs and Apple Silicon's unified memory. It does not map one-to-one to PyTorch's safetensors format and usually requires conversion and requantization, so the same model often ships with both original weights and GGUF versions at multiple quantization levels. For Mac users, GGUF means local inference directly via the Metal backend; for machines without a supported GPU, it can run purely on CPU, just more slowly.

Hires fix (high-resolution fix) is a standard post-processing pipeline in image generation: first generate a low-resolution image to establish composition, then upscale the image and redraw details to avoid the composition collapse and VRAM blowup that come from sampling directly at ultra-high resolution. The one-step upscaling and refinement mentioned here compresses a multi-step upscale-plus-redraw pipeline into a single step, an optimization of sampling efficiency.

NVIDIA Nemotron 3.5 Bolt E4B: A Major Boost to Tool Calling

NVIDIA's Nemotron 3.5 Bolt E4B, fine-tuned from Gemma 4 E4B, is a reasoning version aimed at tool calling and instruction following. According to Unsloth's release notes, it beats the original Gemma 4 E4B on 16 of 21 NVIDIA tests, with gains concentrated in tool use and multi-turn dialogue. The Tau2-Bench score is 63.2 versus 38.7 for the original—a substantial gap.

One detail worth noting: the previously crashing DPO training issue for Gemma 4 E2B and E4B (including the Nemotron version) has also been fixed.

MoE Inference on Mac: Putting Experts on SSD

One of the most practical performance improvements in this update is how MLX MoE models handle insufficient memory: expert weights that exceed memory are kept on the SSD, at the cost of slower responses. According to the release notes, Qwen3.8-Flash-Next can run on a 32GB Mac, and DeepSeek^Ad-V4-Flash and GLM-5.3-Flash require far less memory than their parameter counts would suggest.

This path is not without cost—SSD reads and writes slow down generation—but it changes a premise: model size is no longer hard-capped by unified memory capacity. For developers who want to experiment with large MoE models on a Mac, this is a low-cost entry point.

MLX is Apple's array computing and machine learning framework for Apple Silicon, leveraging the unified memory architecture so that the CPU and GPU share the same memory without explicit copying. The benefit of unified memory is that it eliminates transfers between host and VRAM, but it also means model weights share the same capacity limit with the system and other applications.

Keeping expert weights that exceed memory on the SSD and swapping them in on demand is essentially an expert-level paging/offloading strategy: since MoE activates only a few experts at a time, the volume of data swapped in and out is relatively manageable, but SSD sequential and random read/write bandwidth is far lower than unified memory, so once the hit rate drops, generation speed slows noticeably. The actual experience of this path depends heavily on the model's routing locality—if adjacent tokens repeatedly activate different experts, thrashing becomes severe. This also explains why the article positions it as a "low-cost experimentation entry point" rather than a production solution.

Fine-Tuning and Training: REAP Expert Pruning and an OpenAI-Compatible API

MoE Expert Pruning: Cutting 25% or 50%

The Export page on Windows and Linux now supports using REAP to prune the 25% or 50% least-used experts in MoE models, at the cost of some quality loss. The Python-side reap_prune is said to be up to 54x faster than the llm-compressor implementation. For teams looking to compress large MoEs onto local hardware, this is a direct engineering tool.

REAP (Router-weighted Expert Activation Pruning) is a class of expert-level structured pruning methods for MoE models: it measures each expert's routing weight and activation frequency on calibration data to estimate each expert's contribution to the output, then removes the lowest-contributing experts wholesale. Unlike element-wise sparsification, pruning entire experts directly reduces the model's total parameter count and VRAM usage and does not require special sparse inference kernels; the cost is that the routing distribution is altered and the capabilities originally handled by removed experts degrade, so a small amount of retraining or calibration is usually needed to recover quality.

Note that the relationship between pruning ratio and quality loss is not linear: 25% is often relatively safe, while 50% may significantly affect performance in specific domains. In practice, it's advisable to evaluate with a calibration set close to the target use case rather than relying only on general benchmarks.

Training Efficiency and Interface Compatibility

Changes on the training side are dense: DPO and other training that requires sequence padding is up to 3.8x faster on NVIDIA Ampere and newer architectures, with lower memory usage; training Qwen3-MoE, Gemma 3, and Gemma 4 on GPUs that don't support bf16 reduces attention memory usage by up to 7x (requires torch 2.13 or earlier). On the speech model side, training memory for Parakeet, Canary, and CTC is reduced by up to 55%.

At the interface level, Unsloth now supports OpenAI's fine-tuning API, so you can use the OpenAI SDK to upload datasets and run supervised fine-tuning on local models. The unsloth train command has also been extended to vision models, and audio models are available on non-Mac platforms.

Desktop: Chat-Only Installation and Security Fixes

On first launch, Unsloth Desktop now offers a "chat-only (GGUF)" installation that is significantly smaller, with training features installable later from settings. The Chat page in settings can now view, edit, clear, or disable the memory notes sent to the model with each conversation; in document-retrieval conversations, Show passages lists the actual source text the model received and can jump to the corresponding page.

One security note to be aware of: Unsloth's installer, updater, and pip install -U unsloth now reject eMudhra's compromised emSign certificates—certificates that could be used to impersonate websites. However, the optional vLLM and SGLang engines still trust these certificates. Additionally, requests carrying an Unsloth API key can no longer run Python and terminal tools without a sandbox; only the Unsloth UI can grant full access.

Summary

The throughline of this update is clear: keep lowering the bar for "it runs." Flint brings coding agents into the 24GB VRAM range, MOSS-Image lets 16GB GPUs do image generation with text rendering, and NVIDIA Bolt E4B fills in the tool-calling gap for small models. Together with SSD expert offloading, REAP pruning, and the OpenAI-compatible fine-tuning API, the feasibility of local AI workflows has moved up another notch. The real limitation may no longer be hardware, but how much speed you're willing to trade away.