DEV Community: Foreverse

SillyTavern on Android: Termux vs Cloud vs Native App, the Real Trade-offs

Foreverse — Sun, 26 Jul 2026 11:06:40 +0000

Originally published on the Foreverse blog.

SillyTavern is a Node.js server that happens to draw a chat window. That one architectural fact decides everything about phones: Android treats long-running background processes as a problem to be solved, and a self-hosted web server is exactly the kind of process it solves. Every "SillyTavern on Android" thread is really arguing about a single question. Where should the server live?

Three answers exist in 2026: on the phone itself inside Termux, on a rented machine somewhere else, or nowhere, because a native app replaced the server entirely. Disclosure before anything else: we build Foreverse, the app in that third road, so weigh our judgment accordingly. We have tried to describe the first two roads the way their own communities describe them, because each of the three is the right answer for somebody.

Why is a phone the hard case for SillyTavern?

Desktop SillyTavern assumes a machine that stays awake. The Node server holds your cards, chats and API keys, and a browser talks to it at localhost:8000. Phones break the assumption: Android suspends and kills background work to save battery, so the server half of SillyTavern needs life support (Termux), different housing (a cloud box), or replacement (a native app).

That is the entire decision tree. Everything below is the concrete version of it.

Road one: Termux, where the install is easy and staying alive is not

The official Android route puts a Linux userland on the phone and runs the server there. Four commands, per the official Termux guide:

pkg update && pkg upgrade
pkg install git nodejs
git clone https://github.com/SillyTavern/SillyTavern -b release
cd SillyTavern && ./start.sh

Then open localhost:8000 in Chrome. Cost: zero dollars, full data ownership, every extension the desktop build has. The bill arrives later, as process management.

The first trap sits before the first command: the Termux build you want comes from F-Droid, not the Play Store, whose listing has been stale for years. That alone filters out the half of the audience that has never sideloaded an app store.

The second trap is the one people write forum posts about at 2am. Since Android 12, the OS enforces a system-wide cap of 32 "phantom" child processes and kills the excess without telling you; a Node server spawned from a shell session is a textbook phantom process. The Termux tracking issue for this, termux-app #2366, has been open for years. The standard workaround needs a PC:

adb shell device_config put activity_manager max_phantom_processes 2147483647

and on many devices it quietly reverts after a reboot unless you also disable config syncing. termux-wake-lock and a battery-optimization exemption help with ordinary screen-lock kills, but vendor ROMs from Samsung, Xiaomi and friends layer their own process killers on top of stock Android's, and they do not read your wake lock as a promise.

Updates are a smaller, steadier tax: git pull, reinstall dependencies, wait while native modules rebuild on a phone CPU. If you enjoy terminals, none of this will scare you, and an 8 GB flagship handles the load fine. This road rewards exactly one kind of person: the one who reads a process-lifecycle bug report for fun.

Road two: the cloud, where battery problems become ops problems

Host SillyTavern on a small VPS for $3–6 a month and every phone limitation disappears at once. The server never sleeps, any browser can reach it, chats and cards follow you across devices. The trade: you now administer a public web server that holds your API keys, and the configuration that keeps strangers out is your job, not a default.

Out of the box SillyTavern only answers localhost. Opening it to your phone means setting listen: true, dealing with the IP whitelist that is on by default, and enabling basicAuthMode so the login page exists at all; the official docs walk through each switch, and they are blunt about why. Port scanners find naked instances. An unauthenticated tavern on a public IP is somebody else's free API key the day it is discovered.

Latency, the objection people expect, mostly is not one: the model call leaves from the server, so the phone only pushes UI traffic. The real recurring cost is quieter. Distro updates, a Node upgrade that breaks the build, a disk that fills with chat logs and generated images, a TLS certificate that expires on a weekend. None of it is hard. All of it is yours. This road fits people who already run a VPS for something else, anyone living across three devices, and every iPhone user, since iOS has no Termux equivalent at all.

Road three: a native app, where the server stops existing

A native tavern app ships the chat runtime inside an ordinary Android app. No Node process, no Termux session to babysit, no VPS invoice. The evaluation question changes shape: not "will it stay up?" but "does my stuff import?" Cards, lorebooks, presets, regex pipelines, group chats, and the API keys you bring with you.

Concretely, for our own entry in this lane: Foreverse imports PNG cards (v2 and v3 chara chunks), JSON cards, and .charx archives; lorebooks both embedded and standalone, including chara_card_v3 decorators; presets; regex scripts; SillyTavern group chat JSON; and cards fetched straight from a Chub, JanitorAI, Pygmalion or RisuRealm URL. We regression-test that claim against a collection of 1,500+ community files across 38 categories; in the last breadth matrix we drew from it, all 30 character cards imported 30/30 and rendered their opening screens 30/30, old English V1 relics included. Keys are BYOK across 62 providers, encrypted on the device, with calls streaming directly to the provider you configured.

