[Bug] Unsloth Loading a repo id that exists in a registered scan folder downloads it into the hub cache instead of using the local copy

name: Unsloth Studio Bug about: Report a problem with the Unsloth Studio desktop app or web UI title: "[Unsloth Bug] Loading a repo id that exists in a registered scan folder downloads it into the hub cache instead of using the local copy" labels: bug assignees: ""

Environment

Where are you using Unsloth?

• Unsloth desktop application
• Unsloth web UI (unsloth studio)
• Unsloth CLI
• Python package or notebook
• Colab or Kaggle

Operating system and version: Windows 10 Pro x64

GPU model(s) and accelerator backend: NVIDIA Tesla V100-PCIE-32GB (CUDA)

Versions: Unsloth 2026.9.11, unsloth_zoo 2026.9.7, transformers 5.5.0, torch 2.11.0+cu126, Python 3.13.14, llama.cpp b11160

What happened?

Steps to reproduce:

1. Register a scan folder (Hub → On Device) containing a complete HF-style repo copy of a GGUF model, e.g. unsloth/Devstral-Small-2-24B-Instruct-2512-GGUF (UD-Q5_K_XL, ~16.8 GB).
2. Load it by repo id (POST /api/inference/load, i.e. the Load button).
3. Watch the server log and the hub cache.

Expected behavior: The load uses the local copy from the scan folder.

Actual behavior: The server checks only the hub cache and starts a full download of the repo — a byte-identical duplicate of the file already on disk.

The download and the load request ran ~26 minutes and never completed; it only ended when I restarted the server. A second attempt stalled the same way — the UI's unload control stays inactive during a load, but POST /api/inference/unload aborted it (Unsloth Unload Button not active).

Model and operation involved: GGUF inference loads by repo id; all three repos are held only in a registered scan folder:

• unsloth/Devstral-Small-2-24B-Instruct-2512-GGUF (UD-Q5_K_XL, ~16.8 GB) — the run documented above
• unsloth/Muse-Glimmer-30B-GGUF (UD-Q4_K_XL)
• unsloth/gpt-oss-20b-GGUF (F16)

Diagnostics and logs

Server log of the affected session, key lines (paths redacted):

GGUF download: 16.8 GB needed (0.0 GB already cached), 47.0 GB free on disk
Downloading (xet transport)...        
Model load exceeded 15s; padding the response so a proxy cannot time it out
Cancelled 1 in-flight model load(s) for shutdown

Additional context

Root cause (from reading the code): ModelConfig.from_identifier classifies a repo-shaped id as remote, and the llama.cpp load path resolves only the hub cache (_verified_cached_gguf → _download_gguf). The local index that already covers scan folders (core/inference/local_model_resolver.py::resolve_local_gguf) is never consulted on /load.

I have a minimal fix ready (one insertion in routes/inference.py + tests) that resolves the repo id through that index first and keeps today's behavior on a miss. I'll open a PR. Related but not covering this: #6989 and #11246.