Generative AI models maintenance policy

This article describes the model maintenance policy for the Foundation Model APIs pay-per-token, Foundation Model APIs provisioned throughput, and Foundation Model Fine-tuning offerings.

In order to continue supporting the most state-of-the-art models, Databricks might update supported models or retire older models for these offerings.

Model retirement policy

The model retirement policy explains how Databricks notifies you when a supported model is set for retirement, what happens during the transition period, and what to expect on the retirement date. Timelines differ by offering and model category as summarized in the following sections.

For currently retired models and planned retirement dates, see Retired models. For partner models, see Partner model retirement policy.

Important

The retirement policies that apply to the Foundation Model APIs pay-per-token and Foundation Model Fine-tuning offerings only impact supported chat and completion models.

Foundation Model APIs pay-per-token

The following table summarizes the retirement policy for Foundation Model APIs pay-per-token.

Retirement notification	Transition to retirement	On the retirement date
Databricks takes the following steps to notify customers about a model that is set for retirement: On the Serving page of your Databricks workspace, a warning message appears on the model card that indicates that the model is planned for retirement. The applicable documentation contains a notice that indicates the model is planned for retirement and the start date it will no longer be supported.	Databricks will retire the model in three months. During this three-month period, customers can either: Choose to migrate to a Foundation Model APIs provisioned throughput endpoint to continue using the model past its end-of-life date. Migrate existing workflows to use recommended replacement models.	The model is no longer available for use and removed from the product. Applicable documentation is updated to recommend using a replacement model.

Foundation Model APIs provisioned throughput

The following table summarizes the retirement policy for Foundation Model APIs provisioned throughput.

Retirement notification	Transition to retirement	On the retirement date
Databricks takes the following steps to notify customers about a model that is set for retirement: For endpoints that serve a deprecated model, a warning message appears on that serving endpoint's details page in your Databricks workspace. This message indicates that the model is planned for retirement and the applicable retirement date. A tooltip message provides recommended alternate models for workload migration. The applicable documentation contains a notice that indicates the model is planned for retirement and the start date it will no longer be supported.	Databricks will retire the model in six months. During this six-month period: Customers can continue running existing provisioned throughput endpoints using the deprecated model until the retirement date. Customers that are not actively using a deprecated model cannot create new provisioned throughput endpoints or restart stopped endpoints for a deprecated model.	The model is no longer available for use and removed from the product. All endpoints using the retired model are transitioned to a failed state with a descriptive message. Any requests to these endpoints will fail. The customer can delete endpoints that use the retired model, but cannot restart them. Applicable documentation is updated to recommend using a replacement model.

Partner model retirement policy

Partner models are models provided by third-party partners, specifically OpenAI, Anthropic, and Google, that are available through Foundation Model APIs. For these partner models, Databricks generally follows the same deprecation timelines and policies as described for provisioned throughput and pay-per-token models.

However, retirement dates provided by partners might be shorter than the transition periods published by Databricks. In these cases, Databricks attempts to bridge the gap by temporarily redirecting models to a similar version, so customers receive the full transition time.

For example, if a pay-per-token model deprecation is announced with one month's lead time instead of three, Databricks redirects the model for an additional two months to prevent immediate breakage and allow time for migration. Queries fail at the end of the full three-month period.

Note

This redirection can only occur if the replacement model has the same price and is backwards compatible. The replacement model is usually an incremental model version, like 3.0 versus 3.1.

Foundation Model Fine-tuning

The following table summarizes the retirement policy for Foundation Model Fine-tuning.

Retirement notification	Transition to retirement	On the retirement date
Databricks takes the following steps to notify customers about a model that is set for retirement: In the Experiments tab, a warning message appears in the dropdown menu for Foundation Model Fine-tuning that indicates that the model is planned for retirement. The applicable documentation contains a notice that indicates the model is planned for retirement and the start date it will no longer be supported.	Databricks retires the model in three months. During this three-month period, customers can migrate existing workflows to use recommended replacement models.	The model is no longer available for use and removed from the product. Applicable documentation is updated to recommend using a replacement model.

Model updates

Databricks might ship incremental model updates to deliver optimizations. When a model is updated, the endpoint URL remains the same, but the model ID in the response object changes to reflect the date of the update. For example, if an update is shipped to meta-llama/Meta-Llama-3.3-70B on 3/4/2024, the model name in the response object updates to meta-llama/Meta-Llama-3.3-70B-030424. Databricks maintains a version history of the updates that you can refer to.

