Agents de codage soucieux des coûts : quand le délestage vers des modèles moins onéreux est pertinent

Équipe de recherche CyberShell

Rapport technique

Un rapport technique de l'équipe de recherche CyberShell sur le délestage d'agents de codage vers des modèles moins coûteux, le routage de modèles, l'exécution validée par vérificateur et les compromis coût-performance en pratique.

Alexandre

Expert en la matière

Contexte

Les modèles de codage de pointe sont de plus en plus performants — et de plus en plus coûteux. Cette expérience pose une question pratique : dans quelle mesure pouvons-nous réduire le coût du travail des agents de codage en utilisant DeepSeek V4 Pro, et qu'obtenons-nous à ce prix réduit?

Nous avons confié les trois mêmes tâches Terminal-Bench à Codex propulsé par DeepSeek V4 Pro et à Codex propulsé par GPT-5.6 Sol.

Ce que cette expérience évalue

Il s'agit d'une comparaison de systèmes complets d'agents de codage, et non d'un classement de modèles seuls. Chaque système comprend Codex, sa boucle d'outils, le harnais d'évaluation, la voie d'inférence, le modèle et la configuration de raisonnement ou d'agent retenue.

L'expérience compare trois conditions :

• DeepSeek V4 Pro x-high, agent unique : Codex passe par Moon Bridge, OpenRouter et Together jusqu'à DeepSeek V4 Pro 0813, avec les fonctions multi-agents désactivées.
• DeepSeek V4 Pro Ultra : la même voie protégée, avec le niveau de raisonnement le plus élevé disponible et le mode multi-agents de Codex.
• GPT-5.6 Sol Ultra : Codex utilise l'API native d'OpenAI avec le niveau de raisonnement le plus élevé disponible et le mode multi-agents.

Nous avons ainsi obtenu un modèle à moindre coût sans faire transiter nos données de test par un point de terminaison exploité par DeepSeek.

Méthodologie

Nous avons utilisé les trois mêmes tâches du commit Terminal-Bench 2.0 69671fba, avec Codex CLI 0.147.0 et Harbor 0.20.0. Les conteneurs, les vérificateurs, les limites et les délais d'expiration sont restés constants.

Chaque tâche a été exécutée une seule fois, de façon séquentielle, dans une session isolée, sans nouvelle tentative. La recherche Web et MCP étaient désactivés. Avant chaque tâche, nous avons vérifié le modèle demandé, le niveau de raisonnement et — sur la voie DeepSeek — que Together était bien le fournisseur.

Les vérificateurs officiels des tâches déterminaient la réussite. Les durées couvrent l'exécution de bout en bout; les coûts proviennent de la consommation du solde OpenRouter ou de l'utilisation de jetons GPT.

Les trois tâches d'évaluation

Résultats par harnais et par agent

Chaque tâche s'est déroulée dans sa propre session d'agent racine. Le nombre de sous-agents correspond au total des lancements sur l'ensemble des tâches, et non au nombre maximal exécuté simultanément.

Résultats et conclusions

DeepSeek x-high est une option de délestage économique viable lorsque la latence est flexible

La comparaison la plus nette oppose les deux configurations qui ont réussi toutes les tâches. DeepSeek x-high a pris 35 min 17 s, contre 16 min 03 s pour GPT-5.6 Sol Ultra, soit environ 2,2 fois plus de temps.

Son coût s'est élevé à 0,252382 $, contre 3,200433 $ pour GPT, soit environ 12,7 fois moins cher, ou une réduction des coûts de 92,1 % lors de cette exécution.

Ce compromis est intéressant lorsque le travail n'est pas urgent, que la tâche est de complexité facile ou moyenne, que ses données peuvent être confiées à un sous-traitant externe et qu'un test ou un vérificateur déterministe peut détecter les échecs.

Parmi les exemples : l'entretien encadré de dépôts, la conversion de données, la génération de tests, la transformation de documentation et d'autres travaux pouvant être mis en file d'attente. Une politique de production pragmatique acheminerait d'abord les tâches admissibles vers DeepSeek x-high protégé, puis transférerait à GPT les échecs et le travail sensible à la latence.

La conclusion doit rester prudente. Trois tâches à tentative unique ne suffisent pas à établir un taux de qualité général, et fix-git était classée comme facile. L'expérience démontre la faisabilité et l'intérêt économique, et non une équivalence générale entre les systèmes.

GPT-5.6 Sol Ultra a été le plus rapide et a obtenu le seul résultat Ultra de 3/3

GPT a été la condition la plus rapide et la seule condition Ultra à réussir les trois tâches. Il a aussi lancé sept sous-agents, alors que les deux configurations DeepSeek sont restées de fait à agent unique.

Dans cette expérience, le surcoût de GPT de 2,948051 $ par rapport à l'exécution DeepSeek réussie a permis d'obtenir le délai d'achèvement le plus court et un résultat de 3/3. Cette prime peut se justifier pour du travail urgent ou pour des flux de travail où un premier essai raté coûte cher.

