Meta lance Muse Ember : le million de jetons en entrée à partir de 0,10 $

Lorsqu'un agent lit plusieurs fichiers, choisit un outil et lance un test pour une simple petite correction, l'argent part à chaque étape intermédiaire. Quand ces étapes se comptent par milliers, le choix du modèle devient une question d'économie du produit. Meta a lancé Muse Ember précisément pour ce travail : appels d'outils, extraction de données, analyse de documents et petites tâches de code.

Le scénario pratique est simple : un modèle établit le plan de correction, tandis qu'Ember reçoit une mission distincte — trouver la fonction voulue ou préparer un petit correctif. Pour un développeur, c'est l'occasion de vérifier s'il est possible de réduire le coût des opérations répétitives sans multiplier les erreurs.

Ce que cache un jeton bon marché

Dans l'analyse de Simon Willison, les tarifs de base d'Ember, de GPT-6 Luna et de Claude Haiku 5.5 sont identiques : 0,10 $ par million de jetons en entrée et 0,50 $ par million en sortie. Sur une requête courte, la grille tarifaire seule ne permet pas de désigner un vainqueur.

La différence apparaît avec la croissance du contexte. Pour Ember, le seuil est de 200 000 jetons : au-delà, l'entrée coûte 0,30 $ par million et la sortie 1,50 $. Chez Luna, la hausse commence après 272 000 jetons, chez Haiku après 100 000. Les trois modèles prennent en charge un contexte allant jusqu'à un million de jetons, mais les règles de facturation diffèrent.

Prenons une requête théorique de 250 000 jetons en entrée et 10 000 en sortie, sans mise en cache. D'après le tableau fourni, Ember coûtera 0,09 $, Luna 0,03 $ et Haiku 0,15 $. Il s'agit d'un calcul pour un volume donné, et non d'une prévision de la dépense réelle : les modèles peuvent consommer un nombre différent de jetons pour une même mission.

Ainsi, charger tout un dépôt dans une seule requête est techniquement possible, mais l'intérêt économique d'une telle approche doit être calculé séparément. Il est parfois plus avantageux de sélectionner d'abord les fichiers utiles et de ne transmettre qu'eux au modèle.

Pourquoi le mode de raisonnement change la comparaison

Ember propose six niveaux de raisonnement, de minimal à max. Un mode plus élevé peut consommer plus de jetons, et un tarif identique ne signifie plus un coût identique pour le résultat. Dans un produit, c'est tout le parcours qui compte : première réponse, vérification, nouvelle tentative et éventuel transfert d'un cas complexe à un autre modèle.

Sur les graphiques du billet de Willison, Ember figure parmi les modèles offrant la combinaison la plus avantageuse entre résultat et coût de la tâche. Mais cette comparaison porte sur un ensemble de tests précis. La transposer à son propre service sans vérification serait précipité.

La source primaire contient aussi un détail important : Meta présente le coût d'Ember sur le graphique comparatif comme une estimation fondée sur les tarifs proposés. De plus, sur FrontierCode 2.0-AA, Ember obtient 27,2 % contre 34,9 % pour Haiku en mode maximal. Même parmi les résultats présentés, le meilleur dépend de la tâche. Ces réserves figurent dans l'annonce de Meta.

Willison a lui-même testé les niveaux de raisonnement avec son exercice habituel : dessiner un pélican à vélo en SVG. Le mode high n'a pas renvoyé un SVG complet, et l'augmentation du niveau n'améliorait pas l'image de façon constante. C'est une expérience isolée, mais un rappel utile : le réglage maximal ne garantit pas la meilleure réponse pour chaque mission.

Que vérifier avant l'intégration

Commencez par une seule étape répétitive de votre agent, par exemple l'extraction de champs dans des documents ou le choix d'un outil à partir d'une demande d'utilisateur. Rassemblez des exemples dont le résultat correct peut être vérifié, y compris des entrées longues et des cas ambigus.

Testez plusieurs niveaux de raisonnement et calculez le coût du résultat accepté. Notez en parallèle la latence, les erreurs de format, les appels répétés et la part des tâches qu'il a fallu transmettre à un modèle plus coûteux. Pour le code, ajoutez le taux de réussite des tests et le volume de corrections manuelles.

Pour un product manager, ce test répondra à une question concrète : combien coûte le traitement d'une demande ou la préparation d'une correction avec la qualité requise. Pour un fondateur, c'est une raison de recalculer le coût de revient d'une fonctionnalité. Ember mérite sa place dans une telle comparaison ; la décision de migrer doit reposer sur les résultats de votre propre flux de travail.