Claude Sonnet 5.5 vs Kimi K3 : aucun des deux modèles ne prendra votre réglage de température

Voici une comparaison où les deux modèles s'accordent sur un point qui cassera votre code dans tous les cas. Claude Sonnet 5.5, publié le 28 septembre 2026, rejette toute requête qui définit temperature, top_p ou top_k à une valeur non par défaut, avec une erreur 400. Kimi K3, disponible en général auprès de Moonshot AI depuis la mi-juillet 2026, n'accepte aucun paramètre d'échantillonnage — pas de temperature, pas de top_p, pas de seed — et n'expose la profondeur de raisonnement que via un contrôle reasoning_effort. Deux laboratoires différents, deux architectures différentes, une conclusion commune : les réglages d'échantillonnage que la plupart des intégrations définissent encore par habitude ont disparu chez les deux.

Ce n'est pas la comparaison sur laquelle tout le monde écrit. La comparaison sur laquelle tout le monde écrit, c'est le prix : Kimi K3 à 3 $ par million de tokens d'entrée et 15 $ en sortie, face à Claude Sonnet 5.5 à 2 $ et 10 $, ce qui est une victoire sans ambiguïté pour Anthropic sur la grille tarifaire. Mais Kimi K3 est un modèle à poids ouverts de 2 800 milliards de paramètres, de type mélange d'experts, que vous pouvez télécharger et exécuter à l'intérieur de votre propre périmètre, et Claude Sonnet 5.5 est un modèle fermé disponible sur quatre clouds. Entre un modèle fermé moins cher et un modèle téléchargeable plus cher, la décision ne se prend pas du tout sur le prix par token.

Ce que chacun est, en un paragraphe chacun

Claude Sonnet 5.5 est le deuxième modèle de la génération 5.5 d'Anthropic, arrivé sur l'API Claude cinq jours après le lancement de Claude Opus 5.5. Il est proposé sous le nom de claude-sonnet-5-5 sur l'API Claude, Amazon Bedrock, Google Cloud et Microsoft Foundry, conserve une fenêtre de contexte de 1 M de tokens et un plafond de sortie synchrone de 128 K, et reprend exactement la tarification de Claude Sonnet 5 : 2 $ en entrée, 10 $ en sortie, 0,20 $ par million pour les lectures de cache. La réflexion adaptative est activée par défaut au niveau d'effort high. Il est disponible sans rétention de données, et Artificial Analysis lui attribue un Intelligence Index de 56 dans sa révision v4.3.2 — troisième sur les 216 modèles qu'elle mesure.

Kimi K3 est le fer de lance de Moonshot AI : un modèle à mélange d'experts de 2,8 billions de paramètres, activant environ 104 milliards de paramètres par token, avec une fenêtre de contexte d'un million de tokens et une compréhension visuelle native. Il est conçu pour le codage à long horizon et le travail de connaissance en plusieurs étapes, et Moonshot le positionne explicitement pour les harnais d'agents de programmation. Il utilise le format d'API OpenAI, expose reasoning_effort comme son unique contrôle de raisonnement, et ses poids sont ouverts sous la licence Kimi K3 — ce qui n'est pas la même chose que de l'open source, et c'est cette différence qu'il faut lire avant de construire quoi que ce soit dessus.

La grille tarifaire, et le numéro en dessous.

Comparez les deux sur les dimensions qui déterminent une facture plutôt qu’un gros titre :

• Prix d'entrée — Claude Sonnet 5.5 2 $ par million vs Kimi K3 3 $ par million

• Prix de sortie — Sonnet 5.5 $ par million vs Kimi K3 15 $ par million

• Lectures du cache — 0,20 $ par million contre 0,30 $ par million

• Fenêtre de contexte — 1 000 000 jetons contre 1 048 576 jetons

• Poids — propriétaires, quatre plateformes hébergées vs open-weight sous la licence Kimi K3

• Indice d’intelligence — Claude Sonnet 5.5 56 contre Kimi K3 44 sur la même révision v4.3.2

• Coût par tâche de l'Intelligence Index — Claude Sonnet 5.5 : 7,60 $ contre Kimi K3 : 2,00 $

