Kimi K3: Functies, benchmarks, API en 5 hands-on voorbeelden

De open model-race verschoof opnieuw op 16 juli 2026, toen Moonshot AI Kimi K3 uitbracht, een model met 2,8 biljoen parameters, een contextvenster van 1 miljoen tokens en native vision. Het is het grootste open model dat Moonshot heeft verscheept, ver voorbij Kimi K2 qua omvang, en het eerste dat ze beschrijven als behorend tot de klasse van 3 biljoen parameters.

Wil je het lanceringsverhaal, de architectuur-deep-dive, de benchmarkgrafieken, de vergelijkingen met Claude, GPT en andere Chinese labs, en Moonshots eigen lijst met beperkingen, dan behandelt onze Kimi K3-blogpost dat allemaal. Deze tutorial is het praktische deel: hoe je er toegang toe krijgt en hoe het zich gedraagt zodra je het gebruikt. Ik loop vijf kleine voorbeelden door, vier via de API, waarin ik het daadwerkelijke tokenverbruik en de kosten laat zien, en twee in de kimi.com-webapp. Samen laten ze zien hoe K3 omgaat met:

• Tools aanroepen en strikt JSON retourneren
• On-the-fly een tooldefinitie laden
• Kosten voor long context verlagen met automatische caching
• Een screenshot lezen en de layout repareren
• Een interactief dashboard bouwen met één prompt

De vier API-voorbeelden draaiden op 17 juli 2026 tegen het kimi-k3-model en kostten ongeveer 11 cent bij een cold run, of een paar cent zodra caching inschakelde.

Hoe krijg je toegang tot Kimi K3

De snelste manier om het model te proberen is kimi.com, waar de webapp en mobiele apps Kimi K3 draaien voor algemene agenttaken zonder setup.

Voor zwaarder werk zoals rapporten en dashboards is er Kimi Work, een desktop-app.

Als je in de terminal leeft, is Kimi Code een codeeragent die je via npm installeert als @moonshot-ai/kimi-code, en je kiest daar het model met het /model-commando. K3 gebruiken in Kimi Code vereist een betaald lidmaatschap, en voor het volledige contextvenster van 1 miljoen tokens is een hogere tier nodig.

Deze tutorial richt zich op de ruwe API en de webapp, maar de terminalagent is er als je die wilt.

K3 vervangt zijn broers en zussen niet, trouwens. De onderstaande tabel laat zien hoe de huidige line-up is opgedeeld.

De korte samenvatting is dat K3 het model is om mee te beginnen wanneer een klus code, tools, documenten en afbeeldingen mixt, of wanneer je het contextvenster van 1 miljoen tokens echt nodig hebt. Voor pure codegeneratie waar snelheid belangrijker is dan context, is kimi-k2.7-code nog steeds de verstandigere keuze, dus ga er niet vanuit dat het nieuwste model altijd de juiste is.

De Kimi K3 API instellen

De API is compatibel met de OpenAI SDK, dus als je die eerder hebt gebruikt, is hier vrijwel niets nieuw. Je hebt Python 3.9 of later en een API-sleutel nodig.

Stap 1: Een API-sleutel genereren

Log eerst in op het Kimi-platform en open de API Keys-pagina in de console. Maak een sleutel, kopieer hem één keer en bewaar hem veilig, want je ziet hem niet meer terug. Je hebt ook een klein tegoed op het account nodig om calls te kunnen doen, en voor deze hele tutorial is een paar dollar ruim voldoende.

Een Kimi K3 API-sleutel aanmaken. Afbeelding door auteur.

Stap 2: De SDK installeren

Installeer vervolgens de OpenAI SDK in je omgeving. Eén commando is genoeg.

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

Dat haalt de clientbibliotheek binnen die de rest van de voorbeelden gebruikt, en er is niets Kimi-specifieks om te installeren.

Stap 3: De sleutel opslaan en de client initialiseren

Het is beter om de sleutel te lezen uit een omgevingsvariabele dan hem in je code te plakken. Stel MOONSHOT_API_KEY in je shell of een .env -bestand in, en wijs de client vervolgens naar Moonshots basis-URL.

import os
from openai import OpenAI

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

