Local Weights · core end-user journey
The MVP keeps the original journey's main promise: the developer does not configure models, runtimes, ports, or trust files by hand. The supported profile has already been selected and signed. The app explains what it will do, performs the installation, and leaves the developer with a working command and endpoint.
This is an ambitious UX with a narrow product scope: one signed profile, supported macOS and Linux tiers, one llama-server runtime, and a small set of lifecycle controls.
install the app → open invite → review plan → install → start → run → show status
The invite supplies the registry, trust key, and profile. Technical settings remain in the signed profile.
Show the selected model, source, disk requirement, and progress. Do not promise an estimate until enough data exists.
macOS and Linux use the same manager, events, profile schema, and health checks. Hardware integration and service backends remain platform-specific.
Step 0 · get the app
Distribution is a single shell command served from the registry host. Browser downloads of unnotarized apps arrive quarantined and report the app as “damaged”, so the terminal path is the supported one: the installer downloads the archive, verifies its checksum, and places Weights.app in Applications.
implemented — scripts/package-release.sh builds and ad-hoc-codesigns the app and CLI, produces versioned tarballs plus an install.sh with pinned sha256s, and the whole set is published next to the registry. The install line doubles as the audit trail: the version maps to a rad-artifact record in the repo.
curl -fsSL https://wheresmy.ai/install.sh | sh Downloading weights-v0.2.0-demo-macos-arm64.tar.gz… Checksum verified. Installed Weights.app to /Applications. Open the Weights app and paste your invite.
Step 1 · invite
A teammate or administrator sends one invite. Opening it identifies the registry, public trust key, and profile. The app shows the organization and signing-key fingerprint before saving them.
implemented — one ccweights://join URL format, parsed in core and accepted by the desktop app (pasted) and weights join on Linux. An invite can initialize trust or confirm the existing key; it can never replace a different one. Pasting the invite is the supported path; OS-level protocol-link handling is still to come.
Step 2 · review
The app verifies the registry, detects the machine, selects the matching tier, checks disk space, and looks for a local, LAN, or Hugging Face source. The developer reviews the result and chooses whether to share the model after installation.
implemented — trusted registry snapshots, hardware-tier planning, source selection, disk preflight, and local/LAN/HF acquisition live in the shared manager. Folders registered with weights scan-dir add are scanned at the next launch, hashing registry-sized files first; while a same-size file is still being hashed, the plan warns that installing now would download instead of reusing it. Linux hardware detection and the signed Strix Halo tier are confirmed working on the local test machine.
Step 3 · installation
The app shows the current source and verified bytes transferred. The developer can close the setup window, cancel, or retry without losing resumable data. After the model arrives, the app verifies and installs the pinned runtime.
implemented — manager events, operation IDs, cancellation, resumable HF and iroh state, cross-process locks, and final hash verification. Runtime archives are verified against signed hashes, extracted safely, and installed atomically; an interrupted install resumes with a full re-verification pass.
Downloading from the team network
You can close this window. Installation will continue in the app.
Step 4 · starting
A 35B model takes on the order of a minute to load; a first cold start can take longer. Without an explicit state the user reads that silence as a hang. The app names the phase and keeps the window honest until the endpoint answers.
implemented — service starts are asynchronous, so the app records the start moment and treats “running but not yet responding” inside a five-minute grace window as starting, polling health every two seconds and flipping to ready the moment /props answers with the expected model. The tray shows code-agent — starting (loading the model)… during the same window. Every control also reacts instantly: Pause, Restart, and Start switch to “Pausing…”, “Restarting…”, “Starting…” the moment they are clicked.
Starting the agent…
Loading the model — this can take a minute.
Step 5 · ready
Once the expected model is healthy, the endpoint is ready independently. The user can optionally set up a pinned pi coding agent, after which the verified pi command is shown.
implemented — the model is installed without an extra full copy, llama-server runs under launchd or systemd --user, and health means /props reports the exact managed model path — identity, not just liveness. pi onboarding keeps an existing working pi or, after consent, installs a pinned version and adds a dedicated provider through pi's documented models.json configuration. It preserves unrelated settings, does not edit shell startup files, and does not act as a general package manager.
✓ Model server is running
The model server starts automatically when you log in — and keeps running when this window closes.
Step 6 · routine use
The agent is a background service, deliberately independent of the app: closing or quitting the app leaves it running. The developer can pause or restart it from the Local Agent window or the menu-bar tray, open the Local Weights library window, and choose between two exits — quit and keep the agent running, or stop the agent and quit. Linux exposes the same state and actions through the CLI.
implemented — the manager owns runtime state and health; small service backends handle launchd on macOS and systemd user services on Linux. Left-click on the tray icon opens the menu. Uninstalling is a two-step Remove… → “Really remove?” in the window: it removes the background service but keeps the model on disk, so reinstalling is quick.
code-agent — running localhost:8837 ────────────────────── Pause the agent ────────────────────── Local Agent… Local Weights… ────────────────────── Quit Weights (keep agent running) Stop agent and quit
weights profile status code-agent profile code-agent state ready model Qwen3.6 35B endpoint http://127.0.0.1:8837 service systemd --user · running health expected model confirmed start · stop · restart · logs · uninstall
Step 7 · recovery
Failures use plain language and retain enough detail for support. The first version needs retry, recent runtime logs, and clear handling for unsupported hardware, insufficient disk, missing credentials, and port conflicts.
implemented — retry, recent runtime logs, and copyable details, plus plain-sentence outcomes for the states real runs produced: a running but unresponsive agent, a resumable interrupted install, and an invite for a different team's key (a dead end by design — trust is never replaced by a link). Comprehensive automatic repair and diagnostics submission can follow after more failure modes are observed in real use.
The agent could not start
Another process is using port 8837.
Complete desktop journey: one-command install, pasted invites, launchd lifecycle, menu-bar status and controls, and CLI parity.
The same planning, acquisition, runtime, health, and lifecycle behavior through the CLI first. Initial support targets the confirmed local Strix Halo machine and its systemd user session.