Kimi K3: funciones, benchmarks, API y 5 ejemplos prácticos

La carrera de modelos abiertos dio otro giro el 16 de julio de 2026, cuando Moonshot AI lanzó Kimi K3, un modelo de 2,8 billones de parámetros con una ventana de contexto de 1 millón de tokens y visión nativa. Es el modelo abierto más grande que Moonshot ha publicado, muy por encima de Kimi K2 en tamaño, y el primero que describen como de la clase de 3 billones de parámetros.

Si quieres la historia del lanzamiento, el análisis de arquitectura, los gráficos de benchmarks, las comparativas con Claude, GPT y otros laboratorios chinos, y la lista de limitaciones de Moonshot, nuestro artículo del blog sobre Kimi K3 cubre todo eso. Este tutorial es la parte práctica: cómo acceder al modelo y cómo se comporta al usarlo. Verás cinco ejemplos pequeños, cuatro vía API (mostrando uso real de tokens y coste) y dos en la app web de kimi.com. En conjunto, verás cómo K3 gestiona:

• Llamadas a herramientas y retorno de JSON estricto
• Carga dinámica de una definición de herramienta
• Reducción del coste en contextos largos con caché automática
• Lectura de una captura de pantalla y corrección del layout
• Creación de un panel interactivo a partir de un único prompt

Los cuatro ejemplos con API se ejecutaron el 17 de julio de 2026 contra el modelo kimi-k3 y costaron unos 11 céntimos en una ejecución en frío, o un par de céntimos una vez activada la caché.

Cómo acceder a Kimi K3

La forma más rápida de probar el modelo es kimi.com, donde la app web y las apps móviles ejecutan Kimi K3 para tareas generales de agente sin configuración previa.

Para trabajos más pesados como informes y paneles, está Kimi Work, una app de escritorio.

Si vives en la terminal, Kimi Code es un agente de codificación que instalas desde npm como @moonshot-ai/kimi-code, y eliges el modelo allí con el comando /model. Usar K3 en Kimi Code requiere una suscripción de pago, y la ventana completa de 1 millón de tokens exige un plan superior.

Este tutorial se centra en la API en bruto y la app web, pero el agente de terminal está ahí si lo prefieres.

Eso sí, K3 no sustituye a sus hermanos. La tabla siguiente muestra cómo se reparte la gama actual.

En resumen, K3 es el modelo con el que empezar cuando una tarea combina código, herramientas, documentos e imágenes, o cuando de verdad necesitas la ventana de 1 millón de tokens. Para generación de código pura donde prima la velocidad sobre el contexto, kimi-k2.7-code sigue siendo la opción más sensata, así que no des por hecho que el modelo más nuevo es siempre el adecuado.

Configuración de la API de Kimi K3

La API es compatible con el SDK de OpenAI, así que si ya lo has usado, aquí casi no hay novedades. Necesitas Python 3.9 o superior y una clave de API.

Paso 1: generar una clave de API

Primero, inicia sesión en la plataforma Kimi y abre la página de API Keys en la consola. Crea una clave, cópiala una vez y guárdala en un lugar seguro, porque no volverás a verla. También necesitas un pequeño saldo en la cuenta para poder hacer llamadas; para todo este tutorial, con unos pocos dólares basta.

Creación de una API key de Kimi K3. Imagen del autor.

Paso 2: instalar el SDK

Después, instala el SDK de OpenAI en tu entorno. Un único comando lo hace.

python -m pip install --upgrade "openai>=1.0"

Con eso obtienes la librería cliente que usan el resto de ejemplos, y no hay nada específico de Kimi que instalar.

Paso 3: guardar la clave e inicializar el cliente

Es mejor leer la clave desde una variable de entorno que pegarla en tu código. Define MOONSHOT_API_KEY en tu shell o en un archivo .env y apunta el cliente a la URL base de Moonshot.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

Las dos únicas diferencias frente a una configuración estándar de OpenAI son la base_url y el nombre del modelo, que es kimi-k3. Con eso listo, ya puedes hacer una llamada.

Paso 4: tu primera llamada

Vamos con la primera petición. Le pedí al modelo que se presentara en una frase, y se convirtió en un pequeño momento de honestidad.

completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Introduce Kimi K3 in one sentence."}],
    max_completion_tokens=800,
)
print(completion.choices[0].message.content)

La respuesta fue una negativa educada a especular: el modelo dijo que no tenía información fiable sobre Kimi K3, ya que se entrenó antes de su propio lanzamiento, y me remitió a los anuncios de Moonshot. Es un buen recordatorio de que un modelo no sabe sobre sí mismo. La llamada a la API que acabo de hacer cuesta alrededor de siete décimas de centavo. Fíjate en el límite max_completion_tokens , que establecí en todas las llamadas de este tutorial para evitar que una salida prolija dispare la factura.

