What's wrong with this entry?
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.
- 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).
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.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.