Cursor Models : accès et choix après les changements d’octobre

Informations vérifiées le 25 octobre 2026 dans la documentation en ligne de Cursor sur les modèles, les abonnements, Router et les sous-agents. La distinction essentielle : avoir accès à un modèle ne signifie pas que son utilisation est comprise dans l’abonnement.

Cursor Models : quels modèles sont disponibles aujourd’hui ?

Cursor propose ses propres modèles Grok et Composer ainsi que Claude, GPT et Gemini, mais l’accès dépend de votre abonnement. Avec The X Subscription, le système d’abonnement actuel, les comptes payants disposent d’un quota hebdomadaire pour les modèles Cursor, partagé avec Grok. Les requêtes adressées aux modèles tiers consomment du crédit prépayé. La documentation actuelle des modèles Cursor précise cette répartition.

Le tableau distingue les abonnements actuels des anciennes offres. « Inclus » signifie que l’utilisation est décomptée d’un quota, sans accès illimité. L’offre Free est limitée ; les quotas payants dépendent du compte.

Sources : modèles disponibles, abonnements actuels et anciennes offres. Teams et Enterprise paient également le Cursor Token Rate sur les requêtes tierces concernées ; la liste des exclusions mérite donc attention. Les comptes individuels ne paient pas ce supplément.

Les tarifs mensuels individuels hors taxes sont de $0 pour Free, $8 pour Plus, $30 pour Premium, $100 pour Super et $200 pour Ultra, selon les prix publiés par Cursor. Notre guide des tarifs Cursor détaille les quotas, les licences d’équipe et les anciennes offres.

Cursor gratuit et Plus : quels modèles et quelles limites ?

Free permet d’essayer les modèles maison ; Plus offre un environnement de programmation limité à ces mêmes modèles. Avec Plus, Fast reste désactivé et l’effort de raisonnement est fixé au niveau moyen. Grok 4.7 y utilise une fenêtre de contexte de 256k. Auto, les modèles tiers et l’utilisation de vos propres clés API sont exclus. Ces limites sont explicitement prévues par l’abonnement : l’absence de Claude ne signale donc pas forcément un problème d’installation.

Pour un développeur qui effectue de petites modifications avec Composer, cela peut suffire. Si votre workflow dépend précisément de Claude ou de GPT, Plus ne répond pas au besoin, avant même de comparer la qualité des résultats. Déterminez les modèles auxquels vous devez accéder avant de vous abonner.

Cursor Premium et anciennes offres : une facturation différente

Premium et les offres supérieures donnent accès aux modèles tiers, mais le nouvel abonnement ne comprend aucun quota pour leur utilisation. La situation est différente avec un compte Pro, Pro+ ou un ancien Ultra : son quota mensuel Other Models couvre toujours les modèles tiers au tarif public de leur API. Une fois ce quota épuisé, l’utilisation à la demande, si elle est activée, permet de continuer moyennant facturation. La documentation des anciennes offres Cursor explique cette différence.

Imaginez un abonnement de restaurant : le nouveau compte comprend le menu maison, tandis que les plats des chefs invités sont facturés à part. Un ancien compte dispose aussi d’une enveloppe pour ces plats. Un même modèle peut donc apparaître sur les deux comptes tout en étant décompté de soldes différents.

Si vous conservez un ancien abonnement, examinez votre consommation réelle de modèles tiers avant de migrer. Cursor précise que le passage au nouvel abonnement est facultatif et définitif. Un quota plus généreux pour les modèles maison ne remplace pas un crédit Claude inclus si Claude reste votre modèle principal.

Quel modèle Cursor choisir selon la difficulté du travail ?

Partez du problème rencontré : des échanges trop lents, des tâches longues qui restent inachevées ou le besoin d’un comportement propre à un modèle. Dans ses conseils de sélection, Cursor recommande Composer pour la programmation interactive, Grok 4.7 pour les tâches les plus difficiles et prolongées, et Claude Opus ou GPT-5.6 Sol pour les travaux complexes en plusieurs étapes. Les exemples ci-dessous appliquent ces recommandations au développement quotidien.

Composer 2.5 : le point de départ lorsque vous guidez les modifications au fil des échanges. Cursor le présente comme optimisé pour l’utilisation d’outils, la modification de fichiers et les opérations dans le terminal. Sa fiche modèle indique une fenêtre de contexte de 200k, une variante rapide pour les sessions interactives et une variante standard qui privilégie un coût inférieur par token.

