Google Cloud lists 16 managed open-model IDs for retirement on 21 October

Sixteen IDs have a scheduled retirement date, not a measured outage

Google Cloud's managed open-model deprecation table lists 16 exact Model as a Service (MaaS) IDs with the same dates: deprecated on 21 July 2026 and scheduled for retirement on 21 October 2026. The documentation says an endpoint remains functional during deprecation; at retirement it is permanently deactivated and API requests to that retired ID fail. That is Google's published lifecycle rule and schedule. We have not independently observed a failed production request or established the hour at which any individual endpoint stopped answering.

This is a dependency story for teams whose applications call one of those 16 managed IDs. A model name embedded in a client library, environment variable, orchestration tool or batch job can survive long after its original selection. If it points to a retired managed endpoint, requests using that ID will fail under Google's stated policy. The impact can be an obvious API error, but it can also surface later in a scheduled run, rarely used fallback path or an embedding index that is updated only occasionally. The notice does not say that the underlying open model weights disappear or that every Google Cloud AI model is affected.

The complete 16-ID inventory

The official table contains four DeepSeek IDs, two GLM, one gpt-oss, one Kimi, one Llama, one MiniMax, two multilingual E5 embedding IDs and four Qwen IDs. The exact spelling matters: a different suffix or version may describe a different endpoint. The third column below records the family Google recommends for a self-deployed alternative; it is not a promise of identical model behaviour, context limits, request shape or cost.

All 16 MaaS IDs in Google's open-model deprecation table, read 21 October 2026. Every row has the same 21 July deprecation and 21 October 2026 retirement dates. The alternative is a Google-listed self-deploy family, not an automatic endpoint replacement.

Family	Exact retiring MaaS ID	Google-listed self-deploy family
DeepSeek	deepseek-ocr-maas	DeepSeek-OCR
DeepSeek	deepseek-r1-0528-maas	DeepSeek-R1
DeepSeek	deepseek-v3.2-maas	DeepSeek-V3.2
DeepSeek	deepseek-v3.1-maas	DeepSeek-V3.1
GLM	glm-5-maas	GLM 5
GLM	glm-4.7-maas	GLM 4.7
gpt-oss	gpt-oss-20b-maas	GPT OSS
Kimi	kimi-k2-thinking-maas	Kimi K2
Llama	llama-3.3-70b-instruct-maas	Llama 3.3
MiniMax	minimax-m2-maas	MiniMax M2
E5 embeddings	multilingual-e5-large-instruct-maas	E5 Text Embedding
E5 embeddings	multilingual-e5-small-maas	E5 Text Embedding
Qwen	qwen3-235b-a22b-instruct-2507-maas	Qwen3
Qwen	qwen3-coder-480b-a35b-instruct-maas	Qwen3 Coder
Qwen	qwen3-next-80b-a3b-instruct-maas	Qwen3 Next
Qwen	qwen3-next-80b-a3b-thinking-maas	Qwen3 Next

The two E5 entries deserve separate treatment from chat and code models. They are embedding endpoints: their outputs become vectors used for search and retrieval. Replacing an embedding model can change vector dimensionality, tokenisation, normalisation and the geometry of the index. A new deployment cannot safely be treated as a mere URL change. Record the old vector schema, rebuild or version the index when required, and compare retrieval quality on representative queries before a cutover. The retirement table names a common E5 Text Embedding self-deploy family for both IDs; it does not assert that their outputs are interchangeable.

Several other entries also serve distinct jobs despite sharing a family label: DeepSeek OCR is named for document recognition, Qwen Coder for coding, and Qwen Next has separate instruct and thinking IDs. An application that relies on a reasoning trace, image input, structured output, tool calls or a particular safety filter should test those behaviours separately. The presence of a similarly named family in Model Garden is a route to evaluate, not a guarantee that its managed endpoint contract continues.

Why self-deployment is a different operating model

