Fournisseurs IA & réglages agents

Singularity ne contacte pas directement les API des fournisseurs. Il prépare le ticket, ouvre un processus local et pilote le CLI du fournisseur sélectionné. Installez d’abord ce CLI avec la méthode recommandée par son éditeur, ouvrez un terminal, lancez-le une première fois et terminez son authentification.

Le test le plus simple consiste à demander une réponse au CLI depuis le dossier d’un projet. S’il réclame une connexion, une approbation de dossier ou une mise à jour, réglez cela avant de lancer un ticket dans Singularity.

Installez Claude Code, lancez claude, puis suivez la connexion interactive Anthropic. La liste de modèles (Auto et les modèles Claude accessibles à votre compte) est chargée depuis le catalogue du fournisseur, donc elle peut évoluer sans mise à jour de cette page.

L’onglet permet de régler le mode de permissions, l’effort, la réflexion étendue ou adaptative, le mode rapide réservé à Opus, le cache de prompts, le contexte étendu, la mémoire, les limites de réflexion et de sortie, ainsi que les équipes d’agents.

Installez le CLI Codex, lancez codex et connectez votre compte OpenAI dans le parcours proposé. Les modèles affichés sont ceux du catalogue Codex disponible sur le poste, avec le choix Auto.

L’onglet expose la personnalité, la politique d’approbation, le bac à sable, l’effort et le résumé de raisonnement, ainsi que l’éditeur utilisé pour ouvrir les références. Les choix de sécurité modifient réellement les droits accordés au processus : préférez l’accès à l’espace de travail sauf besoin explicite.

Installez le CLI GitHub Copilot, lancez copilot et authentifiez-vous auprès de GitHub. Votre compte et votre organisation doivent autoriser Copilot. Auto et les modèles retournés par Copilot sont ensuite proposés.

L’onglet règle le mode d’approbation (suggestion, édition automatique ou autonomie complète), la recherche web, le mode plan et la délégation. Commencez en suggestion sur un dépôt sensible.

Installez Cursor et son agent CLI, puis lancez agent pour terminer la connexion. Auto et les modèles publiés par Cursor alimentent la sélection. Une clé peut aussi être saisie dans l’onglet ; le champ est masqué.

Les réglages couvrent les permissions (force, shell ou plan), les confirmations du mode shell, la recherche web et la conservation de l’historique de session.

Installez Gemini CLI, lancez gemini et choisissez la connexion Google proposée. Auto et les modèles Gemini autorisés sont découverts par le catalogue.

C’est l’onglet le plus détaillé : approbations, nombre de tentatives et de tours, compression et rétention des sessions, détection de boucle, routage des plans, stratégie de dépassement, format texte ou JSON, bac à sable, mode Vim, mise à jour automatique, notifications et intégration IDE.

Installez le CLI Mistral Vibe et vérifiez qu’il démarre depuis un terminal. Configurez ensuite un profil ou une clé Mistral dans le champ masqué de l’onglet. Auto et les modèles renvoyés par le fournisseur sont proposés.

Vous pouvez activer les modèles hors ligne, choisir entre YOLO, demande et plan pour les permissions, puis régler la recherche web et la persistance de l’historique.

Installez Ollama, démarrez son démon local et vérifiez ollama list. Singularity utilise par défaut l’endpoint local http://127.0.0.1:11434 et pilote Claude Code vers ce serveur. L’onglet sait rechercher, télécharger, supprimer et actualiser les modèles ; il recommande aussi ceux adaptés à la RAM et au processeur via llmfit ou une estimation.

Téléchargez le modèle avant de le sélectionner. Un petit modèle quantifié répond plus vite et consomme moins de mémoire, mais suit moins bien les longues consignes et les refactorings complexes. Sur CPU, attendez-vous à une génération nettement plus lente ; sur une machine sans assez de RAM ou de mémoire GPU, le modèle peut devenir inutilisable. Gardez un fournisseur distant pour les tâches difficiles.

Le réglage du fournisseur définit le modèle par défaut pour les nouveaux agents de l’espace de travail. Auto — choisir selon le contexte laisse la préqualification sélectionner un modèle admissible selon la tâche.

Au niveau d’un ticket, le sélecteur d’agent peut remplacer ce choix pour cette exécution : utile pour réserver un modèle puissant à une migration, ou choisir un modèle rapide pour une correction mécanique. Le réglage du ticket gagne sur le défaut de l’espace sans modifier celui-ci.

Dans « Modèles pour la sélection automatique », décochez un modèle pour empêcher Auto de le choisir. Il reste disponible pour une sélection manuelle. Utilisez cette exclusion pour éviter un modèle trop coûteux, trop lent, déprécié ou inadapté à votre dépôt.

Quand le fournisseur expose une profondeur de raisonnement, vous pouvez aussi retirer certains niveaux des sélecteurs de ticket. Cela évite par exemple une réflexion minimale sur du code critique ou un niveau maximal sur les tâches courtes. Ces exclusions réduisent les choix automatiques ; elles ne désinstallent rien.

Pour mesurer le coût d’un lot de tickets, relevez la consommation du même périmètre avant et après son exécution, puis séparez dépenses variables, abonnements et temps humain. Un compteur de tokens ou une estimation de session ne prouve pas le montant facturé. Aucun coût par ticket ni aucune économie ne sont garantis.

