text-generation-webui, Start to First Response

If you followed a link to github.com/oobabooga/text-generation-webui and landed somewhere else, nothing is broken. The project is now called TextGen and lives at github.com/oobabooga/textgen; the old URL redirects, so existing clones and bookmarks keep working. Everything below is written against that.

The name changed

The rename matters for a tutorial because half the instructions on the web name directories, scripts and issue links that have moved. The repository’s own description now reads “Open-source desktop app for local LLMs”, which is the second change: alongside the web UI there is an Electron desktop app, and the 4.x line has added vision input, tool calling and an Anthropic-compatible API endpoint next to the OpenAI-compatible one. Release v4.9 is dated 20 May 2026 on the project’s releases page and is the version this page describes.

The keyword people still search is the old one, which is why this page carries the old name in its title. Treat “text-generation-webui” and “TextGen” as the same thing and read any guide older than 2026 with that substitution in mind.

Portable build or installer

The path of least resistance is a portable build. These are self-contained downloads per platform and per GPU backend — the v4.9 release publishes Windows and Linux variants for CUDA 12.4, CUDA 13.1, Vulkan, ROCm 7.2 and CPU-only, plus ik_llama.cpp variants, and macOS builds for Apple Silicon and Intel. Sizes in that release run from 307 MB for the Linux CPU build to 1.33 GB for the largest Windows CUDA one, which tells you where the weight is: bundled GPU libraries, not model weights.

• Pick the backend you have. A CUDA build on an AMD card will fall back to CPU rather than fail loudly, and you will conclude the project is slow. Vulkan is the cross-vendor choice.
• Your data lives in user_data/. Models, characters, presets and settings all sit under that directory, which is what you carry across when you replace a portable build with a newer one.
• The one-click installer is the other route, and it builds a Python environment locally. It gives you a checkout you can modify; it also gives you a Python environment to keep working. Take the portable build unless you intend to edit the code.

The Model tab and the loader

1. Launch the app and open the Model tab. Models are read from user_data/models; put a GGUF there, or use the download field in the same tab with a Hugging Face repository name.
2. Choose a loader. TextGen supports several backends — llama.cpp for GGUF, Transformers for unquantised or bitsandbytes weights, ExLlamaV2 and ExLlamaV3 for EXL2/EXL3, TensorRT-LLM for compiled NVIDIA engines. The loader must match the file format. A GGUF loaded with Transformers fails; an EXL3 loaded with llama.cpp fails. This is the single most common first-run error and the error text names the format, so read it. If you are unsure which format to download in the first place, choosing a quantisation covers the trade-off.
3. Set n-gpu-layers (llama.cpp) or the equivalent split for your loader, and set the context size. Both compete for the same VRAM — the KV cache grows linearly with context, derived on the memory budget page.
4. Press Load and watch the terminal, not the browser tab.

First response

Switch to the Chat tab and send a message. Recent releases show tokens per second and current context size live during generation, which is the readout to use rather than any published figure: it is your machine, your model and your quantisation, and no benchmark elsewhere substitutes for it. If that number is far lower than you expect, go back to the Model tab and raise the GPU layer count until either it stops improving or the load fails.

If the model replies but ignores your instructions, the instruction template is wrong rather than the model. TextGen picks a template from the model’s metadata where it can and falls back to a default where it cannot, and the fallback is frequently wrong for a newly-released model. The template selector is in the parameters area; matching it to the model’s documented chat format fixes more “this model is bad” complaints than any sampler change.

The extension trap

Extensions are the reason many people choose this project, and they are where the portable builds bite. Two things have to be true and only one of them is obvious.

First, an extension has to be enabled at launch — either ticked in the Session tab and applied, or passed as --extensions name on the command line. Copying a folder into extensions/ does nothing on its own.

Second, and this is the trap: most extensions have their own requirements.txt, and a portable build ships its own bundled Python interpreter. Running pip install -r requirements.txt in your ordinary shell installs those packages into the system Python, which the portable build never consults, so the extension continues to fail with an import error while pip list insists the package is present. The install has to target the bundled interpreter — the Python inside the portable directory, or the environment the one-click installer created. If an extension fails to import a module you are certain you installed, you installed it into the wrong interpreter.

A third, quieter failure is ordering. Extensions load in the order they are listed, and some of them modify the same generation hooks; two that each work alone can produce nothing useful together. If the UI comes up but generation returns empty strings after you enable a second extension, disable everything, confirm a bare generation still works, then re-enable one at a time. That is dull and it is faster than reading tracebacks, because the traceback usually names the last extension in the chain rather than the one that broke it.