Gemini 3.8 Flash API-tutorial: thinking levels, PDF-extractie en function calling in Python

Wat is Gemini 3.8 Flash?

Gemini 3.8 Flash is Google’s werkpaardmodel, algemeen beschikbaar sinds 2 september 2026, onder het model-ID gemini-3.8-flash. Het verscheen 3 weken na 3.7 Flash en Google positioneert het voor long-horizon coding, agentic workflows en meerstapsredeneren in gespecialiseerde domeinen zoals finance en juridisch werk.

De specificaties die tellen voor API-calls zijn ongewijzigd ten opzichte van 3.7: 

• een contextvenster van 1M tokens
• 64k max outputtokens
• multimodale input (tekst, afbeeldingen, video, audio, pdf’s) met tekstoutput
• Dezelfde introductieprijs van $0,75 per 1M inputtokens en $3,75 per 1M outputtokens t/m 31 december 2026 (stijgend naar $1,50 en $7,50 vanaf 1 januari 2027)

Wat veranderde is gedrag, niet de surface: Google zegt dat 3.8 harder werkt aan complexe taken, extra denkstappen zet en iteratief tools aanroept, wat het tokenverbruik kan verhogen bij hogere inspanningsniveaus. 3.7 Flash blijft volledig ondersteund voor workloads waar efficiency belangrijker is dan diepgang.

Voor benchmarks en gedetailleerde prijzen, bekijk onze Gemini 3.8 Flash-gids, of lees de Wat is Google Gemini?-gids voor een overzicht van het platform.

Gemini 3.8 Flash vs. 3.8 Flash Cyber

De lancering omvat 2 varianten, en slechts 1 daarvan heeft een model-ID dat je kunt intypen. 

• Gemini 3.8 Flash is het algemene model, vandaag beschikbaar in Google AI Studio en de Gemini API. 
• Gemini 3.8 Flash Cyber is een cybersecurity-variant, getuned voor het vinden van kwetsbaarheden en geautomatiseerd patchen.

De Cyber-variant is niet beschikbaar op de publieke API: toegang loopt via Google’s Fairwind Program, dat is beperkt tot goedgekeurde overheidsinstanties, operators van kritieke infrastructuur en softwaremaintainers.

Als je deze tutorial volgt, is jouw model-ID gemini-3.8-flash. Niets hieronder heeft of gebruikt de Cyber-variant.

Interactions API vs. generateContent

Om Gemini 3.8 Flash aan te roepen, gebruik je client.interactions.create() in de google-genai SDK. Google maakte de Interactions API GA in juni 2026 en raadt deze aan voor al het nieuwe werk. Hoewel generateContent nog werkt, is het nu legacy. Nieuwe features zoals server-side geschiedenis, background execution en observeerbare execution steps landen eerst op Interactions.

De grootste verandering in de praktijk is state management. Multi-turn-calls gebruiken nu een server-side previous_interaction_id: je geeft de laatste interaction ID door, en de server handelt het herstel van de status af. Je hoeft niet langer handmatig de volledige chathistorie vanuit je client toe te voegen of opnieuw te versturen. Vermijd ook het vooraf invullen van modelbeurten; dat is een legacy-generateContent-patroon en zal breken op Gemini 3.x.

Eén ding pakt bijna iedereen, en komt terug in het PDF-gedeelte: previous_interaction_id herstelt de gespreksgeschiedenis en niets anders. tools, system_instruction, generation_config en response_format zijn interactie-gebonden, dus elke beurt die ze nodig heeft, moet ze opnieuw doorgeven.

thinking_level vervangt sampling-knoppen

Op oudere Gemini-modellen gebruikten developers temperature, top_p en top_k om de willekeurigheid van output te sturen. Gemini 3.x schrapt deze sampling-knoppen en vervangt ze door thinking_level, dat nu de enige draaiknop is.

Het accepteert 3 waarden:

• low: de minste reasoningtokens, snelst en goedkoopst. Past bij extractie, classificatie en alles wat je zelf controleert.

• medium: de standaard, en Google’s aanbeveling voor code en agent-werk.

• high: het grootste reasoningbudget, voor lastige meerstapslogica en tool-zware taken.

Stuur geen minimal. Dit is ongeldig sinds Gemini Flash 3.7 en geeft een 400-validatiefout. 

Nog een regel die is overgenomen uit 3.7: frequency_penalty, presence_penalty en candidate_count geven nu een actieve API-fout, dus verwijder ze ook uit legacy-configs.

