Pareto 26.10 vs Pareto 26.9: Un solo número separa estas dos versiones

Comparar Pareto 26.10 con Pareto 26.9 es en gran medida un estudio sobre cosas que no cambiaron. El mismo proveedor, la misma arquitectura compuesta, la misma respuesta máxima de 131.072 tokens, los mismos cinco parámetros declarados, las mismas tarifas publicadas en la propia página de precios del proveedor y —en el único benchmark que comparten ambas versiones— una diferencia de una décima de punto a favor del modelo más antiguo. En las superficies en las que la gente suele comparar modelos, estos dos son el mismo producto con distintos números de versión. En una superficie no lo son, y es la superficie que determina qué cargas de trabajo pueden usar cualquiera de los dos: la ventana de contexto, donde 26.9 ofrece 262.144 tokens y 26.10 ofrece 1.048.576. Los fallos de IA y los incidentes de agentes documentados que hay detrás de versiones como esta se recopilan en the OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, su nivel de gravedad, su grado de confianza y su indicador de disputa.

Ambos están activos. pareto-26.10 es la versión que se convirtió en la predeterminada detrás del alias pareto el 15 de octubre de 2026, cuando Unbiased trasladó a ella su versión de disponibilidad general; pareto-26.9 es la versión de septiembre que el proveedor dice que «sigue disponible» para quien quiera quedarse. Esa es toda la decisión a la que se enfrenta hoy una persona que llama, y el resto de esta página son los detalles que hay detrás.

Los hechos que lo rodean

Ambos modelos están documentados como capaces de aceptar entrada de texto e imágenes y devolver texto, y ninguno publica un identificador de Hugging Face — los pesos son cerrados en ambos lados de esta comparación, así que no hay nada que descargar ni autoalojar. Ninguno tiene un benchmark independiente. Ambos son servidos por un único proveedor, Unbiased en sí, lo que significa que no hay un segundo host al que conmutar en caso de fallo dentro de la propia pila tecnológica del proveedor para ninguna de las dos versiones. Por lo tanto, la comparación siguiente es entre dos configuraciones de una única línea de producto de un único proveedor, no entre dos ecosistemas.

El contexto lo es todo en un argumento.

Un aumento de contexto de 4× suena a una línea de ficha técnica hasta que lo trasladas a lo que la gente realmente hace con los modelos de contexto largo.

Con 262.144 tokens, una sesión de agente sobre un repositorio completo, una transcripción larga de soporte o un hilo de investigación de varias horas son un problema de fragmentación. Recuperas, resumes, mantienes una ventana móvil y aceptas que el modelo ve una reconstrucción de la tarea en lugar de la tarea. Con 1.048.576 tokens, esas cargas de trabajo caben —no siempre de forma cómoda, y no de forma barata a $0.80 por millón de tokens de entrada sin acierto de caché, pero caben. La diferencia práctica entre las dos versiones es si tu pipeline necesita una capa de recuperación entre tus datos y el modelo.

Esa sí que es una verdadera decisión de ingeniería y, además, es la única de esta página que tiene una respuesta defendible. Todo lo demás está tan parejo que la elección debería basarse en algo distinto de la calidad.

Lado a lado, dimensión por dimensión

• Cadena de modelo: pareto-26.10 (predeterminado detrás de pareto desde el 2026-10-15) frente a pareto-26.9 (retenido, no predeterminado).

• Ventana de contexto: 1.048.576 tokens frente a 262.144 tokens.

• Respuesta máxima — 131.072 tokens en ambos. Sin cambios entre versiones.

• Modalidades — entrada de texto e imagen, salida de texto, en ambos.

• Parámetros declarados: max_tokens, temperature, top_p, tools y tool_choice en 26.10; el mismo conjunto más response_format en 26.9.

• Llamada a herramientas — tool_choice restringido a auto en 26.10; el modelo decide si llamar, no puedes forzarlo.

• Pesos — cerrados en ambos; ningún identificador de Hugging Face en ninguno de los dos registros.

• Proveedores de servicio — uno, el vendedor, en ambos.

