Modèles budget vs premium sur du PHP/TypeScript réel

Mise à jour juillet 2026 — Le setup décrit ici (Kilo Gateway, MiniMax 2.5) date de cette période et n’est plus mon quotidien — je suis revenu à Claude Code (abonnement Max, voir Anthropic, le Apple de l’IA). Le principe de routing par type de tâche, lui, tient toujours.

Depuis que j’ai migré vers Kilo Code CLI (un fork d’OpenCode) avec Kilo Gateway, j’utilise MiniMax 2.5 et Claude Sonnet en parallèle sur le même projet Symfony/TypeScript, en routant les sessions selon la nature de la tâche. Voici ce que cette comparaison en conditions réelles produit comme données — pas des benchmarks HumanEval, des livrables que des collègues ont reviewé sans savoir quel modèle les avait générés.

Le contexte de comparaison

Projet : application Symfony 7 + API Platform 3 côté backend, TypeScript React 18 côté frontend. Environ 80k lignes de code existant, base de tests PHPUnit + Vitest. Les sessions se font via Kilo Code CLI avec Kilo Gateway pour les modèles gratuits et l’API Anthropic pour Sonnet.

Méthodologie empirique : on observe si la PR review signale des problèmes inhabituels selon le modèle utilisé.

Là où les modèles budget sont indistinguables de Sonnet

Tests unitaires PHPUnit

C’est la tâche où la différence est la plus insignifiante. MiniMax 2.5 comprend les patterns PHPUnit, génère des data providers corrects, mocke les dépendances de façon cohérente avec le pattern MockObject du projet. Le taux de corrections en review est comparable à Sonnet.

// Exemple de test généré par un modèle budget — indistinguable d'un test Sonnet
// sur ce type de tâche structurée
public function testCalculateDiscountWithExpiredCoupon(): void
{
    $coupon = $this->createMock(Coupon::class);
    $coupon->method('isExpired')->willReturn(true);

    $this->expectException(ExpiredCouponException::class);
    $this->calculator->calculate(100.0, $coupon);
}

Fixtures Doctrine

Génération de fixtures de test pour des entités avec des relations — le modèle budget suit les conventions du projet aussi bien que Sonnet. Même résultat, coût nul via Kilo Gateway.

DTOs et Value Objects

Les structures typées sans logique complexe. MiniMax produit du PHP 8.3 propre (readonly, named arguments, types union), respecte les annotations de sérialisation Symfony existantes.

Migrations de refactoring mécanique

Renommages de méthodes en masse, ajout de types à des signatures existantes, extraction d’interfaces depuis des classes concrètes quand le pattern est évident.

TypeScript côté frontend

Types, interfaces, hooks React standards, composants sans logique métier complexe. Les modèles budget connaissent bien le TypeScript moderne et les patterns React — le résultat est propre.

Là où Claude Sonnet garde une avance réelle

Debugging de comportements inattendus

C’est la catégorie où la différence est la plus marquée. Quand un service produit des résultats incohérents selon le contexte — un cas de race condition, un problème de cache Doctrine, un comportement d’API Platform qui dépend du groupe de sérialisation actif — Sonnet trouve plus vite et avec plus de précision.

Les modèles budget identifient souvent la zone du problème mais proposent des solutions qui corrigent les symptômes plutôt que la cause. C’est suffisamment fréquent pour qu’on ait établi une règle : debugging non trivial → Sonnet directement.

Refactoring avec contraintes d’interface

Quand on doit refactoriser un service en conservant des contraintes multiples et parfois contradictoires — interface publique inchangée, compatibilité avec 3 consumers existants, pas de régression sur les tests d’intégration — Sonnet gère mieux la complexité des contraintes simultanées. Les modèles budget ont tendance à optimiser pour une contrainte au détriment d’une autre.

Architecture et conception

“Propose une architecture pour découpler le module de paiement de celui de notification sans casser l’interface existante” — Sonnet produit une proposition plus nuancée, qui intègre mieux les contraintes implicites qu’on n’a pas formulées.

Code legacy complexe

Sur du code vieilli avec des conventions mixtes et des couplages non documentés, Sonnet comprend mieux le contexte implicite.

L’impact concret

Sur une semaine de dev type, le ratio de sessions par type :

Tâches mécaniques (tests, DTOs, migrations)  : ~65% des sessions → MiniMax 2.5 (gratuit via Kilo Gateway)
Tâches de contexte long (modules entiers)    : ~20% des sessions → Gemini Flash
Tâches de raisonnement (debugging, archi)   : ~15% des sessions → Claude Sonnet

Avec Kilo Gateway, les 65% de tâches mécaniques ne coûtent rien. La facture se résume aux sessions Sonnet et Gemini Flash.

Ce que ce n’est pas

Ce n’est pas un argument pour toujours utiliser le modèle le moins cher possible. Le routing intelligent, c’est l’inverse de la frugalité aveugle — c’est dépenser exactement ce que la tâche justifie, ni plus ni moins.

Ce n’est pas non plus un benchmark définitif. Les modèles évoluent vite. Ce qui est vrai aujourd’hui peut ne plus l’être dans six mois. La bonne habitude est de tester périodiquement, pas de graver une décision dans le marbre.

Ce que c’est : la confirmation empirique que le coût d’inférence est une variable qu’on peut optimiser sans sacrifier la qualité — à condition de router consciemment plutôt que d’utiliser le même modèle pour tout.

Ce routing change de nature quand ce n’est plus une facture perso à optimiser mais un budget d’équipe à répartir. La question n’est plus “quel modèle coûte le moins cher” mais “où est-ce qu’on met de la qualité maximale, et où est-ce qu’on accepte un modèle économique” — pas de compromis sur les tâches à risque (auth, paiement, migrations de données), modèle économique assumé sur le boilerplate. Une politique de routing explicite, écrite quelque part, vaut mieux que chaque dev qui arbitre seul dans son coin.

→ Guide : optimiser les coûts de son workflow IA