From ed2e37d14d17f7a7b6383692c6e29ebf513af11f Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 3 Sep 2026 17:29:36 +0000 Subject: [PATCH] Do not register models the catalog would not offer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The registry is cheap to append to, which is why it grows without anyone deciding that it should. A daily job proposing every model its providers ship makes that worse, not better: left alone it would register routing for models nothing surfaces, and each one is a name the gateway then has to route, price and test forever for a model no user can select. Point the skill at the curation bar that actually governs this — the one in chat-api's add-catalog-model skill, where a new model earns a picker row only if it offers something no current row does, and a better model replaces the model it supersedes instead of joining it. Registration is downstream of that decision, so apply it here first rather than registering speculatively and sorting it out later. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01LCzE1jP1Yvy4fbSj4xtRkv --- .claude/skills/add-gateway-model/SKILL.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/.claude/skills/add-gateway-model/SKILL.md b/.claude/skills/add-gateway-model/SKILL.md index 2fe0815..7a9e1e1 100644 --- a/.claude/skills/add-gateway-model/SKILL.md +++ b/.claude/skills/add-gateway-model/SKILL.md @@ -16,6 +16,22 @@ change. A model from a *new* provider is a different, larger job: it needs a client, an API key path in `__main__.py` and `/v1/keys`, and is out of scope for a routine model addition. +## Register only what will actually be offered + +The registry is cheap to append to, which is exactly why it grows without +anyone deciding to. Do not register a model speculatively: routing exists so +chat-api's catalog can offer the model, and that catalog holds a real curation +bar (`.claude/skills/add-catalog-model/SKILL.md` there — a new model earns a +picker row only if it gives users something no current row does, and a better +model replaces the one it supersedes rather than joining it). Apply the same +judgement here first. If the model would not clear that bar, do not register +it; if it supersedes a model already registered, expect the catalog change to +hide the old one, and say which in your PR. + +Registered-but-unoffered ids are not free: every one of them is a name the +gateway must keep routing, price correctly and test, for a model no user can +select. + ## Steps 1. **Check it isn't already there.** Grep `_MODEL_LOOKUP` for the api name and