# Six ways to install, none of them sharing data, and a 95 percent cache claim with no benchmark

> dsh-tavern wraps DeepSeek Harness as a text game agent that imports SillyTavern character cards. Its readme is unusually concrete about the costs of each route: six installation methods whose data directories do not share, a phone feature that a command line install deletes, an Android APK still served from an older release, and speed numbers that rest on user screenshots rather than measurement.

**flizzywine/dsh-tavern** — 基于 DeepSeek Harness（DSH）的 SillyTavern 类文字游戏 Agent，支持候选项生成、对话式人物卡编辑、剧本模式与素材抽取。

- Repository: https://github.com/flizzywine/dsh-tavern
- Stars: 601 · Forks: 45
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/flizzywine-dsh-tavern

## Six installation routes, and the data directories never meet

There are at least six ways in, and the readme states plainly that they do not share state: updates preserve your character cards, chats and settings, and the data of each installation method is kept separate. That single sentence is the most important operational fact in the document, because the obvious move for a user is to try the quick route, dislike it, and install properly, and that path silently starts from nothing.

The routes are a Windows installer executable for x64, an Android APK for Android 11 and above on ARM64, installation through DSH Desktop on Windows and macOS, installation through DSHA on Android, a command line route needing Node.js 22.19 or newer, and a standard plugin install for people who already have a compatible harness. The last of those is labelled experimental rather than stable.

The Windows installer is the only route that claims to be self contained, promising no separate Node.js and no separate DSH Desktop. The command line route inverts that, needing Node.js but no harness at all. The APK route is fully automated too: install, open, tap start, stay online while it installs itself, then enter the tavern, with no commands typed and no DSHA installed separately.

So the choice is not between equivalent paths to the same place. Each one provisions a different amount of the stack, and the upgrade that preserves your data preserves only the data of the route you are on.

## The Android APK is still served from v2.1 while Windows ships from v2.4

The two one click installers point at different releases. The Windows executable is fetched from the v2.4 release, while the Android APK link points at the v2.1 release assets. Three release tags separate them, and the release history shows what landed in between: v2.2 for long conversation optimisation, failure recovery and multi device play, v2.3 for card editing memory, MVU creation and save synchronisation, and v2.4 for a save refactor and very long conversation performance.

An Android user following the readme therefore installs a build from before all three of those, while a Windows user gets the save refactor. Both are described the same way, as one click installs.

The Windows file name carries a second piece of information. It is `DSH-Tavern-Desktop-2.0.13-x64-Setup5.exe`, so the installer bundles DSH Desktop version 2.0.13, which matches the version the separate DSH Desktop route tells you to install. The trailing Setup5 indicates the installer has been repackaged at least five times, and the readme attributes the current one to a fix for install timeouts on slow networks or when a system proxy is enabled. That is a useful fix to have in a network dependent installer, and it is also a reminder that the artefact is a repackaged binary rather than a plain build output.

So there are two things to check if you are on Android: whether a newer asset has appeared in the release you are pointed at, and whether your saved chats survive the move once you upgrade to the refactored save format that v2.4 introduced.

## The installer pipes an unpinned branch into a shell

The command line route for macOS, Linux and WSL2 is one command:

```bash
curl -fsSL https://cdn.jsdelivr.net/gh/flizzywine/dsh-tavern@main/install.sh | DSH_TAVERN_HOST=cli sh
```

Two things are worth pausing on. The URL names the `main` branch of the repository rather than a tag, so the script you run is whatever is at the head of that branch when you run it, and the same is true of the PowerShell equivalent, which downloads the script's bytes, decodes them as UTF-8 and evaluates them in the session. You are executing unreviewed code from a mutable reference, by design, as the documented happy path.

The delivery is via a public CDN in front of GitHub rather than a release asset. That is a reasonable way to keep one URL working across platforms without publishing six copies of a script, and it also means the installer is fetched from a third party host whose content is a mirror of the branch you named.

The rest of the flow is conventional: the browser opens automatically after install, and two commands cover the rest of the life of the installation, `dsh-tavern open` and `dsh-tavern update`. There is also an in application update button that preserves cards, chats and settings and asks for a restart, and it is the route the readme recommends once you are inside.

