3,5× menos tokens y el mismo score: Toast 1 se queda con todo el loop de búsqueda de tu agente
El 13 de agosto Mixedbread lanzó Toast 1, un modelo entrenado para una sola cosa: buscar. No es un asistente general y no pretende serlo. Lo enchufas debajo del modelo que ya usas —Claude, GPT, lo que sea que corra tu agente— y se queda con todo el loop de retrieval: descompone la consulta en subqueries, junta evidencia, inspecciona las fuentes y devuelve el contexto ya curado.
El número del titular sale del benchmark LAB Firm Knowledge de Harvey: de 80,6M tokens a 23M, con el score sin moverse en 55. Mismo resultado, 3,5× menos tokens.
Antes de que reescribas tu stack alrededor de esa cifra, vale la pena leer despacio la tabla de donde sale. Porque ese 3,5× no es lo que hace Toast 1 por sí solo.
La tabla, leída fila por fila
Mixedbread corrió el benchmark en tres configuraciones. Esto es lo que publicaron:
| Configuración | Tokens | Turnos/tarea | Score |
|---|---|---|---|
| Agente vanilla | 80,6M | 21,7 | 55 |
| + Mixedbread Search | 47M (−42%) | 14,6 | 55 |
| + Toast 1 como subagente | 23M (−51% adicional) | 11,2 | 55 |
Fíjate de dónde vienen los ahorros. El primer corte —de 80,6M a 47M, la caída individual más grande de las dos— no tiene nada que ver con Toast 1. Viene de reemplazar el backend de retrieval por Mixedbread Search. Toast 1 entra recién en la tercera fila y aproximadamente parte a la mitad lo que quedaba.
Sigue siendo un número excelente. Pero cambia lo que la historia significa para ti: si no adoptas su capa de retrieval, la cifra realista con la que planificar está más cerca de 2× que de 3,5×. Mixedbread es directo sobre esto en el post — Toast 1 “was co-designed with Mixedbread Search’s primitives and will be at its strongest performance with it”, aunque sigue siendo “backend agnostic: it can run over your existing retrieval indexes”. Es decir: fue diseñado junto con las primitivas de Mixedbread Search y rinde al máximo con ellas, pero puede correr sobre tus índices actuales. Lee esa frase por lo que es: el 3,5× es un número de dos productos.
El conteo de turnos es la métrica que yo miraría con más atención que la de tokens, en realidad. De 21,7 a 11,2 turnos por tarea es el loop cerrándose en la mitad de las idas y vueltas, y los turnos son lo que sientes como latencia y lo que se rompe cuando una corrida larga del agente empieza a derrapar.
Una cosa que el post no define: sobre cuánto es un score de 55, ni qué mide exactamente. Es un benchmark de Harvey, no de Mixedbread, lo cual juega a favor — pero la escala absoluta no está en el post, así que “sin cambios en 55” te dice que no hubo regresión, no qué tan bueno era el baseline.
El segundo benchmark, que es el más interesante
Debajo del benchmark legal hay una corrida sobre OfficeQA Pro V2 (Databricks) que arma mejor el caso:
- GPT-5.6 Sol, solo: 33% de respuestas correctas
- Claude Fable 5, el mejor resultado previo: 60% a unos $4 por tarea
- GPT-5.6 Sol + Toast 1 dentro de Codex: 70% a unos $1,15–$1,20 por tarea
Esa es la forma interesante. El mismo modelo base pasa de 33% a 70% delegando la búsqueda, y le gana al mejor resultado previo a menos de un tercio del costo. Acá la historia no es “lo mismo por menos” — es “un modelo de costo medio más retrieval especializado le gana al modelo caro buscando por su cuenta”.
Los dos benchmarks son corridas del propio vendor. Mixedbread publicó el harness que usaron (mixedbread-ai/toast-harness, Apache-2.0), que es más de lo que hace la mayoría, pero todavía nadie reprodujo estos números de forma independiente.
Lo que cuesta, incluida la parte que no está en el titular
Precio de lanzamiento del modelo:
- $0,30 por millón de input tokens
- $0,036 por millón de cached input tokens (las escrituras de caché son gratis)
- $0,72 por millón de output tokens
Por query, Mixedbread reporta $0,016–$0,023 en una corrida estándar y $0,05–$0,07 en la configuración de fusion de alta calidad, con una latencia mediana de 8–11 segundos. Su comparación es contra agentes de retrieval basados en modelos frontier, que tardan entre 20 segundos y 4 minutos.
Ahora la aritmética que nadie pone en el post de lanzamiento. Toast 1 no solo reduce una factura — mueve una parte de ella a una línea nueva. Los tokens que dejas de pagarle a tu proveedor frontier vuelven como cargos de Mixedbread, y son más que solo el modelo:
- Indexing: $1,50 por millón de tokens (Fast) o $3 por millón (High Quality con OCR)
- Semantic search: $4 por cada 1.000 queries, $3,50 con reranking
- Storage: $0,50 por millón de content tokens al mes
Que el “>60% menos costo” se sostenga en tu workload depende de cómo caiga ese reparto. Un workload con un corpus grande y que cambia todo el tiempo paga mucho indexing para ahorrar poco en búsqueda; un corpus estable con mucho volumen de queries es donde los números funcionan. Haz esa cuenta con tus propios volúmenes antes de comprometerte — el benchmark tiene la forma de 33 tareas contra un corpus fijo, que es el caso amable.
Hay $5 en créditos al registrar una API key, suficiente para correr una evaluación real, y hasta $250 para startups con inversión de VC.
Ponerlo a andar
Tres puertas de entrada, de menos a más trabajo.
1. Activar un flag sobre un store existente
Si ya tienes documentos en un store de Mixedbread, la búsqueda agéntica es un booleano:
from mixedbread import Mixedbread
mxbai = Mixedbread(api_key="YOUR_API_KEY")
results = mxbai.stores.search(
query="What are the yearly numbers for 2020-2025?",
store_identifiers=["yearly-reports"],
search_options={"agentic": True},
)
El formato de respuesta es idéntico al de una búsqueda estándar, así que es un reemplazo drop-in — no tocas el código que consume los resultados. Bajo search_options.agentic hay dos campos opcionales:
instructions— guía en texto libre que se agrega al system prompt del agente, hasta 5.000 caracteresstrict_top_k— entruelimita los resultados a exactamentetop_kchunks; enfalsedeja que el agente devuelva todo lo que considere relevante
Por dentro corre subqueries en paralelo e itera hasta 4 rondas antes de entregar los resultados rankeados. La recomendación del propio Mixedbread vale la pena repetirla: esto es para consultas que abarcan múltiples entidades, años o fuentes, o donde una sola lista top-k se sigue perdiendo cosas. Para lookups puntuales, la búsqueda normal es más rápida y más barata. No lo actives de forma global.
2. Agregarlo a tu coding agent como skill
npx skills add mixedbread-ai/skills
El repo (Apache-2.0) funciona con Claude Code, Cursor, Codex, Gemini CLI y 20+ más a través del registry de skills. Trae cinco skills:
mxbai-cli— administrar knowledge bases, subir documentos y buscar desde la terminalmixedbread-search— construir y consultar knowledge bases gestionadas vía API/SDKmixedbread-parsing— extracción estructurada y OCRmixedbread-search-agent— Toast 1 a través de la Chat Completions APImixedbread-search-agent-harness— loops de búsqueda a medida
Este es el camino si lo que quieres es que tu coding agent deje de entrar en la espiral de grep y leer archivo tras archivo sobre un repo o un set de documentos grande.
3. Correr el harness tú mismo
pip install toast-harness
toast-harness es lo que Mixedbread usó para producir los números del benchmark, y es la pieza que yo instalaría primero si quisiera verificarlos. Expone herramientas de retrieval sobre un store de Mixedbread y maneja el loop del agente, funciona con cualquier modelo compatible con OpenAI, es async-native con una capa de compatibilidad síncrona y —el detalle que importa en esta historia en particular— hace conteo exacto de tokens en lugar de estimación por caracteres. Si vas a discutir una reducción de 3,5× en tokens, quieres que el contador sea exacto.
Necesita una API key de Mixedbread (MXBAI_API_KEY) y un endpoint compatible con OpenAI. Acepta clientes de retrieval y funciones de generación propias, que es la costura por donde lo apuntas a tu propio índice en vez del de ellos — y por lo tanto la forma de medir cuánto del 3,5× sobrevive sin Mixedbread Search debajo.
La apuesta que hay debajo
Toast 1 es una instancia de un patrón que aparece cada vez más: el modelo frontier es la forma más cara de hacer retrieval, y el retrieval es la mayor parte de lo que hace un agente durante todo el día. Un modelo grande buscando es un modelo grande gastando su context window en leer cosas que va a descartar, a tarifa frontier por token, para una tarea que no necesita razonamiento frontier.
Especializar esa capa es el mismo movimiento que ponerle un índice a una columna de base de datos. Solo rinde cuando lo estás haciendo mucho — que, si corres agentes sobre cualquier corpus real, es tu caso.
El contrapeso honesto: estás agregando un vendor al camino crítico de cada query de tu agente, los benchmarks son autoinformados, y el número más fuerte requiere adoptar también su backend de retrieval. Los $5 de crédito y el harness abierto existen justamente para que lo pruebes contra tu corpus en vez del de ellos. Haz eso antes de recablear nada.
¿Alguna vez mediste qué fracción de los tokens de tu agente se va en buscar y cuánta en razonar? Cuéntanos en los comentarios, sobre todo si probaste separar el retrieval en un modelo aparte y no te terminó rindiendo.