Comment utiliser DeepSeek V4-Pro avec Cursor : Guide de configuration du Proxy de Raisonnement (2026)

Connectez DeepSeek V4-Pro à Cursor avec ses paramètres par défaut compatibles OpenAI et le premier appel d'outil renvoie une erreur 400. La raison est mineure mais tenace : V4-Pro est un modèle de réflexion qui renvoie un bloc reasoning_content, Cursor supprime ce champ de ses requêtes de suivi, et l'API de DeepSeek rejette les messages d'appel d'outil qui abandonnent la chaîne de raisonnement. Un proxy open-source à l'adresse yxlao/deepseek-cursor-proxy met en cache le contenu de raisonnement et le réinjecte dans les requêtes sortantes. Une fois le proxy en marche, V4-Pro se comporte comme n'importe quel autre modèle dans le panneau des modèles personnalisés de Cursor, avec les tokens de réflexion rendus sous forme de markdown escamotable. Vous trouverez ci-dessous la configuration complète, le calcul des coûts et la liste de dépannage.

TL;DR

• Cursor et DeepSeek V4-Pro renvoient par défaut des erreurs 400, car V4-Pro est un modèle de réflexion et Cursor supprime reasoning_content des messages d'appel d'outil.
• deepseek-cursor-proxy (open source, Python) s'intercale entre Cursor et DeepSeek, met en cache le contenu de raisonnement de chaque conversation et le réinjecte afin que les appels d'outil ne échouent pas.
• Configuration : installez via uv ou pip, exécutez deepseek-cursor-proxy, collez l'URL ngrok plus votre clé API DeepSeek dans les paramètres de modèle personnalisé de Cursor.
• V4-Pro dans Cursor coûte désormais environ 0,87 $ par million de tokens de sortie, soit environ 34 fois moins cher que GPT-5.5 en sortie. Voir DeepSeek V4-Pro : une réduction de prix de 75 % désormais permanente pour le contexte complet des prix.

Pourquoi avez-vous besoin d'un proxy en premier lieu

V4-Pro renvoie deux éléments dans chaque réponse : un champ content régulier et un champ reasoning_content qui contient la chaîne de pensée. Pour un chat ordinaire, vous pouvez ignorer reasoning_content. Le problème commence avec les appels d'outils.

Le contrat d'API de DeepSeek pour les modèles de réflexion exige que, lorsque vous poursuivez une conversation qui contenait un bloc reasoning_content, vous incluiez ce bloc dans la requête suivante, en plus du résultat des tool_calls. La chaîne de raisonnement fait partie de l'état de la conversation. Cursor n'est pas au courant de cette exigence. Il fournit un client de chat de style OpenAI, et reasoning_content ne fait pas partie du schéma OpenAI, il supprime donc ce champ. L'appel d'outil suivant revient avec un code HTTP 400 et un message concernant un reasoning_content manquant.

Ce n'est pas exactement un bug de Cursor. C'est un désaccord contractuel entre deux fournisseurs qui partagent la majeure partie de leur surface d'API. Tant que Cursor n'aura pas ajouté un support V4-Pro de première classe ou que DeepSeek n'aura pas assoupli le contrat, la solution consiste en un proxy qui se souvient de ce que Cursor a oublié.

Ce que le proxy fait, en trois lignes

• Écoute sur un port local (par défaut 9000) les requêtes de chat sortantes de Cursor.
• Met en cache reasoning_content de chaque réponse V4-Pro, indexé par le SHA-256 du préfixe de conversation canonique.
• À chaque nouvelle requête, recherche le reasoning_content mis en cache pour le préfixe correspondant et l'ajoute au message avant de le transmettre à DeepSeek.

Il expose également le port local via un tunnel ngrok, car le paramètre de modèle personnalisé de Cursor nécessite HTTPS et n'accepte pas une URL localhost.

Le cache se trouve dans ~/.deepseek-cursor-proxy/reasoning_content.sqlite3. L'indexation SHA-256 signifie que deux conversations parallèles n'entrent pas en collision. Le contenu de raisonnement est stocké exactement tel que DeepSeek l'a renvoyé, de sorte que le propre cache de prompts de DeepSeek fonctionne toujours, ce qui est important pour la nouvelle tarification permanente.

Prérequis

Vous avez besoin de quatre éléments avant de commencer :

• Cursor 2.0 ou plus récent. L'interface utilisateur du modèle personnalisé est la même dans la version 3.x ; les deux fonctionnent.
• Une clé API DeepSeek. Inscrivez-vous sur platform.deepseek.com si vous n'en avez pas. Un petit solde est suffisant ; les détails de la tarification sont ci-dessous.
• Python 3.11 ou plus récent. Le proxy est purement Python. uv est recommandé mais pip fonctionne.
• Un compte ngrok avec un authtoken. Le niveau gratuit est suffisant pour les développeurs individuels. Les domaines statiques sont facultatifs mais facilitent la vie si vous redémarrez souvent le proxy.

Si vous n'avez jamais installé uv, consultez la documentation officielle d'installation de uv. Pour ngrok, le guide de démarrage rapide d'ngrok vous guide à travers l'étape de l'authtoken.

Étape 1 : Installer le proxy

Le chemin le plus rapide est uv. Depuis n'importe quel répertoire :

uv tool install deepseek-cursor-proxy

Si vous préférez pip, clonez le dépôt et installez-le en tant que package éditable :

git clone https://github.com/yxlao/deepseek-cursor-proxy.git
cd deepseek-cursor-proxy
pip install -e .

L'une ou l'autre méthode place une commande deepseek-cursor-proxy sur votre PATH. Vérifiez avec deepseek-cursor-proxy --help.

Étape 2 : Configurer ngrok

Le proxy a besoin d'une URL HTTPS publique car le champ de modèle personnalisé de Cursor n'acceptera pas http://localhost. ngrok fournit le tunnel.

ngrok config add-authtoken YOUR_NGROK_AUTHTOKEN

Récupérez votre authtoken depuis le tableau de bord ngrok après votre inscription. Le niveau gratuit vous donne un sous-domaine aléatoire à chaque redémarrage. Si cela pose problème, réservez un domaine dans le tableau de bord et passez-le au proxy avec --ngrok-url https://your-reserved.ngrok-free.app.

Étape 3 : Démarrer le proxy

Les paramètres par défaut conviennent à la plupart des configurations :

deepseek-cursor-proxy

Lors de la première exécution, le proxy crée ~/.deepseek-cursor-proxy/config.yaml, ouvre un tunnel et affiche l'URL publique. La sortie ressemble à ceci :

Démarrage de deepseek-cursor-proxy
Tunnel : https://random-name.ngrok-free.app
Local :  http://127.0.0.1:9000
Cache :  /Users/vous/.deepseek-cursor-proxy/reasoning_content.sqlite3

Options utiles :

• --port 9000 : change le port local si 9000 est déjà utilisé.
• --verbose : affiche les corps des requêtes et des réponses. Utilisez ceci lors du débogage de l'intégration de Cursor.
• --no-ngrok : ignore le tunnel. Utile lors des tests depuis un outil qui accepte http://localhost.
• --no-display-reasoning : supprime les blocs de réflexion escamotables de la vue de Cursor. Le raisonnement continue de passer ; seul le rendu est supprimé.

Gardez le proxy en cours d'exécution dans un terminal séparé, ou enveloppez-le dans un travail launchctl sur macOS. Cursor communique avec lui à chaque requête.

Étape 4 : Configurer Cursor

Ouvrez les paramètres de Cursor, naviguez vers Modèles, et ajoutez un modèle personnalisé. Les champs dont vous avez besoin :

• Nom du modèle : deepseek-v4-pro. Le proxy transmet cette chaîne directement à DeepSeek, elle doit donc correspondre à un identifiant de modèle DeepSeek réel. Utilisez deepseek-v4-flash pour la variante moins chère.
• URL de base : l'URL ngrok affichée par le proxy, plus /v1. Exemple : https://random-name.ngrok-free.app/v1.
• Clé API : votre clé API DeepSeek (commence par sk-). Le proxy n'a pas sa propre couche d'authentification ; il transmet la clé telle quelle.

Cursor exécute une vérification « Vérifier le modèle ». La vérification envoie une seule complétion de chat. Une coche verte signifie que vous avez terminé. Une erreur de connexion pointe généralement vers l'URL ngrok : copiez-la à nouveau depuis la sortie du proxy et confirmez qu'elle se termine par /v1.