Primera salida de la API de Kimi K3. Imagen del autor.

Ejemplo 1: razonamiento en streaming y respuesta final

K3 siempre razona, y la API devuelve ese razonamiento en un canal separado de la respuesta. Al hacer streaming, cada fragmento puede llevar reasoning_content, content final o ambos, para que puedas ubicar por separado el pensamiento y la respuesta.

stream = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "A bat and a ball cost $1.10 together. The bat costs $1.00 more than the ball. How much is the ball?"}],
    max_completion_tokens=1200,
    stream=True,
    stream_options={"include_usage": True},
)

for chunk in stream:
    if not chunk.choices:
        continue
    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="", flush=True)
    if delta.content:
        print(delta.content, end="", flush=True)

El modelo hizo streaming de su razonamiento primero: reconoció el problema del bate y la pelota como el clásico Cognitive Reflection Test, señaló la respuesta intuitiva errónea de $0,10, luego resolvió el álgebra hasta que la pelota cuesta $0,05 y comprobó que $1,05 más $0,05 son $1,10. Lo útil es la separación: en una app real muestras content a los usuarios y guardas reasoning_content para logs, porque mostrar el razonamiento en bruto en producción rara vez es lo que quieres. Esta llamada usó 488 tokens de salida y costó menos de un centavo.

Razonamiento en streaming y después la respuesta final. Imagen del autor.

Ejemplo 2: llamadas a herramientas con salida estructurada

Kimi K3 es el modelo de la gama que admite tool_choice="required", que obliga a hacer al menos una llamada a herramienta en un turno. Es útil cuando quieres que el modelo recupere datos antes de responder en lugar de conjeturar. Aquí le di dos herramientas simuladas, una para precios y otra para stock, forcé una llamada a herramienta, ejecuté las herramientas localmente y luego pedí el resultado como JSON estricto usando response_format.

first = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    tools=TOOLS,
    tool_choice="required",
    max_completion_tokens=2500,
)
assistant_message = first.choices[0].message
messages.append(assistant_message)

for tool_call in assistant_message.tool_calls or []:
    args = json.loads(tool_call.function.arguments)
    messages.append({"role": "tool", "tool_call_id": tool_call.id, "content": run_tool(tool_call.function.name, args)})

El modelo llamó a ambas herramientas con el código de producto correcto y luego devolvió un resumen de pedido limpio en JSON: cinco teclados mecánicos a $89 cada uno, total de $445 y una marca de stock en true. Dos detalles hacen que esto funcione en la práctica. Debes añadir de vuelta el mensaje completo del asistente a la conversación antes de agregar los resultados de las herramientas, y debes parsear solo content para el JSON, nunca el campo de razonamiento. El par de llamadas costó en conjunto menos de un centavo.

Llamadas a herramientas y salida JSON estructurada. Imagen del autor.

Ejemplo 3: carga dinámica de herramientas

Si tienes docenas de herramientas, enviar todas sus definiciones en cada petición desperdicia tokens y ensucia el prompt. Kimi K3 te permite inyectar una definición de herramienta en mitad de la conversación con un mensaje system que lleva un campo tools y sin content. La herramienta queda disponible a partir de ese punto, lo que mantiene catálogos grandes de herramientas fuera de tu prefijo cacheado hasta que realmente se necesiten.

messages = [
    {"role": "user", "content": "Convert 100 US dollars to euros at a rate of 0.92."},
    {"role": "system", "tools": [{
        "type": "function",
        "function": {
            "name": "convert_currency",
            "description": "Convert an amount from one currency to another",
            "parameters": {
                "type": "object",
                "properties": {"amount": {"type": "number"}, "rate": {"type": "number"}},
                "required": ["amount", "rate"],
            },
        },
    }]},
]
completion = client.chat.completions.create(model="kimi-k3", messages=messages)
print(completion.choices[0].message.tool_calls)

K3 detectó la herramienta recién cargada y llamó a convert_currency con amount 100 y rate 0,92, tal y como se pretendía. Ten en cuenta que el servidor no conserva esta definición por ti, así que vuelve a enviar el mensaje de sistema en peticiones posteriores si quieres que la herramienta siga disponible. Esta fue la llamada más barata del conjunto, unos dos décimos de centavo.

Llamada a una herramienta de divisas cargada dinámicamente. Imagen del autor.

Ejemplo 4: recortar costes en contextos largos con caché

