Kimi K3 compite con Fable, y la combinación de ambos modelos logra un rendimiento de primer nivel

• Al comparar Kimi K3 y Fable 5 en unas 1,030 tareas de agentes, el enrutamiento por tarea logró una calidad superior a la de cada modelo por separado, con 93% de precisión
• En tareas de SWE, terminal, algoritmos, multilenguaje y legales, el rendimiento general fue similar, pero las áreas de trabajo donde cada modelo mostraba fortalezas eran distintas
• El enrutamiento oráculo asignó entre 72% y 96% de las tareas a K3, y K3 fue más eficiente en costos que Fable en los 5 grupos de tareas
• En bucles largos de agentes, K3 mostró una eficiencia de costos de hasta 50 veces mayor que usar solo Fable, aunque más pasos de ejecución pueden alargar el tiempo de procesamiento
• Un router adaptado a la carga de trabajo que use un modelo abierto barato como base y envíe las tareas más difíciles a otro modelo puede mejorar a la vez calidad y costo

---

Medido con tareas reales de agentes

• Kimi K3 y Fable 5 se ejecutaron en el mismo harness para realizar unas 1,030 tareas en formato de bucles reales de agentes
  • SWE: 460 tareas similares a corregir bugs en repositorios reales
  • Terminal: 89 tareas de agentes de larga duración en seguridad, criptografía, ingeniería inversa, administración de sistemas y más
  • Algoritmos: 100 problemas del tipo LeetCode y AtCoder
  • Multilenguaje: 225 tareas de implementación en 6 lenguajes
  • Legal: 120 tareas de agentes legales evaluadas por abogados
• Se compararon ambos modelos promediando los resultados de benchmark sobre varios tipos de tareas

Qué significa el enrutamiento oráculo y cuáles son sus límites

• El enrutamiento oráculo es una forma teórica de medición en la que se ejecuta cada tarea en todos los modelos y luego se elige el modelo más barato entre los que dieron la respuesta correcta
• Como un router real no puede ejecutar de antemano la tarea en varios modelos, debe predecir por adelantado cuál ofrece el mejor equilibrio entre costo y calidad
• En este enfoque, K3 fue elegido en 72% a 96% del total de tareas
• Podría ser posible un router que distinga entre tareas cotidianas y las tareas de cola larga que requieren modelos de primer nivel
  • Para confirmarlo, se necesita 10 veces más datos de enrutamiento que una muestra de un solo dígito, además de validar el rendimiento en entornos reales

El rendimiento general es parecido, pero las fortalezas son distintas

• En un resultado representativo de SWE, K3 obtuvo 92.4% y Fable 92.6%, casi lo mismo
• También en los 5 tipos de tareas, la diferencia entre ambos modelos fue por lo general de apenas unos puntos porcentuales, aunque Fable estuvo un poco por delante en el rango de programación multilenguaje
• A pesar de tener puntajes generales similares, en las tareas detalladas cada modelo mostró áreas donde era claramente superior

Diferencias por área de trabajo

• Al dividir SWE por dominio del problema, K3 fue mejor en matemáticas simbólicas y herramientas de desarrollo, mientras que Fable se impuso en tareas web y de visualización de datos
• En tareas multilenguaje, Fable estuvo por delante en Java, Python y C++, mientras que K3 fue competitivo en JavaScript y Rust
• En tareas largas de terminal que implican manipular el shell decenas de veces, K3 mostró fortalezas
  • Resolvió hash de 7z, criptoanálisis de FEAL, secretos filtrados, vulnerabilidades reales y tareas asíncronas fuera de control que Fable no pudo resolver
• Al comparar precisión y costo en conjunto, Fable estuvo por delante en multilenguaje, K3 en terminal y legal, y en el resto estuvieron en general parejos

La estructura que genera la brecha de costos

• La ventaja de costo de K3 proviene del precio por token, el caching de prompts y el volumen de uso por tarea
• Por cada tarea de SWE, K3 usó unas 55 vueltas y 1.3 millones de tokens, mientras que Fable usó unas 21 vueltas y 130 mil tokens
• En tareas largas de terminal ocurrió lo contrario: Fable llegó a usar unas 64 vueltas y 1.5 millones de tokens, y a veces alcanzó el timeout
• Aunque K3 leyó 10 veces más tokens en SWE, su costo de ejecución fue menor que el de Fable gracias al acierto del caché de prompts
• Si aumentan los pasos de ejecución, el tiempo real de procesamiento puede alargarse
  • En tareas que deben responder en menos de 2 segundos, la latencia es importante
  • En agentes de fondo a gran escala, importa más una factura final más baja

El resultado de combinar ambos modelos