Modifier un composant à partir d’un test dont l’échec est clairement identifié constitue un bon premier cas d’usage. Demandez le changement minimal, examinez le diff et poursuivez les échanges. Arrêtez lorsque les corrections s’accumulent sans résoudre le problème de fond. Précisez alors la demande ou passez à un modèle plus capable, au lieu de prolonger indéfiniment une conversation improductive. Vérifiez le réglage de vitesse avant de considérer que « Composer » correspond à un profil de consommation unique.

Grok 4.7 : pour les tâches qui exigent une investigation et des vérifications prolongées. Selon Cursor, il améliore l’autovérification et le travail de longue durée par rapport à Grok 4.6. Une modification de l’authentification répartie sur plusieurs fichiers illustre bien l’intérêt de cette persévérance : l’agent doit relier le traitement des requêtes, la logique de session, les tests et les cas d’échec. Définissez ces vérifications avant de lui confier la tâche.

La fiche de Grok 4.7 distingue un contexte standard de 256k d’un maximum de 500k. L’unité est le token, un fragment de texte ou de code traité par le modèle. Le contexte détermine la quantité de contenu qu’un modèle peut prendre en compte dans une requête ; sa capacité ne garantit pas qu’il repérera la dépendance pertinente. Fournissez le comportement défaillant et les critères d’acceptation, pas seulement davantage de fichiers.

Grok 4.6 et Grok 4.5 : à conserver si un workflow existant justifie leur place. Cursor référence toujours les deux, mais sa page consacrée à Grok 4.6 recommande 4.7 pour une meilleure autovérification et les travaux plus longs. La familiarité seule justifie mal de choisir une ancienne version par défaut pour une nouvelle tâche difficile. À l’inverse, rien ne presse de bouleverser un workflow qui fonctionne sans évaluer son remplaçant. Le comparatif Grok 4.7 et Grok 4.6 aide à décider de cette migration.

Claude Opus et GPT-5.6 Sol : un choix délibéré pour les travaux complexes ou pour essayer une autre approche. Leur intérêt apparaît lorsqu’un problème gagne à être interprété par un autre modèle. Gardez la même tâche et les mêmes tests d’acceptation en changeant de modèle. Vous pourrez ainsi juger le résultat, sans favoriser une explication simplement plus convaincante.

La page de GPT-5.6 Sol chez Cursor décrit un agent persévérant et des réponses concises pour la planification et le débogage. Elle signale aussi un recours excessif aux sous-agents et, parfois, l’attente d’une consigne explicite pour passer à l’exécution. Si le modèle propose la bonne correction puis s’arrête, demandez-lui clairement de la mettre en œuvre. Un plan bien présenté ne suffit pas à terminer un ticket.

Gemini : à évaluer lorsque vous avez déjà une raison de le préférer. Les recommandations générales de Cursor mentionnent la préférence de certains utilisateurs pour Gemini Pro. Elles n’affirment pas pour autant que Gemini domine une catégorie particulière de programmation. Le catalogue actuel comprend Gemini 4 Argon, Gemini 3.1 Pro et Gemini 3.8 Flash, ainsi que des modèles Claude plus récents comme Opus 5.5 et Sonnet 5.5. Consultez le catalogue des modèles directement sélectionnables : cette liste est distincte de celle utilisée par Auto pour le routage.

En pratique, prenez Composer pour les travaux que vous pouvez relire en continu, Grok 4.7 lorsque la difficulté tient à la longueur de l’investigation, et un modèle tiers autorisé lorsque ses résultats justifient une consommation facturée à part. Dans tous les cas, la validation doit reposer sur la revue humaine et les vérifications du dépôt.

Cursor Auto : comprendre Cost, Balance et Intelligence

Auto est un mécanisme de sélection, pas un modèle supplémentaire. Le nouveau Cursor Router nécessite actuellement Teams ou Enterprise. La documentation de Router réserve Balance et Intelligence à ce système. Plus exclut explicitement Auto. Ne supposez donc pas que tous les comptes disposent du même menu Auto.

La définition de ces modes et leurs règles de facturation proviennent de la documentation de Cursor Router. Cursor présente Balance comme le mode par défaut des nouveaux utilisateurs ; les administrateurs d’équipe contrôlent les modes proposés. La colonne « Usage conseillé » en donne une interprétation pratique : commencez un ticket courant avec le réglage habituel, puis montez en gamme si la tâche le justifie, plutôt que par simple curiosité.

La liste actuellement documentée des modèles de Router comprend GPT-5.5, Claude Opus 5, Grok 4.6 et Claude Fable 5. Cursor prévient qu’elle évolue et qu’un modèle peut devenir directement sélectionnable avant d’être intégré au routage. La présence de Grok 4.7 et de GPT-5.6 Sol dans le sélecteur ne prouve donc pas qu’Auto les utilise. Référez-vous à la liste publiée.

