Cloud assistants are polished but place every prompt, response, and history on someone else’s server; local assistants keep data on owned hardware but have been desktop-bound. W5 closes the gap: the comfort of a modern chat app – history, projects, artifacts, tools – reachable from a phone, while the model and every conversation stay on hardware the owner controls.
Design & build planconsumer tier buildable now · enterprise a hardware step, not a rewrite · claims stated as acceptance criteria
Cloud comfort. Local custody.
Pick both.
Deliberately a consumer product first – not evaluation infrastructure, not an operator workstation. The design that works at home is the same one that scales to a team; compute is a hardware variable, governance a software layer.
Two forces make the timing right in 2026. The first is privacy by construction: the only architecture that can offer a genuine “data never leaves the device” guarantee is one where inference and storage are both local – a property cloud providers cannot match. The second is economics: once the hardware is in place, self-hosted inference runs at a marginal cost dominated by electricity, and at sustained usage it crosses below commercial-API spend. Sovereignty is no longer a trade of convenience or money against privacy – increasingly it is cheaper and more private, provided the model fits the card.
Reach owned hardware.
Open no ports.
The host serves an open-weight model behind an OpenAI-compatible endpoint; the phone is a thin client; the two are bridged by an end-to-end-encrypted mesh that exposes nothing to the public internet.
This maps to a shipping consumer product: LM Studio’s Locally (first-party iPhone/iPad client) with LM Link (the encrypted transport) – distinct layers, and the security property is the point. Honest current limits of that first-party path: iPhone/iPad only, both ends run the same app, account-gated pairing, shorter default phone context. These are convenience-layer constraints, not architectural ones – open-source alternatives (Off Grid, 3sparks, Open-WebUI) relax several of them.
Reach capable owned hardware, from anywhere, over an encrypted tunnel nobody else can read. Because the host serves an ordinary OpenAI-compatible endpoint, every tool that targets it keeps working – locally or remotely, with no reconfiguration.
Sovereignty is only real
if the model fits.
Footprints accurate to the shipping weights – and an honest line between what the consumer card runs with headroom and what the enterprise tier adds.
One quality caveat, consistent with the evaluation work: 4-bit formats hold within roughly 2–4 percentage points on most tasks but are most likely to lose ground on complex multi-step reasoning – so the choice of quant is a quality decision, not only a memory one. That caveat is made testable as acceptance criterion C5.
One endpoint decouples
everything.
Because the server is OpenAI-compatible, the assistant is model-agnostic and tool-compatible – and everything above the API survives the move from one user to many.
Five criteria, C1–C5.
A design & build plan, not a measured deployment – so its central claims are stated as falsifiable acceptance criteria, each with an instrument and a threshold, marked predicted until measured. Thresholds marked [proposed] are defaults offered for confirmation.
None of these require frontier-scale compute; all are runnable on the consumer build with a router, a laptop, and the evaluation pipeline already in the program – which is the point. C1 in particular converts the paper’s headline promise from an assertion into a test.
“Sovereign” as a precise claim,
not a slogan.
Under normal operation, inference runs on the owned host, history stays on owned devices, and the mesh opens no inbound ports. The guarantee is bounded – and the honest statement of it enumerates what it does and does not cover.
- Compromised host. If the host is compromised, local inference and history are exposed. Sovereignty defends against third-party cloud exposure, not endpoint compromise. Mitigation: host hardening, full-disk encryption, the hardened-sandbox discipline of the evaluation stack for untrusted tool execution.
- Compromised or malicious client. The phone holds chat history; a malicious app or a stolen, unlocked device exposes it. Mitigation: device encryption, trusted sources, biometric lock, minimal on-device retention.
- Device-discovery / account trust. Pairing is brokered through the vendor’s account system – the single residual third-party touchpoint. The device list, not the conversation, is what leaves. Mitigation: strong auth with 2FA, or self-hosting the coordination plane.
- Backend / supply chain. Backend, weights, and mesh client are third-party software; a poisoned weight file is a genuine vector. Mitigation: pinned versions, checksum/signature verification, preference for auditable open-source components.
- On-path network adversary. A hostile network (hotel Wi-Fi, CGNAT) sees only ciphertext – the case the architecture handles best.
The defensible claim is therefore precise: content never leaves owned hardware under normal operation, bounded by host and client integrity and by the small device-discovery dependency – not “no third-party software is ever involved.” C1 verifies the content-egress half of that claim empirically.
Compute scales by hardware.
Governance is built.
“The same stack serves the team” is true for compute and misleading for governance. Continuous batching lets one shared model serve many users, and local hosting satisfies data residency by construction – but a governance layer must be built above the API.
From one desk
to the whole team.
The concrete deployment the design serves – and the status it honestly carries.
- Situation. A privacy-conscious professional – and later their small firm – wants a capable assistant with the comfort of a modern chat interface including phone access, but confidential material cannot go to a third-party cloud, and desktop-bound local setups are useless away from the desk.
- Task. Stand up a sovereign assistant that is genuinely usable day to day, reachable from a phone anywhere, running a model that actually fits the hardware – with a clean path to a team that doesn’t require rebuilding the core.
- Action. Serve a 32 GB-fitting model through the OpenAI-compatible endpoint on the home RTX 5090; wrap it in a polished chat UX; reach it from the phone over the encrypted mesh – no open ports, inference and history on owned hardware.
- Result. A personal assistant used from the phone with nothing leaving the owner’s control – verified by C1 – and a documented enterprise path: add hardware for compute and the governance layer for isolation, and the same client and endpoint serve a 120B-class model to the whole team, still with no public exposure.
Status. Buildable now at the consumer tier with real, fitting models; the enterprise tier is a hardware step for compute and a defined software step for governance, not a re-architecture. The core property holds at every scale – inference and history stay on owned hardware – and the acceptance criteria make that property testable rather than merely asserted.