claudeup 6.7.1 → 6.8.0

package/src/__tests__/models-adapter.test.ts

@@ -6,6 +6,7 @@ import {
 } from "../data/models-presets.js";
 import type { ModelsConfig, ModelsStatus } from "../services/models-core.js";
 import {
+	CUSTOM_LABEL,
 	type ModelsBrowserItem,
 	buildModelsItems,
 	firstSelectableIndex,
@@ -161,9 +162,9 @@ describe("marking the active preset", () => {
 		]);
 	});
 
-	test("a hand-edited config gets a row of its own, marked active", () => {
-		// Without it the list shows four built-ins with none marked, which reads
-		// as "routing is off" for a project whose routing is emphatically on.
+	test("a diverged config gets ONE row, called `Custom`, carrying its settings", () => {
+		// Divergence is a thing you HAVE, not a fault. The row is the option that holds those
+		// settings, so they can be selected and inspected like any preset.
 		const config = customConfig();
 		const items = buildModelsItems({
 			status: status({ state: "on", preset: "custom" }),
@@ -174,16 +175,30 @@ describe("marking the active preset", () => {
 		const rows = presetRows(items);
 		expect(rows).toHaveLength(BUILT_IN_PRESETS.length + 1);
 		const mine = rows.at(-1);
-		expect(mine?.config.preset).toBe("custom");
+		expect(mine?.label).toBe(CUSTOM_LABEL);
 		expect(mine?.custom).toBe(true);
 		expect(mine?.active).toBe(true);
 		expect(mine?.isDefault).toBe(false);
-		// Its own config, so the detail pane shows what it actually routes.
+		// Its own config, so the detail pane and the chart show what it actually routes.
 		expect(mine?.config).toBe(config);
-		// And it is the ONLY active row.
+		// And it is the ONLY active row: a built-in of the same name is not this routing.
 		expect(rows.filter((item) => item.active)).toHaveLength(1);
 	});
 
+	test("the `Custom` row is never labelled with the file's `preset` string", () => {
+		// `models use opus-lead` writes `opus-lead`, and hand-editing afterwards leaves it. A
+		// row labelled from that string wears a built-in's name while not being that built-in.
+		const items = buildModelsItems({
+			status: status({ state: "on", preset: "opus-lead" }),
+			config: { ...customConfig(), preset: "opus-lead" },
+			query: "",
+		});
+		const mine = presetRows(items).at(-1);
+		expect(mine?.custom).toBe(true);
+		expect(mine?.label).toBe(CUSTOM_LABEL);
+		expect(mine?.label).not.toBe("Opus main");
+	});
+
 	test("a config naming a built-in adds no extra row", () => {
 		const items = buildModelsItems({
 			status: status({ state: "on", preset: "sonnet-economy" }),

package/src/__tests__/models-cli.test.ts

@@ -108,6 +108,83 @@ describe("models list", () => {
 		expect(out).toContain("(default)");
 	});
 
+	/**
+	 * A hand-edited config that routes agents through claudish.
+	 *
+	 * `models list` prints TIERS, never agents, so before this a mate assigned per-agent —
+	 * the ordinary way to use one — appeared nowhere in the command's output at all, and the
+	 * project's own config was printed as a bare name while the four presets it replaced were
+	 * printed in full.
+	 */
+	test("an UNBOUND slot says so, rather than printing its own name as a model", async () => {
+		// A slot with no entry in `mates` names no model at all. Printing `kangaroo` in the
+		// model column would read as a model id nobody recognises — the slot is a role, and a
+		// role is not a model. Saying `unbound` names the thing the reader has to go fix.
+		await fs.outputJson(join(project, ".claude", "models.json"), {
+			version: 1,
+			preset: "outback",
+			main: { model: "opus", effort: "xhigh" },
+			grades: {
+				smart: { model: "kangaroo" },
+				normal: { model: "opus", effort: "xhigh" },
+				cheap: { model: "sonnet", effort: "high" },
+			},
+			agents: { "dev:researcher": { model: "mate1" } },
+			fallback: "normal",
+		});
+
+		const code = await runModelsCommand(["list"], project);
+
+		expect(code).toBe(0);
+		const out = logs.join("\n");
+		expect(out).toContain("outback");
+		expect(out).toContain("unbound");
+		expect(out).toContain("via claudish");
+		// And the per-agent routing, which no tier row could have shown.
+		expect(out).toContain("dev:researcher");
+		expect(out).toContain("mate1");
+	});
+
+	test("a BOUND slot prints the external model, not the slot name", async () => {
+		// The other half, and the one that makes the pair worth having: without it, a bug that
+		// printed `unbound` unconditionally would pass the test above and look like proof.
+		//
+		// `grok-4.6` is written as a bare catalog id on purpose — no `@`, no `/`. Those forms
+		// pin a provider and bypass subscription-aware routing, and the validator rejects them.
+		await fs.outputJson(join(project, ".claude", "models.json"), {
+			version: 1,
+			preset: "outback",
+			main: { model: "opus", effort: "xhigh" },
+			grades: {
+				smart: { model: "kangaroo" },
+				normal: { model: "opus", effort: "xhigh" },
+				cheap: { model: "sonnet", effort: "high" },
+			},
+			agents: { "dev:researcher": { model: "mate1" } },
+			mates: {
+				kangaroo: { model: "grok-4.6" },
+				mate1: { model: "kimi-k3", effort: "high" },
+			},
+			fallback: "normal",
+		});
+
+		const code = await runModelsCommand(["list"], project);
+
+		expect(code).toBe(0);
+		const out = logs.join("\n");
+		expect(out).toContain("grok-4.6");
+		expect(out).toContain("kimi-k3");
+		// The bound slot must no longer be advertising itself as unbound.
+		expect(out).not.toContain("kangaroo → unbound");
+	});
+
+	test("says nothing about claudish when no agent is routed there", async () => {
+		// The negative control for the block above: it is a report, not a standing headline.
+		const code = await runModelsCommand(["list"], project);
+		expect(code).toBe(0);
+		expect(logs.join("\n")).not.toContain("claudish");
+	});
+
 	test("marks the active preset", async () => {
 		await seedProfile();
 		await runModelsCommand(["use", "opus-lead"], project);
@@ -130,6 +207,29 @@ describe("models status", () => {
 		expect(logs.join("\n")).toContain("Model tiers:");
 	});
 
+	test("a config that routes agents through claudish is healthy, not invalid", async () => {
+		// Validity is a property of the FILE, not of this machine: the multimodel plugin is
+		// certainly not installed in a temp directory, and the config still has to read as
+		// routing that works. `off` is the honest state here — nothing has been applied.
+		await fs.outputJson(join(project, ".claude", "models.json"), {
+			version: 1,
+			preset: "outback",
+			main: { model: "opus" },
+			grades: {
+				smart: { model: "mate1" },
+				normal: { model: "opus" },
+				cheap: { model: "kangaroo" },
+			},
+			agents: { "dev:docs": { model: "mate2" } },
+			fallback: "normal",
+		});
+
+		const code = await runModelsCommand(["status"], project);
+
+		expect(code).toBe(0);
+		expect(logs.join("\n")).not.toContain("invalid");
+	});
+
 	// An invalid config routes nothing, so it is a failure, not a report.
 	test("exits 1 on an invalid config and prints each error", async () => {
 		await fs.outputJson(join(project, ".claude", "models.json"), {

package/src/__tests__/models-core.test.ts

@@ -7,6 +7,8 @@
  * bench — never a reason to relax the assertion.
  */
 import { describe, expect, test } from "bun:test";
+import { readFileSync } from "node:fs";
+import path from "node:path";
 import {
 	BUILT_IN_PRESETS,
 	DEFAULT_AGENT_GRADES,
@@ -17,11 +19,13 @@ import {
 	EFFORTS,
 	type Effort,
 	GRADES,
+	MATES,
 	type ModelsConfig,
 	baseAlias,
 	buildSettingsPatch,
 	computeModelsStatus,
 	evaluateAgentHook,
+	isMate,
 	isRoutableModel,
 	resolveAgentRouting,
 	validateModelsConfig,
@@ -250,6 +254,48 @@ describe("evaluateAgentHook", () => {
 		const d = evaluateAgentHook(agentCall({ model: "" }), base());
 		expect(d.kind).toBe("update");
 	});
+
+	/**
+	 * A mate passes through, and says so in its own words.
+	 *
+	 * The reason is not cosmetic. `unroutable-model` is the hook reporting a BROKEN config —
+	 * a value that would refuse the spawn if it were injected — and a mate is the config
+	 * working exactly as written. Reporting one as the other would make every deliberate
+	 * external routing look like a typo in the hook log, which is the only place a user can
+	 * see what the hook decided.
+	 */
+	test("a mate passes through as `mate`, never as `unroutable-model`", () => {
+		for (const mate of MATES) {
+			const c = base();
+			(c.grades.smart as { model: string; effort?: Effort }).model = mate;
+			// biome-ignore lint/performance/noDelete: a mate carries no effort
+			delete (c.grades.smart as { effort?: Effort }).effort;
+			const decision = evaluateAgentHook(agentCall(), c);
+			expect(decision).toEqual({ kind: "passthrough", reason: "mate" });
+		}
+	});
+
+	test("a mate pinned to one agent passes through, and the rest still route", () => {
+		const c = base();
+		c.agents["dev:docs"] = { model: "kangaroo" } as never;
+		expect(
+			evaluateAgentHook(agentCall({ subagent_type: "dev:docs" }), c),
+		).toEqual({ kind: "passthrough", reason: "mate" });
+		// The negative control: the mate changed nothing about the agents around it.
+		expect(evaluateAgentHook(agentCall(), c).kind).toBe("update");
+	});
+
+	test("a mate is never written into updatedInput — there is no update to write it into", () => {
+		const c = base();
+		c.agents["dev:docs"] = { model: "mate1" } as never;
+		const decision = evaluateAgentHook(
+			agentCall({ subagent_type: "dev:docs" }),
+			c,
+		);
+		// Stated as the absence of an `update`, because `updatedInput.model` is the exact
+		// field AMR-1 measured as spawn-refusing for a non-alias.
+		expect(decision.kind).not.toBe("update");
+	});
 });
 
 describe("buildSettingsPatch", () => {
@@ -295,6 +341,55 @@ describe("buildSettingsPatch", () => {
 		expect(set.modelSettings).toBeUndefined();
 	});
 
+	/**
+	 * A mate may never reach `modelSettings`, and the guard that stops it is load-bearing.
+	 *
+	 * `add()` returns early on anything that is not an alias, which is currently the ONLY
+	 * thing keeping `mate1` out of settings — and it reads as an accident of ordering rather
+	 * than a rule, so it is pinned here. Two ways it could go wrong, both tested:
+	 *
+	 *   - a `mate1` key, which Claude Code can key nothing by;
+	 *   - an `undefined` key, which is what a `resolveFullId` returning null would write if
+	 *     the guard moved and the full-id branch ran on a name it cannot resolve.
+	 *
+	 * The config is built by hand past the validator on purpose: the validator refuses effort
+	 * on a mate, and this function is also reached from `doctor` and the TUI with whatever a
+	 * hand-edited file holds.
+	 */
+	test("a mate produces no modelSettings key of its own, and no `undefined` key", () => {
+		const c = base();
+		(c.grades.smart as { model: string; effort?: Effort }).model = "mate1";
+		c.agents.pinned = { model: "kangaroo" } as never;
+
+		const withResolver = buildSettingsPatch(
+			c,
+			((alias: string) => `claude-${alias}-5`) as never,
+		);
+		const keys = Object.keys(
+			withResolver.set.modelSettings as Record<string, unknown>,
+		);
+		for (const mate of ["mate1", "mate2", "kangaroo"]) {
+			expect(keys).not.toContain(mate);
+			expect(keys).not.toContain(`claude-${mate}-5`);
+		}
+		expect(keys).not.toContain("undefined");
+		// And the aliases beside it are untouched — the mate cost nothing else its entry.
+		expect(keys).toContain("opus");
+
+		// The same, with an effort the validator would have refused. This is the branch that
+		// actually exercises the `isModelAlias` gate rather than the `effort === undefined`
+		// one above it.
+		const forced = base();
+		forced.grades.smart = { model: "mate1", effort: "xhigh" } as never;
+		const patch = buildSettingsPatch(forced, noFullId);
+		const forcedKeys = Object.keys(
+			patch.set.modelSettings as Record<string, unknown>,
+		);
+		expect(forcedKeys).not.toContain("mate1");
+		expect(forcedKeys).not.toContain("undefined");
+		expect(forcedKeys.sort()).toEqual(["opus", "sonnet"]);
+	});
+
 	test("a [1m] main model keys its effort by the base alias", () => {
 		const c = base();
 		(c.main as { model: string }).model = "opus[1m]";
@@ -356,7 +451,10 @@ describe("computeModelsStatus", () => {
 		expect(s.drift).toEqual([]);
 	});
 
-	test("stale names the key that differs", () => {
+	test("settings differing from the config is CUSTOM, not a fault", () => {
+		// There is no state for it and no drift list. A project may run models and efforts no
+		// shipped preset names; the list says so with a `Custom` row carrying those settings,
+		// rather than the header reporting a difference as something to fix.
 		const s = computeModelsStatus({
 			config: base(),
 			errors: [],
@@ -364,108 +462,13 @@ describe("computeModelsStatus", () => {
 			settings: { ...applied(), effortLevel: "high" },
 			resolveFullId: noFullId,
 		});
-		expect(s.state).toBe("stale");
-		expect(s.drift.join(" ")).toContain("effortLevel");
-	});
-	/**
-	 * Drift text is READ BY A PERSON, and these three assertions each pin a defect that
-	 * shipped because the only existing test checked `.toContain("effortLevel")` — which the
-	 * broken copy satisfied too.
-	 */
-	test("an absent key is said in words, never as the string `undefined`", () => {
-		// `JSON.stringify(undefined)` returns the STRING "undefined", so the old line read
-		// `model: settings has undefined` — a JavaScript value leaking into user-facing text.
-		const s = computeModelsStatus({
-			config: base(),
-			errors: [],
-			hookRegistered: true,
-			settings: { model: "sonnet" },
-			resolveFullId: noFullId,
-		});
-		expect(s.state).toBe("stale");
-		expect(s.drift.join(" ")).not.toContain("undefined");
-	});
-
-	/**
-	 * A drift line may never say that X differs from X.
-	 *
-	 * This is the defect a code review caught by EXECUTING the function rather than reading
-	 * it: `modelSettings` was summarised on each side with the full-id keys filtered out to
-	 * keep the line short, so when only a full id differed — the overwhelmingly common case,
-	 * since the patch writes every model twice — both sides rendered identical text while
-	 * `JSON.stringify` correctly said they differed.
-	 *
-	 * It matters beyond legibility. Per AMR-1, a full id BEATS an alias when the two disagree,
-	 * so the suppressed key was the one actually serving subagents. And it arrives on its own
-	 * schedule: apply a preset, wait for the next model release, and the stored full id stops
-	 * matching the resolved one for every project.
-	 */
-	test("a modelSettings difference in a full-id key is named, not collapsed", () => {
-		const settings = {
-			...applied(),
-			modelSettings: {
-				opus: { effortLevel: "medium" },
-				"claude-opus-4-1-stale": { effortLevel: "low" },
-			},
-		};
-		const s = computeModelsStatus({
-			config: base(),
-			errors: [],
-			hookRegistered: true,
-			settings,
-			resolveFullId: noFullId,
-		});
-		const line = s.drift.find((d) => d.startsWith("modelSettings"));
-		expect(line).toBeDefined();
-		// The stale user-scope key is the one that wins at runtime, so it has to be visible.
-		expect(line).toContain("claude-opus-4-1-stale");
-		// And the line must state a CHANGE, never two identical halves.
-		expect(line).not.toMatch(/settings has (.+), config wants \1/);
-	});
-
-	test("only the models that actually differ are listed", () => {
-		// The control for the test above: a diff that named every key would satisfy it while
-		// burying the one that changed.
-		const s = computeModelsStatus({
-			config: base(),
-			errors: [],
-			hookRegistered: true,
-			settings: {
-				...applied(),
-				modelSettings: {
-					...(applied().modelSettings as Record<string, unknown>),
-					opus: { effortLevel: "low" },
-				},
-			},
-			resolveFullId: noFullId,
-		});
-		const line = s.drift.find((d) => d.startsWith("modelSettings"));
-		expect(line).toContain("opus low");
-		// `fable` agrees on both sides, so it has no business in a line about what differs.
-		expect(line).not.toContain("fable");
-	});
-	test("modelSettings drift is summarised, not dumped as JSON", () => {
-		// It is a map of model → effort and prints as one. Raw JSON was a 200-character wall
-		// that wrapped over four lines and told the reader nothing they could act on.
-		const s = computeModelsStatus({
-			config: base(),
-			errors: [],
-			hookRegistered: true,
-			settings: {
-				...applied(),
-				modelSettings: { opus: { effortLevel: "low" } },
-			},
-			resolveFullId: noFullId,
-		});
-		const line = s.drift.find((d) => d.startsWith("modelSettings"));
-		expect(line).toBeDefined();
-		expect(line).not.toContain("{");
-		expect(line).toContain("opus low");
+		expect(s.state).toBe("on");
+		expect(s.drift).toEqual([]);
 	});
 
-	test("nothing written at all is ONE line, not one per key", () => {
-		// Three lines that all say "absent" read as three distinct problems. The wording states
-		// effect, not history — an unparseable settings.json also reads as all-absent here.
+	test("settings written by nobody at all is still not a fault", () => {
+		// The strongest form of the same claim, and the one the old `1 drift` badge described
+		// most misleadingly: every key absent counted as ONE message.
 		const s = computeModelsStatus({
 			config: base(),
 			errors: [],
@@ -473,23 +476,23 @@ describe("computeModelsStatus", () => {
 			settings: {},
 			resolveFullId: noFullId,
 		});
-		expect(s.state).toBe("stale");
-		expect(s.drift).toHaveLength(1);
-		expect(s.drift[0]).toContain("carry none of the config");
+		expect(s.state).toBe("on");
+		expect(s.drift).toEqual([]);
 	});
 
-	test("but a partial write still names each key that differs", () => {
-		// The negative control for the collapse above: without it, a status that ALWAYS
-		// returned one line would pass that test and hide every real per-key difference.
+	test("drift survives for the states that ARE faults", () => {
+		// The negative control for the three tests above: `drift` was not emptied everywhere,
+		// only where it described a difference. An unhooked config routes NOTHING, and that
+		// line is the reason why.
 		const s = computeModelsStatus({
 			config: base(),
 			errors: [],
-			hookRegistered: true,
-			settings: { model: "opus" },
+			hookRegistered: false,
+			settings: applied(),
 			resolveFullId: noFullId,
 		});
-		expect(s.drift.length).toBeGreaterThan(1);
-		expect(s.drift.join(" ")).toContain("effortLevel");
+		expect(s.state).toBe("unhooked");
+		expect(s.drift.length).toBeGreaterThan(0);
 	});
 
 	test("warns that CLAUDE_CODE_SUBAGENT_MODEL is now inert", () => {
@@ -637,4 +640,163 @@ describe("isRoutableModel", () => {
 		])
 			expect(isRoutableModel(bad)).toBe(false);
 	});
+
+	/**
+	 * THE constraint the whole mate feature is built around.
+	 *
+	 * AMR-1 `bogus-model` measured 5/5 that a non-alias `model` refuses the spawn outright —
+	 * the session gets a tool error and no subagent at all. A mate is a non-alias by
+	 * construction, so a change that made this pass would not route agents to claudish, it
+	 * would stop the agents spawning. There is no version of this that is a nice improvement.
+	 */
+	test("a mate is NEVER routable — injecting one would refuse the spawn", () => {
+		for (const mate of MATES) expect(isRoutableModel(mate)).toBe(false);
+	});
+});
+
+describe("mates", () => {
+	test("isMate is exact — no prefix rule, no near match", () => {
+		for (const mate of MATES) expect(isMate(mate)).toBe(true);
+		// `mate10` is a typo, not a tenth slot; `Mate1` is a different string. Resolving
+		// either into a real slot would route an agent somewhere nobody named.
+		for (const bad of [
+			"mate",
+			"mate10",
+			"Mate1",
+			"mate3",
+			"kangaroo ",
+			"",
+			null,
+			3,
+		])
+			expect(isMate(bad)).toBe(false);
+	});
+
+	test("`kangaroo` is mate3 under another name, so all three are one vocabulary", () => {
+		expect([...MATES]).toEqual(["mate1", "mate2", "kangaroo"]);
+	});
+
+	test("a grade may name a mate, with no effort", () => {
+		const c = base();
+		(c.grades.smart as { model: string; effort?: Effort }).model = "mate1";
+		// biome-ignore lint/performance/noDelete: absence is the point — a mate carries none
+		delete (c.grades.smart as { effort?: Effort }).effort;
+		expect(validateModelsConfig(c)).toEqual([]);
+	});
+
+	test("an agent may be pinned to a mate", () => {
+		const c = base();
+		c.agents["dev:researcher"] = { model: "kangaroo" } as never;
+		expect(validateModelsConfig(c)).toEqual([]);
+		expect(resolveAgentRouting(c, "dev:researcher")).toEqual({
+			model: "kangaroo",
+			source: "agent-override",
+		});
+	});
+
+	test("main REJECTS a mate, and the message says why the main thread cannot take one", () => {
+		const c = base();
+		(c.main as { model: string }).model = "mate1";
+		const errors = validateModelsConfig(c);
+		expect(errors.map((e) => e.path)).toEqual(["main.model"]);
+		// Not a bare "must be one of …": the reason is that claudeup writes this value into
+		// settings.model, which has to name a model Claude Code itself runs.
+		expect(errors[0]?.message).toContain("settings.model");
+		expect(errors[0]?.message).toContain("claudish");
+	});
+
+	test("effort on a mate is ALLOWED — the rule reversed", () => {
+		// It used to be an error, on the reasoning that effort is keyed by model and a mate
+		// owns no `modelSettings` key. The key part is still true; the conclusion was wrong. A
+		// mate's effort is a per-call value handed to claudish, not a settings key, so there
+		// is nothing for it to collide with and no reason to refuse it.
+		//
+		// What must remain true is that it never reaches `modelSettings` — pinned separately,
+		// on `buildSettingsPatch`, because that is where the damage would be.
+		const onGrade = base();
+		onGrade.grades.cheap = { model: "mate2", effort: "high" } as never;
+		expect(validateModelsConfig(onGrade)).toEqual([]);
+
+		const onAgent = base();
+		onAgent.agents["dev:docs"] = { model: "mate1", effort: "low" } as never;
+		expect(validateModelsConfig(onAgent)).toEqual([]);
+	});
+
+	test("effort on `inherit` is STILL an error — the two questions are not the same one", () => {
+		// The half of the old rule that survives. `inherit` names no model at all, so there is
+		// no key AND no call to attach a value to; a mate names one claudish resolves.
+		const onGrade = base();
+		onGrade.grades.cheap = { model: "inherit", effort: "high" } as never;
+		const gradeErrors = validateModelsConfig(onGrade);
+		expect(gradeErrors.map((e) => e.path)).toEqual(["grades.cheap.effort"]);
+		expect(gradeErrors[0]?.message).toContain("inherit names no model");
+
+		const onAgent = base();
+		onAgent.agents["dev:docs"] = { model: "inherit", effort: "low" } as never;
+		expect(validateModelsConfig(onAgent).map((e) => e.path)).toEqual([
+			"agents.dev:docs.effort",
+		]);
+	});
+
+	test("two mates on the same model may declare different efforts", () => {
+		// Not a conflict, for the same reason the one-model-one-effort pass skips mates
+		// entirely: neither owns a `modelSettings` key, so neither can lose one to the other.
+		const c = base();
+		c.agents.a = { model: "mate1", effort: "low" } as never;
+		c.agents.b = { model: "mate2", effort: "xhigh" } as never;
+		c.mates = {
+			mate1: { model: "grok-4.6" },
+			mate2: { model: "grok-4.6" },
+		} as never;
+		expect(validateModelsConfig(c)).toEqual([]);
+	});
+
+	/**
+	 * Two seats on one mate is not the `modelSettings` conflict two seats on one alias is.
+	 *
+	 * The one-model-one-effort pass exists because `modelSettings` is keyed by model and one
+	 * key cannot hold two efforts. A mate owns no key at all, so there is nothing to collide
+	 * — and sending several agents to the same external model is the ordinary way to use a
+	 * slot, not a mistake to report.
+	 */
+	test("several agents may share one mate", () => {
+		const c = base();
+		c.agents.a = { model: "mate1" } as never;
+		c.agents.b = { model: "mate1" } as never;
+		(c.grades.cheap as { model: string; effort?: Effort }).model = "mate1";
+		// biome-ignore lint/performance/noDelete: absence is the point — a mate carries none
+		delete (c.grades.cheap as { effort?: Effort }).effort;
+		expect(validateModelsConfig(c)).toEqual([]);
+	});
+
+	/**
+	 * Validity may not depend on the machine reading the file.
+	 *
+	 * `models.json` is committed and shared through `profiles.json`, so if `mate1` were only
+	 * valid where `multimodel@magus` happens to be installed, the same file would be valid on
+	 * one teammate's laptop and invalid on the next one's — and the error would land on
+	 * whoever had not installed the plugin, over a routing decision they did not make.
+	 *
+	 * Pinned at the strongest available level: the module imports NOTHING, so there is no
+	 * seam through which a machine fact could reach the validator. Whether the slots are
+	 * DRAWN is a separate question, answered in the renderers from a boolean passed in.
+	 */
+	test("the core imports nothing, so validity cannot depend on the machine", () => {
+		// Comments are stripped first, the way hook-import-policy.test.ts does it: this file
+		// explains itself in English, and a sentence containing `from "…"` is not an import.
+		const specifiersOf = (file: string): string[] => {
+			const source = readFileSync(
+				path.join(import.meta.dir, "..", "services", file),
+				"utf-8",
+			)
+				.replace(/\/\*[\s\S]*?\*\//g, "")
+				.replace(/\/\/[^\n]*/g, "");
+			return [...source.matchAll(/\bfrom\s+["']([^"']+)["']/g)].map(
+				(match) => match[1] as string,
+			);
+		};
+		expect(specifiersOf("models-core.ts")).toEqual([]);
+		// Negative control: a regex that matched nothing would pass that forever.
+		expect(specifiersOf("models-manager.ts").length).toBeGreaterThan(0);
+	});
 });

package/src/__tests__/models-manager.test.ts

@@ -308,21 +308,24 @@ describe("readModelsStatus", () => {
 		expect(status.preset).toBe(PRESET);
 	});
 
-	test("reports stale when settings drift from the config", async () => {
-		await applyModelPreset({ projectPath: project, preset: PRESET });
-		const settingsPath = join(project, ".claude", "settings.json");
-		await fs.writeJson(settingsPath, {
-			...(await fs.readJson(settingsPath)),
-			model: "haiku",
-		});
+	test("settings differing from the config stays `on` — that is a custom config", () => {
+		// Nothing to report. A project running a model no preset names has made a choice, and
+		// the list shows it as a `Custom` row rather than the status calling it a problem.
+		return (async () => {
+			await applyModelPreset({ projectPath: project, preset: PRESET });
+			const settingsPath = join(project, ".claude", "settings.json");
+			await fs.writeJson(settingsPath, {
+				...(await fs.readJson(settingsPath)),
+				model: "haiku",
+			});
 
-		const status = await readModelsStatus(project);
-		expect(status.state).toBe("stale");
-		expect(status.drift.join(" ")).toContain("model");
+			const status = await readModelsStatus(project);
+			expect(status.state).toBe("on");
+			expect(status.drift).toEqual([]);
+		})();
 	});
 
-	// `unhooked` outranks `stale`: a config with no hook routes NOTHING, so
-	// leading with a drifted effort value would bury the reason.
+	// A config with no hook routes NOTHING, which is a fault and keeps its drift line.
 	test("reports unhooked when the hook is not registered", async () => {
 		await applyModelPreset({ projectPath: project, preset: PRESET });
 		await fs.writeJson(join(configDir, "settings.json"), {});