GitHub a rendu Copilot Fusion largement disponible, faisant passer le routage multimodèle d'un problème d'infrastructure au flux de travail de codage quotidien. Au lieu de demander à un développeur de sélectionner un modèle fixe, Fusion peut choisir et orchestrer un ou plusieurs modèles pour une requête.

La version compte au-delà de GitHub Copilot. Il montre comment un utilisateur peut soumettre une tâche pendant que le service prend plusieurs décisions de modèle sous-jacentes, générant potentiellement plusieurs appels facturés séparément. Cela change ce que les développeurs, les administrateurs et les systèmes de facturation doivent savoir à propos d'une demande : le modèle affiché dans l'interface n'est plus nécessairement une description complète de la façon dont le travail a été effectué.

Fusion peut sélectionner, cascader ou critiquer

GitHub documente trois modèles d'exécution pour Fusion. Une demande peut être adressée à un seul modèle sélectionné, parcourir une cascade de modèles ou utiliser un modèle pour critiquer le résultat d’un autre modèle. Les utilisateurs peuvent également choisir des niveaux d'effort Standard, Élevé ou Max, ce qui leur donne un certain contrôle sur le degré d'orchestration appliquée.

Il s'agit d'un changement de produit important, car le routage devient une partie de l'expérience de l'utilisateur final plutôt qu'une optimisation invisible derrière un fournisseur API. Une passerelle multimodèle API pour les équipes peut effectuer une sélection similaire au niveau de la couche application, mais Fusion place la décision dans un environnement de développement majeur et expose un contrôle des efforts directement au développeur.

Cette approche pourrait réduire la nécessité pour les utilisateurs de comprendre les points forts de chaque modèle disponible. Cela crée également un nouveau problème de diagnostic. Lorsqu'une réponse est lente, coûteuse ou incorrecte, les équipes doivent savoir si le résultat provient d'un seul modèle, d'une cascade ou d'une passe critique impliquant plusieurs modèles.

Une requête peut générer plusieurs frais

GitHub indique que chaque modèle utilisé par Fusion est facturé au tarif standard de ce modèle. Il a également annoncé une réduction temporaire de 30 % sur les coûts du modèle Fusion pour les forfaits payants, bien que l'annonce examinée ne précise pas quand cette réduction prendra fin.

Cette conception de facturation rend la trace d'exécution commercialement importante. Une seule action du développeur peut consommer plus de ressources qu'un appel direct à un modèle, même lorsque l'orchestration produit un meilleur résultat. Les équipes évaluant Fusion devront donc comparer le coût par tâche de codage terminée, et pas seulement le prix du jeton indiqué pour le premier modèle impliqué.

Le même problème s'applique à la facturation unifiée de l'IA API. Les enregistrements d'utilisation doivent identifier chaque appel de modèle sous-jacent tout en préservant la connexion à la demande originale de l'utilisateur. Sans cette relation, les administrateurs peuvent voir les frais du modèle, mais avoir du mal à expliquer quelle tâche les a générés ou si un paramètre d'effort a augmenté le coût.

Les politiques d'entreprise façonnent toujours la route

Les administrateurs d'entreprise et d'organisation peuvent restreindre les modèles que Fusion peut utiliser via les politiques de modèle existantes de GitHub. Cela donne aux entreprises un moyen d'exclure les modèles qui ne répondent pas aux exigences internes, mais cela signifie également que la même requête Fusion peut être acheminée différemment d'une organisation à l'autre.

Pour les responsables de l'ingénierie, la politique de modèle et la politique budgétaire doivent désormais être considérées ensemble. Autoriser un modèle coûteux dans le catalogue peut permettre à Fusion de l'invoquer dans le cadre d'une séquence multimodèle, et pas seulement lorsqu'un développeur le choisit explicitement. Les contrôles pratiques des dépenses de l'IA API pour les équipes doivent donc tenir compte de la profondeur de l'orchestration, du niveau d'effort et du coût total de tous les appels associés à une tâche.

Les opérateurs de passerelles sont confrontés à une exigence de reporting connexe. Les journaux doivent distinguer le modèle ou le mode demandé par l'utilisateur de chaque modèle qui a réellement répondu à la demande. Cette distinction prend en charge l'attribution des coûts, les enquêtes sur les incidents et les évaluations reproductibles lorsque le comportement de routage change au fil du temps.

Le routage local n'élimine pas les questions liées au cloud

GitHub a également introduit un aperçu expérimental qui peut effectuer le routage entre les modèles locaux et cloud éligibles. L'inférence locale peut fournir une autre option en termes de coût, de latence ou de traitement des données, mais le mot « local » ne décrit pas à lui seul le chemin de traitement complet. Les équipes ont encore besoin de clarté quant aux décisions de routage, aux invites, aux métadonnées ou aux appels de modèle de suivi qui restent dans les services cloud de GitHub.

Plusieurs détails restent en suspens. GitHub n'a pas spécifié la durée de la remise de 30 %, et ses comparaisons publiées de coûts et de performances avec Claude Code dépendent d'une configuration de référence particulière. Ces résultats ne doivent pas être traités comme des estimations universelles pour chaque référentiel ou charge de travail.

Le changement durable est architectural : l'orchestration des modèles devient une fonctionnalité standard des outils de développement. Dans ce cas, les enregistrements de routage transparents, la sélection de modèles tenant compte des règles et le reporting des coûts au niveau des tâches deviennent des éléments nécessaires du produit plutôt que des fonctionnalités d'observabilité facultatives.