Opus 5 vs GPT-5.6 vs Kimi K3: qué modelo para qué trabajo
DominicodeUn lunes cambié el modelo de un agente que llevaba semanas funcionando bien. El nuevo costaba la mitad por millón de tokens de salida: quince dólares contra veinticinco. Una línea de configuración, cinco segundos, dinero ahorrado.
El viernes miré la factura. Había subido.
No era un bug del proveedor. Era que la tarifa por millón de tokens no te dice cuántos tokens vas a gastar, y ese segundo número decide lo que pagas.
De eso va esta comparativa de Opus 5 vs GPT-5.6 vs Kimi K3: de trabajo real, no de specs. De cada modelo por separado ya hay un análisis en este blog. Aquí hay una sola pregunta, repetida cuatro veces: para este trabajo concreto, ¿cuál de los tres y por qué?
Opus 5 vs GPT-5.6 vs Kimi K3: los tres de un vistazo
| Claude Opus 5 | GPT-5.6 Sol | Kimi K3 | |
|---|---|---|---|
| Entrada / salida por millón | $5 / $25 | $5 / $30 | $3 / $15 |
| Contexto | 1M tokens | 1,05M tokens | 1M tokens |
| Intelligence Index | sin medición pública | 58,9 | 57 |
| Pesos | cerrados | cerrados | abiertos |
| Rasgo diferencial | thinking adaptativo por defecto | contexto de 1,05M y tres tiers de precio | pesos abiertos: cualquiera puede servirlo |
Esa tabla no decide nada. La pongo porque es lo que vas a encontrar en los otros veinte posts que has leído esta semana, y porque quiero enseñarte por qué te lleva a la decisión equivocada.
Un apunte que me niego a esconder: Opus 5 no tiene medición pública en el índice independiente de Artificial Analysis. Salió el 24 de julio de 2026, después de la última ronda de medición.
Las referencias que sí existen: Claude Fable 5 puntúa 59,9 costando unos $50 por millón de salida, y Claude Opus 4.8 —la generación anterior de la misma familia— puntúa 56.
Opus 5 está por encima de ese 56, probablemente bastante. Pero "probablemente" no es un número y no voy a inventármelo.
El truco del precio: por qué el orden se invierte
Kimi K3 parece el barato. Quince dólares por millón de salida contra los veinticinco de Opus 5 y los treinta de Sol. Mitad de precio que el más caro.
El problema es que un modelo no te cobra por millón de tokens: te cobra por los tokens que emite. Y cuánto emite para resolver la misma tarea es una propiedad del modelo, igual que su precio.
En el análisis de Kimi K3 salió el dato medido: durante la evaluación independiente, Kimi K3 consumió 130 millones de tokens de salida frente a una media de 63 millones. Eso es 2,06 veces la media. Su coste efectivo por millón de tokens útiles no es $15, es $15 × 2,06 ≈ $31.
Míralo sobre una tarea concreta. Supón un trabajo que requiere 100.000 tokens de salida útiles:
| Modelo | Tokens que emite | Precio salida | Coste |
|---|---|---|---|
| Claude Opus 5 | 100.000 | $25 / M | $2,50 |
| GPT-5.6 Sol | 100.000 | $30 / M | $3,00 |
| Kimi K3 (a precio de lista) | 100.000 | $15 / M | $1,50 |
| Kimi K3 (verbosidad medida 2,06×) | 206.000 | $15 / M | $3,09 |
El barato acaba siendo el más caro de los tres. No por poco: $3,09 contra los $2,50 de Opus 5.
Ahora la parte incómoda. Estoy comparando una cifra medida contra dos cifras de lista, y eso no es justo. Opus 5 también gasta más de lo que sugiere su tarifa: el thinking viene adaptativo y activado por defecto, max_tokens es un tope duro que cubre razonamiento y respuesta juntos, y esos tokens de razonamiento se facturan como salida. Encima escribe respuestas más largas que la generación anterior por diseño. No existe medición pública de ese sobrecoste: cuando exista, su columna también subirá.
La conclusión que te llevas no es "Kimi es caro". Es esta: ninguno de los tres se paga a precio de lista, y el único que tiene el multiplicador publicado es Kimi. Cualquier comparativa que ordene los tres modelos por su tarifa está ordenando por el número equivocado.
Trabajo 1: agente de coding que corre largo
Para un agente de coding que corre durante horas, la elección es Claude Opus 5 en effort xhigh. No por la tarifa: porque en sesiones largas la verbosidad se compone en vez de sumarse, y lo que arruina la factura son los reintentos.
Sesiones de horas. Decenas de tool calls. Cada turno reenvía el contexto acumulado de todos los turnos anteriores.
Aquí la verbosidad deja de ser un coste lineal y se vuelve compuesto. El output del turno 3 es input del turno 4, del 5 y del 20. Un modelo que escribe el doble no te cuesta el doble en ese turno: te infla el contexto de todos los siguientes. Pagas esa respuesta larga una vez como salida y luego otras quince como entrada.
Kimi compensa parte con un cache hit agresivo a $0,30 por millón —un 90% de descuento—, pero el caching abarata reenviar el contexto, no lo hace más pequeño. El techo de la ventana llega igual, y llega antes.
Arrancar en xhigh es la recomendación de Anthropic para coding y trabajo agéntico, y coincide con lo que veo trabajando: en sesiones largas lo que arruina la factura no son los tokens, son los reintentos. Una tarea que el modelo barato tiene que repetir tres veces cuesta más que una que el caro resuelve a la primera.
Un aviso, porque migrar a Opus 5 no es cambiar el string del modelo. Si vienes de Opus 4.8, hay dos cambios que rompen código: el thinking viene activado por defecto y desactivarlo con effort xhigh o max devuelve un 400. Los dos, con el código antes y después, están en los breaking changes de Claude Opus 5. Revísalos antes de mover tráfico.
Y si al medir descubres que buena parte de tu agente nunca necesitó un modelo frontera —pasa más de lo que la gente admite—, Claude Sonnet 5 cubre ese terreno por mucho menos dinero. Enrutar por dificultad de tarea ahorra más que elegir bien el modelo caro.
Trabajo 2: una pasada grande sobre un repo grande
Para trabajo input-heavy de una sola pasada, Kimi K3 es genuinamente el más barato de los tres. Es el caso donde la tabla de precios acierta: el peso está en la entrada y la verbosidad solo penaliza la salida.
Metes 800.000 tokens de código, pides un análisis de arquitectura o una migración planificada, y recoges veinte mil tokens de informe.
Aquí se invierte todo lo anterior. El peso está en la entrada, no en la salida, y la verbosidad solo castiga la salida.
Con esos 800K de entrada: Opus 5 y Sol cobran $5 por millón, o sea $4,00 cada uno. Kimi cobra $3: $2,40. La salida es tan pequeña en comparación que el multiplicador de verbosidad casi no mueve la aguja.
Ahí no hay trampa que deshacer: el número de la tabla de precios es el número que pagas.
La ventana de contexto se sobrevende. Lo que sí importa es que Anthropic cobra la ventana completa de 1M a tarifa estándar, sin recargo por contexto largo. Y si tu repo no cabe en 1M, tu problema no es el modelo: es que necesitas trocear e indexar antes de preguntar.
Aquí los pesos abiertos de Kimi valen algo concreto, y no es lo que la gente cree: cualquier proveedor puede servirlo, así que no dependes de un único vendor para el precio, la disponibilidad ni la política de retención. Eso presiona a la baja lo que te cobran.
Trabajo 3: volumen alto y simple
Clasificar diez mil tickets. Extraer entidades de un lote de documentos. Normalizar un CSV enorme a JSON.
La respuesta correcta a "¿cuál de los tres?" es ninguno de los tres.
Los números, sobre 10.000 documentos de 2.000 tokens de entrada y 200 de salida cada uno (20M y 2M en total):
| Modelo | Entrada 20M | Salida 2M | Total |
|---|---|---|---|
| GPT-5.6 Luna | $20 | $12 | $32 |
| Kimi K3 (lista) | $60 | $30 | $90 |
| Kimi K3 (verbosidad 2,06×) | $60 | $61,80 | $121,80 |
| Claude Opus 5 | $100 | $50 | $150 |
| GPT-5.6 Sol | $100 | $60 | $160 |
Luna sale cinco veces más barato que Sol en un trabajo donde la diferencia de inteligencia entre ambos es irrelevante, porque la tarea no pide razonar: pide seguir un formato. Y bajas otro 50% mandándolo por Batch API si no necesitas la respuesta en caliente. El desglose de las tres variantes está en la guía de la API de GPT-5.6.
Una honestidad sobre mi propia tabla: ese 2,06× se midió en evaluaciones difíciles, no clasificando tickets. Si fuerzas un esquema de salida estricto, la verbosidad se desploma en cualquiera de los tres. Que es justo lo que deberías hacer, porque el error caro aquí no es el modelo: es confiar en que la salida llegue bien formada. Valídala con un esquema y falla ruidosamente cuando no encaje —es lo que enseño en el curso de Zod, y un parseo estricto en la frontera evita más incidencias que cualquier upgrade de modelo.
Trabajo 4: orquestación y tool calling
Aquí esperaba encontrar el argumento que le da la vuelta al precio de GPT-5.6 Sol. Me equivocaba, y prefiero contarlo que maquillarlo.
Programmatic Tool Calling deja que el modelo escriba código que se ejecuta en un sandbox aislado y coordine varias llamadas a herramientas dentro de un mismo turno, sin ida y vuelta a la API entre cada una. Los resultados intermedios de las herramientas no entran en el contexto: solo entra el resultado final. La mecánica está en la guía de la API de GPT-5.6.
El problema para esta comparativa es que no es exclusivo de OpenAI. Anthropic tiene la misma función, con el mismo nombre, y claude-opus-5 aparece en su tabla de modelos compatibles. No desempata nada.
Y ahora fíjate dónde cae el ahorro, porque es donde casi todo el mundo se equivoca. Anthropic mide un 37% menos de tokens en tareas complejas de research —de 43.588 a 27.297 de media— y un 24% menos de tokens de entrada en benchmarks de búsqueda agéntica.
De entrada. No de salida. Tiene todo el sentido: lo que se recorta son los resultados intermedios que ya no viajan al contexto. Así que quien te presente esto como un descuento sobre la tarifa de salida está moviendo el número a la columna equivocada — justo el truco que denuncié dos secciones más arriba.
Por cierto: OpenAI no publica ningún porcentaje para su implementación. Su guía dice que el efecto depende de la tarea y de las respuestas de las herramientas, y recomienda medir contra tu propia línea base. Si ves un rango concreto atribuido a OpenAI por ahí, pídele la fuente a quien lo publique.
Mi elección aquí es la misma que en el trabajo 1: Claude Opus 5. No porque gane el tool calling —empata—, sino porque a igualdad de función te lo llevas con la tarifa de salida más baja de los dos: $25 contra $30.
El criterio que sí sirve
Una sola métrica: coste por tarea resuelta.
coste por tarea resuelta = coste medio por intento / tasa de éxito
Los reintentos dominan el resultado y no aparecen en ninguna comparativa. Con números que me invento a propósito, para que veas la forma y no para que te los creas: un modelo a $31 efectivos con un 80% de acierto sale a $38,75 por tarea resuelta; otro a $25 con un 95% de acierto sale a $26,32. El que parecía el caro por tarifa de lista sale un 32% más barato por tarea resuelta. Pon tus tasas reales, que solo tú las tienes.
Para medirlo necesitas dos cosas. La primera, una definición escrita de qué significa "resuelto": los tests pasan, el diff no toca ficheros fuera de alcance, el JSON valida contra el esquema. Escribir eso antes de medir es literalmente una spec, y es la mitad del método que desarrollo en el libro de Spec-Driven Development.
La segunda, correr esas evals con tus prompts y tu andamiaje. Y ojo, porque es lo que más gente ignora: el harness que envuelve al modelo cambia el resultado tanto como el modelo. Si cambias las dos variables a la vez, no has medido nada.
Es el mismo criterio que aplico en el curso Construye con IA: montar la eval antes de elegir el modelo, no después de que llegue la factura.
Veredicto: qué modelo para qué trabajo
Trabajas con un agente de coding a diario. Claude Opus 5 en xhigh, y enruta a Sonnet 5 todo lo que tus evals demuestren que no necesita frontera. El ahorro real está en el enrutado, no en la tarifa.
Tu carga está dominada por herramientas encadenadas. Cualquiera de los dos cerrados, pero enciende el tool calling programático: el ahorro está en la función, no en la marca del modelo. Mídelo un mes contra tu factura anterior mirando solo la línea de tokens de entrada, que es donde cae. Si no se mueve, tu flujo no era tan tool-heavy como creías.
Procesas repos o corpus grandes de una pasada. Kimi K3. Aquí el precio bajo de entrada es real, la verbosidad apenas te toca, y los pesos abiertos te quitan la dependencia de un único proveedor.
Clasificas, extraes o transformas en masa. Ninguno de los tres. GPT-5.6 Luna o un modelo de gama baja, con esquema estricto y Batch API. Frente a Sol, eso es un 80% menos de factura.
Necesitas el techo absoluto de inteligencia y el coste es secundario. Claude Fable 5, a 59,9 y unos $50 por millón de salida. Es un caso raro. Si crees que es el tuyo, mídelo antes: casi nunca lo es.
Haz una cosa hoy. Coge las diez últimas tareas que le mandaste a tu agente, córrelas contra dos modelos con el mismo harness y anota dos columnas: coste total y cuántas salieron bien a la primera. Divide. En media hora sabrás más que leyendo comparativas durante un mes.
Es lo que hacemos, modelo a modelo, en Dominicode Labs.
Preguntas frecuentes sobre Opus 5, GPT-5.6 y Kimi K3
¿Cuál es más barato entre Opus 5, GPT-5.6 y Kimi K3?
Depende de si miras el precio de lista o el coste real por tarea. Por tarifa gana Kimi K3: $3 de entrada y $15 de salida por millón, frente a $5/$25 de Opus 5 y $5/$30 de GPT-5.6 Sol. Pero Kimi emite 2,06 veces los tokens de la media medida, lo que sitúa su coste efectivo de salida en unos $31 por millón, por encima de los otros dos. Con una salvedad que hay que decir: 2,06× es una cifra medida y las de Opus 5 y Sol son de lista. Los tres gastan más de lo que sugiere su tarifa —Opus 5 razona por defecto y factura ese razonamiento como salida—, pero Kimi es el único con el multiplicador publicado. En trabajo dominado por la entrada —repos grandes, documentos largos— Kimi sí es genuinamente el barato, porque la verbosidad solo penaliza la salida.
¿Por qué Opus 5 no tiene puntuación en el Intelligence Index?
Porque se publicó el 24 de julio de 2026, después de la última ronda de medición del índice independiente de Artificial Analysis. Los puntos de referencia disponibles son Claude Opus 4.8 con 56 y Claude Fable 5 con 59,9. Que falte la medición del modelo más nuevo no es un detalle menor: durante las primeras semanas solo tienes los benchmarks del fabricante, y esos se publican siempre en el escenario que más favorece.
¿Qué modelo elijo para un agente de coding que corre durante horas?
Claude Opus 5, arrancando en effort xhigh, que es lo que recomienda Anthropic para coding y trabajo agéntico. La razón no es la tarifa: en sesiones largas el output de cada turno se convierte en input de todos los siguientes, así que la verbosidad se compone en lugar de sumarse. Y lo que arruina la factura son los reintentos: una tarea que hay que repetir tres veces con el modelo barato cuesta más que una que sale a la primera con el caro.
¿Qué gano realmente con Programmatic Tool Calling?
Que el modelo escriba código en un sandbox aislado para coordinar varias llamadas a herramientas en un solo turno, en vez de ir y volver a la API entre cada una. Los resultados intermedios de las herramientas no entran en el contexto, así que el ahorro cae sobre los tokens de entrada, no sobre los de salida. Anthropic mide un 37% menos de tokens en tareas complejas de research y un 24% menos de tokens de entrada en benchmarks de búsqueda agéntica; son cifras del propio fabricante, no de un tercero, y OpenAI no publica ningún porcentaje para su implementación. Sobre todo: no es un diferenciador entre modelos, porque tanto GPT-5.6 como Claude Opus 5 lo soportan.
¿Cómo calculo el coste por tarea resuelta en mi proyecto?
Divide el coste medio por intento entre tu tasa de éxito. Para eso necesitas antes una definición escrita de qué significa "resuelto" en tu caso —tests en verde, diff dentro del alcance previsto, JSON que valida contra su esquema— y correr las mismas tareas con el mismo harness para todos los modelos que compares. Si cambias de modelo y de andamiaje a la vez, no estás midiendo el modelo: estás midiendo el ruido.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.