Soulstone

In plain words: Local Models overview

Operator validation 2 min read 6 glossary terms 13 connected pages

The short version written for the Snayu team

Describes a Local Model (Soulstone): a service running on your own machine in a rootless Podman container, defined by a Service Config File and supervised by systemd.

Why read it: Read this before adding or running a local model service.

1You declare image, models, devices, mounts, secrets and lifecycle in a Service Config File (Rune).
2Only warm models get Model Passes; the Stage Manager alone starts, loads or swaps them.
3Repository tests cover compilation and adapters; a real GPU run still needs operator proof.

Operator validation Built and tested in repo; awaiting real systemd/Podman/GPU proof.

Words on this page, decoded click one for its card

Where it sits in LychD

Local Model Soulstone

An AI model running on your own GPU or CPU, managed by LychD.

It's like: Your own generator in the basement: you start it, stop it, maintain it.

Click a dot to open that part's card.

Glossary page On the system map In the network

In this section 4 pages

Soulstone Rune Local model config file reference Reference for the Local Model Service Config File (Soulstone Rune): a TOML file under runes/animator/soulstones/<runtime>/ listing fields like image, port, devices, volumes, secrets and the model catalogue. open → Soulstone Disciplines Local model runtime families A short map of the built-in local model runtimes: vLLM (Kinetic), SGLang (Radix) and llama.cpp (Titan), plus how loading a model in a running server differs from restarting it. open → Soulstone Engines Local model engines index Index of supported inference engines for local services: vLLM, SGLang, llama.cpp, ExLlamaV3 via TabbyAPI, ComfyUI and audio.cpp, and which app or plug-in area owns each kind of output. open → Soulstone Resources and Secrets Local model devices, mounts, secrets Rules for what a local model service may receive: explicit devices, volume mounts, non-secret environment, Podman secret references and a unique host port. open →

The original text Underlined words open their plain-English card.

A daemon in a bottle, with its fire in your keeping.

A SoulstoneLocal Model keeps a service on your own iron: it is a local Animator running in a rootless Podman container, projected through Quadlet and supervised by the user's systemd manager. You describe the service in an immutable SoulstoneLocal Model RuneService Config File in the CodexSettings Folder. Binding compiles that intent into its physical service. The AnimatorModel Runtime adapter then declares what it can do, probes whether it is ready, and translates any supported runtime-native operations.

For a model-backed capability, the SoulstoneLocal Model is the local furnace in which an Animus may become active. The loaded model lends bounded power through its Connector and CapabilityGrant; it is not the LichAssistant's Spiritmind office or identity.

The local contract also preserves a practical dimension of sovereignty: useful capability can be possessed, inspected, stopped, and resumed by the operator rather than existing only as revocable remote tenancy.

The Local Contract

To give a SoulstoneLocal Model its body, name the quadlet.image, runtime, models, endpoint, devices, mounts, secrets, and lifecycle intent. It receives only that declared substrate. The generated Quadlet governs the service; callers receive a scoped capability rather than the container itself. The live SoulstoneLocal Model AnimatorModel Runtime holds the RuneService Config File and Connector, separately from the generated Quadlet document.

The Rune's schema boundary keeps embedded deployment structure separate from RuneService Config File ancestry and Domain ownership. Soulstone remains one domain concept, never Soul + Stone, and the only service term ending in “Stone”.

Read Soulstone Rune to declare the service and its models. Read Resources and Secrets before granting a device, mount, port, or credential.

Choose a Discipline

Disciplines is the short map of the built-in runtime families. The detailed engine contracts live under Soulstone Engines, including the difference between a server pinned to one model and a router that activates models in process. The engine pages own runtime-specific launch, connector, readiness, resource, and evidence boundaries; SoulstoneLocal Model owns their local lifecycle and RuneService Config File binding.

Lifecycle and Readiness

The Dispatcher grants only WARM; the Orchestrator alone owns managed starts, dynamic activation, conflict drain, and compensation. Coven groups compatible services; declared conflict domains govern physical incompatibility.

Proof and Recovery

Repository tests prove compilation, adapter contracts, and the declared-conflict topology. A real systemd/Podman/GPU/model run still needs the named receipt recorded by State of Work. Refusal before mutation leaves the prior world intact; uncertain mutation remains contained for operator recovery.