One version constraint applies to all of it: the host is adapted to a specific harness build, 0.1.5-rc.2, and the readme asks you to use the matching version from the documentation. That is a pre release, so a harness update on the host side is the thing most likely to break this installation.

## A command line install deletes the phone feature and its toggle

Remote play from a phone is one of the more attractive features in a text game agent, and the readme handles it in two ways. The tavern can run on a computer or a server and be played from a phone browser, either by scanning a QR code from a computer with a companion project, or by putting a login in front of the remote web interface with a different companion project. The first is configured automatically by the Desktop installer and can be pointed at a local network or the public internet from the settings. The second one needs you to supply a reachable server address, and the readme is explicit that the plugin does not provide any kind of network traversal.

Then the caveat: Pocket phone access is offered by the Desktop build only, and a command line install or upgrade removes Pocket along with its on/off switch. So the route you pick at install time determines whether the feature exists afterwards, and there is no note about restoring it other than reinstalling through Desktop.

That is an unusually clean statement of a limitation. It is also the sharpest example of the general pattern in this readme: features are attached to specific install routes rather than to the product, and the documentation says so in the same sentence that describes the feature.

Both remote access routes are third party repositories, credited by name in the readme, which is the right way to point at a dependency the core project does not ship. Neither is described as maintained by the project, so their lifetimes are their own.

## Ten seconds a turn and 95 percent cache, with nothing behind either figure

The feature list contains two numbers, and they are the numbers a reader will remember.

One is speed: a round of interaction takes about ten seconds, with no long waits. The other is cache: a cache hit rate above ninety five percent. Paired with those is a third claim that context is read on demand, only pulling what is currently needed, to cut wasted tokens, and a fourth that a built in memory retrieval tool keeps long play coherent.

None of the four has a measurement attached. There is no model named, no token count, no context size, no hardware, no concurrency setting and no definition of what a cache hit means here, whether it is a prefix cache at the provider, a local reuse of an identical prompt, or something the harness tracks. A ninety five percent hit rate against a prefix cache and against a local prompt cache are very different claims about your bill and your latency.

What does support the performance story is twenty two screenshots of user feedback, and their file names are themselves informative: long chat memory, cache and cost, long session cache hit, cache hit feedback, reply speed, local 27b, more alive and faster. Those are reports from people, and the file name mentioning a 27b model suggests the answers vary with the model the user brought.

So the honest reading is that the author reports a fast, cache friendly system and has not published the figures that would let you check it. That is common in this category and it is worth pricing accordingly, because both claims scale your cost.

## A restore point that expires the moment you generate again

The free play mode lets you type freely or pick from independently generated candidate actions, with ongoing guidance, rewrite with feedback, and rollback. The rollback is the interesting part, because it can itself be undone. If you roll back by mistake, an undo action in a menu restores the text and state of that most recent rollback. And the moment you start a new generation or make an edit, the restore point is invalidated.

That is a precisely stated rule about a state machine, and it tells you the implementation keeps one rollback of the last rollback rather than a stack. Two generations of undo is what you get. It also means the safety net disappears as soon as you act, which is exactly when a user who just rolled back by accident is most likely to act.

The design decision around it is that candidate actions and background state are handled separately, so the prose carries less formatting weight. Script mode adds a further layer, showing script progress and a reference excerpt for the current round on the right rather than stuffing an entire novel into the context, which is the same on demand context claim applied to a long source.

The card pipeline is similarly explicit about what is preserved. Importing a character card keeps the original, and discussion happens before any change is made, with modifications applied to a working version. Cards arrive as PNG or JSON, with regex beautification and HTML display, and MVU variables are updated by a background agent while a status bar stays visible on the right.

## Compatibility with the wider ecosystem is scoped to whichever API a script uses

The project positions itself against the SillyTavern ecosystem, which is its entire premise: it imports those character cards and calls itself a SillyTavern style text game agent. The compatibility claim is careful rather than absolute. Character cards, presets, world books, assistant scripts, MVU and regex are supported, and most assistant scripts can be used directly. Then the qualifier, twice, in two different sections: the exact compatibility depends on which interface a given script uses.

That is the right shape for a claim like it, because third party scripts in that ecosystem reach into a host through specific interfaces, and there is no way to support all of them without becoming the host. It also sets the expectation that a script which pokes at an undocumented hook may not run.

