Local versus hosted models

Local and hosted model paths differ in where the runtime is operated and who manages the surrounding infrastructure. Use this page when deployment location, control, provider dependence, privacy requirements, or operational effort affects model selection. Ethen’s approved positioning includes flagship, open, and local lanes where supported, but Batch 01 does not verify hardware sizing, installation, universal local availability, or product-specific privacy guarantees.

Hosted models

A hosted model is accessed through a provider-managed service or configured gateway path. The provider operates the model-serving infrastructure, while the Ethen environment represents the model, provider, capability, status, and available operational fields.

Hosted paths can simplify initial access when provider configuration and credentials are ready. They may also expose current pricing, latency, throughput, context, and output fields in the catalog. Those fields are dynamic and can differ by record.

Hosted access still has prerequisites:

• the model must be represented by the intended provider;
• the requested modality must be supported;
• required credentials must be present;
• the current status must permit a run;
• the account or environment must be allowed to use the route;
• the task’s data and approval requirements must be satisfied.

A provider name or catalog row does not establish regional availability, service level, or contractual terms.

Hosted models are accessed through a provider or managed model path rather than a runtime on the user’s machine. Ethen’s approved positioning includes flagship and open models in hosted lanes.

The inspected sources do not define provider regions, account eligibility, quotas, processing terms, or universal availability. Use current provider and Gateway evidence before relying on a hosted path.

Local models

A local model path runs on infrastructure closer to or controlled by the user, team, or organization. Approved Ethen language allows local lanes where supported, but the current sources do not identify the complete local runtime, installation process, compatible model set, device support, or resource requirements.

A local path may be attractive when runtime control, network independence, model portability, or custom operations matter. Those are evaluation goals, not guaranteed outcomes.

Before selecting local, verify in the dedicated Local and Desktop documentation:

• supported operating systems and runtime;
• model formats and acquisition path;
• hardware and memory requirements;
• context and throughput behavior;
• update and rollback process;
• storage locations and lifecycle;
• network behavior;
• integration with Ethen workspace, catalog, or routing surfaces.

Do not infer support from an open-weight label alone. A model can be open-weight yet unsuitable for the available device or unsupported by the product runtime.

Approved platform language includes local or private lanes where supported.

This does not establish which runtimes, hardware, operating systems, model formats, acceleration methods, or offline behaviors are supported. Those implementation details belong in the Local and Desktop batch.

Privacy

Runtime location affects data flow, but “local” is not synonymous with “private,” “offline,” or “secure.” Privacy depends on the complete path: application telemetry, model files, storage, operating system, integrations, network calls, logs, backups, and user behavior.

A hosted path can have documented privacy controls, while a poorly configured local path can expose data. Conversely, a verified local runtime may reduce reliance on an external model provider for inference. The correct conclusion must come from the current implementation and policy sources.

For either approach:

• minimize task context;
• keep credentials outside prompts;
• identify which system receives the data;
• review policy commitments separately from product descriptions;
• avoid claiming retention or deletion behavior that has not been verified.

Batch 01 cannot compare legal or compliance properties of local and hosted paths.

Local and hosted describe deployment or access location, not a complete privacy conclusion.

A local model may still use cloud services for other parts of a workflow, and a hosted model may operate under approved data handling. Verify context movement, logs, retention, provider terms, and the current legal policy before handling sensitive material.

Performance

Hosted performance depends on provider infrastructure, route conditions, model behavior, request size, and current service state. Local performance depends on device resources, runtime efficiency, model size or representation, and workload shape.

This table identifies evaluation areas, not a winner. Batch 01 does not provide numeric hardware or benchmark guidance for local operation.

Performance depends on model architecture, hardware, runtime, context length, concurrency, provider capacity, and task shape.

The current product surfaces do not provide a controlled local-versus-hosted benchmark. Do not claim that one category is always faster, cheaper, or higher quality.

Operations

Hosted operation shifts model serving to a provider but retains work for credentials, provider configuration, cost monitoring, availability review, and fallback planning. Local operation adds model acquisition, storage, runtime lifecycle, device capacity, updates, and troubleshooting.

Operational questions include:

• Who owns provider or runtime configuration?
• How are model versions identified?
• What evidence records the route used?
• How are failures surfaced?
• Is fallback allowed, and does it change data handling?
• How are updates tested?
• What happens when the local device or hosted provider is unavailable?

Fallback between local and hosted paths should never be assumed. A substitution can change provider exposure, performance, cost, and review requirements. It must be configured and made visible where supported.

Hosted paths shift some serving operations to the provider; local paths usually introduce environment-specific installation and resource concerns.

The exact monitoring, updates, model storage, recovery, and security responsibilities are not defined here. Record them before production use and follow the later operations documentation.

Evidence parity

Try to collect comparable evidence from both lanes. For hosted execution, preserve provider, model ID, status, and route. For local execution, preserve runtime, model artifact, device context, and current integration state. Record the same task and review criteria.

Evidence parity does not make the environments identical, but it prevents the comparison from favoring the path with better instrumentation. Missing local or hosted measurements should remain explicit limitations.

Choosing an approach

Choose hosted when provider-managed access, broad model selection, or reduced local infrastructure work is more important than operating the runtime directly. Confirm current status, credentials, modality, cost, and policy fit.

Choose local for further evaluation when runtime control or local operation is a firm requirement and the dedicated product documentation verifies compatible hardware, models, and setup. Do not select it solely because a model is open-weight.

A hybrid approach may use research and catalog surfaces to compare candidates and then select local or hosted execution per task. The platform wording supports multiple lanes, but exact routing and fallback must be verified.

Record the decision with the chosen model, provider or runtime, required context, expected workload, availability risks, and unresolved policy questions. Revisit the choice when model data, provider status, hardware, or product maturity changes.

Choose by data boundary, required capability, current model evidence, environment readiness, operational ownership, and the need for provider-managed access.

A mixed approach may be appropriate where the platform supports it, but do not assume automatic routing between local and hosted lanes. Validate each lane independently with a small task.

Operational ownership matrix

Assign ownership before choosing the lane.

The matrix clarifies responsibility; it does not assert that every local or hosted control is currently implemented by Ethen.

Testing the same workload

A fair local-versus-hosted comparison uses the same source material, task instructions, output criteria, and review process. Record the exact hosted model/provider and the exact local model/runtime identity. Compare quality, latency, throughput, context fit, setup effort, and evidence availability.

Do not compare a local small model with a different hosted model and attribute every difference to runtime location. Model capability and model size or version can dominate the result.

Failure and continuity

Plan for provider unavailability, missing credentials, local device downtime, runtime incompatibility, and model-file problems. Decide whether work should stop, wait, or move to a verified alternate path.

A continuity plan should make substitutions visible. If a hosted fallback receives context that was intended for local processing, that change may require new review. If a local fallback cannot support the same modality or context, it is not equivalent.

Deferred local details

Hardware sizing, acceleration support, installation commands, model download procedures, storage requirements, and desktop integration belong to the Local and Desktop batch. Keeping them out of this page prevents generic hardware advice from becoming an unsupported Ethen requirement.