SillyMemory 0.3.0 (experimental)

SillyMemory 0.3.0 — experimental pre-release

Long-term memory for SillyTavern. Powered by LambdaDB.

Release boundary: 2026-10-04. Confirm publication through the
GitHub Release.
Install from https://github.com/lambdadb/SillyMemory, leaving the branch field
empty to follow main; no build step is required.
Supported host: SillyTavern 1.19.0, commit
06bde939fb1e9c4c8d8641d810f0a916b5bce127. Other host versions are unverified.

What changes

• Optional versioned story memory shares committed history across native chat
  branches. Each chat path has a writable LambdaDB branch in its story collection.
  Unchanged inherited documents do not require another embedding submission.
• Named checkpoints save the native transcript, hidden swipes and chat metadata
  together with a retained memory branch. Resume creates a new chat/path; it does
  not overwrite the source. The manager lists ready/pending/invalid states and
  supports retry, resume, rename and individually scoped deletion.
• Interrupted preparation/resume can be retried. Changed checkpoint content,
  duplicate identities, missing branches and mismatched snapshots are rejected.
• Ordered commit confirmation can reduce repeated reads while waiting to fork.
  It keeps conservative full checks when write history is unknown or ambiguous,
  and always verifies the complete checkpoint contents before readiness.

Retrieval, chunking, memory budget defaults and recent-message protection are
unchanged from 0.2.0. This release adds history reuse and checkpoint lifecycle
behavior; it does not claim improved answer accuracy or consistently lower latency.

Update and opt in

Back up SillyTavern data first. Use Manage
extensions → SillyMemory → Update, then reload. Enter the LambdaDB key again
and enable memory when ready. The key remains session-only. Direct browser CORS
and LambdaDB managed embeddings remain in use; no separate embedding-provider key,
server plugin, proxy setting or host restart is required.

Updating alone leaves existing per-chat memory in use. As in 0.2.0, a new client
session can resubmit unchanged documents in that layout; the zero-upsert reuse
checks apply to opted-in versioned branches. To enable reuse for a
selected story, connect, prepare memory, select a saved character chat and click
Use versioned memory for this story. Confirm and enable memory. Initial opt-in
indexes older local history into a new story collection, consuming managed
embedding/storage usage. Old per-chat data is preserved for explicit cleanup;
there is no automatic bulk migration or deletion.

For that story, enter an optional name and click Save / finish checkpoint.
Memory stays disabled afterward. Use Refresh story checkpoints and Resume
to create a new path, then enable memory. A pending save can use Finish / retry.
Commit waiting may take minutes; an upsert acknowledgement alone does not mean a
snapshot contains the write. See versioned memory,
checkpoint recovery and integrity and
commit confirmation.

Cleanup, backup and rollback

Delete this chat's remote memory removes its branch in an opted-in story;
other paths/checkpoints remain. Delete all owned remote memory removes owned
story families, checkpoint branches and old per-chat/shared collections. Native
chat files remain, but their old checkpoints can no longer resume without their
remote branches. Native chat deletion and extension uninstall do not automatically
remove remote memory. Removing a branch is not proof of physical snapshot erasure.

A checkpoint includes chat transcript/swipes/metadata, not character cards,
World Info, files, model configuration or external state. Native host files and
the installation's owner identity are required; LambdaDB alone is not a complete
backup or cross-device setup. Keep a native host-data backup.

Disable memory before code rollback. Version 0.2.0 cannot manage smstory_*
collections or checkpoint controls and uses its former per-chat layout. Use
0.3.0 cleanup before a permanent downgrade if remote removal is wanted; do not
delete remote memory merely to switch versions. Pinning v0.2.0 changes code,
not transcripts, metadata or remote writes. The upgrade test checks code rollback
after test-data cleanup, not reversal of live versioned metadata.

Evidence and limits

See the 0.3.0 validation record for installation acceptance
and exact producer boundaries. Historical lifecycle/recovery and 1,000-message
reuse evidence remains linked in the feature documents. No new answer-quality
evaluation is included; the historical results remain
qualified by their original datasets and producers.

One active writer is required. Concurrent devices, other extensions editing the
same native files, and out-of-band remote writes are unsupported. Local-file and
remote-branch operations are not a distributed transaction. Long-duration
snapshot/expiry correctness is assumed from LambdaDB, not newly measured here.
A retained checkpoint branch must still exist and remain unchanged for resume.

Licensed under AGPL-3.0-only. Experimental status is not a stable-support
commitment.