43645d4b59
Sweep findings #3 and #4 (plans/admin-portal-functional-sweep.md). #3. "stale" was inert. The models page offers active / deprecated / stale, and only "deprecated" was ever read. The reasoning in the old docstring was wrong rather than conservative: it said stale "already has its own filter", meaning freshness.exclude_stale -- but that filter reads models.availability, the catalog column, and an admin override lives in admin_model_overrides and is never merged into those rows. Selecting "stale" wrote a row and changed nothing. Measured on /route before the fix: 27 candidates with a stale override set, 27 with it cleared, against 28 when a deprecated override was cleared. Both off-states now exclude, unconditionally rather than gated on freshness.exclude_stale / exclude_deprecated. Those settings are a policy about catalog age; an override is an operator naming one model, and an explicit instruction should not need a second flag to take effect. _admin_deprecated_models is renamed _admin_excluded_models in all three modules, since "deprecated" no longer describes what it returns. #4. The override bound /route but nothing else. /v1/models reads models.availability directly, so a switched-off model stayed advertised; _resolve_pinned_provider had no check, so a client that took it from that list was served by it as normal. The override applied to routed traffic only, which is the opposite of what "deprecated" reads as in the portal. Both are now closed, and /v1/models grows the same guard it already applies under gaming mode -- with the comment there giving the reason verbatim: do not advertise a model whose pin is about to be refused. The new tests parametrize over both off-states rather than testing "deprecated" and trusting "stale" to follow, since trusting that is exactly how stale stayed inert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VRQXz5SYZYVWscxS1QqF6U
5.0 KiB
5.0 KiB