DeepSeek V4 Pro (0813): Thinking-Passback und 3-API-Matrix

Dieser Artikel behandelt Nutzungshinweise und typische Stolpersteine für deepseek-v4-pro-0813. Auf AIHubMix ist das Modell über die Chat-Completions-, Responses- und die Claude-kompatible Messages-API verfügbar. Siehe auch: offizielle DeepSeek-API-Dokumentation.

Die Abschnitte mit dem Vermerk „Verifiziert“ sowie die Beispielantworten stammen aus tatsächlichen Aufrufen vom 13.08.2026 über die AIHubMix-APIs (Chat Completions / Responses / Messages). Spezifikationspunkte, die nicht als „Verifiziert“ gekennzeichnet sind, stammen aus der offiziellen Dokumentation von DeepSeek.

1. Einordnung des Modells und Spezifikationen im Überblick

V4 Pro ist die Spitzenklasse der V4-Generation von DeepSeek (das leichtgewichtige deepseek-v4-flash ist sein Pendant). Die Veröffentlichungslinie geht auf DeepSeek-V4 Preview vom 24.04.2026 zurück, und 0813 ist die MODELLVERSIONSBEZEICHNUNG, die DeepSeek dem aktuellen Build zugewiesen hat. Abgesehen von den reinen Spezifikationen zeichnen sich vier Punkte aus:

• Ein dünn besetztes Spitzenmodell: 1,6 Bio. Gesamtparameter / 49 Mrd. aktivierte Parameter (eine MoE-Architektur, also Mixture-of-Experts – bei jedem Inferenzdurchlauf wird nur ein Teil der Expertennetzwerke aktiviert: Die Gesamtparameter bestimmen die Wissenskapazität, die aktivierten Parameter den Rechenaufwand pro Aufruf). Die Modellkarte nennt die hybride Aufmerksamkeit CSA+HCA, mHC und den Muon-Optimierer.
• Offene Gewichte unter MIT: deepseek-ai/DeepSeek-V4-Pro wird auf HuggingFace unter der MIT-Lizenz veröffentlicht (eine der freizügigsten Open-Source-Lizenzen – kommerzielle Nutzung und die Weiterverbreitung als Closed-Source sind beide erlaubt) und kann selbst gehostet werden. MIT ist für ein Modell dieser Größe ungewöhnlich. Die Hinweise zum Selbst-Hosting in der Modellkarte empfehlen zudem ein Kontextfenster von ≥384K Token, wenn im Think-Max-Modus (der höchsten Denkstufe) gearbeitet wird. Dabei handelt es sich um Bereitstellungsempfehlungen für das Selbst-Hosting, nicht um eine Spezifikation der gehosteten API.
• Mehrprotokoll-Unterstützung ist direkt vom Anbieter, keine Drittanbieter-Übersetzung: DeepSeek selbst bietet eine OpenAI-Chat-API, einen Anthropic-kompatiblen Endpunkt (/anthropic, der claude-opus* auf dieses Modell abbildet) und die Responses-API (DeepSeek beschreibt eine native Unterstützung des Formats mit Anpassungen für Codex). Außerdem gibt es FIM-Completion (Fill-in-the-Middle) als Beta-Funktion auf einem separaten Endpunkt, der nicht zu den drei AIHubMix-APIs gehört.
• Eine Preisdifferenz von etwa 120× zwischen Cache-Treffer und Cache-Fehlschlag: Laut DeepSeeks veröffentlichtem Preismodell kostet ein Cache-Treffer 0,003625 $/M, ein Cache-Fehlschlag 0,435 $/M (Output 0,87 $/M), und das Caching läuft automatisch ohne einzustellenden Parameter. Bei Workloads, die lange Präfixe wiederverwenden (Systemprompts, lange Dokumente), bestimmt diese Differenz die Kosten maßgeblich. Der tatsächliche Endkundenpreis ist der, den die Modellseite anzeigt.

Verifiziert: Eine Überschreitung von max_tokens wird durch die Validierung abgelehnt und nicht stillschweigend gekürzt – das Senden von max_tokens=9999999 liefert HTTP 400, und der Fehlertext nennt das Feld und die Obergrenze 393216.

# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"

❗ Bilder lösen keinen Fehler aus, werden aber verworfen: Der offizielle Wortlaut für die Responses-API lautet: „Bild- und Datei-Eingaben werden nicht unterstützt (input_image-Teile verursachen keinen Fehler, werden aber durch Platzhaltertext ersetzt)“ – ein input_image-Teil bringt die Anfrage nicht zum Scheitern, sondern wird durch Platzhaltertext ersetzt. Bei Chat Completions akzeptiert der content der Benutzernachricht nur einen String, und bei Messages sind type="image"-Blöcke als nicht unterstützt markiert. Wer multimodales Routing aufbaut, sollte „kein Fehler“ niemals als Beleg dafür werten, dass das Modell das Bild tatsächlich gesehen hat.

2. Wie schaltet man Thinking aus? Drei APIs, drei Feldstrukturen

V4 Pro denkt standardmäßig mit: Sendet man gar keine Parameter, enthält die Antwort Thinking-Inhalte. Zum Ausschalten wird auf jeder der drei APIs eine andere Feldstruktur verwendet.

Chat Completions

Verwende das oberste thinking-Objekt.

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent

Verifiziert: Mit thinking.type="disabled" verschwinden message.reasoning_content und usage.completion_tokens_details.reasoning_tokens gemeinsam, was bestätigt, dass die Umschaltung gewirkt hat.

Responses

Bei Responses gibt es keinen eigenen Schalter; Thinking wird ausgeschaltet, indem die Stufe auf none gesetzt wird.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item

Verifiziert: reasoning.effort="none" unterscheidet sich im Ergebnis deutlich von der Standardstufe (Thinking-Token fallen auf null, das Ausgabeelement reasoning verschwindet), was bestätigt, dass es gewirkt hat.

Messages

Gleicher Name und gleiche Struktur wie bei Chat Completions: das oberste thinking-Objekt.

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]

Verifiziert: Nach dem Deaktivieren verschwindet der thinking-Block vollständig, und nur der text-Block bleibt übrig.

Zu den Thinking-Stufen: low und max lieferten bei Chat Completions im Test beide 200 (high ist der Standard und gilt, wenn das Feld weggelassen wird). Die Anzahl der Thinking-Token zeigt jedoch für dieselbe Frage keinen monotonen Unterschied zwischen den Stufen (einfache Frage: low=43 / max=27; schwierige Frage: low=114 / max=92), und in der Antwort wird nichts zurückgespiegelt. Die Stufen werden akzeptiert, aber die Antwort liefert kein unterscheidbares Signal. Bei Responses lässt sich von der Antwortseite her nur die Stufe none (Thinking aus) bestätigen.

3. Warum liefert eine mehrstufige Konversation plötzlich 400? Die Thinking-Historie muss unverändert zurückgegeben werden

Dies ist der mit Abstand häufigste Stolperstein bei diesem Modell: Im Thinking-Modus muss eine mehrstufige Konversation die Thinking-Inhalte des vorherigen Turns unverändert zurückgeben, sonst wird die Anfrage abgelehnt. Nicht schlechtere Qualität, sondern ein harter HTTP-400-Fehler.

Die drei APIs transportieren denselben Thinking-Inhalt unter unterschiedlichen Feldnamen:

Verifiziert (Auslösebedingungen): Diese Validierung greift zuverlässig bei mehrstufigen Anfragen mit tools (das Modell stellt einen Tool-Aufruf, danach wird das Tool-Ergebnis zurückgesendet). Bei einfachen mehrstufigen Anfragen ohne Tools, bei denen das Modell direkt antwortet, griff die Validierung in dieser Testrunde nicht, und die Anfrage lieferte 200. Anders gesagt: Die Tool-Orchestrierung (Agent- oder Function-Calling-Workloads) ist der Bereich, in dem man am ehesten darauf stößt. Daher sollte man Thinking-Inhalte als Teil des Gesprächszustands behandeln, den man speichert und erneut sendet.

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error

Verifiziert: Eine historische Assistenten-Nachricht ohne reasoning_content liefert 400; fügt man es wieder hinzu, liefert dieselbe Anfrage 200 und setzt die Konversation korrekt fort.

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400

Verifiziert: Es genügt, response.output unverändert wieder einzufügen. Filtert man beim Zusammenstellen der Historie die Ausgabeelemente nach type == "message", fällt das reasoning-Element weg und löst den 400-Fehler aus. Das ist der häufigste Weg, in diese Falle zu tappen.

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking block -> HTTP 400

Verifiziert: Das Entfernen des thinking-Blocks aus dem Inhaltsarray liefert 400 (mit error.type gleich invalid_request_error).

4. Tool-Aufrufe

Jede API deklariert Tools in ihrer eigenen Protokollstruktur; die Strukturen sind nicht austauschbar.

Chat Completions

Verschachtelte Struktur (ein function-Objekt, das name und parameters umschließt). Ein tool_choice mit benannter Funktion erzwingt den Aufruf.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}

❗ Verifiziert: tool_choice: "required" kann nicht verwendet werden, solange Thinking aktiv ist. Es liefert 400 mit Thinking mode does not support this tool_choice; deaktiviert man Thinking (thinking.type="disabled"), liefert dieselbe Anfrage 200. Wenn man die Semantik „muss ein Tool aufrufen“ braucht, verwendet man stattdessen ein tool_choice mit benannter Funktion tool_choice (wie oben, das funktioniert auch mit aktivem Thinking), oder man schaltet Thinking zuerst aus und verwendet dann required.

Responses

Flache Struktur (type, name und parameters auf derselben Ebene).

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["reasoning", "function_call"]; arguments = {"city": "Paris"}

Verifiziert: Kopiert man die verschachtelte Struktur von Chat Completions (function: {...}) in Responses, liefert das 400. Stattdessen die flache Struktur verwenden. tool_choice: "required" unterliegt bei Responses derselben Einschränkung im Thinking-Modus wie bei Chat.

Messages

Anthropic-native Struktur (input_schema), mit tool_choice: {"type": "any"}, um einen Aufruf zu erzwingen.

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}

❗ Paralleler Tool-Aufruf lässt sich nicht abschalten, so ist es von DeepSeek bewusst konzipiert: Die offizielle Seite zur Anthropic-Kompatibilität vermerkt in der Zeile zu tool_choice, dass disable_parallel_tool_use is ignored gilt, und die Responses-Seite nennt ebenso parallel_tool_calls | Ignored (parallel tool calling is always enabled). Der Test bestätigt das: Fragt man nach zwei Städten gleichzeitig und setzt disable_parallel_tool_use: true, liefert die Antwort trotzdem zwei tool_use-Blöcke. Wer eine serielle Ausführung braucht, nimmt den ersten Aufruf oder reiht die Aufrufe clientseitig selbst in eine Warteschlange ein.

Anzahl der Tools und Kontextkosten: Das Senden von 200 Funktionsdefinitionen in einer einzigen Anfrage lieferte weiterhin 200 mit einer normalen Antwort und löste keine Anzahlprüfung aus (auf diesem Pfad beobachtet; höhere Anzahlen wurden nicht getestet). Aber prompt_tokens erreichte bei dieser Anfrage 6,105 — Tool-Definitionen werden vollständig in den Kontext aufgenommen und abgerechnet. Wenn Sie viele Tools haben, schränken Sie das Tool-Set pro Szenario ein, statt alles unbedingt zu deklarieren.

5. Strukturierte Ausgabe

Chat Completions

response_format unterstützt den JSON-Modus.

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}

Verifiziert: Die Ausgabe ist gültiges JSON.

Responses

Deklarieren Sie ein JSON Schema über text.format; der strict-Modus wird unterstützt.

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"a":1}

Verifiziert: Die Ausgabe entspricht strikt dem vorgegebenen Schema.

Messages

Das Messages-Protokoll (Anthropic) hat kein Äquivalent zu response_format / text.format. Der übliche Workaround besteht darin, das Schema in einem Tool zu übergeben: Deklarieren Sie ein Tool, dessen input_schema Ihr Zielschema ist, setzen Sie tool_choice: {"type": "any"} und lesen Sie das strukturierte Ergebnis aus dem input des tool_use-Blocks. Diese Testrunde hat dieses Muster nicht gezielt verifiziert; wenn Sie harte Schema-Garantien benötigen, bevorzugen Sie Chat Completions oder Responses.

6. Wie aktivieren Sie Context Caching? Gar nicht, es ist automatisch

Context Caching (identische Präfixe werden wiederverwendet, und der gecachte Anteil wird zu einem niedrigeren Satz abgerechnet) ist standardmäßig aktiviert und benötigt keine Parameter. Eine zweite Anfrage mit demselben langen Präfix meldet den Treffer in usage, unter einem Feldnamen, der je nach API variiert. Details zum Caching und aktuelle Preise finden Sie auf der Modellseite; zur modellübergreifenden Caching-Strategie und Techniken für Trefferquoten siehe Best Practices für Prompt Caching.

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0

Verifiziert: Zwei unmittelbar aufeinanderfolgende Aufrufe mit demselben langen Präfix auf demselben Kanal erhöhten cached_tokens von 0 auf 640.

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896

Verifiziert: Das oben genannte Präfix wurde durch eine Responses-Anfrage mit identischem Inhalt vorgewärmt, und der erste Messages-Aufruf traf sofort 896 — konsistent damit, dass das Caching über den Inhaltspräfix gesteuert und über Protokoll-Oberflächen hinweg geteilt wird.

7. logprobs: Chat liefert zwei Kanäle

logprobs (Log-Wahrscheinlichkeiten – die Konfidenzdetails des Modells pro Kandidaten-Token) kommen auf den beiden APIs in unterschiedlicher Form zurück, und Parsing-Code muss sie getrennt behandeln.

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text

❗ Verifiziert: Chat liefert Log-Wahrscheinlichkeiten sowohl für content als auch für reasoning_content. Code, der nur logprobs.content gemäß der standardmäßigen OpenAI-Antwortstruktur liest, bricht nicht mit einem Fehler ab, verpasst aber stillschweigend den Denk-Kanal; wenn Ihr Code von einem einzelnen Array unter logprobs ausgeht, fügen Sie zuerst eine Strukturprüfung hinzu.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details

Verifiziert: Responses hängt logprobs nur an das letzte Textelement an – keine der dualen Kanal-Strukturen, die bei Chat zu sehen ist.

Messages

Das Messages-Protokoll (Anthropic) hat kein entsprechendes Feld. Für Wahrscheinlichkeitsdetails auf Token-Ebene verwenden Sie Chat Completions oder Responses.

8. Welche APIs können das Web durchsuchen?

Die Websuche ist hier ein serverseitiges Tool (die Abfrage läuft auf dem Server; der Client stellt die Anfrage nie selbst), und sie wird in den Tests tatsächlich sowohl über die Responses- als auch über die Messages-API ausgeführt.

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["reasoning", "web_search_call", "reasoning", "message"]

Verifiziert: Ein web_search_call-Element erscheint in der Ausgabesequenz, was bedeutet, dass der Server tatsächlich eine Abfrage ausgeführt hat.

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1

Verifiziert: usage.server_tool_use.web_search_requests zählt 1 – die Suchanfrage hat tatsächlich stattgefunden und wurde abgerechnet.

Chat Completions

Websuche kann auf Chat nicht ausgelöst werden. Die offizielle Chat-API-Referenz von DeepSeek enthält im Anfrageschema kein Such-Tool-Feld (diese Feststellung beruht darauf, die Feldliste Punkt für Punkt durchzugehen; DeepSeek hat keine explizite Aussage gemacht, die Unterstützung verneint). Die API mit einer ausdrücklichen offiziellen Unterstützungsaussage für serverseitige Suche ist Responses (web_search), und die offizielle Messages-Kompatibilitätsseite listet ebenfalls die suchbezogenen Content-Blöcke auf.

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A

Verifiziert: Das Senden von web_search_options oder enable_search löst keinen Fehler aus, ruft aber auch nichts ab – die Antwort enthält keine annotations (die Quellenliste, die einer Antwort bei ausgeführter Websuche beigefügt wird), und die Usage stimmt Feld für Feld mit der Kontrollgruppe überein. Für Webzugriff verwenden Sie stattdessen die Responses- oder Messages-API.

9. Nutzungshinweise: DeepSeeks Design vs. Abweichungen auf unserem Pfad

Alles Folgende liefert HTTP 200 zurück, verhält sich aber kontraintuitiv. Die Ursachen unterscheiden sich, ebenso wie das, was Sie dagegen tun sollten, daher werden sie getrennt aufgeführt: Die erste Gruppe beruht auf DeepSeeks Modelldesign, und ein Anbieterwechsel ändert daran nichts; die zweite Gruppe ist das aktuelle Verhalten auf dem AIHubMix-Pfad, an dem wir arbeiten.

9.1 Durch DeepSeeks Design bedingt

9.2 Aktuelles Verhalten auf dem AIHubMix-Pfad

9.3 Von DeepSeek nicht definiert, daher weder als richtig noch als falsch bewertet

Das Senden eines Werts außerhalb des Enums für reasoning_effort (z. B. bogus_xyz) liefert 200 mit einer normalen Antwort, ohne Fehler und ohne beobachtbare Wirkung. Der Sachverhalt ist klar genug – dieser Pfad validiert das Enum von reasoning_effort derzeit nicht. Unklar ist, ob er das sollte: DeepSeek veröffentlicht das zulässige Enum, legt jedoch nie fest, ob eine unzulässige Stufe abgelehnt werden müsste; es gibt also keinen Maßstab zur Beurteilung, weshalb dies weder als offizielles Verhalten noch als Mangel auf unserem Pfad zählt. Der sichere clientseitige Ansatz: Prüfen Sie die Stufe selbst und verlassen Sie sich nicht darauf, dass die API den Fehler abfängt.

10. Matrix aus Funktion × API-Unterstützung

Die folgenden Zellen geben die Parameter- bzw. Feldschreibweise für jede API an. Sofern nicht als ausdrückliche DeepSeek-Formulierung gekennzeichnet, stammt jede Schlussfolgerung aus tatsächlichen Aufrufen vom 2026-08-13 gegen die AIHubMix-Produktions-APIs.

Legende: ✅ geprüft und funktionsfähig · 🟡 akzeptiert, aber Wirksamkeit nicht bestätigbar · ❗ benötigt Aufmerksamkeit (siehe Hinweise oben) · ➖ dieses Konzept gibt es in dieser API nicht

FAQ

Welche APIs unterstützt deepseek-v4-pro-0813 auf AIHubMix?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) und die Claude-kompatible Messages API (/v1/messages).

Warum liefert eine Konversation mit mehreren Runden plötzlich 400?
Die häufigste Ursache ist ein nicht zurückgesendeter Denkverlauf. Im Denkmodus muss der Denkinhalt der vorherigen Runde wortgetreu erneut übermittelt werden: reasoning_content in der Assistant-Nachricht bei Chat, das Ausgabeelement type="reasoning" bei Responses und der Inhaltsblock thinking bei Messages. Besonders kritisch wird es bei Mehrrunden-Konversationen mit Tools – viele Frameworks filtern beim Zusammenstellen des Verlaufs Ausgabeelemente nach type == "message", wodurch das Reasoning-Element verloren geht.

Lässt sich das Denken abschalten?
Ja. Sende bei Chat oder Messages thinking: {"type": "disabled"} und bei Responses reasoning: {"effort": "none"}. Danach verschwinden sowohl der Denkinhalt als auch die Denk-Tokens.

Unterscheiden sich die drei reasoning_effort-Stufen?
low / high / max werden alle akzeptiert (Standard ist high; medium und xhigh werden zur Kompatibilität auf high abgebildet). Bei Tests zeigt die Anzahl der Denk-Tokens für dieselbe Frage zwischen den Stufen keinen monotonen Unterschied, und es wird nichts zurückgespiegelt; der Unterschied lässt sich von der Aufruferseite aus also nicht bestätigen. Nur die Stufe none bei Responses (Denken aus) erzeugt einen eindeutig erkennbaren Unterschied.

Warum liefert tool_choice: "required" den Fehler 400?
Dieser Wert wird bei aktiviertem Denken nicht akzeptiert (der Fehlertext lautet Thinking mode does not support this tool_choice). Verwende eine benannte Funktion in tool_choice ({"type": "function", "function": {"name": "..."}}), um bei aktivem Denken einen bestimmten Aufruf zu erzwingen, oder deaktiviere das Denken zuerst und verwende danach required.

Wie aktiviert man das Kontext-Caching?
Gar nicht – es ist automatisch aktiv. Platziere die stabilen, unveränderlichen Inhalte (System-Prompts, Wissensausschnitte, Tool-Definitionen) am Anfang der Anfrage. Die Anzahl der Treffer wird in der Usage ausgewiesen: prompt_tokens_details.cached_tokens bei Chat, input_tokens_details.cached_tokens bei Responses und cache_read_input_tokens bei Messages.

Preise und den aktuellen Status findest du auf der Modellseite von deepseek-v4-pro-0813; weitere Modelle findest du in der Modellgalerie.

Verwandte praktische Anleitungen: Praxisleitfaden zu Kimi K3 (neue Parameter und eine Matrix der drei unterstützten APIs) und Änderungen bei Prompt-Caching und Abrechnung für GPT-5.6.