# Choosing a runtime

Use `live-sandboxed` for assistant-built widgets, forms, dashboards, lightweight
visualizations, and integrations that fit the serializable API. It provides the
strongest boundary and needs no visible build, but accepts only one plain
JavaScript/CSS bundle and declarative UI.

Use `sandboxed-page` for isolated packaged dashboards and custom page DOM whose
data access fits capability RPC. It supports a self-contained HTML page, but not
native host components or the embedded editor.

Use `native` only for features that need trusted host DOM integration, mounted
SearchView/editor/Markdown components, or another capability unavailable to an
isolated runtime. Bundle every runtime dependency into one import-free ESM
entry. Native code receives full application-realm trust.

Changing runtime changes the trust review and available API surface; it is not
an implementation-only toggle.

All three runtimes are personal-vault only in v1. They stop in shared or
unavailable workspaces, and received package/source bytes never become
executable there. See [compatibility.md](compatibility.md) for the complete
runtime and contribution matrix.
