> ## Documentation Index > Fetch the complete documentation index at: https://docs.gloo.com/llms.txt > Use this file to discover all available pages before exploring further. # Model Lifecycle > How models arrive in the Gloo AI catalog, what happens when one is retired, and how to detect both from the API. The Gloo AI catalog changes as providers ship new models and retire old ones. Both ends of that lifecycle are visible in one place — [`GET /platform/v2/models`](/api-reference/get-models/v2) — so you can detect additions and deprecations programmatically instead of watching for an announcement. Nothing on your side needs redeploying or reconfiguring to pick up a new model — it becomes usable the moment it appears in the catalog. A deprecation is best effort rather than a guarantee: where a replacement has been chosen, the deprecated ID keeps serving requests while you migrate, and where one has not, the catalog says so. ## New models Gloo AI tracks provider releases automatically, and new models are usually added to the catalog within a business day or two of a provider making them generally available. Once a model is listed it is immediately usable across the [Responses API](/api-guides/responses-v1) and [Completions V2](/api-guides/completions-v2) — pass its ID as the `model` parameter. ### Where to find available models * **[Supported Models](/api-guides/supported-models)** — a live table of the current catalog, grouped by family, with context windows, list pricing, and capability flags. * **[`GET /platform/v2/models`](/api-reference/get-models/v2)** — the public, unauthenticated endpoint the table is built from. Call it directly to enumerate models programmatically; poll it to detect new additions. Use each entry's `id` field as your `model` parameter. * **[Model Explorer in Gloo Studio](https://studio.ai.gloo.com/models)** — a richer side-by-side comparison including modalities, reasoning, and speed ratings. All three read from the same catalog, so they agree by construction — the table and the Model Explorer are renderings of what the endpoint returns, not separately maintained lists. Pick whichever suits the task: the endpoint to automate against, the table to scan, the Explorer to compare. ### Model ID naming Gloo model IDs follow a consistent, human-readable pattern: ``` gloo-- ``` For example: | Model ID | Provider | Model | | ---------------------------------- | --------- | ----------------- | | `gloo-anthropic-claude-sonnet-4.6` | Anthropic | Claude Sonnet 4.6 | | `gloo-openai-gpt-5-mini` | OpenAI | GPT-5 mini | | `gloo-google-gemini-2.5-pro` | Google | Gemini 2.5 Pro | Always take the exact ID from the `id` field of the catalog rather than constructing it by hand — the naming pattern is a convention, not a guarantee, and the catalog is the source of truth. ### Model families Every model carries a `family` field that groups it by its underlying provider or model line — for example **Anthropic**, **Google**, **OpenAI**, and **Open Source**, alongside other families as new providers are added. The [Supported Models](/api-guides/supported-models) table is organized by this field, and it is returned on every [`GET /platform/v2/models`](/api-reference/get-models/v2) entry so you can filter or route by family in your own code. ### Adopting a new model To switch to a newly available model, set the `model` parameter to its ID — no other change is required. Before you commit to a model, check its per-model capability flags (`supports_tools`, `supports_streaming`, `supports_reasoning`, `supports_vision`), its `context_window`, and its `input_modalities` / `output_modalities`. These are shown in the Supported Models capability table and returned on the models endpoint. You can try a new model before changing any code: pick it from the model dropdown in the [Chat Playground](/studio/playground-chat) in Gloo AI Studio and send it a prompt. The playground draws its model list from the same catalog, so a newly added model is selectable there as soon as it is listed. Playground requests run through your organization's credentials and are billed at standard rates. Watching [`GET /platform/v2/models`](/api-reference/get-models/v2) programmatically is the most reliable way to learn about new models as soon as they land — no announcement or manual check required. ## Deprecated models Models are occasionally retired as providers release newer, better, or cheaper alternatives. Retirement is ultimately the provider's decision, not ours, so what we can offer is a best effort to make it a managed transition rather than a silent break: where we can, a deprecated model ID keeps serving requests and the catalog tells you what replaces it, so you have time to migrate. Treat that as best effort rather than a guarantee. A provider can withdraw a model faster than any notice period, and when that happens we redirect if there is a suitable replacement and tell you if there is not. The catalog is the authoritative signal in both cases — check `is_deprecated` on the models you use. ### How deprecations are announced Deprecations are surfaced on the catalog itself. Each [`GET /platform/v2/models`](/api-reference/get-models/v2) entry carries: * **`is_deprecated`** — `true` once a model is scheduled for retirement. * **`deprecation_note`** — a plain-language explanation, including the replacement and any price change. Read this one specifically: it is where a price increase, or a move to a different family, is stated. * **`replacement_model`** — the Gloo model ID that requests are routed to. The [Supported Models](/api-guides/supported-models) table also renders a **Deprecated** badge and the note inline for any flagged model. ### Where a deprecated ID's requests go When a model is deprecated and a replacement has been chosen, requests still using the old ID are routed to that replacement, so the flag appearing is not by itself a breaking change on your side. When no replacement has been chosen — `replacement_model` is null — nothing is redirected, and the old ID stops working once its catalog entry is removed. Replacements normally stay within the same model family — a deprecated Anthropic model is replaced by another Anthropic model, and the same holds for every family. Where no model in the family is suitable, a replacement may be chosen from another family, and the `deprecation_note` says so. You are never moved to a different family silently. ### How a replacement is chosen Choosing a replacement is best effort, like the rest of a deprecation — these are the criteria we apply, not promises about an outcome a provider ultimately controls. Two of them do the most work: * **Capability should not go backwards.** We look for a model that supports everything the deprecated one did — tool calling, vision, reasoning, its input modalities — with a context window at least as large, and we do not substitute one that would shrink your context window or drop a capability you were using. * **Price stays within a band.** A candidate costing more than **1.3× the deprecated model's rate on either the input or the output axis** is not considered. Within those limits we prefer, in order: the newest model in the same family priced at or below the old one on both axes; then a same-family model priced within the band; then the same provider; then any family. Many models also declare their successor in advance, and where that exists it is used directly rather than recomputed. For example, when Claude Sonnet 4 was deprecated its requests were routed to Claude Sonnet 4.6 at the same price; when Claude Opus 4 was deprecated its requests were routed to Claude Opus 4.8 at a lower price. Same-or-cheaper is the ordinary outcome. **A replacement can cost more per token than the model it replaced.** It happens when nothing same-or-cheaper clears the capability bar, and it is capped at 1.3× on each axis. The `deprecation_note` states the increase whenever there is one. If you bill through on token cost, read it when a model you use is flagged rather than assuming the price is unchanged. If nothing at all clears both bars, no automatic redirect is made. The model is flagged deprecated with no `replacement_model`, and choosing where that traffic goes is left to you — we would rather tell you there is no equivalent than move you somewhere that quietly is not one. ### Notice before removal Once a model is flagged as deprecated and its replacement routing is in place, its catalog entry is intended to stay listed for at least a week before it can be removed, so both the old ID and its replacement are live and interchangeable while you migrate. Routing for a retired ID is intended to outlive its catalog entry, but the catalog is the contract: an ID you can still see in [`GET /platform/v2/models`](/api-reference/get-models/v2) is supported, and one that has been removed is not. Treat continued routing after removal as a courtesy rather than something to build on. ### What you should do Poll [`GET /platform/v2/models`](/api-reference/get-models/v2) and check the `is_deprecated` flag on the models you use. This is the earliest and most reliable signal. When a model you depend on is deprecated, read its `replacement_model` and `deprecation_note` to see exactly where its traffic is being routed and whether the price changes. An empty `replacement_model` means no equivalent was found and the choice is yours. Update the `model` parameter in your requests to the replacement ID. Migrating explicitly keeps your configuration accurate and lets you validate the replacement's behavior on your own timeline, rather than relying on automatic routing indefinitely. You do not have to migrate the moment a model is flagged — automatic routing keeps your integration running. Migrating simply keeps your requests pointed at a model ID that is still listed and actively maintained.