This article provides information about the sunset of DeepL's Classic language model as well as troubleshooting steps per issue you might encounter. Click to expand each issue.
Reasons for the sunset
What is happening?
DeepL is upgrading the model that serves API requests using the LATENCY_OPTIMIZED model.
Since November 2024, API calls allow users to select one of two model types: QUALITY_OPTIMIZED and LATENCY_OPTIMIZED.
The Next-gen model serving QUALITY_OPTIMIZED requests was upgraded in April 2025, November 2025, Mar 2026, and has another planned upgrade in June 2026. The Classic language model serving LATENCY_OPTIMIZED is more than two years old. It is being upgraded to a low-latency variant of Next-gen.
| If you requested… | In Q1 2026, your request was served by… | In Q3 2026, your request will be served by… |
| QUALITY_OPTIMIZED | The latest Next-Gen model | The latest Next-Gen model |
| LATENCY_OPTIMIZED (or no explicit model selection) |
The Classic model (more than 2 years old) |
The exact same Next-Gen model as QUALITY_OPTIMIZED, but deployed in a low-latency mode. |
Why are you making this change?
The translation quality of the Classic model continues to fall behind the Next-gen model as it was decided to stop investing engineering support into the older model.
In April, DeepL ran human blind tests to compare DeepL Next-gen and DeepL Classic against Google Translate, MS Translate, and OpenAI, Anthropic, and Google Gemini. LLMs were used on their slowest, most expensive settings. DeepL's Next-gen language model came out as winner in head-to-head match ups against all of these competitors. DeepL Classic loses to all but one of them.
Features that are released after 2024 are also often not supported for the Classic model including new languages or updates to DeepL's customization hub.
Changes for QUALITY_OPTIMIZED and LATENCY_OPTIMIUED
Do I need to change my code?
No. You don’t need to change your code. Every request that succeeded before the upgrade will still succeed after the upgrade. LATENCY_OPTIMIZED requests will be translated by a new model, with improved output.
Do I need to remove my use of the LATENCY_OPTIMIZED parameter?
No. You don’t need to change your code. Model types will still exist. Users can still select a faster reply or better quality. LATENCY_OPTIMIZED requests will be translated by a new model with improved output.
Do I need to upgrade to API v3?
No. You don’t need to change your code. v2 is still live. LATENCY_OPTIMIZED requests for v2 will be translated by a new model with improved output.
What if my code doesn’t explicitly specify a model at all?
Right now requests without an explicit model parameter are defaulted to LATENCY_OPTIMIZED. If you do nothing, you should see a slight jump in quality.
I used to select the Classic model as an API parameter. How can I keep using it?
You selected LATENCY_OPTIMIZED, not Classic. Historically, LATENCY_OPTIMIZED was served by Classic, but that was never guaranteed. Our latency-optimized Next-gen will meet our users’ goal of faster responses. Learn more in DeepL's API documentation.
What about PREFER_QUALITY_OPTIMIZED?
PREFER_QUALITY_OPTIMIZED was relevant in the months between Nov 2024 — when the first-version of our Next-gen model was released for a limited number of languages — and April 2025 — when our Next-gen model supported all the languages covered by the Classic model. It allowed users to fall back if their languages weren’t yet supported.
Next-gen reached parity with Classic in April 2025 and PREFER_QUALITY_OPTIMIZED became functionally equivalent to QUALITY_OPTIMIZED.
Further questions
What if I’m using the CAT API?
You don’t need to change your code. CAT API requests will be translated by a new model with improved output.
Why wasn’t I notified of this API change?
Because this is an upgrade, not a deprecation. The new model has a similar latency profile and a quality increase, as measured by blind tests.
DeepL reserves the right to quietly change which model serves e.g. a model_type=quality_optimized request, as long as we think it is a net benefit to the user (e.g. no significant latency increase, but a quality increase, or a significant latency reduction with no or only very slight decrease in quality).
But what was this 30 June email about then?
The API allows users to choose a goal, not a model. Both of those choices will be preserved. The website, on the other hand, did let users explicitly choose a model. That choice is going away. On 30 June, the “Powered by” dropdown on web and apps will disappear. All web users will use the same model as the one used for QUALITY_OPTIMIZED API requests.
When will the APIs switch?
APIs are being upgraded via a phased rollout between 27 May and 15 June. We cannot provide a specific date for a specific customer.