Hosted models retire from 14 October: pin model IDs, and know which open weights you could run yourself

Hosted model retirements from 14 October 2026: pin your model IDs, and know which open weights you could run yourself

Start with the calendar. Over ten days in October 2026, several hosted model IDs reach their retirement dates. OpenAI's deprecations page lists a block of legacy snapshots and fine-tuned lines with a shutdown date of 23 October 2026. Google's open-model Model-as-a-Service table sets 21 October as the retirement date for DeepSeek, GLM, Qwen3, Llama 3.3, Kimi K2, MiniMax M2, gpt-oss-20b and E5 embedding IDs, and names self-deploying the same weights as the alternative. Google's own pages disagree on Gemini 2.5 Pro, Flash and Flash-Lite: an April release note says 16 October, while the lifecycle table read on 6 October says 20 October. Snowflake's own deprecation notice sets 14 October 2026 as the end-of-life date for two Cortex models, claude-4-sonnet and openai-gpt-4.1.

The thesis fits in two sentences. A hosted model ID is a dependency with an expiry date, so it belongs in an inventory with a named owner. Open weights you run yourself carry no vendor retirement date, but they move the upgrade clock, the hardware and the patching onto you.

What follows: the provider-by-provider calendar, what "retired" means in practice, six habits for pinning model IDs, the honest trade-offs of self-hosting, and a sidebar on Aleph Alpha's Kolibri, released on 3 October with open weights under Apache 2.0. Every date below comes from a vendor page; those pages were re-read on 6 October 2026, and Snowflake's on 9 October 2026.

OpenAI, 23 October. The section of OpenAI's deprecations page dated 22 April 2026 lists these snapshots for shutdown on 23 October: gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-turbo, gpt-4.1-nano, gpt-4o-2024-05-13, gpt-image-1, o1-2024-12-17, o1-pro-2025-03-19, o3-mini-2025-01-31, o4-mini-2025-04-16 and ft-o4-mini-2025-04-16, plus fine-tuned lines on gpt-3.5-turbo, gpt-4, gpt-4.1-nano, babbage-002 and davinci-002. The replacements OpenAI names are the gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna family, with gpt-image-2.5-sunburst or gpt-image-2.5-flare for gpt-image-1. Several rows also list related names in a separate column, and the table does not say plainly whether those names stop too. Where a row also lists related names, check every name your code calls against the page.

Google open models, 21 October. Google's open-model MaaS deprecations table lists DeepSeek (OCR, R1-0528, V3.1 and V3.2), GLM (5 and 4.7), gpt-oss-20b, Kimi K2 Thinking, Llama 3.3 70B Instruct, MiniMax M2, two multilingual E5 embedding models and four Qwen3 variants: 16 model IDs in all, with a retirement date of 21 October. All were deprecated on 21 July, and every row names self-deploying the model on Model Garden as the alternative.

Gemini 2.5 on Google Cloud, 16 or 20 October. An April release note set 16 October; Google's lifecycle table read on 6 October shows 20 October. Plan for the earlier date and check the lifecycle page for your project. In detail: a Vertex AI release note from around 2 April 2026 says the retirement dates for Gemini 2.5 Pro, Flash-Lite and Flash "have been updated to October 16, 2026." The live model versions and lifecycle table shows 20 October for all three, with replacements such as gemini-3.8-flash, gemini-3.5-flash, gemini-3.5-flash-lite and gemini-3.1-flash-lite. We found no later note that explains the difference. Google's Gemini API deprecations page announces no shutdown date for these three models, so the clock depends on which Google surface a workload calls.

Snowflake Cortex, 14 October. Snowflake's Cortex model deprecations notice lists 14 October 2026 as the end-of-life date for claude-4-sonnet and openai-gpt-4.1, which entered legacy status on 12 August 2026. After end-of-life, queries and API calls that name either model fail.

