Luker: a SillyTavern fork that moves generation state to the backend
LLM Frontend for Power Users. Better SillyTavern.
At a glance
- What is it?
- Luker is an AGPL-3.0 fork of SillyTavern whose fork notes describe patch-first persistence, a backend-owned generation lifecycle and a plugin-first extension model. The interesting question is not the chat UI, which is inherited, but whether those API changes are worth switching a working SillyTavern install for.
- Who is it for?
- Luker is aimed at people who write SillyTavern extensions or run long, reconnect-prone sessions, and the fork notes give them a concrete migration target: read docs/luker-api-migration.md and check whether your extension calls chat append/patch or still relies on full-save payloads. If you only chat through the stock interface and never touch getContext(), the fork offers you nothing the upstream README does not already describe, and you inherit a smaller test surface.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The fork exists for extension authors, not for chat users
The README is inherited from SillyTavern nearly verbatim, including the badge block that still points at SillyTavern/SillyTavern, the Discord invite, the contributor list and the installation links to docs.sillytavern.app. The only Luker-specific section is a short block titled Luker Fork Notes, and it defines the project in one line: a fork of SillyTavern focused on cleaner API design and stronger extension capabilities. That is the whole scope statement. Everything else in the README describes the parent project: a locally installed interface for text generation LLMs, image generation engines and TTS voice models, with WorldInfo lorebooks, Visual Novel Mode and an extension system.
So the audience is narrow and specific. If you write plugins against SillyTavern's client-side state, or you run sessions long enough that a dropped connection mid-generation matters, the fork notes describe problems you have probably hit. If you install a frontend, pick a character card and chat, the fork notes describe nothing you will notice. The README does not claim otherwise, which is at least honest, but it also means the inherited documentation describes a UI that Luker has partially rewritten underneath.
Patch-first persistence and the payload it is meant to avoid
The first fork note reads: "Patch-first persistence (chat append/patch, metadata/state patch, and settings patch) to avoid repeated full-save payloads." Read that as a statement about write amplification. In a full-save model, every state change serialises the entire chat and settings object and sends it to the backend. A long roleplay chat with a large lorebook attached produces a large payload on each turn, and the cost grows with the history rather than with the change. The patch model replaces that with three narrower operations: append or patch a chat, patch metadata and state, and patch settings. Only the delta moves.
The mechanism implies a merge step on the receiving side, and the README does not describe how conflicts are resolved when two clients patch the same chat. That is a real gap, not a nitpick, because the fork notes present patch-first persistence as the headline change while the migration guide is the only place that could plausibly document the merge semantics, and the README only links to it. Whether a patch is applied as a shallow merge, a JSON Patch operation or something else is not stated in the supplied material. If you run one browser tab against one backend, the distinction rarely surfaces. If you run several, it decides whether your state survives.
Backend-owned generation changes who holds the stream
The second fork note is "Backend-owned generation lifecycle (including reconnect-safe persistence and active-output recovery behavior)." This is a bigger architectural claim than the persistence one. In a client-owned model, the browser opens the request to the model provider, streams tokens into the page, and writes the result when the stream ends. Close the tab, lose the network, or let the phone sleep, and the generation is gone along with whatever partial output existed.
Moving the lifecycle to the backend means the server holds the request and the accumulating output, and the client reattaches to it. The phrase "active-output recovery behavior" in the fork notes implies there is a path for a client to ask what is currently being generated and resume from it. The README does not specify the reconnection protocol, the timeout after which an abandoned generation is discarded, or whether recovery works across a backend restart rather than only a client reconnect. Those are the questions that decide whether this feature is useful in practice, and the supplied material does not answer them. Treat the claim as a direction, not a specification.
Plugins get getContext() and world-info hooks
The third and fourth fork notes are the ones an extension author should read twice. "Plugin-first helpers via getContext() and generation world-info hooks" and "Built-in Orchestrator and Memory plugins." The getContext() helper is a single accessor for whatever a plugin needs from the host, which is a common pattern and a sensible one: it gives the fork a place to add capabilities without breaking every plugin that already destructures the host object directly. The world-info hooks during generation are more specific. WorldInfo in SillyTavern is the lorebook system, and hooks that fire during generation let a plugin inspect or alter which entries are injected rather than only reading the final prompt.
Orchestrator and Memory shipping as built-in plugins is the clearest signal of intent in the whole README. The fork is not only exposing hooks, it is using them for its own features, which is the only way to know an extension API is exercised. The README gives no description of what Orchestrator or Memory actually do. Given the names, one plausibly sequences model calls and the other manages long-term context, but that is inference, and the supplied material does not confirm it. Anyone evaluating Luker for its plugins should read the source or the migration guide rather than the README.
Running it looks exactly like running SillyTavern
There are no Luker-specific installation instructions. The README routes to the SillyTavern documentation site for Windows, macOS and Linux, Android via Termux, and Docker, and the hardware note is inherited unchanged: anything that runs NodeJS 20 or higher, with a 3000-series NVIDIA card and at least 6GB of VRAM suggested only if you do local inference. The default branch is release, and the recent releases listed are v2.6.0 and v2.6.1 in June 2026, followed by v2.7.0 on 2026-06-13, with the last push to the repository on 2026-09-06.
That branch name matters if you clone. A fork that keeps its working code on release and its development elsewhere means a naive clone of the default branch is the safer choice, and a checkout of an unlisted development branch is not. The README does not name a configuration file, an environment variable, or a startup command, so the only concrete artifact it points at for setup is the parent project's installation documentation. The one Luker-specific file path in the entire README is the migration guide at docs/luker-api-migration.md on the release branch.
The migration guide is the real documentation, and the README admits it
Every one of the four fork notes describes a change that breaks something. Patch-first persistence changes how the frontend talks to the backend. A backend-owned generation lifecycle changes who owns the stream. getContext() and world-info hooks change what a plugin can call. The README's response is a single link: "Plugin/API migration guide: docs/luker-api-migration.md." That link is doing an enormous amount of work for a document that is not reproduced in the README at all.
This is the fork's biggest practical weakness as presented. A fork that changes the persistence protocol and the generation lifecycle has to tell existing extension authors what stopped working, and the supplied material shows the pointer but not the content. Anyone with a working SillyTavern plugin should assume the migration guide is required reading and should not assume the inherited SillyTavern documentation site covers the forked APIs, because it is upstream's site and upstream has not made these changes. The German, Chinese, Traditional Chinese, Japanese, Russian and Korean READMEs are inherited alongside the English one, and there is no indication any of them carry the fork notes.
Upstream SillyTavern is the alternative, and the difference is who owns state
The obvious alternative is SillyTavern itself, and the README states the relationship plainly: Luker is a fork of it, beginning as a fork of TavernAI 1.2.8 in February 2023 in the parent's history, with the fork notes describing what Luker changed. The difference in approach is not features, since the feature list is inherited. It is where state lives. Upstream keeps the client in charge of generation and persists by saving the whole object. Luker moves the generation lifecycle to the backend and persists by patch. That single decision produces the reconnect behaviour and the smaller payloads, and it also produces the migration burden and the merge-semantics question.
The trade is asymmetric in a way worth naming. If you never lose a connection and never write a plugin, you pay the migration cost and receive none of the benefit. If you do either, upstream's model is the thing that frustrates you. There is no middle option in the supplied material: the fork notes do not describe a compatibility mode that keeps full-save behaviour available, and they do not describe a fallback for plugins that have not migrated. A third choice is to stay on upstream and patch around the specific problem you have, which keeps you on the larger project's release cadence and its documentation site.
AGPL-3.0 and the cost of tracking a fork
Luker is AGPL-3.0, the same licence family as the parent project, and the README carries the standard warranty disclaimer. The practical implication for anyone modifying and hosting it is the network clause: if you run a modified version as a service other people reach over a network, the AGPL requires you to offer them the corresponding source. That is a summary of the licence's well-known behaviour, not legal advice, and the full text is in the repository. If you are building a private extension for yourself, the clause is not what you should be thinking about.
The maintenance cost is the part the README leaves implicit. Luker tracks a parent project that has been in independent development for three years with over 300 contributors, according to the inherited README, and it has rewritten the persistence protocol and the generation lifecycle on top of it. Every upstream change that touches chat saving or generation now has to be reconciled rather than merged. The release history shows v2.6.0 and v2.6.1 a week apart in June 2026 and v2.7.0 shortly after, which is a normal patch cadence, but the README gives no statement about how the fork handles upstream releases or how far behind it tracks. For an extension author, that is the number that matters most and the one the supplied material does not provide.
Editorial conclusion
Luker is aimed at people who write SillyTavern extensions or run long, reconnect-prone sessions, and the fork notes give them a concrete migration target: read docs/luker-api-migration.md and check whether your extension calls chat append/patch or still relies on full-save payloads. If you only chat through the stock interface and never touch getContext(), the fork offers you nothing the upstream README does not already describe, and you inherit a smaller test surface. Verify two things before switching: that your frontend is on the release branch, and that the plugin API you depend on is covered by the migration guide rather than only by the fork notes.
Community notes