1. Définir la tâche témoin. Choisissez un petit correctif représentatif, avec le commit de départ, le même jeu de données, les critères d’acceptation et les tests. Listez les tickets du lot, y compris ceux qui échouent. Pour comparer deux workflows, repartez du même état et conservez les mêmes critères.
2. Figer le contexte. Notez le fournisseur, la version du CLI, le modèle réellement utilisé (et chaque changement si Auto est actif), l’effort, le nombre d’agents et le mode abonnement ou API. Identifiez le compte/projet de facturation sans copier de clé ni de donnée confidentielle.
3. Relever avant. Horodatez avec le fuseau, sauvegardez la source du compteur, sa période, sa devise, les tokens par modèle et les valeurs de cache si disponibles. Isolez le lot des autres usages du compte, ou déclarez la mesure non attribuable. Avec Claude Code interactif, consultez /usage dans la session concernée ; pour un lot orchestré sans accès à cette session, utilisez le relevé fournisseur du périmètre isolé, pas une nouvelle session CLI vide.
4. Exécuter et journaliser. Gardez toutes les tentatives, erreurs, relances, sous-agents et corrections après revue. Chronométrez séparément préparation, attente machine, revue humaine et intégration. Une durée murale de session n’est pas un temps de travail humain.
5. Relever après. Attendez la fin des agents et l’actualisation des compteurs ; conservez l’heure de capture et la fenêtre couverte. Utilisez exactement la même source et le même périmètre. Archivez chaque session avant sa remise à zéro ; une différence négative ou un changement de période invalide la soustraction.
6. Rapprocher et publier les limites. Calculez après moins avant, dans la même unité. Pour l’API, rapprochez l’estimation des montants du fournisseur une fois disponibles. Additionnez uniquement des périodes disjointes : ne comptez pas deux fois un total parent et ses sous-agents. Indiquez tickets tentés, acceptés et rejetés, qualité obtenue et temps de revue. Une moyenne par ticket accepté reste propre à ce lot, avec les échecs inclus au numérateur.

Comment mesurer la consommation de Claude Code ?

La documentation officielle des coûts Claude Code, consultée le 11 octobre 2026, décrit /usage : le bloc Session estime le coût des tokens ; les barres d’abonnement suivent les limites du plan. Le montant de session n’est pas la facture d’un abonnement Pro ou Max. Pour l’API, consultez la vue Usage de la Claude Console du compte facturé (connexion requise). Vérifiez la commande disponible dans votre version du CLI et la fraîcheur du relevé.

Exemple illustratif : trois tickets, pas un benchmark

Chiffres fictifs, non mesurés. Sur un périmètre API isolé, un relevé fournisseur cumulatif du 11/10/2026 à 10:00 UTC indique 12,00 USD et celui de 10:40 UTC 13,80 USD, pour la même période et la même devise : différence illustrative de 1,80 USD. Le journal fictif compte trois tickets tentés, deux acceptés, un rejeté, quatre tentatives et 18 minutes de revue. Le modèle exact et la version du CLI seraient à consigner dans un relevé réel ; cet exemple n’a exécuté aucun modèle.

Si les relevés sont complets et exclusifs au lot, 1,80 / 2 = 0,90 USD par ticket accepté pour ce seul exemple, échec compris. Ce n’est ni un tarif annoncé ni une prévision. Avec un abonnement, notez plutôt l’évolution du quota et les éventuels dépassements réellement facturés : ne transformez pas un pourcentage de quota en euros. Une quote-part d’abonnement est une convention comptable à expliciter, pas un coût marginal observé.

Fiche de relevé à copier

Lot / tickets / commit de départ :
Critères / tests / données :
Fournisseur / version CLI / modèle(s) / effort / agents :
Mode abonnement ou API / périmètre de facturation :
Source / période / fuseau / devise / taxes :
Avant : horodatage, montant ou quota, tokens/cache disponibles
Après : horodatage, montant ou quota, tokens/cache disponibles
Tentatives / erreurs / relances / tickets acceptés et rejetés :
Minutes de préparation / attente / revue / intégration :
Différence observée / rapprochement facture / pièces expurgées :
Limites : usages simultanés, délais, resets, cache, frais exclus

Le cache, les prix contractuels, les devises, les taxes, les crédits et les autres appareils peuvent empêcher une attribution exacte. Si un compteur manque, indiquez « indisponible », jamais zéro. Gardez la licence Singularity, les abonnements fournisseurs, les dépassements, l’exécution distante et le temps humain sur des lignes séparées ; ne recomptez pas une consommation déjà incluse. Consultez les tarifs et coûts fournisseurs et appliquez cette fiche au protocole comparatif Claude Code.

Singularity ne téléverse pas de lui-même votre code vers un fournisseur IA. Seuls les CLI que vous avez installés et configurés communiquent avec leurs services extérieurs, selon leurs propres conditions, réglages et politiques de conservation. Les prompts, extraits de fichiers et résultats d’outils nécessaires à l’agent peuvent donc transiter par le fournisseur choisi.

Avec Ollama sur l’adresse locale et un modèle exécuté localement, l’inférence reste sur le poste ; le téléchargement initial d’un modèle contacte toutefois le registre Ollama. Un endpoint Ollama distant ou un modèle cloud n’est plus local. Consultez le tableau des politiques des sept intégrations. Vérifiez toujours l’URL configurée et les permissions de l’agent avant de traiter un dépôt confidentiel.

La conservation dépend du fournisseur, de l’offre et du compte réellement utilisé par le CLI. Ce relevé de la documentation des éditeurs, consultée le 11 octobre 2026, permet de retrouver la règle applicable ; il ne constitue ni un engagement de Singularity ni une vérification de votre contrat.

Avant un dépôt confidentiel, vérifiez l’authentification, l’endpoint, le modèle, les options de partage et les règles de votre organisation. Absence d’entraînement, absence de conservation et historique local sont trois sujets distincts. Aucun délai universel n’est déduit ici : exceptions légales, anti-abus, retours volontaires et services avec état restent à lire dans les sources. Les outils web, extensions/MCP, journaux et historiques du CLI peuvent avoir leurs propres destinations et durées, même avec une inférence locale.