• Verbosité sur l’Index — Claude Sonnet 5.5 410 M de tokens de sortie vs Kimi K3 160 M

Cette dernière paire est le renversement qui mérite qu’on s’y attarde. Le modèle d’Anthropic est 50 % moins cher en entrée et un tiers moins cher en sortie, et coûte pourtant 3,8 fois plus cher pour terminer la même évaluation, parce qu’il dépense 2,6 fois plus de tokens pour y parvenir. Sur le composite, il obtient aussi douze points de plus, donc ce n’est pas un cas où un modèle gaspilleur n’apporterait rien. C’est le cas de deux modèles dont le comportement en matière de coûts ne peut pas être comparé en lisant deux grilles tarifaires, d’où l’existence du chiffre de la tâche d’index.

Aucun de ces deux décomptes de jetons ne correspondra à votre décompte de jetons. La documentation de Moonshot indique elle-même que la profondeur de raisonnement de K3 est définie par reasoning_effort plutôt que par l'échantillonnage, et il en va de même, en pratique, pour le paramètre effort de Claude Sonnet 5.5 — ainsi, sur les deux modèles, le levier le plus important sur votre facture est un réglage d'effort, non une négociation de prix.

Les erreurs 400, en détail

Le refus partagé des paramètres d’échantillonnage est le recoupement le plus pratique ici, car c’est la défaillance qui se manifeste le lendemain matin d’un changement de modèle.

Sur Claude Sonnet 5.5, les règles sont explicites et impitoyables. Une valeur non par défaut de temperature, top_p ou top_k renvoie une 400. Envoyer thinking: {"type": "disabled"} renvoie une 400 pointant vers between_tools, le nouveau paramètre de réflexion le plus bas, qui est accepté aux efforts faible, moyen et élevé, mais rejeté à xhigh ou max. L'utilisation forcée d'outils — tool_choice défini sur "any" ou sur un outil nommé — renvoie une 400 avec le message « tool_choice: type \"tool\" and \"any\" are not supported for this model », et le correctif consiste à utiliser auto, plus l'utilisation stricte d'outils ou des sorties structurées. Plus encore : les blocs de réflexion sont désormais liés au modèle et au compte qui les ont produits, de sorte qu'une conversation peut être déplacée de Claude Sonnet 5 vers Sonnet 5.5 avec son raisonnement intact, mais ne peut pas transférer ce raisonnement vers une autre famille de modèles, et un préfixe modifié peut transformer un rejeu en une 400.

Sur Kimi K3, la surface est plus petite, mais les conséquences sont similaires. Il n’y a aucun paramètre d’échantillonnage à envoyer, donc tout client qui en code un en dur envoie déjà un paramètre que le modèle ne lit pas. La profondeur de raisonnement est plutôt un champ de premier niveau reasoning_effort à la place.

Les deux changements vont dans le même sens : l’approche par bouton déterministe pour le contrôle des prompts est remplacée par un cadran d’effort du côté du modèle. Tout pipeline qui se réglait lui-même avec une température de 0,2 et une graine fixe doit être réajusté par niveau d’effort sur ces deux modèles, et ce réajustement constitue la migration.

Ce que les poids ouverts vous apportent réellement ici

La raison d’envisager Kimi K3 face à un modèle fermé moins cher et mieux noté n’est ni la capacité ni le prix. C’est la frontière.

Exécuter K3 au sein de votre propre infrastructure signifie que les prompts, les documents et les sorties ne quittent jamais un réseau que vous contrôlez, ce qui pose une question de conformité différente de celle d’un accord de rétention zéro des données avec un fournisseur. Cela signifie aussi que le modèle ne peut pas être déprécié sous vos pieds — Claude Sonnet 5.5 s’accompagne d’un engagement de retrait d’Anthropic pas avant le 28 septembre 2027, et un checkpoint téléchargé n’a pas une telle date. Et cela signifie que la courbe des coûts marginaux s’aplatit : après le matériel, les tokens sont gratuits, ce qui est la seule structure dans laquelle un modèle de 2 800 milliards de paramètres devient un jour l’option bon marché.