Hoe stel je de Gemini 3.8 Flash API in?

Je omgeving opzetten kost zo’n 2 minuten. Je hebt een API-sleutel van Google AI Studio en de bijgewerkte google-genai Python-bibliotheek nodig.

Haal een API-sleutel op bij Google AI Studio

Bezoek Google AI Studio in je browser en log in met je Google-account. Klik op Create API Key, kies of maak een Google Cloud-project en kopieer je geheime sleutelstring. 

Open je terminal en sla de sleutel op als omgevingsvariabele met export GEMINI_API_KEY=<your-key>.

Geef de sleutel nooit door als ?key= queryparameter in een URL; querystrings belanden in serverlogs, browsergeschiedenis en proxycaches. Wil je het model eerst verkennen in een playground voordat je code schrijft, dan behandelt de Google AI Studio Tutorial Chat-, Build- en Stream-modi; dit artikel blijft bij de API.

Voor productieomgevingen verandert het auth-verhaal: Vertex AI (nu onderdeel van het Gemini Enterprise Agent Platform) geeft je OAuth, IAM-rollen en regionale endpoints in plaats van een ruwe API-sleutel. Alles in deze tutorial gebruikt AI Studio-sleutels omdat dat het snelste is om te leren, maar plan de Vertex-migratie voordat iets echte gebruikersdata raakt.

Installeer google-genai en maak een client

Veel tutorials zeggen nog steeds dat je google-generativeai moet installeren. Dat is de oude SDK, en die heeft geen Interactions API. Installeer google-genai (versie 2.3.0 of later):

pip install -U google-genai

Zodra geïnstalleerd, controleer je dat Python de bibliotheek laadt en je client zonder fouten initialiseert:

from google import genai # reads GEMINI_API_KEY from the environment
client = genai.Client() 
print("Client initialized successfully.")

Doe je eerste Interactions API-call

Elke aanvraag aan de Interactions API maakt een Interaction resource aan, die de volledige beurt registreert: jouw input, de gedachten van het model, eventuele toolcalls en de uiteindelijke output. De SDK stelt de uiteindelijke tekst bloot via de output_text-gemaksproperty, dus je hoeft zelden handmatig de stappen te doorlopen.

from google import genai
client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=(
        "Write a pandas one-liner that adds a 7-day rolling average "
        "revenue column per store_id to a DataFrame with columns "
        "date, store_id, revenue. Reply with only the code, no explanation."
    ),
    generation_config={"thinking_level": "medium"},
)
print(interaction.output_text)
usage = interaction.usage
print(
    f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
    f"thinking={usage.total_thought_tokens} | total={usage.total_tokens}"
)

Op mijn machine antwoordde het model met een gekoppelde pandas one-liner, en deze usage-regel:

Die getallen verbergen het eerste echte verschil met 3.7. Ik draaide dezelfde taak nog eens met een langere prompt en zonder outputbeperking, en 3.8 besteedde 1.436 thinkingtokens tegen 870 outputtokens. Met de beperking besteedde het 1.515 tegen 42. Het reasoningbudget bewoog nauwelijks, wat het tegenovergestelde is van 3.7, waar dezelfde 2 prompts thinking lieten schommelen van 838 naar 1.530.

Met andere woorden, 3.8 beslist hoe hard het nadenkt op basis van de taak, niet op basis van hoe je de taak formuleert, wat past bij Google’s claim dat het model doelbewuster redeneert en verifieert. Thinking wordt gefactureerd tegen het outputtarief, dus bij de begrensde call waren ongeveer 97% van de gefactureerde tokens reasoning die ik nooit zag. Daarom bestaat de volgende sectie. 

Stream de respons

Voor chatinterfaces of alles wat iemand live bekijkt, voelt enkele seconden wachten op de volledige respons traag. Geef stream=True door aan client.interactions.create() en print chunks zodra ze binnenkomen:

	from google import genai

	client = genai.Client()

	stream = client.interactions.create(
	   model="gemini-3.8-flash",
	   input="Explain the difference between a JOIN and a correlated subquery in SQL.",
	   generation_config={"thinking_level": "low"},
	   stream=True,
	)

	for event in stream:
	   if event.event_type == "step.delta" and event.delta.type == "text":
	       print(event.delta.text, end="", flush=True)
	print() 

Toen ik dit draaide, gaf het model een lang, goed geordend antwoord op thinking_level: "low": een conceptuele vergelijking, een samenvattingstabel en 2 SQL-voorbeelden om de meest recente bestelling per klant te vinden, 1 met een derived-table join en 1 met een correlated subquery in de SELECT-lijst. De eerste woorden verschenen vrijwel meteen, precies de bedoeling.

Die laatste print() staat er niet voor niets. Zonder dat eindigt de laatste chunk halverwege de regel, en zsh toont een verdwaalde % voor je prompt, omdat de stream precies stopt waar de modeltekst stopt. Ook: deltas dragen alleen tekst; als je token-tellingen per request logt, lees ze dan uit het laatste completion-event in plaats van chunks op te tellen.

Hoe verandert thinking_level kosten en kwaliteit?

thinking_level bepaalt hoeveel redenering Gemini 3.8 Flash doet voordat het het antwoord schrijft. Reasoningtokens worden gefactureerd tegen het outputtarief van $3,75 per 1M, dus het niveau dat je kiest stuurt kosten en latency direct, en Google zegt dat 3.8 hier bewust op leunt: het zet extra denkstappen bij complexe taken en kan meer tokens besteden op hogere inspanningsniveaus dan 3.7 deed.

Draai één prompt op low, medium en high

De test is een race condition in een payment-retry-functie die met dezelfde prompt op alle 3 niveaus wordt verzonden. Concurrency-bugs straffen skim-lezen af, dus als de niveaus verschillen, is dit waar het zichtbaar moet worden. Als je maar 1 codeblok uit dit artikel draait, laat het dan dit zijn, want de cijfers overtuigen beter dan welke tekst ook.

import time

from google import genai

client = genai.Client()

BUGGY_CODE = '''
import threading

payment_attempts = {}

def retry_payment(order_id, charge_fn, max_retries=3):
    """Retry a failed payment up to max_retries times."""
    if order_id not in payment_attempts:
        payment_attempts[order_id] = 0

    while payment_attempts[order_id] < max_retries:
        success = charge_fn(order_id)
        if success:
            del payment_attempts[order_id]
            return True
        payment_attempts[order_id] += 1
    return False
'''

PROMPT = (
    "Two worker threads can call retry_payment() with the same order_id "
    "at the same time. Identify the concurrency bug that can double-charge "
    "a customer, and rewrite the function to fix it.\n\n" + BUGGY_CODE
)

for level in ["low", "medium", "high"]:
    start = time.perf_counter()
    interaction = client.interactions.create(
        model="gemini-3.8-flash",
        input=PROMPT,
        generation_config={"thinking_level": level},
    )
    elapsed = time.perf_counter() - start
    usage = interaction.usage
    print(f"\n=== thinking_level: {level} | {elapsed:.1f}s ===")
    print(interaction.output_text)
    print(
        f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
        f"thinking={usage.total_thought_tokens}"
    )

Ter context: de kwetsbaarheid is een niet-atomische check-then-act op payment_attempts[order_id]. Onder concurrency kunnen 2 threads allebei de while-voorwaarde passeren en allebei charge_fn() aanroepen voordat een van beiden de teller verhoogt. Oplossen betekent de read-check-charge-increment-flow in een lock per order wikkelen, of een idempotency key bij de gateway gebruiken.

De resultaten vergelijken

Resultaten van mijn runs:

Alle 3 niveaus vonden de dubbele afschrijving, en alle 3 leverden locks per order, zodat niet-gerelateerde orders parallel lopen. Dat 2e deel is de kop als je dit vergelijkt op 3.7: daar wikkelde low alles in 1 globale lock die tijdens de netwerkcall werd vastgehouden, en locks per order verschenen pas op medium. Op 3.8 schrijft low dat betere ontwerp bij 0 thinkingtokens, in 7,8 seconden, voor minder dan een derde cent.

Wat leveren de niveaus nu op? Auditdiepte. Deze code heeft 4 verschillende faalmodi (de dubbele afschrijving, een KeyError bij gelijktijdig verwijderen, een her-afschrijving nadat het succespad de status verwijdert, en niet-atomische tellerverhogingen), en high was het enige niveau dat alle 4 noemde; low miste het her-afschrijvingsgeval, en medium miste de teller. 

high was ook de enige die de failurepad-semantiek van zijn fix uitschreef: zodra retries op zijn, krijgen latere aanroepers False terug in plaats van opnieuw te belasten.

De thinking-kolom is Google’s „3.8 werkt harder”-claim die in een terminal zichtbaar wordt. Tegen dezelfde prompt op 3.7 ging medium van 2.343 thinkingtokens naar 3.158, en high van 2.217 naar 4.512, ruwweg het dubbele, en de extra tokens kochten een vollediger analyse in plaats van een andere uitkomst. Latentie klom mee in deze run (7,8 s, 16,6 s, 25,5 s), maar single-run timings op deze modellen schommelen, dus vergelijk tokentellingen in plaats van seconden.

Kies een default en wanneer op te schalen

Dit is mijn vuistregel voor reasoningniveaus:

• Op 3.8 verdiende low een grotere rol dan Google’s medium-standaard suggereert: het produceerde een correcte, goed ontworpen fix bij 0 thinkingtokens, dus begin daarmee voor alles wat een mens leest voordat het ertoe doet (triage, concepten, samenvattingen, code die je reviewt). 

• Houd medium waar de output ongelezen doorstroomt, omdat het extra nadenken een vollediger analyse van faalmodi opleverde, en een ongelezen pijplijn is precies waar de faalmodus die je niet noemde, degene is die afgaat.

• Reserveer high voor outputs waar het failurepad zelf het product is, zoals betalingsstromen, migraties of alles wat een reviewer regel voor regel zou auditen. In mijn run was het het enige niveau dat alle 4 bugs ving en documenteerde wat er gebeurt nadat retries zijn uitgeput.

Bij 6.6x de kosten van low voor high, leest die tradeoff heel anders bij $3,75 per 1M outputtokens nu versus $7,50 na 31 december 2026, dus schaal per request op in plaats van globaal.

Een handige uitweg om te kennen is dat Google aangeeft dat 3.7 Flash volledig ondersteund blijft voor efficiency-first workloads. Als 3.8’s extra zorgvuldigheid meer kost dan je taak nodig heeft, is op gemini-3.7-flash blijven voor die workload een ondersteunde keuze, geen hack.

Hoe extraheer je gestructureerde data uit een PDF?

Gemini 3.8 Flash leest PDF’s direct als input, dus je kunt een factuur of rapport sturen en er vragen over stellen. Ik gebruikte een 1-pagina leveranciersfactuur met het factuurnummer, datums, 4 regelniveau-items en een totaal.

Voeg een PDF toe aan de prompt

Laten we een lokale factuur-PDF uploaden met de Files API. De Files API verzorgt filestorage en caching op Google’s infrastructuur:

	from google import genai
	client = genai.Client()
	print("Uploading invoice...")
	doc = client.files.upload(file="invoice_aug_2026.pdf")
	print(f"File uploaded: {doc.uri}\n")

	interaction = client.interactions.create(
	   model="gemini-3.8-flash",
	   input=[
	       {
	           "type": "text",
	           "text": "Extract the invoice number, total amount due, and due date.",
	       },
	       {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
	   ],
	)
	print(interaction.output_text)

De output van mijn factuur:

Alle 3 waarden kloppen. De upload gebeurt één keer, en het bestand blijft beschikbaar voor latere requests, wat belangrijk is zodra je meer dan 1 vraag over hetzelfde document stelt. Het antwoord komt terug als markdown-bullets, wat prima is om te lezen en minder geschikt om een pijplijn in te sturen.

Forceer JSON met een responseschema

Om JSON in plaats van proza te krijgen, geef je een schema door in response_format. Op de Interactions API is dit een top-level-parameter; de instelling responseMimeType binnen generationConfig die je in oudere tutorials ziet, hoort bij de legacy-generateContent-endpoint.

import json

from google import genai
from pydantic import BaseModel

client = genai.Client()


class Invoice(BaseModel):
    invoice_number: str
    total_due_usd: float
    due_date: str  # ISO 8601


doc = client.files.upload(file="invoice_aug_2026.pdf")

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {
            "type": "text",
            "text": "Extract the invoice number, total amount due in USD, and due date.",
        },
        {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
    ],
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": Invoice.model_json_schema(),
    },
)

invoice = json.loads(interaction.output_text)
print(invoice)

Dit is de output die ik ontving: 

Je Pydantic-klasse definieert de vereiste velden en datatypes, terwijl model_json_schema() het JSON-schema genereert dat de Gemini API vereist. Eenmaal verwerkt zet json.loads() de output van het model om in een standaard Python-dictionary. Vanaf hier is de gestructureerde data klaar om te worden omgezet in een DataFrame-rij, weggeschreven in een database, of toegevoegd aan een Google Sheet.

Stel een vervolgvraag met previous_interaction_id

Voor een 2e vraag over hetzelfde document geef je de id van de 1e interactie door als previous_interaction_id. De server heeft de PDF en de 1e uitwisseling al, dus je stuurt geen van beide opnieuw:

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input="List each line item on the invoice with its amount.",
)

print(follow_up.output_text)

Het gaf alle 4 items in volgorde terug, inclusief de herhaalde compute-regel, zonder opmerking over de herhaling. Dat is het juiste gedrag voor de gestelde vraag; als je wilt dat het anomalieën markeert, vraag daar dan expliciet om. 

Voor wat het waard is, 3.7 gedroeg zich hier identiek, dus 3.8’s extra zorgvuldigheid geldt voor zijn eigen redenering, niet voor ongevraagd auditen dat je niet vroeg.

2 dingen om te weten over deze call: 

• response_format is niet meegekomen, omdat het interactie-gebonden is, dus deze beurt gaf proza terug. 

• En interacties worden standaard opgeslagen (store=True) voor 55 dagen op de betaalde tier en 1 dag op de gratis tier; store=False maakt een call stateless, maar je kunt er dan geen previous_interaction_id op ketenen.

Hoe voeg je Function Calling toe aan Gemini 3.8 Flash?

Function calling op Gemini 3.8 Flash is één loop, waarbij het model om een tool vraagt, jouw code die draait, jij het resultaat terugstuurt en het model het definitieve antwoord schrijft. In deze sectie bouwen we die loop met de hand.

Wil je dat Google de loop voor je draait met gehoste multi-tool agents, lees dan daarna onze tutorial over  "Managed Agents" in de Gemini API. En als agents je langetermijndoel zijn, bouwt de cursus Building AI Agents with Google ADK een volledige klantenservice-assistent op dezelfde basisprimitieven.

Definieer een tool en voer de interactieloop uit

De tool is lookup_exchange_rate(currency, date), ondersteund door een kleine in-memory dict, zodat het voorbeeld zonder externe API draait. De declaratie is een JSON-schema. Het model draait de functie nooit zelf; het retourneert een function_call-stap waarin jouw code wordt gevraagd om:

import json

from google import genai

client = genai.Client()

# Local "data source" standing in for a real FX API
RATES = {
    ("USD", "2026-08-03"): 87.42,
    ("USD", "2026-08-10"): 87.15,
    ("EUR", "2026-08-03"): 95.08,
}


def lookup_exchange_rate(currency: str, date: str) -> dict:
    rate = RATES.get((currency.upper(), date))
    if rate is None:
        return {"error": f"No rate for {currency} on {date}"}
    return {"currency": currency.upper(), "date": date, "inr_rate": rate}


rate_tool = {
    "type": "function",
    "name": "lookup_exchange_rate",
    "description": "Look up the INR exchange rate for a currency on a date (YYYY-MM-DD).",
    "parameters": {
        "type": "object",
        "properties": {
            "currency": {"type": "string", "description": "ISO code, e.g. USD"},
            "date": {"type": "string", "description": "YYYY-MM-DD"},
        },
        "required": ["currency", "date"],
    },
}

# Turn 1: the model decides to call the tool
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="What was the USD to INR exchange rate on 2026-08-03?",
    tools=[rate_tool],
)

fc_step = next(s for s in interaction.steps if s.type == "function_call")
print(f"Model requested: {fc_step.name}({fc_step.arguments})")

# Your code executes the function locally
result = lookup_exchange_rate(**fc_step.arguments)

# Turn 2: send the result back; tools must be re-specified (interaction-scoped)
final = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input=[
        {
            "type": "function_result",
            "name": fc_step.name,
            "call_id": fc_step.id,
            "result": [{"type": "text", "text": json.dumps(result)}],
        }
    ],
    tools=[rate_tool],
)

print(final.output_text)

De output: 

Er gebeurden 3 dingen:  

1. Beurt 1 gaf een function_call-stap terug met een naam, gestructureerde argumenten en een id.

2. Je Python voerde de lookup uit.

3. Beurt 2 stuurde een function_result-blok terug dat naar die call verwijst. 

De parameter tools wordt in beurt 2 opnieuw meegegeven om dezelfde reden dat response_format opnieuw moest worden meegegeven in het PDF-gedeelte: previous_interaction_id draagt geschiedenis, geen config.

Function-calling fouten op Gemini 3.x

Als een toollaag breekt, is het bijna altijd 1 van 2 dingen. 

Ten eerste moet elk resultaat terug te voeren zijn op zijn call. Op de Interactions API zijn dat call_id en name op het function_result-blok; op de legacy-generateContent API moeten de FunctionResponse en de id en name van de voorafgaande FunctionCall overeenkomen. Geen van beide is optioneel op Gemini 3.x.

Ten tweede ontstaat een Malformed_Function_Call-fout meestal wanneer het model commentaar uitstuurt vóór de toolcall. Google’s 3.8 developer guide zegt: ruim leidende pre-tooltekst op, formatteer inline-instructies met \n\n, en wikkel werknotities in een dedicated function call in plaats van ruwe tekst. Verstrak de system instruction; niet blind herproberen.

Wat breekt er als je overschakelt naar Gemini 3.8 Flash?

Dat hangt af van waar je begint. 

• Van Gemini 3.7 Flash: niets. Verander de modelstring naar gemini-3.8-flash, en elke snippet in dit artikel draait ongewijzigd, omdat het API-oppervlak identiek is. 

• Van Gemini 3.6 Flash of eerder vereist de modelconfiguratie dezelfde audit van 15 minuten als voorheen.

Migratie-checklist (vanaf 3.6 Flash of eerder)

Werk deze in volgorde af. Items 1 t/m 3 veroorzaken directe 400’s; items 4 en 5 veroorzaken stille kwaliteitsproblemen.

1. Wijzig het model-ID naar gemini-3.8-flash.

2. Verwijder dode sampling-parameters: temperature, top_p en top_k worden genegeerd of afgewezen op Gemini 3.x, en frequency_penalty, presence_penalty en candidate_count geven een actieve API-fout. Strip alle 6 uit legacy-configs.

3. Vervang thinking_budget door thinking_level: gebruik alleen low, medium of high. De oude waarde minimal geeft een validatiefout. Het sturen van zowel thinking_budget als thinking_level in één request geeft een 400.

4. Verwijder vooraf ingevulde modelbeurten: strip deze uit elke conversatie die je construeert en zorg dat de laatste user-beurt niet-lege tekst heeft. History-payloads mogen niet eindigen met een modelbeurt.

5. Standaardiseer multi-turn-flows: vertrouw op previous_interaction_id in plaats van client-side historiekherhaling. Je moet je tools, system_instruction en generation_config in elke beurt waar ze ertoe doen opnieuw specificeren.

Google publiceert de gezaghebbende versie in de Gemini API-modeldocs, inclusief een geautomatiseerd pad als je codingagent skills ondersteunt. Lees het zelf één keer, toch; een geautomatiseerde migratie vertelt je niet waarom je temperature=0.2 er in de eerste plaats stond.

Fouten die je in productie tegenkomt

Dit zijn de 4 statuscodes waar je handlers voor wilt bedraden, en wat elk op deze API daadwerkelijk betekent:

Nog 2 belangrijke punten:

• Zet expliciete client-timeouts wanneer je thinking_level: "high" combineert met lange toollussen, want een vastgelopen request is erger dan een mislukte, en 3.8’s extra zorgvuldigheid maakt lange reasoningruns waarschijnlijker, niet minder. 

• En log interaction.id bij elk request; dat is je handvat om opgeslagen interacties later op te halen, te debuggen of te verwijderen.

Tot slot

Alles in dit artikel komt neer op 3 verschuivingen. De Interactions API veranderde de aanroepconventie, thinking_level verving elke sampling-knop die je eerder gebruikte, en server-side state via previous_interaction_id maakte zowel de PDF-vervolgbeurt als de toollaag tot éénregelige beurten in plaats van history-replay-oefeningen. Gemini 3.8 Flash veranderde niets aan dat oppervlak; wat het veranderde is hoe hard het model daarbinnen werkt, en daarom zijn de metingen in dit artikel vers op 3.8 genomen in plaats van overgezet uit 3.7.

Voordat je mijn niveau-aanbevelingen op gezag overneemt, richt het vergelijkingsscript op een taak uit je eigen backlog; het niveau dat wint op een payment-retry-race kan verliezen op jouw SQL-generatieworkload. 

Wanneer losse API-calls niet meer genoeg zijn en je productie-AI-systemen wilt, behandelt ons Associate AI Engineer for Developers-traject het volledige pad, en het Associate AI Engineer for Data Scientists-traject doet hetzelfde vanaf de datakant.