• Tarifa publicada — $0.80 de entrada / $0.03 en caché / $3.20 de salida por millón en ambos, según la página de precios actual del proveedor.

• DeepSWE v1.1 — 69,9 % a 0,24 $ por tarea en 26.10 frente a 70,0 % a 0,29 $ por tarea en 26.9, ambas ejecutadas por el proveedor.

Dos de esas filas merecen su propio párrafo, porque son las que se informan mal.

La diferencia en la salida estructurada que nadie anuncia

Las listas de parámetros no son idénticas. El registro de catálogo de 26.9 declara response_format entre sus parámetros admitidos; el registro de 26.10 no lo hace. La superficie declarada para 26.10 es max_tokens, temperature, top_p, tools y tool_choice, y punto.

Léalo con atención, no como un titular: la ausencia de un parámetro en una lista declarada no demuestra que el endpoint lo rechace, y la propia documentación de la API del proveedor no enumera ninguna de las dos listas. Pero si su pipeline depende del modo JSON o de la salida restringida por esquema, y va a pasar de la 26.9 a la 26.10 dando por hecho que la versión más reciente es un superconjunto estricto, ese supuesto no está respaldado por nada publicado. Pruébelo con su propio tráfico antes de migrar, o prevea validar la salida en el lado del cliente. Es una minucia que se convierte en un incidente un martes cualquiera.

Dos tarjetas de tarifas vigentes no coinciden en cuánto cuesta 26.9

Esta es la parte más desordenada de la comparación y la que más probabilidades tiene de afectar a una decisión real.

Unbiased publica una única tarifa —0,80 $ de entrada, 0,03 $ de entrada en caché, 3,20 $ de salida— y no la versiona por lanzamiento. Leído al pie de la letra, eso significa que 26.10 y 26.9 cuestan lo mismo por token hoy, lo que hace que la migración sea gratuita y que el aumento de contexto sea la única variable. Mientras tanto, el propio registro de ficha técnica del modelo todavía contiene las cifras de septiembre para 26.9: 2,50 $ de entrada, 0,25 $ en caché, 7,50 $ de salida. Ambas fuentes estaban activas cuando se escribió esto. Ninguna tiene fecha, y el proveedor no ha publicado ninguna entrada de registro de cambios que explique el movimiento, así que no hay ninguna línea citable de «tal día bajó el precio» en ninguna parte del registro.

La orientación práctica no es glamorosa. Asume la tarjeta inferior, porque dos de las tres superficies que puedes consultar la publican y una de ellas es la página contra la que se factura al cliente; luego vuelve a comprobarla antes de comprometerte con una cifra en un presupuesto. Si fijas cualquiera de las dos versiones para la atribución de costos, ten en cuenta que un mes mixto que abarque la transición del 15 de octubre no se descompondrá limpiamente a posteriori, porque las versiones tuvieron precios distintos en momentos distintos y el proveedor no fecha sus cambios.

Un punto, una décima de punto, y nada que concluir

El único benchmark que ambas versiones tienen en común es DeepSWE v1.1, y las cifras del propio proveedor sitúan la 26.9 en 70,0 % y la 26.10 en 69,9 %. Ambas cifras están ejecutadas por el proveedor, la más antigua sobre una muestra de 30 tareas en lugar del conjunto de evaluación completo, y Unbiased describe toda la comparación como no validada de forma independiente.

La lectura honesta es que esta medición no distingue entre las versiones. Una décima de punto en un fragmento parcial de tareas queda dentro del ruido de una sola ejecución, y tratarlo como una clasificación en cualquier dirección —«26.10 sufrió una regresión» o «26.10 es mejor porque es más barato por tarea»— es leer las hojas de té. Las cifras de coste por tarea difieren más ($0.24 frente a $0.29), e incluso esas provienen de ejecuciones en meses distintos con un modelo combinado cuya composición subyacente el proveedor no revela.

Lo que la hoja sí te dice es dónde no mirar. Si estás eligiendo entre estos dos por calidad, estás eligiendo con base en un número que no puede sustentar esa decisión. La evidencia que los separa es arquitectónica —la ventana de contexto y la superficie de parámetros— y ambas son verificables de una forma en que las puntuaciones no lo son.

