Connect a local runtime
Connect Ethen Desktop to a detected model runtime and verify provider, endpoint trust, version, status, and installed-model readiness.
Connect a local runtime
A local runtime is a model-serving process that Ethen Desktop can detect through its bridge or a configured endpoint. Connection readiness is established by provider identity, detected state, endpoint label, version, checked time, runtime detail, and installed-model count. A configured endpoint may be remote, so the interface must not describe all configured runtimes as same-device or automatically private.
Runtime model
Ethen Desktop connects the product interface to the runtime through window.ethenDesktop.localModels. The bridge can request status, list installed or running models, inspect a model, start a pull, cancel work, delete a model, submit chat, and receive events. Those method names describe the bridge contract; they do not prove that every action is exposed by the current Local Models page.
Ollama is the inspected default or fallback provider. The documentation should not generalize that finding into universal runtime support. Any additional runtime family needs its own verified capability and security review.
A runtime can be detected without being ready for chat. At least one installed model must also be available and selectable.
The runtime is a separate model-serving process reached through Desktop or a configured endpoint. The bridge can report baseUrlLabel as localhost or configured. Ollama is the inspected default or fallback provider, but universal multi-runtime support was not established. Local Models calls status and list endpoints and can request details for an installed model.
The bridge can report baseUrlLabel as localhost or configured; start the runtime before opening the Local Models surface. Desktop bridge is preferred; browser fallback reports no runtime and cannot generate, as shown by the current implementation; treat configured as an instruction to verify the endpoint location and trust boundary. Do not publish a universal fixed endpoint or assume every runtime uses the same security model.
Endpoint authentication, transport security, and locality require separate review for configured endpoints; check provider, detected state, endpoint label, version, and installed-model count. Ollama is the inspected default or fallback provider, but universal multi-runtime support was not established; open an installed model to confirm that the runtime can return model details.
Prerequisites
Use Ethen Desktop rather than ordinary browser mode. Browser fallback avoids crashes and explains that Desktop and a local runtime are required, but it reports no detected runtime and cannot generate a model response.
Start a supported runtime through its own approved documentation. Ethen does not currently provide a verified runtime installer, fixed endpoint, authentication scheme, or universal configuration command.
Before connecting sensitive work, decide whether the runtime is on the same device or reached through another configured endpoint. Review the endpoint owner, transport, access control, logs, and data-handling boundary.
Desktop, a running supported runtime, and at least one installed model are needed for a complete Local Chat path. The desktop bridge is preferred; browser fallback reports no runtime and cannot generate. Runtime status should include detected state, provider, endpoint label, version, installed-model count, detail, and checked time when available. Endpoint authentication, transport security, and locality require separate review for configured endpoints.
Local Models calls status and list endpoints and can request details for an installed model; check provider, detected state, endpoint label, version, and installed-model count. Endpoint authentication, transport security, and locality require separate review for configured endpoints; open an installed model to confirm that the runtime can return model details. A healthy bridge connection does not prove that model installation, deletion, or every management method is wired in the current UI.
The bridge can report baseUrlLabel as localhost or configured; treat configured as an instruction to verify the endpoint location and trust boundary. The desktop bridge is preferred; browser fallback reports no runtime and cannot generate; use Local Chat only after the runtime is detected and an installed model is selectable. A successful bridge check still does not prove that model installation, deletion, or every management method is wired in the current UI.
Connection setup
Do not paste credentials or sensitive query parameters into an endpoint field unless the runtime’s approved setup requires them and the interface is designed to protect them. No universal endpoint-authentication contract is documented.
Open Local Models and allow the application to query runtime status. Do not type a universal URL from this documentation because the bridge can report either localhost or configured, and the exact endpoint contract depends on the current environment.
A useful setup sequence is:
- Launch Ethen Desktop.
- Start the supported runtime.
- Open
/models. - Refresh or inspect runtime status.
- Confirm the provider and detected state.
- Review the endpoint label and runtime detail.
- Verify that at least one installed model appears.
Treat an endpoint labeled configured as a separate trust boundary. The label does not prove that the service is local, encrypted, authenticated, or controlled by the same user.
Connection setup is evaluated through detected state and endpoint metadata rather than one universal URL. A detected runtime without an installed model is not ready for Local Chat. Treat configured as an instruction to verify the endpoint location and trust boundary. Open an installed model to confirm that the runtime can return model details.
Runtime status should include detected state, provider, endpoint label, version, installed-model count, detail, and checked time when available; treat configured as an instruction to verify the endpoint location and trust boundary. The bridge can report baseUrlLabel as localhost or configured; use Local Chat only after the runtime is detected and an installed model is selectable.
Verification
A complete connection check uses several status fields together:
| Check | Interpretation |
|---|---|
detected | The bridge received a runtime response. |
| Provider | Identifies the runtime family reported by the bridge. |
baseUrlLabel | Distinguishes localhost from another configured endpoint. |
| Version and detail | Help identify compatibility or startup problems. |
| Installed-model count | Shows whether a model can be selected for chat. |
| Checked time | Indicates when the status was last refreshed. |
After status succeeds, open one installed model and request its details. Then send a short Local Chat prompt. These checks test runtime detection, model visibility, and generation as separate layers.
Use the status fields together:
| Status field | Why it matters |
|---|---|
| Provider | Identifies the runtime family reported by the bridge. |
| Detected | Shows whether a runtime responded. |
| Endpoint label | Distinguishes localhost from another configured endpoint. |
| Version | Helps diagnose compatibility. |
| Installed-model count | Indicates whether Local Chat can select a model. |
| Runtime detail | Provides current diagnostic context. |
| Checked time | Shows when the status was refreshed. |
Open one installed model and request its details. A model listed by the runtime is stronger evidence of readiness than an entry in the broader Model Library. Then send a short Local Chat prompt to confirm the full path from UI to runtime and back.
Provider, endpoint label, version, model count, detail, and check time establish current readiness. Use Local Chat only after the runtime is detected and an installed model is selectable. Start the runtime before opening the Local Models surface.
A detected runtime without an installed model is not ready for Local Chat; open an installed model to confirm that the runtime can return model details. Local Models calls status and list endpoints and can request details for an installed model; start the runtime before opening the Local Models surface.
Security
A localhost label narrows the likely network path but does not verify which process owns the port or whether other local users can reach it. A configured label requires stronger review because the endpoint may cross a device or network boundary. Confirm the endpoint owner, transport, authentication, runtime logging, and access controls before sending sensitive prompts or files.
Endpoint trust is the primary security boundary. localhost suggests a same-device address but still requires review of the runtime process and local access. configured can refer to another machine or network service and must not be described as local without confirmation.
Do not send secrets, credentials, or private files until the endpoint is understood. File context becomes part of the model request. Runtime logs, telemetry, authentication, and retention are controlled by the runtime and deployment, not by the label alone.
The runtime bridge does not establish TLS, endpoint authentication, firewall rules, or multi-user isolation. Keep the endpoint-security review flag until those controls are verified.
Configured runtime endpoints require explicit trust review because they may not be on the same device. Check provider, detected state, endpoint label, version, and installed-model count.
Ollama is the inspected default or fallback provider, but universal multi-runtime support was not established; use Local Chat only after the runtime is detected and an installed model is selectable. Runtime status should include detected state, provider, endpoint label, version, installed-model count, detail, and checked time when available; check provider, detected state, endpoint label, version, and installed-model count.
Troubleshooting
- Browser fallback is shown: launch Ethen Desktop and confirm the bridge loaded.
- Runtime is not detected: start the runtime and review its own logs and endpoint configuration.
- Provider is unexpected: confirm which runtime the bridge reached.
- Endpoint says configured: verify the host, owner, transport, and access control.
- No models appear: inspect the runtime’s installed inventory.
- Model details fail: confirm model presence, runtime compatibility, and current version.
- Local Chat still fails: check model selection and the returned chat error.
Change one layer at a time. Reinstalling Desktop does not necessarily fix a stopped runtime, and restarting the runtime does not create an installed model. For internal support, include safe status fields and versions without exposing credentials or private endpoint data.
Runtime failures should be isolated from missing-model and browser-fallback conditions.
Desktop bridge is preferred; browser fallback reports no runtime and cannot generate, as shown by the current implementation; start the runtime before opening the Local Models surface. A detected runtime without an installed model is not ready for Local Chat, within the current product boundary; treat configured as an instruction to verify the endpoint location and trust boundary.