v0.2.1 — require explicit model list for API mode
Follow-up to v0.2.0. The previous release's /v1/models endpoint
silently fell back to [adapter.name] (e.g. ["pi"]) when no model
list was configured — that's a harness binary name, not a valid model
id. OAI clients calling /v1/chat/completions with model="pi" got
nonsense.
This release:
- API mode refuses to boot if neither AICODEBOX_AVAILABLE_MODELS
nor adapter.available_models declares anything. Loud failure
with a clear "set this env var" message.
- /v1/models reflects the configured list verbatim — no
adapter-name fallback.
- Telegram /model and /effort pickers degrade gracefully on empty
list (reply with a "set this env var" message; bot keeps running).
- Cron / MCP / passthrough are unaffected — they forward the
caller's model string to the harness, which errors directly on
bad model ids.
- shared/choices.py is the single source of truth for the list.
Breaking change vs v0.2.0: API mode containers that didn't set
AICODEBOX_AVAILABLE_MODELS used to boot and serve /v1/models with the
bogus fallback. Now they refuse to start. Set the env var
(comma-separated) with the model ids your provider actually serves.