SillyTavern: A Local LLM Frontend for Power Users

What SillyTavern solves, and who it is for

Most people who run a language model end up with two or three chat windows open. One for a local KoboldAI or llama.cpp server, one for a hosted API, and a third for whatever image model they are experimenting with. Each has its own prompt format, its own history handling and its own idea of what a system message looks like. SillyTavern exists to collapse that into a single browser interface.

The README describes it as a locally installed user interface for text generation LLMs, image generation engines and TTS voice models, and lists KoboldAI/CPP, Horde, NovelAI, Ooba, Tabby, OpenAI, OpenRouter, Claude and Mistral among the supported APIs. The project began in February 2023 as a fork of TavernAI 1.2.8 and the README states it now has over 300 contributors and 3 years of independent development.

The audience is explicit in the tagline: power users. The README's vision section says the project aims to give users as much utility and control over LLM prompts as possible, and adds that the steep learning curve is part of the fun. That is an honest description of the product. If you want a chat box that just works, this is more surface area than you asked for. If you want to edit the prompt template, reorder the context, inject a lorebook entry by keyword and swap the backend without losing your character, the surface area is the point.

How the pieces fit: a Node server with a browser client

The repository layout makes the architecture fairly easy to read. There is a server.js at the top level, a src/ directory, a public/ directory holding the client, a plugins/ directory, and a default/ directory that ships starter content. The package.json lists Express, body-parser, cookie-session, csrf-sync, compression and cors among the dependencies, which is the shape of a conventional Node web server rather than a desktop application.

That matters for how you use it. SillyTavern is not a native app you launch from a dock. It starts a local server, and you open it in a browser, which is why the README can claim a mobile-friendly layout and a Visual Novel Mode without shipping separate mobile builds. The same server can be reached from a phone on the same network, and the README links to an Android (Termux) installation guide for people who want to run it on the device itself.

The feature list in the README covers the parts that sit on top of that server: WorldInfo (lorebooks), auto-translate, customizable UI, prompt options, and third-party extensions. The repository has a plugins.js and a plugins/ directory, and the README mentions endless growth potential via third-party extensions. The Dockerfile even creates a public/scripts/extensions/third-party directory and runs git config --global --add safe.directory "*" so extension repositories can be managed inside the container.

Installing SillyTavern and connecting a first backend

The README does not repeat installation steps. It points to four separate guides on the documentation site, one each for Windows, MacOS/Linux, Android (Termux) and Docker. The hardware note is the one concrete requirement in the README: it runs on anything that can run NodeJS 20 or higher. That is the floor for the interface itself, not for model inference.

On Windows, the repository ships Start.bat, UpdateAndStart.bat and UpdateForkAndStart.bat at the top level, which are the launchers the Windows guide builds around. On Linux and macOS there is a start.sh. Both paths assume Node is already installed and that you have cloned the repository.

git clone https://github.com/SillyTavern/SillyTavern.git
cd SillyTavern

After that, the platform guides take over. If you would rather not manage Node on the host, the Dockerfile exposes port 8000 and is built on node:lts-alpine3.23, so a container run maps that port to your machine.

docker build -t sillytavern .
docker run --name sillytavern -p 8000:8000 sillytavern

The Dockerfile creates config, data, plugins, public/scripts/extensions/third-party and backups directories, links config.yaml to ./config/config.yaml, and sets NODE_ENV to production. Those are the directories you would mount as volumes if you want your characters and settings to survive a container rebuild. The image runs as the node user through su-exec, not as root.

Once the server is up, the first real task is pointing it at a model. Open the interface, go to the API connection settings, and choose your backend from the list the README gives: KoboldAI/CPP, Horde, NovelAI, Ooba, Tabby, OpenAI, OpenRouter, Claude or Mistral. For a local server such as KoboldCpp, you enter the address the backend is listening on. For a hosted API, you paste a key. After connecting, send one short message and confirm a reply comes back before you start building character cards, because a misconfigured backend will look like a broken prompt editor rather than a connection problem.

The local inference requirement is separate from the app requirement

