Le modèle d’agent de programmation le moins cher est celui qui permet de faire accepter une modification lors de la revue avec la facture totale la plus basse, et pas nécessairement celui dont le tarif d’entrée est le plus faible. Un agent envoie à plusieurs reprises le contexte du dépôt, reçoit la sortie des outils, raisonne, rédige un correctif et peut avoir besoin de plusieurs corrections. Cette comparaison utilise l’instantané du catalogue de modèles en temps réel de GetVibe au 3 octobre 2026 et se concentre sur les modèles utilisables dans des workflows de programmation.
Instantané des prix du catalogue
Les chiffres suivants sont exprimés en USD pour un million de tokens, l’entrée étant indiquée en premier et la sortie en second. Les cellules de prix affichées sont résolues à partir du catalogue GetVibe ; la date indique le moment où cette comparaison a été vérifiée.
| Modèle | Tarif entrée / sortie | Premier test recommandé |
|---|---|---|
| GPT-6 Luna | $0.0055 entrée · $0.0274 sortie par million de tokens | Petits correctifs, résumés et itérations rapides |
| GPT-6.1 Sol | $0.1096 entrée · $0.548 sortie par million de tokens | Modifications en plusieurs étapes et raisonnement plus approfondi |
| GPT-6 Sol | $0.1096 entrée · $0.548 sortie par million de tokens | Comparer avec 6.1 sur les prompts existants |
| Claude Sonnet 5.5 | $0.168 entrée · $0.84 sortie par million de tokens | Programmation au format Messages et boucles d’agent |
Il s’agit de tarifs du catalogue, et non du résultat d’un benchmark. La page du modèle reste la source actuelle si les tarifs changent après le 3 octobre 2026. Claude Sonnet 5.5 est utile pour Claude Code, car il accepte le format Messages ; les modèles GPT-6 doivent être testés via un outil compatible avec Responses tel que Codex CLI, et non via Claude Code.
Utilisez un test de programmation qui mesure le travail terminé
Choisissez trois tâches de dépôt : un correctif localisé avec un test en échec, une petite fonctionnalité touchant plusieurs fichiers et une refactorisation avec une exigence explicite de ne pas modifier le comportement. Figez le même commit Git, les mêmes instructions, les mêmes autorisations d’outils et la même commande de test pour chaque exécution. Évaluez si la tâche est correcte, si les tests réussissent, combien de tours de correction ont été nécessaires et combien de temps la modification complète a pris.
Ne comparez pas uniquement la réponse finale. Un modèle peut produire un correctif convaincant qui échoue aux tests, ce qui entraîne un autre long tour. Enregistrez l’utilisation des tokens d’entrée et de sortie pour chaque tour, y compris les résultats des outils et les prompts de correction. Calculez le coût par modification validée. Exécutez au moins quelques échantillons par tâche ; une réponse chanceuse ne constitue pas un classement stable.
Pourquoi un tarif de tokens faible peut malgré tout coûter plus cher
Les agents renvoient souvent un préfixe volumineux : instructions système, notes du dépôt, schémas d’outils et conversation précédente. Les tokens de sortie peuvent représenter une part plus importante de la facture que ne le laissent penser de courts prompts. Un modèle qui nécessite deux tours de correction peut coûter plus cher qu’un modèle dont le tarif par token est supérieur, mais qui produit un correctif fonctionnel en une seule passe. Les lectures depuis le cache peuvent modifier l’économie des entrées répétées, mais vérifiez que les entrées mises en cache sont bien indiquées dans l’utilisation avant de comptabiliser les économies.
Gardez le contexte ciblé. Ignorez la sortie du build, les dépendances, les snapshots générés et les packages sans rapport. Demandez à l’agent d’inspecter d’abord uniquement les fichiers probablement concernés. Cela réduit le nombre de tokens et améliore souvent l’attention. Consultez les recommandations sur le prompt caching pour les préfixes répétés et stables.
Avec quel modèle commencer ?
- GPT-6 Luna : une base peu coûteuse et pertinente pour les modifications courantes et bien délimitées. Consultez la page du modèle pour connaître le contexte et les fonctionnalités, puis faites passer les tâches qu’il échoue à un modèle supérieur.
- GPT-6.1 Sol : comparez-le sur les tâches où la planification et le raisonnement sur plusieurs fichiers sont importants. Dans cet instantané du catalogue, son tarif est inférieur à celui de GPT-6 Sol.
- GPT-6 Sol : conservez-le dans la matrice si vos prompts existants dépendent de son comportement ; utilisez les résultats mesurés pour décider si un changement est avantageux.
- Claude Sonnet 5.5 : incluez-le pour Claude Code et les workflows basés sur Messages. Son chemin d’exécution et la sémantique de ses outils diffèrent de ceux de Codex, basé sur Responses ; comparez donc les résultats plutôt que de faire comme si les clients étaient identiques.
Rendez la comparaison reproductible
Utilisez l’API compatible avec OpenAI avec une clé définie dans l’environnement pour les clients basés sur un SDK :
export GETVIBE_API_KEY="your-dashboard-key"
python - <<'PY'
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
result = client.chat.completions.create(
model="gpt-6-luna",
messages=[{"role": "user", "content": "Inspect src/parser.py and fix the failing edge case. Run the relevant test."}],
max_tokens=1200,
)
print(result.choices[0].message.content)
PYUtilisez le point de terminaison exact pris en charge par le client de l’agent. Pour Codex CLI, utilisez la configuration de l’API Responses ; pour Claude Code, utilisez la configuration Messages. Conservez les invites d’autorisation et exécutez les agents dans une branche afin de pouvoir examiner un diff concret.
Règle de décision
Choisissez le candidat le moins coûteux qui atteint votre objectif de taux de réussite et respecte votre budget de latence sur vos propres tâches de dépôt. Conservez l’ensemble d’évaluation fixe et relancez-le lorsque le catalogue, la version de l’agent ou le prompt change. Enregistrez la date, l’ID du modèle, l’utilisation et le résultat des tests pour chaque observation. L’instantané du catalogue du 3 octobre 2026 est accessible via les pages des modèles ; utilisez ces pages pour connaître les prix actuels plutôt que de copier des valeurs obsolètes dans une feuille de calcul.
Estimez le coût total d’une tâche
Pour la planification, séparez l’utilisation des entrées et des sorties. Si une tâche utilise 40,000 tokens d’entrée et 2,000 tokens de sortie, calculez chaque composante avec les tarifs actuels par million de tokens indiqués sur la page du modèle sélectionné, puis additionnez-les. Il ne s’agit que d’une base de référence : les entrées mises en cache, les frais minimums par requête, les multiples tours d’agent et les nouvelles tentatives peuvent modifier la facture réelle. Utilisez les détails d’utilisation après une exécution de test pour remplacer les estimations par les totaux observés.
Ne confondez pas la taille du contexte avec le nombre de tokens facturés. Le contexte maximal d’un modèle indique ce qu’il peut accepter, et non le coût de chaque requête. Empêchez l’agent de programmation de charger l’intégralité du dépôt lorsque seuls quelques fichiers sont pertinents. Un contexte sélectif améliore souvent la qualité des réponses et réduit le nombre de tokens envoyés.
Suivez les indicateurs de qualité qui influent sur le coût
Pour chaque exécution, indiquez si le correctif s’applique correctement, si les tests pertinents réussissent, combien d’appels d’outils échouent, combien de tours de correction ont lieu et si un reviewer accepte la modification. Un modèle qui nécessite de nombreuses nouvelles tentatives peut avoir un coût par modification acceptée supérieur, même si son tarif de tokens affiché est plus faible. La latence compte également : la route la plus lente peut convenir à un travail effectué pendant la nuit, mais pas à un éditeur interactif.
Faites la distinction entre les erreurs du modèle et celles du harness. Une commande de test manquante, un checkout obsolète ou un refus d’autorisation ne doit pas être considéré comme un échec de raisonnement. Conservez une trace avec l’ID de la tâche, l’ID du modèle, le SHA du dépôt et une catégorie d’erreur expurgée afin qu’une équipe puisse répéter la même comparaison ultérieurement.
N’utilisez un workflow à deux niveaux que si les données le justifient
Une stratégie de réduction des coûts consiste à essayer un modèle moins coûteux pour les modifications courantes et à faire remonter une tâche après un signal déterministe, tel que des tests en échec ou une sortie structurée non valide. Cela peut permettre d’économiser lorsque la plupart des tâches sont simples. Mais cette stratégie peut également ajouter un second passage complet avec le contexte pour les tâches difficiles. Mesurez le taux de remontée et l’utilisation combinée avant de la déployer.
Gardez la sélection du modèle de secours explicite dans la configuration de l’application. Si la reproductibilité est importante, indiquez quel modèle a traité chaque tâche. N’appelez pas silencieusement un autre modèle public tout en indiquant à un développeur que la modification provient du modèle initial.