Étape 5 : Choisir le modèle et essayer un appel d'outil

Ouvrez le sélecteur de modèle dans le panneau de chat et sélectionnez votre nouveau modèle personnalisé. La première instruction à essayer est celle qui force l'utilisation d'outils, car les appels d'outils sont la source des erreurs 400 d'origine :

« Ouvrez le fichier README de ce dépôt, listez chaque bloc de code et dites-moi lesquels n'ont pas d'indications de langage. »

Cursor émettra un appel d'outil read_file. Si le proxy fait son travail, la chaîne de réponse ressemble à ceci :

1. Cursor envoie le message utilisateur au proxy.
2. Le proxy transmet à DeepSeek sans reasoning_content (c'est le premier tour).
3. DeepSeek renvoie du texte plus un bloc reasoning_content plus une requête tool_calls.
4. Le proxy met en cache le reasoning_content indexé par le hachage du préfixe de conversation.
5. Cursor exécute l'outil, puis envoie un suivi avec le résultat de l'outil. Le suivi n'a pas de reasoning_content car Cursor l'a supprimé.
6. Le proxy recherche le reasoning_content mis en cache par hachage de préfixe et le réinjecte avant de le transmettre.
7. DeepSeek accepte la requête, poursuit le raisonnement et renvoie la réponse finale.

Exécutez avec --verbose et vous verrez l'injection se produire dans les logs.

À quoi ressemble le coût en pratique

V4-Pro dans Cursor paie les tarifs API standards de DeepSeek, et non les tarifs de crédit groupés de Cursor. Ces tarifs sont permanents à partir de mai 2026 :

Une journée intense avec Cursor ressemble à environ 50 tours de chat plus 20 chaînes d'appels d'outils. Chaque tour fait en moyenne environ 8 000 jetons d'invite (contexte de fichier plus invite système plus historique) et 1 500 jetons de sortie. Ce qui fait :

• 50 tours × 8 000 jetons d'entrée × 0,435 $ / 1 000 000 = 1,74 $ au pire des cas
• Avec des succès de cache sur un préfixe système et contexte de 6 000 jetons à 60 % : environ 0,85 $
• 50 × 1 500 × 0,87 $ / 1 000 000 = 0,065 $ de sortie

Total : environ 1 $ par jour intense. Comparé à l'exécution de la même charge de travail via le quota GPT-5.5 inclus dans Cursor Pro, c'est un ordre de grandeur moins cher avant que la limitation de quota ne se déclenche. Le calcul complet de la réduction de prix se trouve dans DeepSeek V4-Pro : une réduction de prix de 75 % désormais permanente.

Pour en savoir plus sur les autres modèles DeepSeek, consultez Qu'est-ce que DeepSeek V4 et Comment utiliser l'API DeepSeek V4.

Comment V4-Pro se comporte dans Cursor

Trois différences apparaissent par rapport à votre modèle Cursor par défaut.

1. Les tokens de réflexion sont visibles. Par défaut, le proxy rend le raisonnement de DeepSeek sous forme de bloc markdown escamotable au-dessus de chaque réponse. Le panneau de chat de Cursor l'affiche comme un élément <details>. Utile pour déboguer les invites ; bruyant pour le travail de routine. Activez/désactivez avec --no-display-reasoning.

2. La latence du premier appel d'outil est plus élevée. V4-Pro est un modèle de réflexion, et la chaîne s'exécute avant tout appel d'outil. Attendez-vous à 2 à 4 secondes avant que le premier outil ne se déclenche, puis un débit standard pour les suivis.

3. Les suggestions « Appliquer » de Cursor s'améliorent sur les refactorisations complexes. C'est le point clé. La chaîne de raisonnement de V4-Pro détecte les dépendances multi-fichiers que les modèles de complétion simples ne voient pas. Les renommages, les changements de signature et les refactorisations basées sur la configuration qui nécessitaient auparavant trois cycles avec GPT-5.5 sont souvent réalisés en une seule passe avec V4-Pro.

D'autres tutoriels DeepSeek-avec-Cursor existent pour les modèles prédécesseurs. Consultez Comment utiliser DeepSeek R1 localement avec Cursor et DeepSeek V3 avec Cursor : étape par étape pour les anciens schémas. Le proxy dans ce guide remplace les astuces manuelles d'injection de raisonnement documentées dans ces articles.

Tester votre configuration DeepSeek avec Apidog

L'intégration de Cursor ne prouve que le chemin depuis l'intérieur de Cursor. Si vous déployez V4-Pro sur d'autres surfaces (un bot CI, un agent backend, un plugin IDE personnalisé), vous souhaitez un harnais de test déterministe contre le même point de terminaison vers lequel votre proxy transmet.

C'est là qu'Apidog prend toute sa place. Pointez un environnement Apidog vers https://api.deepseek.com/v1, insérez votre clé API et importez le schéma de complétion de chat OpenAI. Vous pouvez :

• Enregistrer des réponses de référence de V4-Pro et les rejouer à chaque changement d'invite pour détecter les dérives.
• Valider les formes de tool_calls avec des assertions de schéma JSON afin qu'une mauvaise édition d'invite système ne casse pas silencieusement votre agent de production.
• Comparer V4-Pro et GPT-5.5 côte à côte sur le même lot d'entrée en utilisant les scénarios de test d'Apidog.

Téléchargez Apidog, importez la spécification OpenAPI de DeepSeek, et vous disposerez d'un banc de test V4-Pro fonctionnel en cinq minutes. Le même flux de travail que nous décrivons dans Comment utiliser l'API DeepSeek V4.

Pièges courants

• Erreurs 400 après le premier appel d'outil. Le mode de défaillance classique que ce proxy a été conçu pour corriger. Si vous le voyez toujours après la configuration, le proxy ne fonctionne pas ou Cursor pointe vers la mauvaise URL de base. Vérifiez à nouveau que l'URL se termine par /v1 et que le journal du proxy affiche les requêtes entrantes.
• Le tunnel ngrok ne cesse de se reconnecter. Les tunnels du niveau gratuit tournent au redémarrage. Si la vérification de Cursor réussit mais échoue quelques minutes plus tard, votre tunnel a changé. Passez à un domaine réservé (en un clic dans le tableau de bord ngrok) et transmettez-le avec --ngrok-url.
• Le contenu de raisonnement apparaît en double. Cela se produit lorsque deux instances de proxy s'exécutent avec le même chemin de cache SQLite. Arrêtez les deux, supprimez ~/.deepseek-cursor-proxy/reasoning_content.sqlite3 et démarrez une seule instance.
• Le taux de succès du cache semble faible. Le cache de prompts de DeepSeek nécessite des préfixes identiques au byte près. Cursor injecte des horodatages et des identifiants de session dans certaines invites système, ce qui annule les succès du cache. La solution n'est pas dans le proxy ; soit vous acceptez le coût, soit vous utilisez le mode « sans-invite-système » de Cursor pour les sessions V4-Pro.
• Cursor signale « modèle introuvable ». Le nom du modèle dans les paramètres de Cursor doit correspondre à un modèle DeepSeek réel. Les valeurs valides aujourd'hui sont deepseek-v4-pro, deepseek-v4-flash, deepseek-v3-2-pro et deepseek-r1-1. Le proxy ne traduit pas les noms ; il les transmet.

Alternatives si le proxy ne vous convient pas

Le proxy est la voie la plus propre aujourd'hui, mais deux alternatives existent :

• V4-Flash sans le proxy. V4-Flash n'est pas un modèle de réflexion et ne renvoie pas reasoning_content. Cursor lui parle directement sans solution de contournement. Vous renoncez à l'amélioration de la chaîne de pensée mais gardez l'intégration simple. La tarification est de 0,14 $ / 0,28 $ par million de tokens.
• Cline, Continue, ou d'autres plugins IDE AI avec support natif des modèles de pensée. Ces outils gèrent reasoning_content sur les messages d'appel d'outil de manière native. Si vous n'êtes pas spécifiquement lié à Cursor, changer d'éditeur est parfois plus facile que d'exécuter le proxy. Voir Meilleurs assistants de codage open source en 2026 : alternatives gratuites à Cursor pour le domaine.

Autres intégrations de modèles Cursor couvertes en détail : Claude Opus 4.6 avec Cursor, Kimi K2.5 avec Cursor, et Gemini 3.0 Pro avec Cursor.

FAQ

• Pourquoi Cursor ne prend-il pas en charge DeepSeek V4-Pro nativement ? Le client de chat de Cursor suit le schéma OpenAI Chat Completions. reasoning_content ne fait pas partie de ce schéma ; c'est une extension spécifique à DeepSeek qui est apparue avec la famille R1 et est restée dans V4-Pro. Cursor devrait ajouter une gestion spécifique au fournisseur pour transmettre le champ. Ils le feront peut-être ; en attendant, le proxy est la solution de contournement.
• Le proxy fonctionne-t-il avec DeepSeek R1 ou V3.2 ? Oui. Tout modèle de réflexion DeepSeek qui renvoie reasoning_content et le requiert lors des suivis d'appels d'outils est pris en charge. Définissez le nom du modèle dans les paramètres de Cursor sur l'identifiant réel du modèle DeepSeek.
• Le proxy peut-il être laissé en marche en toute sécurité ? Oui, avec une mise en garde : le cache SQLite contient le contenu de raisonnement brut de vos sessions. Si vous utilisez des configurations multi-utilisateurs ou partagez des machines, restreignez les permissions du répertoire du cache ou exécutez avec --no-cache (en mémoire uniquement, ce qui signifie que les appels d'outils échouent après un redémarrage du proxy).
• Puis-je utiliser le proxy sans ngrok ? Oui, avec --no-ngrok. Le proxy expose alors uniquement http://127.0.0.1:9000. L'interface utilisateur du modèle personnalisé de Cursor rejette les URL http:// dans les versions standard, mais certaines versions chargées en sideload et les configurations patchées acceptent localhost. La plupart des utilisateurs voudront ngrok ou un équivalent (Cloudflare Tunnel, Tailscale Funnel).
• Est-ce que cela fonctionne avec Cursor Composer 2.5 ? Composer utilise le même pipeline de routage de modèles que le panneau de chat, donc oui. Le premier appel d'outil au sein d'un agent Composer déclenchera la même exigence de reasoning_content et le proxy le corrigera de la même manière.
• Quel est le surcoût de latence du proxy ? Négligeable. Le proxy ajoute un saut de réseau local, une recherche SQLite et quelques Ko de manipulation JSON par requête. Le surcoût mesuré est de 5 à 15 ms par appel. ngrok ajoute 30 à 80 ms selon le point de bord le plus proche. Le proxy n'est pas le goulot d'étranglement.
• Comment le proxy décide-t-il quoi mettre en cache ? Il hache le préfixe de la conversation (tout ce qui précède le dernier message de l'utilisateur ou de l'outil), associe le SHA-256 de ce hachage au reasoning_content de la dernière réponse de DeepSeek, et stocke les deux dans SQLite. Lors de la requête suivante, il calcule le hachage du nouveau préfixe et recherche l'entrée correspondante. C'est une approche conservatrice. Les correspondances de préfixe partielles ne déclenchent pas de succès de cache, de sorte que deux conversations presque identiques ne se polluent pas mutuellement.
• Anthropic, OpenAI ou Cursor vont-ils casser cela ? Anthropic et OpenAI ne sont pas impliqués. Cursor pourrait soit ajouter un support natif des modèles de pensée (auquel cas le proxy deviendrait inutile) soit modifier le format des requêtes d'une manière qui casserait le proxy. Le dépôt est maintenu ; surveillez ses problèmes pour les mises à jour de compatibilité.

Où cela vous mène

La capacité de codage de V4-Pro se situe à quelques points de référence de GPT-5.5 (comparaison DataCamp) pour environ 1/34e du prix de sortie. Le seul obstacle pour les utilisateurs de Cursor était une incompatibilité de contrat d'API concernant reasoning_content. Le dépôt deepseek-cursor-proxy résout cela en moins d'une centaine de lignes de code significatif et une configuration de cinq minutes.

Trois prochaines étapes concrètes :

• Installez le proxy et exécutez un test côte à côte par rapport à votre modèle Cursor par défaut actuel sur cinq vraies pull requests de votre dépôt.
• Vérifiez votre invite système Cursor pour le contenu variable (horodatages, identifiants de session) qui annule les succès du cache. Déplacez ce contenu dans le message utilisateur.
• Connectez une suite de régression Apidog contre api.deepseek.com afin de pouvoir détecter les dérives de contrat sans avoir à retester via Cursor à chaque fois.

La taxe sur les tokens de réflexion est payée. Le prix ne l'est pas.