Premiers pas avec le modèle Composer

Composer est le modèle de codage agentique de pointe propre à Cursor, formé en interne et optimisé pour une seule chose : accomplir du vrai travail de codage rapidement. Il planifie, modifie plusieurs fichiers, exécute des commandes de terminal et enchaîne les outils avec une latence inhabituellement faible, le tout pour une fraction du coût des grands modèles de pointe. Ce guide explique ce qu'est Composer, comment le sélectionner, où il excelle, où vous devriez encore préférer les modèles de la classe Claude ou GPT, et comment en tirer le meilleur parti au quotidien.

Qu'est-ce que le modèle Composer ?

Composer est une famille de modèles personnalisés conçus par l'équipe Cursor plutôt que sous licence d'un tiers. Il est entraîné spécifiquement pour le codage agentique : lire votre base de code, former un plan, appeler des outils, appliquer des modifications sur plusieurs fichiers et vérifier les résultats. Contrairement aux modèles de chat polyvalents adaptés au codage, Composer a été optimisé dès le départ pour la boucle d'agent.

Les objectifs de conception derrière la gamme de modèles sont :

• Faible latence : les réponses commencent vite et les appels d'outils s'exécutent sans longs intervalles, donc la boucle modification-test semble immédiate.
• Efficacité agentique : le modèle est réglé pour enchaîner judicieusement les appels d'outils au lieu de vous demander de micromanager chaque étape.
• Efficacité tarifaire : Composer est nettement moins cher par requête que les meilleurs modèles de pointe, ce qui compte pour les longues sessions d'agent.
• Raisonnement pratique : il est assez puissant pour planifier des changements multi-étapes tout en restant bien plus rapide que les modèles à réflexion étendue.

Dans l'éditeur, il se comporte comme n'importe quel autre modèle : vous le sélectionnez dans le sélecteur de modèles et il alimente Chat, le mode Agent, les modifications en ligne et les agents en arrière-plan. La différence se ressent dans le débit. Des tâches qui prennent une minute de réflexion à un modèle de pointe se terminent souvent en quelques secondes avec Composer, avec une qualité qui tient bien pour la majorité du travail de codage quotidien.

Composer n'est pas la fonctionnalité Composer de 2024

Ne confondez pas le modèle Composer avec l'ancienne fonctionnalité d'édition multi-fichiers « Composer » que Cursor a publiée en 2024. Cet outil précoce était un workflow d'interface pour appliquer des changements sur de nombreux fichiers, et il a ensuite été intégré à ce qui est aujourd'hui le mode Agent. Le Composer dont traite ce guide est le modèle lui-même, sélectionné dans le même sélecteur que Claude et GPT. Si vous lisez d'anciens tutoriels qui traitent Composer comme un panneau séparé ou un raccourci clavier, ils décrivent la fonctionnalité retirée, pas ce modèle.

En quoi Composer diffère des modèles tiers

Les modèles Claude, GPT et Gemini sont des modèles de pointe polyvalents vers lesquels Cursor route via le réseau. Composer est d'une autre nature : un modèle conçu par Cursor spécifiquement pour la boucle d'agent. Cette différence se manifeste dans le comportement même si les détails internes exacts ne sont pas publics.

Lignée de modèle de fondation vs modèles de pointe routés

Lorsque vous sélectionnez un modèle tiers dans Cursor, vous appelez un grand modèle polyvalent entraîné sur une distribution très large, puis enveloppé dans le harnais d'agent de Cursor. Lorsque vous sélectionnez Composer, vous appelez un modèle dont les objectifs de conception ont été façonnés dès le départ autour de la navigation dans la base de code, de l'utilisation d'outils et de l'itération rapide. En pratique, cela signifie :

• Les modèles tiers apportent une immense étendue et un raisonnement profond, au prix de la latence et du prix par requête.
• Composer apporte vitesse et faible coût, réglé pour la forme spécifique des tâches de codage plutôt que pour des benchmarks de raisonnement général.
• Le harnais compte dans les deux cas. Les outils de Cursor (lecture de fichiers, modifications, terminal, recherche) se trouvent devant les deux, donc la comparaison porte en réalité sur le comportement du modèle à l'intérieur de ce harnais.

