New Unsloth Release: Scheduled Tasks and MiniMax-M3.1-Flash Arrive

Unsloth's latest release, v0.1.911-beta, brings a range of practical updates covering automated tasks, new model support, image editing, and multi-platform performance optimizations. This article rounds up the key highlights and analyzes what these changes mean for developers in practice.

Scheduled Tasks: Let Models Run Automatically in the Background

Unsloth has added a "Scheduled" entry to the "More" menu in the sidebar, allowing users to run prompts on a schedule. Task frequency supports one-time, daily, weekdays, weekly, or monthly runs, and the result of each run is saved as a new chat session.

Tasks can be specified to run on an already-loaded model, a model on the local device, or a model from a connected API provider. If the model a task requires is not yet loaded, Unsloth will ask the user first, unless the "Switch automatically when I'm away" option is enabled. Users can also set a notification policy: notify after every run, notify only on failure, or never notify.

Note that tasks only execute while Unsloth is running, and tool calls and web search are not supported. This design suits repetitive text generation or analysis tasks, such as daily summaries or scheduled reminders.

MiniMax-M3.1-Flash: Built for Coding and Agent Workflows

This update introduces MiniMax-M3.1-Flash, a MoE model with 428B total parameters and 23B activated parameters, officially positioned for coding, tool use, and agent workflow scenarios. It supports context lengths of up to 1 million tokens, making it suitable for long documents or complex conversations.

For GGUF quantization, the 1-bit quantized version requires at least 130GB of combined memory and VRAM. For users who want to run this model locally, this is a significant hardware threshold that requires evaluating device specs in advance.

MoE (Mixture of Experts) is a sparsely activated model architecture: the model internally contains multiple "expert" subnetworks, and each token is routed to only a few of these experts for computation during inference. As a result, the total parameter count can be very large while the number of parameters actually used in a single forward pass (the "activated parameters") remains small. This is exactly why MiniMax-M3.1-Flash can run with 428B total parameters but only 23B activated parameters—it retains the knowledge capacity that comes with large-scale parameters while keeping inference costs close to those of a 23B dense model. For local deployment, VRAM requirements are mainly determined by the activation path and the weights that actually reside after quantization, and quantization formats such as GGUF further compress weight size; however, 1-bit quantization still requires roughly 130GB of combined memory and VRAM, showing that total parameter scale remains the dominant factor in the hardware threshold.

Enhanced Image Editing and Generation

FLUX 3 now supports editing images via prompts. Users can modify photos in Images > Edit while preserving the original dimensions. This provides a more flexible approach to post-processing images.

In addition, the Images page adds a Detailer feature that can be enabled to redraw faces, hands, or other user-specified regions at higher resolution. This feature requires SAM 3 and a model that supports inpainting.

On the video side, users can generate video from text or images in the Video page via NVIDIA's Cosmos3-Edge. For older NVIDIA GPUs (pre-RTX 30 series), Wan2.1 1.3B text-to-video rendering is about 5x faster, significantly lowering the barrier for users on older hardware.

Inpainting (image restoration/partial redrawing) refers to regenerating content only within a specified mask region of an image while keeping pixels outside the mask unchanged, making it especially suitable for local edits such as fixing faces, repairing hands, or removing objects. The Detailer workflow typically has two steps: first, use a detection or segmentation model (here, SAM 3, the third generation of Segment Anything Model) to automatically or manually outline the target region; then crop and upscale that region, hand it to an inpainting-capable model for redrawing at higher resolution, and finally paste it back into the original image. Because diffusion models allocate too few pixels to small areas such as faces and fingers at the original resolution, direct generation can easily look blurry or distorted; upscaling before redrawing significantly improves detail quality, which is also why Detailer requires an additional segmentation model.

Performance Optimizations: Faster Mac and Local Inference

Mac users are the main beneficiaries of this round of performance improvements. MLX chat replies are up to 16% faster with a draft model, and MLX models that come with a built-in draft model enable this feature automatically with no extra download. On Apple Silicon, Z-Image GGUF generates images from text using the MLX engine by default, at 1.5 to 2 times the previous speed.

