Unsloth v0.1.913-beta Released: Custom Backgrounds, Doubled Performance, and an Upgraded Local LLM Experience

Unsloth has released version v0.1.913-beta, and the keywords for this update are "personalization, performance, and interface experience." In the release notes, the team explicitly states that the new version lets users "Make Unsloth your own," while significantly shortening app update times, improving Linux performance, and accelerating Qwen-Image generation under limited VRAM. In addition, DeepSeek^Ad-V4.1-Flash-1017 has been introduced to Unsloth, and the accompanying Unsloth Dynamic v3.1 GGUFs are now available as a preview.

For users who deploy LLMs locally, fine-tune models, and run multimodal generation, this update spans the chat interface, image and video rendering, the training API, and underlying performance optimizations—making it a fairly dense iteration.

Personalization and Interface: From Backgrounds to Chat Box Layout

The most visible changes in this update are at the interface level. Unsloth adds a custom background feature that lets users personalize the chat interface, and the team teases that "more customization options are coming next week." The app also adds support for 14 languages, broadening its reach.

In terms of interaction details, several changes point toward a "cleaner, more consistent" experience:

• You can move the chat box to the bottom in "Settings > Chat," making the new chat page closer to the layout of common chat apps;
• Greetings can be fully hidden, making the new chat interface cleaner;
• Chat cards in the Library are shorter, tooltips are clearer, and sort and filter icons share a consistent style;
• You can drag a filled input-slot image onto an empty slot to duplicate it;
• Pinned models persist after Unsloth Desktop restarts;
• Each browser tab retains its own unsent message draft.

Individually, none of these changes are groundbreaking, but together they address a long-standing problem with local AI tools: the interface feels like lab software. Unsloth is clearly moving toward a more mature desktop app experience.

Performance Optimizations: Update Times Halved, Long Replies No Longer Stutter

Performance gets the most attention in these release notes. The team says that by skipping Python precompilation, app update times are cut by about half, at the cost of a slightly slower first launch after updating—consistent with behavior before v0.1.912.

For streaming chat output, long replies now render more smoothly even when math formatting is not yet complete. The team's measured example: parsing an 83 KB reply containing a stray $$ dropped from 71 seconds to 0.7 seconds. An improvement of this magnitude comes primarily from linearizing the Markdown parsing path, indicating a clear performance bottleneck in the previous implementation.

Other performance figures include:

• Peak memory when previewing a 1 GB local Parquet file dropped from 1.5 GB to about 300 MB;
• On Linux + NVIDIA + X11 + driver 610+, tested frame rates for scrolling long chats rose from about 17 fps to 60 fps;
• With VRAM limited to 16 GB, Qwen-Image rendering is up to 2x faster, and Qwen-Image-Edit-2511 is about 1.3x faster;
• In memory-constrained NVIDIA tests, MiniMax-H3 video clips completed about 1.7x faster.

Unsloth also stays responsive while models load, preventing the interface from freezing during Transformers and MLX model loading.

GGUF is the model file format used by the llama.cpp ecosystem, typically a single-file package of quantized model weights (e.g., 4-bit, 8-bit) that can be loaded on consumer hardware. Unsloth Dynamic GGUFs is Unsloth's custom improvement to quantization: instead of applying a uniform bit width across the whole model, it dynamically selects precision per layer or per tensor based on sensitivity, keeping more critical weights at higher bit widths to reduce accuracy loss at the same file size. "Dynamic v3.1" is the third major iteration of this quantization scheme; the "size-accuracy lead" mentioned in the article means better benchmark performance at the same file size, but as a preview release it still needs independent verification.

Image, Video, and Low-Spec Device Support

On the multimodal side, FLUX.2-klein-9B can now load and render on Linux with 12.7 GB of system memory plus a supported GPU. The team notes that its diffusion module spills the int8 denoiser to scratch files, allowing machines with limited memory to run larger image models.

There is progress on audio as well: on MLX, sending a voice clip to LFM3-Audio or LFM3-Omni now returns both a text answer and a voice answer.

Training and API: Batched MoE Fine-Tuning

A key training update: compatible LoRA and QLoRA jobs on MoE models can now be trained together, such as Qwen3.6-35B-A3B, with each job having its own adapter. In Studio, Unsloth assigns an independent fp16 loss scale to each batched fine-tuning job and lets each job use its own expert LoRA.

The "Train" page adds a "Use via API" entry that generates Python, JavaScript, and curl examples based on the user's configuration. Single-column text datasets are now detected automatically, with no manual column mapping required.

MoE (Mixture of Experts) is an architecture that splits a model into multiple "expert" subnetworks and activates only a few of them at a time. Compared with a dense model of the same parameter count, MoE activates fewer parameters during inference, so it can support a larger total parameter count with less compute—Qwen3.6-35B-A3B is such a model (its total parameter count far exceeds what is actually activated). The cost is that gradients are unevenly distributed across experts during training, and how LoRA adapters attach to expert layers requires special handling. Unsloth gives each batched job its own expert LoRA and independent fp16 loss scale precisely to prevent jobs from interfering with each other when sharing expert weights—loss scale is used for gradient scaling in mixed-precision training to prevent gradient underflow under fp16, and sharing a single scaling factor across jobs can easily cause individual jobs to diverge.

Mac and Experimental Features

On Mac, requests from Claude Code, Codex, and OpenCode can now share a single MLX batch. In the team's tests, four concurrent requests completed up to 2.3x faster.

Experimental features include:

• Neural Engine Prefill: in tests on an M3 Max with Qwen3.8-27B-4bit, prompt processing is up to 31% faster. This feature must be enabled manually and may slightly change response content;
• Auto context: GGUF models start with a context of no more than 65,536 tokens by default to reduce initial memory usage, and users can still increase it manually.

Stability and Error Handling Improvements

The release notes also list numerous reliability fixes: GGUF models reload in the background after llama-server crashes; failed or canceled GGUF downloads do not affect the currently loaded model; extremely long GGUF chats can continue after compressing context; rejected GGUF requests show llama-server's specific explanation instead of a generic error. When Claude Code connects to a local GGUF, new sessions can reuse cached prompts.

What This Update Means

Judging by the version number v0.1.913-beta, Unsloth is still in a rapid iteration phase. The signal from this update is clear: on one hand, it continues to consolidate its technical lead in local model fine-tuning and quantization; on the other, it invests heavily in the desktop product experience—custom backgrounds, multiple languages, chat layout, and desktop state persistence are all hallmarks of consumer software.

For developers, the most notable items are batched MoE fine-tuning, API example generation, and improved long-text parsing performance; for ordinary users, the perceived improvements from faster updates, a cleaner interface, and support for low-VRAM devices may be more direct.

One caveat: the team explicitly labels Dynamic v3.1 GGUFs and Neural Engine Prefill as preview or experimental. It is advisable to verify output quality locally before using them in production.

Background Notes

The "prefill" in Neural Engine Prefill refers to the forward stage in which the model first encodes the entire input prompt into a KV cache when processing a user prompt, as opposed to the decode stage that generates the answer token by token. The longer the prompt, the higher the share of compute spent on prefill, and the more likely it becomes the bottleneck for time to first token—so prefill acceleration is most noticeable in long-context scenarios. Auto context relates to llama.cpp's context window mechanism: when a GGUF model starts, KV cache must be preallocated according to the maximum context, and a default of 65,536 tokens consumes considerable VRAM or memory. Starting with a smaller window and increasing it as needed can significantly reduce initial usage on low-spec machines.