Compromis vitesse vs profondeur

Considérez-le comme un cadran entre profondeur et débit plutôt qu'un binaire « bon » / « mauvais » :

• Les modèles orientés profondeur passent plus de temps à planifier et raisonner en interne, ce qui paie sur les problèmes ambigus et étendus.
• Les modèles orientés débit comme Composer agissent plus tôt, devinent moins souvent que leur vitesse ne le suggère et convergent vite sur les tâches bien délimitées.
• La plupart du vrai travail est un mélange. Par défaut, allez vers l'extrémité orientée débit et escaladez lorsqu'une tâche s'avère nécessiter de la profondeur.

Chiffres de latence illustratifs

Pour rendre le compromis concret, voici des chiffres approximatifs et illustratifs. Considérez-les comme des ordres de grandeur approximatifs, et non comme des benchmarks mesurés, car la latence dépend fortement de la taille de la tâche, de la longueur du contexte et de la charge.

Scénario	Composer (approx.)	Modèle de pointe (approx.)
Premier token significatif	Bien moins d'une seconde	Une seconde ou plus
Une courte modification d'un seul fichier	Quelques secondes	Dix à trente secondes
Une tâche multi-fichiers à forte utilisation d'outils	Des dizaines de secondes	Une à plusieurs minutes

Les chiffres sont indicatifs, pas contractuels

Les chiffres ci-dessus n'existent que pour transmettre la forme de la différence : Composer est systématiquement plus rapide, et l'écart s'élargit sur les boucles à forte utilisation d'outils. Ne les citez pas comme des chiffres fermes ; mesurez sur votre propre charge de travail si la précision compte.

Sélectionner Composer dans le sélecteur de modèles

Composer est disponible partout où vous pouvez choisir un modèle : Chat, mode Agent et les workflows en ligne de style Composer à l'intérieur d'Agent. Pour y passer :

1. Ouvrez le mode Chat ou Agent avec le raccourci de panneau habituel.
2. Cliquez sur le sélecteur de modèle à côté de la zone de saisie.
3. Trouvez Composer dans la liste des modèles. Les modèles internes de Cursor sont regroupés séparément des modèles tiers.
4. Sélectionnez l'entrée Composer et envoyez votre prompt comme d'habitude.

Vous pouvez aussi faire de Composer votre modèle par défaut dans Settings > Models, afin que chaque nouvelle discussion commence avec lui. De nombreux développeurs gardent Composer comme défaut et ne basculent manuellement vers un modèle plus lourd que lorsqu'une tâche a réellement besoin d'un raisonnement plus profond.

Composer apparaît aussi dans la liste des modèles pour les agents en arrière-plan, ce qui en fait un choix naturel pour les tâches distantes où vous ne surveillez pas la latence directement mais où le coût et le temps total comptent.

Où Composer peut être utilisé

Surface	Comment utiliser Composer	Modèle de coût typique
Chat	Sélectionnez-le dans le sélecteur de modèles	Par requête, décompté de votre plan
Mode Agent	Même sélecteur, utilisé pour les tâches multi-étapes	Par requête
Cmd-K / modification en ligne	Disponible pour des modifications ponctuelles rapides	Par requête
Agents en arrière-plan	Sélectionnez Composer au démarrage de la tâche	Par requête, les sessions plus longues coûtent plus
Complétion Tab	Pas un choix de sélecteur ; Tab utilise son propre modèle	Décompté différemment des requêtes de modèle

Coût par requête vs par token

L'utilisation du plan Cursor est généralement décomptée par requête plutôt que purement par token, c'est pourquoi un modèle moins cher par requête comme Composer étire un plan bien plus loin que son seul prix brut par token ne le suggérerait. Deux implications pratiques :

