Kimi K3 vs Claude Fable 5 vs GPT-5.6 Sol: ¿qué modelo probar primero?

Empieza por Kimi K3 cuando necesites margen para muchas iteraciones y el coste sea la restricción principal. Usa GPT-5.6 Sol como referencia cuando busques un equilibrio entre capacidad, herramientas y precio. Reserva Claude Fable 5 como escalado premium para tareas largas y difíciles en las que una decisión arquitectónica equivocada cuesta más que los tokens adicionales.

A 17 de julio de 2026, la API de K3 está disponible, pero Kimi programa la publicación de los pesos completos para el 27 de julio. Por tanto, hoy no es una opción verificable de autoalojamiento. En la API de OpenAI, el alias gpt-5.6 apunta actualmente a gpt-5.6-sol. Conviene fijar el ID real, no solo el nombre comercial, antes de comparar.

Una tabla pública no autoriza una migración. Congela el mismo commit, instrucciones, permisos, presupuesto, pruebas y criterio de revisión. Después cuenta reintentos, latencia, minutos de revisión y recuperación de fallos además de la factura de tokens. La ruta correcta es la más barata que supera el mismo trabajo de forma estable y respeta las políticas del equipo.

Iguala las condiciones API antes de mirar los resultados

Los tres modelos comparten promesas de contexto largo, programación y trabajo agéntico, pero no son endpoints intercambiables. Precio, salida máxima, herramientas, salto de tarifa en contexto largo, rechazo, fallback, retención de datos y futura opción de autoalojamiento pueden cambiar una decisión aunque dos respuestas parezcan igual de buenas.

Las fuentes de esos datos volátiles son el anuncio de K3, la documentación del modelo Sol y la documentación de Fable. Son precios de lista de la API directa, no cuotas de una suscripción de consumo ni precios de un router externo.

Una petición con 100.000 tokens de entrada sin caché y 20.000 de salida cuesta $0,60 en K3, $1,10 en Sol y $2,00 en Fable, antes de herramientas, reintentos y revisión. Es una razón para probar K3 primero, no una prueba de que terminará la tarea al menor coste. Una respuesta barata que falla las pruebas y obliga al revisor a reconstruir el parche todavía no es un trabajo aceptado.

Sol ocupa la franja intermedia, pero su economía de contexto largo tiene un corte. Una petición de 270K y otra de 275K son casi iguales en tamaño y, sin embargo, entran en regímenes distintos. Si un agente devuelve en cada turno el repositorio completo, el historial de herramientas y los archivos generados, mide p50, p95 y máximo de tokens de entrada en lugar de confiar en la ventana nominal de 1,05M.

Fable añade condiciones propias. Anthropic explica que algunas negativas pueden llegar con HTTP 200 y stop_reason: refusal; una configuración de fallback puede cambiar qué modelo completa realmente la solicitud. La retención de 30 días y la falta de zero data retention pueden ser un límite absoluto para repositorios sensibles, aunque el resultado técnico sea bueno.

Elige la primera prueba según el tipo de trabajo

Prueba K3 primero cuando puedas descartar resultados débiles con rapidez. Es un inicio razonable para clasificación del repositorio, varias propuestas de implementación, iteraciones de frontend y correcciones rutinarias protegidas por pruebas. Los pesos previstos abren una futura evaluación de autoalojamiento, pero hasta comprobar archivos, licencia, memoria y stack de inferencia después del 27 de julio siguen siendo una opción futura.

K3 deja de ser económico cuando el precio bajo produce más bucles de reparación. Si una persona tiene que deducir qué quería hacer el parche, la tarea no está aceptada. Cambia a Sol cuando, sobre el mismo conjunto, reduce claramente la recuperación y esa mejora supera la diferencia de tarifa.

Prueba Sol primero cuando necesites una línea base neutral. OpenAI lo sitúa como el nivel insignia de GPT-5.6 y ofrece contexto largo, salida de 128K y una superficie actual de herramientas. Para un equipo que ya evalúa con Codex, el resultado pertenece tanto al modelo como al agente que selecciona archivos, llama herramientas, administra contexto y comprueba cambios.