De enige twee dingen die verschillen van een standaard OpenAI-setup zijn de base_url en de modelnaam, die kimi-k3 is. Met dat op zijn plek ben je klaar om een call te doen.

Stap 4: Je eerste call doen

Nu een eerste verzoek. Ik vroeg het model om zichzelf in één zin voor te stellen, wat een eerlijk klein momentje opleverde.

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)

Het antwoord was een beleefde weigering om te gokken: het model zei geen betrouwbare informatie over Kimi K3 te hebben, omdat het vóór zijn eigen release was getraind, en wees me in plaats daarvan op Moonshots aankondigingen. Dat is een nuttige herinnering dat een model niet over zichzelf weet. De API-call die ik net deed, kostte ongeveer zeven tiende cent. Let op de max_completion_tokens limiet, die ik in elke call in deze tutorial instel om te voorkomen dat breedsprakige output de rekening opjaagt.

Kimi K3 eerste API-call output. Afbeelding door auteur.

Voorbeeld 1: Streaming van redenering en het definitieve antwoord

K3 redeneert altijd, en de API levert die redenering op een apart kanaal dan het antwoord. Bij streamen kan elk chunk reasoning_content, de uiteindelijke content, of beide bevatten, zodat je het denken en het antwoord apart kunt plaatsen.

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)

Het model streamde eerst zijn werkwijze: het herkende de bat-and-ball-vraag als de klassieke Cognitive Reflection Test, markeerde het intuïtieve foute antwoord van $0,10, werkte daarna de algebra uit naar $0,05 voor de bal en controleerde dat $1,05 plus $0,05 $1,10 maakt. De splitsing is het nuttige deel: in een echte app toon je content aan gebruikers en bewaar je reasoning_content voor logs, want ruwe redenering tonen in productie is zelden wat je wilt. Deze call gebruikte 488 outputtokens en kostte minder dan een cent.

Eerst de redenering streamen, daarna het definitieve antwoord. Afbeelding door auteur.

Voorbeeld 2: Tools aanroepen met gestructureerde output

Kimi K3 is het model in de line-up dat tool_choice="required" ondersteunt, wat minstens één tool call afdwingt in een beurt. Dat is handig wanneer je wilt dat het model eerst data ophaalt voordat het antwoordt, in plaats van te gokken. Hier gaf ik het twee mocktools, een prijsopvraag en een voorraadcheck, dwong een tool call af, draaide de tools lokaal en vroeg daarna om het resultaat als strikt JSON met 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)})

Het model riep beide tools aan met de juiste productcode en retourneerde vervolgens een nette besteloverzicht als JSON: vijf mechanische toetsenborden à $89, een totaal van $445, en een voorraadvlag op true. Twee details laten dit in de praktijk werken. Je moet het complete assistant-bericht terug in het gesprek plaatsen voordat je toolresultaten toevoegt, en je zou alleen content moeten parsen voor de JSON, nooit het reasoning-veld. Het paar calls kostte samen minder dan een cent.

Tool calls en gestructureerde JSON-output. Afbeelding door auteur.

Voorbeeld 3: Tools dynamisch laden

Als je tientallen tools hebt, is het zonde van tokens en vervuilt het de prompt om al hun definities bij elk verzoek mee te sturen. Kimi K3 laat je een tooldefinitie halverwege het gesprek injecteren met een system-bericht dat een tools-veld draagt en geen content. De tool is vanaf dat moment beschikbaar, wat grote toolcatalogi uit je gecachte prefix houdt totdat een tool daadwerkelijk nodig is.

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 pikte de zojuist geladen tool op en riep convert_currency aan met een amount van 100 en een rate van 0,92, precies zoals bedoeld. Eén ding om te onthouden is dat de server deze definitie niet voor je vasthoudt, dus je stuurt het system-bericht in latere verzoeken opnieuw mee als je de tool beschikbaar wilt houden. Dit was de goedkoopste call in de set met ongeveer twee tiende cent.

Een dynamisch geladen valutatool aanroepen. Afbeelding door auteur.

Voorbeeld 4: Kosten voor long context verlagen met caching

