Luker forks SillyTavern and then changes the two things that annoy you

It is a SillyTavern fork that promises zero migration cost

The compatibility claim is the first thing the project states and it is specific about what it covers: Luker is built on SillyTavern and stays fully data-compatible with it, with character cards, world info, presets and chats moving in both directions at zero migration cost. That is a narrower claim than it sounds and a more useful one. It does not mean every setting behaves identically, because the project explicitly changes behaviour in two places. It means your content survives, which for a roleplay platform is the whole asset. Two details about the repository support the claim. The default branch is named release rather than main, which suggests a maintained release line is what people actually install. And the README is translated into seven languages including German, Simplified and Traditional Chinese, Japanese, Russian and Korean, which is a rough proxy for who the existing SillyTavern user base is. The project also positions itself against its parent by name, describing itself as a next-generation roleplay chat platform rather than as a fork, which tells you it intends to diverge.

The memory is a graph of typed nodes, not a running summary

This is the feature the rest of the project is built to serve. Long-term memory is a knowledge graph, and chat content distills into typed nodes with links between them: characters, locations, events and plotlines are the named types. Before a reply is generated, a recall pass walks that graph and injects the most relevant memories into context. The example given is specific enough to be the right test of whether you want this. When the protagonist returns to a place they visited earlier, a character who has been off-stage for a long time gets recalled. That is a different failure mode from the usual summarising memory, which tends to preserve what was said recently and forget who is involved. Whether a graph walk retrieves a dormant character better than a vector search over recent turns is exactly the kind of thing you would have to try on your own content, and the documentation site carries a dedicated page for the memory graph rather than a mention in a list.

Five execution modes, and the trace arrives with the reply

The orchestrator runs a configurable team of agents before handing off to the writer model, and the named roles are distiller, planner and critic: recent context is condensed, the next scene is sketched, and the result is reviewed. What follows is that the final reply arrives with a runtime trace you can inspect, which is the difference between a multi-agent system you have to trust and one you can audit. The modes are the part worth choosing between. Spec is a fixed pipeline. Single Agent is the obvious case. Agenda has the flow dispatch agents dynamically. Loop has a single agent iterate on its own tool calls until the task is complete, which is the mode that can run away and the one that can also finish things. Director has a main agent and a sub-agent team explore the context and draft the message body together, and it is the default profile the bundled skills ship with. Five modes over the same three roles means the difference is orchestration shape, not capability, so you can switch without losing the underlying agents.

Skills use someone else's format, and cards are edited by conversation

Skills here are reusable knowledge packs an agent reads on demand rather than plugins it executes, and the examples given are writing rules, voice conventions and anti-cliché checklists. Those are the kind of instructions that are tedious to keep in every character card and easy to version once. The design decision worth noticing is that the format is compatible with Anthropic's Claude Skills, so a pack written for one works in the other, and the orchestrator's default Director profile ships with some bundled. Distribution is also worth noting: skills can travel with a character card or a preset, which means a whole writing setup moves between users as one file rather than as a folder you have to ask someone to send separately. There is a documentation page for the skills system as well, so the format is treated as a contract rather than an implementation detail. If you already maintain instruction packs for other assistants, the migration path here is a format conversion rather than a rewrite. The character card tooling is the part that reads most like a development tool than a chat app, and it is described in two tiers. A regular card gets a popup editor. A card with an embedded CardApp, described as a card-hosted mini application, opens in a full studio instead, with a file tree, a live preview and history. Behind both is the actual idea, which is that you edit cards by talking to an AI: there is a chat panel, and changes are approved through diffs item by item rather than accepted wholesale. That approval model is the same one used by the preset assistant, which takes a description of what you want a chat-completion preset to do, iterates on the preset with you, and presents every change as a diff for review until it matches, including reading parameters, editing prompt entries and comparing against a reference preset. The stated benefit is that you are never asked to trust an edit you have not seen. It also means the cost of a wrong edit is bounded, since you reject one field rather than losing a card. The same workflow covers orchestrator presets.

The Android app is the whole server, not a client

