|
| 1 | +# Removing a built-in model is a no-op on the user's own machine |
| 2 | + |
| 3 | +**Problem (one line):** Asked to "remove qwen3.5", I deleted it from |
| 4 | +`DEFAULT_CONFIG` — but `ccmr models` still showed it, and `qwen` still |
| 5 | +defaulted to 3.5. |
| 6 | + |
| 7 | +## Approach |
| 8 | + |
| 9 | +1. Ran the Five Copies edit for the add/remove/add as usual. |
| 10 | +2. Verified the package with `new ConfigManager(null)` (defaults only) → all |
| 11 | + correct: 3.5 gone, `qwen` → 3.8-max. |
| 12 | +3. Verified again with `node dist/cli.js models` → **3.5 still there.** The |
| 13 | + two commands disagreed. That gap is the whole lesson. |
| 14 | +4. Cause: `ccmr models` goes through **config discovery**, which finds the |
| 15 | + user's `~/.ccmr/models.yaml` (or a project `models.yaml`) and **merges it |
| 16 | + over** `DEFAULT_CONFIG` at the *variant* level. Those files carry a full |
| 17 | + `qwen:` block generated by an old `ccmr init`, so they re-declare the 3.5 |
| 18 | + variants and pin `default_variant: 3.5-plus`. User config wins → the |
| 19 | + package deletion is invisible on that machine. |
| 20 | +5. Surfaced the gap, got the user's OK to also patch `~/.ccmr/models.yaml` |
| 21 | + and `ccmr-start/models.yaml`, then re-verified `ccmr models` from each cwd. |
| 22 | + |
| 23 | +## Judgment calls (deliberately NOT done) |
| 24 | + |
| 25 | +- **Did not edit the user's live yaml silently.** Those files weren't named in |
| 26 | + the request; editing `~/.ccmr` / `ccmr-start` is a "stop and ask" trigger. |
| 27 | + I reported the merge gap and asked before touching them. |
| 28 | +- **Did not "fix" the 403 in code.** `qwen3.8-max` pay-go returned |
| 29 | + `403 AccessDenied`; a control test (`qwen3.7-max` → OK on the same key) |
| 30 | + proved key+endpoint+model_id are right and the 403 is account-side |
| 31 | + (preview not granted). Account state, not a router bug. |
| 32 | +- **Did not guess a base_url from the lookalike domain.** The request pointed |
| 33 | + at `platform.qianwenai.com` (not Alibaba's usual `dashscope.aliyuncs.com`). |
| 34 | + Read the vendor's own Anthropic reference first: the API endpoint is the |
| 35 | + official `dashscope.aliyuncs.com/apps/anthropic` with `x-api-key`; only the |
| 36 | + subscription/key portal lives on qianwenai.com. So it's the same endpoint as |
| 37 | + pay-go, differing only by an `sk-sp-` key → a separate provider |
| 38 | + (`qwen-plan`, new `QWEN_PLAN_API_KEY`), same step/step-plan precedent. |
| 39 | + |
| 40 | +## Reusable rule |
| 41 | + |
| 42 | +When a request says **remove** (or re-default) a built-in model, the |
| 43 | +`DEFAULT_CONFIG` edit alone changes nothing on any machine whose |
| 44 | +`~/.ccmr/models.yaml` or project `models.yaml` re-declares that provider — |
| 45 | +user config merges over defaults per-variant. Always verify with |
| 46 | +`node dist/cli.js models` (discovery path), not just `ConfigManager(null)`; |
| 47 | +if they disagree, the user's live yaml must be patched too — and that's a |
| 48 | +scope decision to confirm, since those files are rarely named in the request. |
| 49 | +See also [[vendor-platform-split]]. |
0 commit comments