• Les longues sessions qui enchaînent de nombreux appels d'outils sont là où l'avantage de Composer est le plus grand, car chaque étape supplémentaire est comparativement bon marché.
• Si vous avez l'habitude de raisonner sur le coût des tokens en termes d'API brute, rappelez-vous que Cursor présente votre utilisation comme une consommation de plan, donc le chiffre que vous surveillez est le compteur du plan, pas un montant en dollars.

Forces et compromis

Aucun modèle ne gagne tout. Voici comment Composer se compare aux modèles de pointe entre lesquels vous alternerez typiquement.

Capacité	Composer	Modèles de la classe Claude	Modèles de la classe GPT
Latence de réponse	Très rapide	Modérée à lente	Modérée
Coût par requête	Faible	Élevé	Élevé à modéré
Modifications multi-fichiers	Solide, conçu pour cela	Excellent	Très bon
Aisance avec les commandes de terminal	Solide	Excellente	Très bonne
Raisonnement architectural profond	Bon	Excellent	Excellent
Longues refactorisations ambiguës	Bon avec des instructions claires	Le meilleur	Très bon
Boucles d'itération rapides	Le meilleur	Modérées	Modérées

Le schéma est clair : Composer échange un peu de profondeur de raisonnement de pointe contre un large gain en vitesse et en coût. Pour une grande part des tâches quotidiennes, comme implémenter un composant bien spécifié, corriger un test défaillant, écrire un script de migration ou refactoriser un module avec une interface claire, Composer termine le travail avant qu'un modèle de pointe n'ait fini de planifier.

Choisir entre Composer et des modèles plus grands

Une règle empirique pratique consiste à utiliser Composer par défaut et à escalader lorsque la tâche montre des signes de besoin de raisonnement plus profond. Choisissez Composer lorsque :

• La tâche est bien spécifiée : vous connaissez les fichiers, le modèle à suivre et la définition de terminé.
• Vous itérez rapidement et attendez plusieurs petits cycles de modifications.
• Vous effectuez de la maintenance de routine : mises à jour de dépendances, renommages, refactorisations dictées par le formatage.
• Vous regroupez de nombreuses petites tâches indépendantes, où le coût s'accumule vite.

Optez pour un modèle de la classe Claude ou GPT lorsque :

• Le problème est ambigu et le modèle doit inférer l'intention à partir d'une base de code étendue.
• Vous avez besoin d'un raisonnement soutenu sur de nombreux modules interdépendants, par exemple un changement de protocole touchant les couches client, serveur et schéma.
• Vous déboguez un problème subtil de concurrence, de mémoire ou de correction où les mauvaises suppositions coûtent cher.
• Vous faites de la conception au niveau architectural où la qualité du premier plan compte plus que la vitesse de la première réponse.

Escaladez en cours de tâche plutôt que de redémarrer

Si vous commencez une tâche avec Composer et remarquez qu'il tourne en rond sans converger, changez de modèle pour le tour suivant plutôt que de démarrer une nouvelle discussion. Le contexte existant, les fichiers ouverts et le plan jusqu'ici sont conservés, et le modèle plus puissant peut reprendre là où le modèle rapide s'est enlisé.

Conseils de prompt pour les petits modèles rapides

Les modèles rapides récompensent la précision. Composer répond nettement mieux lorsque vos prompts suppriment les conjectures, car chaque conjecture qu'il n'a pas à faire représente de la latence et des tokens économisés.

Adoptez ces habitudes :

• Nommez les fichiers et les répertoires d'emblée. Les modèles rapides planifient moins largement, donc les orienter immédiatement vers la bonne zone les maintient sur la bonne voie.
• Énoncez la définition de terminé. Indiquez quels tests doivent passer, quelle commande doit s'exécuter ou quel comportement doit changer.
• Un objectif par prompt. Séparez les demandes à objectifs multiples en prompts séquentiels ; la boucle d'agent gère bien mieux les chaînes de petits objectifs qu'un seul objectif étendu.
• Ancrez-vous à des patrons existants. Référencez un fichier qui implémente déjà le patron que vous voulez et demandez au modèle de le suivre.
• Restreignez le rayon d'impact. Dites explicitement ce qu'il ne faut pas toucher, par exemple « ne modifie pas l'API publique de UserService ».

