DeepSeek-V4-Pro-0813 est devenu généralement disponible le 12 août 2026, accessible via l'identifiant de modèle `deepseek-v4-pro` à `https://api.deepseek.com`, aux côtés du modèle moins cher `deepseek-v4-flash` (Unite.AI a couvert l'annonce de la disponibilité générale). Les spécifications principales sont solides : une fenêtre de contexte de 1M de tokens, une sortie maximale de 384K, l'appel d'outils, des sorties structurées et trois modes de pensée qui affichent la trace de raisonnement du modèle dans un champ `reasoning_content`.
La particularité ne réside pas dans les spécifications. C'est qu'un seul modèle répond dans trois dialectes d'API. V4 Pro accepte les requêtes OpenAI ChatCompletions, les requêtes Anthropic Messages et les requêtes vers l'API Responses propre à DeepSeek. Dirigez votre code SDK OpenAI existant vers celui-ci, dirigez un agent construit sur Claude vers celui-ci, ou intégrez-le dans une boucle d'agent de style Codex, mêmes poids, trois formats de communication.
Personne n'a encore présenté les trois formats d'API DeepSeek V4 Pro côte à côte, c'est pourquoi ce guide le fait. Vous verrez une requête fonctionnelle par format, où les structures diffèrent réellement, un tableau comparatif et comment tester les trois à partir d'un seul projet Apidog avec des variables d'environnement partagées. Si vous souhaitez la configuration du compte et la première démonstration d'appel, commencez par comment utiliser l'API DeepSeek V4 et revenez ensuite.
TL;DR
- DeepSeek-V4-Pro-0813 est en disponibilité générale via `deepseek-v4-pro` à `https://api.deepseek.com`; `deepseek-v4-flash` partage les mêmes interfaces à un prix inférieur.
- Il prend en charge trois formats d'API : OpenAI ChatCompletions (fonctionne avec le SDK `openai` standard en changeant `base_url`), Anthropic Messages (remplacement direct pour les requêtes de type SDK `anthropic`, y compris Claude Code), et l'API Responses de DeepSeek (sa nouvelle interface, conçue pour les agents de style Codex et les workflows avec état).
- Spécifications : 1M de contexte, 384K de sortie maximale, appel d'outils, sorties structurées, trois modes de pensée avec `reasoning_content`.
- Tarification : 0,435 $/M de tokens d'entrée (échec du cache), 0,003625 $/M en cas de succès du cache, 0,87 $/M de sortie.
- Les formats diffèrent par le placement de l'invite système, la sémantique de `max_tokens`, la forme du schéma d'outils et la forme de l'événement de streaming, détails ci-dessous.
- Un projet Apidog avec `{{DEEPSEEK_API_KEY}}` et des variables d'URL de base par format vous permet d'envoyer la même invite aux trois et de comparer les réponses brutes.
Pourquoi un modèle parle trois dialectes
Il s'agit d'un enjeu de compatibilité d'écosystème : chaque format d'API représente une base installée d'outils que DeepSeek obtient gratuitement. ChatCompletions est la lingua franca, des milliers de SDK et de frameworks peuvent appeler V4 Pro avec un simple changement de `base_url` en une ligne. Le format Anthropic Messages cible les équipes qui ont bâti sur Claude : les agents, les harnais d'évaluation et les outils comme Claude Code peuvent pointer vers V4 Pro sans réécriture. Et l'API Responses est le pari de DeepSeek sur les agents : `deepseek-v4-flash` l'a adoptée en juillet pour la compatibilité de style Codex, et V4 Pro la propose dès sa disponibilité générale pour les workflows avec état et multi-étapes.
V4 Pro est également listé sur des agrégateurs (voir la page OpenRouter pour deepseek-v4-pro-0813), mais l'histoire des trois formats s'applique à l'API propriétaire de DeepSeek, qui est ce que cet article teste. Pour un aperçu plus large de la famille V4, consultez comment utiliser DeepSeek V4.
Format 1 : OpenAI ChatCompletions
C'est la forme que vous connaissez déjà : un tableau `messages` où l'invite système est le premier message avec `role: "system"`, et une limite facultative de jetons maximum. La configuration est la même pour les trois formats, la voici donc une fois : votre clé API DeepSeek, l'URL de base de DeepSeek et le `model` défini sur `deepseek-v4-pro` (ou `deepseek-v4-flash`). Seuls le point de terminaison et la forme du corps changent.
Python, via le SDK `openai` standard :
from openai import OpenAI
client = OpenAI(
api_key="YOUR_DEEPSEEK_API_KEY",
base_url="https://api.deepseek.com",
)
response = client.chat.completions.create(
model="deepseek-v4-pro",
messages=[
{"role": "system", "content": "You are a precise technical writer."},
{"role": "user", "content": "Explain idempotency keys in two sentences."}
],
)
print(response.choices[0].message.content)
Pas de nouveau SDK, pas de nouveau schéma d'authentification. L'appel d'outils utilise la forme `function` imbriquée familière, et le streaming arrive sous forme de deltas `chat.completion.chunk` terminés par `data: [DONE]`, correspondant à la spécification OpenAI. Un comportement spécifique à V4 à prévoir : lorsqu'un mode de pensée est actif, la trace de raisonnement arrive dans un champ `reasoning_content` séparé à côté de `content`, les analyseurs doivent donc tolérer ce champ supplémentaire.
Quand l'utiliser : vous disposez d'outils OpenAI existants, de frameworks de type LangChain ou de bibliothèques internes qui gèrent déjà les ChatCompletions. C'est le chemin le plus simple et le plus facile à vérifier ; l'anatomie de la requête est identique à ce qui est couvert dans le test de l'API ChatGPT avec Apidog, seul l'hôte et le modèle étant échangés.
Format 2 : Anthropic Messages
Le format Messages semble similaire à première vue et diffère de manières qui rendent une traduction naïve difficile. Trois différences importent le plus, toutes héritées de la spécification Anthropic :
- L'invite système sort du tableau. C'est un paramètre `system` de niveau supérieur ; le tableau `messages` ne contient que des tours `user` et `assistant` alternés.
- `max_tokens` est requis, pas facultatif. Chaque requête déclare un budget de sortie explicite. Avec une sortie maximale de 384K pour V4 Pro, ce plafond est généreux, mais vous devez le spécifier.
- Les définitions d'outils sont plates. Chaque outil comporte `name`, `description` et un `input_schema` au niveau supérieur, sans enveloppe `function` imbriquée. Les appels d'outils reviennent sous forme de blocs de contenu `tool_use`, et vous renvoyez les résultats sous forme de blocs `tool_result` à l'intérieur d'un message utilisateur.
Python, requête Messages via le SDK `anthropic` :
import os
import anthropic
client = anthropic.Anthropic(
api_key=os.environ["DEEPSEEK_API_KEY"],
base_url="https://api.deepseek.com/anthropic", # Base compatible Anthropic ; confirmez le chemin actuel dans la documentation de DeepSeek
)
message = client.messages.create(
model="deepseek-v4-pro",
max_tokens=8192,
system="You are a precise technical writer.",
messages=[
{"role": "user", "content": "Explain idempotency keys in two sentences."}
],
)
print(message.content[0].text)
Les réponses sont renvoyées sous forme de liste de blocs de contenu plutôt que d'une seule chaîne, et le streaming utilise des événements SSE typés `message_start`, `content_block_delta`, `message_stop` au lieu de morceaux uniformes. L'authentification suit les conventions d'en-tête de la spécification Anthropic plutôt qu'un jeton bearer. La documentation de l'API DeepSeek contient les détails actuels de l'interface compatible.
Le bénéfice pratique, ce sont les agents. Parce que des outils comme Claude Code lisent leur point de terminaison à partir de variables d'environnement, vous pouvez diriger un agent construit sur Claude vers DeepSeek sans toucher à son code :
export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=$DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-v4-pro
Quand l'utiliser : vos outils ont été construits pour Claude. Si votre équipe envoie déjà des requêtes de type Messages aux modèles Anthropic (la même anatomie couverte dans notre guide de l'API Claude Opus 5), ce format vous permet de comparer DeepSeek et Claude dans le même environnement, avec les mêmes corps de requête et les mêmes gestionnaires de streaming.
Format 3 : API Responses de DeepSeek
L'API Responses est la nouvelle interface de DeepSeek, et la raison de son existence est les agents. V4 Flash l'a adoptée en juillet pour que les agents de style Codex puissent piloter les modèles DeepSeek ; V4 Pro l'a lancée dès le premier jour. La forme de la requête suit la spécification OpenAI Responses : vous envoyez un `input` (une chaîne de caractères ou une liste d'éléments typés) ainsi que des `instructions` de niveau supérieur, au lieu d'un seul tableau de messages.
Curl, requête API Responses :
curl https://api.deepseek.com/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-d '{
"model": "deepseek-v4-pro",
"instructions": "You are an API review agent. Be terse.",
"input": "Review this OpenAPI diff and list any breaking changes: [diff here]",
"stream": false
}'
Trois choses distinguent ce format des deux autres, toutes suivant la spécification Responses :
- L'état peut résider côté serveur. Au lieu de renvoyer toute la conversation à chaque tour, une requête de suivi peut référencer la réponse précédente par ID (`previous_response_id` dans la spécification), ce qui permet de maintenir des boucles d'agents multi-étapes peu coûteuses à orchestrer.
- La sortie est une liste d'éléments typés, et non un seul message : les éléments de raisonnement, les éléments de texte et les éléments d'appel d'outils arrivent sous forme d'entrées distinctes, ce qui convient aux agents qui agissent différemment sur chaque type d'élément.
- Le streaming est sémantique. Plutôt que des deltas de texte bruts, le flux émet des événements nommés (`response.output_text.delta`, `response.completed`, et autres), de sorte qu'un agent peut réagir aux changements de cycle de vie sans analyser les morceaux avec des expressions régulières.
L'appel d'outils existe aussi ici, avec des définitions d'outils et des éléments `function_call`/`function_call_output` conformes à la spécification Responses plutôt qu'à l'un des anciens formats. Lorsque les détails d'implémentation de DeepSeek vont au-delà de la spécification, considérez api-docs.deepseek.com comme la source de vérité.
Quand l'utiliser : intégrations de type agentique et Codex, workflows multi-étapes longs, ou tout système où un état de conversation géré côté serveur et des éléments de sortie typés simplifient votre code d'orchestration. Pour une simple complétion de chat, c'est plus de machinerie que nécessaire.
Les trois formats côte à côte
| OpenAI ChatCompletions | Anthropic Messages | API Responses de DeepSeek | |
|---|---|---|---|
| Point de terminaison | POST /chat/completions sur api.deepseek.com |
POST /v1/messages sur la base compatible Anthropic (/anthropic) |
POST /responses sur api.deepseek.com |
| Forme de la requête | Tableau messages unique, invite système comme premier message |
system de niveau supérieur + messages user/assistant alternés |
instructions de niveau supérieur + chaîne input ou liste d'éléments |
| Limite de sortie | Limite facultative de jetons maximum | max_tokens requis |
Limite facultative selon la spécification Responses |
| Définitions d'outils | Imbriquées : objet function avec parameters |
Plates : input_schema par outil |
Entrées plates selon la spécification Responses |
| Résultats d'outils | Messages role: "tool" |
Blocs de contenu tool_result |
Éléments function_call_output |
| Streaming | Deltas chat.completion.chunk uniformes, se termine par [DONE] |
Événements typés : message_start → content_block_delta → message_stop |
Événements de cycle de vie sémantiques (response.output_text.delta, …) |
| État de la conversation | Géré par le client (réexpédition de l'historique) | Géré par le client (réexpédition de l'historique) | Option côté serveur via la référence à la réponse précédente |
| Idéal pour | Outils et frameworks OpenAI existants | Outils et agents natifs Claude (Claude Code) | Boucles d'agents, workflows de style Codex et avec état |
Même modèle, même tarification, trois contrats. Les différences se situent entièrement au niveau du protocole, ce qui est précisément le type de différence le plus facile à vérifier empiriquement plutôt que de mémoire.
Tester les trois dans un seul projet Apidog
Observer la même invite produire trois réponses de formes différentes permet de saisir les détails d'implémentation qu'aucun tableau comparatif ne peut montrer. La configuration reproductible :
- Créez un projet, trois dossiers : `chat-completions`, `anthropic-messages`, `responses`, chacun contenant une requête enregistrée par scénario (complétion simple, appel d'outil, streaming).
- Partagez les identifiants via des variables d'environnement. Définissez `{{DEEPSEEK_API_KEY}}`, `{{BASE_URL}}` et `{{ANTHROPIC_BASE}}` une seule fois ; la rotation d'une clé ou le passage à `deepseek-v4-flash` devient une modification d'un seul champ.
- Envoyez l'invite identique via chaque format et comparez les corps bruts : `choices[0].message.content` versus une liste de blocs `content` versus des éléments de sortie typés.
- Inspectez les flux avec `stream: true`. La vue SSE intégrée rend les différences évidentes : des morceaux anonymes terminés par `[DONE]`, des événements Messages nommés, des événements de cycle de vie Responses. Si le débogage SSE est nouveau pour vous, comment diffuser des réponses API avec SSE couvre la mécanique.
- Ajoutez des assertions sur les champs que votre intégration lit réellement (chemin de contenu, emplacement de l'ID d'appel d'outil, raison de la fin) et réexécutez la collection chaque fois que DeepSeek publie une mise à jour instantanée.
Le projet à trois dossiers sert également de documentation vivante : « à quoi ressemble le schéma d'outil Messages déjà ? » devient une requête enregistrée avec une véritable réponse capturée.
Notes de migration
Le déplacement du code existant vers V4 Pro est délibérément ennuyeux, et c'est tout l'intérêt.
Depuis OpenAI : changez trois valeurs, `base_url` à `https://api.deepseek.com`, la clé API et le modèle à `deepseek-v4-pro`. Votre construction de message, vos définitions d'outils et vos gestionnaires de streaming restent. Deux vérifications avant de déployer : confirmez que tous les paramètres au-delà de la spécification de base se comportent comme prévu (exécutez-les via votre collection de tests plutôt que de supposer), et assurez-vous que votre analyse des réponses tolère l'apparition de `reasoning_content` à côté de `content`.
Depuis Anthropic : remplacez l'URL de base par le chemin compatible Anthropic, échangez la clé et définissez le modèle. Étant donné que la forme des Messages est conservée, les `max_tokens` requis, les blocs de contenu, les événements de flux typés, un client conforme aux spécifications n'a pas besoin de modifications logiques. Pour les agents qui lisent les variables d'environnement, la migration correspond aux trois lignes `export` montrées précédemment.
Vers l'API Responses : celle-ci est une réécriture de votre couche de requêtes plutôt qu'un changement de configuration, car aucun des anciens formats ne se traduit mécaniquement. Adoptez-la lorsque vous souhaitez ce qu'elle offre de manière unique, l'état côté serveur et les éléments de sortie typés, pas parce qu'elle est la plus récente.
Dans toutes les directions, le conseil est le même : migrez la configuration, puis réexécutez votre collection de régressions avant de lui faire confiance. À ces prix, un après-midi de trafic de vérification coûte moins cher que le café que vous buvez pendant.
FAQ
Quel format un nouveau projet devrait-il choisir ? Optez par défaut pour ChatCompletions pour le support d'outils le plus large. Choisissez Messages si votre stack est native Claude. Choisissez l'API Responses si vous construisez un agent multi-étapes et que vous souhaitez un état géré côté serveur.
Puis-je pointer Claude Code vers DeepSeek V4 Pro ? Oui. Définissez `ANTHROPIC_BASE_URL` sur le point de terminaison compatible Anthropic de DeepSeek, utilisez votre clé DeepSeek comme jeton d'authentification et définissez le modèle sur `deepseek-v4-pro`. C'est le bénéfice pratique du support du format Messages.
L'appel d'outils et les sorties structurées fonctionnent-ils dans tous les formats ? Le modèle prend en charge les deux, et chaque dialecte expose l'appel d'outils selon la forme de sa propre spécification : objets fonction imbriqués, outils `input_schema`, ou éléments de style Responses. Vérifiez vos schémas spécifiques par rapport à chaque interface dans une collection de tests avant de déployer ; les cas limites de la forme des schémas sont précisément là où les implémentations compatibles divergent.