# 2.5 — `GET /v1/models` (GREEN)

Phase: 2 — LLM surface
Stage: GREEN
Depends on: [2.1](2.1-model-registry.md)

- [ ] `GET /v1/models` returns 200 with `Content-Type: application/json`
- [ ] The response shape is `{"object":"list","data":[{"id","object":"model","owned_by","created"}]}`
- [ ] Every entry's `object` is the literal string `model`
- [ ] The `id` values are exactly the model names the configured registry will accept for dispatch — no more, no fewer
- [ ] Adding or removing a model in configuration changes this response with no code change
- [ ] No model list is hardcoded anywhere; the list cannot disagree with what routing accepts
- [ ] The endpoint contacts no upstream and stays cheap

Kong served a static list via `request-termination`, and its own manifest flags that
the list can drift from what the engines actually serve. Deriving from the registry
makes that drift structurally impossible: the same source answers this endpoint and
decides which `model` values dispatch.

## Verify

```bash
curl -s localhost:8080/v1/models
# expected: 200, {"object":"list","data":[...]} with ids reasoning, ornith:35b, qwen2.5:3b-instruct,
#           nomic-ai/nomic-embed-text-v2-moe, BAAI/bge-reranker-base

# every advertised id must dispatch; nothing advertised may 404
for m in $(curl -s localhost:8080/v1/models | grep -o '"id":"[^"]*"' | cut -d'"' -f4); do
  curl -s -o /dev/null -w "$m %{http_code}\n" localhost:8080/v1/chat/completions \
    -H 'content-type: application/json' -d "{\"model\":\"$m\",\"messages\":[]}"
done
# expected: no unknown-model rejection for any advertised id
```