Google's self-deployed model overview draws the boundary clearly. Managed MaaS is serverless and does not require the customer to deploy the model. A self-deployed model runs within the customer's Google Cloud project and VPC, where the customer controls the deployment environment. Google also says open models can be run on other infrastructure subject to the model's licence. Therefore the scheduled MaaS retirement is not a claim that DeepSeek, Llama, Qwen or the other model families cease to exist, or that a previously self-deployed copy will automatically stop.

The operational bargain changes when a team moves to self-deployment. It must select serving hardware and region, provision capacity, monitor utilisation and latency, patch the serving stack, and plan scaling and failure recovery. A managed endpoint may have a per-token bill; a self-deployment typically adds provisioned compute and idle-capacity costs. Google's deprecation table supplies no like-for-like price, throughput or availability comparison, so a headline cost saving or increase cannot be calculated from the notice alone. An alternative managed model may keep serverless operations, but it still needs compatibility, data-governance and quality tests.

Migration choices described by Google, with implementation implications inferred from the published service definitions. Verify actual product availability and terms for each candidate.

Route	What changes	What must be proven
Different managed endpoint	New model ID and possibly provider, version or API behaviour	Output quality, tool/schema compatibility, region, quota, price and error handling
Self-deploy from Model Garden	Customer operates model serving in its project and VPC	Weights and licence availability, hardware fit, scaling, security, latency and total cost
Run weights elsewhere	Infrastructure and support move outside this MaaS endpoint	Licence, data path, model serving, monitoring and recovery responsibility

A production migration needs a contract test and a rollback route

Start with discovery rather than a blanket text replacement. Search source code, config, model registries, API gateways, scheduled jobs and observability logs for each exact ID in the inventory. Attribute calls to owners and workloads, including low-frequency jobs and fallbacks. Record the current endpoint location, credentials, quotas and last successful request. This produces an exposure list instead of assuming that a model family name in a presentation is what production actually calls.

Build a small, permission-cleared evaluation set from the real workload. For generation, compare task success, hallucination and refusal patterns, JSON or tool-call validity, prompt-injection resistance where applicable, and latency under expected concurrency. For OCR, compare field extraction and error rate on representative scans and languages. For embeddings, compare retrieval precision and recall on the same query/document set, as well as vector dimensions and index migration time. These are proposed checks, not benchmark results from Google's notice. A version change that passes one generic prompt can still fail a production contract.

Then perform a canary cutover: route a small, observable slice of traffic to the replacement, keep the old response path only while it remains available, and watch error rates, timeouts, output validity, cost per successful task and user-facing failures. Define an explicit stop condition and a fallback that does not itself call another retiring ID. For embedding systems, dual-write or versioned indexes can support a safer transition than mixing old and new vectors in one unlabelled store. After cutover, remove the retired IDs from deployment templates and add a retirement-date check to model governance.

Decision log for an engineering owner. Unknowns require an actual request, configuration review or commercial confirmation; they are not answered by the retirement table.

Question	Evidence to keep
Are we actually using one of these 16 IDs?	Configuration search plus recent API logs, including batch and fallback paths
Does the candidate meet the same product contract?	Golden-set outputs, schema/tool tests and error budget at production concurrency
Does a self-deploy fit governance and budget?	Model licence, region/data flow, hardware, quota, support and capacity-cost estimate
Can we recover from a failed cutover?	Canary metrics, fallback destination, owner and tested rollback procedure

What remains unknown on the retirement date

Google's page gives a calendar date and lifecycle definition, but no time zone or precise switch-off hour for these 16 entries. It does not publish per-customer usage, incident reports, failed-request counts, a replacement managed ID for every row, or evidence that an endpoint was already unavailable when this article was checked. A support ticket or a customer-side API probe could establish the status of one deployment, but it would not establish the status of all regions and customers. Until that evidence exists, the accurate verb is scheduled for retirement on 21 October, not 'went offline'.

The practical consequence is narrower and more useful than a claim that open AI models are disappearing from Google Cloud: 16 named managed serving routes reach their documented retirement date. Teams that depend on one should verify their live call path, move to a tested endpoint or self-deployment, and prove that their fallback does not preserve the same retired dependency.