Un prompt bien façonné pour Composer ressemble à ceci :

In src/services/, add retry logic to the StripeClient class.
Follow the existing retry pattern in src/services/GithubClient.ts
(exponential backoff, max 3 attempts, logs via the shared logger).

Requirements:
- Only src/services/StripeClient.ts and its test file may change.
- Add unit tests mirroring GithubClient.test.ts.
- `npm test -- stripe` must pass when you are done.

Do not modify the public constructor signature.

Comparez cela avec un prompt vague comme « ajoute des tentatives au client Stripe ». Les deux finissent par fonctionner, mais la première version aboutit généralement en une seule passe, ce qui est exactement la raison d'être d'un modèle optimisé pour la vitesse.

Optimiser les prompts pour un modèle rapide

Les habitudes ci-dessus couvrent les bases ; cette section approfondit la façon de façonner le travail d'un modèle rapide pour qu'il réussisse à la première passe.

À faire et à ne pas faire

À faire	À ne pas faire
Nommer les fichiers et répertoires exacts	Demander au modèle de « trouver où se trouve X » dans tout le dépôt
Énoncer la définition de terminé	Laisser les critères de réussite implicites
Donner un objectif par prompt	Regrouper plusieurs objectifs sans rapport dans un seul prompt
Pointer vers un patron existant à copier	Décrire un tout nouveau patron uniquement en prose
Lister ce qui ne doit pas changer	Supposer que le modèle inférera le rayon d'impact
Demander une étape de vérification	Sauter les tests et approuver le diff à l'œil

Un bon prompt vs un mauvais prompt

Un prompt diffus tend à produire une modification diffuse :

Clean up the auth code and make it better.

Un prompt délimité donne au modèle rapide tout ce dont il a besoin pour aboutir en une passe :

In src/auth/session.ts, extract the token-refresh logic into a
private method refreshToken() and call it from getSession().

Constraints:
- Only src/auth/session.ts and src/auth/session.test.ts may change.
- Keep the public exports of the module identical.
- Mirror the structure of src/auth/oauth.ts, which already does this.
- `npm test -- auth` must pass.

Report the test output when done.

La différence n'est ni la politesse ni la longueur ; c'est le nombre de décisions que le modèle doit prendre seul. Moins de décisions signifie moins de faux pas et, pour un modèle optimisé pour la vitesse, moins de secondes gaspillées.

Découper les tâches en petites étapes

Décomposez les objectifs plus grands en une courte séquence et laissez la boucle d'agent porter chaque étape :

1. Planifier : demandez un plan écrit et confirmez-le avant toute modification.
2. Implémenter : un fichier ou un module par prompt.
3. Vérifier : exécutez les tests ou la commande pertinents après chaque étape.
4. Continuer : ne passez à l'étape suivante qu'une fois la précédente au vert.

Donner des références de fichiers explicites

Préférez les chemins et les symboles aux descriptions. « Mets à jour src/billing/Invoice.ts » vaut mieux que « mets à jour le code de facturation ». Lorsque c'est possible, collez le nom exact de la fonction ou un court extrait à suivre, car le modèle passe alors moins de temps à chercher et plus de temps à modifier.

Demander une vérification

Les modèles rapides bénéficient le plus lorsque vous rendez la vérification explicite. Terminez les prompts par une ligne telle que « exécute npm test -- <scope> et collez la sortie », ou « signale les commandes exactes que tu as exécutées ». Cela transforme la vitesse de l'agent en progrès digne de confiance plutôt qu'en mouvement non vérifié.

Encoder les conventions d'équipe dans les règles

Parce que Composer optimise pour la vitesse, il s'appuie davantage sur les garde-fous qu'un modèle plus lent qui raisonne tout. Placer vos conventions dans .cursor/rules paie de manière disproportionnée avec les modèles rapides. Un fichier de règles compact :

---
description: Service layer conventions for fast model edits
globs:
  - "src/services/**/*.ts"
