Ploy, la plateforme qui construit des sites marketing avec un agent, a migré son système de Claude Opus 4.8 vers GPT-5.6 Sol. Les chiffres sur des charges de travail réelles : 2.2 fois plus rapide pour compléter une build, 27% moins cher, moitié moins de tokens de sortie. Ce n’était pas juste changer un nom dans la configuration.

L’équipe de Ploy documente les trois pièges d’une vraie migration : les appels tool avec 25 paramètres envoyés en intégralité même quand ce n’est pas nécessaire (Claude en envoie 2 ou 3, GPT-5.6 les remplit tous en inventant des valeurs), le prompt caching qui se comporte différemment entre les deux providers, et la relecture du raisonnement entre les tours qui change de stratégie. Chaque différence a exigé des modifications de leur suite d’eval avant même de toucher à l’agent.

Pourquoi ça vous concerne. Si vous avez un agent en production sur Claude et évaluez GPT-5.6, attendez-vous à des comportements différents masqués par le SDK universel. Le post est un guide de migration écrit par ceux qui l’ont vraiment fait, avec des traces complètes et des comparaisons côte à côte sur de vraies builds. Ce n’est pas un benchmark synthétique : c’est la même tâche (construire une homepage à partir d’une référence) exécutée par deux modèles, mesurée avec les mêmes critères, avec les différences documentées fichier par fichier.

En détail

Le contexte : quatre mois avec Opus comme défaut

Depuis mars 2026, Ploy a conservé Claude Opus comme modèle par défaut pour son agent de construction de sites. D’abord Opus 4.7, puis 4.8. Chaque version frontier était testée contre lui, et aucune ne tenait la comparaison sur leur charge de travail : construire des composants React, générer des images, faire des captures d’écran, décider quand le travail est terminé. GPT-5.6 a été le premier modèle à dépasser ce test.

Qu’est-ce qui a changé dans les chiffres

Le tableau que Ploy publie compare 11 builds complètes avec Opus contre 10 avec GPT-5.6, même suite de test. Coût moyen par build : de $3.06 à $2.22. Temps : de 8 minutes à 3 minutes et 42 secondes. Tokens de sortie : de 33.000 à 17.100. Le visual score (évaluation de design sur 10 critères binaires) augmente légèrement : 0.936 contre 0.970.

GPT-5.6 écrit du code plus compact : dans un cas comparé, Opus a produit un fichier CSS de 17.957 caractères avec 174 variables CSS (rampes de couleurs complètes, en grande partie inutilisées), GPT-5.6 a écrit 2.508 caractères et 45 variables pour une page rendue comparable.

Les trois pièges cachés

Appels tool avec tous les paramètres. L’outil code de Ploy a 25 paramètres de haut niveau, un obligatoire (action) et les autres optionnels. Claude n’envoie que ceux qu’il utilise. GPT-5.6 les envoie tous, à chaque fois, en inventant des valeurs plausibles pour ceux dont il n’a pas besoin : offset: 0, timeout: 120000, siteId: 00000000-0000-0000-0000-000000000000. Trois jours de traces en production : 6.635 appels code(read), tous avec 25 propriétés. Ce schéma a forcé Ploy à revoir la validation des arguments des tools.

Prompt caching différent entre providers. Ploy utilise le caching pour éviter de repasser la base de code entière à chaque tour. Anthropic et OpenAI implémentent cette fonction avec des règles différentes sur ce qui est caché et combien de temps ça dure. La migration a exigé de refaire les tests sur quand le cache hit se produit réellement, car les suppositions valides pour Claude ne tenaient pas avec GPT-5.6.

Relecture du raisonnement. Entre un tour et le suivant, l’agent doit voir son travail précédent pour décider de l’étape suivante. Claude tend vers une stratégie séquentielle (un fichier à la fois), GPT-5.6 émet des appels parallèles. Leur executor d’eval ne supportait pas les batchs de lectures de fichiers, quelque chose qu’Opus utilisait rarement et que GPT-5.6 utilise constamment. Environ un tiers des défaillances dans la première run cross-modèle traçaient vers des limites du test harness, pas du modèle.

Design : épuré, mais uniforme

L’équipe de Ploy remarque une convergence stylistique : GPT-5.6 produit des mises en page très épurées, modernes, à grille serrée, mais tend vers ce look à moins de direction explicite. Avec leur ancien harness conçu pour Opus 4.8, GPT-5.6 tendait à ignorer les design systems existants et à produire des outputs visuellement génériques, même s’ils étaient techniquement corrects. Ploy écrit que la solution mérite un post dédié, et qu’avec leur équipe de design ils ont réussi à obtenir une “conformité à la marque de niveau mondial qu’on n’obtient pas out of the box”.

Implications pour ceux qui évaluent une migration

Si vous utilisez Claude en production et regardez GPT-5.6, le takeaway de Ploy est clair : votre suite d’eval est accordée au modèle incumbent plus que vous ne le pensez. Budget d’appels tool dimensionné selon le style d’un modèle, executor qui suppose des comportements spécifiques, seuils invisibles hérités des défauts. Avant de faire confiance à un pass rate cross-modèle, triez les traces une par une. Sinon vous mesurez simplement à quel point le nouveau modèle imite l’ancien, pas à quel point il résout la tâche.

La migration a été complétée le 9 juillet 2026, et GPT-5.6 Sol est maintenant le défaut de chaque workspace Ploy. Le post original inclut des captures d’écran côte à côte des outputs réels et les tableaux complets des comparaisons.