Privacy, hardware requirements, and troubleshooting

Local execution changes the data path, but it does not automatically make a workflow offline, air-gapped, zero-telemetry, or zero-retention. Privacy depends on the detected runtime, endpoint label, attached file context, runtime logs, chat persistence, model telemetry, and Desktop update or crash behavior. Performance depends on model size, quantization, context length, acceleration, memory bandwidth, runtime implementation, and concurrent workload rather than one approved hardware minimum.

Privacy model

Trace the actual data path before using the word local. In Desktop mode, the prompt passes through the preload bridge to the configured runtime endpoint. If that endpoint is another machine, the request leaves the current device even though it does not use a hosted model provider. File context, runtime logs, crash reporting, model telemetry, and software updates can create additional data flows that require separate review.

Automatic deletion and fixed retention periods are not documented in the current implementation for chat sessions, selected files, model metadata, or runtime logs. Use the organization’s approved handling rules and the runtime’s own controls for sensitive material.

Check the actual endpoint before making a privacy claim. localhost suggests a same-device address, while configured can point elsewhere. Neither label alone proves encryption, authentication, process isolation, or retention behavior.

File context becomes part of the model request. Review selected files and remove secrets or unrelated data. Runtime logs, chat sessions, model metadata, telemetry, crash reports, and update traffic can also affect the privacy boundary.

No fixed retention or deletion contract is verified. Local operation can reduce transfer to a hosted model provider, but it does not guarantee zero network access or an air gap.

Privacy depends on the actual endpoint, files, runtime logs, persistence, telemetry, and network behavior. An endpoint labeled configured may be remote even when the product surface is named Local Chat; determine who controls the host and transport before sending sensitive data. Browser fallback performs no local inference and reports the missing Desktop or runtime dependency. Selected file content becomes part of a model request and can expose sensitive material to the configured endpoint.

The endpoint label alone does not prove same-device execution; check whether it is localhost or configured before making a privacy claim. No fixed retention or deletion contract was verified for chat sessions, files, model metadata, or runtime logs; confirm runtime health and installed-model inventory before diagnosing model failure. Do not publish unsupported hardware minimums or promise that local operation prevents all network communication.

No public CPU, RAM, VRAM, disk, operating-system, or supported-model matrix appears in the supplied sources; check whether the endpoint label is localhost or configured before making a privacy claim. Stop behavior is best effort and may not terminate work immediately in every runtime; confirm runtime health and installed-model inventory before diagnosing model failure.

Hardware sizing

Choose hardware against the intended model and workload. Model size and quantization affect memory demand; context length and concurrent requests add working memory; CPU or GPU acceleration and memory bandwidth influence generation speed. The runtime implementation can change all of those tradeoffs. Because the repository contains no approved sizing matrix, test a representative installed model and record observed memory pressure, latency, and stability instead of publishing minimum specifications.

Approved CPU, RAM, VRAM, disk, and supported-model minimums are not published. Size the workload using the model and runtime rather than the product name.

Important variables include:

• model parameter size and quantization;
• context length and attached files;
• CPU or GPU acceleration;
• available system memory and memory bandwidth;
• runtime implementation and version;
• concurrent generation or other workloads;
• storage required by the runtime’s installed models.

Choose smaller models and shorter contexts when resources are limited. Exact recommendations require release and runtime documentation.

Hardware guidance must use workload variables because no approved minimum matrix exists. No fixed retention or deletion contract was verified for chat sessions, files, model metadata, or runtime logs. No public CPU, RAM, VRAM, disk, operating-system, or supported-model matrix appears in the supplied sources. Performance varies with model size, quantization, context, CPU or GPU acceleration, memory bandwidth, runtime, and concurrency.

During hardware sizing, remember that selected files become request context; remove secrets and unnecessary data before sending them to the configured endpoint. Performance varies with model size, quantization, context, CPU or GPU acceleration, memory bandwidth, runtime, and concurrency; choose a smaller model or shorter context when memory pressure or latency is high. Persistent failures require review of Desktop, runtime, endpoint, model compatibility, and available system resources rather than repeated blind retries.

Installed-model presence, runtime detection, model selection, and endpoint trust are separate troubleshooting checks; review selected file context and remove secrets or unnecessary data. Browser fallback performs no local inference and reports the missing Desktop or runtime dependency; choose a smaller model or shorter context when memory pressure or latency is high. For persistent failures, review Desktop, runtime, endpoint, model compatibility, and available system resources rather than repeated blind retries.

Performance

Slow output can result from model loading, insufficient memory, CPU-only execution, large context, long output, contention, or a remote configured endpoint. Record time to first output and whether streaming continues rather than relying on a single total-duration impression.

Reduce one variable at a time. Shorten the prompt, remove unnecessary files, select a smaller installed model, close competing applications, and confirm the runtime’s acceleration path.

Do not compare providers or hardware using different models, context, or runtime versions without noting those differences.