alwaysApply: false
---

- Follow the client class pattern in src/services/GithubClient.ts.
- All network calls use the shared http client; never import axios directly.
- Every public method needs a unit test in the matching .test.ts file.
- Prefer early returns; keep methods under 40 lines.
- After edits, run `npm test -- <affected-scope>` and report results.

Avec des règles comme celle-ci en place, vous pouvez lancer de courts prompts à Composer et compter sur le fait que les normes répétitives sont appliquées sans les réénoncer à chaque fois.

Utiliser Composer dans les agents en arrière-plan

Les agents en arrière-plan exécutent l'agent de Cursor à distance sur votre dépôt pendant que vous faites autre chose, en revenant avec un diff ou une pull request. Composer est souvent le meilleur défaut ici pour deux raisons :

1. Efficacité des coûts. Les tâches en arrière-plan ont tendance à être plus longues et plus exploratoires, et les coûts de tokens s'accumulent sur toute la session. Un modèle moins cher par requête garde une flotte d'agents en arrière-plan abordable.
2. Débit. Lorsque vous lancez plusieurs agents en arrière-plan en parallèle, chacun finissant quelques minutes plus tôt se cumule en un workflow global bien plus réactif.

Les bonnes tâches en arrière-plan pour Composer incluent l'écriture de tests manquants pour un module, l'application d'une refactorisation mécanique sur un paquet, la génération d'ébauches de documentation et la correction de problèmes simples tirés d'un tracker. Pour les tâches qui exigent des jugements sur tout le système, démarrez l'agent en arrière-plan avec un modèle de la classe Claude ou GPT à la place, ou commencez par une phase de planification dans votre éditeur au premier plan et confiez à Composer un plan précis.

Écrivez les prompts en arrière-plan comme un ticket

Un agent en arrière-plan ne peut pas vous poser de questions de clarification en cours d'exécution comme le peut une session interactive. Donnez-lui l'objectif, les contraintes, les fichiers concernés et comment vérifier le succès. Traitez le prompt comme un petit ticket autonome et Composer utilisera bien son autonomie.

Composer dans les agents en arrière-plan

Les agents en arrière-plan sont là où les avantages de coût et de vitesse de Composer se cumulent, car vous n'êtes pas assis à surveiller chaque étape. Bien déléguer demande un peu de discipline.

Déléguer des tâches longues

Un bon prompt de délégation est autonome et en forme de ticket :

Goal: add unit tests for every public method in src/services/Billing.ts.

Context: follow the testing style in src/services/Billing.test.ts if it
exists; otherwise mirror src/services/GithubClient.test.ts.

Scope: only create or edit test files under src/services/. Do not change
production code. If a method looks untestable as written, note it in the
final summary instead of refactoring.

Verify: `npm test -- services/Billing` must pass. Report the output.

Choisir la portée

• Limitez une tâche en arrière-plan à un paquet, un module ou une préoccupation. Les tâches larges dérivent.
• Préférez les changements mécaniques pour les exécutions en arrière-plan : renommages, couverture de tests, ébauches de doc, scripts de migration.
• Évitez les tâches qui reposent sur le goût ou le jugement architectural ; commencez celles-ci dans une session au premier plan où vous pouvez orienter.

Examiner le diff

Les agents en arrière-plan renvoient un diff ou une pull request, donc examinez-le comme le travail d'un coéquipier :

1. Vérifiez les fichiers touchés par rapport à la portée que vous avez fixée. Tout ce qui sort de la portée est un signal d'examen plus attentif.
2. Lisez le résumé de l'agent sur ce qu'il prétend avoir fait, puis vérifiez au moins une affirmation dans le code.
3. Exécutez les tests localement ou confirmez la sortie signalée avant de fusionner.
4. Si le diff est globalement correct mais comporte quelques aspérités, corrigez-le dans l'éditeur plutôt que de relancer tout l'agent ; la relance peut modifier des lignes sans rapport.

Les diffs en arrière-plan non examinés sont un risque