Pour un responsable d’équipe, la politique de routage comporte aussi des dépendances. Bloquer Grok 4.6 désactive Router ; bloquer à la fois GPT-5.5 et Claude Opus 5 le désactive également. Selon Cursor, n’en bloquer qu’un parmi ces deux derniers dégrade la qualité du routage. Examinez la liste des modèles autorisés comme une configuration dont dépend le fonctionnement du routage, et pas seulement comme une liste de fournisseurs préférés.

Les administrateurs Enterprise doivent activer Router, et les contrôles d’équipe peuvent limiter les modes ou imposer Auto. Les réglages d’administration expliquent pourquoi un développeur peut ne pas pouvoir modifier une option pourtant visible sur un autre compte. Une requête routée vers un modèle tiers reste soumise à la facturation des modèles tiers ; sélectionner Auto ne la fait pas entrer dans le quota inclus des modèles maison.

Comment changer de modèle sans perdre le fil de ses réglages ?

Changez de modèle dans le panneau de chat ou d’agent, puis vérifiez ses réglages avant d’envoyer la tâche suivante. Cursor précise que la sélection persiste d’une conversation à l’autre. C’est pratique, jusqu’à ce qu’un choix coûteux ou spécialisé fait la veille devienne discrètement votre réglage par défaut. Les instructions pour changer de modèle constituent le même point de départ, que vous choisissiez un modèle précis ou Auto.

Plusieurs modèles dans Cursor : comment les sous-agents choisissent-ils ?

Le modèle sélectionné pour l’agent principal ne détermine pas celui de tous les sous-agents. Un sous-agent est un agent distinct auquel une partie du travail est déléguée. Les sous-agents intégrés à Cursor choisissent un modèle adapté à leur sous-tâche. Les sous-agents personnalisés utilisent par défaut inherit, qui reprend le modèle de l’agent principal, ou peuvent préciser un identifiant de modèle. L’agent principal peut également désigner un modèle au lancement d’un sous-agent. La documentation des sous-agents Cursor décrit ces possibilités.

Voici un exemple de configuration personnalisée à placer dans .cursor/agents/local-review.md :

---
name: local-review
description: Reviews a bounded code change for correctness.
model: "composer-2.5[fast=false]"
---
Review the supplied diff and relevant tests.
Report concrete defects with file references. Do not edit files.

Ce réglage sélectionne explicitement Composer 2.5 à vitesse standard. Utilisez plutôt model: inherit si vous souhaitez que le sous-agent reprenne le modèle de l’agent principal. La syntaxe provient de la documentation de configuration de Cursor.

La conséquence sur la facturation passe facilement inaperçue. Un agent principal utilisant Grok, Composer ou Auto peut déléguer une tâche à un modèle tiers précis. Ce sous-agent consomme alors du crédit prépayé avec le nouvel abonnement, ou le quota Other Models avec une ancienne offre. Sa fiche de tâche affiche le modèle utilisé, que l’on retrouve dans le tableau de bord de consommation. Les restrictions de l’abonnement et les blocages administrateur peuvent empêcher l’utilisation d’un modèle pourtant indiqué dans la configuration.

Si une équipe examine une facture inattendue, ces relevés de sous-agents sont le premier endroit à regarder. Le seul affichage d’un modèle maison dans le chat principal ne suffit pas à conclure que le quota a été mal décompté. Chaque sous-agent possède son propre contexte et sa propre consommation de tokens. La délégation doit donc avoir une utilité : mener une investigation indépendante, effectuer une revue distincte ou traiter un travail qui bénéficie d’un contexte séparé.

Utiliser sa propre clé API dans Cursor

Votre clé API change qui facture l’inférence compatible ; elle ne supprime ni les restrictions d’abonnement, ni celles des fonctionnalités ou des fournisseurs. Plus exclut le BYOK, pour « bring your own key », c’est-à-dire l’utilisation de votre propre clé. La documentation des clés API de Cursor prévoit la prise en charge des modèles de chat standard d’OpenAI sans raisonnement, d’Anthropic Claude, de Google Gemini, d’Azure OpenAI et d’AWS Bedrock, dans les configurations compatibles de chaque fournisseur.

Pour connecter une clé, ouvrez Cursor Settings > Models, choisissez le fournisseur, saisissez la clé et enregistrez. Avec les abonnements individuels compatibles, le fournisseur facture directement ces requêtes : elles ne consomment ni le quota de modèles inclus dans Cursor ni le crédit prépayé. Avec Teams et Enterprise, le Cursor Token Rate continue de s’appliquer aux requêtes concernées. La complétion Tab utilise toujours les modèles intégrés de Cursor.

