Meta lanza Muse Ember: desde $0,10 por millón de tokens de entrada

Cuando un agente lee varios archivos, elige una herramienta y ejecuta una prueba para hacer un pequeño cambio, cada paso intermedio cuesta dinero. Si esos pasos se cuentan por miles, elegir un modelo se convierte en una cuestión de economía del producto. Meta ha lanzado Muse Ember precisamente para ese trabajo: llamadas a herramientas, extracción de datos, análisis de documentos y pequeñas tareas de programación.

Un caso práctico es sencillo: un modelo elabora el plan de corrección y Ember recibe un encargo concreto, como encontrar la función adecuada o preparar un pequeño parche. Para los desarrolladores, es una oportunidad de comprobar si pueden reducir el gasto en operaciones repetitivas sin aumentar los errores.

Qué hay detrás de los tokens baratos

En el análisis facilitado de Simon Willison, las tarifas base de Ember, GPT-6 Luna y Claude Haiku 5.5 coinciden: $0,10 por millón de tokens de entrada y $0,50 por millón de tokens de salida. En una solicitud corta, la lista de precios por sí sola no permite elegir un ganador.

La diferencia aparece a medida que crece el contexto. El umbral de Ember es de 200.000 tokens: por encima, la entrada cuesta $0,30 por millón y la salida, $1,50. En Luna, el aumento comienza después de los 272.000 tokens; en Haiku, después de los 100.000. Los tres modelos admiten un contexto de hasta un millón de tokens, pero lo cobran con reglas distintas.

Tomemos una solicitud hipotética con 250.000 tokens de entrada y 10.000 de salida, sin caché. Según la tabla presentada, Ember costaría $0,09; Luna, $0,03; y Haiku, $0,15. Es un cálculo para un volumen determinado, no una previsión del gasto real: los modelos pueden consumir cantidades distintas de tokens para un mismo encargo.

Por tanto, cargar todo el repositorio en una sola solicitud es técnicamente posible, pero su rentabilidad debe calcularse por separado. A veces resulta más económico seleccionar primero los archivos necesarios y enviar solo esos al modelo.

Por qué el modo de razonamiento cambia la comparación

Ember tiene seis niveles de razonamiento, de minimal a max. Un nivel más alto puede consumir más tokens, de modo que una tarifa idéntica deja de significar un coste idéntico por resultado. En un producto importa todo el proceso: la primera respuesta, la comprobación, el reintento y la posible derivación de un caso difícil a otro modelo.

En los gráficos del artículo de Willison, Ember figura entre los modelos con la mejor relación entre resultados y coste por tarea. Pero esa comparación se basa en un conjunto concreto de pruebas. Extrapolarla a un servicio propio sin comprobarla sería precipitado.

También hay un detalle importante en la fuente original: Meta presenta el coste de Ember en el gráfico comparativo como una estimación basada en las tarifas propuestas. Además, en FrontierCode 2.0-AA, Ember obtiene un 27,2%, frente al 34,9% de Haiku en su nivel máximo. Incluso dentro de los resultados presentados, el líder depende de la tarea. Estas salvedades aparecen en el anuncio de Meta.

El propio Willison probó los niveles de razonamiento con un encargo habitual: dibujar un pelícano en bicicleta en SVG. El modo high no devolvió un SVG completo y subir el nivel no mejoró la imagen de forma constante. Es un experimento aislado, pero deja un recordatorio útil: el ajuste máximo no garantiza la mejor respuesta para cada encargo.

Qué comprobar antes de integrarlo

Empiece por una etapa recurrente de su agente. Por ejemplo, extraer campos de documentos o elegir una herramienta a partir de una solicitud del usuario. Reúna ejemplos cuyo resultado correcto pueda verificarse, incluidos casos con entradas largas y situaciones ambiguas.

Pruebe varios niveles de razonamiento y calcule el coste de un resultado aceptado. Registre también la latencia, los errores de formato, las llamadas repetidas y la proporción de tareas que hubo que derivar a un modelo más caro. Para el código, añada la superación de las pruebas y la cantidad de correcciones manuales necesarias.

Para un responsable de producto, esta comprobación responde a una pregunta concreta: cuánto cuesta procesar una solicitud o preparar un cambio con la calidad requerida. Para un fundador, ofrece una base para recalcular el coste de una funcionalidad. Ember merece un lugar en esa comparación; los resultados de su propio flujo de trabajo deben determinar la decisión de cambiar.