[Ark0N]

Codeman can now set up a coding model that runs on the Mac the server runs on. It reads the hardware, recommends a model and a coding agent that fit it, and on request downloads and checks both, saves the model as a Custom Model Endpoint Profile (id local-ollama) and offers to start a session of that agent on it. No account or API key is involved, and the model server runs with its cloud features switched off (OLLAMA_NO_CLOUD=1).

Ships in Codeman 1.50.0, with the macOS app (#763).

All of it is experimental: the routes and their payloads may change in any release (docs/versioning-policy.md). Apple silicon macOS only. On a server that is not a Mac the button and the Settings row stay hidden, and an install request is refused (400). An Intel Mac, a macOS older than 14 or a Mac with too little memory gets the window, which says why nothing is offered. Neither the routes nor the button sit behind a setting. In multi-user mode every route is admin only (403), and a non-admin sees neither surface.

What the user gets

• "Run a local model" at the top of the start screen, above the launchers and in the size of the primary button: white with dark ink (dark on the light skins, where white would vanish). It reads "Local model" once one is installed and appears only after the server has answered for a Mac. Its tooltip says that "this Mac" is the machine Codeman runs on, which is not always the device the page is open on.
• App Settings > Models > Model on this Mac: one row with the state in a few words and a button that opens the window.
• One window for the whole flow. The chooser shows a memory map of what this Mac can give a model, filled with the selected model's weights, context and brief peak, and the models that fit as a radio list (the pick first, then the others by download size, largest first), each with its download size, a speed gauge and at most one tag: "Tested on a Mac like this", "Best fit", "Best fit, tight", "Tight", "Slow" or "Small model". The coding agent is chosen there too. The confirm screen lists the download (model, runtime and, when it must be installed, the coding agent with its literal install command), the total and where it goes. The other screens follow the job: progress, paused, failed (the server's sentence and the one action that helps), installed (Start a session, Stop or Start, Remove) and "nothing fits".
• On a Mac without Xcode or the Command Line Tools, the confirm and installed screens say that coding agents use git and Python and that macOS will offer to install its developer tools the first time an agent needs one. fix(macos): never run Apple's placeholder git, which opens the developer tools window #779 keeps Codeman itself from running the placeholder git, but the agent runs git and python3 on its own.

The open window polls GET /api/local-model once a second; the start screen and App Settings ask it at most once a minute. There is no SSE event. The job runs in the server, so the window can be closed. Every new string has a zh-CN entry.

How it works

The recommendation (read only)

GET /api/local-model answers { hardware, recommendation, catalogUpdated, install }. It downloads, installs and changes nothing; its one write is bookkeeping (a job a restart interrupted is marked paused).

