Koboldcpp v1.120 Adds DirectIO Loading and Two New Models
Koboldcpp v1.120, released on 29 August 2026, adds a DirectIO model loading mode, full support for Qwen3.8-Flash-Next and Ling-3.0-Flash, user-configurable JavaScript tool calling, and several stability fixes. This post explains what changes, what the two new models offer on local hardware, and which settings to check before you load them.
On this page
What the v1.120 update changes
Koboldcpp is a one-file local LLM runtime forked from llama.cpp: you grab a binary for Windows, Linux, or Mac, point it at a GGUF model file, and it serves a local web interface on localhost:5001 [4]. That single-file approach is why it remains popular with people who want a no-install local chat server alongside tools like Ollama or LM Studio.
Version 1.120, published on 29 August, is worth attention for two reasons. The first is a new DirectIO model load mode, enabled with a --usedirectio flag, plus support for combining mlock with mmap [1]. Both settings change how a model moves from disk into memory. If you keep large GGUF files on an external or network drive, DirectIO can reduce caching overhead on the way in, and mlock keeps a loaded model pinned in RAM so it is not swapped out mid-session [1].
The two new models it unlocks
The second reason is model support. The release lists Qwen3.8-Flash-Next and Ling-3.0-Flash as fully supported, with a warning that "there are bad quants floating out there", so users should verify they download correct files [1].
Qwen3.8-Flash-Next is Alibaba's preview of the Qwen4 architecture: a 125B-parameter mixture-of-experts model that activates only about 6B parameters per token, supplemented by an additional 51B of N-gram embeddings, with a 262K native context window [2]. Post-trained weights are downloadable from the official repository on Hugging Face [3]. Ling-3.0-Flash, from Ant Group's inclusionAI lab, pairs 124B total parameters with just 5.1B active per token, carries a 256K context window, ships under an MIT license, and already has community GGUF quantizations available [4].
Tool calling and fixes for daily use
Beyond models and loading, v1.120 adds custom, user-configurable JavaScript tools that are compatible with standard tool calling, which brings simple agent workflows to fully local setups [1]. The release also fixes assistant generation prefill triggering incorrectly, corrects a bug where failsafe mode was wrongly selected, syncs community image generation updates, and rolls in the usual round of upstream llama.cpp merges [1].
What this means for local AI users
Two cautions before you click update. First, small active parameter counts do not mean small downloads: a 124B or 125B total model still needs substantial RAM or VRAM even if only 5B to 6B parameters are active per token, so check quantized builds against your hardware before committing [2]. Second, take the release's quant warning seriously. A badly quantized file can quietly wreck output quality in ways that look like a broken prompt, so stick to trusted quantizers [1].
If your hardware checks out, the combination is genuinely useful: efficient MoE models with long context, faster control over loading, and local tool calling make v1.120 one of the more practical Koboldcpp releases this year for anyone running AI on their own machine [1].