The honest gap: there is no third-party extension runtime. A desktop install with a hand-picked extension stack still wins any feature-checklist fight, and a few power features, vector-storage lorebooks and exact per-model token budgeting among them, are approximations on mobile today. Before switching, write down the three extensions you cannot live without and check each one by name. If one of them is load-bearing for your workflow, roads one and two are still your roads.

How do you choose without locking yourself in?

Choose by the failure you are most willing to debug: process death (Termux), server administration (cloud), or a missing desktop extension (native app). The choice is lower-stakes than it looks, because the tavern ecosystem's file formats are the portable part. Cards move as PNG, JSON or charx; lorebooks as World Info JSON; presets and regex as JSON. Only chat histories need care.

Keep the exit open. Before you commit to any road, export your cards as original PNGs and your lorebooks as JSON, and park a copy somewhere that is not the phone. We wrote a separate walkthrough on moving a SillyTavern data folder; the short version is that the formats are the contract, and any road that honors them is reversible.

Our own answer is on record and biased: we built road three because we kept watching the same story — someone installs Termux, it works, a screen lock eats a session mid-scene, they post the phantom-process incantation, it reverts after a reboot, they give up or rent a VPS. Foreverse removes the process Android wants to kill instead of defending it. What it does not yet do is replicate a decade of desktop extensions, and we would rather say that here than have you discover it after the move.

FAQ

Can I run SillyTavern on Android without Termux or a server?

Not the desktop build itself: it is a Node.js application and needs a Node runtime somewhere. What you can do is run a natively built tavern-style app that reads the same files (PNG/JSON/charx character cards, World Info JSON lorebooks, presets, regex scripts) and keeps everything on the phone. Check the app's import coverage against your own library before committing.

What is Android's phantom process killer, and can I turn it off?

Since Android 12, the OS caps background child processes (like a Node server spawned inside Termux) at 32 system-wide and silently kills the excess. You can raise the cap with adb from a PC: device_config put activity_manager max_phantom_processes 2147483647. On many devices the setting reverts after a reboot unless you also disable config syncing, and aggressive vendor ROMs add their own killers on top.

Is it safe to put a SillyTavern instance on a public VPS?

Only with authentication configured. SillyTavern ships with a whitelist that blocks remote access by default; to open it up safely you enable basic auth (and ideally TLS via a reverse proxy or tunnel) rather than just disabling the whitelist. Port scanners do find unauthenticated instances, and an open one exposes your API keys and chat history.

Do lorebooks, presets and regex scripts move between the three roads, or only character cards?

The whole kit is portable in principle: cards are PNG/JSON/charx, lorebooks are World Info JSON, presets and regex scripts are JSON too. Portability in practice depends on the destination's import support, so test your most complex lorebook and your regex pipeline first. Chat histories are the least portable part; export them before you move.

Our LLM Judges Called Human Writing "AI-Flavored" 88% of the Time

Foreverse — Sat, 25 Jul 2026 12:41:50 +0000

The setup was textbook. Four LLM judges on different base models. Double-blind pairs. Both presentation orders, to cancel position bias. Gold anchors seeded into the pool — samples where humans had already reached a verdict, including character-card copy a real user had flagged as "obviously AI" on sight, and community cards written by humans that had accumulated over a million conversations.

All the judges had to do was answer, for the anchors, "which of these two reads more human?" They scored 12%.

Failure one: not noisy — inverted

Twelve percent is the interesting kind of failure. A coin flip scores 50%; a noisy judge hovers around it. Scoring 12% means the panel was confidently wrong in a consistent direction: the copy humans called AI, judges praised as "grounded, textured, clearly human"; the human-written hits, judges dismissed as "formulaic, likely generated."

Failure two: agreement without accuracy

Pairwise agreement across the four judges was 86%. Before the experiment we'd planned to use majority voting for robustness. That plan died here: voting cancels independent random errors, but these errors weren't independent — the judges shared the same learned bias and converged on the same wrong answers. High consensus made the panel look more trustworthy while being reliably backwards. Separately, in about a third of the pairs, simply swapping presentation order flipped the verdict — position bias is a documented LLM-as-judge failure mode (the MT-Bench paper measured it systematically); we just met it again in our own data.

The bias, named. Reading the judges' rationales, two substitutions kept surfacing: they treated detail density as humanity, and ordinariness as fakeness. AI-polished copy — precise numbers, perfect structure, a hook per paragraph — read to them as "lived-in." Human copy — with its filler, lazy adjectives, and repetition — read as "generic." One detail stung: community-style stat-bar formatting in human cards was cited as "evidence of real community interaction"… and the same formatting in our imitation cards earned the same praise.

Failure three: prompting rescues one model family, not the rest