• Probe (src/local-model/hardware.ts): one bounded spawn of /usr/sbin/sysctl with seven keys (memory, chip, arm64, Rosetta, iogpu.wired_limit_mb, macOS version, model), the free disk of the data dir through statfs behind the bounded path probe, node:os as the fallback when the spawn fails, cached for 60 s. It never runs system_profiler, never throws, and spawns nothing off macOS.
• Catalogue (src/config/local-model-catalog.ts): a compiled constant checked by a Zod schema, with no override file. Eight models, one or more for every Apple silicon memory size from 8 to 512 GB, chosen from a web survey of current coding models (benchmarks, licences, tool-call support in the runtime's renderers and parsers). Every row says which runner a Mac uses for it (runner: mlx | llamacpp, required), and its size is what a Mac really downloads (the registry's manifest list, read the way the runtime reads it). Three coding agent rows (OpenCode, Claude Code, and pi, which is gated and never offered); a table of chip memory bandwidths. Model ids are lowercase name:tag without a slash, so they can only name a model of the runtime's default registry.
• Budget: before the runtime exists it is an estimate: the wired limit when one is set, else 2/3 of memory below 36 GB and 3/4 from 36 GB, less 1 GiB, and never more than memory less a reserve (6 GiB up to 18 GB, 8 GiB up to 48 GB, 12 GiB above). Once the runtime has run, the device total it prints at start replaces the estimate (budgetSource: "measured"), still bounded by the reserve.
• Need: per row and per runner, never borrowed. A llama.cpp row: its weights, a q8_0 K/V cache for the whole context, its fixed recurrent state, the copies llama-server keeps beside the cache (8 context checkpoints, and the rollback copies a multi-token-prediction tag needs per drafted token), 1 GB for the runner and the bounded 1 GiB prompt cache. An MLX row: its weights, the K/V cache and recurrent state, and the runner's fixed 8 GiB prefix-cache budget. Only qwen3.6:35b-a3b (MLX) is measured, on an M5 Pro with 48 GB; every other figure is computed from the model's config.json, marked estimated, and re-derived by test/local-model-catalog.test.ts from a table of architectures. The runtime now starts llama.cpp models with OLLAMA_KV_CACHE_TYPE=q8_0, OLLAMA_FLASH_ATTENTION=1, LLAMA_ARG_CACHE_RAM=1024 and LLAMA_ARG_CTX_CHECKPOINTS=8 (runtimeEnv()); the MLX runner reads none of them.
• Fit: need over budget up to 0.85 is Good, up to 0.98 Tight, and above that the model is not offered. Fit decides whether a row is listed, not its place.
• Ranking: a pair tested on a Mac like this one first, then speed (ok, unknown, slow below 10 tokens per second; estimated from the chip's bandwidth, and unknown for a chip not in the table or a model without a speed figure, never guessed), then model rank, coding agent rank and the larger context. A coding agent counts when it is not gated, is installed or has a stock install command without sudo or brew, works at that context and accepts the model id. A download must leave 10 GiB free on the disk; the best-ranked model left out for that reason is named in a note.
• Verdicts: ok; limited when no model of 12 billion parameters or more fits (a statement about the Mac, judged before the disk filter); none with a reason (not-macos, intel, macos, memory, no-harness, disk) and one sentence.
• "Recommended for this Mac" appears only for an ok pick that has a tested entry for exactly this chip, this memory size and this coding agent. The catalogue has one: Qwen3.6 35B-A3B with OpenCode on an Apple M5 Pro with 48 GB. Any other ok pick reads "Best fit for this Mac" with "Codeman has not run this on a Mac like this yet."; a limited answer has a headline of its own.

What each Mac gets (estimated budget, every coding agent available; pinned for every size from 8 to 512 GB in test/local-model-recommend.test.ts, the rule tests run on a frozen copy of the first catalogue in test/fixtures/local-model-rules-catalog.ts):

Memory	Budget	What it gets
8 GB	2.1 GB	Nothing. The smallest model a coding agent can work with needs 10.2 GB at 65,536 tokens
16 GB	10.4 GB	Nothing. MiMo V2.6 9B at 65,536 tokens needs 10.2 GB, 98.7% of the budget, just past the 98% a tight fit may reach (it is 95% of the 10.7 GB a 16 GB Mac mini measured). On the edge either way: only a run on such a Mac settles it
18 GB	11.8 GB	A small model (limited): MiMo V2.6 9B at 131,072 tokens, 11.4 GB, tight. Its base, Qwen3.5 9B, is the one alternative
24 GB	16.1 GB	The same, with room. On a base M2 or M3 (100 GB/s) it computes to 9.3 tokens per second: slow
32 GB	21.8 GB	The same. North Mini Code 1.0 needs 23.2 GB at 65,536 tokens; once the runtime measures about 3/4 of the memory, as it did on a 16 and a 48 GB Mac, the Mac gets it at 131,072 tokens, or Qwen3.8 27B at 65,536 tokens on a Max chip
36 GB	27.9 GB	Qwen3.8 27B at 131,072 tokens on an M4 or M5 Max (27.0 GB, 97%); on a slower chip, where the dense 27B computes to under 10 tokens per second, Qwen3.6 35B-A3B as a GGUF build (27.1 GB, 97%). Both tight
48 GB	37.6 GB	Qwen3.6 35B-A3B (MLX) at 131,072 tokens: the pair we tested, "Recommended" on an Apple M5 Pro with 48 GB. On a Max chip Qwen3.8 27B at 262,144 tokens (32.1 GB, tight). The test was a short task: in a long session MLX may keep up to 8 GiB more, which brings this pair to the edge of the budget, and past it while a long prompt is processed
64 GB	50.5 GB	Qwen3.8 27B at 262,144 tokens on a Max chip; Qwen3.6 35B-A3B (MLX) on a Pro chip
96 GB	76.2 GB	Qwen3.8 27B at 262,144 tokens; on an M3 Max, Qwen3.6 35B-A3B (MLX)
128 GB	102 GB	Ornith 1.5 122B-A10B (MLX) at 131,072 tokens, 97.4 GB, tight
192, 256, 512 GB	154 GB+	Ornith 1.5 122B-A10B at 262,144 tokens

Every pick runs with OpenCode. Set aside on purpose, with the reason in the catalogue header: Bonsai 2 27B (no agent-loop evidence), Ornith 1.5 397B and 9B/35B (no tool parser in the runtime), Flint (a tool-argument bug), LFM2.5 and Qwen3.8-Flash-Next (licences), Laguna (open macOS issues), gpt-oss:20b (weak at agentic coding), and the plain MLX tags at 36 GB and below (the 8 GiB prefix budget).

From a Claude Code session: cloud plus local

The codeman skill (skills/codeman, mirrored into plugins/codeman) can hand work to the installed model, so a Claude Code session plans and reviews in the cloud while the Mac does the bulk:

• local_model asks GET /api/v1/local-model once and prints one line of JSON: installed and running or not, the coding agent, the endpoint and the model, or the reason there is nothing to use (not a Mac, nothing installed, install unfinished, blocked, admin only, no local model support on an older server). It never downloads or installs anything.
• spawn_worker <name> local (also name:local in spawn_workers) starts the runtime the way the window's Start does when it is stopped, then quick-starts the installed agent with customModel (the same launch as the window's Start a session). A confirmation the server asks for fails the spawn with empty stdout; the skill never confirms. Readiness for OpenCode is its composer bar, measured live with OpenCode 1.3.0; a worker that never draws it is deleted.
• sendmark <sid> <prompt> [timeoutSec] gives any worker without an end-of-turn signal a task: the prompt asks for the answer in codeman-answer-<token>.md plus a completion marker, and the helper returns once the marker shows or the answer file has settled (OpenCode's streamed redraws can split the marker, which a live run showed), reading at most 256 KB and refusing a symlink.
• Tests: test/agent-skill-local-model.test.ts runs the real preamble against a fake server (34 tests, under bash 5 and bash 3.2).

Keeping the catalogue current

.github/workflows/local-model-catalog.yml runs scripts/check-local-model-catalog.mjs every Monday (and on demand): for every row it reads the registry the way the pinned runtime does on a Mac, and reports a tag that is gone, a size that drifted, or a runner that changed, plus a newer runtime release. It opens or updates ONE issue ("Local model catalogue: weekly check"), with contents: read and issues: write only. Its first live run found two rows of the first catalogue with the wrong Mac size, which the rebuild fixed. A model change still ships only in a release: the catalogue is compiled in on purpose.

The install

POST /api/local-model/install with { modelId, cli, context, acknowledgedBytes } starts one job of five steps (src/local-model/install-job.ts):

Step	What it does
runtime	downloads, checks and unpacks the pinned runtime, chooses a port, starts it, reads the measured budget and judges the choice again. A model that no longer fits ends the job here with does-not-fit and the next model to try, before any of the model is downloaded
model	pulls the model through the runtime (POST /api/pull, parsed piece by piece: a 23 GB pull is about 1.4 million lines), retried up to five times
verify	one small chat that loads the model; GET /api/ps must show all of it on the GPU at the chosen context; one tool call on /v1/chat/completions whose arguments parse
agent	installs the coding agent with the CLI registry's stock command; skipped when it is installed
connect	saves the endpoint and switches the endpoints setting on (below)

Before anything is downloaded, the request must name a model and context the current recommendation offers and a coding agent offered for that row (else 400), and acknowledgedBytes must be the server's own total for it (else 409 size-changed with the new total). A saved endpoint called local-ollama that this feature did not write is a 400 at this point too. One job at a time, and one installed model: another install answers 409 until Remove. Every step can be entered again, so Resume and Try again continue where the job stopped. Cancel interrupts the step in flight and pauses; in connect it counts only before the first write, after which both writes finish and the job ends installed. A job a server restart interrupted comes back paused and never continues without a click. Every failure is an error code with one sentence and one next step.

The other verbs are POST /api/local-model/cancel, POST /api/local-model/resume ({ newPort? }), POST /api/local-model/runtime ({ action: "start" | "stop", newPort? }) and DELETE /api/local-model ({ removeModel? }). Stop, a port change and Remove answer 409 with the session names while a live session uses the model.

Downloads, and how each is checked

• Runtime: Ollama 0.40.15, ollama-darwin.tgz from Ollama's GitHub release, 185,971,671 bytes. The URL, size and sha256 are a compiled constant (OLLAMA_RUNTIME_PIN in src/local-model/runtime.ts) that no file, setting, environment variable or request can change. The archive is hashed while it streams, continued with a Range request at most three times, refused when longer than the pin, and compared before anything is unpacked; a mismatch deletes it. /usr/bin/tar unpacks it into a temporary folder, which is then renamed, and the archive is deleted.
• Model: pulled by the runtime from its own registry under the catalogue's name:tag. Codeman does not hash the model itself, and the catalogue pins the name, not a digest. Once the check passed, Codeman stores the digest the runtime reports and compares it again at boot and before every agent start on the endpoint.
• Coding agent: the compiled stock install command of a catalogue row, never a clis.json override (for OpenCode, curl -fsSL https://opencode.ai/install | bash). The window shows that literal command on the confirm screen before it sends the install; the server cannot tell whether an API caller saw it. Codeman verifies nothing about what that script fetches, the same as the install button in App Settings > CLIs, whose runner this step now shares (src/cli-install-runner.ts: an environment without CODEMAN_*, its own process group, a five-minute bound, one install per CLI at a time). It does not need cliManagementEnabled, and it writes the admin audit entry cli_install with via: "local-model".

What runs, and what is written where

• The runtime is a non-detached child of the Codeman server, running as the server's user. Its environment is an allowlist: PATH, TMPDIR, LANG, the proxy variables, a private HOME, and fixed OLLAMA_* values (loopback host, model folder, context length, OLLAMA_NO_CLOUD=1, a 10-minute keep-alive, one request and one loaded model at a time). No CODEMAN_* variable and none of the user's own OLLAMA_* settings reach it. It listens on 127.0.0.1, on a port chosen once by binding from 11435 (11434 is left to a runtime the user may run). It is started at boot once a model is installed and was not stopped, restarted at most three times after a crash, and sent SIGTERM at shutdown. A leftover from a server that was killed is recognized by the command line of its stored pid (/bin/ps -o command=: a binary under Codeman's runtime folder) and adopted or replaced. Any other listener on the port is port-in-use and is never signalled.

• The other programs this feature runs, all as the server's user: /usr/sbin/sysctl, /usr/bin/tar, /usr/bin/xcode-select -p (whether the developer tools are there; never git or python3), /bin/ps, and the coding agent's installer.

• On disk, under the data dir: local-model.json (the job's state, mode 0600, holds no path, not part of config backups) and local-model/ with runtime/ollama-0.40.15/ (about 579 MB, plus the archive while it downloads), models/ (23.1 GB for the 35B model) and home/ (the runtime's private HOME, where it keeps its key pair; the user's own ~/.ollama is never created or touched). Every path comes from src/local-model/paths.ts, never from the state file.

• Beyond those, Codeman writes two things, both undone by Remove:

  1. One record in custom-model-hosts.json: id local-ollama, label "This Mac", baseUrl http://127.0.0.1:<port>, the one model, and the chosen context as defaultContextLength (the runtime states none, so this is what reaches the coding agent).
  2. customModelEndpointsEnabled: true in settings.json (off by default). The value before is kept, and Remove switches it off again only when this feature switched it on and no other endpoint is saved. Switching it on also starts the existing five-minute discovery sweep for the other saved endpoints.

  The connection is claimed in the state file before either write, so a server killed between them leaves nothing the state file does not know about. The admin audit log gets local_model_install, local_model_remove and cli_install entries.

• The coding agent's installer writes wherever it installs (OpenCode: under ~/.opencode). Remove leaves the agent installed.

• Remove ends the runtime before any file goes, then deletes the runtime and its private home, and the model when asked, only inside local-model/ (and refuses a local-model folder that is a symbolic link). In the window "Also delete the downloaded model" starts ticked; the API keeps the model unless removeModel is true.

Starting a session on it

"Start a session" goes through the existing custom model launch (the Run menu's endpoint entry) with the installed coding agent on local-ollama. Before a new agent process is started on that endpoint, the server checks that the runtime child it started is alive, that the model's digest is the stored one, and that the model asked for is the one installed. The check sits on every path that starts an agent: a new session with the model (POST /api/quick-start), a model applied to a running session (POST /api/sessions/:id/custom-model), the attach that creates a missing pane or respawns a dead one (from a click on the tab or boot recovery), restartCli(), and the reboot-restore rebuild, which skips the entry as local-model-not-ready and leaves it on offer. An attach to an agent that still runs, and a respawn cycle that types into it, are not launches and are not asked. A refusal is a LaunchRefusedError and never falls back to a direct PTY.

Changes outside the feature

• src/custom-model-hosts-writer.ts: every write of custom-model-hosts.json (the four writing /api/model-endpoints routes, the discovery sweep and this feature's connect step) now goes through one serialized writer with a random temp name, mode 0600. Before, two writers at once could tear the file or drop each other's record: ten creates sent together did not all land. A file that does not parse is now refused with 409 instead of being read as an empty list and replaced, and deleting an unknown id no longer rewrites the file. The id local-ollama is reserved: a new endpoint may not take it, and while the record is the managed one these routes neither edit nor delete it and the sweep skips it. All of this is visible on the stable /api/v1/model-endpoints routes: creating an endpoint with that id, or editing or deleting the managed record, now fails with INVALID_INPUT. A guard test fails any other writer in src/.
• src/cli-install-runner.ts: the CLI install runner moves out of cli-registry-routes.ts unchanged, so both callers share it; the route's tests are unchanged. New in it: an abort signal that kills the process group, stockInstallCommand() and tryBeginCliInstall().
• src/session.ts: setLaunchGuard() and LaunchRefusedError, asked before every new agent process. WebServer.setupSessionListeners() sets the guard for every session, and it has nothing to say for a session that is not on the managed endpoint.
• src/web/server.ts: the routes, the service's boot() at start-up and shutdown() beside stopDeepSeekWeb() (both skipped in test mode).
• src/web/sensitive-path.ts: the runtime's private home and any .ollama/id_ed25519 are sensitive paths.
• Docs: the guide docs/local-models.md, the API reference, the versioning policy, security architecture §10d and .github/SECURITY.md (the port without a login), plus the endpoint pages, the wiki and both CLAUDE.md files.

Map of the new files

File	What it holds
src/types/local-model.ts, src/types/local-model-install.ts	the payload, every sentence the server may send (the zh-CN dictionary is keyed by them), the install states, steps and error codes
src/config/local-model-catalog.ts	the catalogue and its schema
src/local-model/hardware.ts	the probe
src/local-model/recommend.ts	recommend() and modelFitsBudget(), pure
src/local-model/harness-facts.ts	the one module here that reads the CLI registry
src/local-model/runtime.ts	the pin, the download, the environment, the port, the supervisor, removal
src/local-model/ollama-client.ts	the runtime's HTTP API, the pull parser, the checks
src/local-model/install-job.ts	the state tables, the pure reducer, the view and the service (2,235 lines)
src/local-model/connect.ts	the two writes, their undoing, the digest comparison
src/local-model/state-store.ts, paths.ts, format.ts, developer-tools.ts	the state file, the folders, the one size formatter, the xcode-select -p check
src/web/routes/local-model-routes.ts	the six routes
src/web/public/local-model-ui.js	the button, the Settings row and the window (styles in styles.css and mobile.css, strings in i18n.js)

About 31,000 lines are added: 18,600 of them tests, 9,000 server code, 3,100 frontend.

Testing

Unit and integration tests (no Mac, no network, no runtime process; the end-to-end test does run the real /usr/bin/tar):

• The probe parser on the captured sysctl output of two real Macs, the catalogue schema, recommend() across memory sizes, chips and every none reason, the pull parser and the checks, the state file, the job's reducer, and the window over the real markup in JSDOM.
• A fake runtime (test/fixtures/fake-ollama.ts) on a port the system picks, answering in the shapes measured on a Mac.
• test/local-model-install-e2e.test.ts runs the real routes, service, download, hash check, /usr/bin/tar, supervisor, pull, checks, connection and state file against that fake: the whole install and its removal, a runtime download that arrives damaged, a model download that fails twice and then finishes, one that keeps failing, a model that calls no tool, Cancel during the download, a server restart during the download, and a runtime left behind by a server that was killed.
• Launch guard tests for both session routes, the dead-pane respawn, restartCli() and reboot restore.
• The full gate on the branch head (be8fc298): 16,013 tests in 732 files passed, 12 skipped. test/local-model-ui.browser.test.ts, which is outside the gate, passes 6 of 6 in Chromium.

On a real Mac (a MacBook Pro with an M5 Pro chip and 48 GB, macOS 27.2), with a server from a test branch that merged this branch with the other 1.50.0 work:

• GET /api/local-model, on an earlier head of this branch with the same rules, answered Qwen3.6 35B-A3B at 131,072 tokens with OpenCode, 36.0 of 37.6 GB estimated, tight, tagged "Tested on a Mac like this", OpenCode not installed.
• The start screen button and the chooser were seen in the macOS app on that Mac.
• The install request the button sends (qwen3.6:35b-a3b, OpenCode, 131,072, acknowledgedBytes 23,291,770,627) was sent through the API, not clicked: the runtime (about 0.2 GB) in 5 s, the model (23.1 GB) at 53 to 74 MB/s, verify, the OpenCode install, connect. The state was installed after 376 s, with the model loaded on the GPU and the endpoint on port 11435.
• The chooser's start-a-session request (quick-start with OpenCode and customModel on local-ollama), also sent through the API, started an OpenCode session on the local model, and it answered a prompt.

By hand, before this feature existed, with the same runtime build and the same model on that MacBook; the catalogue's measured figures and its one tested entry come from this run. The runtime reported a device total of 37.4 GiB and generated 67.7 tokens per second. The model held 36,000 to 38,000 bytes per token of context and 2.5 to 3 GB beside the weights, and took 5.3 GiB (5.7 GB) more for a moment while an 89,000-token prompt was processed (the catalogue uses 37,000 bytes, 3 GB and 5 GB). A four-step task with tools made 4 tool calls, none malformed. On a Mac mini with an M4 and 16 GB the same runtime reported 11.8 GiB, and the recommendation tests use that figure: that Mac gets no model with either budget.

Limits

• Nothing but the 48 GB pair is measured: the rebuilt rows are computed. Measuring the shortlist on a real Mac (the 16 GB and 18 GB 9B first, then the llama.cpp settings on Metal) can promote rows to measured or move the 16 GB answer, which today misses a tight fit by 0.7%. The skill's local worker path has run against a fake server and a live OpenCode on Linux, not yet on a Mac with the model.

• The tested 48 GB pair was measured on single long prompts. A runtime issue reports this model's MLX build growing up to 8 GiB over a long agent session, which would pass the measured budget on that Mac; a 30-request session settles it.

• The runtime's port has no login. Any program on the Mac, and any page served from localhost, can use the model server and change its models, as with any model server of its kind. Codeman limits what that buys (one model in the endpoint record, the sweep leaves it alone, the digest check before an agent starts) but does not authenticate the port. Listed in .github/SECURITY.md.

• Not yet done on a real Mac: clicking Install in the window (the real install went through the API), Cancel and Resume, Stop and Start, Remove, a Codeman restart with a model installed (the start at boot, adopting or ending a leftover runtime, SIGTERM at shutdown with live sessions), the launch refusals and a change of the runtime pin. Only the tests above cover these. Nobody has tried Safari.

• Only OpenCode has been run on the local model. Claude Code is offered as the second coding agent (the catalogue marks its first turn as slow, for its long fixed prompt) and has not been run against this runtime.

• The runtime stops with Codeman. A session that is mid-answer on the local model loses that answer at a Codeman restart; the runtime comes back with the server and the first request loads the model again. An open session keeps calling the port while the runtime is stopped, which is why Stop and a port change are refused while a session uses the model.

• An agent that already runs when Codeman restarts is not checked again, since Codeman does not start it.

• The runtime does not enforce the context length: in the hand run it accepted a 167,012-token prompt at 131,072.

• A loaded model keeps its memory for ten minutes after the last request (23.2 GB for the 35B model on the MacBook).

• The memory figures rest on one measured model. They may be too high for the 9B rows, which is what leaves 16, 18 and 24 GB Macs without a model, and too low for the two dense 27B rows. Only the check after the download (all of the model on the GPU) catches a row judged too kindly. The speed estimates come from one published run on an M1 Max.

• The model is pinned by name, not by digest: an install gets what the registry serves under that tag that day, and from then on the digest is held.

• There is no way to update the runtime in place. An installed model keeps the runtime version it was installed with; a later pin takes effect after Remove and a new install.

• After does-not-fit the window offers only a model that needs less memory, not the same model at a smaller context.

• The OpenCode the job installs is not on the login shell's PATH: Codeman finds it, opencode typed in a terminal does not.

• A config-backup restore can take the endpoint record away while the model stays installed. Codeman puts it back at its next start, not at the restore.

• The runtime archive is fetched with Node's built-in fetch, which ignores HTTP_PROXY by default; the model pull goes through the runtime, which is given the proxy variables. Neither has been tried behind a proxy.

• On a phone, "this Mac" is the server. mobile.css makes the window full-screen, and the start screen button is reached only with the phone overview switched off. This PR reports no run of it on a phone or in npm run test:mobile.

• For reviewers: harness-facts.ts repeats the launch path's model-id acceptance test, which session-routes.ts keeps inline at two sites, so a change to that rule must be made in all three until they share a helper. install-job.ts holds both the pure tables and the IO service.

Landing

Base master. The branch sits directly on the current master and merges cleanly. It is already in the 1.50.0 integration branch; when the release lands, master fast-forwards to it and this PR shows as merged.

It depends on no other PR of the batch. Against the others it has two small text conflicts, both resolved on the integration branch by keeping both sides: config/test-suites.ts with #763 (each adds a browser test to the list) and the state files line of CLAUDE.md with #778. #783 also changes the start screen and merges with this one without a conflict.

No changeset on the branch: the 1.50.0 release changeset covers it.