Parce que Composer va vite, il peut produire un grand diff rapidement. La vitesse de production n'est pas la vitesse de correction. Traitez chaque résultat en arrière-plan comme une proposition jusqu'à ce que vous ayez vérifié les tests et la portée, et planifiez du temps d'examen, pas seulement du temps d'exécution.

Caractéristiques de coût et d'utilisation

Composer est l'un des moyens les plus économiques de consommer votre plan Cursor. Implications pratiques :

• Beaucoup plus de requêtes d'agent tiennent dans l'allocation d'utilisation de votre plan, comparé à tout exécuter sur des modèles de pointe.
• Les longues sessions agentiques, qui enchaînent de nombreux appels d'outils, restent abordables car chaque étape coûte moins.
• Des réponses rapides signifient moins de temps horloge par session, ce qui économise indirectement de l'argent lorsque vous itérez de manière interactive.

Si vous surveillez l'utilisation dans le tableau de bord, vous verrez clairement la différence après une semaine à utiliser Composer par défaut : le même volume de tâches terminées aboutit à une part nettement plus faible de votre quota. Une stratégie courante consiste à dépenser du quota de modèle de pointe uniquement là où cela achète une vraie qualité de raisonnement et à laisser Composer absorber le volume de routine.

Ce qui compte pour vos limites

Les requêtes Chat et Agent, les modifications Cmd-K et les exécutions d'agents en arrière-plan comptent tous pour votre plan, décomptés par requête. Les complétions Tab sont généralement gérées séparément, et lire des fichiers ou exécuter des commandes n'est pas facturé en soi ; le coût est déterminé par les tours de modèle qui les appellent.

Coût, vitesse et qualité relatifs

Le tableau ci-dessous est une comparaison approximative et grossière pour vous aider à choisir, pas un benchmark. Les classements peuvent changer entre les versions de modèles et selon votre mix de tâches.

Modèle	Vitesse relative (approx.)	Coût relatif (approx.)	Profondeur de raisonnement relative (approx.)
Composer	Le plus rapide	Le plus bas	Bon
Claude Sonnet	Modérée	Plus élevé	Solide
Claude Opus	Le plus lent	Le plus élevé	Le plus solide
Modèles de la famille GPT	Modérée	Élevé à modéré	Solide
Modèles Gemini	Modérée à rapide	Modérée	Solide

Lisez le tableau comme « Composer gagne sur la vitesse et le coût ; les modèles de pointe gagnent sur le raisonnement de pointe ». La plupart des équipes finissent par utiliser Composer par défaut et escalader délibérément, plutôt que l'inverse.

Combiner Composer avec d'autres modèles

Le workflow le plus solide n'est pas « choisir un modèle pour toujours » ; c'est router chaque phase d'une tâche vers le modèle qui lui convient.

1. Planifiez avec un modèle de raisonnement. Commencez par un modèle de la classe Claude ou GPT et demandez uniquement un plan : quels fichiers toucher, dans quel ordre et comment vérifier. Ne modifiez pas encore.
2. Exécutez avec Composer. Une fois le plan écrit et approuvé, changez de modèle pour Composer pour les modifications réelles. Un modèle rapide avec un plan clair surpasse un modèle rapide qui découvre le plan au fur et à mesure.
3. Révisez avec un second modèle. Après l'application des modifications, passez à un modèle différent et demandez-lui d'examiner le diff pour la correction, les cas limites et les exigences manquées. Un modèle frais lisant le résultat attrape ce que le modèle exécutant a rationalisé.

Phase 1 (Claude/GPT, plan only):
"Read src/payments/ and propose a step-by-step plan to add idempotency
keys to the charge endpoint. List files, order, and verification. Do not edit."

Phase 2 (Composer, execute):
"Implement step 1 from the plan. Only src/payments/charge.ts may change.
Run `npm test -- payments` and report output."

Phase 3 (second model, review):
"Review this diff for correctness and edge cases. Flag anything that
breaks idempotency under retries."

