[munchist]

Plan 323 P3 and P3b, plus D17 and D18, and a test fix. Plan: docs/plans/323-models-that-run-on-this-computer.md.

What it does

D17: loading shown in the chat

While a turn waits on a model on this computer, the chat's activity row says so in place of "Working…": "Loading Gemma 4 26B (this computer) into memory…", then "Reading the conversation…". The first thinking or text token replaces it.

• How the end of a load is known: the Ollama adapter reads /api/ps. If the request would load the model, the adapter loads it first at the request's window, so the load has a visible end.
• New channel: the lines travel on a new status live-delta channel.

D15 and P3: one diagnosis, and the models on This Computer

• The record: LocalRuntimeDiagnostics and diagnoseLocalRuntime. Every issue carries a cause with its numbers and a remedy, which is either an action or an instruction.
• Readiness: derives localFit and localIssues from the record. An error issue, such as Ollama down or a role's model not downloaded, counts against ready, and the banner points at This Computer.
• New page section, "Models on this computer":
  • issue cards whose buttons run their remedies;
  • downloads with progress, stop and resume (one per runtime and tag, a second request joins it, and a download too large for the free disk is refused before it starts);
  • load, unload, use for every role, and delete.
• Shared code: routes, readiness and Helmsman share @aflow/cybernetic-runtime localModels/.
• Host inventory: publishes free disk under the model store.
• Onboarding (D18): offers the models on this computer. In the local edition, a tenant following the platform recommendation may assign them.
• Cost: a run whose every model call ran here reads "Cost: local".

P3b: Helmsman reads and asks

• Two operations: model.runtime.status and model.runtime.change, in a model step type that only the local edition composes. They run inline in the orchestrator.
• Who holds them: Helmsman can discover both, and its status read is pinned on the local edition. Runners are excluded, and skills that reference them are rejected.
• Capability: migration 220 grants the new model.runtime group to the system profiles.
• Approval: a change parks on the write-approval pause as a third target, local_model, with its own Action Center card. A space admin answers it.
  • The request: rebuilt from a fresh diagnosis whenever the step runs. Its hash covers the change and whether the asking conversation's model is the one changed.
  • Spending: the approval is spent once, through spendWriteApprovalGrant, which browser actions now share.

Test fix

streamRetention's consumer-hygiene tests walked every job stream on the Redis the live stack shares. They reaped the stack's idle consumers and deleted its eval job stream. cleanupStaleConsumers now takes the groups to visit, and the tests use a stream of their own.

Not built (stated in the plan)

• the trial load for an unpaired machine, beyond Load now;
• recent tokens per second in the diagnosis;
• the approved one-time install;
• issue codes on local-model tool errors.

Helmsman cannot assign a role's model. That goes through the space update, which no executor reaches, so Helmsman tells the operator to do it.

Review findings left as they are

• Spent browser approvals reset at deploy: the spend key moved from aflow:browser-ask:spent: to aflow:approval-spent:, so for up to an hour after deploy a browser approval spent before it reads as unspent. The host's ACL gains ~aflow:approval-spent:*, and a host executor running new code before the server has re-applied ACLs gets NOPERM on a spend until the server restarts.
• Stale approval reuse: an approval whose dispatch re-parked under a different hash stays unspent until its TTL. With the hash now only the change plus whether it reloads the asking conversation, that needs Helmsman's role model to change between the ask and the approval.
• Repeated loading reports: servesWithoutLoading compares /api/ps context_length with the window on llama.cpp. If the runtime ever reported a different figure, each request would report loading and send an extra (no-op) load. Not seen in the tests against 0.40.5.

Testing

• yarn typecheck and the web-product build pass.
• yarn test:changed passes except aflow-executor-host checkoutReplacement ("cannot be made from inside the sandbox"). It also failed before this branch's host changes and imports nothing it touches.
• The diagnosis was run against Ollama 0.40.5 on the 24 GB M3. It reports the measured Gemma build as verified, a 16K fit, and the spill at 32K.
• Not yet run on the dev stack: the page, a download, the Helmsman approval flow, and the chat loading line.

🤖 Generated with Claude Code