claude-api skill: five model IDs in models.md now return 404, one listed under "still active"

> **AI-assisted contribution.** I used Claude Code to run this sweep and check each ID
> against the API. Every status below is a real response from today, and the reproduction
> steps re-run the whole check from a fresh clone.

`skills/claude-api/shared/models.md` opens with:

> **Only use exact model IDs listed in this file.** Never guess or construct model IDs — incorrect IDs will cause API errors.

Five of the IDs currently listed produce exactly that error. Checked against the Messages
API today, 2026-08-17:

| ID | doc status | live |
|---|---|---|
| `claude-opus-4-5` / `-20251101` | Active | OK 200 |
| `claude-sonnet-4-5` / `-20250929` | Active | OK 200 |
| **`claude-opus-4-1` / `-20250805`** | under "Legacy Models (**still active**)", retires 2026-08-05 | **404** |
| **`claude-sonnet-4-0` / `claude-sonnet-4-20250514`** | Deprecated, retires TBD | **404** |
| **`claude-opus-4-0` / `claude-opus-4-20250514`** | Deprecated, retires TBD | **404** |
| **`claude-3-haiku-20240307`** | Deprecated, retires Apr 19 2026 | **404** |

The rows marked Active are all correct. It is specifically the deprecated and legacy rows
that have drifted.

Two things stand out:

1. `claude-opus-4-1` sits under the heading **"Legacy Models (still active)"** with a
retirement date of 2026-08-05, which passed 12 days ago. A reader following the heading
would reasonably conclude it still works.
2. The "Deprecated Models (**retiring soon**)" table describes three models that have
already retired, two of them as "Retires: TBD".

The underlying pattern looks like status fields that were accurate when written and go
stale silently as dates pass, with nothing to notice the transition from "deprecated" to
"gone".

## Why it seemed worth reporting

This skill is what gets loaded to answer model-ID questions, and the file explicitly tells
the reader to trust it over their own knowledge. So a stale row here does not just sit in a
doc, it becomes an answer. The failure mode is recommending a model that 404s, which is the
exact thing the opening instruction exists to prevent.

To be fair about the blast radius: the same line offers an escape hatch, pointing at the
Models Overview URL in `shared/live-sources.md` and at the Programmatic Model Discovery
section. Anyone who follows either gets current data. So this is bounded, not severe.

## Reproduce

```bash
git clone --depth 1 https://github.com/anthropics/skills.git && cd skills
sed -n '/## Legacy Models/,/Haiku 3/p' skills/claude-api/shared/models.md
```

Then call any of the bolded IDs:

```bash
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-opus-4-1","max_tokens":4,"messages":[{"role":"user","content":"hi"}]}'
```

```
{"type":"error","error":{"type":"not_found_error","message":"model: claude-opus-4-1"}}
```

`models.md:126` carries the same "retires 2026-08-05" phrasing in the natural-language
lookup table, and `shared/model-migration.md` lines 209, 220 and 492 reference the same
IDs, though those are migration tables where listing a retired ID is correct by design.

## Suggested direction

The minimal change is moving the four retired families into a "Retired" state and marking
the dates as passed rather than pending.

The slightly larger and more durable option: the repo already has both a `live-sources.md`
WebFetch table and a Programmatic Model Discovery section, so the ingredients for a
periodic check already exist. Something that flags rows whose retirement date is in the
past would catch this class of drift automatically. I have not assumed you want that, since
it is a workflow change rather than a docs edit.

Happy to send a PR for the table update if useful. I would rather not guess at the exact
status vocabulary you want ("Retired" vs "Unavailable" vs removing the rows), so I would
follow your preference on that.