Dit voorbeeld is waar het contextvenster van 1 miljoen tokens praktisch wordt. Contextcaching is automatisch, zonder cache-ID en zonder time-to-live om te beheren. Je stuurt een grote prefix, houdt die byte-voor-byte identiek bij latere verzoeken, en het herhaalde deel wordt afgerekend tegen het cache-hit-tarief in plaats van het cache-miss-tarief. Om het verschil zichtbaar te maken gebruikte ik een kennisbank van ongeveer 33.000 tokens en stelde daar een vraag over.

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,
)

De eerste keer dat ik die prefix stuurde, was er niets gecachet en kostte het verzoek ongeveer 9,9 cent voor grofweg 33.000 inputtokens. Nadat de prefix was gezien, raakte hetzelfde verzoek de cache op alle 32.512 prefix-tokens en kostte het ongeveer 1,1 cent, bijna een factor negen lager. De reden is het prijsverschil: gecachete input kost $0,30 per miljoen tokens versus $3,00 voor niet-gecachete. Een eigenaardigheid die ik tegenkwam is dat cache-schrijfs asynchroon zijn, dus de hit verschijnt niet bij een onmiddellijke back-to-back call. Hij landt bij een later verzoek, dus het script twee keer draaien met een minuut ertussen laat eerst de miss en daarna de hit zien.

Cache miss versus cache hit-kosten. Afbeelding door auteur.

Voorbeeld 5: Layoutbugs spotten in een screenshot

Vision is native in K3, en de API is een nette manier om het te gebruiken, al accepteert die geen publieke afbeeldings-URL. Je stuurt de afbeelding als een base64 data-URL en maakt de bericht-content een array van objecten, één deel voor de afbeelding en één voor de tekst. Ik renderde een klein dashboard met een paar opzettelijke layoutbugs, sloeg een screenshot op en vroeg K3 wat er mis was.

Het dashboard met opzettelijke layoutbugs. Afbeelding door auteur.

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 las de afbeelding goed. Het ving de kaart die lager in de rij zit en overlapt met zijn buur, de badge die bovenop een getal staat (het las de bedekte 3.910 zelfs als 5.910, wat de bug zelf bewijst), de ongelijke ruimte voor de laatste kaart, de balk die omhoog bloedt in de kaart erboven, en de tooltip die over de balken ligt, en gaf voor elk een korte CSS-fix, zoals de kaarten in één grid zetten. Het sloeg echter de bijna onzichtbare laag-contrast subtitel over, dus vision pikt vooral op wat in het oog springt en minder subtiel detail. De call kostte ongeveer twee cent.

Beperkingen van Kimi K3

De API-voorbeelden verliepen goed, maar een paar ruwe randjes zijn het benoemen waard zodat je niet verrast wordt. Ik liep tegen de meeste hiervan direct aan.

• Alleen reasoning_effort="max" is nu beschikbaar, dus je kunt het denken nog niet lager zetten om geld te besparen.

• De sampling-instellingen zijn vast. Waarden zoals temperature, top_p en de straffen zijn vergrendeld, dus laat ze weg uit verzoeken in plaats van ze te tunen.

• Output kan lang en duur worden. Beperk max_completion_tokens, zoals in de voorbeelden, en valideer elke agentlus.

• Publieke afbeeldings-URL's worden niet ondersteund via de API, dus reken daar op base64 of geüploade bestanden voor vision.

Geen van deze zijn showstoppers, maar ze bepalen wel hoe je het model gebruikt. De outputkosten zijn degene die ik het meest in de gaten zou houden.

Conclusie

In mijn runs sprongen twee dingen eruit. Het aanroepen van tools en de gestructureerde output hadden geen retries nodig, en caching bleek belangrijker dan ik verwachtte, omdat hergebruik van dezelfde lange prefix een grote aanvraag goedkoop opnieuw te versturen maakte. Dus voor analyse op repository-schaal, herhaalde long-context calls of multimodale engineering is K3 een redelijk default; voor snelle, goedkope chat of precieze samplingcontrole is een kleiner model de makkelijkere keuze. De details over open-weights en licentie, die ik eerder aanstipte, zouden duidelijker moeten zijn na de release van 27 juli.

Voor meer achtergrond over de patronen die deze voorbeelden gebruiken, behandelt onze Developing AI Systems with the OpenAI API-cursus function calling en het koppelen van modellen aan externe tools in Python.