• Si cada tarea se envía al modelo más adecuado, no se obtiene un punto intermedio entre ambos, sino un rendimiento superior al de cualquiera de los modelos por separado
• El enrutamiento oráculo por tarea siempre mostró mejor rendimiento que ejecutar cada modelo por separado, y la precisión total llegó a 93%
• Incluso enviando entre 72% y 96% del tráfico a K3, el modelo optimizado por costo, la calidad total fue más alta que la de cada modelo y el costo quedó cerca de usar solo K3
• K3 fue más eficiente en costos que Fable en los 5 grupos de tareas, y en bucles largos de agentes registró una eficiencia de costos de hasta 50 veces mayor

Enrutamiento por carga de trabajo en vez de un solo modelo

• Enrutar Kimi K3 y Fable juntos permite aprovechar sus fortalezas distintas mientras se reduce el costo
• Como cada modelo tiene precios y áreas de especialidad diferentes, la IA de mayor calidad puede surgir de una combinación de varios modelos más que de un solo proveedor
• Se puede tomar como opción base un modelo abierto como K3, al que el oráculo asignó la mayor parte del tráfico y que tuvo costos hasta 50 veces más bajos
• El router debe ajustarse a la carga de trabajo real y seguir aprendiendo la relación entre tareas y la adecuación de cada modelo

[GN⁺]

Comentarios en Hacker News

• Si los ejecutas y pruebas tú mismo, todos estos modelos están sobreajustados a los benchmarks. Aunque se acerquen a modelos de frontera en alguna métrica, se derrumban en tareas reales y su eficiencia de tokens es ridículamente baja
  Fireworks obtiene grandes beneficios al alojar K3, a diferencia de los modelos cerrados, así que tiene un incentivo muy fuerte para poner ese tipo de titular

  • Después de probar durante varios días K3, Qwen 3.8 Max Preview, Fable y Sol, coincido en parte en que es difícil confiar en los benchmarks y en que los modelos chinos son lentos y tienen baja eficiencia de tokens
    Aun así, están más o menos al nivel de los mejores modelos de la generación anterior, Opus 4.8 y GPT 5.5, y también se pueden comparar en https://senko.net/vibecode-bench/
    Usando la API oficial y las herramientas de programación de cada uno, les pedí crear una app web simple pero nada trivial solo a partir de una especificación detallada, y en pruebas con usuarios los resultados de K3, Qwen 3.8 y Fable fueron casi iguales; en la revisión de código de Sol todos cumplieron bien, aunque Fable quedó un poco por delante
    En trabajo real sigo prefiriendo Opus 4.8 y Sol, pero si hace falta una alternativa, K3 y Qwen 3.8 también son bastante utilizables
  • Todos están sobreajustados a los benchmarks, pero el punto clave es qué tanto están sobreajustados entre sí
    Evalúo principalmente capacidad de programación en entornos abiertos multiagente, donde los agentes se influyen entre sí y no hay conjunto de respuestas correcto; ahí los modelos chinos suelen rendir por debajo de lo que anuncian sus model cards frente a los modelos estadounidenses
    Kimi K3 es una excepción y de verdad está muy cerca de la frontera, pero es muy lento. Muse Spark 1.1 es el siguiente más fuerte después de Fable y Sol, y además el más eficiente en costo, así que hubo un gran cambio desde Llama 4. Los datos están en https://gertlabs.com/rankings
  • Fable funciona muy bien incluso en bases de código bastante grandes. Tuve que corregirlo o reencaminarlo algunas veces, pero casi siempre fue porque los requisitos del prompt eran insuficientes, y solo estuvo realmente equivocado unas dos veces, así que su tasa de error es menor que en toda mi carrera profesional
    La calidad del código está al nivel de lo que yo escribiría, y es mejor en áreas que no domino. También hace de forma constante tareas que la gente suele posponer o le resultan tediosas, como refactorización, pruebas de integración y regresión, y revisión de logs de auditoría y alertas de errores, elevando así el nivel general de la ingeniería de software
    Es un servicio real relativamente complejo en Ruby on Rails con PostgreSQL, y en el plan Max de 200 dólares al mes el presupuesto de tokens no fue problema; el costo vale totalmente la pena
  • No leí el artículo, pero ya desde el titular me pareció sospechoso que una empresa de servicios de inferencia destacara un modelo de nivel Mythos que ofrece en su propia plataforma. GLM 5.2, con menos de un tercio de los parámetros de Kimi K3, sigue siendo su modelo principal
  • A todas estas evaluaciones hay que ponerles la condición de por ahora. Viendo la tendencia, está claro que pronto llegarán a un nivel suficientemente bueno para programación, aunque todavía no estén ahí, y debemos prepararnos para un mundo donde los modelos abiertos realicen casi todo el trabajo de software