Sol tampoco es automáticamente la mejor relación entre precio y resultado. El razonamiento y los bucles de herramientas amplían la salida; las entradas largas cambian la tarifa de toda la petición. Solo merece ser el valor por defecto si la tasa de aceptación, el tiempo de revisión y la estabilidad operativa justifican el sobrecoste respecto a K3.

Usa Fable como escalado para una clase definida de problemas difíciles. Depuración ambigua, cambios en muchos archivos, decisiones de arquitectura y trabajos largos donde una dirección equivocada pierde horas son buenos candidatos. La prima se justifica únicamente cuando Fable rescata fallos de las rutas baratas, acorta revisión sénior o evita reversiones costosas de forma repetible.

Guarda en el registro tanto el modelo solicitado como el que realmente completó la tarea. Un éxito ayudado por fallback es útil en producción, pero no demuestra que Fable puro produjera el resultado. Separa una medición sin fallback de la configuración operativa si necesitas atribución o reproducibilidad.

Entiende por qué el ganador cambia con la configuración

Un resultado de programación se interpreta mejor así:

resultado observado = modelo + entorno del agente + presupuesto de razonamiento + herramientas + fallback + configuración de prueba

Las notas del lanzamiento de K3 hacen visible el problema. En distintas filas, K3 usa KimiCode, Fable usa Claude Code o Terminus y a veces fallback, mientras Sol usa Codex. Colocar los nombres en tres columnas no convierte las ejecuciones en equivalentes.

Es una comparación propiedad de Kimi, no un ranking neutral. Demuestra que trabajo y stack cambian al ganador; no demuestra que uno gane en general.

Una medición independiente ofrece otra vista, pero también exige leer el nombre completo de la configuración. El 17 de julio, Artificial Analysis mostraba K3 con 57 en Intelligence Index v4.1, Sol Max con 59 y Fable con 60 bajo “Adaptive Reasoning, Max Effort, Opus 4.8 Fallback”.

Un punto de índice importa menos que fallback, agente, consumo de tokens y coste de medición. Fable incluye fallback en la configuración mostrada, Sol está ligado a Codex y K3 gastó más tokens de salida que los otros dos en el conjunto. Ninguno predice la tasa de aceptación de tu repositorio.

Calcula el coste total por tarea aceptada

Una tarea aceptada ha superado controles automáticos y el umbral de revisión del equipo. Convierte las tarifas con esta fórmula:

coste total = (API + herramientas + infraestructura por intento) / tasa de aceptación + tiempo de revisión + recuperación esperada de fallos

La tasa debe proceder del mismo conjunto. No compares tareas fáciles de K3 con tareas difíciles de Fable ni un Sol con caché frente a rivales sin caché. Aunque el proveedor no cobre una petición fallida, herramientas, cola, fallback y atención humana siguen teniendo coste.

Supongamos una tarea con 100K de entrada sin caché y 20K de salida. El intento cuesta $0,60, $1,10 y $2,00. Ahora asumimos —no medimos— tasas de aceptación del 80%, 90% y 94%, revisión de ocho, seis y cinco minutos y un coste interno de $60 por hora.

El ejemplo explica el método, no afirma esas eficiencias. Un token barato puede perder tras reintentos; un modelo premium también pierde si la mejora real es menor que la supuesta. Sustituye todas las tasas y minutos por datos propios. Para tarifas de otros proveedores, descuentos batch, routers y presupuesto mensual, consulta la comparativa de precios de API LLM sin mezclarla con esta prueba de carga.

Ejecuta una evaluación reproducible en el mismo repositorio

Antes de migrar, congela el trabajo para que el modelo sea la variable principal.

1. Elige 30–50 tareas de un único commit: cambios rutinarios, ediciones en varios archivos, diagnóstico, fallos de herramientas, contexto largo y algunos casos que exigieron revisión sénior.
2. Usa las mismas instrucciones, permisos, red, sandbox, timeouts y estado del repositorio. Registra el entorno del agente y su versión.
3. Asigna un presupuesto documentado de razonamiento o tokens. Si activas adaptive thinking, max effort o fallback, muéstralo en el resultado.
4. Define la aceptación antes de ejecutar: build, tests, lint, tipos, seguridad, aserciones de la tarea, archivos permitidos y rúbrica humana.
5. Ciega la revisión cuando sea posible. Registra aceptación, reintentos, tokens, tiempo, fallos de herramientas, minutos de revisión y regresiones que exijan revertir.
6. Repite una parte estable otro día. Capacidad y routing de la semana de lanzamiento pueden deformar una instantánea corta.

