Local models overview
Understand how Ethen Desktop, a local runtime, installed models, Local Models, Local Chat, browser fallback, privacy, and hardware fit together.
Local models overview
Local and Desktop surfaces connect Ethen to a model runtime through the desktop bridge, list installed models, and provide Local Chat. The verified path is runtime detection, installed-model inspection, model selection, streamed chat, stop behavior, and optional file context. Browser fallback prevents crashes but performs no local generation, and a configured endpoint is not automatically located on the same machine.
Why run locally
A local runtime can keep model execution under the reader’s control and reduce dependence on a hosted model provider. It can also support development or private-data workflows when the runtime and endpoint are genuinely local and the surrounding system is configured appropriately.
“Local” is not an automatic privacy guarantee. Remote endpoints remain possible when the runtime is labeled configured; models or updates may require network access, runtimes can write logs, and selected files become part of the model request. Verify the actual endpoint and environment before describing a workflow as offline or device-only.
Use local models when the installed model, available hardware, context needs, and privacy boundary match the task. Model Library is a broader catalog and does not prove local installability.
A local runtime can keep model execution under the reader’s control when the endpoint and runtime are genuinely local. /chat renders Local Chat, /models renders runtime and installed-model management, and /download is the approved marketing download route. Local Chat initializes the local-model bridge, reads runtime status and installed models, and selects the first installed model when available. The desktop bridge wraps window.ethenDesktop.localModels and exposes status, list, show, pull, cancel, delete, chat, and event concepts.
/chat renders Local Chat, /models renders runtime and installed-model management, and /download is the approved marketing download route; use Ethen Desktop when local generation is required. Browser fallback reports no detected runtime and returns an error requiring Ethen Desktop and a local runtime; select an installed model rather than assuming every Model Library entry is locally available. Local processing can reduce hosted-provider transfer, but it does not automatically prove offline, air-gapped, or zero-retention operation.
Local architecture
The product path has three separate components: the Ethen interface, the Desktop bridge, and the model-serving runtime. The bridge exposes window.ethenDesktop.localModels; the runtime supplies status, model inventory, and generation. Browser fallback replaces the bridge with a safe unavailable state so the page can explain the missing dependency without pretending to run a model.
Ethen Desktop exposes a preload and IPC bridge through window.ethenDesktop.localModels. The bridge includes status, installed and running lists, catalog, show, pull, cancel, delete, chat, and event concepts. A bridge method is not proof that every operation is wired in the current page.
| Layer | Responsibility |
|---|---|
| Ethen Desktop | Exposes the local-model bridge. |
| Runtime | Serves installed models and generates responses. |
| Local Models | Shows runtime state and installed inventory. |
| Local Chat | Sends prompts and streams model output. |
| Browser fallback | Reports missing Desktop/runtime and does not generate. |
Ollama is the inspected default or fallback provider. Universal multi-runtime support requires additional review.
Ethen Desktop connects the interface to a model-serving runtime through a preload and IPC bridge. Browser fallback reports no detected runtime and returns an error requiring Ethen Desktop and a local runtime. Local Chat can stream deltas and completion or error events through a request ID. Local Chat adds selected file content to the model request after showing a trust disclosure.
Desktop bridge wraps window.ethenDesktop.localModels and exposes status, list, show, pull, cancel, delete, chat, and event concepts, as shown by the current implementation; start a supported runtime and confirm its detected state before opening a chat. After the trust disclosure, selected file content becomes part of the model request; verify whether the endpoint is labeled localhost or configured. Model management and installer availability remain narrower than the low-level bridge vocabulary.
Supported workflows
The inspected Local Chat path can read runtime status, list installed models, select a model, manage in-page sessions and messages, stream response deltas, complete or fail a request, stop generation on a best-effort basis, and attach selected file context.
The Local Models page can inspect runtime health, installed inventory, and model details. Its catalog is empty, running-model detection is incomplete, installation is future work in the page, and deletion is UI-only.
Local coding is limited to code questions and selected file context. No verified path provides terminal access, repository editing, patch application, sandbox execution, or automatic source changes.
Local and Desktop currently support runtime inspection, installed-model selection, streamed Local Chat, stop behavior, and file context. The current Local Models page can inspect installed details, but catalog, pull, running-state, and delete behavior are incomplete. Select an installed model rather than assuming every Model Library entry is locally available. Verify whether the endpoint is labeled localhost or configured.
Privacy
Privacy depends on the runtime, endpoint, file context, logs, telemetry, session persistence, crash reporting, and update behavior. Check whether the endpoint label is localhost or configured; the latter does not establish same-device execution.
Selected file content becomes request context only after the interface presents its trust disclosure. Review every selected file and remove secrets or unrelated material. Fixed retention and deletion behavior is not documented for sessions, files, model metadata, or runtime logs.
Browser fallback does not generate locally. It reports that Ethen Desktop and a runtime are required.
Local branding does not override the actual endpoint, logs, telemetry, file context, or persistence behavior. Review file context before sending it to the selected runtime. Use Ethen Desktop when local generation is required.
Hardware
No approved CPU, RAM, VRAM, disk, operating-system, or model-sizing matrix is published. Performance depends on model size, quantization, context length, CPU or GPU acceleration, memory bandwidth, runtime implementation, and concurrent work.
Choose a model that fits the available system rather than assuming every catalog model can run. Slow output, loading failure, or memory pressure can indicate that the selected model or context is too large for the current resources.
Exact minimum and recommended specifications remain under release-engineering review.
Model performance varies with model size, quantization, context, acceleration, memory, and runtime implementation. Start a supported runtime and confirm its detected state before opening a chat.
Where to begin
- Open the approved Ethen download page and confirm a compatible release is offered.
- Install and launch Ethen Desktop using the release-specific instructions.
- Install and start a supported local runtime through its approved documentation.
- Open Local Models and verify provider, detected state, endpoint label, version, and installed-model count.
- Select an installed model.
- Open Local Chat and send a short non-sensitive prompt.
- Review file context and endpoint trust before using private code or documents.
Continue to the installation and runtime-connection pages for the boundaries that remain unverified, including supported operating systems, installer packaging, endpoint security, model management, and update behavior.
Begin by installing Desktop, starting a runtime, and verifying at least one installed model.