• Es interesante que hayan probado Kimi K3 y Fable en unas 1,000 tareas divididas en cinco áreas, como ingeniería de software y derecho
  Ponen al frente un modelo router para predecir qué modelo resolverá correctamente cada respuesta a menor costo, y creo que al final habrá que seguir entrenándolo con la carga de trabajo propia de cada quien
  El router eligió Kimi en 72~96% de las tareas según el área, logrando reducciones de costo de 1.5 a 50 veces dependiendo del campo

  • Aquí el router es un punto de referencia oráculo que ejecuta ambos modelos, verifica si pasan y luego elige el más barato
    Es solo una suposición de Fireworks: que se puede ahorrar costo si existe un router capaz de predecir eso de antemano, y la existencia de ese router es una premisa importante
  • Hay varios routers parecidos, como https://openrouter.ai/openrouter/auto

• Si un modelo conversa como persona, incluso aceptaría una caída del 5% en benchmark

  • Yo más bien prefiero modelos que no intenten hablar como personas
  • Ni siquiera hace falta sacrificar ese 5%; puedes pasar la salida de Fable por Gemini Flash para que la reescriba en frases más fáciles de leer
  • Prefiero firmemente que el modelo no imite mi tono humano. Que Claude actúe como si fuera tu amigo y responda LOL a una broma no solo es ridículo, sino hasta perjudicial
  • Opus por defecto produce un estilo que yo llamo claudés. Son frases demasiado simplificadas y gramaticalmente incompletas, dolorosas de leer; quizá sea fácil de leer y escribir para el modelo, pero no para los humanos
    Por ejemplo, mostró una guía larga de un artículo en una sola línea, densamente unida con fragmentos imperativos, palabras clave en negritas y flechas, como “échale un vistazo ahora y vuelve a consultarlo mientras lees la Parte II”
  • Los LLM no son humanos, así que no hay razón para que deban hablar como personas

• Anthropic parece el Imperio romano en cámara rápida: da la impresión de haber pasado su pico y entrado en fase de declive incluso antes de hacer su IPO

• Me pregunto cómo se aplican la gobernanza de datos y la privacidad al suscribirse al plan de codificación de Kimi K3. Quiero cambiarme desde Anthropic

  • Según https://platform.kimi.ai/docs/agreement/modeluse, el contenido puede usarse para prestar, mantener, desarrollar y mejorar el servicio, y los clientes que necesiten restricciones de entrenamiento deben discutir un contrato empresarial separado o un acuerdo por escrito
    A diferencia de Claude, no hay una opción de exclusión del entrenamiento del modelo, y según los términos Kimi puede usar el código del cliente para entrenamiento
  • Habrá que esperar hasta que proveedores occidentales empiecen a alojarlo
  • La forma más simple es registrarse en OpenRouter y excluir a todos los proveedores que no sean de retención cero de datos (ZDR). Aun así, las tarifas de la API pueden ser más caras que el plan de codificación, y los 1.7 mil millones de tokens incluidos en el plan mensual de 20 dólares de MiniMax valen entre 200 y más de 500 dólares en términos de API, según la proporción entre entrada, salida y caché
    Si no quieres tratar directamente con empresas chinas, AtlasCode por 20 dólares al mes, OpenCode Go por 10 dólares al mes y Cline Pass por 10 dólares al mes ofrecen de 2 a 6 veces más uso en algunos modelos populares de pesos abiertos
    Personalmente, estoy suscrito a Z.ai por 17 dólares al mes y pago tarifas de API a cada proveedor original por MiMo v2.5, Hy3, Qwen 3.7 Plus y DeepSeek v4
  • La política de privacidad puede revisarse en https://www.kimi.com/user/agreement/zh/userPrivacy

• Me pregunto si se puede cobrar por publicar textos como este para impulsar modelos abiertos y, de ser así, cuál sería el objetivo
  Por mi experiencia trabajando en productos SaaS modernos con FastAPI·Python y Spring Boot·Java, el único modelo abierto que fue bueno y eficiente fue Qwen 3.7 Max
  GLM 5.2 y Kimi suelen pasarse casi 70 mil a 80 mil tokens explorando la base de código antes de escribir código, y aun así muchas veces terminan rompiéndolo. Funcionan bien si les das especificaciones muy detalladas, como hace un año, pero Qwen 3.7 termina el trabajo sin mucho esfuerzo de mi parte

  • Es buen marketing de contenidos. Fireworks es un gran proveedor de inferencia de modelos que vende acceso a Kimi K3
  • Fireworks se especializa en ejecutar rápido modelos abiertos, y como obtiene la mayor parte de sus ingresos de modelos chinos, el incentivo económico coincide con todo su modelo de negocio
  • En el negocio de la influencia tecnológica hay mucho dinero, pero la mayor parte viene de grandes empresas, como la adquisición de tbpn por OpenAI o el acceso anticipado para algunos influencers
  • Lin Qiao es cofundador y CEO de Fireworks AI. Los LLM equivalen a la carrera espacial de la nueva guerra fría entre EE. UU. y China, así que el incentivo para demostrar superioridad nacional y civilizatoria podría ser mayor que el dinero

