Plan 323 — Start Ollama from the banner and the page

[munchist]

What it does

When Ollama on this machine doesn't answer, the chat's readiness banner and This Computer now offer Start Ollama, as long as this machine's host executor is paired. That replaces the instruction to open the app or run ollama serve. Where nothing in Aflow can start it (a runtime on another machine, or no paired executor), the instruction stays as it was.

How

• Request. The operator's existing POST /spaces/:id/local-models/actions route takes a new action, start_runtime. It requires a space admin, like the other actions there.

  • The route publishes the request on a per-machine channel, hostRuntimeRequestChannel(hostname), and waits for the answer.
  • The request names nothing to run but the port.
  • Only this route publishes on that channel. The host's existing &aflow:pubsub:* grant covers it, so the Redis permissions don't change.

• Starting it. The executor starts Ollama the way the machine has it installed, in this order:

  1. a Homebrew service, through brew services start ollama;
  2. another launch agent, through launchctl;
  3. a Linux user unit, through systemctl --user;
  4. the macOS app;
  5. only then, ollama serve as the operator: detached, and without the executor's own environment (no REDIS_URL).

  Then it waits until Ollama answers.

• Why a service comes first. A service's definition carries the runtime's settings. On this Mac, Homebrew's sets OLLAMA_KV_CACHE_TYPE=q8_0 and OLLAMA_FLASH_ATTENTION=1, the settings G6 was measured with. A bare ollama serve drops both.

  • An early version fell through to a bare serve on a real test, because brew services stop removes the launch agent's file. That's why Homebrew is checked first, through its own command.

• System services. A Linux system service is left to the administrator, and the answer gives the sudo systemctl command.

• Not the server. In the appliance the server runs in a container that can reach Ollama but can't start a program on the Mac.

• Not Helmsman. start_runtime is an operator action only and isn't in Helmsman's change schema. Helmsman can't run while its model's runtime is down anyway.

• Shared exchange. The browser settings' publish-and-wait exchange moved into @aflow/redis as askHost, and both routes use it. probeEnv is shared by the host's three callers.

• Errors on the page. A refused action, such as "not installed, get it from https://ollama.com/download", now shows on This Computer as well as in the banner.

• Guard updated. The host's one-spawn-path guard names localRuntimeStart.ts, with its reason.

Testing

• This Mac (Homebrew 0.40.5). I stopped Ollama with brew services stop ollama and started it through startLocalRuntime. It answered in about 1 s with q8_0 and flash attention set, and brew services reports it started.
• Unit tests:
  • host start: 10 tests, covering Homebrew, a launch agent loaded and unloaded, the app, a Linux user unit, a system unit refused, plain serve without the executor's credentials, not installed, already running, and never answering;
  • the server's start action: 4 tests;
  • the diagnosis remedy;
  • the browser-settings routes, moved onto askHost.
• Checks. yarn typecheck and the web-product build pass.
  • test:changed: 822 pass.
  • Host workspace: 1259 pass, 1 failure, the unrelated checkoutReplacement that also fails on main.
  • Guard tests (background work, edition ownership, Redis ACL): 56 pass.
• Not yet run end to end through the UI. After it's merged into live and the host executor restarts: stop Ollama, then click Start Ollama in the chat banner.

🤖 Generated with Claude Code