Most mobile companion apps for a web tool are clients. This one runs the platform. The Luker backend executes inside an Android app, so installing the APK and opening it gives you the full server plus the interface on a single device, with no Termux, no manual Node install and no port forwarding. That last item is the one that matters in practice, because port forwarding is the step where most self-hosted setups on a phone go wrong. Migration is handled by a backup ZIP import on the first-run screen, which matters given the project's compatibility claim, since bringing an existing library across means importing what you already have rather than rebuilding it. There is a dedicated guide for the Android app, and the platform it targets is therefore genuinely self-contained: a phone can be the only machine running it. That also means the deployment story elsewhere in the project is not the only option, which is worth keeping in mind when weighing the container route.

Generation runs on the backend, so closing the tab stops nothing

This is a small architectural decision with a large effect on how you use the thing. Generation runs on the backend and is streamed to the interface over a WebSocket. Reload the tab, close the laptop lid, lose the Wi-Fi, and the reply keeps writing on the server, reconnecting to the interface when you are back. Nothing is lost and nothing has to restart. Compare that with the common alternative, where generation is a request held open by the page that asked for it, and the practical consequence is that a long reply no longer has to be babysat and a browser that reloads mid-generation is not a lost generation. The project gives this its own documentation page on backend storage and lifecycle, which suggests it is treated as a feature rather than an implementation note. It also pairs with the LAN sync feature, where two instances on the same network keep chats, cards, world info and settings in step with nothing pushed to a cloud, so the backend is the single source of truth even when you are moving between machines.

Models and presets are decoupled, which is the actual SillyTavern complaint

One paragraph in the feature list is aimed squarely at an existing frustration, and it is the clearest statement of intent in the README. In SillyTavern, API connections and chat-completion presets move together, so switching to a different model drags your whole prompt configuration along with it. Luker decouples the two: you can swap the model without rebuilding your prompt setup, and swap the preset without touching your API keys. For anyone who experiments across providers, that is the difference between a five minute change and a twenty minute one. The rest of the long tail is in the same spirit. Chats can be split at any turn or merged, with branch history staying consistent, which the project frames as useful when a scene gets out of hand and you want the interesting parts without losing the rest. Text to speech can attribute quoted lines to their own speakers, with a background pass working out who says which quote and newly discovered characters entering the voice map automatically. And search tools can give the writer a live web search, or run a pre-request agent that writes results into world info before the reply starts.

The container binds to loopback and mounts four host directories

The deployment configuration is short enough to read as a security decision. The compose file runs the published image, names the container, maps a single port bound to the loopback address rather than to all interfaces, mounts four host directories into the container, and restarts unless stopped. Loopback binding is the one to notice: out of the box the service is reachable from the machine it runs on and not from the network, which is the correct default for something holding chat logs and API keys. The four mounts are plugins, config, data and extensions mapped into the third-party extensions directory, so the paths a power user tends to edit are all persistent and all outside the image. The image build is more opinionated than a typical application container. It installs its own system tools rather than inheriting them from the base, sets production mode, installs dependencies with scripts disabled, and then does something clever: it removes the config file and recreates it as a symbolic link into a config directory, with a comment explaining that this is needed for non-root mode and for running without volumes. Public libraries are pre-compiled at build time, and an init wrapper handles signal delivery so the container stops cleanly.

Editorial conclusion

Use it if you already live in SillyTavern and have hit the two walls this project names, because that is the design brief and the compatibility claim is the reason migration is not the obstacle. Cards, world info, presets and chats move both ways, so the decision is whether the memory graph and the orchestrator are worth a fork. Do not adopt it for the smaller features, since most of them are conveniences around an existing workflow. Three things to check before you commit. Which execution mode you want, because a fixed pipeline and a dynamic one produce very different replies and the default is not specified here. Whether the Android app is your target, since it is the whole platform rather than a client. And how you deploy, because the container image binds to loopback only and mounts four host directories, which is a sensible default you will need to change deliberately rather than by accident.

Frequently asked questions

Official sources

1. funnycups/Luker on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases