Kimi K3: Features, Benchmarks, API und 5 praxisnahe Beispiele

Das Rennen um offene Modelle nahm am 16. Juli 2026 neue Fahrt auf, als Moonshot AI Kimi K3 vorstellte: ein Modell mit 2,8 Billionen Parametern, einem Kontextfenster von 1 Million Token und nativer Bildverarbeitung. Es ist das größte offene Modell, das Moonshot bisher ausgeliefert hat – weit größer als Kimi K2 – und das erste, das sie der 3-Billionen-Parameter-Klasse zuordnen.

Wenn du die Launch-Story, den Architektur-Deep-Dive, Benchmarks, Vergleiche mit Claude, GPT und anderen chinesischen Labs sowie Moonshots eigene Liste mit Einschränkungen möchtest, deckt unser Kimi K3 Blogpost all das ab. Dieses Tutorial ist die praxisnahe Ergänzung: wie du Zugriff bekommst und wie es sich im Einsatz verhält. Ich gehe fünf kleine Beispiele durch – vier über die API, bei denen ich reale Token-Nutzung und Kosten zeige, und zwei in der kimi.com Web-App. Zusammen decken sie ab, wie K3 mit Folgendem umgeht:

• Tools aufrufen und striktes JSON zurückgeben
• Eine Tooldefinition im laufenden Dialog laden
• Kosten bei langem Kontext durch automatisches Caching senken
• Einen Screenshot lesen und das Layout korrigieren
• Ein interaktives Dashboard aus einem Prompt bauen

Die vier API-Beispiele liefen am 17. Juli 2026 gegen das kimi-k3 Modell und kosteten im Kaltstart rund 11 Cent – oder ein paar Cent, sobald das Caching griff.

How to Access Kimi K3

Am schnellsten testest du das Modell auf kimi.com. Die Web-App und die mobilen Apps nutzen Kimi K3 direkt für allgemeine Agent-Aufgaben – ganz ohne Setup.

Für schwerere Jobs wie Berichte und Dashboards gibt es Kimi Work, eine Desktop-App.

Wenn du im Terminal lebst, ist Kimi Code ein Coding-Agent, den du über npm als @moonshot-ai/kimi-code installierst; das Modell wählst du dort mit dem /model Befehl. Für K3 in Kimi Code brauchst du eine kostenpflichtige Mitgliedschaft, und für das volle 1‑Million‑Token‑Fenster eine höhere Stufe.

Dieses Tutorial konzentriert sich auf die rohe API und die Web-App, aber falls du magst, steht dir der Terminal-Agent zur Verfügung.

K3 ersetzt seine Geschwister jedoch nicht. Die Tabelle unten zeigt, wie sich die aktuelle Aufstellung aufteilt.

Kurz gesagt: K3 ist das richtige Startmodell, wenn ein Job Code, Tools, Dokumente und Bilder mischt – oder wenn du wirklich das 1‑Million‑Token‑Fenster brauchst. Für reine Codegenerierung, bei der Geschwindigkeit wichtiger ist als Kontext, bleibt kimi-k2.7-code die vernünftigere Wahl. Verlass dich also nicht darauf, dass das neueste Modell immer das beste ist.

Setting Up the Kimi K3 API

Die API ist kompatibel mit dem OpenAI SDK. Wenn du das schon genutzt hast, ist hier fast alles vertraut. Du brauchst Python 3.9 oder neuer und einen API-Schlüssel.

Step 1: Generating an API key

Melde dich zunächst auf der Kimi-Plattform an und öffne die API Keys Seite in der Konsole. Erstelle einen Schlüssel, kopiere ihn einmalig und bewahre ihn sicher auf, denn du siehst ihn nicht erneut. Für Aufrufe brauchst du außerdem ein kleines Guthaben; für dieses gesamte Tutorial reichen ein paar Dollar locker.

Einen Kimi K3 API-Schlüssel erstellen. Bild: Autor.

Step 2: Installing the SDK

Installiere als Nächstes das OpenAI SDK in deiner Umgebung. Ein einzelner Befehl genügt.

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

Damit holst du die Clientbibliothek, die der Rest der Beispiele nutzt. Es gibt nichts Kimi-Spezifisches zu installieren.

Step 3: Storing the key and initializing the client

Es ist besser, den Schlüssel aus einer Umgebungsvariablen zu lesen, statt ihn in den Code zu kleben. Setze MOONSHOT_API_KEY in deiner Shell oder in einer .env Datei und zeige den Client dann auf Moonshots Base-URL.

import os
from openai import OpenAI

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

Die einzigen zwei Unterschiede zu einem Standard-OpenAI-Setup sind die base_url und der Modellname kimi-k3. Damit bist du bereit für den ersten Aufruf.

Step 4: Making your first call

Jetzt zur ersten Anfrage. Ich bat das Modell, sich in einem Satz vorzustellen – und bekam eine ehrliche kleine Szene.

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)

Die Antwort war eine höfliche Weigerung zu raten: Das Modell erklärte, es habe keine verlässlichen Informationen über Kimi K3, da es vor seiner eigenen Veröffentlichung trainiert wurde, und verwies stattdessen auf Moonshots Ankündigungen. Eine nützliche Erinnerung daran, dass ein Modell nichts über sich selbst weiß. Der API-Call kostete rund sieben Zehntel Cent. Beachte das Limit max_completion_tokens, das ich in allen Beispielen setze, damit ausführliche Ausgaben die Rechnung nicht hochtreiben.

Erste API-Antwort von Kimi K3. Bild: Autor.

Example 1: Streaming Reasoning and the Final Answer

K3 begründet stets und die API liefert diese Begründung auf einem separaten Kanal neben der Antwort. Beim Streaming kann jeder Chunk reasoning_content, finale content oder beides tragen – so kannst du Denken und Antwort getrennt platzieren.

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)

Das Modell streamte zuerst seine Herleitung: Es erkannte die Schläger-und-Ball-Frage als Klassiker des Cognitive Reflection Test, markierte die intuitive, falsche Antwort von $0,10, rechnete dann die Algebra zur Lösung $0,05 für den Ball und prüfte, dass $1,05 plus $0,05 $1,10 ergibt. Der Split ist der praktische Teil: In einer echten App zeigst du Nutzerinnen und Nutzern content und behältst reasoning_content für Logs, denn rohes Denken in der Oberfläche ist selten sinnvoll. Dieser Aufruf nutzte 488 Output-Tokens und lag unter einem Cent.

Erst die Begründung, dann die finale Antwort. Bild: Autor.

Example 2: Tool Calling With Structured Output

Kimi K3 ist das Modell in der Reihe, das tool_choice="required" unterstützt – damit erzwingst du auf einem Turn mindestens einen Toolaufruf. Das ist hilfreich, wenn das Modell vor der Antwort Daten holen soll statt zu raten. Hier habe ich zwei Mock-Tools gegeben, eine Preisauskunft und eine Bestandsprüfung, den Toolaufruf erzwungen, die Tools lokal ausgeführt und dann das Ergebnis als striktes JSON via response_format angefordert.

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

Das Modell rief beide Tools mit dem korrekten Produktcode auf und lieferte anschließend eine saubere Bestellübersicht als JSON: fünf mechanische Keyboards zu je $89, Gesamtsumme $445, und ein Stock-Flag auf true. Zwei Details sind in der Praxis entscheidend. Du musst die vollständige Assistant-Nachricht wieder in die Konversation einfügen, bevor du Tool-Ergebnisse hinzufügst, und du solltest nur content für das JSON parsen – niemals das Reasoning-Feld. Das Call-Paar kostete zusammen unter einem Cent.

Toolaufrufe und strukturiertes JSON-Output. Bild: Autor.

Example 3: Loading Tools Dynamically

Wenn du Dutzende Tools hast, verschwenden deren Definitionen in jeder Anfrage Tokens und überladen den Prompt. Kimi K3 erlaubt es, eine Tooldefinition mitten im Gespräch per system-Nachricht mit einem tools Feld und ohne content zu injizieren. Das Tool steht ab diesem Punkt zur Verfügung – so bleibt ein großer Toolkatalog aus deinem gecachten Präfix draußen, bis ein Tool tatsächlich gebraucht wird.

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 erkannte das frisch geladene Tool und rief convert_currency mit amount 100 und rate 0,92 auf – genau wie beabsichtigt. Denk daran, dass der Server die Definition nicht für dich behält: Du sendest die Systemnachricht in späteren Requests erneut, wenn das Tool verfügbar bleiben soll. Das war der günstigste Call der Reihe mit rund zwei Zehntel Cent.

Aufruf eines dynamisch geladenen Währungstools. Bild: Autor.

Example 4: Cutting Long-Context Cost With Caching

Hier wird das 1‑Million‑Token‑Fenster praktisch. Context Caching ist automatisch – ohne Cache-ID und ohne Time-to-Live. Du sendest ein großes Präfix, lässt es bei späteren Requests bytegenau identisch und der wiederholte Teil wird zum Cache-Hit-Tarif statt zum Cache-Miss-Tarif abgerechnet. Um den Unterschied sichtbar zu machen, nutzte ich eine Wissensbasis mit ca. 33.000 Tokens und stellte dazu eine Frage.

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

Beim ersten Senden des Präfixes war nichts gecacht und die Anfrage kostete rund 9,9 Cent für grob 33.000 Input-Tokens. Nachdem das Präfix gesehen wurde, traf dieselbe Anfrage den Cache auf allen 32.512 Präfix-Tokens und kostete rund 1,1 Cent – fast ein Neuntel. Grund ist die Preisspanne: gecachter Input kostet $0,30 pro Million Tokens, ungecachter $3,00. Eine Besonderheit: Cache-Schreibvorgänge sind asynchron, daher taucht der Hit nicht bei einem sofortigen zweiten Aufruf auf. Er greift bei einer späteren Anfrage – zwei Läufe mit einer Minute Abstand zeigen erst den Miss, dann den Hit.

Cache-Miss vs. Cache-Hit-Kosten. Bild: Autor.

Example 5: Spotting Layout Bugs in a Screenshot

Vision ist in K3 nativ vorhanden, und die API ist ein sauberer Weg, das zu nutzen – allerdings akzeptiert sie keine öffentlichen Bild-URLs. Du sendest das Bild als Base64-Data-URL und machst den Nachrichten-content zu einem Array von Objekten: ein Teil für das Bild, einer für den Text. Ich habe ein kleines Dashboard mit ein paar absichtlichen Layout-Bugs gerendert, einen Screenshot gespeichert und K3 gefragt, was nicht stimmt.

Das Dashboard mit absichtlichen Layout-Bugs. Bild: 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 hat das Bild gut gelesen. Es erkannte die Karte, die tiefer als die Zeile sitzt und ihren Nachbarn überlappt, das Badge oben auf einer Zahl (es las die verdeckten 3.910 sogar als 5.910 – der Bug beweist sich selbst), den ungleichmäßigen Abstand vor der letzten Karte, den Balken, der in die Karte darüber hineinläuft, sowie das Tooltip über den Balken. Für jeden Punkt gab es einen kurzen CSS-Fix, etwa die Karten in ein gemeinsames Grid zu legen. Den nahezu unsichtbaren, kontrastarmen Untertitel ließ es jedoch aus – Vision greift eher das, was ins Auge sticht, als feine Details. Der Call kostete etwa zwei Cent.

Kimi K3 Limitations

Die API-Beispiele liefen gut, aber ein paar Ecken solltest du kennen, damit du nicht überrascht wirst. Die meisten davon sind mir direkt begegnet.

• Nur reasoning_effort="max" ist derzeit verfügbar – du kannst das Denken noch nicht herunterdrehen, um Kosten zu sparen.

• Die Sampling-Parameter sind fix. Werte wie temperature, top_p und die Penalties sind gesperrt – lass sie weg statt sie zu tunen.

• Outputs können lang und teuer werden. Setze ein Limit bei max_completion_tokens wie in den Beispielen und validiere jede Agent-Schleife.

• Öffentliche Bild-URLs werden in der API nicht unterstützt. Plane für Vision dort mit Base64 oder hochgeladenen Dateien.

Nichts davon ist ein Showstopper, aber es prägt den Einsatz des Modells. Die Output-Kosten würde ich am stärksten im Blick behalten.

Conclusion

In meinen Läufen fielen zwei Dinge auf: Toolaufrufe und strukturiertes Output klappten ohne Retries, und Caching war wichtiger als erwartet – das Wiederverwenden desselben langen Präfixes machte eine große Anfrage günstig erneut sendbar. Für Repository-Analysen, wiederholte Long-Context-Calls oder multimodales Engineering ist K3 daher eine solide Standardwahl; für schnelles, kostengünstiges Chatten oder präzise Sampling-Kontrolle ist ein kleineres Modell oft die leichtere Entscheidung. Details zu Open-Weights und Lizenz, die ich zuvor markiert habe, sollen nach dem Release am 27. Juli klarer sein.

Mehr Hintergrund zu den hier genutzten Mustern findest du in unserem Kurs Developing AI Systems with the OpenAI API – dort geht es um Function Calling und das Anbinden von Modellen an externe Tools in Python.