Unsloth: a desktop app, a web UI and a Python CLI for running and fine-tuning local models, shipped as rolling betas

One project, three front ends: Desktop, Studio and Core

Unsloth ships the same engine in three forms. Unsloth Desktop is the native app and the recommended route, with installers for Windows, Windows ARM64, macOS, Ubuntu as a .deb for x86 and ARM64, and a generic Linux AppImage. Unsloth Studio is the web UI, documented under unsloth.ai/docs/new/studio. Unsloth Core is the code-based version for people who want to script training rather than click through it. The repository layout reflects that split: unsloth/ holds the library, studio/ the web interface, unsloth_cli/ and cli.py the command line, docker/ the container build, and install.sh and install.ps1 the bootstrap scripts. The practical effect is that a bug report or a guide written for one front end does not always map cleanly onto another, so note which of the three you are running when you look for help on Discord, Reddit or GitHub Issues.

Two of the install routes pipe a remote script straight into a shell

Besides the Desktop installers, there are four manual routes and a container image. On macOS, Linux and WSL:

curl -fsSL https://unsloth.ai/install.sh | sh

On Windows, in PowerShell:

irm https://unsloth.ai/install.ps1 | iex

Through Homebrew:

brew install --cask unsloth

Through Winget:

winget install --id UnslothAI.Unsloth -e

The first two download a script from unsloth.ai and execute it immediately, so you run whatever that server returns at that moment. Copies of install.sh and install.ps1 sit at the top of the repository, which gives you something to read before running the hosted version, but nothing in the one-liner guarantees the two match. On managed machines where piping to a shell is blocked, Homebrew and Winget are the routes that go through a package manager. The Docker image is unsloth/unsloth on Docker Hub; no run command appears next to it on GitHub, only a link to the Docker guide in the docs.

Every download link follows releases/latest, and latest is a beta

All Desktop download links resolve through github.com/unslothai/unsloth/releases/latest/download, so the file you get depends on the day you click. The recent release history shows how fast that target moves: v0.1.911-beta on 26 October 2026 (Scheduled, MiniMax-M3.1-Flash and performance gains), v0.1.912-beta on 28 October 2026 (Trick or Treat and optimizations), and v0.1.913-beta on 30 October 2026 (customization, performance and UI/UX improvements). The last push to main was on 2 November 2026, so the project is under active development. The cost for users is reproducibility. A training run you set up on one machine can behave differently on a colleague's machine installed four days later, and every build so far carries a 0.1.x version and a beta label. If results need to be repeatable, record the exact release tag you installed and download that release's asset from the GitHub Releases page instead of the latest link.

unsloth start wires coding agents to a local model in one command

Unsloth Start is the piece aimed at developers who already use an AI coding agent. It launches the agent against a model served locally by Unsloth:

unsloth start claude --model unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL

The model argument is a Hugging Face style repository name followed by a quantization tag, here a GGUF build of Qwen3.8-27B. The subcommand picks the agent: claude for Claude Code, codex for OpenAI Codex, vscode for Visual Studio Code, dsh for DeepSeek Harness, opencode for OpenCode, hermes for Hermes Agent, pi for Pi, openclaw for OpenClaw and vibe for Mistral Vibe. The quick start does not say how much memory a 27B model at that quantization needs, so the one-command promise only holds if your machine can actually hold the model. Pick the model and quantization to fit your hardware first, then the agent subcommand; the agent will feel only as capable as the local model behind it.

The README's hardware list is broader than the package metadata

On paper the platform story is wide: Windows, Linux, WSL and macOS, with multi-GPU setups, NVIDIA, AMD and Intel GPUs, CPUs and a Vulkan backend. The Python package metadata is narrower. Its classifiers in pyproject.toml name Environment :: GPU and Environment :: GPU :: NVIDIA CUDA, and nothing for AMD, Intel or Vulkan. Classifiers are labels rather than a test matrix, so this does not prove the other backends are missing, but it does mean the package index gives AMD and Intel users no signal either way. The speed claims also come in two versions. The README promises training 2x faster with 70% less VRAM and no accuracy loss, linking to the project blog; the pyproject description says 2-5X faster training. Both are the project's own figures. Treat them as the vendor's headline and measure on your own GPU, model size and method before planning capacity around them.

The pip package is a CLI that drags in the Studio backend and a certifi floor

The unsloth package installs a single console script, unsloth, mapped to unsloth_cli:app. Its dependency list explains a few surprises. typer, rich, pydantic, pyyaml, json5 and huggingface-hub 0.34.0 or newer are expected for a CLI. structlog 24.1.0 or newer is there because CLI commands import studio.backend, which loads structlog at module level, so the command line is coupled to the web UI's backend code. click 8.0 or newer is pinned explicitly because unsloth_cli imports it through commands/start.py and typer stopped supplying it in 0.27. The certifi floor is 2026.10.19, the release that removes the distrusted emSign ECC Root CA - G3, and pip install unsloth upgrades an older certifi in place. If you install into a shared environment, that upgrade changes the CA trust store for every other package using certifi. Supported Python runs from 3.9 up to but not including 3.15; the build pins setuptools 84.1.0 on 3.10 and newer and 82.0.1 on 3.9, because setuptools 83 and later dropped 3.9.

Training methods run from LoRA to FP8, and export goes out to GGUF and NVFP4

The training side covers reinforcement learning, LoRA, QLoRA, full fine-tuning, pretraining, GRPO, DPO and FP8, across LLMs, diffusion, decision, TTS and embedding models. Models can be exported or deployed as GGUF, NVFP4, FP8 and other formats, which is how a fine-tuned checkpoint ends up usable in a GGUF runtime. Data Recipes builds training datasets from PDFs, CSVs, DOCX files and similar sources, so a first experiment does not have to start with hand-written JSONL. The named model families include Qwen3.8, GLM-5.3-Flash, Kimi K3, Qwen-Image-2.1, MiniMax-H3, DeepSeek-V4 and Gemma 4. That list moves quickly: the repository description still mentions Qwen3.6 while the feature list has moved on to Qwen3.8, and v0.1.911-beta added MiniMax-M3.1-Flash. A model guide you find in the docs can therefore be ahead of or behind the build you installed, so check the release notes for your version before following one.

LAN access, Cloudflare tunnels and code execution widen what a local install exposes

Unsloth is not only a training tool. It serves models through an OpenAI compatible API, can connect a ChatGPT or Codex subscription and other cloud providers, and offers web search, deep research, auto-compaction with a rolling context window, and RAG. Local models can be used with Claude Code, Codex and MCP, including tool calling and code execution. Models can be reached from other devices on the LAN or remotely over HTTPS through Cloudflare. Each of these turns a desktop app into something that listens on a network or acts on your files. Code execution means a model's output can run on the machine hosting it, and LAN or Cloudflare access means other devices can reach the API. Before enabling remote access, read the LAN and Cloudflare guides in the docs and decide who should be able to reach the endpoint; the defaults suited to a single laptop are not the ones you want on a shared network.

Editorial conclusion

Unsloth suits people who want to fine-tune or run open models such as Gemma 4, Qwen3.8 or DeepSeek-V4 on their own machine through a desktop app, and developers who want to point Claude Code, Codex or OpenCode at a local model with one command. It is a poor fit for anyone who needs a frozen, versioned toolchain, since every release so far is a 0.1.x beta and the download links track the latest one. Before committing, check that your GPU vendor is supported in the docs rather than relying on the NVIDIA-only package classifier, read install.sh or install.ps1 before piping them into a shell, and measure the advertised speed and VRAM savings on your own model and hardware.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes