DeepSeek V4 Pro (0813): Thinking Passback & 3-API-matrix

Dit artikel behandelt de gebruiksaanwijzingen en valkuilen voor deepseek-v4-pro-0813. Op AIHubMix is het model beschikbaar via de Chat Completions-, Responses- en Claude-compatibele Messages-API's. Zie ook: officiële API-documentatie van DeepSeek.

De conclusies met het label "Verified" en de voorbeeldresponses in elke sectie komen van daadwerkelijke aanroepen op 2026-08-13 via de AIHubMix-API's (Chat Completions / Responses / Messages). Specificatie-items die niet als "Verified" zijn gemarkeerd, komen uit de officiële documentatie van DeepSeek.

1. Positionering van het model en specificaties in één oogopslag

V4 Pro is de high-end variant van de V4-generatie van DeepSeek (het lichtgewicht deepseek-v4-flash is de broer ervan). De releaselijn gaat terug tot DeepSeek-V4 Preview op 2026-04-24, en 0813 is het MODELVERSIE-label dat DeepSeek aan de huidige build heeft toegekend. Naast de ruwe specificaties onderscheidt het model zich op vier punten:

• Een sparse frontier-model: 1,6T totale parameters / 49B geactiveerd (een MoE, of mixture-of-experts, architectuur: bij elke inferentiestap worden slechts een deel van de expertnetwerken geactiveerd. Het totale aantal parameters bepaalt de kenniscapaciteit, het aantal geactiveerde parameters bepaalt de rekenkosten per aanroep). De model card vermeldt de hybride CSA+HCA-aandacht, mHC en de Muon-optimizer.
• Open weights onder MIT: deepseek-ai/DeepSeek-V4-Pro is gepubliceerd op HuggingFace onder de MIT-licentie (een van de meest permissieve open-sourcelicenties: commercieel gebruik en closed-source herdistributie zijn beide toegestaan) en kan zelf worden gehost. MIT is ongebruikelijk voor een model van deze omvang. De hostingnotities op de model card adviseren ook een contextvenster van ≥384K tokens bij gebruik in Think Max (het hoogste denkniveau). Dat is deploymentadvies voor zelfhosting en geen specificatie van de gehoste API.
• Ondersteuning voor meerdere protocollen is first-party, geen vertaling door derden: DeepSeek biedt zelf een OpenAI Chat API, een Anthropic-compatibel eindpunt (/anthropic, dat claude-opus* op dit model afbeeldt) en de Responses API (DeepSeek beschrijft native ondersteuning voor het formaat, met aanpassingen voor Codex). Daarnaast biedt het FIM-completion (fill-in-the-middle) als bètafunctie op een apart eindpunt, dat geen deel uitmaakt van de drie AIHubMix-API's.
• Een prijsverschil van ~120× tussen cache-hit en cache-miss: de gepubliceerde prijsmechanismen van DeepSeek zijn cache-hit $0,003625/M versus cache-miss $0,435/M (output $0,87/M), en caching verloopt automatisch zonder parameter die je moet instellen. Bij workloads die lange prefixen hergebruiken (systeemprompts, lange documenten) bepaalt dat verschil grotendeels de kosten. De werkelijke retailprijs is wat de modelpagina toont.

Verified: een max_tokens die de limiet overschrijdt, wordt door de validatie afgewezen in plaats van stilzwijgend afgekapt. Een verzoek met max_tokens=9999999 geeft HTTP 400, en de foutbody noemt het veld en geeft het maximum 393216 aan.

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

❗ Afbeeldingen geven geen foutmelding, maar worden weggelaten: de officiële formulering voor de Responses API luidt "Image and file inputs are not supported (input_image parts do not cause an error, but are replaced with a placeholder text)". Een input_image-onderdeel laat het verzoek dus niet mislukken, maar wordt vervangen door tijdelijke tekst. Bij Chat Completions accepteert de content van een gebruikersbericht alleen een string, en bij Messages zijn type="image"-blokken gemarkeerd als Not Supported. Gebruik bij het opzetten van multimodale routering nooit "geen foutmelding" als bewijs dat het model de afbeelding daadwerkelijk heeft gezien.

2. Hoe schakel je denken uit? Drie API's, drie veldvormen

V4 Pro denkt standaard: stuur geen enkele parameter mee en de response bevat denkinhoud. Om het uit te schakelen gebruik je op elk van de drie API's een andere veldvorm.

Chat Completions

Gebruik het bovenliggende thinking-object.

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

Verified: met thinking.type="disabled" verdwijnen message.reasoning_content en usage.completion_tokens_details.reasoning_tokens tegelijk, wat bevestigt dat de schakelaar werkt.

Responses

Er is op Responses geen aparte schakelaar; denken uitzetten betekent het niveau op none zetten.

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

Verified: reasoning.effort="none" is waarneembaar anders dan het standaardniveau (denktokens vallen naar nul, het reasoning-outputitem verdwijnt), wat bevestigt dat het werkt.

Messages

Dezelfde naam en dezelfde vorm als bij Chat Completions: het bovenliggende thinking-object.

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]

Verified: eenmaal uitgeschakeld verdwijnt het thinking-blok volledig en blijft alleen het text-blok over.

Over denkniveaus: low en max gaven in tests beide 200 op Chat Completions (high is de standaard en geldt wanneer het veld ontbreekt), maar het aantal denktokens verschilt niet monotoon tussen de niveaus voor dezelfde vraag (eenvoudige vraag: low=43 / max=27; moeilijke vraag: low=114 / max=92). Bovendien wordt niets teruggestuurd in de response. de niveaus worden geaccepteerd, maar er is in de response geen onderscheidend signaal waar te nemen. Op Responses kan alleen het none-niveau (denken uit) aan de responskant worden bevestigd.

3. Waarom geeft een meerdaags gesprek ineens 400? De denkgeschiedenis moet woordelijk worden teruggestuurd

Dit is de meest voorkomende valkuil bij dit model: in denkmodus moet een meerdaags gesprek de denkinhoud van de vorige beurt woordelijk meesturen, anders wordt het verzoek afgewezen. Het wordt niet slechter of van mindere kwaliteit, maar krijgt een harde HTTP 400.

De drie API's dragen dezelfde denkinhoud onder verschillende veldnamen:

Verified (triggervoorwaarden): deze validatie treedt consistent op bij meerdaagse verzoeken die tools bevatten (het model doet een tool-aanroep, waarna het toolresultaat wordt teruggestuurd). Bij gewone meerdaagse verzoeken zonder tools, waarbij het model direct antwoordt, trad de validatie in deze testronde niet op en gaf het verzoek 200. Met andere woorden: toolorkestratie (agent- of function-calling-workloads) is waar je het het vaakst tegenkomt, dus behandel denkinhoud als onderdeel van de gespreksstatus die je opslaat en opnieuw afspeelt.

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

Verified: een historisch assistant-bericht zonder reasoning_content geeft 400; als je het toevoegt, geeft exact hetzelfde verzoek 200 en gaat het correct verder.

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

Verified: het is voldoende response.output ongewijzigd terug in de geschiedenis te plaatsen. Als je bij het opbouwen van de geschiedenis outputitems filtert op type == "message", valt het reasoning-item weg en krijg je de 400. Dit is de meest voorkomende manier om hierin te trappen.

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

Verified: het thinking-blok uit de contentarray verwijderen geeft 400 (met error.type gelijk aan invalid_request_error).

4. Tool-aanroepen

Elke API declareert tools in zijn eigen protocolvorm; de vormen zijn niet onderling uitwisselbaar.

Chat Completions

Geneste vorm (een function-object dat name / parameters omhult). Een tool_choice met een benoemde functie dwingt de aanroep af.

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

❗ Verified: tool_choice: "required" kan niet worden gebruikt terwijl denken aan staat. Het geeft 400 Thinking mode does not support this tool_choice; denken uitschakelen (thinking.type="disabled") maakt exact hetzelfde verzoek 200. Als je de semantiek "er moet een tool worden aangeroepen" nodig hebt, gebruik dan een benoemde functie als tool_choice (zoals hierboven, die werkt met denken aan), of zet eerst denken uit en gebruik daarna required.

Responses

Platte vorm (type / name / parameters op hetzelfde niveau).

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

Verified: de geneste vorm van Chat Completions (function: {...}) overnemen in Responses geeft 400. Gebruik de platte vorm. tool_choice: "required" valt onder dezelfde beperking in denkmodus als op Chat.

Messages

Anthropic-native vorm (input_schema), met tool_choice: {"type": "any"} om een aanroep af te dwingen.

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

❗ Parallelle tool-aanroepen kunnen niet worden uitgeschakeld, door het eigen ontwerp van DeepSeek. De officiële Anthropic-compatibiliteitspagina vermeldt in de rij tool_choice dat disable_parallel_tool_use is ignored, en de Responses-pagina vermeldt eveneens parallel_tool_calls | Ignored (parallel tool calling is always enabled). De tests bevestigen dit: een vraag over twee steden tegelijk met disable_parallel_tool_use: true geeft nog steeds twee tool_use-blokken. Als je seriële uitvoering nodig hebt, neem dan alleen de eerste aanroep of zet ze zelf in de wachtrij aan de clientzijde.

Aantal tools en contextkosten: het sturen van 200 functiedefinities in één verzoek gaf nog steeds 200 met een normaal antwoord en leidde niet tot een telvalidatiefout (geobserveerd op dit pad; hogere aantallen zijn niet getest). Maar prompt_tokens voor dat verzoek kwam uit op 6.105 — tooldefinities worden volledig in de context opgenomen en worden gefactureerd. Als je veel tools hebt, beperk de toolset dan per scenario in plaats van alles onvoorwaardelijk op te geven.

5. Gestructureerde output

Chat Completions

response_format ondersteunt 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}

Geverifieerd: de output is geldige JSON.

Responses

Declareer een JSON Schema via text.format, waarbij de strict-modus wordt ondersteund.

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}

Geverifieerd: de output voldoet strikt aan het opgegeven schema.

Messages

Het Messages-protocol (Anthropic) heeft geen equivalent van response_format / text.format. De gebruikelijke workaround is het schema in een tool te plaatsen: declareer een tool waarvan de input_schema je doelschema is, stel tool_choice: {"type": "any"} in en lees het gestructureerde resultaat uit de input van het tool_use-blok. In deze testronde is dat patroon niet specifiek geverifieerd; als je harde schemagaranties nodig hebt, kies dan bij voorkeur Chat Completions of Responses.

6. Hoe schakel je context-caching in? Dat doe je niet, het is automatisch

Context-caching (identieke voorvoegsels worden hergebruikt en het gecachte deel wordt tegen een lager tarief gefactureerd) staat standaard aan en heeft geen parameters nodig. Een tweede verzoek met hetzelfde lange voorvoegsel meldt de treffer in usage, onder een veldnaam die per API verschilt. Voor details over caching en de actuele prijzen, zie de modelpagina; voor cachingstrategie over modellen heen en technieken om de trefferkans te verhogen, zie best practices voor prompt-caching.

Chat Completions

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

Geverifieerd: twee opeenvolgende aanroepen met hetzelfde lange voorvoegsel op hetzelfde kanaal verhoogden cached_tokens van 0 naar 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

Geverifieerd: het voorvoegsel hierboven werd opgewarmd door een Responses-verzoek met identieke inhoud, en de eerste Messages-aanroep leverde meteen 896 treffers op, wat past bij caching op basis van het inhoudelijke voorvoegsel dat over protocoloppervlakken heen wordt gedeeld.

7. logprobs: Chat geeft twee kanalen terug

logprobs (logwaarschijnlijkheden — de betrouwbaarheidsdetails per kandidaat-token van het model) komen op de twee API's in verschillende vormen terug, en parseercode moet ze apart afhandelen.

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

❗ Geverifieerd: Chat geeft logwaarschijnlijkheden voor zowel content als reasoning_content. Code die alleen logprobs.content leest, zoals de standaard OpenAI-responsevorm voorschrijft, geeft geen fout maar mist stilzwijgend het denkkanaal; als je code aanneemt dat er één array onder logprobs staat, voeg dan eerst een controle op de vorm toe.

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

Geverifieerd: Responses voegt logprobs alleen toe aan het laatste tekstitem — er is geen dubbelkanaalsvorm zoals bij Chat.

Messages

Het Messages-protocol (Anthropic) heeft geen equivalent veld. Gebruik voor gedetailleerde kansinformatie per token Chat Completions of Responses.

8. Welke API's kunnen het web doorzoeken?

Webzoeken is hier een server-side tool (het ophalen gebeurt op de server; de client stuurt het verzoek zelf nooit), en het wordt in tests daadwerkelijk uitgevoerd op zowel de Responses- als de Messages-API.

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"]

Geverifieerd: een web_search_call-item verschijnt in de outputvolgorde, wat betekent dat de server daadwerkelijk een ophaalactie heeft uitgevoerd.

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

Geverifieerd: usage.server_tool_use.web_search_requests telt 1 — het ophaalverzoek heeft echt plaatsgevonden en is gemeten.

Chat Completions

Webzoeken kan niet worden geactiveerd op Chat. De officiële Chat API-referentie van DeepSeek bevat nergens een zoektool-veld in het verzoekschema (dit is een afwezigheid die is vastgesteld door de veldlijst één voor één na te lopen; DeepSeek heeft niet expliciet ontkend dat er ondersteuning is). De API met een expliciete officiële ondersteuningsverklaring voor server-side zoeken is Responses (web_search), en de officiële compatibiliteitspagina voor Messages vermeldt eveneens de zoekgerelateerde contentblokken.

# 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

Geverifieerd: het meesturen van web_search_options of enable_search geeft geen fout, maar er wordt ook niets opgehaald — de response bevat geen annotations (de lijst met bronvermeldingen die bij een response hoort wanneer webzoeken draait), en het gebruik komt veld voor veld overeen met de controlegroep. Voor webtoegang gebruik je de Responses- of Messages-API.

9. Gebruiksnotities: DeepSeek's ontwerp versus afwijkingen op ons pad

Alles hieronder geeft HTTP 200 terug terwijl het zich contra-intuïtief gedraagt. De oorzaken verschillen, en dus ook wat je eraan kunt doen, daarom staan ze apart vermeld: de eerste groep is hoe DeepSeek het model heeft ontworpen, en van die groep verandert het wisselen van provider niets; de tweede groep is het huidige gedrag op het AIHubMix-pad, waaraan we werken.

9.1 Volgens het ontwerp van DeepSeek

9.2 Huidig gedrag op het AIHubMix-pad

9.3 Niet gedefinieerd door DeepSeek, dus geen oordeel in beide richtingen

Een waarde buiten de enum voor reasoning_effort (bijv. bogus_xyz) geeft 200 terug met een normaal antwoord, geen fout en geen waarneembaar effect. Het feit is duidelijk genoeg — dit pad valideert de enum van reasoning_effort momenteel niet. Onduidelijk is of het dat wel zou moeten: DeepSeek publiceert de geldige enum, maar vermeldt nooit of een ongeldig niveau moet worden afgewezen, dus er is geen referentie om tegen te toetsen. Daarom telt dit noch als officieel gedrag, noch als defect op ons pad. De veilige aanpak aan de clientzijde: valideer het niveau zelf en reken er niet op dat de API het opvangt.

10. Matrix van mogelijkheden × API-ondersteuning

De cellen hieronder geven de parameter- of veldschrijfwijze per API. Behalve waar het als expliciete formulering van DeepSeek is aangegeven, komt elke conclusie uit daadwerkelijke aanroepen op 2026-08-13 tegen de AIHubMix-productie-API's.

Legenda: ✅ geverifieerd werkend · 🟡 geaccepteerd maar effect kan niet worden bevestigd · ❗ vereist aandacht (zie de notities hierboven) · ➖ dit concept bestaat niet bij deze API

Veelgestelde vragen

Welke API's ondersteunt deepseek-v4-pro-0813 op AIHubMix?
Chat Completions (/v1/chat/completions), Responses (/v1/responses) en de Claude-compatibele Messages API (/v1/messages).

Waarom geeft een gesprek met meerdere beurten ineens 400 terug?
De meest voorkomende oorzaak is een denkgeschiedenis die niet is teruggestuurd. In de denkmodus moet de denkinhoud van de vorige beurt woordelijk opnieuw worden meegestuurd: reasoning_content op het assistentbericht voor Chat, het type="reasoning"-outputitem voor Responses en het thinking-contentblok voor Messages. Meerdere beurten met tools is waar dit het meest problemen geeft, omdat veel frameworks outputitems filteren op type == "message" bij het opbouwen van de geschiedenis, waardoor het redeneeritem wegvalt.

Kan het denken worden uitgeschakeld?
Ja. Stuur thinking: {"type": "disabled"} bij Chat of Messages, en reasoning: {"effort": "none"} bij Responses. Eenmaal uitgeschakeld verdwijnen zowel de denkinhoud als de denktokens.

Verschillen de drie reasoning_effort-niveaus?
low / high / max worden allemaal geaccepteerd (standaard high; medium en xhigh worden om compatibiliteitsredenen toegewezen aan high). In tests vertonen de aantallen denktokens voor dezelfde vraag geen monotoon verschil tussen de niveaus en wordt er niets teruggestuurd, dus het verschil kan aan de kant van de aanroeper niet worden bevestigd. Alleen het niveau none bij Responses (denken uit) levert een duidelijk waarneembaar verschil op.

Waarom geeft tool_choice: "required" 400 terug?
Die waarde wordt niet geaccepteerd terwijl het denken aan staat (de foutmelding luidt Thinking mode does not support this tool_choice). Gebruik een tool_choice met een benoemde functie ({"type": "function", "function": {"name": "..."}}) om bij ingeschakeld denken een specifieke aanroep af te dwingen, of schakel het denken eerst uit en gebruik daarna required.

Hoe schakel je context caching in?
Dat hoeft niet, het is automatisch. Plaats de stabiele, onveranderde inhoud (systeemprompts, kennisfragmenten, tooldefinities) vooraan in het verzoek. Het aantal hits wordt gerapporteerd in usage: prompt_tokens_details.cached_tokens bij Chat, input_tokens_details.cached_tokens bij Responses en cache_read_input_tokens bij Messages.

Voor prijzen en actuele status, zie de modelpagina van deepseek-v4-pro-0813; voor meer modellen, bezoek de modelgalerij.

Gerelateerde praktische gidsen: praktische gids voor Kimi K3 (nieuwe parameters en een matrix met ondersteuning voor drie API's) en wijzigingen in prompt caching en facturatie van GPT-5.6.