# unsloth installs a command line app before it installs a training stack

> unslothai/unsloth offers four ways in: a native desktop app, a web UI, a Python package and a Docker image. Reading the packaging and the download tables closely shows that the base package carries no deep learning framework, the Windows ARM64 build is pinned to one old beta, and the speed claim is written two different ways in the same repository.

**unslothai/unsloth** — Unsloth is a local UI for training and running Gemma 4, Qwen3.6, DeepSeek, Kimi, GLM and other models.

- Repository: https://github.com/unslothai/unsloth
- Website: https://unsloth.ai/docs
- Stars: 77,025 · Forks: 7,083
- Language: Python
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/unslothai-unsloth

## Two download tables in the same README disagree about Windows ARM64

The page carries two download tables and they do not agree. The table under Get started lists five targets: Windows, macOS, Linux x64 as an Ubuntu deb, Linux ARM64 as an Ubuntu 24.04+ deb, and Linux x64 as an AppImage. The table further down, under Unsloth Desktop, lists those same five and adds Windows ARM64 as a sixth.

The ARM64 row is also built differently from every other row. Five of the rows point at a `releases/latest/download/` path, which follows whatever the newest tag happens to be. The Windows ARM64 row points at a fixed tag instead:

```
https://github.com/unslothai/unsloth/releases/download/v0.1.811-beta/Unsloth-Desktop-Windows-ARM64.exe
```

The consequence for someone on Windows on ARM is concrete. That build stays at v0.1.811-beta however far the project moves, while a user on any of the other five platforms receives the newest tag. The repository's last push was on 2026-09-29 and its newest listed release is v0.1.900-beta from 2026-09-28, so the pinned build already trails the current line by 89 patch versions. If you script your installs, take the URLs from the Unsloth Desktop table rather than the first one, and treat that ARM64 row as a deliberate pin you have to live with rather than a gap that will close on its own.

## The base install is a CLI, not a training framework

It is worth looking at what installing the base package actually pulls in. The dependency list in pyproject.toml is typer>=0.19.0, rich, pydantic, pyyaml, nest-asyncio, huggingface-hub>=0.34.0, structlog>=24.1.0 and click>=8.0. There is no torch in that list, no transformers, no trl and no peft.

Two comments in the same file explain why the command line stack is heavier than it looks. One records that every CLI command imports studio.backend.*, which reaches structlog at module level, and that the rest of the server stack lives in the studio extra. The other records that click had to become a direct dependency because typer stopped supplying it at version 0.27.

What the base package gives you is the console script, declared as `unsloth = "unsloth_cli:app"`, together with its argument parsing, progress output and model downloads. The consequence is that the project description, which promises 2-5X faster training, reinforcement learning and finetuning, is not something this dependency set delivers on its own. If you are integrating rather than clicking through the desktop app, the first question is which extra carries the stack you need, because a base install will not fail loudly here. It will simply have nothing to train with.

## The manual installer pipes a remote script into your shell

Two of the documented install paths execute a script fetched at the moment you run it. On macOS, Linux and WSL the page gives:

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

On Windows it gives the PowerShell equivalent:

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

Neither is pinned. There is no version argument, no commit reference, no checksum and no signature in what you are asked to run, and what executes is whatever that URL serves at that moment. The consequence is narrow but real: on a machine that cannot reach unsloth.ai, or in an environment where an audit requires a fixed and verifiable artefact, this path gives you nothing to check the file against and nothing to re-fetch later.

The page does offer two better behaved alternatives. There is a per-platform file on GitHub Releases, which is at least a fixed URL tied to a tag, and a Docker image named `unsloth/unsloth` on Docker Hub, which is versioned by image tag. For unattended, reproducible or headless builds, prefer one of those two over the piped script, and keep the script for a workstation you control.

## Every versioned release is a beta, and the CUDA 13 kernels ship under a non-version tag

Three releases are listed, and together they describe how this project versions itself. v0.1.900-beta, dated 2026-09-28, is described as Laya Decision Models plus Library. v0.1.815-beta, dated 2026-09-23, is Qwen-Image-2.1 plus Skills. Sitting between them is a tag called prebuilt-wheels-cu13, dated 2026-09-27, whose contents are Flash-Attention2, Causal-Conv1D and Mamba_SSM binaries.

Two consequences follow. First, there is no stable version to pin. Every versioned release carries a beta suffix, so a production environment has to choose a specific beta and accept that it will be superseded by the next one. Second, the compiled CUDA kernels are not part of any version. They arrive under a separate tag with a different shape, which means pinning the package to a version does not by itself tell you which Flash-Attention2, Causal-Conv1D or Mamba_SSM build you are running.

The numbering itself carries no compatibility promise either. The two versioned releases are five days apart and 85 patch versions apart, so the third component behaves as a counter rather than as a signal you can reason about. Plan for that: decide where your kernel binaries come from separately from which package version you install, and record both, because a single version pin does not describe the machine you are actually running on.

## setuptools-scm derives the version from repository metadata

The version number is not written down in the project. pyproject.toml declares it dynamic and resolves it through setuptools-scm:

```toml
[tool.setuptools.dynamic]
version = {attr = "unsloth._version.__version__"}
```

The build system above it is pinned exactly, requiring setuptools==82.0.1 and setuptools-scm==9.2.2, and the package data table has to carry shell and PowerShell scripts, batch files, two prebuilt pin manifests and the compiled frontend bundle.

The consequence is that packaging depends on version data living outside the source tree, and that a build cannot start without those two exact build requirements. setuptools-scm derives a version from repository metadata, so a source tree that arrives without that metadata has nothing to derive from and you get a version you did not choose. The two exact pins also mean a mirror, an air-gapped builder or a corporate index that has not mirrored setuptools 82.0.1 fails before a single module is compiled. If you build this yourself, mirror the build requirements first. They are the part most likely to be missing, not the training code.

## The speed claim is 2x in the feature list and 2-5X in the package metadata

The same performance claim is written twice in this repository and the two versions disagree. The feature list says Unsloth trains LLMs, diffusion, TTS and embedding models 2× faster with 70% less VRAM with no accuracy loss, and it points at a blog page for the detail. The project description in pyproject.toml says 2-5X faster training, reinforcement learning and finetuning.

Neither figure is tied to anything a reader could reconstruct. No model is named, no GPU is named, there is no baseline library, no batch size, no sequence length and no stated measurement method on either side, and the two numbers do not match each other. The no accuracy loss clause is the part with no measurement attached to it at all.

The consequence for an engineer is that you cannot size a training run or defend a capacity plan from either number. What you can do is treat both as a claim to test on your own hardware before you commit to it. Pick one model, one precision or quantisation format and one batch size, hold the baseline library fixed, and measure the difference yourself. The comparison the page is making cannot be recovered from anything the page publishes, and the two figures disagreeing with each other is the clearest signal that they are marketing copy rather than a specification.

## The Qwen version in the description is not the one in the command

The model identifier in the command and the model identifier in the project description are not the same generation. The repository description calls Unsloth a local UI for training and running Gemma 4, Qwen3.6, DeepSeek, Kimi, GLM and other models. The feature list links Qwen3.8, GLM-5.3-Flash, Kimi K3, Qwen-Image-2.1, MiniMax-H3, DeepSeek-V4 and Gemma 4, and the worked example uses a Qwen3.8 repository.

The practical form of this is the model string, which packs two decisions into one argument:

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

The repository part and the quantisation are joined by a colon inside a single flag, so choosing which model you run and choosing how it is quantised are one edit. UD-Q4_K_XL names one specific quantisation of a 27B model in GGUF form. The consequence is that the identifier has to match what the documentation actually serves, and the Qwen3.6 named in the description will not lead you to the page this command expects. Check the model list before copying an identifier, and note that no VRAM figure is given per quantisation anywhere on this page, so how large a model you can hold is not something the project page will tell you.