Memory required at the end of image and video rendering is greatly reduced, so stuttering from swapping on low-memory Macs will decrease noticeably. In addition, many image and video models save their built versions after first loading on NVIDIA GPUs, making subsequent loads faster.

MLX is Apple's array computing and machine learning framework designed for Apple Silicon chips. It can uniformly leverage CPU and GPU shared memory, so running large models on Macs is typically more efficient than with generic backends. The "draft model" mentioned here corresponds to speculative decoding: a small, fast draft model first guesses several tokens in succession, which the target large model then verifies in parallel all at once. Accepted guesses are kept directly, reducing the number of large-model forward passes without changing the output distribution and thereby achieving speedup. The better the draft model "matches" the target model, the higher the acceptance rate and the more pronounced the speedup. MLX models with built-in draft models enable this mechanism automatically, which saves users the step of manually selecting a matching draft model.

Training and API Security Improvements

On the training side, LoRA and QLoRA training now support splitting each layer of the model across multiple GPUs. By setting the UNSLOTH_TP_SIZE environment variable and launching with torchrun, VRAM usage per GPU is lower. For GRPO training with vLLM generation on Linux + NVIDIA GPUs combined with 16-bit LoRA, per-step speed improves by up to 1.9x; without vLLM, Llama and Qwen3 achieve up to 4.4x faster per-step speed on NVIDIA GPUs.

On API security, apps using an Unsloth API key can no longer approve Python or terminal calls to run outside the sandbox on their own. Unsloth also no longer trusts forwarded client IPs by default. If deployed behind a reverse proxy, you need to set UNSLOTH_STUDIO_TRUST_FORWARDED=1; otherwise all users will share the same login rate limit.

Splitting each layer of the model across multiple GPUs follows the idea of tensor parallelism: the weight matrices within a single layer are partitioned across different devices, each device computes partial results, and these are aggregated via collective communication (such as all-reduce), thereby distributing single-GPU VRAM pressure across multiple GPUs. Unlike data parallelism, tensor parallelism partitions the parameters of the same layer itself, making it suitable for fine-tuning large models that don't fit on a single GPU—but at the cost of frequent inter-device communication and sensitivity to interconnect bandwidth. torchrun is the distributed launcher provided by PyTorch; it is responsible for setting environment variables such as rank and world size for each process and spawning multiple processes. UNSLOTH_TP_SIZE tells Unsloth the desired degree of parallelism. The two must be consistent, or you'll run into mismatches between process count and partitioning strategy.

Conclusion

Unsloth v0.1.911-beta makes substantive progress in automation, model ecosystem, and performance. Scheduled tasks make repetitive work more convenient, MiniMax-M3.1-Flash expands the range of large models that can run locally, and optimizations on the Mac and training sides directly improve the day-to-day experience. For developers focused on local AI workflows, this version is worth upgrading to.

One-line Summary

Unsloth v0.1.911-beta adds scheduled tasks, the MiniMax-M3.1-Flash model, and image editing capabilities, while significantly optimizing Mac and training performance.

Paragraph Summary

Unsloth v0.1.911-beta brings updates on multiple fronts. On automation, it adds "Scheduled" tasks that can run prompts once, daily, on weekdays, weekly, or monthly, saving results as new sessions, with support for specifying models and configuring notification policies—though tasks only run while Unsloth is running and don't support tool calls or web search. The model ecosystem introduces MiniMax-M3.1-Flash, a MoE architecture with 428B total parameters and 23B activated, supporting 1 million token context; 1-bit quantization still requires about 130GB of combined memory and VRAM. On the image side, FLUX 3 supports prompt-based editing while preserving original dimensions, a new Detailer requires SAM 3 and an inpainting model, video can be generated with Cosmos3-Edge, and Wan2.1 1.3B is about 5x faster on older NVIDIA GPUs. On performance, Mac MLX chat is up to 16% faster, Z-Image text-to-image is 1.5-2x faster, and memory usage at the end of rendering drops; on the training side, cross-GPU layer-split training and GRPO speedups are supported, and API security policies have been tightened.