ChatGPT and Codex, 14 October. OpenAI's official ChatGPT & Codex changelog, in an entry dated 14 September 2026, sets 14 October 2026 as the date on which GPT-5.5 is retired from ChatGPT, ChatGPT Work and Codex on all plans, including Business, Enterprise and Edu. The same entry says the retirement does not apply to the OpenAI API, so API calls to gpt-5.5 are not affected by it. In Codex, workspace defaults, saved model settings, custom agents, scheduled tasks and scripts that still select gpt-5.5 need a replacement model.

The calendar does not stop after October. The next OpenAI dates already on the page are 1 December for GPT Image models and 11 December for dated GPT-5 and o3 snapshots.

"Retired" sounds administrative. In production it means errors. Google's open-model page defines two stages. During the deprecation period the endpoint keeps working for existing workloads so you can migrate, but new use of the endpoint may be restricted. On the retirement date the endpoint is deactivated, and API requests that call a retired model ID fail.

OpenAI's wording is shorter: at shutdown, a model or endpoint is no longer accessible. One rule on the same page catches teams out. Inference on a fine-tuned model stops when its base model is deprecated, so a fine-tune is only as durable as the base it was trained on. The customer who paid for a fine-tune last year bought something that carries the base model's expiry date.

Notice periods vary by stage. OpenAI's page promises at least six months for generally available models, at least three months for specialised variants, and possibly as little as about two weeks for models with preview in the name. Google keeps preview-stage open models available for at least 45 days from release. The practical rule: preview IDs do not belong on a customer-facing critical path unless the contract allows a fast migration.

There is an escape hatch, and it is commercial. OpenAI says some developers may be able to arrange dedicated capacity for continued access after a shutdown date through its sales team. That is a negotiation, not a default, and it should not be the plan.

What breaks in an MSP estate is rarely the flagship app. It is the forgotten summarizer in a ticketing integration, the embedding job behind a search index, or the fine-tune a customer paid for last year. Embedding retirements matter twice: a new embedding model usually means re-indexing the corpus, not only swapping a name in a configuration file.

An inventory row needs a pinned ID, the date, a replacement under test, and a named owner. The illustrative YAML below shows the shape; every name in it is a placeholder.

# model-inventory.yaml: one row per call site, reviewed monthly
- call_site: ticket-summarizer
  provider: openai
  model_id: o4-mini-2025-04-16        # listed for shutdown 2026-10-23
  replacement_under_test: gpt-5.6-terra
  owner: platform-team
  eval_set: summaries-golden-v3
  cutover_ticket: CHG-0000
- call_site: kb-search-embeddings
  provider: google-maas
  model_id: multilingual-e5-large-instruct-maas   # retires 2026-10-21
  plan: self-deploy same weights OR switch model + re-index
  owner: search-team

Pinning is not a product. It is six habits, each with something that counts as evidence.

1. Call dated snapshots, not floating names, in production. A floating name can move to a new model under you. A dated ID changes only when you change it. Evidence: the deployed configuration shows the dated ID. Not evidence: "we use the latest."

2. Keep one inventory row per call site, with provider, exact ID, owner, retirement date and the replacement under test. Search code, infrastructure configuration and low-code automations, not just the main application. The call sites that hurt are usually the ones built outside the main repository.

3. Subscribe to the source of truth. That means the vendor deprecation pages and the account emails they send. A roll-up newsletter is a tip, not a source. This article proves the point: one Google page disagrees with another Google page on Gemini 2.5.

4. Test the replacement on your own traffic with a small golden set before cutover: output format, refusals, latency and cost per task. Never assume a "recommended replacement" behaves the same as the model it replaces.

5. Cut over before the date, with a rollback window that ends before the date. A rollback to a retired ID is not a rollback. If the earliest plausible date is 16 October, the rollback window closes before 16 October.

6. Treat default changes as releases. When a provider changes which model a default name points to, the bill and the behaviour can move without any price change. Pinning is what turns that into a planned change with a ticket, a test and an owner.

The cleanest evidence in this story that hosted access and the model itself are different things comes from Google. For every open model with a 21 October retirement date, Google's own table documents the alternative: deploy the same weights yourself on Model Garden. The endpoint goes away; the weights do not.