Cette boucle planifier-exécuter-réviser garde les appels coûteux de raisonnement profond petits et concentrés, tandis que Composer absorbe le volume de l'édition réelle.

Même contexte, modèle différent

Changer de modèle en cours de tâche garde la discussion, les fichiers ouverts et le plan intacts, donc le passage entre les phases ne coûte rien. Vous n'avez pas besoin de réexpliquer la tâche ; changez simplement le sélecteur et continuez.

La suite : Composer 3

La gamme Composer est en développement actif, et la feuille de route communautaire est déjà pleine de demandes pour une prochaine itération, souvent appelée Composer 3. Les thèmes récurrents de cette discussion incluent une planification à long horizon plus solide, de meilleures performances sur de très grands dépôts et une fiabilité accrue sur les tâches multi-étapes ambiguës, tout en conservant la signature de faible latence et de faible coût.

Vous n'avez pas besoin d'attendre tout cela pour en bénéficier aujourd'hui. Les modèles Composer actuels sont des outils quotidiens de qualité production, et comme la sélection de modèle est une liste déroulante plutôt qu'un engagement, vous pouvez les adopter maintenant et changer dès qu'une génération plus récente apparaît dans le sélecteur.

Problèmes et limites courants

Composer est rapide, et la vitesse a des modes de défaillance que vous devriez reconnaître tôt.

Effectuer de grandes modifications globales

Composer peut tenter un changement à l'échelle du dépôt en une seule fois et laisser un diff étendu et difficile à examiner.

• Cause : un prompt non délimité comme « refactorise la journalisation partout ».
• Solution : restreignez le changement à un paquet ou un module, ou décomposez la tâche en une courte séquence de prompts délimités. Demandez d'abord un plan si le changement est réellement large.

Perdre des instructions dans les tâches longues

Sur une longue session, les contraintes antérieures peuvent se diluer à mesure que le contexte grandit.

• Cause : de nombreux tours avec des objectifs changeants dans une seule discussion.
• Solution : réénoncez les contraintes critiques lorsque vous changez de direction, ou démarrez une nouvelle discussion avec un résumé compact de l'objectif et des règles. Les fichiers de règles dans .cursor/rules aident aussi à fixer les conventions sur toute une session.

API hallucinées

Les modèles rapides référencent parfois des méthodes ou des paquets qui n'existent pas.

• Cause : le modèle fait de la correspondance de motifs à partir de son entraînement plutôt que de votre base de code.
• Solution : donnez des références de fichiers explicites et demandez-lui de vérifier par rapport à la source réelle. S'il invente une API, pointez la vraie et demandez-lui de refaire la modification en utilisant uniquement des symboles qui existent dans le dépôt.

Nécessiter une refactorisation de toute la base de code

Certaines refactorisations s'étendent véritablement sur tout le système et dépassent ce qu'un modèle rapide gère bien en une passe.

• Cause : le changement a des dépendances transverses et des frontières ambiguës.
• Solution : planifiez-le d'abord avec un modèle de raisonnement, puis exécutez-le comme une série d'étapes Composer délimitées, en vérifiant après chacune. Envisagez un agent en arrière-plan par paquet plutôt qu'une seule exécution géante.

Délais d'attente ou blocages

Parfois une exécution d'agent se bloque ou expire, surtout sur de très grandes tâches.

• Cause : un objectif trop large, un contexte énorme ou une seule étape qui ne se résout jamais.
• Solution : réduisez la tâche et réessayez ; si cela se reproduit, découpez le travail en étapes plus petites, et envisagez un modèle de pointe pour l'étape qui bloque sans cesse. Délimitez les longues exécutions en arrière-plan afin qu'un blocage vous coûte des minutes, pas une heure.

Du symptôme à la cause à la solution