Two capabilities sit outside the core and are gated accordingly. Scene illustrations for a plot are generated manually, on demand, with feedback and version switching, and are off by default, requiring a separately configured image service. The image generation code is a separate workspace package in the tree with its own build and test scripts, so it is an optional component rather than part of the main client.

The remaining surface is extension oriented. Users can write, install and combine harness plugins themselves, and updates preserve plugins and configuration the user added. That is a compatibility statement as much as a feature: your additions survive a version bump, which is the thing that usually breaks in this kind of plugin host.

## A support channel behind a membership gate, and logs that contain your conversations

Support runs through a Discord discussion channel, and there is a gate on it: entry requires membership of a particular community. So the place to report a bug is not reachable by installing the software. That is a deliberate choice about where the project's conversations live rather than a defect, but it does mean the support path and the install path are controlled by two different rules.

For bug reports there is a specific instruction about evidence. An execution log can be downloaded from the top of the conversation, and the readme asks you to check the conversation and attachment privacy inside it before sharing. That is worth taking seriously rather than treating as boilerplate: an execution log from an agent that handles character cards, world books, imported text files and image generation is a record of what you sent it, not a stack trace.

The rest of the project surface is documentation hosted on the author's own GitHub Pages, with a getting started guide and an install and troubleshooting anchor inside it, a feature guide, and separate documents for memory format, Windows distribution and phone access. The readme states plainly that the documentation site is not itself an online game service, which is a small courtesy that stops people from expecting to play there.

One contributor is credited by name for sustained detailed bug reports, reproduction steps, performance analysis and fix suggestions, along with verifying improvements across long sessions, background tasks and interface stability. The project records that publicly, which is how you tell which of its numbers rest on other people's measurements.

## Conclusion

dsh-tavern is worth trying if you already live in the SillyTavern card ecosystem and want an agent that keeps a long session coherent, and the readme tells you more about how the thing actually behaves than most projects of this type do. Two things to decide before you install. Pick your route once and stay on it, because data directories are kept separate per install method, so changing your mind costs you your cards, chats and settings rather than a file copy. And if phone access matters to you, take the Desktop build, since a command line install removes the Pocket feature and its toggle entirely. On the performance claims, treat roughly ten seconds a turn and a cache hit rate above ninety five percent as the author's reports rather than measurements: there is no model, no hardware and no token count behind either figure in the visible documentation, only screenshots of other people's conversations.

## FAQ

### How do I install dsh-tavern, and which route should I pick?

Six routes are documented: a Windows x64 installer that needs no Node.js and no separate DSH Desktop, an Android 11+ ARM64 APK, installation through DSH Desktop on Windows and macOS, through DSHA on Android, a command line route needing Node.js 22.19+, and an experimental standard plugin install. Data is kept separate per route, so pick one and stay on it.

### Do character cards, chats and settings survive an update in dsh-tavern?

Yes, updates preserve cards, chats and settings within the same installation method. The readme states that each installation method keeps its own data, so moving between routes does not carry them over.

### Can I play dsh-tavern from my phone?

The tavern can run on a computer or server and be played from a phone browser, via a QR code companion project or a login wrapper for the remote web interface, which does not provide network traversal. Pocket access itself is Desktop only: a command line install or upgrade removes it and its toggle.

### How fast is dsh-tavern per turn, and how good is the cache?

The readme reports about ten seconds per round of interaction and a cache hit rate above ninety five percent, with context read on demand. No model, hardware, token count or definition of a cache hit is published with those figures, so treat them as reported rather than measured.

### Will SillyTavern assistant scripts work with dsh-tavern?

Cards, presets, world books, assistant scripts, MVU and regex are supported and most assistant scripts can be used directly, but the readme qualifies this twice by saying exact compatibility depends on which interface a script uses. Image generation is off by default and needs a separately configured service.

## Sources

- [flizzywine/dsh-tavern on GitHub](https://github.com/flizzywine/dsh-tavern)
- [Issues](https://github.com/flizzywine/dsh-tavern/issues)
- [License: AGPL-3.0](https://github.com/flizzywine/dsh-tavern/blob/main/LICENSE)
- [README](https://github.com/flizzywine/dsh-tavern/blob/main/README.md)
- [Releases](https://github.com/flizzywine/dsh-tavern/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flizzywine-dsh-tavern