What you gain is specific. Weights you download and serve do not disappear because a vendor retires an endpoint. You choose when to upgrade, and you can keep the exact revision you validated. Pin the repository revision you tested, not just the model name, because a model repository can change after you first downloaded from it.

What you take on is just as specific: GPUs or reserved capacity, a serving stack and its updates, monitoring, your own evaluation before every upgrade, and the security patching of everything around the model. That is a real operating cost. The figure depends on your workload and your contracts, so this article does not put a number on it.

Licences differ. Some open models ship under Apache 2.0; others use custom licences with their own conditions on use, attribution or scale. Read the licence of the exact repository before a customer depends on it, and keep a copy next to the inventory row.

Where does it fit for an MSP? Steady, well-defined workloads such as classification, extraction and retrieval over a customer's own documents are good candidates. Frontier-level reasoning on spiky demand often is not. A hybrid is normal: hosted models for the hard tail, pinned self-hosted weights for the predictable core. This is a general pattern, not a recommendation for any particular hosting product.

Sidebar: Kolibri, open weights released on 3 October. Aleph Alpha announced Kolibri from Heidelberg on 5 October 2026 in a press release. The model has been available since 3 October and supports German and English. The company says it is designed for deployment on infrastructure customers control, with documented data provenance and design decisions. It supports agentic workflows, retrieval-augmented generation and native tool calling, and Aleph Alpha says it was trained to abstain when the supplied documents lack evidence.

The shape, from the Hugging Face model card: a mixture-of-experts model with 78 billion total parameters and about 3.46 billion active per token (the press release rounds this to around 3 billion). Native context is 262,144 tokens; the card says quality was validated up to about one million tokens, but recommends staying at or below 262,144 for serving efficiency.

The licence, verified on the card on 6 October, is Apache 2.0 for the weights and configuration files published in that repository. The card also says what the grant does not extend to: underlying code, model architecture, parameter settings or any training method. "Open weights under Apache 2.0" is the accurate description. Calling the whole stack open source goes beyond what the card claims.

Hardware reality, again from the card: FP8 weights with a memory footprint of about 78 GB, and a listed minimum of two A100 80 GB, two H100 SXM5, or one H200, B200 or B300. Serving uses Aleph Alpha's aleph-alpha-inference package, a vLLM plugin, or its container image, and the card shows an OpenAI-compatible API once the model is served that way. Few active parameters lower the compute per token. They do not shrink memory: the whole model still has to fit.

Why it belongs here: no vendor retirement date applies to weights you host yourself, and Kolibri is a current, dated example of that option for German- and English-language work. Three context lines matter. The card says the model is intended for workflows where a person reviews output before it is acted on. Aleph Alpha's agreement with Cohere remains subject to regulatory approval, and the company continues to operate independently until closing. And "sovereign", in Aleph Alpha's release, is the company's word for customer control and freedom of choice. It is not a certification, and this article claims none.

The verified calendar, in one paragraph: OpenAI's legacy snapshots and fine-tuned lines have a shutdown date of 23 October. Google's open-model MaaS IDs have a retirement date of 21 October, with self-deploying the same weights as Google's own documented alternative. For Gemini 2.5 Pro, Flash and Flash-Lite on Google Cloud, the retirement date is 16 or 20 October depending on which Google page you read, so plan for 16. Snowflake's end-of-life date for claude-4-sonnet and openai-gpt-4.1 in Cortex is 14 October.

The operating rule does not change with the vendor. A hosted model ID is a dependency with an expiry date: pin it, inventory it, give it an owner, and test the replacement on your own traffic before the date. Open weights you run carry no vendor retirement date, but the upgrade clock, the hardware and the patching become yours. Kolibri is one dated example of open weights under Apache 2.0, with a licence that its model card scopes to the weights and configuration files in the repository.

All vendor pages cited here were re-read on 6 October 2026, and Snowflake's notice on 9 October 2026. If a vendor moves a date, this article will be corrected.