Aquí es donde la ventana de 1 millón de tokens se vuelve práctica. La caché de contexto es automática, sin ID de caché ni TTL que gestionar. Envías un prefijo grande, lo mantienes idéntico byte a byte en peticiones posteriores y la parte repetida se factura a precio de acierto de caché en lugar de fallo. Para que se viera la diferencia, usé una base de conocimiento de unas 33.000 tokens y lancé una pregunta sobre ella.

knowledge = Path("knowledge_base.md").read_text(encoding="utf-8")
completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": knowledge},
        {"role": "user", "content": "What is the rated payload of the Atlas robot?"},
    ],
    max_completion_tokens=600,
)

La primera vez que envié ese prefijo, nada estaba en caché y la petición costó unos 9,9 céntimos por aproximadamente 33.000 tokens de entrada. Tras verse el prefijo, la misma petición acertó la caché en los 32.512 tokens del prefijo y costó alrededor de 1,1 céntimos, cerca de una bajada por nueve. La razón es la diferencia de precio: la entrada cacheada cuesta $0,30 por millón de tokens frente a $3,00 sin caché. Un detalle: las escrituras en caché son asíncronas, así que el acierto no aparece en una llamada inmediata consecutiva. Llega en una petición posterior, así que ejecutar el script dos veces con un minuto de diferencia muestra primero el fallo y luego el acierto.

Coste de fallo de caché frente a acierto. Imagen del autor.

Ejemplo 5: detección de fallos de layout en una captura

La visión es nativa en K3, y la API es una forma limpia de usarla, aunque no acepta una URL pública de imagen. Envías la imagen como una data URL base64 y haces que el content del mensaje sea un array de objetos, una parte para la imagen y otra para el texto. Rendericé un pequeño panel con unos cuantos fallos de layout a propósito, guardé una captura y le pregunté a K3 qué fallaba.

El panel con fallos de layout deliberados. Imagen del autor.

import base64
from pathlib import Path

image_data = base64.b64encode(Path("broken_dashboard.png").read_bytes()).decode()
completion = client.chat.completions.create(
    model="kimi-k3",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_data}"}},
            {"type": "text", "text": "List the layout and alignment problems you can see, and give a short CSS fix for each."},
        ],
    }],
    max_completion_tokens=3500,
)
print(completion.choices[0].message.content)

K3 interpretó bien la imagen. Detectó la tarjeta que queda más baja que la fila y se superpone a su vecina, la insignia encima de un número (incluso leyó mal el 3.910 tapado como 5.910, lo que confirma el fallo), el hueco desigual antes de la última tarjeta, la barra que sangra hacia la tarjeta superior y el tooltip sobre las barras, y dio una corrección CSS breve para cada caso, como mover las tarjetas a una única grid. Sin embargo, pasó por alto el subtítulo de bajo contraste casi invisible, así que la visión capta lo que salta a la vista más que los detalles sutiles. La llamada costó unos dos céntimos.

Limitaciones de Kimi K3

Los ejemplos con la API fueron bien, pero conviene mencionar algunos bordes ásperos para que no te sorprendan. Me crucé con la mayoría de ellos.

• Por ahora solo está disponible reasoning_effort="max", así que todavía no puedes bajar el nivel de razonamiento para ahorrar.

• Los parámetros de muestreo están fijos. Valores como temperature, top_p y las penalizaciones están bloqueados, así que omítelos en las peticiones en lugar de afinarlos.

• La salida puede alargarse y encarecerse. Limita max_completion_tokens, como en los ejemplos, y valida cualquier bucle de agente.

• La API no admite URLs públicas de imagen, así que para visión tendrás que usar base64 o archivos subidos.

Ninguna de estas pegas es decisiva, pero sí condicionan cómo usas el modelo. El coste de salida es el que más vigilaría.

Conclusión

En mis pruebas, destacaron dos cosas. Las llamadas a herramientas y la salida estructurada no necesitaron reintentos, y la caché importó más de lo esperado, ya que reutilizar el mismo prefijo largo hizo barata la repetición de peticiones grandes. Así que, para análisis a escala de repositorio, llamadas repetidas con contexto largo o ingeniería multimodal, K3 es una elección razonable; para chat rápido y barato o control fino del muestreo, un modelo más pequeño es una apuesta más sencilla. Los detalles sobre pesos abiertos y licencia, que mencioné antes, deberían aclararse tras el lanzamiento del 27 de julio.

Para profundizar en los patrones que usan estos ejemplos, nuestro curso Developing AI Systems with the OpenAI API cubre function calling y cómo conectar modelos con herramientas externas en Python.