Cette option est utile lorsqu’une organisation possède déjà un compte chez un fournisseur et souhaite y faire facturer l’inférence. Elle ne garantit pas que toutes les variantes de modèles ou toutes les fonctionnalités de Cursor utiliseront ce compte. Avant de revoir les hypothèses de facturation de l’équipe, vérifiez que le modèle précis apparaît dans le sélecteur et que le workflow nécessaire est pris en charge.

Il faut également tenir compte du traitement des données : les requêtes passent toujours par le backend de Cursor pour construire les prompts. Cursor indique que les clés sont transmises de façon sécurisée et ne sont pas conservées, mais sa politique Zero Data Retention ne s’applique pas au BYOK. C’est la politique du fournisseur qui fait foi. Choisissez la connexion qui répond aux exigences de votre organisation, au-delà de la seule préférence de facturation.

La disponibilité régionale peut réduire le choix des modèles

Un modèle absent peut s’expliquer par les restrictions géographiques du fournisseur autant que par votre abonnement. La documentation des régions de Cursor précise que les restrictions des fournisseurs peuvent retirer des modèles du sélecteur. Choisissez un autre modèle activé, ou Auto si votre compte le propose. Une clé fournisseur ne fonctionne que là où ce fournisseur autorise l’accès ; elle ne permet pas de contourner un blocage régional.

Pour une équipe de développement répartie dans plusieurs régions, vérifiez la configuration prévue depuis la région de chaque développeur avant d’imposer un standard supposant un menu identique pour tous. Si un modèle manque, contrôlez dans cet ordre l’abonnement, la liste des modèles autorisés par l’administrateur, puis la disponibilité du fournisseur. Ce diagnostic est plus utile que de réinstaller l’éditeur à répétition.

Ce que les changements d’octobre ne permettent pas de conclure

Un changement dans les offres d’abonnement ne prouve pas que GPT a disparu de Cursor. À la date de vérification, Cursor documente toujours GPT-5.6 Sol. Une publication sur les réseaux sociaux ne suffit pas à établir un retrait ni une date de fin d’accès. Décidez de votre workflow à partir du catalogue actuel et des accès réels de votre compte.

Auto ne signifie pas non plus « le modèle le plus récent à chaque requête ». Sa liste validée diffère du catalogue complet, et son rôle consiste à sélectionner un modèle selon la tâche. Si un modèle précis fait partie de vos critères d’acceptation, sélectionnez-le directement lorsqu’il est disponible, au lieu d’espérer que le routeur le choisisse.

Enfin, une fenêtre de contexte plus grande ou un effort de raisonnement plus élevé ne remplacent pas une tâche bien définie. Pour un bug difficile, fournissez la procédure de reproduction, le comportement attendu et les tests qui doivent réussir. Davantage de capacité permet de prendre en compte davantage d’éléments ; cela ne comble pas les exigences manquantes.

Si votre besoin est de conserver l’accès à vos fournisseurs en passant d’un outil de programmation à un autre, le comparatif des alternatives à Cursor traite cette question distincte. La portabilité justifie d’évaluer une solution de repli, sans supposer qu’un fournisseur a quitté Cursor.

Faut-il changer maintenant, attendre ou conserver sa configuration ?

Les développeurs devraient modifier leur choix par défaut uniquement s’ils savent quel problème ce changement résout. Si Composer produit des modifications faciles à relire sur les tâches courantes, conservez-le. Si les tâches difficiles restent régulièrement inachevées, évaluez Grok 4.7 avec une condition de réussite explicite. Si l’échec vient d’une demande ambiguë, commencez par la préciser.

Les responsables d’équipe devraient examiner dès maintenant le routage et les sous-agents. Vérifiez les modèles autorisés, les modes Auto visibles, l’affichage du modèle réellement utilisé et les modèles imposés aux sous-agents personnalisés. Une politique qui ne valide que le modèle de l’agent principal laisse une partie du workflow réel sans examen.

Si vous avez besoin de Claude, GPT ou Gemini, écartez Plus. Si vous disposez d’un ancien abonnement, attendez de comprendre le quota auquel vous renonceriez avant de migrer. Un ancien compte qui fonctionne n’est pas obligé d’adopter la nouvelle structure de facturation simplement parce que les noms des offres publiques ont changé.

Lundi, prenez un ticket courant et un ticket difficile dans votre propre backlog. Notez le modèle choisi, les réglages, les modèles des sous-agents, les vérifications effectuées et la consommation. Conservez la configuration qui produit un travail acceptable avec le moins de corrections et une consommation prévisible. Ces observations sont plus utiles que d’uniformiser toute l’équipe autour d’un seul nom de modèle.

Questions fréquentes

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur les changements de modèles et leurs effets sur vos workflows.