Symptôme	Cause probable	Solution
Diff énorme, impossible à examiner	Prompt non délimité	Restreignez la portée ; demandez un plan et découpez en étapes
Le modèle ignore les contraintes antérieures	Dilution du contexte sur une longue discussion	Réénoncez les contraintes ou démarrez une nouvelle discussion résumée
Le modèle appelle des méthodes qui n'existent pas	Correspondance de motifs basée sur l'entraînement	Donnez des références de fichiers ; demandez-lui de vérifier par rapport aux vrais symboles
Une refactorisation de toute la base de code semble risquée	Changement transversal	Planifiez avec un modèle de raisonnement, puis exécutez en étapes délimitées
L'exécution se bloque ou expire	Tâche trop large ou contexte surdimensionné	Réduisez et réessayez ; découpez en étapes plus petites

Questions fréquentes

Composer est-il identique à la fonctionnalité Composer de 2024 ?

Non. Le « Composer » de 2024 était un workflow d'édition multi-fichiers dans l'interface de Cursor, ensuite intégré au mode Agent. Le Composer de ce guide est un modèle, sélectionné dans le même sélecteur que Claude et GPT.

Sur quel modèle Composer s'exécute-t-il ?

Composer est la gamme de modèles interne propre à Cursor, entraînée par l'équipe Cursor plutôt que routée vers un tiers. Son profil de vitesse et de coût découle de cette focalisation plutôt que d'un modèle de fondation polyvalent.

Quand dois-je choisir Composer plutôt que Claude ou GPT ?

Utilisez Composer par défaut pour le travail bien spécifié, rapide et itératif. Escaladez lorsqu'une tâche est ambiguë, s'étend sur de nombreux modules interdépendants ou nécessite un raisonnement profond au niveau architectural.

Est-il assez bon pour du vrai travail de production ?

Oui, pour la grande majorité des tâches quotidiennes : implémenter des composants spécifiés, corriger des tests, refactorisations mécaniques et maintenance de routine. Pour un raisonnement à enjeux élevés, associez-le à un modèle de pointe via le workflow planifier-exécuter-réviser.

Cela coûte-t-il plus cher ?

C'est l'un des moyens les moins chers de consommer votre plan. Comme les plans sont largement décomptés par requête, un modèle à faible coût par requête permet à plus de travail de tenir dans votre allocation.

Puis-je changer de modèle au milieu d'une tâche ?

Oui, et vous devriez. La discussion, les fichiers ouverts et le plan sont conservés, donc vous pouvez planifier avec un modèle de raisonnement puis basculer vers Composer pour exécuter sans perdre le contexte.

Pourquoi mes modifications se bloqueraient-elles ou tourneraient-elles en rond ?

Généralement parce que la tâche était trop large pour une seule passe. Réduisez la portée, donnez des fichiers explicites et vérifiez après chaque étape plutôt que d'attendre d'un seul prompt qu'il fasse tout.

Y aura-t-il un Composer 3 ?

La discussion communautaire pointe vers une prochaine génération avec une planification à long horizon plus solide et de meilleures performances sur les grands dépôts. Vous n'avez pas besoin d'attendre ; la sélection de modèle est une liste déroulante, donc vous pouvez adopter une version plus récente le jour où elle apparaît.

Référence rapide

Question	Réponse
Qu'est-ce que Composer ?	Le modèle de codage agentique interne de Cursor, optimisé pour la vitesse
Où le sélectionner ?	Sélecteur de modèles dans Chat et mode Agent, ou Settings > Models
Quand ne pas l'utiliser ?	Tâches de raisonnement profond, ambiguës et à forte composante architecturale
Est-ce l'ancienne fonctionnalité Composer ?	Non, l'outil multi-fichiers de 2024 a été intégré au mode Agent
Fonctionne-t-il dans les agents en arrière-plan ?	Oui, et c'est un défaut rentable là-bas
Quelle est la suite ?	Discussion communautaire sur une génération Composer 3

Composer récompense un workflow simple : utilisez-le par défaut, écrivez des prompts précis, encodez vos conventions dans des règles et escaladez vers des modèles de pointe uniquement lorsqu'une tâche a vraiment besoin d'un raisonnement plus profond. Cette habitude vous procure les avantages de vitesse et de coût de la gamme de modèles propre à Cursor sans sacrifier la qualité là où elle compte.