Pour une longue file de tâches non urgentes et vérifiables de façon indépendante, l'écart de coût favorise nettement DeepSeek.

Pourquoi DeepSeek V4 Pro Ultra a échoué

DeepSeek Ultra n'a jamais créé le fichier requis /app/regex.txt .

Sur regex-log, il est entré dans une génération d'outils incontrôlée et a construit des commandes shell et Python en ligne extrêmement volumineuses — environ 104 Ko et 58 Ko lors de l'exécution initiale. Deux réponses ont indiqué exactement 65 536 jetons de sortie, et les chaînes et heredocs obtenus étaient incomplets.

Codex a ensuite signalé des arguments d'appel de fonction mal formés — EOF while parsing a string — et sa requête de récupération s'est terminée par une erreur HTTP 400, Server tool request failed.

Les contrôles de routage eux-mêmes ont fonctionné : l'essai a utilisé Together, le modèle exact DeepSeek V4 Pro 0813 et le paramètre d'effort transmis max. Les deux autres tâches Ultra ont réussi, et aucun sous-agent n'a été lancé.

Une reprise diagnostique ultérieure, exclue du tableau comparatif, a échoué à la même tâche selon le même schéma de génération surdimensionnée, bien qu'elle se soit terminée par un délai d'expiration plutôt que par la même erreur HTTP 400.

À l'inverse, x-high a réussi regex-log avec la même version de Codex, le même modèle, la même voie Together, la même politique OpenRouter, le même Moon Bridge et le même vérificateur, tout en produisant des commandes de l'ordre de quelques kilo-octets plutôt que de dizaines de milliers de caractères.

Les éléments recueillis ne permettent pas d'imputer la faute à un seul composant :

• Le comportement de DeepSeek ou du fournisseur est le déclencheur probable. Le contenu répétitif surdimensionné est arrivé dans la sortie d'appel d'outil de l'assistant en amont. Toutefois, aucun contrôle direct auprès du fournisseur n'a été effectué; cette expérience ne peut donc pas distinguer DeepSeek lui-même de l'implémentation Responses de Together/OpenRouter.
• Codex a révélé l'échec, mais n'en était probablement pas la source initiale. Codex a correctement rejeté un JSON d'appel de fonction incomplet. Son mécanisme de récupération a ensuite reçu l'erreur HTTP 400.
• Moon Bridge est une cause possible, mais relativement peu probable. Sur cette voie Responses, Moon Bridge relaie la réponse en amont sans transformer les arguments de fonction. Un défaut de la passerelle ne peut être exclu sans un contrôle direct d'OpenRouter vers Codex.
• La combinaison compte. X-high et Ultra ne différaient pas seulement par un réglage de calcul standardisé. Ultra annonçait aussi des outils multi-agents, même si aucun sous-agent n'a été lancé.

Le prochain test devrait relancer regex-log avec Codex directement sur le même point de terminaison OpenRouter/Together protégé, en retirant Moon Bridge du chemin. Si l'échec persiste, un test d'API contrôlé devrait comparer le mode en continu (streaming) et le mode sans continu, puis faire varier le niveau de raisonnement indépendamment du mode multi-agents.

Recherches futures

Avant de concevoir un codec de confidentialité sur mesure, nous devrions d'abord tirer le maximum des protections natives d'OpenRouter. Cela signifie tester et documenter les listes d'autorisation de modèles et de fournisseurs les plus strictes qui restent utiles, l'application de la ZDR, la désactivation des replis, les restrictions de collecte de données et les contrôles de dépenses par clé.

Les contrôles natifs sont plus simples à auditer et à maintenir qu'une nouvelle couche de transformation.

Si nous testons plus tard un point de terminaison direct vers un modèle à moindre coût, une piste de recherche serait un codec de confidentialité avec état à la frontière du flux. Avant que le contenu sortant n'atteigne le point de terminaison, le codec pourrait remplacer les secrets, les URL privées, les noms d'hôte internes, les identifiants de compte et d'autres valeurs sensibles par des jetons opaques stables, puis inverser les substitutions dans le flux entrant.

Il devrait gérer les valeurs réparties sur plusieurs fragments, empêcher les collisions d'espaces réservés ou la falsification de jetons, préserver suffisamment de syntaxe pour les tâches de codage, garder les correspondances hors du contexte visible par le modèle et échouer de façon sécuritaire (fail closed) lorsque la classification est incertaine.

Ce codec réduirait les divulgations accidentelles, mais il ne rendrait pas un fournisseur non fiable sûr pour du code propriétaire arbitraire.

Sources

• Terminal-BenchTerminal-Bench 2.0 commit 69671fba
• OpenRouterProvider routing
• OpenRouterGuardrails
• OpenRouterZero Data Retention
• Together AIPrivacy and security