Comparaison de quatre modèles de coding dans OpenFox : coûts, auto-vérifications et routage par agent

Déroulé structuré

Segment 1 — Comparaison pratique de quatre modèles de coding

Statut : information première main, benchmark anecdotique d’un seul développeur.

• Compare Kimi K3, Claude Opus 5, GPT 5.6 Sol et DeepSeek V4 Flash local sur trois tâches de coding via OpenFox et OpenRouter.
• Prix API rapportés par million de tokens : Kimi K3 3 $ entrée / 15 $ sortie, Claude Opus 5 5 $ / 25 $, GPT 5.6 Sol 5 $ / 30 $, DeepSeek V4 Flash 0,14 $ / 0,28 $ ; l’usage local de DeepSeek ne coûte rien au présentateur.
• Tâche 1 : page d’analyse de l’invalidation de cache à partir d’une capture SQLite session.db, avec prompt volontairement ambigu.
• DeepSeek a d’abord lu session.db, polluant son contexte ; après redirection, il a produit la solution attendue, mais via un file picker que l’auteur juge techniquement valide mais non déterministe.
• Kimi K3 a demandé des questions de clarification ; GPT 5.6 a demandé de valider des critères d’acceptation, puis les modèles ont ajouté des critères en mode planner.
• Contexte rapporté pour la tâche 1 : environ 12 000 tokens pour Kimi K3, 27 000 pour Opus 5, 20 000 pour GPT 5.6 et 58 000 pour DeepSeek après la lecture SQLite.
• Comportements d’auto-vérification non demandés : GPT 5.6 appelle un code reviewer puis un verifier pour les critères ; Kimi K3 et Opus 5 chargent une compétence navigateur et prennent des screenshots.
• Les trois modèles cloud voient les images ; DeepSeek ne le fait pas directement, OpenFox peut décrire les images via un autre modèle avec moins de précision.
• Budget OpenRouter de 9 $ épuisé : GPT 5.6 Sol a fait passer le solde à -0,20 $ ; la session Opus 5 aurait coûté 7,26 $ et la session GPT 5.6 complète 2 $.
• Résultats de la tâche 1 jugés par l’auteur : page fonctionnelle pour Kimi K3, mise en page moins dense pour Opus, résultat solide avec indicateurs d’alerte pour GPT 5.6, et DeepSeek réparé après correction.
• Préférence finale de la tâche 1 : Kimi K3 pour l’efficacité et le coût, alors que DeepSeek était d’abord classé premier.

Segment 2 — Mini-jeu hors-ligne en HTML5 Canvas

Statut : information première main, évaluation subjective.

• Demande un fichier HTML unique contenant un jeu de dinosaure hors-ligne en HTML5 Canvas.
• Kimi K3 a utilisé peu de contexte et a écrit le fichier rapidement ; Opus, GPT 5.6 et DeepSeek ont raisonné plus longtemps avant d’écrire ; Opus a rencontré des difficultés d’écriture de fichiers.
• L’auteur estime que les quatre modèles ont produit un jeu fonctionnel, mais classe GPT 5.6 comme le plus beau, Opus 5 comme le plus fluide et agréable, Kimi comme scintillant avec peu d’obstacles, et DeepSeek comme moins esthétique mais fonctionnel.
• Débits rapportés : environ 20 tokens/s pour Kimi K3 via API et environ 56 tokens/s pour DeepSeek V4 Flash local ; la lenteur de Kimi est attribuée en partie à une forte utilisation.

Segment 3 — Implémentation du modèle par agent dans OpenFox

Statut : information première main, travail de développement en cours / démonstration.

• Feature demandée : spécifier un modèle par agent ou sous-agent dans OpenFox.
• Conception : impact UX attendu sur le sélecteur de modèle ; gestion des agents personnalisés comme Planner Plus ; Kimi K3 évoque stockage en agent.md ou base de données utilisateur.
• L’auteur privilégie un stockage par utilisateur en base de données pour éviter de modifier un agent partagé commité pour tout le monde.
• Kimi K3 aborde le comportement de fallback si le modèle configuré est indisponible ; choix par défaut silencieux avec message visible dans le chat.
• DeepSeek V4 Flash propose une troisième approche UX : afficher le modèle associé à l’agent tout en permettant l’override UI ; l’auteur retient cette option.
• Workflow build-and-verify : DeepSeek capture la discussion dans des critères d’acceptation et utilise TDD.
• Incident : oubli d’isolation des workspaces, les deux agents écrivent dans le même dossier ; idée d’ajouter un avertissement automatique avant d’entrer dans un workspace partagé.
• La session Kimi K3 est finalisée par DeepSeek V4 Flash après épuisement des crédits API ; avantage multi-modèles et indépendance des providers.
• Bug infini d’appel frontend dans la version DeepSeek, corrigé ; comportement final : bascule du sélecteur quand un agent lié à un modèle est sélectionné et retour au modèle par défaut, non instantané.
• L’auteur mentionne un workflow possible avec un modèle fort pour la planification et un modèle local bon marché pour les changements, mais ne le recommande pas et ne l’utilise pas.
• Configuration OpenFox pour Moonshot/Kimi K3 : endpoints api.moonshot.ai/V1 ou coding/v1, 12 modèles, contexte réglable, température 1 et top_p 0,95 requis ; taux de cache élevé mais vitesse basse.

Segment 4 — Verdict pratique

Statut : opinion de l’auteur.

• Conserver DeepSeek V4 Flash pour le quotidien, estimé à 80-85 % du résultat à très bas coût.
• Réserver Kimi K3 aux bugs complexes que le local ne résout pas.
• L’épuisement répété des crédits cloud et la valeur du cluster DGX Spark local justifient ce choix dans l’expérience de l’auteur.

Points notables

• L’asymétrie de coût est centrale : les modèles API flagships peuvent épuiser un petit budget à cause du contexte verbeux, de l’usage d’images et des appels de vérification supplémentaires, tandis que le local DeepSeek coûte moins mais exige plus de redirection.
• La capacité du modèle est traitée comme indissociable du comportement du harnais : critères d’acceptation, auto-revue, screenshots navigateur, vérification par sous-agent et fallback multi-modèles affectent coût et fiabilité.
• L’usage du contexte varie fortement selon la tâche et les erreurs : Kimi K3 reste autour de 12 000 tokens sur la tâche 1, DeepSeek atteint 58 000 après la lecture non souhaitée de session.db.
• Le comportement de DeepSeek n’est pas présenté comme déterministe : il peut interpréter autrement la tâche, lire des fichiers non demandés ou produire une variante fonctionnelle non attendue.
• L’implémentation OpenFox introduit un choix de stockage, de fallback et d’override qui a des implications directes sur l’expérience utilisateur et l’isolation des workspaces.

Limites & biais factuels

• Benchmark anecdotique d’un seul développeur, sans protocole de mesure indépendant.
• Les prix, débits et comportements dépendent des versions de modèles, de la charge API et des paramètres OpenFox/OpenRouter.
• Les évaluations de qualité des sorties de code et du mini-jeu sont subjectives.
• Certains comportements, comme la lecture de session.db par DeepSeek ou les auto-vérifications, sont rapportés comme non déterministes.
• Les démos visuelles des pages, du jeu ou de l’interface sont signalées comme possibles dans le plan d’attention, mais leur existence effective n’est pas établie par les données fournies.