No ajustes una prueba distinta hasta que gane cada modelo. Puede haber configuración específica para una comparación productiva, pero cada excepción debe quedar escrita: prompt adicional, recorte de contexto, effort, fallback y retry. Sin esa información no se reproduce la decisión.

La evaluación debe responder por separado qué modelo pasa el trabajo normal al menor coste, cuál rescata los casos difíciles, qué fallos son del modelo y cuáles del agente, y qué límite operativo cambia el despliegue. Si migras una integración anterior, los IDs y rutas de K2 están en la guía de la API Kimi K2. No mezcles esa migración con la comparación de K3, Sol y Fable.

Define cuándo promover, escalar, esperar o revertir

Promueve K3 para el tráfico normal cuando no tenga regresiones críticas, quede dentro del margen acordado respecto a Sol y conserve un ahorro real tras reintentos y revisión. Mantén Sol o Fable para tareas que superen el umbral de complejidad.

Mantén Sol como valor por defecto cuando mejore de forma material la aceptación o el tiempo de revisión frente a K3, las herramientas sean estables y la ventaja sobreviva al multiplicador de contexto largo. Escala casos concretos en vez de pagar Fable para todo.

Escala a Fable cuando rescate una clase definida de fallos o reduzca suficiente revisión sénior. Registra el fallback. Para datos incompatibles con la retención actual, la política puede prohibirlo con independencia de la calidad.

Pausa la migración si la diferencia no se repite, las configuraciones no son comparables o el aparente ganador crea un nuevo fallo. Un empate con operaciones inciertas favorece mantener la ruta existente.

Revierte si suben las regresiones críticas, el coste por tarea supera el baseline, p95 rompe el presupuesto de latencia, se agrupan fallos de herramientas o se viola la política de datos. Conserva ruta anterior y corpus hasta que la nueva supere un slice monitorizado.

K3 necesita otra comprobación después del 27 de julio: verificar los pesos reales, licencia, memoria y requisitos de serving, y repetir el mismo trabajo en el stack previsto. Poder descargar archivos inicia la evaluación de autoalojamiento; no garantiza el coste ni la velocidad de la API alojada.

Preguntas frecuentes

¿Kimi K3 es mejor que Fable 5 y GPT-5.6 Sol en general?

No. K3 tiene el menor precio directo actual y lidera algunas filas publicadas por Kimi; Sol y Fable lideran otras. Agente, esfuerzo, fallback, tokens y trabajo cambian el resultado. K3 es una primera prueba económica, no un campeón universal.

¿Puedo autoalojar los pesos de Kimi K3 ahora?

No a 17 de julio de 2026. Kimi programa los pesos completos para el 27. Después habrá que revisar licencia, memoria, inferencia y comportamiento sobre tareas propias antes de considerarlo producción.

¿Cuándo compensa el precio de Claude Fable 5?

Cuando una mejora medida en trabajos largos reduce fallos, reintentos o revisión sénior lo suficiente para cubrir $10 de entrada y $50 de salida, y cuando fallback, refusal, retención de 30 días y falta de ZDR encajan.

¿GPT-5.6 Sol ofrece la mejor relación calidad-precio?

Es una referencia equilibrada, especialmente si Codex forma parte de la prueba. No es automáticamente el menor coste: superar 272K cambia toda la petición y un K3 que pase el mismo trabajo puede resultar más barato.

¿Con qué modelo empiezo para programar?

Sin datos internos, usa Sol como referencia, compara K3 en el trabajo normal y reserva Fable para los fallos más difíciles. Si el presupuesto manda, empieza por K3 y sube a Sol solo cuando la misma prueba demuestre que falta calidad.

La decisión durable no es un nombre, sino una regla de routing: empieza por el candidato razonable más barato, promuévelo solo tras superar el mismo trabajo, escala casos difíciles definidos y conserva una reversión.