Model Management and Inference
Model Capability Registry — Stack
Model capability registry › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
This is a small, slowly-changing, highly-read dataset whose main risk is silent staleness.
- Schema strength. Are capability fields typed and enumerated, or free-text? A free-text modality list cannot be queried by a routing rule.
- Provenance per field. Can an entry record where each value came from — provider documentation, a provider API, or a measurement — and when it was last confirmed?
- Freshness signalling. Whether the store can express and enforce a maximum age, and surface entries past it before a caller depends on them.
- Read path. Whether consumers can read it without a network call on the hot path: a generated artefact, an embedded snapshot, or a cached client.
- Change control. Whether admitting a model is a reviewable change with an approver, which matters once the registry also carries residency and approval status.
- Extensibility. Room for fields you have not thought of yet, without a migration for every new model attribute the industry invents.
Options
| Option | Best for | Watch out for |
|---|---|---|
| A versioned file in the repository (JSON/YAML) validated by schema in CI | Small estates; making admission a pull request with an approver | Updating it is manual, so freshness depends entirely on someone remembering |
| Generated from provider list-models endpoints at build time | Keeping identifiers and context windows in step with what the account can actually call | Provider listings omit price, residency, and most behavioural facts; they cover a fraction of the schema |
| Community-maintained model metadata (LiteLLM's model cost and context map, OpenRouter's model listing) | A fast start on prices and context windows across many providers | Third-party transcription of someone else's pricing page; verify before billing against it |
Hugging Face model cards and config.json for open-weight models |
Authoritative context length, architecture, and licence for self-hosted weights | Cards are author-written and uneven; the licence field in particular needs human reading |
| An existing service catalogue or CMDB entry type | Organisations where governance already requires every external dependency to be catalogued | Generic catalogues model ownership and contracts, not context windows; expect a custom schema |
| A small internal service with an API and a cached client | Large estates with many consumers and frequently changing entries | You have built a runtime dependency for data that changes monthly; cache aggressively and degrade to the last snapshot |
Whatever the store, fix the minimum field set required before a model is admitted: a pinned version identifier, context and output ceilings, tokenizer family, input modalities, tool-calling and structured-output behaviour, price per million input and output tokens, processing region, and retirement date. A model that cannot be described in those terms cannot be depended on by the components that read this registry.