Retired models

The following sections summarize current and upcoming model retirements for the indicated feature offerings.

Foundation Model APIs pay-per-token retirements

The following table shows model retirements, their retirement dates, and recommended replacement models to use for Foundation Model APIs pay-per-token serving workloads. Databricks recommends that you migrate your applications to use replacement models before the indicated retirement date.

Partner model	Retirement date	Recommended replacement model
Anthropic Claude 3.7 Sonnet	April 12, 2026	Use the latest Claude Sonnet model

Open model	Retirement date	Recommended replacement model
Meta Llama 3.1 405B	February 15, 2026	OpenAI GPT OSS 120B
DBRX Instruct	April 30, 2025	Meta-Llama-4-Maverick
Mixtral-8x7B Instruct	April 30, 2025	Meta-Llama-4-Maverick
Meta-Llama-3.1-70B-Instruct	December 11, 2024	Meta-Llama-4-Maverick
Meta-Llama-3-70B-Instruct	July 23, 2024	Meta-Llama-4-Maverick
Meta-Llama-2-70B-Chat	October 30, 2024	Meta-Llama-4-Maverick
MPT 7B Instruct	August 30, 2024	Meta-Llama-4-Maverick
MPT 30B Instruct	August 30, 2024	Meta-Llama-4-Maverick

If you require long-term support for a specific model version, Databricks recommends using Foundation Model APIs provisioned throughput for your serving workloads.

Foundation Model APIs provisioned throughput retirements

The following table shows model family retirements, their retirement dates, and recommended replacement models to use for Foundation Model APIs provisioned throughput serving workloads. Databricks recommends that you migrate your applications to use replacement models before the indicated retirement date.

Partner model	Retirement date	Recommended replacement model
Gemini 3 Pro	March 26, 2026	Gemini 3.1 Pro. To allow more time for migration, between March 26, 2026 and June 7, 2026, API calls to Gemini 3 Pro will be temporarily redirected to Gemini 3.1 Pro. The pricing for both models is identical.

Open model family	Retirement date	Recommended replacement model
Meta Llama 3.1 405B	May 15, 2026	OpenAI GPT OSS 120B
Meta Llama 3 70B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Meta Llama 3 8B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Meta Llama 2 70B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Meta Llama 2 13B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Meta Llama 2 7B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Mixtral 8x7B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
Mistral 7B	February 27, 2026	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
DBRX	December 19, 2025	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
MPT 30B	December 19, 2025	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.
MPT 7B	December 19, 2025	Comparable model on the same offering, like Llama 3.2, 3.3, or 4 model of similar size.

Foundation Model Fine-tuning retirements

The following table shows retired model families, their retirement dates, and recommended replacement model families to use for Foundation Model Fine-tuning workloads. Databricks recommends that you migrate your applications to use replacement models before the indicated retirement date.

Model family	Retirement date	Recommended replacement model family
DBRX	April 30, 2025	Llama-3.1-70B
Mixtral	April 30, 2025	Llama-3.1-70B
Mistral	April 30, 2025	Llama-3.1-8B
Meta-Llama-3.1-405B	January 30, 2025	Llama-3.1-70B
Meta-Llama-3	January 7, 2025	Meta-Llama-3.1
Meta-Llama-2	January 7, 2025	Meta-Llama-3.1
Code Llama	January 7, 2025	Meta-Llama-3.1

Find workloads that use retired models

Use the following query to find workloads that are using deprecated models and identify their owners.

SELECT
   eu.requester,
   se.endpoint_name,
   se.entity_name,
   COUNT(*) AS request_count,
   SUM(eu.input_token_count) AS total_input_tokens,
   SUM(eu.output_token_count) AS total_output_tokens,
   MIN(eu.request_time) AS first_request,
   MAX(eu.request_time) AS last_request
 FROM system.serving.endpoint_usage eu
 JOIN system.serving.served_entities se
   ON eu.served_entity_id = se.served_entity_id
 WHERE LOWER(se.entity_name) LIKE '%claude-opus-4-1%'
 GROUP BY eu.requester, se.endpoint_name, se.entity_name
 ORDER BY request_count DESC