## Four install surfaces, and the page does not say which of them can train

The install section names three ways to use the project: Unsloth Desktop, the desktop app; Unsloth Studio, the web UI; and Unsloth Core, the code based version. The page also points at a Docker image, `unsloth/unsloth`, with its own install guide, which makes four paths rather than three.

They are not interchangeable, and the page does not attribute the training claims to any of them. Desktop is a native binary per platform, resolved through those download tables. Studio is a web interface with its own manual install snippet for macOS, Linux and WSL. Core is the Python package, and as the base dependency list shows, it arrives as a command line tool. The Docker image is the only one of the four versioned by an image tag rather than by a per-platform link.

The consequence is that installing Unsloth is four separate decisions rather than one, and the feature list advertises fine-tuning, reinforcement learning, LoRA, QLoRA, full fine tuning, pretraining, GRPO, DPO and FP8 without saying which surface carries them. Choose by how you will run it: a per-machine binary for an interactive workstation, the container for a reproducible or headless environment, and the package when you intend to write code against it. Confirm on the documentation site which surface supports fine-tuning before you budget a training run against it.

## Conclusion

Take Unsloth seriously as a set of four distinct surfaces rather than one install, and choose by how you will run it. Before you commit, check three things: which extra carries the training stack, because the base dependency list contains no torch or transformers; which build you get on Windows on ARM, because that download is pinned to v0.1.811-beta while every other platform follows the latest tag; and what your own measurement says, because the 2x and 2-5X figures in this repository disagree with each other and name no model, GPU or baseline. For unattended environments use the Docker image or a fixed GitHub Releases download rather than the piped install script, which has no checksum to verify against.

## FAQ

### What is Unsloth used for?

It is a local environment for running and training models. The project describes running and training LLMs, MLX, GGUF, diffusion, embedding and audio models, plus fine-tuning with LoRA, QLoRA, full fine tuning, pretraining, reinforcement learning, GRPO, DPO and FP8, and exporting to GGUF, NVFP4 and FP8. It reaches agents such as Claude Code, Codex and OpenCode through an OpenAI compatible API and an `unsloth start` command.

### How do I install Unsloth?

The page gives five options: a native desktop download for Windows, macOS, Linux x64 and Linux ARM64; `curl -fsSL https://unsloth.ai/install.sh | sh` on macOS, Linux and WSL; `irm https://unsloth.ai/install.ps1 | iex` on Windows; the `unsloth/unsloth` Docker image; or the Python package. The desktop app is the one the page marks as recommended, and the Windows ARM64 download is pinned to a fixed tag rather than the latest release.

### Is Unsloth AI free?

The repository is licensed Apache-2.0, which covers the code. The page does not state what the hosted service or the desktop application costs, so the licence and the price are two separate questions and only the first is answered here. The README also points to a Docker image and a download page rather than describing pricing terms.

### How do you use Unsloth Studio?

Studio is the web UI, one of three surfaces alongside the Desktop app and the code based Core version. The page gives it a manual install snippet for macOS, Linux and WSL and links a documentation page for it, but it does not describe the interface, the ports it listens on or which training features it exposes. Its Python dependencies live in the studio extra rather than in the base package.

### Can you use Unsloth in a Kaggle notebook?

The page does not mention Kaggle. What it describes is five desktop download targets, a shell installer for macOS, Linux and WSL, a PowerShell installer for Windows, a Docker image, and documentation hosted at unsloth.ai/docs. No notebook environment or hosted-notebook setup is written down here, so you would be working from the Docker path or the package rather than from instructions on this page.

## Sources

- [Official documentation](https://unsloth.ai/docs)
- [Official README](https://github.com/unslothai/unsloth#readme)
- [Project repository](https://github.com/unslothai/unsloth)
- [Release notes](https://github.com/unslothai/unsloth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unslothai-unsloth