La licence est ce que vous signez réellement. Kimi K3 est à poids ouverts, et non open source, et Moonshot n’utilise pas ce dernier terme. La licence Kimi K3 est permissive pour la plupart des usages, mais une activité de modèle en tant que service dépassant un seuil de chiffre d’affaires glissant nécessite un accord commercial distinct, et les produits dépassant des seuils élevés d’utilisateurs ou de chiffre d’affaires doivent afficher la mention « Kimi K3 ». Le qualifier de sous licence MIT est une inexactitude de l’ère K2 qui circule encore. Si vous prévoyez de construire sur les poids plutôt que d’appeler l’API, il s’agit d’un examen juridique, et non d’une simple note de bas de page.

Et les poids sont suffisamment volumineux pour que l'auto-hébergement constitue une décision d'investissement. Un MoE de 2,8 T de paramètres avec environ 104 Md de paramètres actifs n'est pas un déploiement sur un seul serveur, et l'effort nécessaire pour le mettre en place représente le véritable coût de cette option — un coût qui éclipse la différence de 5 $ par million sur les tarifs de sortie.

Où OrcaRouter s'intègre

La plupart des équipes qui évaluent ces deux options ne veulent pas choisir entre une API managée et un approvisionnement matériel. Elles veulent router.

OrcaRouter est un point de terminaison compatible OpenAI donnant accès à plus de 200 modèles, avec le prix catalogue du fournisseur répercuté sans marge, de sorte qu'un changement de tarif chez un fournisseur, d'un côté comme de l'autre, est appliqué le jour même plutôt qu'au cycle de facturation suivant. Kimi K3 figure au catalogue depuis juillet, au tarif propre à Moonshot de 3 $ / 15 $, avec un temps mesuré jusqu'au premier token (p50) d'environ huit secondes et environ 371,9 millions de tokens traités au cours de la dernière semaine. Claude Sonnet 5 — le modèle sur lequel passe encore l'essentiel du trafic de l'API Claude, à 150 tokens de sortie par seconde en mesure — est routable depuis le 30 juin, au tarif d'Anthropic de 2 $ / 10 $.

Claude Sonnet 5.5 n'est pas encore dans notre catalogue. Lorsque c'est le cas, dites-le et contournez le problème : l'API du fournisseur lui-même est la voie d'accès, et le moyen de le tester sans engagement est un pourcentage de trafic derrière un basculement automatique, avec Claude Sonnet 5 ou Kimi K3 comme solution de repli. Si ce qui vous pousse à examiner K3 est la limite plutôt que le tarif, les poids sont téléchargeables dès aujourd'hui et l'API est une solution provisoire — ce qui relève d'une décision concernant votre infrastructure, et non d'une comparaison de modèles.

Le verdict, décomposé selon ce que vous achetez réellement

Choisissez Claude Sonnet 5.5 lorsque le travail se fait à contexte long et à forte production de sortie, lorsque ce qui est acheté, ce sont douze points d’indice composite, et lorsqu’une API gérée avec zéro rétention des données passe votre évaluation. Prévoyez un budget pour la consommation de tokens — 410M de tokens sur l’Index contre 160M pour K3, c’est un véritable multiplicateur — et prévoyez une journée pour les changements liés à l’utilisation d’outils et aux blocs de réflexion.

Choisissez Kimi K3 lorsque la frontière est l’exigence, lorsque vous voulez un point de contrôle qu’aucun fournisseur ne peut retirer, ou lorsque votre charge de travail est du codage agentique à haut volume, où 2,00 $ par tâche d’indexation contre 7,60 $ se cumulent. Acceptez qu’il s’agit d’un modèle de 2,8 T de paramètres à héberger, que sa licence comporte des clauses d’attribution et de revenus, et qu’il obtient un score inférieur à celui de la gamme Anthropic sur le composite.

Ce à quoi aucun des deux choix n'échappe, c'est le premier paragraphe : les paramètres d'échantillonnage ont disparu dans les deux cas, et le réglage de l'effort est le contrôle qui les a remplacés. Quel que soit celui que vous choisissez parmi ces deux-là, c'est le changement dont votre code a besoin.