The README draws a line that is easy to miss. SillyTavern itself needs almost nothing: any machine that runs NodeJS 20 or higher. The recommendation for a 3000-series NVIDIA graphics card with at least 6GB of VRAM applies only if you intend to do LLM inference on your local machine, and even then the README hedges, saying actual requirements may vary depending on the model and backend you choose.

This split is the source of most disappointment. Someone reads that the app is lightweight, installs it on a laptop with integrated graphics, and then finds that the model they want to run does not fit. The app is fine. The model is not. Nothing in the README promises that SillyTavern will make a large model run on weak hardware, and it is not a quantization tool or an inference engine. It is a client.

If you have no GPU and no intention of buying one, the honest answer is to use a hosted API from the supported list rather than local inference. The README lists OpenAI, OpenRouter, Claude and Mistral alongside the local backends precisely because the interface does not care where the tokens come from. You lose the privacy argument for running locally, and you take on per-token cost, but you keep the prompt control that is the actual product.

What SillyTavern is not good at

The steep learning curve the README mentions is real, and it is not evenly distributed. Basic chat is quick to reach. Prompt templates, context ordering, WorldInfo activation rules and extension configuration are not, and the documentation site is where that complexity lives rather than in the README. Anyone expecting the README to explain how a lorebook entry gets triggered will not find it there.

SillyTavern is also the wrong tool if you need a supported product. The README states plainly that the project provides no online or hosted services and does not programmatically track user data. That is a privacy position, and it also means there is no vendor to call. Support runs through a Discord server, Reddit accounts and GitHub issues, all listed in the README. If your organisation requires a support contract or an SLA, this is not it.

The AGPL-3.0 licence is a third constraint. The README points to the GNU Affero General Public License and carries the standard warranty disclaimer. The AGPL is a copyleft licence with a network-use clause, which is a different proposition from the MIT licence of the TavernAI 1.2.8 code it forked from. If you plan to modify SillyTavern and expose it to users over a network, the licence terms are worth reading in full before you build on it. This is not legal advice, and the LICENSE file in the repository is the authoritative text.

Finally, the release branch is where the project ships. The last push recorded for the repository is 2026-05-03, which is also the date of the 1.18.0 release. That is more than four months before this article, so treat the project as one that ships in bursts rather than continuously, and check the release notes for 1.17.0 and 1.16.0 before you assume a behaviour you read about elsewhere is current.

How it compares with running a backend's own web UI

The most direct alternative is not another frontend. It is the web interface that ships with your inference backend. KoboldCpp, for example, serves its own chat page, and so do several other local servers. If you only ever talk to one backend with one character and never touch the prompt template, that built-in UI is less work: no second process, no Node install, no updates to track.

The difference in approach is what happens when you want a second backend. A backend's own UI is bound to that backend. SillyTavern treats the model as a swappable component and keeps the surrounding state, characters, lorebooks, prompt presets, chat history, in a layer that does not move when you change the API. The README's list of supported backends is the whole argument: KoboldAI/CPP, Horde, NovelAI, Ooba, Tabby, OpenAI, OpenRouter, Claude and Mistral behind one interface.

That portability has a cost. You are running an extra server, keeping NodeJS 20 or higher available, and following a release branch that ships on its own schedule. You are also relying on the frontend's abstraction over each API, which will not always expose every parameter a specific backend offers. For a single local model and a simple chat, the built-in UI wins on setup time. For anything involving more than one backend, or character cards and lorebooks you want to keep, the abstraction is the reason to accept the extra moving part.

Editorial conclusion

Adopt SillyTavern if you already run a local model or hold API keys and want one prompt editor across several backends, character cards and lorebooks. Skip it if you want a hosted service with zero configuration or need a supported commercial product. Before committing, check the NodeJS version on your machine, read the Windows, Linux/macOS, Android or Docker installation page that matches your platform, and confirm which backend you will point it at, because the README recommends a 3000-series NVIDIA card with at least 6GB of VRAM only for local inference.

Frequently asked questions

Official sources

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