Voxtral 3: Mistral lanza SDK de voz con 50+ idiomas
Mistral acaba de poner en la misma canasta transcripción, síntesis de voz y llamadas a herramientas: antes había que coser tres productos distintos para armar un agente que atienda una llamada real. Con Voxtral 3, la empresa francesa anuncia una familia de modelos de habla y un SDK que promete resolver ese problema en un solo flujo en tiempo real, con soporte para más de 50 idiomas.
El lanzamiento llega en un momento en que contact centers, asistentes virtuales y copilotos de manos libres compiten por el mismo mercado: agentes que escuchen, razonen y actúen sin fricciones perceptibles para quien llama.
TL;DR
- Mistral lanzó Voxtral 3, un SDK de agentes de voz con modelos STT y TTS en más de 50 idiomas.- Voxtral Small Transcribe 3 supera a Whisper, Scribe v2 y Gemini 3.5 Transcribe en precisión multilingüe.- El modelo Mini de transcripción tiene 4.000 millones de parámetros y cuesta $0,0035 por minuto.- Pro Voice clona el estilo de un hablante con solo 30 minutos de audio.- Disponible vía API alojada en la UE o para despliegue en infraestructura propia.
Qué es Voxtral 3
Voxtral 3 es la nueva familia de modelos de voz de Mistral AI, compuesta por un modelo de transcripción (speech-to-text), uno de síntesis (text-to-speech) y un SDK de agentes que une ambos con razonamiento y llamadas a herramientas. Está pensada para construir agentes conversacionales en tiempo real que escuchan, interpretan intención, hablan con naturalidad y ejecutan acciones en sistemas conectados, con despliegue tanto en la nube europea de Mistral como en infraestructura propia.
Qué pasó
Mistral presentó Voxtral 3 como respuesta a un problema que la propia empresa describe en su anuncio oficial: construir un agente de voz confiable exige que cuatro capacidades funcionen simultáneamente en tiempo real. Escuchar con precisión en distintos idiomas y acentos, razonar sobre lo que el usuario realmente quiere, hablar con expresividad natural y ejecutar acciones de varios pasos sobre sistemas conectados.
Hasta ahora, cada una de esas piezas se resolvía con un producto distinto. Un motor de transcripción por un lado, un sintetizador de voz por otro, y una capa de orquestación hecha a medida para conectar ambos con la lógica de negocio. Voxtral 3 empaqueta las tres cosas (escucha, razonamiento con llamadas a herramientas, y habla) en un único pipeline de streaming.
El ejemplo que Mistral usa en su demo es elocuente: una paciente llamada Béatrice dicta un número de referencia médica en francés, el agente lo transcribe, llama a una función get_referral para recuperar la carta de derivación, se la explica en inglés y agenda la cita con una llamada a book_appointment. Todo en la misma conversación, sin que el usuario perciba el cambio de tarea.
Contexto e historia
Mistral viene posicionándose como alternativa europea a los grandes laboratorios de IA de Estados Unidos, con un énfasis constante en soberanía de datos. Cada lanzamiento reciente de la compañía repite el mismo argumento: ofrecer la opción de procesar información dentro de la infraestructura del cliente, sin que los datos salgan de la Unión Europea si así se decide.
La voz es, en ese sentido, un terreno especialmente sensible. Las llamadas de un contact center o un servicio de salud contienen información personal que muchas organizaciones no quieren que termine en servidores de terceros fuera de su jurisdicción. Voxtral 3 se apoya en ese argumento: la API alojada por Mistral está en la UE, y la alternativa de autodespliegue da control total sobre dónde se procesa el audio y si se retiene o no.
Voxtral Small Transcribe 3 cubre 50 idiomas, incluidos los 24 oficiales de la UE.
Detalles técnicos
El corazón de Voxtral 3 son dos modelos con funciones complementarias. Voxtral Small Transcribe 3 es el modelo de transcripción, y según los benchmarks publicados por Mistral en el anuncio, supera a Whisper large-v3, Scribe v2, GPT Transcribe y Gemini 3.5 Transcribe en precisión multilingüe medida con tasa de error de palabra (WER) sobre el benchmark FLEURS. Mistral reporta un WER macro-promedio de 4,1% para la versión Small, frente a cifras de entre 4,5% y 16% para los modelos rivales en la misma comparación de 45 idiomas.
La clave técnica no es solo la precisión bruta sino tres funciones que hacen viable el producto en producción. La primera es la diarización, que identifica quién habló y cuándo dentro de una misma grabación, algo imprescindible en llamadas de atención al cliente con múltiples interlocutores. La segunda es el context biasing: se le puede pasar al modelo una lista de términos técnicos o nombres propios del dominio (marcas, códigos de producto, nombres de medicamentos) para que el modelo les dé prioridad al transcribir, sin necesidad de reentrenarlo. La tercera es la detección de fin de turno, que decide cuándo el usuario terminó de hablar para que el agente responda sin demora, sin cortar la frase ni dejar un silencio incómodo.
Del lado de la síntesis, Voxtral Mini TTS 3 soporta más de 35 idiomas y más de 50 dialectos, y ajusta emoción, ritmo y énfasis según el contexto de la conversación. Mistral también ofrece Pro Voice, un modo de adaptación de voz pensado para casos profesionales donde el clonado básico no alcanza: reproduce el carácter distintivo, el rango emocional y el estilo de habla de una persona real usando apenas 30 minutos de audio como referencia, incluso en idiomas distintos al original.
La variante Mini del modelo de transcripción tiene 4.000 millones de parámetros, lo que permite transcripciones rápidas a un costo de $0,0035 por minuto de audio según los datos publicados por Mistral. Ese tamaño reducido es la diferencia entre correr el modelo en un servidor de contact center con decenas de líneas simultáneas o necesitar una granja de GPUs dedicada solo para escuchar.
> 💭 Clave: el context biasing resuelve en configuración lo que antes exigía fine-tuning: pasarle al modelo los términos del dominio en texto libre, sin reentrenar nada.
El SDK de agentes es la pieza que conecta todo. En vez de encadenar un servicio de STT, pasar el texto a un LLM separado y luego mandar la respuesta a un motor de TTS (con la latencia acumulada de cada salto), Voxtral 3 corre escucha, razonamiento, llamadas a herramientas y habla dentro del mismo stream en tiempo real. El agente puede interrumpir, retomar el hilo y ejecutar una función a mitad de conversación sin que el usuario perciba una pausa de procesamiento.
El costo de hacerlo todo junto
Esa integración tiene un precio de diseño: cuantas más capacidades corren en el mismo pipeline, más difícil es diagnosticar dónde falla una conversación cuando algo sale mal. Un error de diarización puede propagarse y hacer que el modelo de razonamiento interprete mal quién dijo qué, lo que a su vez dispara una llamada a herramienta incorrecta. Separar los componentes facilita el debug; unificarlos reduce la latencia pero exige observabilidad fina en cada etapa del stream.
Impacto y análisis
El caso de uso que Mistral exhibe (contact centers, mesas de servicio, asistentes virtuales y copilotos de manos libres) apunta directo al mercado que hoy dominan proveedores como OpenAI con su API de voz en tiempo real y ElevenLabs con sus modelos de síntesis. La diferencia que Mistral quiere marcar no es solo técnica sino regulatoria: para una empresa europea sujeta al RGPD, poder desplegar el modelo de voz en su propia infraestructura, sin que el audio salga nunca de su red, es un argumento comercial tan fuerte como el benchmark de WER.
La cobertura de idiomas es otro punto a favor concreto. Voxtral Small Transcribe 3 cubre 50 idiomas, incluidos los 24 oficiales de la Unión Europea y varias lenguas asiáticas e índicas de bajos recursos, donde los modelos de transcripción suelen rendir peor por falta de datos de entrenamiento. Para un contact center que opera en varios países europeos a la vez (algo común en banca, seguros o telecomunicaciones), tener un único modelo que cubra francés, español, alemán, polaco y rumano con precisión comparable es más valioso que un modelo excelente solo en inglés.
El riesgo, como con cualquier sistema de agentes de voz con llamadas a herramientas, es la superficie de ataque que se abre cuando un agente puede ejecutar acciones reales (reservar una cita, mover dinero, modificar un registro) a partir de una instrucción hablada. Cuanto más autónomo es el agente, más importa validar cada llamada a función antes de ejecutarla, algo que Mistral no detalla en profundidad en el anuncio más allá de mencionar la integración con sistemas propios del cliente.
Qué sigue
Mistral ya habilitó Voxtral 3 tanto en su API alojada en la UE como para autodespliegue, según el anuncio oficial. La compañía no publicó una hoja de ruta pública de próximas versiones, pero el patrón de sus lanzamientos anteriores sugiere iteraciones rápidas sobre precisión de transcripción y ampliación de idiomas soportados, en línea con lo que hizo con su familia de modelos de texto.
El verdadero examen va a ser la adopción en producción: cuántas empresas eligen correr el modelo en su propia infraestructura en vez de depender de la API alojada, y si la propuesta de soberanía de datos convence a organismos reguladores de sectores sensibles como salud o banca.
📖 Resumen en Telegram: Ver resumen
Probalo vos: revisá la demo interactiva y la documentación del SDK en la página oficial de Voxtral 3 antes de decidir si migrás tu pipeline de voz.
Preguntas frecuentes
¿Qué idiomas soporta Voxtral 3?
El modelo de transcripción de Voxtral 3 cubre más de 50 idiomas, incluidos los 24 oficiales de la Unión Europea y varias lenguas asiáticas e índicas de bajos recursos. El modelo de síntesis de voz soporta más de 35 idiomas y más de 50 dialectos.
¿Voxtral 3 se puede desplegar fuera de la nube de Mistral?
Sí. La familia Voxtral 3 está disponible tanto a través de la API alojada por Mistral en la Unión Europea como para autodespliegue en infraestructura propia, lo que permite controlar dónde se procesa el audio y si se retiene.
¿Qué diferencia a Voxtral Small Transcribe 3 de Whisper?
Según los benchmarks de Mistral sobre el conjunto FLEURS, Voxtral Small Transcribe 3 obtiene una tasa de error de palabra menor que Whisper large-v3, Scribe v2, GPT Transcribe y Gemini 3.5 Transcribe en una comparación de 45 idiomas compartidos.
¿Qué es el context biasing en los modelos de habla de Mistral?
Es la capacidad de pasarle al modelo de transcripción una lista de términos técnicos o nombres propios en texto libre para que les dé prioridad al reconocer el audio, mejorando la precisión en vocabulario de dominio específico sin reentrenar el modelo.
¿Cuánto cuesta transcribir audio con el SDK de voz de Mistral?
La variante Mini del modelo de transcripción, de 4.000 millones de parámetros, cuesta $0,0035 por minuto de audio según los datos publicados en el anuncio oficial de Mistral.
Referencias
- Mistral AI: Voxtral 3: anuncio oficial del lanzamiento, benchmarks de transcripción y detalles del SDK de agentes de voz.- Mistral AI: sitio oficial de la compañía desarrolladora de la familia Voxtral.- Mistral AI en GitHub: repositorios públicos y herramientas relacionadas con los modelos de Mistral.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Mistral Large 4 Benchmark for Coding vs DeepSeek V4.1 Flash
Mistral Large 4 scored 0.5462 on our Gauntlet benchmark, 28th of 44. About a third of what it lost came from a check of ours that read its table the wrong way round. All 12 amounts it put on screen were correct. I went in expecting to write about a slow, expensive model, and on our Forge benchmark that part holds up.
If you pay for a coding agent, this model is pitched at your budget. Mistral released Large 4 on 6 October as a Public Preview, 1.05 trillion parameters with 52 billion active and a 1M-token context, at half its list price for the first two weeks. Their launch post puts it ahead of DeepSeek V4 Pro on their own Coding Agent Index (49.8%), which is the kind of claim that moves a budget, so we ran it through both of our agentic coding benchmarks. The Gauntlet has an agent build a payments console with two services and a 3D view inside 150 model calls, then scores it on 99 checks. Forge 2.0 asks for a v2 upgrade of a working Jira Forge app inside 300 calls and scores it on 105 checks against three seeded Jira sites.
Getting a Gauntlet score took four attempts. The first, on 9 October, ended after 49 calls on OpenRouter's "Upstream idle timeout exceeded". On 18 October the second was ended by Mistral's servers. Early on 19 October the third was ended by a bug in goose, the open-source coding agent we run (our own fork), and the fourth finished that afternoon. Its Forge 2.0 pair scored 0.1086 and 0.3304 for at least $10.95. DeepSeek V4.1 Flash 1017 did better on the same Forge task. It's the 17 October snapshot I wrote about in my DeepSeek piece, and it scored 0.2422 and 0.6618 for at least $0.62 in about a quarter of the time.
On the Gauntlet the low score is mostly our scorer's fault. On Forge the code losses were Mistral's own. Our harness also gave it a smaller context window than DeepSeek. The build trees show where each loss came from. This is one scored Gauntlet run and one Forge pair, in our setup, on a model whose vendor says it can change silently while it's in preview.
Mistral Large 4 benchmark results: Gauntlet 0.5462, Forge 2.0 median 0.2195
| | Mistral Large 4 | DeepSeek V4.1 Flash 1017 |
|---|---|---|
| Gauntlet 7.2 | 0.5462, 144 min, $4.93 | 0.6957, 23 min, $0.21 |
| Forge 2.0 build 1 | 0.1086, 118 min, at least $5.40 | 0.2422, 28 min, $0.30 |
| Forge 2.0 build 2 | 0.3304, 106 min, $5.55 | 0.6618, 30 min, at least $0.32 |
| Unscored Gauntlet attempts | 9 Oct: idle timeout after 49 calls, at least $1.43. 18 Oct: Mistral 503 after 30 calls, at least $1.18. 19 Oct: our 400 after 97 calls, $3.04 | none |
I checked these on the live boards on 21 October; if a run page says something else now, trust the run page. All six Mistral runs together cost at least $21.53, with three of the bills only lower bounds.
Six things we found in the Mistral Large 4 builds
1. The x0.6 "wrong money" critical on the Gauntlet is our bug. Our money check compares the amounts on screen with the oldest 50 payments, and Mistral's table opens on the newest.
2. Mistral's money formatter works on integer digits with a per-currency decimals table, the same approach as DeepSeek's.
3. Forge build 1, by my reading, lost most of its gap to build 2 to a throttle it wrote itself: it booked 25 to 34 times the real cost of a list call and paused its own scheduled work each hour, before its v1 migration could run.
4. Neither Forge build ever displayed its admin page, and neither ran a browser self-test.
5. The 18 October attempt opened with one 37,853-word thought that ran 18 minutes, hit a 65,536-token output limit and was thrown away.
6. Mistral's API refused a message order that three other providers' endpoints had answered, through OpenRouter, in our runs two weeks earlier.
Mistral Large 4 on our Gauntlet: 0.5462, about 0.70 without a check of ours that misread its table
Most Gauntlet checks just add to a weighted average, but a handful are critical, and when one of those fails it multiplies the whole score down, by as much as x0.6. Wrong money in a payments console is one of those. The money check is called b_money_rendered. A browser probe reads the amount cell of the first 12 rows of the payments table. Then the scorer checks that the digits match a stored amount and that the decimals match the currency, because amounts are stored as integers in the currency's smallest unit (cents, or fils for the Kuwaiti dinar). A correct cell shows two decimals for EUR and USD, none for yen and three for dinars. Mistral's run scored 0.00 on it, with the detail line "0.00 of 12 cells exponent-correct; JPY/KWD traps 0.00", and the multiplier took the whole run from 0.9104 down to 0.5462.
What Mistral rendered
These are the 12 cells the probe read, verbatim: KWD 111.000, ¥594, ¥199, $4.47, ¥809, €224.00, KWD 82.400, €33.10, KWD 2.420, ¥1,060, $1,840.00, KWD 72.400. Our probe also records each row's id, and joined to the fixture, pay_12287 is stored as KWD 111000, so 111.000 dinars is right, and pay_12286 is JPY 594, which needs no decimals. All 12 are right. So are the probe's 12 extra rows.
Its formatter in web/app.js (lines 7 to 25, with the source's \u escapes shown as characters) never touches a float:
const CUR = {
EUR: { sym: '€', exp: 2 },
USD: { sym: '$', exp: 2 },
JPY: { sym: '¥', exp: 0 },
KWD: { sym: 'KWD ', exp: 3 },
};
...
const s = String(a).padStart(exp + 1, '0');
const int = s.slice(0, s.length - exp) || '0';
const frac = exp > 0 ? s.slice(s.length - exp) : '';
It planned this before writing it. At 10:58 our time (EEST), 27 minutes in, it checked the contract's example and two real payments in its thinking: "129900 EUR → €1,299.00 ✓; JPY 8564 → ¥8,564 ✓; KWD 8263000 → KWD 8,263.000 ✓". Our scorer's own screenshot of the inspector shows that dinar payment as KWD 8,263.000, and the inspector check (q_payment_context) passed.
Why the check said zero
Here is the scorer, score_sb7.py around line 973:
first_page = c.pack.payments[:50]
by_cur: Dict[str, set] = {}
for row in first_page:
by_cur.setdefault(row["currency"], set()).add(row["amount_minor"])
payments is stored in date order, so payments[:50] is pay_00000 to pay_00049, the oldest fifty. A rendered cell only passes if its digits equal one of those fifty amounts, so the check assumes, without saying it, that the table opens oldest first. Mistral's opens newest first (sort: '-created_at', web/app.js:49). None of its 12 cells could ever match. Our probe even collects the row ids "so the scorer can join against fixtures", in its own comment. No scorer file reads them.
I re-graded the run with the scorer's own _money_ok function, copied unchanged. It gives 0.0 as written, 1.0 against the 50 rows actually on screen, and 24 of 24 when each cell is joined to its payment by row id.
Was opening newest first a mistake by Mistral? Its contract fixes the API's default order ("created_at (default, ascending by INSTANT)") and says the Date header toggles, but it never says which way the table starts. Mistral saw the gap and decided, at 11:48 our time: "The grader might check the first page shows specific rows? Unlikely to assume an order. I'll default to '-created_at' (newest first) — most console-like." It bet that the grader would not assume an order, and the grader did. You can argue the UI should inherit the API's default. I'd listen. Even then it's a sort-order quibble. The check charged it as wrong money.
Who did better at money
All five models I compared passed with 1.0: Claude Opus 5.5, Claude Sonnet 5.5, GPT-6.1 Sol (the model behind Jev Router's top Forge score), GPT-6.1 Sol Pro and DeepSeek V4.1 Flash 1017. All of them open their table with sort: 'created_at', and so does our own reference app, which is why our release validation never met a descending default. Grade those five tables against the newest 50 payments and four score 0.0, Sol 0.05.
DeepSeek's formatter is close to a copy of Mistral's:
let digits = String(Math.abs(minor));
if (exponent > 0) digits = digits.padStart(exponent + 1, '0');
const whole = exponent > 0 ? digits.slice(0, digits.length - exponent) : digits;
Same idea, same output. It got 1.0 and Mistral got 0.0. Sol and Sol Pro call Intl.NumberFormat and divide the integer by 10**exp first, and Sonnet does the same with Math.pow, which is fine for amounts this size. So on money code it's a tie between Mistral and DeepSeek. The sort order made the difference.
Mistral did leave one real money bug, in its own test. Its browser self-test checks the first amount against /^[€$¥]\d[\d,]*\.\d{2}$|^KWD [\d,]+\.\d{3}$/, which would reject a correct ¥594 because it demands two decimals after a yen sign. It printed "PASS money formatted" four times, and my guess is that its own first row was never a yen payment. I can't see which row it was.
Without our false critical: about 0.70 and 11th of 44
The score path for this run goes like this. Its checks earned 0.9104. Our false critical multiplied that by 0.6, to 0.5462. Separately, a run that fails some of the 3D checks gets a ceiling on its score, and Mistral's partial failures on picking, the coasting camera and the overview's legibility set it at 0.709. The ceiling formula keeps a score just under the cap, so without the false critical the run would come out at about 0.7048. That's my arithmetic, not a re-score. The board still says 0.5462. It would sit 11th of 44, two places above DeepSeek 1017's 0.6957. The 3D failures, which are Mistral's own, cost it about 0.2 on top.
My audit of that check turned up a second flaw. The yen and dinar "traps" score 0 when no yen or no dinar row happens to be among the cells the probe reads (up to 12). A run whose visible amounts are all right can still pay x0.92. Four ranked runs paid it that way: Elorian Glimpse, Step 5 Preview, Qwen3.8 Omni Flash and GLM-5.3. Across every Gauntlet 7.2 build I could reach, Mistral is the only one the sort assumption hit.
Is Mistral Large 4 good for coding? Forge 2.0 builds of 0.1086 and 0.3304
Forge 2.0 tests the same habits harder: the agent reads a long spec, upgrades a working Forge app under a Jira rate model, and has to prove it all in a local sandbox (our Forge emulator kit) before the calls run out. My piece on the September DeepSeek V4.1 Flash covered this same task, with medians of 0.33 for it and 0.67 for Opus 5.5 in an earlier comparison group. Both Mistral builds and DeepSeek 1017's pair are in the same comparison group on our board. That means the same task, seeds, scorer and engine build. All four asked for the same effort setting.
A Forge 2.0 score is the earned score times a critical multiplier times a reliability factor, where reliability starts at 1 and loses up to 10% for each group of checks whose worst check failed, with a floor of 0.25. Build 1 sat on that floor (its unfloored product was 0.2194) and build 2 came out at 0.4718. Neither triggered a critical. My reading is that most of the 0.22 gap comes from build 1's throttle and the order it ran its migration in.
Build 1 throttled itself and never migrated
The task gives each Jira site a rate budget of 2,400 points an hour, and background work may use 70% of it, so 1,680. Build 1 wrote a gate for that in src/dose.js (lines 76 to 88):
if (dose.bg + estimatedCost > limit) {
const untilMs = hourStartOf(now) + 3600000;
await kvs.set(PAUSE_KEY, { untilMs });
throw new QuotaPaused(untilMs);
The gate is fine. The estimates feeding it were not. With no points header from the site, it charged its own counter from guesses. It booked 51 points for a board or sprint list page (src/config.js:43, cost: 1 + 50), 105 for a search and 260 for a changelog bulk fetch. On the scoring site its first scheduled run had counted 1,567 points after 21 seconds. The next estimated call would have taken it past 1,680. So it paused for the rest of the hour. Yet the site's own ledger for that run says it had spent 715 points over 27 requests, with list pages costing 1.5 to 2 points each.
That would only have been a nuisance if the migration ran first. It ran last. reconcile() in src/index.js calls reconcileAll, then saveClosed, then migrateV1Rows, and the pause in the first step skipped the rest. Its rescan had no cursor. Each hour it started over and paused in the same place. Our scorer's verdict reads "0/130 historical changes v1 never recorded" and "h2: 0 of 59 v1 rows in scope-ledger", and it traces 15 checks to that one root cause.
On the development site, which our spec gives the same shape on another seed, the gate tripped too, twice. At 21:19 our time it wrote "The reconcile hit my own dose gate". After a reset one run got through and it reported "migration complete (88/88)".
Build 2 got the same thing right. I think it was more luck than design. Its cost counter under-counted instead (its own words near the end: "my costOf under-counts returned records"). It ran over the background share in 4 of 31 hours, and on our scoring sites it never paused early. In its last minutes its own dev run did pause early. At call 300 of 300 it spotted the ordering problem: "I'm at the call budget (300/300) — this is my final turn". Then it moved the migration to the top with the comment "it is the graded deliverable and needs the fewest points". It never ran that version. It still scored 59 of 59 migrated and 130 of 130 backfilled. DeepSeek 1017's build 2 had that ordering from the start (src/sync.js:409, "Migrate v1's rows first").
Neither build displayed its admin page
Both Mistral builds score 0.00 on the admin panel tier. That one failure takes down the panel labels, the CI web trigger (no secret can exist before the panel's Rotate button creates one) and the admin boot check with it. Build 1's src/frontend/admin.jsx ends with export default AdminPage; and never calls ForgeReconciler.render, so UI Kit had nothing to draw. It found that out at 21:39, on the 298th of its 300 calls, when its only admin-page test printed "(nothing rendered)". Build 2 does call ForgeReconciler.render(<App />) at line 197, and the non-admin view displayed its permission message, but the admin view came back as an empty tree. The probe recorded no error that explains it. And build 2 never ran the kit's UI Kit check on that page.
DeepSeek 1017's build 2 renders the same way (admin.jsx:186) and ran that UI Kit check 14 times before it finished. The habit shows in the counts too: DeepSeek's two builds invoked their resolvers in the sandbox 45 and 30 times, Mistral's 3 and 4, and neither Mistral build ran a browser self-test at all. Build 1 also sent 37 of its 355 tool calls, about one in ten, to a bash tool that doesn't exist (goose's is called shell), and build 2 sent 19 of 344.
Build 2 had good moments. It had the highest UI-function (0.9957) and reconcile (0.9974) tiers of the four builds in this comparison group. Both are small tiers. Both also beat an Opus 5.5 build from an earlier group. In its last ten minutes it noticed that v1's React bundles were 244 KB against a 150 KB boot budget. It rewrote all three Custom UI pages in plain DOM, to between 102 and 106 KB each.
Mistral Large 4 vs DeepSeek V4.1 Flash 1017: 27 minutes to the first file against 2
Time is where the two models differ most. Mistral's first app-code write came 32, 35 and 27 minutes into its three Gauntlet attempts of 18 and 19 October, and about 49 and 55 minutes into its Forge builds. DeepSeek 1017 wrote its first app file 2.4 minutes into its Gauntlet run and about 4.5 minutes into each Forge build, and it finished both Forge builds with 29 to 37 calls to spare. Mistral ran out of calls in both.
Its median call took 4.5 to 4.8 seconds on Forge against DeepSeek's 4.0. The typical call barely differs. The slow tail is what costs it. Each Mistral run had calls that took 11 to 18 minutes, and in the Gauntlet attempts the calls over five minutes add up to more than half of all the time the model spent answering. DeepSeek's slowest call in any of its three runs took 71 seconds, and across our runs Mistral generated between 55 and 70 tokens a second while DeepSeek managed 108 to 155.
The 18-minute thought that was thrown away
The 18 October attempt that Mistral's servers later ended opened with one thinking call of 37,853 words that ran 1,081 seconds. It was coherent (under 1% of its 12-word sequences repeat). It covered the money rule, the 3D tower heights and the order of the services. Then it stopped at exactly 65,536 output tokens. goose marked the reply as cut off, and nothing in it was carried out. Its next thought: "Let me continue. I was planning extensively. Time to write code." goose sent no max_tokens and our model limits list 262,144 output tokens, so the 65,536 cap came from the serving side. Whether that's OpenRouter or Mistral, our logs don't show.
Reasoning was 57% to 81% of everything it generated, depending on the run. On Forge both builds also compacted their context three times, once the prompt had grown to between about 170,000 and 210,000 tokens. After most compactions it re-read files it had already read ("I need to re-read the v1 sources and my v2 files"). Build 2's own compaction summary says it plainly: "I've spent ~66% of context on exploration; no code".
Those compactions are partly ours. goose gave Mistral a usable window of 262,144 tokens. It took the smallest Mistral endpoint's 524,288 (the EU one) and reserved half of it for output, on a model whose card says 1M, while DeepSeek got 655,360. At about 200,000 tokens a call, DeepSeek would have compacted too under Mistral's limit, and under its own it never did. The summary calls ran about 9 to 11 minutes per Forge build, inside the times charged to Mistral.
What did the long thinking buy? On the Gauntlet, quite a lot: its plans got the money rule right, and its decisions file is careful (a rejected draft is terminal, and any further action on it answers 409 invalid_state). On Forge it bought almost nothing the tests could see. A build that reads for 50 minutes and finds its admin bug on call 298 has no calls left to fix it.
Unexpected role 'tool' after role 'user': the 400 that was our bug
The third Gauntlet attempt ended at 02:05 our time on 19 October, 97 calls in, on this answer from Mistral's API, passed through OpenRouter:
{"object":"error","message":"Unexpected role 'tool' after role 'user'","type":"invalid_request_message_order","param":null,"code":"3230","raw_status_code":400}
Mistral had asked for two tools in parallel, read_image on a screenshot and shell. OpenAI's chat format only accepts text in a tool message ("For tool messages, only type text is supported", in OpenAI's API spec). So since goose 1.0 the formatter has put a placeholder in the tool result and sent the picture as a separate user message right after it. With one tool call, or when the image comes back last, that's harmless. When an image result comes back before another tool result, the request goes out as assistant (two tool calls), tool result, user message holding the image, tool result. Mistral refused the second tool result because a user message stood between it and its call.
Who is right? Mistral's function-calling docs show the order only as a table ("assistant fc.1, fc.2 → tool r.1 → tool r.2 → assistant"), and the error type invalid_request_message_order isn't in their error glossary. Anthropic states the rule in words: "You cannot include any messages between the assistant's tool use message and the user's tool result message." Our request broke the documented order. I count this one as ours.
Three of our runs from 3 and 4 October sent the same order, and all three were answered and scored: Claude Sonnet 5.5 (served by Claude on AWS), GPT-6.1 Sol Pro (OpenAI) and MiMo V2.6 Flash (Xiaomi). All three went through OpenRouter, and I only see what goose sent to OpenRouter, so whether OpenRouter reordered anything for those hosts our logs can't tell. Mistral refused it the first time. Mistral's own coding CLI has an open pull request for the same failure, where a steered user message ends up between a tool call and its result.
We fixed goose 17 minutes after the 400 (commit a0247fffc2, "keep parallel tool results contiguous when one carries an image"). Inside each run of tool results the image messages now move to after the last result, merged into one user message, and a test replays the exact refused request. It shipped in Goose Swarm 3.0.119, our desktop app, on 19 October. The scored fourth attempt most likely ran on 3.0.119, and it never called read_image, so the fix wasn't exercised in a Mistral run.
The second attempt's ending wasn't ours. At 19:40 our time on 18 October Mistral returned "Internal server error" (type unreachable_backend, a 503). goose resent three times with backoff, the last one failed the same way, and the run ended after 30 answered calls and at least $1.18. The 9 October attempt ended on OpenRouter's side. Three times, while it was writing its main service file, OpenRouter dropped the reply with "Upstream idle timeout exceeded", and goose gave up after the third resend. Our harness refuses to score a session the provider ended, because grading a half-built tree would publish an outage as the model's score.
What a Mistral Large 4 build costs: about 18 times DeepSeek's, at sale prices
Its Forge pair billed at least $10.95 for a median of 0.2195. DeepSeek 1017's pair billed at least $0.62 for 0.452, which works out at about $50 per median point against $1.36.
Those Mistral prices are the launch sale: Mistral's changelog says "Launch pricing: 50% off for 2 weeks" from 6 October, which by my arithmetic runs out around the 20th, though OpenRouter still showed the sale prices on the 20th. Its model page lists the regular rates as $1.36 in, $4.18 out and $0.14 cached, and at those rates the same pair would cost roughly twice as much, around $22, or about 35 times DeepSeek's at the off-peak rate it ran at.
Where Mistral's money went:
| | Mistral b2 | DeepSeek 1017 b2 |
|---|---|---|
| Requests | 305 | 271 |
| Prompt tokens per request | 99,182 | 201,619 |
| Share of prompt served from cache | 84.6% | 99.7% |
| Cache-read price per million (OpenRouter list; DeepSeek at the off-peak rate it ran at on Sunday 18 Oct, double at weekday peak) | $0.07 | $0.003 |
| Uncached prompt price per million | $0.68 | $0.15 |
| Bill | $5.55 | at least $0.32 |
DeepSeek carried twice the context into each call, inside a window two and a half times larger. Nearly all of it was billed as cache reads at a price 23 times lower than Mistral's. At list prices, fresh prompt tokens make up about half of each Mistral Forge bill, though they're only 13% to 15% of its prompt tokens. My guess is that the three compactions per build and the re-reads after them are a large part of that uncached slice. On the Forge builds the compaction summaries also ran on Mistral itself, because our host pin caught the helper calls meant for a small Gemini model. We fixed that while build 2 was still running. It shipped in 3.0.119, after the pair. The fourth Gauntlet attempt's four Gemini helper calls are inside its $4.93.
What the architecture might explain
Mistral publishes less than I'd like. The model card says "a granular Mixture-of-Experts architecture" with "52B active parameters and 1.05T total parameters, and a 1.6B vision encoder", a 1M context and "Status: Public Preview". The Hugging Face placeholder says 49 billion active per token, 52 billion counting embeddings and output layers, with weights expected on 31 October. The launch post defers the architecture, "additional benchmarks, and our post-training methodology" to the weights release, and says "the reinforcement learning run behind this preview is still in flight". Expert counts, the attention design and a licence aren't published. There is no tech report yet.
On reasoning, Mistral's reasoning guide documents two values for this model, high and none. We sent medium. We do that for all our cloud runs. It's a valid value in Mistral's API schema, OpenRouter lists only high and none and defaults to high, and nobody documents what medium becomes. The 57% to 81% reasoning share suggests it was not thinking minimally, but that's an inference from our token counts.
I have two guesses about the behaviour. A preview whose RL run is "still in flight" may not yet be tuned for long agentic loops, where a long think costs calls and minutes. Our Forge logs look like that. Thorough reading, late writing, no time left to test. And 49B active parameters per token (52B with embeddings) is about three times the 16B at decode on the V4.1 Flash card, which the 1017 snapshot updates. That fits the gap in tokens per second we measured, though serving hardware and load matter as much, and our numbers can't separate them. Nothing in the cards explains the admin page or the throttle. Those are decisions in the code. I'd judge it on the code.
Mistral's own lifecycle page adds one more caveat: Public Preview models "allow silent updates". A pinned mistral-large-4-0 today may not be the model we measured on 18 and 19 October.
Where we were wrong
1. Our Gauntlet money check assumed the table opens oldest first and charged Mistral x0.6 for correct money. Joining each cell to its payment by row id fixes it; it isn't shipped, and the board still shows 0.5462.
2. The same check scores a currency that isn't on screen as a failed test. Four other ranked runs paid x0.92 for it.
3. We capped Mistral's context at 262,144 tokens on a 1M model, against 655,360 for DeepSeek, so its six Forge compactions and their minutes and dollars are partly ours.
4. goose put a user message between two tool results whenever an image came back before another result. Mistral refused it, and that ended a run. Fixed in 3.0.119.
5. Under a Mistral host pin our helper calls went to Mistral too, so its Forge bills include summary work meant for a cheaper model. Fixed in 3.0.119.
6. We asked for reasoning effort medium, which Mistral doesn't document for this model, so the effort it really ran at was the provider's choice.
Should you put Mistral Large 4 behind your agent?
From these runs, not yet for long agentic builds like our Forge task. It read for close to an hour and ran out of calls. It also cost about 18 times DeepSeek V4.1 Flash 1017 at sale prices. On the Gauntlet, once our check is fixed, it sits around 11th of 44, which is respectable for a preview that's still in training. I'd look again when the weights and the architecture write-up land (Mistral says 31 October), with the effort set to high or none and a full context window.
If you try it in your own setup, test four things. First, check whether your agent ever puts a user message between tool results (images, steering, injected reminders), because Mistral rejects that request outright. Through OpenRouter, the hosts behind three of our earlier runs answered it. Set the reasoning effort to a value Mistral documents. Watch the time to first write and the slowest calls rather than the median, since the 11- to 18-minute calls are where its time went. And read the failing check before you believe a critical, ours included.
Goose Swarm isn't production-ready yet. We run these boards with it because we know what it's made of. I'd like to hear from anyone running Large 4 in a real agent loop: did you get the long first thought too, and did none make it usable, or just cheaper? Tell me in the comments.
---
<!-- lz-footer -->
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net, and if you're planning a migration or a Forge app, that's what we do: leanzero.net.
1 reaction
Mentions
Mistral Large 4 is great for coding and cyber security. Try it out with our open source harness mistralai/mistral-vibe And the ML4 technical paper is a great read too!
Mistral Code PM here Hi subreddit - my name is Isidor and I am PM for Mistral Vibe for coding. I try to answer developer questions on this subreddit; you can also ping me or reach out. For twitter users - consider following me for product updates x.com And do file issues in our open source repo github.com/mistralai/mistral-vibe/issues (ping me @ isidorn on github)
We actually released a new harness recently - that works great. You can read more about it here mistral-vibe#1301 Also if I can help in any way you can reach out - isidor@mistral.ai
We just published our November plan for the Mistral Vibe CLI: mistral-vibe#1366 Let us know what you want to see next in Mistral Vibe
Vibe CLI November plan We just published our plan for November for the Vibe CLI mistral-vibe#1366 And we will continue publishing monthly plans and pinning them in our open source repo. You should always be able to see them by going to github.com/mistralai/mistral-vibe/issues and looking at the top pinned issues. If you have any feedback / feature requests for the CLI feel free to comment and it will influence our future plans (Dec+)
Timestral We introduce Timestral, a family of four time series foundation models for probabilistic forecasting, with 5M, 28M, 123M, and 209M parameters. Timestral sets a new state of the art on GIFT-Eval, TIME, and fev-bench, where Timestral-209M and Timestral-123M take the top two places on every metric. We achieve this with three ingredients: Decoupled Horizon Forecasting (DHF), which separates prediction tokens from the causally encoded context, so that longer horizons are trained without masking context and each observed value is both a forecast target and context for later forecasts; a covariate framework that natively supports known-future covariates within a causal architecture; and a two-stage pipeline that pretrains exclusively on a diverse, large-scale synthetic corpus before post-training on a mix of real and synthetic data with extended context. This report describes the model design and its benchmark results. Weights for all four models are available on Hugging Face and inference code on GitHub. Comments: Webpage: mistral.ai ; Weights: huggingface.co ; Code: mistralai/timestral
An OpenAI tool Mistral rejected: the SDK's strict: null TL;DR: mistral-common's Function.from_openai rejected any tool definition containing "strict": null. That is exactly what the OpenAI SDK produces by default when you dump a tool. My fix (PR #396) was merged by the Mistral AI maintainers on October 21, 2026, and will ship in the next release after 1.12.0. Until then, there is a one-line workaround (below). The symptom You are moving agents from OpenAI to Mistral, or running an OpenAI-compatible gateway in front of Mistral models. Your tools are typed with the OpenAI SDK, then converted by mistral-common: from openai.types.shared import FunctionDefinition from mistral_common.protocol.instruct.tool_calls import Function tool = FunctionDefinition(name="get_weather", parameters={"type": "object"}) Function.from_openai(tool.model_dump()) On mistral-common 1.12.0: pydantic_core._pydantic_core.ValidationError: 1 validation error for Function strict Input should be a valid boolean [type=bool_type, input_value=None, input_type=NoneType] The tool is valid. Tool.from_openai and ChatCompletionRequest.from_openai(tools=...) fail the same way, because they call the same function. The cause In the OpenAI schema, strict is optional and nullable, so the SDK dumps it as None when you don't set it: {'name': 'get_weather', 'description': None, 'parameters': {'type': 'object'}, 'strict': None} Function.from_openai already replaced None with defaults for parameters and description, but not for strict. On the Mistral side, strict is a boolean that defaults to False, so Pydantic rejected None. This is a silent integration bug: each library is right on its own, and the failure only shows up where they meet. The fix Two lines in Function.from_openai: when strict is None, drop the field so that the model falls back to its default (False). if filtered.get("strict") is None: filtered.pop("strict", None) True and False behave as before. Two tests cover Function.from_openai and Tool.from_openai with "strict": None. The full suite (1,294 tests), ruff and mypy all pass. Timeline: - issue #393 on October 20 (minimal reproduction); - PR #396 the same day; - merged on October 21. If you are on 1.12.0 today Until the next release, dump your tools without null fields: Function.from_openai(tool.model_dump(exclude_none=True)) If your tools arrive as raw JSON (in a gateway, for example), drop strict when it is null before converting. A second report, fixed differently by Mistral The same day I reported an inconsistency in the tokenizers (issue #395). Tekkenizer.decode still accepted the legacy integer special token policies (0, 1, 2), but id_to_byte_piece rejected them. I had proposed aligning id_to_byte_piece with decode. The maintainers confirmed the bug and chose the opposite approach: they removed the integer backward compatibility everywhere (PR #402, October 21). It is their design call, and a consistent one. What it means for you: if your code calls decode(..., special_token_policy=1), it will fail with the next release. Switch to the enum, or to its string value, now: from mistral_common.tokens.tokenizers.base import SpecialTokenPolicy tokenizer.decode(tokens, special_token_policy=SpecialTokenPolicy.KEEP) # or "keep" Key takeaways - A tool dumped by the OpenAI SDK contains "strict": None. mistral-common 1.12.0 rejects it, and the next release accepts it. - Workaround today: model_dump(exclude_none=True). - Integer special token policies (0, 1, 2) are going away: use SpecialTokenPolicy. - When migrating from OpenAI to Mistral, test the conversion of your tools exactly as your code produces them, not only hand-written dicts. Related This is the second contribution merged by Mistral AI, after PR #349 on offline tokenizers (article). Other fixes are awaiting review: Three silent bugs in Mistral AI's Python libraries. --- Zakaria Khchiche, freelance Data & AI Tech Lead: 200+ AI agents in production (Copilot Studio, Azure AI Foundry, Azure OpenAI), contributor to Microsoft Agent Framework and Mistral AI. LinkedIn · Website *Want your team to build agents like these? I run a hands-on Copilot Studio training (in French, with Spar-x, Qualiopi-certified, eligible for OPCO funding in France): zakariakhchiche.github.io and a free AI Act article 4 kit: zakariakhchiche.github.io
Voxtral 3: Mistral lanza SDK de voz con 50+ idiomas Mistral acaba de poner en la misma canasta transcripción, síntesis de voz y llamadas a herramientas: antes había que coser tres productos distintos para armar un agente que atienda una llamada real. Con Voxtral 3, la empresa francesa anuncia una familia de modelos de habla y un SDK que promete resolver ese problema en un solo flujo en tiempo real, con soporte para más de 50 idiomas. El lanzamiento llega en un momento en que contact centers, asistentes virtuales y copilotos de manos libres compiten por el mismo mercado: agentes que escuchen, razonen y actúen sin fricciones perceptibles para quien llama. TL;DR - Mistral lanzó Voxtral 3, un SDK de agentes de voz con modelos STT y TTS en más de 50 idiomas.- Voxtral Small Transcribe 3 supera a Whisper, Scribe v2 y Gemini 3.5 Transcribe en precisión multilingüe.- El modelo Mini de transcripción tiene 4.000 millones de parámetros y cuesta $0,0035 por minuto.- Pro Voice clona el estilo de un hablante con solo 30 minutos de audio.- Disponible vía API alojada en la UE o para despliegue en infraestructura propia. Qué es Voxtral 3 Voxtral 3 es la nueva familia de modelos de voz de Mistral AI, compuesta por un modelo de transcripción (speech-to-text), uno de síntesis (text-to-speech) y un SDK de agentes que une ambos con razonamiento y llamadas a herramientas. Está pensada para construir agentes conversacionales en tiempo real que escuchan, interpretan intención, hablan con naturalidad y ejecutan acciones en sistemas conectados, con despliegue tanto en la nube europea de Mistral como en infraestructura propia. Qué pasó Mistral presentó Voxtral 3 como respuesta a un problema que la propia empresa describe en su anuncio oficial: construir un agente de voz confiable exige que cuatro capacidades funcionen simultáneamente en tiempo real. Escuchar con precisión en distintos idiomas y acentos, razonar sobre lo que el usuario realmente quiere, hablar con expresividad natural y ejecutar acciones de varios pasos sobre sistemas conectados. Hasta ahora, cada una de esas piezas se resolvía con un producto distinto. Un motor de transcripción por un lado, un sintetizador de voz por otro, y una capa de orquestación hecha a medida para conectar ambos con la lógica de negocio. Voxtral 3 empaqueta las tres cosas (escucha, razonamiento con llamadas a herramientas, y habla) en un único pipeline de streaming. El ejemplo que Mistral usa en su demo es elocuente: una paciente llamada Béatrice dicta un número de referencia médica en francés, el agente lo transcribe, llama a una función get_referral para recuperar la carta de derivación, se la explica en inglés y agenda la cita con una llamada a book_appointment. Todo en la misma conversación, sin que el usuario perciba el cambio de tarea. Contexto e historia Mistral viene posicionándose como alternativa europea a los grandes laboratorios de IA de Estados Unidos, con un énfasis constante en soberanía de datos. Cada lanzamiento reciente de la compañía repite el mismo argumento: ofrecer la opción de procesar información dentro de la infraestructura del cliente, sin que los datos salgan de la Unión Europea si así se decide. La voz es, en ese sentido, un terreno especialmente sensible. Las llamadas de un contact center o un servicio de salud contienen información personal que muchas organizaciones no quieren que termine en servidores de terceros fuera de su jurisdicción. Voxtral 3 se apoya en ese argumento: la API alojada por Mistral está en la UE, y la alternativa de autodespliegue da control total sobre dónde se procesa el audio y si se retiene o no. Voxtral Small Transcribe 3 cubre 50 idiomas, incluidos los 24 oficiales de la UE. Detalles técnicos El corazón de Voxtral 3 son dos modelos con funciones complementarias. Voxtral Small Transcribe 3 es el modelo de transcripción, y según los benchmarks publicados por Mistral en el anuncio, supera a Whisper large-v3, Scribe v2, GPT Transcribe y Gemini 3.5 Transcribe en precisión multilingüe medida con tasa de error de palabra (WER) sobre el benchmark FLEURS. Mistral reporta un WER macro-promedio de 4,1% para la versión Small, frente a cifras de entre 4,5% y 16% para los modelos rivales en la misma comparación de 45 idiomas. La clave técnica no es solo la precisión bruta sino tres funciones que hacen viable el producto en producción. La primera es la diarización, que identifica quién habló y cuándo dentro de una misma grabación, algo imprescindible en llamadas de atención al cliente con múltiples interlocutores. La segunda es el context biasing: se le puede pasar al modelo una lista de términos técnicos o nombres propios del dominio (marcas, códigos de producto, nombres de medicamentos) para que el modelo les dé prioridad al transcribir, sin necesidad de reentrenarlo. La tercera es la detección de fin de turno, que decide cuándo el usuario terminó de hablar para que el agente responda sin demora, sin cortar la frase ni dejar un silencio incómodo. Del lado de la síntesis, Voxtral Mini TTS 3 soporta más de 35 idiomas y más de 50 dialectos, y ajusta emoción, ritmo y énfasis según el contexto de la conversación. Mistral también ofrece Pro Voice, un modo de adaptación de voz pensado para casos profesionales donde el clonado básico no alcanza: reproduce el carácter distintivo, el rango emocional y el estilo de habla de una persona real usando apenas 30 minutos de audio como referencia, incluso en idiomas distintos al original. La variante Mini del modelo de transcripción tiene 4.000 millones de parámetros, lo que permite transcripciones rápidas a un costo de $0,0035 por minuto de audio según los datos publicados por Mistral. Ese tamaño reducido es la diferencia entre correr el modelo en un servidor de contact center con decenas de líneas simultáneas o necesitar una granja de GPUs dedicada solo para escuchar. > 💭 Clave: el context biasing resuelve en configuración lo que antes exigía fine-tuning: pasarle al modelo los términos del dominio en texto libre, sin reentrenar nada. El SDK de agentes es la pieza que conecta todo. En vez de encadenar un servicio de STT, pasar el texto a un LLM separado y luego mandar la respuesta a un motor de TTS (con la latencia acumulada de cada salto), Voxtral 3 corre escucha, razonamiento, llamadas a herramientas y habla dentro del mismo stream en tiempo real. El agente puede interrumpir, retomar el hilo y ejecutar una función a mitad de conversación sin que el usuario perciba una pausa de procesamiento. El costo de hacerlo todo junto Esa integración tiene un precio de diseño: cuantas más capacidades corren en el mismo pipeline, más difícil es diagnosticar dónde falla una conversación cuando algo sale mal. Un error de diarización puede propagarse y hacer que el modelo de razonamiento interprete mal quién dijo qué, lo que a su vez dispara una llamada a herramienta incorrecta. Separar los componentes facilita el debug; unificarlos reduce la latencia pero exige observabilidad fina en cada etapa del stream. Impacto y análisis El caso de uso que Mistral exhibe (contact centers, mesas de servicio, asistentes virtuales y copilotos de manos libres) apunta directo al mercado que hoy dominan proveedores como OpenAI con su API de voz en tiempo real y ElevenLabs con sus modelos de síntesis. La diferencia que Mistral quiere marcar no es solo técnica sino regulatoria: para una empresa europea sujeta al RGPD, poder desplegar el modelo de voz en su propia infraestructura, sin que el audio salga nunca de su red, es un argumento comercial tan fuerte como el benchmark de WER. La cobertura de idiomas es otro punto a favor concreto. Voxtral Small Transcribe 3 cubre 50 idiomas, incluidos los 24 oficiales de la Unión Europea y varias lenguas asiáticas e índicas de bajos recursos, donde los modelos de transcripción suelen rendir peor por falta de datos de entrenamiento. Para un contact center que opera en varios países europeos a la vez (algo común en banca, seguros o telecomunicaciones), tener un único modelo que cubra francés, español, alemán, polaco y rumano con precisión comparable es más valioso que un modelo excelente solo en inglés. El riesgo, como con cualquier sistema de agentes de voz con llamadas a herramientas, es la superficie de ataque que se abre cuando un agente puede ejecutar acciones reales (reservar una cita, mover dinero, modificar un registro) a partir de una instrucción hablada. Cuanto más autónomo es el agente, más importa validar cada llamada a función antes de ejecutarla, algo que Mistral no detalla en profundidad en el anuncio más allá de mencionar la integración con sistemas propios del cliente. Qué sigue Mistral ya habilitó Voxtral 3 tanto en su API alojada en la UE como para autodespliegue, según el anuncio oficial. La compañía no publicó una hoja de ruta pública de próximas versiones, pero el patrón de sus lanzamientos anteriores sugiere iteraciones rápidas sobre precisión de transcripción y ampliación de idiomas soportados, en línea con lo que hizo con su familia de modelos de texto. El verdadero examen va a ser la adopción en producción: cuántas empresas eligen correr el modelo en su propia infraestructura en vez de depender de la API alojada, y si la propuesta de soberanía de datos convence a organismos reguladores de sectores sensibles como salud o banca. 📖 Resumen en Telegram: Ver resumen Probalo vos: revisá la demo interactiva y la documentación del SDK en la página oficial de Voxtral 3 antes de decidir si migrás tu pipeline de voz. Preguntas frecuentes ¿Qué idiomas soporta Voxtral 3? El modelo de transcripción de Voxtral 3 cubre más de 50 idiomas, incluidos los 24 oficiales de la Unión Europea y varias lenguas asiáticas e índicas de bajos recursos. El modelo de síntesis de voz soporta más de 35 idiomas y más de 50 dialectos. ¿Voxtral 3 se puede desplegar fuera de la nube de Mistral? Sí. La familia Voxtral 3 está disponible tanto a través de la API alojada por Mistral en la Unión Europea como para autodespliegue en infraestructura propia, lo que permite controlar dónde se procesa el audio y si se retiene. ¿Qué diferencia a Voxtral Small Transcribe 3 de Whisper? Según los benchmarks de Mistral sobre el conjunto FLEURS, Voxtral Small Transcribe 3 obtiene una tasa de error de palabra menor que Whisper large-v3, Scribe v2, GPT Transcribe y Gemini 3.5 Transcribe en una comparación de 45 idiomas compartidos. ¿Qué es el context biasing en los modelos de habla de Mistral? Es la capacidad de pasarle al modelo de transcripción una lista de términos técnicos o nombres propios en texto libre para que les dé prioridad al reconocer el audio, mejorando la precisión en vocabulario de dominio específico sin reentrenar el modelo. ¿Cuánto cuesta transcribir audio con el SDK de voz de Mistral? La variante Mini del modelo de transcripción, de 4.000 millones de parámetros, cuesta $0,0035 por minuto de audio según los datos publicados en el anuncio oficial de Mistral. Referencias - Mistral AI: Voxtral 3: anuncio oficial del lanzamiento, benchmarks de transcripción y detalles del SDK de agentes de voz.- Mistral AI: sitio oficial de la compañía desarrolladora de la familia Voxtral.- Mistral AI en GitHub: repositorios públicos y herramientas relacionadas con los modelos de Mistral. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Mistral Large 4 Benchmark for Coding vs DeepSeek V4.1 Flash Mistral Large 4 scored 0.5462 on our Gauntlet benchmark, 28th of 44. About a third of what it lost came from a check of ours that read its table the wrong way round. All 12 amounts it put on screen were correct. I went in expecting to write about a slow, expensive model, and on our Forge benchmark that part holds up. If you pay for a coding agent, this model is pitched at your budget. Mistral released Large 4 on 6 October as a Public Preview, 1.05 trillion parameters with 52 billion active and a 1M-token context, at half its list price for the first two weeks. Their launch post puts it ahead of DeepSeek V4 Pro on their own Coding Agent Index (49.8%), which is the kind of claim that moves a budget, so we ran it through both of our agentic coding benchmarks. The Gauntlet has an agent build a payments console with two services and a 3D view inside 150 model calls, then scores it on 99 checks. Forge 2.0 asks for a v2 upgrade of a working Jira Forge app inside 300 calls and scores it on 105 checks against three seeded Jira sites. Getting a Gauntlet score took four attempts. The first, on 9 October, ended after 49 calls on OpenRouter's "Upstream idle timeout exceeded". On 18 October the second was ended by Mistral's servers. Early on 19 October the third was ended by a bug in goose, the open-source coding agent we run (our own fork), and the fourth finished that afternoon. Its Forge 2.0 pair scored 0.1086 and 0.3304 for at least $10.95. DeepSeek V4.1 Flash 1017 did better on the same Forge task. It's the 17 October snapshot I wrote about in my DeepSeek piece, and it scored 0.2422 and 0.6618 for at least $0.62 in about a quarter of the time. On the Gauntlet the low score is mostly our scorer's fault. On Forge the code losses were Mistral's own. Our harness also gave it a smaller context window than DeepSeek. The build trees show where each loss came from. This is one scored Gauntlet run and one Forge pair, in our setup, on a model whose vendor says it can change silently while it's in preview. Mistral Large 4 benchmark results: Gauntlet 0.5462, Forge 2.0 median 0.2195  | | Mistral Large 4 | DeepSeek V4.1 Flash 1017 | |---|---|---| | Gauntlet 7.2 | 0.5462, 144 min, $4.93 | 0.6957, 23 min, $0.21 | | Forge 2.0 build 1 | 0.1086, 118 min, at least $5.40 | 0.2422, 28 min, $0.30 | | Forge 2.0 build 2 | 0.3304, 106 min, $5.55 | 0.6618, 30 min, at least $0.32 | | Unscored Gauntlet attempts | 9 Oct: idle timeout after 49 calls, at least $1.43. 18 Oct: Mistral 503 after 30 calls, at least $1.18. 19 Oct: our 400 after 97 calls, $3.04 | none | I checked these on the live boards on 21 October; if a run page says something else now, trust the run page. All six Mistral runs together cost at least $21.53, with three of the bills only lower bounds. Six things we found in the Mistral Large 4 builds 1. The x0.6 "wrong money" critical on the Gauntlet is our bug. Our money check compares the amounts on screen with the oldest 50 payments, and Mistral's table opens on the newest. 2. Mistral's money formatter works on integer digits with a per-currency decimals table, the same approach as DeepSeek's. 3. Forge build 1, by my reading, lost most of its gap to build 2 to a throttle it wrote itself: it booked 25 to 34 times the real cost of a list call and paused its own scheduled work each hour, before its v1 migration could run. 4. Neither Forge build ever displayed its admin page, and neither ran a browser self-test. 5. The 18 October attempt opened with one 37,853-word thought that ran 18 minutes, hit a 65,536-token output limit and was thrown away. 6. Mistral's API refused a message order that three other providers' endpoints had answered, through OpenRouter, in our runs two weeks earlier. Mistral Large 4 on our Gauntlet: 0.5462, about 0.70 without a check of ours that misread its table  Most Gauntlet checks just add to a weighted average, but a handful are critical, and when one of those fails it multiplies the whole score down, by as much as x0.6. Wrong money in a payments console is one of those. The money check is called b_money_rendered. A browser probe reads the amount cell of the first 12 rows of the payments table. Then the scorer checks that the digits match a stored amount and that the decimals match the currency, because amounts are stored as integers in the currency's smallest unit (cents, or fils for the Kuwaiti dinar). A correct cell shows two decimals for EUR and USD, none for yen and three for dinars. Mistral's run scored 0.00 on it, with the detail line "0.00 of 12 cells exponent-correct; JPY/KWD traps 0.00", and the multiplier took the whole run from 0.9104 down to 0.5462. What Mistral rendered These are the 12 cells the probe read, verbatim: KWD 111.000, ¥594, ¥199, $4.47, ¥809, €224.00, KWD 82.400, €33.10, KWD 2.420, ¥1,060, $1,840.00, KWD 72.400. Our probe also records each row's id, and joined to the fixture, pay_12287 is stored as KWD 111000, so 111.000 dinars is right, and pay_12286 is JPY 594, which needs no decimals. All 12 are right. So are the probe's 12 extra rows. Its formatter in web/app.js (lines 7 to 25, with the source's \u escapes shown as characters) never touches a float: const CUR = { EUR: { sym: '€', exp: 2 }, USD: { sym: '$', exp: 2 }, JPY: { sym: '¥', exp: 0 }, KWD: { sym: 'KWD ', exp: 3 }, }; ... const s = String(a).padStart(exp + 1, '0'); const int = s.slice(0, s.length - exp) || '0'; const frac = exp > 0 ? s.slice(s.length - exp) : ''; It planned this before writing it. At 10:58 our time (EEST), 27 minutes in, it checked the contract's example and two real payments in its thinking: "129900 EUR → €1,299.00 ✓; JPY 8564 → ¥8,564 ✓; KWD 8263000 → KWD 8,263.000 ✓". Our scorer's own screenshot of the inspector shows that dinar payment as KWD 8,263.000, and the inspector check (q_payment_context) passed.  Why the check said zero Here is the scorer, score_sb7.py around line 973: first_page = c.pack.payments[:50] by_cur: Dict[str, set] = {} for row in first_page: by_cur.setdefault(row["currency"], set()).add(row["amount_minor"]) payments is stored in date order, so payments[:50] is pay_00000 to pay_00049, the oldest fifty. A rendered cell only passes if its digits equal one of those fifty amounts, so the check assumes, without saying it, that the table opens oldest first. Mistral's opens newest first (sort: '-created_at', web/app.js:49). None of its 12 cells could ever match. Our probe even collects the row ids "so the scorer can join against fixtures", in its own comment. No scorer file reads them.  I re-graded the run with the scorer's own _money_ok function, copied unchanged. It gives 0.0 as written, 1.0 against the 50 rows actually on screen, and 24 of 24 when each cell is joined to its payment by row id. Was opening newest first a mistake by Mistral? Its contract fixes the API's default order ("created_at (default, ascending by INSTANT)") and says the Date header toggles, but it never says which way the table starts. Mistral saw the gap and decided, at 11:48 our time: "The grader might check the first page shows specific rows? Unlikely to assume an order. I'll default to '-created_at' (newest first) — most console-like." It bet that the grader would not assume an order, and the grader did. You can argue the UI should inherit the API's default. I'd listen. Even then it's a sort-order quibble. The check charged it as wrong money. Who did better at money All five models I compared passed with 1.0: Claude Opus 5.5, Claude Sonnet 5.5, GPT-6.1 Sol (the model behind Jev Router's top Forge score), GPT-6.1 Sol Pro and DeepSeek V4.1 Flash 1017. All of them open their table with sort: 'created_at', and so does our own reference app, which is why our release validation never met a descending default. Grade those five tables against the newest 50 payments and four score 0.0, Sol 0.05. DeepSeek's formatter is close to a copy of Mistral's: let digits = String(Math.abs(minor)); if (exponent > 0) digits = digits.padStart(exponent + 1, '0'); const whole = exponent > 0 ? digits.slice(0, digits.length - exponent) : digits; Same idea, same output. It got 1.0 and Mistral got 0.0. Sol and Sol Pro call Intl.NumberFormat and divide the integer by 10**exp first, and Sonnet does the same with Math.pow, which is fine for amounts this size. So on money code it's a tie between Mistral and DeepSeek. The sort order made the difference. Mistral did leave one real money bug, in its own test. Its browser self-test checks the first amount against /^[€$¥]\d[\d,]*\.\d{2}$|^KWD [\d,]+\.\d{3}$/, which would reject a correct ¥594 because it demands two decimals after a yen sign. It printed "PASS money formatted" four times, and my guess is that its own first row was never a yen payment. I can't see which row it was. Without our false critical: about 0.70 and 11th of 44 The score path for this run goes like this. Its checks earned 0.9104. Our false critical multiplied that by 0.6, to 0.5462. Separately, a run that fails some of the 3D checks gets a ceiling on its score, and Mistral's partial failures on picking, the coasting camera and the overview's legibility set it at 0.709. The ceiling formula keeps a score just under the cap, so without the false critical the run would come out at about 0.7048. That's my arithmetic, not a re-score. The board still says 0.5462. It would sit 11th of 44, two places above DeepSeek 1017's 0.6957. The 3D failures, which are Mistral's own, cost it about 0.2 on top. My audit of that check turned up a second flaw. The yen and dinar "traps" score 0 when no yen or no dinar row happens to be among the cells the probe reads (up to 12). A run whose visible amounts are all right can still pay x0.92. Four ranked runs paid it that way: Elorian Glimpse, Step 5 Preview, Qwen3.8 Omni Flash and GLM-5.3. Across every Gauntlet 7.2 build I could reach, Mistral is the only one the sort assumption hit.  Is Mistral Large 4 good for coding? Forge 2.0 builds of 0.1086 and 0.3304 Forge 2.0 tests the same habits harder: the agent reads a long spec, upgrades a working Forge app under a Jira rate model, and has to prove it all in a local sandbox (our Forge emulator kit) before the calls run out. My piece on the September DeepSeek V4.1 Flash covered this same task, with medians of 0.33 for it and 0.67 for Opus 5.5 in an earlier comparison group. Both Mistral builds and DeepSeek 1017's pair are in the same comparison group on our board. That means the same task, seeds, scorer and engine build. All four asked for the same effort setting.  A Forge 2.0 score is the earned score times a critical multiplier times a reliability factor, where reliability starts at 1 and loses up to 10% for each group of checks whose worst check failed, with a floor of 0.25. Build 1 sat on that floor (its unfloored product was 0.2194) and build 2 came out at 0.4718. Neither triggered a critical. My reading is that most of the 0.22 gap comes from build 1's throttle and the order it ran its migration in. Build 1 throttled itself and never migrated The task gives each Jira site a rate budget of 2,400 points an hour, and background work may use 70% of it, so 1,680. Build 1 wrote a gate for that in src/dose.js (lines 76 to 88): if (dose.bg + estimatedCost > limit) { const untilMs = hourStartOf(now) + 3600000; await kvs.set(PAUSE_KEY, { untilMs }); throw new QuotaPaused(untilMs); The gate is fine. The estimates feeding it were not. With no points header from the site, it charged its own counter from guesses. It booked 51 points for a board or sprint list page (src/config.js:43, cost: 1 + 50), 105 for a search and 260 for a changelog bulk fetch. On the scoring site its first scheduled run had counted 1,567 points after 21 seconds. The next estimated call would have taken it past 1,680. So it paused for the rest of the hour. Yet the site's own ledger for that run says it had spent 715 points over 27 requests, with list pages costing 1.5 to 2 points each. That would only have been a nuisance if the migration ran first. It ran last. reconcile() in src/index.js calls reconcileAll, then saveClosed, then migrateV1Rows, and the pause in the first step skipped the rest. Its rescan had no cursor. Each hour it started over and paused in the same place. Our scorer's verdict reads "0/130 historical changes v1 never recorded" and "h2: 0 of 59 v1 rows in scope-ledger", and it traces 15 checks to that one root cause. On the development site, which our spec gives the same shape on another seed, the gate tripped too, twice. At 21:19 our time it wrote "The reconcile hit my own dose gate". After a reset one run got through and it reported "migration complete (88/88)". Build 2 got the same thing right. I think it was more luck than design. Its cost counter under-counted instead (its own words near the end: "my costOf under-counts returned records"). It ran over the background share in 4 of 31 hours, and on our scoring sites it never paused early. In its last minutes its own dev run did pause early. At call 300 of 300 it spotted the ordering problem: "I'm at the call budget (300/300) — this is my final turn". Then it moved the migration to the top with the comment "it is the graded deliverable and needs the fewest points". It never ran that version. It still scored 59 of 59 migrated and 130 of 130 backfilled. DeepSeek 1017's build 2 had that ordering from the start (src/sync.js:409, "Migrate v1's rows first"). Neither build displayed its admin page Both Mistral builds score 0.00 on the admin panel tier. That one failure takes down the panel labels, the CI web trigger (no secret can exist before the panel's Rotate button creates one) and the admin boot check with it. Build 1's src/frontend/admin.jsx ends with export default AdminPage; and never calls ForgeReconciler.render, so UI Kit had nothing to draw. It found that out at 21:39, on the 298th of its 300 calls, when its only admin-page test printed "(nothing rendered)". Build 2 does call ForgeReconciler.render(<App />) at line 197, and the non-admin view displayed its permission message, but the admin view came back as an empty tree. The probe recorded no error that explains it. And build 2 never ran the kit's UI Kit check on that page. DeepSeek 1017's build 2 renders the same way (admin.jsx:186) and ran that UI Kit check 14 times before it finished. The habit shows in the counts too: DeepSeek's two builds invoked their resolvers in the sandbox 45 and 30 times, Mistral's 3 and 4, and neither Mistral build ran a browser self-test at all. Build 1 also sent 37 of its 355 tool calls, about one in ten, to a bash tool that doesn't exist (goose's is called shell), and build 2 sent 19 of 344. Build 2 had good moments. It had the highest UI-function (0.9957) and reconcile (0.9974) tiers of the four builds in this comparison group. Both are small tiers. Both also beat an Opus 5.5 build from an earlier group. In its last ten minutes it noticed that v1's React bundles were 244 KB against a 150 KB boot budget. It rewrote all three Custom UI pages in plain DOM, to between 102 and 106 KB each. Mistral Large 4 vs DeepSeek V4.1 Flash 1017: 27 minutes to the first file against 2 Time is where the two models differ most. Mistral's first app-code write came 32, 35 and 27 minutes into its three Gauntlet attempts of 18 and 19 October, and about 49 and 55 minutes into its Forge builds. DeepSeek 1017 wrote its first app file 2.4 minutes into its Gauntlet run and about 4.5 minutes into each Forge build, and it finished both Forge builds with 29 to 37 calls to spare. Mistral ran out of calls in both. Its median call took 4.5 to 4.8 seconds on Forge against DeepSeek's 4.0. The typical call barely differs. The slow tail is what costs it. Each Mistral run had calls that took 11 to 18 minutes, and in the Gauntlet attempts the calls over five minutes add up to more than half of all the time the model spent answering. DeepSeek's slowest call in any of its three runs took 71 seconds, and across our runs Mistral generated between 55 and 70 tokens a second while DeepSeek managed 108 to 155.  The 18-minute thought that was thrown away The 18 October attempt that Mistral's servers later ended opened with one thinking call of 37,853 words that ran 1,081 seconds. It was coherent (under 1% of its 12-word sequences repeat). It covered the money rule, the 3D tower heights and the order of the services. Then it stopped at exactly 65,536 output tokens. goose marked the reply as cut off, and nothing in it was carried out. Its next thought: "Let me continue. I was planning extensively. Time to write code." goose sent no max_tokens and our model limits list 262,144 output tokens, so the 65,536 cap came from the serving side. Whether that's OpenRouter or Mistral, our logs don't show. Reasoning was 57% to 81% of everything it generated, depending on the run. On Forge both builds also compacted their context three times, once the prompt had grown to between about 170,000 and 210,000 tokens. After most compactions it re-read files it had already read ("I need to re-read the v1 sources and my v2 files"). Build 2's own compaction summary says it plainly: "I've spent ~66% of context on exploration; no code". Those compactions are partly ours. goose gave Mistral a usable window of 262,144 tokens. It took the smallest Mistral endpoint's 524,288 (the EU one) and reserved half of it for output, on a model whose card says 1M, while DeepSeek got 655,360. At about 200,000 tokens a call, DeepSeek would have compacted too under Mistral's limit, and under its own it never did. The summary calls ran about 9 to 11 minutes per Forge build, inside the times charged to Mistral. What did the long thinking buy? On the Gauntlet, quite a lot: its plans got the money rule right, and its decisions file is careful (a rejected draft is terminal, and any further action on it answers 409 invalid_state). On Forge it bought almost nothing the tests could see. A build that reads for 50 minutes and finds its admin bug on call 298 has no calls left to fix it. Unexpected role 'tool' after role 'user': the 400 that was our bug The third Gauntlet attempt ended at 02:05 our time on 19 October, 97 calls in, on this answer from Mistral's API, passed through OpenRouter: {"object":"error","message":"Unexpected role 'tool' after role 'user'","type":"invalid_request_message_order","param":null,"code":"3230","raw_status_code":400} Mistral had asked for two tools in parallel, read_image on a screenshot and shell. OpenAI's chat format only accepts text in a tool message ("For tool messages, only type text is supported", in OpenAI's API spec). So since goose 1.0 the formatter has put a placeholder in the tool result and sent the picture as a separate user message right after it. With one tool call, or when the image comes back last, that's harmless. When an image result comes back before another tool result, the request goes out as assistant (two tool calls), tool result, user message holding the image, tool result. Mistral refused the second tool result because a user message stood between it and its call. Who is right? Mistral's function-calling docs show the order only as a table ("assistant fc.1, fc.2 → tool r.1 → tool r.2 → assistant"), and the error type invalid_request_message_order isn't in their error glossary. Anthropic states the rule in words: "You cannot include any messages between the assistant's tool use message and the user's tool result message." Our request broke the documented order. I count this one as ours. Three of our runs from 3 and 4 October sent the same order, and all three were answered and scored: Claude Sonnet 5.5 (served by Claude on AWS), GPT-6.1 Sol Pro (OpenAI) and MiMo V2.6 Flash (Xiaomi). All three went through OpenRouter, and I only see what goose sent to OpenRouter, so whether OpenRouter reordered anything for those hosts our logs can't tell. Mistral refused it the first time. Mistral's own coding CLI has an open pull request for the same failure, where a steered user message ends up between a tool call and its result. We fixed goose 17 minutes after the 400 (commit a0247fffc2, "keep parallel tool results contiguous when one carries an image"). Inside each run of tool results the image messages now move to after the last result, merged into one user message, and a test replays the exact refused request. It shipped in Goose Swarm 3.0.119, our desktop app, on 19 October. The scored fourth attempt most likely ran on 3.0.119, and it never called read_image, so the fix wasn't exercised in a Mistral run. The second attempt's ending wasn't ours. At 19:40 our time on 18 October Mistral returned "Internal server error" (type unreachable_backend, a 503). goose resent three times with backoff, the last one failed the same way, and the run ended after 30 answered calls and at least $1.18. The 9 October attempt ended on OpenRouter's side. Three times, while it was writing its main service file, OpenRouter dropped the reply with "Upstream idle timeout exceeded", and goose gave up after the third resend. Our harness refuses to score a session the provider ended, because grading a half-built tree would publish an outage as the model's score. What a Mistral Large 4 build costs: about 18 times DeepSeek's, at sale prices  Its Forge pair billed at least $10.95 for a median of 0.2195. DeepSeek 1017's pair billed at least $0.62 for 0.452, which works out at about $50 per median point against $1.36. Those Mistral prices are the launch sale: Mistral's changelog says "Launch pricing: 50% off for 2 weeks" from 6 October, which by my arithmetic runs out around the 20th, though OpenRouter still showed the sale prices on the 20th. Its model page lists the regular rates as $1.36 in, $4.18 out and $0.14 cached, and at those rates the same pair would cost roughly twice as much, around $22, or about 35 times DeepSeek's at the off-peak rate it ran at. Where Mistral's money went: | | Mistral b2 | DeepSeek 1017 b2 | |---|---|---| | Requests | 305 | 271 | | Prompt tokens per request | 99,182 | 201,619 | | Share of prompt served from cache | 84.6% | 99.7% | | Cache-read price per million (OpenRouter list; DeepSeek at the off-peak rate it ran at on Sunday 18 Oct, double at weekday peak) | $0.07 | $0.003 | | Uncached prompt price per million | $0.68 | $0.15 | | Bill | $5.55 | at least $0.32 | DeepSeek carried twice the context into each call, inside a window two and a half times larger. Nearly all of it was billed as cache reads at a price 23 times lower than Mistral's. At list prices, fresh prompt tokens make up about half of each Mistral Forge bill, though they're only 13% to 15% of its prompt tokens. My guess is that the three compactions per build and the re-reads after them are a large part of that uncached slice. On the Forge builds the compaction summaries also ran on Mistral itself, because our host pin caught the helper calls meant for a small Gemini model. We fixed that while build 2 was still running. It shipped in 3.0.119, after the pair. The fourth Gauntlet attempt's four Gemini helper calls are inside its $4.93. What the architecture might explain Mistral publishes less than I'd like. The model card says "a granular Mixture-of-Experts architecture" with "52B active parameters and 1.05T total parameters, and a 1.6B vision encoder", a 1M context and "Status: Public Preview". The Hugging Face placeholder says 49 billion active per token, 52 billion counting embeddings and output layers, with weights expected on 31 October. The launch post defers the architecture, "additional benchmarks, and our post-training methodology" to the weights release, and says "the reinforcement learning run behind this preview is still in flight". Expert counts, the attention design and a licence aren't published. There is no tech report yet. On reasoning, Mistral's reasoning guide documents two values for this model, high and none. We sent medium. We do that for all our cloud runs. It's a valid value in Mistral's API schema, OpenRouter lists only high and none and defaults to high, and nobody documents what medium becomes. The 57% to 81% reasoning share suggests it was not thinking minimally, but that's an inference from our token counts. I have two guesses about the behaviour. A preview whose RL run is "still in flight" may not yet be tuned for long agentic loops, where a long think costs calls and minutes. Our Forge logs look like that. Thorough reading, late writing, no time left to test. And 49B active parameters per token (52B with embeddings) is about three times the 16B at decode on the V4.1 Flash card, which the 1017 snapshot updates. That fits the gap in tokens per second we measured, though serving hardware and load matter as much, and our numbers can't separate them. Nothing in the cards explains the admin page or the throttle. Those are decisions in the code. I'd judge it on the code. Mistral's own lifecycle page adds one more caveat: Public Preview models "allow silent updates". A pinned mistral-large-4-0 today may not be the model we measured on 18 and 19 October. Where we were wrong 1. Our Gauntlet money check assumed the table opens oldest first and charged Mistral x0.6 for correct money. Joining each cell to its payment by row id fixes it; it isn't shipped, and the board still shows 0.5462. 2. The same check scores a currency that isn't on screen as a failed test. Four other ranked runs paid x0.92 for it. 3. We capped Mistral's context at 262,144 tokens on a 1M model, against 655,360 for DeepSeek, so its six Forge compactions and their minutes and dollars are partly ours. 4. goose put a user message between two tool results whenever an image came back before another result. Mistral refused it, and that ended a run. Fixed in 3.0.119. 5. Under a Mistral host pin our helper calls went to Mistral too, so its Forge bills include summary work meant for a cheaper model. Fixed in 3.0.119. 6. We asked for reasoning effort medium, which Mistral doesn't document for this model, so the effort it really ran at was the provider's choice. Should you put Mistral Large 4 behind your agent? From these runs, not yet for long agentic builds like our Forge task. It read for close to an hour and ran out of calls. It also cost about 18 times DeepSeek V4.1 Flash 1017 at sale prices. On the Gauntlet, once our check is fixed, it sits around 11th of 44, which is respectable for a preview that's still in training. I'd look again when the weights and the architecture write-up land (Mistral says 31 October), with the effort set to high or none and a full context window. If you try it in your own setup, test four things. First, check whether your agent ever puts a user message between tool results (images, steering, injected reminders), because Mistral rejects that request outright. Through OpenRouter, the hosts behind three of our earlier runs answered it. Set the reasoning effort to a value Mistral documents. Watch the time to first write and the slowest calls rather than the median, since the 11- to 18-minute calls are where its time went. And read the failing check before you believe a critical, ours included. Goose Swarm isn't production-ready yet. We run these boards with it because we know what it's made of. I'd like to hear from anyone running Large 4 in a real agent loop: did you get the long first thought too, and did none make it usable, or just cheaper? Tell me in the comments. --- <!-- lz-footer --> Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net, and if you're planning a migration or a Forge app, that's what we do: leanzero.net.
Mistral just dropped a Time-Series AI model 🤖 ⭐ GitHub Repository: mistralai/timestral In this video, we explore timestral, an open-source project that mistral AI released Timestral, a family of time series foundation models supporting multivariate probabilistic forecasting and long contexts up to 32,768 steps.. #github #coding #opensource #programming #developer