Contexte et méthodologie
Le test porte sur la génération d’une page HTML autonome contenant un hangar spatial en Three.js, avec drones en lévitation, éclairage d’avertissement animé, bandes de piste émissives et brouillard volumétrique. Le prompt, reproduit ci‑dessous, est exécuté en mode /goal afin que le modèle produise le code complet sans itération supplémentaire.
Build a single-page Three.js sci-fi hangar with hovering drones, animated warning lights, emissive runway strips, and subtle volumetric-style fog planes. Include drone formation toggle and cinematic camera path. Output one self-contained HTML file with inline JavaScript.Chaque combinaison associe un modèle de génération (par ex. GLM 5.3 Flash Max) à un harness – interface qui orchestre l’appel API, la gestion du contexte et le comptage des tokens. Au total, dix configurations sont évaluées.
Mesures de performance
Les métriques collectées comprennent : le nombre total de tokens d’entrée (incluant le cache), le nombre total de tokens de sortie (code + raisonnement), la durée d’exécution mesurée en secondes, et le nombre d’erreurs d’outil (ex. appels de fonction échoués). Les colonnes reasoning et DSH durations sont spécifiques à certains harness : le premier indique la portion de tokens dédiée à la réflexion du modèle, le second cumule le temps actif des deux tours de génération, en excluant les pauses intermédiaires.
Les données montrent que le modèle GLM 5.3 Flash Max, lorsqu’il est couplé à un harness qui sépare explicitement le raisonnement, consomme environ 1 200 tokens d’entrée et 3 500 tokens de sortie, dont 800 tokens sont attribués au raisonnement. Le même modèle avec un harness qui ne segmente pas le raisonnement produit 3 200 tokens de sortie, sans colonne de raisonnement distincte.
Analyse des écarts entre harnesses
Les harnesses diffèrent principalement sur deux points : le comptage granulaire des tokens et la gestion du temps d’exécution. Un harness qui rapporte séparément le raisonnement permet d’isoler le coût cognitif du modèle, révélant que la phase de planification consomme près de 25 % du budget token total. En revanche, le DSH adapter ne fournit pas de comptage de raisonnement, ce qui rend impossible la comparaison fine du coût de la réflexion.
Sur le plan temporel, les durées varient de 12 s à 28 s selon la combinaison. Les harnesses qui agrègent les deux tours de génération affichent des durées plus élevées, mais la différence provient surtout de la prise en compte des pauses entre les tours. Les configurations sans pause affichent des temps d’exécution plus courts, ce qui peut être interprété comme une meilleure efficacité de pipeline, mais risque d’ignorer les latences réseau réelles.
Limites et perspectives
Le tableau de résultats comporte plusieurs tirets (« - ») indiquant des valeurs non disponibles ou non rapportées. Cette absence de données empêche une comparaison exhaustive, notamment sur les erreurs d’outil qui ne sont pas systématiquement enregistrées. De plus, le test se limite à un seul prompt ; la généralisation à d’autres scénarios Three.js (par ex. scènes plus complexes ou interactions utilisateur) reste incertaine.
En conclusion, le choix du harness influence fortement la visibilité des métriques de coût et de temps, alors que le modèle sous‑jacent (GLM 5.3 Flash Max) montre une consommation de tokens relativement stable. Une standardisation du reporting – notamment la séparation obligatoire du raisonnement et le suivi des pauses – permettrait d’affiner les comparaisons futures et d’optimiser les pipelines de génération de code Web.