• Me pregunto si Kimi tiene algo especialmente mejor aquí. Entiendo que el precio es similar al de Sonnet 5, así que me pregunto qué pasa si usas Sonnet 5 y Fable, o el más barato Grok 4.5

  • El texto dice que Kimi es mejor que Fable en algunas tareas, pero probablemente eso no aplique frente a Sonnet
  • Los modelos abiertos tienen la ventaja de que las grandes empresas pueden ejecutarlos localmente y ajustarlos finamente en sus propios centros de datos

• Me gustan mucho los modelos chinos y uso DeepSeek casi exclusivamente, y ahora también uso Kimi K3 como una excelente ayuda de planificación para tareas avanzadas de programación
  DeepSeek v4 Flash es muy rápido y maneja casi todo lo que le he encargado en Rust, PostgreSQL, Angular y Terraform
  Alojo yo mismo Bifrost como gateway de LLM, pero ojalá las empresas cobraran automáticamente por el uso real mensual o diario, como un VPS, en lugar de prepago y recarga automática. Preferiría pagar solo por el uso exacto en vez de mantener saldos mínimos no reembolsables en varios proveedores
  OpenRouter ayuda, pero no me gusta el servicio en sí ni los cargos adicionales

  • Últimamente uso DeepSeek v4 Pro como modelo principal, y como tengo mucho trabajo en paralelo la velocidad importa menos. Si falla, en medio de la conversación cambio a GPT 5.5 para que encuentre el problema, luego dejo ese análisis en el contexto y vuelvo a DeepSeek
    Kimi k2.5/6 se volvió más lento y rindió peor, además aumentaron los errores engine overloaded; k3 razona por más tiempo pero los resultados no mejoran de forma notable. Creo que quizá cuantizaron temporalmente el modelo por presión en los recursos de cómputo
    Últimamente uso sobre todo DeepSeek v4 Pro y recurro a GPT 5.5 cuando necesito un modelo potente. GLM 5.2 fue bueno en algunas tareas pero muy malo en otras, y los modelos de Google o Anthropic todavía no me han impresionado
  • Si usas herramientas como reasonix o whale, puedes lograr una tasa de acierto de caché de alrededor del 98%, lo que hace que el costo por solicitud sea prácticamente casi gratis. Eso también es posible con proveedores estadounidenses sin subsidios, como Cloudflare o DigitalOcean
  • El prepago evita que los usuarios consuman grandes cantidades de recursos de inferencia, cancelen la tarjeta y desaparezcan. Un VPS es una inversión a más largo plazo, así que es más difícil cambiarse, y aunque algunos usuarios no paguen un mes, el costo para el proveedor es relativamente menor
  • Estoy evaluando Bifrost, así que me interesa saber por qué elegiste un gateway de LLM
    OpenRouter ofrece casi todos los modelos desde el día en que salen, pero lo atractivo de usar Bifrost es que, incluso si más adelante dejas OpenRouter, no necesitas tocar el resto de tu stack técnico. Si el autoalojamiento se vuelve viable, también puedes reducir la dependencia de OpenAI, Anthropic y OpenRouter, y disminuir el riesgo de que un modelo del que dependías sea retirado de repente
  • Me pregunto qué es lo que no te gusta del servicio de OpenRouter aparte de los cargos adicionales

• Una empresa de hosting de modelos abiertos diciendo que los modelos abiertos son excelentes

  • Publicaron la metodología y los resultados, y me permitió conocer fortalezas y debilidades relativas de Kimi y Fable que no había visto en otro lado. El hecho de que tengan un negocio de hosting de modelos no significa que pierdan el derecho a compartir resultados
  • Fireworks no aloja solo modelos de pesos abiertos, y que una gran noticia pueda atraer nuevos clientes no significa que el contenido sea falso
  • Quien los haya usado directamente sabrá que su evaluación es cierta

• Estoy buscando una herramienta de routing u otra buena plataforma de routing que pueda usarse con Claude Code, como se explica en el artículo. Entiendo que el router de este artículo usa un enfoque tipo oráculo.

  • https://github.com/code-yeongyu/oh-my-openagent implementa el patrón de oráculo del texto original en 11 roles.
    Para cada rol hay un ranking recomendado de LLM de varios proveedores; por ejemplo, usa Sisyphus (claude-opus-4-8 / kimi-k3 / glm-5) como orquestador principal.