The internal model catalog has been refactored from a large inline constants object to a data-driven catalog loaded from a shared source file. Model provider IDs are now derived from structured catalog entries via helper functions, and a validation step ensures all named config exports have non-null provider IDs for every supported platform.
Details
- The catalog object (
iQs) is validated at runtime using a Zod schema (sfd()); if the parse fails the entire catalog silently falls back to an empty stub withschema_version: 0and no models. - A provider-ID reverse-lookup map (
lfd) is built at startup by iterating allprovider_idsvalues across all entries; if the same provider ID string appears in two distinct catalog entries the build throws a hard collision error. - Each entry carries:
id,family,display_name, optionalknowledge_cutoff, per-providerprovider_ids(first_party, bedrock, vertex, foundry, anthropic_aws, mantle, gateway),eager_input_streamingper provider,context(windowsize andsupports_1m_betaflag),capabilitiesarray (e.g."context_management","effort","adaptive_thinking","max_effort"), and optionaldeprecation(retirement_dates,remapped_to). - Top-level catalog fields include
aliases(family-to-provider-ID mappings with optional per-provider overrides),defaults,latest_per_family,alias_migration, andbest. - A build-time script (
bun run generate:model-catalog) validates and formats the source JSON before bundling; the runtime parse is a second safety net for any drift. - This catalog is the authority consumed by the new alias resolution path (see Model Alias Resolution entry above).
Evidence
New catalog loader (search for "Hand-maintained baked-in model catalog") and schema (search for "model catalog: provider id collision across distinct entries")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.