Etherforce
Every analysis Ishvana runs — every consistency check, every Hawken scene scan, every Lorekeeper pass, every research query — flows through one component called Etherforce. It’s the layer between the agents you talk to and the Divinity Engine handlers underneath. No external service is called. No model provider is queried. No token is billed. The work is done by deterministic handlers running in your local backend, and Etherforce is the conduit that decides which handler answers which question and assembles the result.
This page is the conceptual introduction. For deeper breakdowns — handler internals, cache behaviour, data storage — see the full Engine section. For the live diagnostic view of Etherforce’s actual behaviour, see Etherforce Observability.
The thing to know up front: Etherforce used to route between cloud LLM providers. It doesn’t anymore. The Divinity Engine replaced every external provider with bundled local handlers, and Etherforce was rewritten to dispatch handler invocations instead of model calls. If you’re reading older documentation that references Anthropic, OpenRouter, or Ollama, that’s pre-2026-04-26 history.
What it actually does
Section titled “What it actually does”Etherforce takes a typed HandlerInvocation from any agent or backend caller, picks the right handler from the registry, runs it, and returns a typed HandlerResult. The shape is the same for every handler — a list of findings, a list of items, applied parameters that record exactly what the handler did, timing data, and a success/error flag. Every caller speaks one envelope; every handler emits one envelope; the rendering layer receives the same shape no matter which handler produced it.
Three things follow from that:
- Every analysis is reproducible. Same input, same handler, same result. Run a consistency check on a chapter today and again tomorrow, and unless the prose or the lore changed, the findings list is identical.
- Costs are zero. No per-token billing, no rate limits, no quotas. Run as many checks as you want, as often as you want.
- Nothing leaves your machine. No prose is sent to a remote service. No telemetry. No data leakage path through a third-party API.
Handler registry
Section titled “Handler registry”Etherforce keeps a registry of every handler the Divinity Engine ships with. Each handler has a stable model-id (the synthetic identifier that callers pass), a short handler name, an engine version, and a documented input/output contract. The registry handles handler discovery, version pinning, and observability — when a finding surfaces in the UI, the source-handler badge maps directly back to a registry entry.
Today’s registry covers consistency checking (divinity/scene-contradictions, divinity/lorekeeper-consistency), prose analysis (divinity/proseguard-scan, divinity/worldspell-check, divinity/hawken-scene-scan and the chapter / manuscript variants), lore graph work (divinity/lore-ml-validation, divinity/lore-ml-anomalies, divinity/lore-ml-contradictions), research and lookup (divinity/wikipedia-search, divinity/world-rules-query, divinity/lagan-research-query), generative replacements (divinity/gamemaster-stat-forge, divinity/gamemaster-ability-compose, divinity/markov-name-generate), and classifier work (divinity/intent-classify, divinity/project-content-classify). The full list is enumerable through Etherforce Observability.
Streaming results
Section titled “Streaming results”Long-running handlers — manuscript scans, full-project consistency checks, Lore ML training — emit progress chunks as they work. Etherforce surfaces those chunks to the UI as they arrive so a 90,000-word manuscript scan shows scene-by-scene progress instead of going dark for two minutes and then dumping the whole report at once. The streaming contract is the same as the non-streaming one — the handler sends HandlerStreamChunk events for progress and a final HandlerResult for the terminal answer.
Handler-result cache
Section titled “Handler-result cache”Each handler invocation is cached by content hash. If the same scene gets asked the same question with the same parameters and the prose hasn’t changed, Etherforce returns the cached result without re-running the handler. The cache is in-memory, scoped to the current backend process, and invalidates automatically when the underlying content changes — there’s no manual cache-flush button you need to remember.
Where Etherforce lives in the app
Section titled “Where Etherforce lives in the app”- Analysis → Etherforce Observability — the live diagnostic panel. Every dispatch shows up here with handler id, scope reference, applied parameters, timing, and the resulting findings. The “see what’s actually happening” surface.
- Engine section — the conceptual documentation covering what each handler does and why. The “understand it” surface.
There used to be a third surface — a Settings → Models panel where you configured providers and model tiers and per-agent overrides. That panel doesn’t exist anymore. There’s nothing to configure because there are no providers and no models to assign.