After the first round collapsed, we ran a dedicated calibration round — corpus expanded to 17 pairs, more heterogeneous judges — with an explicit debiasing preamble spelling out, among other things, that detail density is not evidence of humanity. A Claude-family judge jumped to 83% (the original four-judge setup had scored 12%): its bias lived at the prompt layer. DeepSeek, GLM and Qwen didn't move past 25–33% with the identical preamble; their prior sits deeper than instructions reach — they even cited the community stat-bar formatting our imitation cards copied as "evidence of real community interaction." Even the rescued judge only barely clears the calibration bar we now enforce, so "barely usable, single configuration" is the honest summary.

The rule we adopted

One sentence went into our engineering standards after this: an LLM judge that has not passed gold calibration (≥80% on human-consensus anchors) must not be used as an optimization target. Not for scoring, not for regression gates, not for leaderboards. Our current stack is three layers: a rule-based detector (phrase blacklists plus sentence-pattern quotas, calibrated against real user judgments — we once had to fix a rule that false-flagged human scenery writing, after which human samples scored clean) as the daily gate; human spot checks as ground truth; LLM blind review only for relative before/after comparisons of the same text.

And the honest boundary: we hold samples of carefully templated AI copy that dodge every pattern rule and sail past both the detector and the judges. The deepest layer of AI flavor lives in whole-text texture — uniform detail density, zero idle sentences, immaculate structure — and nothing automated currently catches it. What catches it is still a well-read human, reading aloud, frowning at the right moment.

Originally published on the Foreverse blog. We build Foreverse, an Android AI reading app; this calibration round is part of the public eval data behind the product's AI-flavor detection.

We Ran 360 Rounds of AI Novel Continuation. Models Fail Long Fiction in Exactly Three Ways

Foreverse — Sat, 25 Jul 2026 12:41:38 +0000

We have now run 360 rounds of novel continuation across nine models and two books — an 8.9M-character Chinese fantasy epic and the palace-intrigue classic Empresses in the Palace. Same protocol every time: continue from a fixed anchor, 20 consecutive rounds, each round's output appended back into a fixed 16k-token window, then double-blind review with two randomized letter mappings. Every long-run failure we observed fits one of three patterns.

Pattern one: the restart loop

The model ignores everything generated so far and restarts from the original text's ending — every single round. Gemini 3.1 Pro did this for 20 out of 20 rounds in the fantasy run: twenty phrasings of the same opening instant, a story that never takes its second step.

The root cause was ours, not the model's. Our context labels which passages are original prose and which are earlier AI continuations, and the explanation line said AI passages were "for plot continuity reference". Gemini read "reference" as "not canon" and skipped them all. Three ablations pinned it: old wording, 20/20 restarts; label with no explanation at all, still roughly 6 of 8 rounds restarting; explanation rewritten to state the passages are canonical events that must be treated exactly like original prose — zero restarts in 28 rounds across both books. One sentence of prompt wording was the entire difference between disqualification and mid-table.

Pattern two: the mid-run freeze

The model advances normally, then locks onto its own recent output and repeats it verbatim. Grok 4.5 froze in the middle windows of the fantasy run — one stretch repeats the same two paragraphs three times word for word — then partially recovered. On the palace novel it froze harder: both blind reviewers independently wrote "plot rewind" in their notes, and across twenty rounds the story clock never left the afternoon of the inciting incident. Kimi K2.6 showed a milder version, copying whole passages from its own earlier rounds.

This is the classic autoregressive fixed point: as the context fills with the model's own text, imitating itself becomes easier than advancing. It is also why one-shot writing benchmarks miss it entirely — the loop needs rounds to build up.

Pattern three: the ending rewind

The strangest one, and it hit the best prose mimic in the field. GPT-5.6 Terra's early and middle windows were, by both reviewers' judgment, the closest thing to the original author anyone produced — it even reproduced micro-habits like tilde-marked onomatopoeia and the author's trademark comma rhythm. Then in rounds 18 through 20 it rewound the entire plot back to the anchor point and replayed chapter one, reusing lines from its own round-2 output. Texture stayed perfect; the story folded back on itself.

The lesson we take from it: surface mimicry and long-range plot coherence are separate capabilities. A model can hold an author's voice flawlessly while losing track of where the story is. On the palace novel, for what it's worth, Terra never rewound — it took first-tier placement with a zero-incident run.

What survived twenty rounds

DeepSeek V4 Flash won the fantasy run outright — the only system both reviewers called "improving as it goes", still opening new plot arcs at round 20. Then it dropped to sixth-seventh on the palace novel, where its plain-spoken instincts fight the author's ornate register, and its sibling V4 Pro — criticized in fantasy for writing "like a finer-penned author" — took first place, because a finer pen is exactly what that book is written with. GLM 5.2 was the only model in the top three of both genres, with one persistent quirk: half-width quotation marks in Chinese prose, in every run, on both books.

No universal ranking survives contact with a second genre. If your app locks you to one model for a whole book, that is a real cost; per-paragraph model switching on continuation is not a luxury feature, it is how you route around each model's failure pattern before it locks in.

Originally published on the Foreverse blog. We build Foreverse, an Android reader that lets you continue any novel with AI — every direction becomes a branch, the original text stays intact. The eval data behind our model choices is public.