Search ARuntime.com

Find runtime definitions and implementation guidance

Search page titles, summaries, headings, glossary terms, use cases, and runtime-directory entries.

Enter at least two characters.

ARuntime Reference

Local and Desktop Runtimes

Local-first means the user-visible control plane, data placement, policy, and evidence remain user-governed even when selected compute is remote.

Audience: Technical readers Reading time: 2 minutes Status: Production guidance Last reviewed:

Local-first means the user-visible control plane, data placement, policy, and evidence remain user-governed even when selected compute is remote.

Key takeaways

  • Local model process
  • Device capability must be explicit.
  • Fallback and rollback behavior should be tested.

Patterns

  • Local model process
  • Desktop sandbox
  • Local tools and files
  • Hybrid hosted fallback
  • Exportable project memory and evidence

Placement decision

Question Why it matters
Device capability Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.
Model footprint Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.
Update channel Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.
Offline continuity Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.
Remote fallback consent Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.
Local secret storage Record the constraint, assumption, and accepted trade-off in the Runtime Decision Record.

Failure and fallback

Define behavior for network loss, provider failure, device pressure, cache loss, invalid artifacts, and unavailable tools. A fallback must preserve data policy and output contracts; it should not silently broaden authority.

Implementation checklist

  • Document the control, execution, data, and evidence locations.
  • Pin artifact, runtime, and policy versions.
  • Test cold start, steady state, overload, failure, and rollback.
  • Expose data movement and hosted fallback to users where relevant.
  • Record cost and capacity assumptions.

Capability negotiation and hosted fallback

Desktop applications should build a local execution profile from available CPU, GPU or NPU, memory, storage, operating-system version, drivers, and model compatibility. The profile selects a model and precision that fit the device rather than attempting a package that will fail after a long download. The interface should state whether a task will run locally, use a hosted model, or be unavailable.

A hosted fallback is a separate policy decision. It should identify which context may leave the device, which provider or region is allowed, whether user approval is required, and how the resulting evidence is merged with local history. Local-first control is preserved when the user can inspect and change these rules and when remote execution is not silently substituted.

Updates, recovery, and deletion

  • Sign and version application, model, adapter, policy, and tool packages independently.
  • Stage updates and retain a known-good rollback package.
  • Checkpoint resumable work outside volatile model processes.
  • Use bounded local logs and expose clear deletion and export controls.
  • Test low-disk, low-memory, sleep/resume, network loss, driver change, and corrupt-model states.
  • Do not retain prompts, files, or memory by default merely because execution is local.

Maintenance record

Found an error, outdated capability, or unclear category boundary? Submit a correction with a supporting source.