Cuál llamar, según la carga de trabajo

• Programación agéntica sobre un repositorio completo — 26.10. La ventana de 1M es la diferencia entre enviar el repositorio y enviar un resumen de él.

• Análisis de documentos largos o transcripciones largas — 26.10, por la misma razón, y ojo con la factura de entrada: 1M de tokens sin acierto de caché cuesta $0.80 por solicitud solo en entrada.

Canalizaciones de salida en modo JSON o restringidas por esquema — 26.9 hasta que hayas probado tú mismo el comportamiento de 26.10, porque la lista de parámetros declarada de 26.9 incluye response_format y la de 26.10 no.

• Una carga de trabajo que ya está en producción y que cabe dentro de 262K — 26.9. No hay evidencia publicada de que migrar mejore el resultado, y fijar la versión es la decisión más económica.

• Cualquier caso en el que quieras el valor predeterminado actual del proveedor sin mantener un pin — 26.10, mediante el alias pareto sin más, entendiendo que el alias sigue el calendario del proveedor en lugar del tuyo.

Para los equipos que trabajan con ambos lados de un ciclo de construcción y verificación, el patrón útil es fijar la versión 26.10 para la pasada de contexto largo y mantener la 26.9 disponible como brazo de comparación, que es exactamente para lo que sirve una capa de enrutamiento. OrcaRouter no incluye ningún modelo Unbiased, por lo que ambas cadenas se invocan a través de la propia API del proveedor; lo que ofrecemos es una sola clave y una sola integración para los modelos con los que querrá comparar 26.10 frente a, de modo que evaluar el cambio no suponga firmar un segundo contrato. OrcaRouter aplica el precio de lista del proveedor sin ningún margen (0 %), lo cual es una afirmación sobre los modelos que sí servimos, no sobre este.

La migración que nadie programó

La razón por la que esta comparación es real y no académica es que el cambio ya les ocurrió a personas que no lo pidieron. El 15 de octubre, el alias pareto pasó de la versión de septiembre a 26.10. Cualquiera que llamara a la cadena literal obtuvo una ventana de contexto cuadruplicada y una superficie de parámetros distinta sin cambiar una línea de código; y, como la documentación del proveedor señala que los identificadores de modelo desconocidos no se rechazan, un pin mal escrito se sigue sirviendo y facturando como Pareto en lugar de fallar de forma evidente.

Si en cambio estabas en la línea de vista previa, ese camino está cerrado: Unbiased dijo a los usuarios de la vista previa que se pasaran a pareto o a pareto-26.10. Si estabas en pareto y dabas por sentada la estabilidad, esa suposición ahora es visible en tus propios registros, haya causado un problema o no.

De cualquier manera, la solución es la misma y requiere una sola línea: nombra la versión que probaste. Una cadena cualificada por versión es lo que hace que un modelo de costes se pueda restar y que una regresión sea atribuible, y es el único mecanismo que este proveedor te ofrece para cualquiera de las dos cosas.

¿Qué sigue sin verificar?

No hay ningún benchmark independiente para ninguno de los dos lanzamientos. Artificial Analysis no tiene una página para ninguno de los dos, y ningún evaluador ha publicado una nueva ejecución del arnés del proveedor. Cada cifra de esta comparación —las cuatro puntuaciones, las cifras de coste por tarea, las ventanas de contexto— o bien está publicada por el proveedor o bien se ha tomado del registro técnico del modelo, y las puntuaciones en concreto llevan las propias etiquetas del proveedor: «preliminar» y «no validado de forma independiente».

Eso no es una razón para evitar ninguno de los dos modelos. Es una razón para decidir sobre las cosas que son verificables: si tu carga de trabajo cabe en 262K, si tu pipeline necesita response_format y si quieres estar en el alias o en un pin. Esas tres preguntas tienen respuesta. Cuál modelo es mejor no la tiene, y ninguna cantidad de lectura de la ficha publicada producirá una.