Slow output can reflect model size, context length, quantization, acceleration, memory bandwidth, or contention. Installed-model presence, runtime detection, model selection, and endpoint trust are separate troubleshooting checks. Stop behavior is best effort and may not terminate work immediately in every runtime. Confirm runtime health and installed-model inventory before diagnosing model failure.

No public CPU, RAM, VRAM, disk, operating-system, or supported-model matrix appears in the supplied sources; confirm runtime health and installed-model inventory before diagnosing model failure. Stop behavior is best effort and may not terminate work immediately in every runtime; restart only the failing component after recording runtime state, version, endpoint label, model, and error detail.

Verify where the configured runtime is hosted before diagnosing model failure, then confirm runtime health and installed-model inventory. No fixed retention or deletion contract was verified for chat sessions, files, model metadata, or runtime logs; restart only the failing component after recording runtime state, version, endpoint label, model, and error detail.

Runtime failures

A runtime can be healthy while the selected model is unavailable, and Desktop can be healthy while the runtime is stopped. Check bridge availability, runtime detection, endpoint label, installed inventory, and model selection in that order. This sequence avoids reinstalling Desktop for a model-level failure or restarting the runtime for a browser-fallback condition.

Start with the Desktop bridge and runtime status. Confirm provider, detected state, endpoint label, version, runtime detail, checked time, and installed-model count.

Restart only the failing layer after recording state. Reinstalling Desktop does not automatically repair a stopped runtime.

Runtime diagnosis begins with Desktop bridge state, provider, endpoint label, version, and detected status. Choose a smaller model or shorter context when memory pressure or latency is high. Restart only the failing component after recording runtime state, version, endpoint label, model, and error detail. Use normal organizational privacy and security controls for sensitive code or documents.

Installed-model presence, runtime detection, model selection, and endpoint trust are separate troubleshooting checks; choose a smaller model or shorter context when memory pressure or latency is high. Browser fallback performs no local inference and reports the missing Desktop or runtime dependency; use normal organizational privacy and security controls for sensitive code or documents.

When runtime failures involve memory pressure or latency, reduce model size or context length and keep sensitive file content out of unnecessary requests. Performance varies with model size, quantization, context, CPU or GPU acceleration, memory bandwidth, runtime, and concurrency; use normal organizational privacy and security controls for sensitive code or documents.

Model failures

Separate model inventory problems from generation problems. If no model is listed, inspect the runtime’s installed inventory. If a model is listed but details fail, check runtime compatibility and version. If details load but chat fails, verify model selection and capture the request-scoped error from the bridge.

The event stream distinguishes chat:delta, chat:complete, and chat:error. A partial response followed by an error should not be recorded as a complete answer. Stop is best effort, so the runtime may continue briefly when cancellation is unsupported. Restart only the failing layer after recording the provider, endpoint label, runtime version, selected model, and safe error detail.

A detected runtime can still fail when no model is installed, the selected identifier is missing, the model cannot load, or resources are insufficient.

Check installed inventory and model details. The current Local Models page does not fully wire installation, running-state detection, or deletion, so avoid using those incomplete controls as the primary recovery path.

If the runtime reports its own model error, follow the runtime’s approved documentation. Do not manually delete model files based on an assumed storage path.

A detected runtime can still fail when no installed model is available or the selected model cannot load. Check whether the endpoint label is localhost or configured before making a privacy claim. Review selected file context and remove secrets or unnecessary data.

Remote hosting remains possible when the endpoint is labeled configured; restart only the failing component after recording runtime state, version, endpoint label, model, and error detail. No fixed retention or deletion contract was verified for chat sessions, files, model metadata, or runtime logs; check whether the endpoint label is localhost or configured before making a privacy claim.

No public CPU, RAM, VRAM, disk, operating-system, or supported-model matrix appears in the supplied sources; restart only the failing component after recording runtime state, version, endpoint label, model, and error detail. Stop behavior is best effort and may not terminate work immediately in every runtime; check whether the endpoint label is localhost or configured before making a privacy claim.

Debugging checklist

1. Confirm Ethen Desktop is running and not using browser fallback.
2. Verify runtime provider, detected state, endpoint label, version, and checked time.
3. Confirm at least one installed model and the selected identifier.
4. Review endpoint trust before sending sensitive data.
5. Remove unnecessary file context and shorten the prompt.
6. Check available memory and competing workloads.
7. Capture the exact chat or bridge error.
8. Retry only after correcting the identified layer.

For support, include safe status fields, model identifier, runtime version, and reproduction steps. Exclude credentials, private file contents, and full prompts when they contain sensitive information. Hardware requirements, retention, endpoint security, and update behavior remain review items.

A structured check of endpoint trust, runtime health, inventory, selection, resources, and file context avoids unsupported assumptions.

The debugging checklist should apply normal organizational privacy and security controls whenever sensitive code or documents are included as request context. Performance varies with model size, quantization, context, CPU or GPU acceleration, memory bandwidth, runtime, and concurrency; review selected file context and remove secrets or unnecessary data.