Tutorial API Gemini 3.8 Flash: niveluri de thinking, extragere din PDF și function calling în Python

Ce este Gemini 3.8 Flash?

Gemini 3.8 Flash este modelul de lucru al Google, disponibil în general din 2 septembrie 2026, sub ID-ul gemini-3.8-flash. A sosit la 3 săptămâni după 3.7 Flash, iar Google îl poziționează pentru coding pe orizont lung, fluxuri agentice și raționament în mai mulți pași în domenii specializate precum finanțe și juridic.

Specificațiile care contează pentru apelurile API sunt neschimbate față de 3.7: 

• fereastră de context de 1M tokeni
• 64k tokeni max la output
• input multimodal (text, imagini, video, audio, PDF-uri) cu output text
• Același preț promoțional de $0,75 per 1M tokeni input și $3,75 per 1M tokeni output până pe 31 decembrie 2026 (urcând la $1,50 și $7,50 de la 1 ianuarie 2027)

Ce s-a schimbat este comportamentul, nu suprafața: Google spune că 3.8 depune mai mult efort pe sarcini complexe, luând pași suplimentari de raționament și chemând unelte iterativ, ceea ce poate crește consumul de tokeni la niveluri mai ridicate de efort. 3.7 Flash rămâne complet suportat pentru workload-uri unde eficiența contează mai mult decât profunzimea.

Pentru benchmark-uri și detalii de preț, consultă ghidul Gemini 3.8 Flash, sau citește ghidul What is Google Gemini? pentru o privire de ansamblu asupra platformei.

Gemini 3.8 Flash vs. 3.8 Flash Cyber

Lansarea include 2 variante, iar doar una are un model ID pe care îl poți introduce. 

• Gemini 3.8 Flash este modelul general, disponibil azi în Google AI Studio și Gemini API. 
• Gemini 3.8 Flash Cyber este o variantă de securitate cibernetică, ajustată pentru descoperirea vulnerabilităților și patching automat.

Varianta Cyber nu este disponibilă pe API-ul public: accesul se face prin Programul Fairwind al Google, care e limitat la autorități guvernamentale aprobate, operatori de infrastructuri critice și mentenanți de software.

Dacă urmezi acest tutorial, ID-ul tău de model este gemini-3.8-flash. Nimic de mai jos nu cere și nu folosește varianta Cyber.

Interactions API vs. generateContent

Pentru a apela Gemini 3.8 Flash, folosește client.interactions.create() în SDK-ul google-genai. Google a făcut Interactions API GA în iunie 2026 și îl recomandă pentru orice proiect nou. Deși generateContent încă funcționează, acum este legacy. Funcționalități noi precum istoric server-side, execuție în fundal și pași de execuție observabili apar întâi pe Interactions.

Cea mai mare schimbare în practică este gestionarea stării. Apelurile multi-turn folosesc acum un previous_interaction_id server-side: transmiți ID-ul ultimei interacțiuni, iar serverul se ocupă de restaurarea stării. Nu mai trebuie să atașezi sau să retrimiți manual tot istoricul conversației din client. Evită și preumplerea turnurilor modelului; acesta e un tipar legacy de la generateContent și va eșua pe Gemini 3.x.

Un detaliu îi prinde aproape pe toți, și revine în secțiunea PDF: previous_interaction_id restaurează istoricul conversației și nimic altceva. tools, system_instruction, generation_config și response_format au scop pe interacțiune, deci orice turn care are nevoie de ele trebuie să le transmită din nou.

thinking_level înlocuiește reglajele de sampling

Pe modelele Gemini mai vechi, dezvoltatorii foloseau temperature, top_p și top_k pentru a controla caracterul aleator al outputului. Gemini 3.x renunță la aceste reglaje de sampling și le înlocuiește cu thinking_level, care este acum singurul buton de control.

Acceptă 3 valori:

• low: cele mai puține tokeni de raționament, cel mai rapid și ieftin. Potrivit pentru extragere, clasificare și orice vei verifica tu însuți.

• medium: implicitul și recomandarea Google pentru cod și lucru cu agenți.

• high: cel mai mare buget de raționament, pentru logică dificilă în mai mulți pași și sarcini cu multe unelte.

Nu trimite minimal. Este invalid începând cu Gemini Flash 3.7 și întoarce o eroare de validare 400. 

O altă regulă moștenită din 3.7: frequency_penalty, presence_penalty și candidate_count aruncă acum o eroare activă a API-ului, deci elimină-le și din configurațiile legacy.

Cum configurezi API-ul Gemini 3.8 Flash?

Configurarea mediului durează cam 2 minute. Ai nevoie de o cheie API din Google AI Studio și de biblioteca Python google-genai actualizată.

Obține o cheie API din Google AI Studio

Vizitează Google AI Studio în navigator și autentifică-te cu contul tău Google. Dă click pe Create API Key, selectează sau creează un proiect Google Cloud și copiază-ți cheia secretă.

Deschide terminalul și salvează cheia ca variabilă de mediu cu export GEMINI_API_KEY=<your-key>.

Nu trece niciodată cheia ca parametru de interogare ?key= într-un URL; șirurile de interogare ajung în jurnalele serverului, istoricul browserului și cache-urile proxy. Dacă vrei să explorezi modelul într-un playground înainte să scrii cod, Tutorialul Google AI Studio acoperă modurile Chat, Build și Stream; acest articol rămâne pe API.

Pentru sisteme de producție, povestea de autentificare se schimbă: Vertex AI (acum parte din Gemini Enterprise Agent Platform) îți oferă OAuth, roluri IAM și endpoint-uri regionale în locul unei chei brute de API. Tot ce este în acest tutorial folosește chei AI Studio pentru că este cea mai rapidă cale de învățare, dar planifică migrarea la Vertex înainte ca ceva să atingă date reale ale utilizatorilor.

Instalează google-genai și creează un client

Multe tutoriale încă spun să instalezi google-generativeai. Acela este SDK-ul vechi și nu are Interactions API. Instalează google-genai (versiunea 2.3.0 sau mai nouă):

pip install -U google-genai

După instalare, verifică faptul că Python încarcă biblioteca și îți inițializează clientul fără erori:

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

Fă primul apel la Interactions API

Fiecare cerere către Interactions API creează o resursă Interaction, care înregistrează întregul turn: inputul tău, gândurile modelului, orice apeluri de unelte și outputul final. SDK-ul expune textul final prin proprietatea convenabilă output_text, astfel că rareori ai nevoie să parcurgi manual pașii.

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

Pe mașina mea, modelul a răspuns cu un one-liner pandas în lanț, iar această linie de utilizare:

Acei indicatori ascund prima diferență reală față de 3.7. Am rulat aceeași sarcină din nou cu un prompt mai lung și fără restricție la output, iar 3.8 a cheltuit 1.436 tokeni de thinking față de 870 tokeni de output. Cu restricția, a cheltuit 1.515 față de 42. Bugetul de raționament abia s-a mișcat, opusul lui 3.7, unde aceleași 2 prompturi au balansat thinking de la 838 la 1.530.

Cu alte cuvinte, 3.8 decide cât de intens gândește în funcție de sarcină, nu de cum formulezi sarcina, ceea ce se potrivește cu afirmația Google că modelul raționează și verifică mai deliberat. Thinking se taxează la tariful de output, așa că pe apelul constrâns, aproximativ 97% din tokenii facturați au fost raționament pe care nu l-am văzut. De aceea există următoarea secțiune. 

Fă streaming la răspuns

Pentru interfețe de chat sau orice urmărește un om, să aștepți câteva secunde pentru întregul răspuns se simte lent. Transmite stream=True la client.interactions.create() și afișează bucățile pe măsură ce sosesc:

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

Când am rulat asta, modelul a returnat un răspuns lung și bine organizat la thinking_level: "low": o comparație conceptuală, un tabel rezumat și 2 exemple SQL pentru a găsi cea mai recentă comandă a fiecărui client, unul cu un join pe tabel derivat și unul cu o subinterogare corelată în lista SELECT. Primele cuvinte au apărut aproape instantaneu, ceea ce este și ideea.

Acel print() final e acolo cu un motiv. Fără el, ultima bucată se termină la mijloc de linie, iar zsh afișează un % rătăcit înainte de prompt, pentru că stream-ul se oprește exact unde se oprește textul modelului. De asemenea, delta-urile poartă text doar dacă înregistrezi numărul de tokeni per cerere, citește-le din evenimentul final de completare, nu aduna bucățile.

Cum schimbă thinking_level costul și calitatea?

thinking_level stabilește cât raționament face Gemini 3.8 Flash înainte să scrie răspunsul. Tokenii de raționament se taxează la tariful de output, $3,75 per 1M, deci nivelul ales controlează direct costul și latența, iar Google spune că 3.8 se bazează intenționat pe asta: face pași suplimentari pe sarcini complexe și poate consuma mai mulți tokeni la niveluri de efort mai mari decât o făcea 3.7.

Rulează un singur prompt la low, medium și high

Testul este o condiție de cursă într-o funcție de reîncercare a plății, trimisă cu același prompt la toate cele 3 niveluri. Bug-urile de concurență pedepsesc citirea în diagonală, deci dacă nivelurile diferă, aici ar trebui să se vadă. Dacă rulezi un singur bloc de cod din acest articol, fă-l pe acesta, deoarece cifrele argumentează mai bine decât orice text.

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

Pentru context, vulnerabilitatea este un check-then-act neatomic pe payment_attempts[order_id]. În concurență, 2 thread-uri pot trece ambele condiția while și pot apela ambele charge_fn() înainte ca vreunul să incrementeze contorul. Rezolvarea înseamnă învelirea fluxului read-check-charge-increment într-un lock per comandă sau folosirea unei chei de idempotency la gateway.

Compararea rezultatelor

Rezultate din rulările mele:

Toate cele 3 niveluri au găsit dublarea taxării, și toate 3 au livrat locking per comandă, astfel încât comenzile fără legătură rulează în paralel. Acea a doua parte e titlul dacă compari asta pe 3.7: acolo, low a înfășurat totul într-un lock global ținut în timpul apelului de rețea, iar lock-urile per comandă au apărut abia la medium. Pe 3.8, low scrie acel design mai bun cu 0 tokeni de thinking, în 7,8 secunde, pentru mai puțin de o treime de cent.

Atunci ce mai aduc nivelurile? Adâncimea auditului. Acest cod are 4 moduri distincte de eșec (dublarea taxării, un KeyError la ștergere concurentă, o retrimitere la plată după ce calea de succes șterge starea și incrementări neatomice ale contorului), iar high a fost singurul nivel care le-a numit pe toate 4; low a ratat cazul de reîncărcare, iar medium a ratat contorul. 

high a fost și singurul care a detaliat semantica traseului de eșec al rezolvării: odată ce reîncercările sunt epuizate, apelanții ulteriori primesc False în loc să taxeze din nou.

Coloana de thinking este afirmația „3.8 muncește mai mult” a Google care apare în terminal. La același prompt pe 3.7, medium a trecut de la 2.343 tokeni de thinking la 3.158, iar high de la 2.217 la 4.512, aproximativ dublu, iar tokenii în plus au cumpărat o analiză mai completă, nu un verdict diferit. Latența a urcat în același pas în această rulare (7,8 s, 16,6 s, 25,5 s), dar timpii pe o singură rulare oscilează, deci compară numărul de tokeni, nu secundele.

Alege un implicit și când să escaladezi

Aceasta este regula mea generală pentru nivelurile de raționament:

• Pe 3.8, low și-a câștigat un rol mai mare decât sugerează implicitul medium de la Google: a produs o rezolvare corectă, bine proiectată, cu 0 tokeni de thinking, deci pornește de aici pentru orice citește un om înainte să conteze (triere, drafturi, rezumate, cod pe care îl vei revizui). 

• Păstrează medium unde outputul pleacă fără a fi citit, pentru că thinking-ul în plus a adus o analiză mai completă a modurilor de eșec, iar într-un pipeline necitit exact modul de eșec pe care nu l-ai listat este cel care se declanșează.

• Rezervă high pentru outputuri unde chiar traseul de eșec este produsul, cum ar fi fluxurile de plată, migrațiile sau orice ar verifica un reviewer linie cu linie. În rularea mea, a fost singurul nivel care a prins toate cele 4 bug-uri și a documentat ce se întâmplă după epuizarea reîncercărilor.

La 6.6x costul lui low pentru high, acel compromis arată foarte diferit la $3,75 per 1M tokeni output acum față de $7,50 după 31 decembrie 2026, deci escaladează per cerere, nu global.

O supapă utilă: Google afirmă că 3.7 Flash rămâne pe deplin suportat pentru workload-uri centrate pe eficiență. Dacă diligența în plus a lui 3.8 costă mai mult decât are nevoie sarcina ta, a rămâne pe gemini-3.7-flash pentru acel workload este o opțiune suportată, nu un hack.

Cum extragi date structurate dintr-un PDF?

Gemini 3.8 Flash citește direct PDF-uri ca input, deci poți trimite o factură sau un raport și poți pune întrebări despre el. Am folosit o factură de la un furnizor, de 1 pagină, cu număr de factură, date, 4 linii de poziții și un total.

Atașează un PDF la prompt

Hai să încărcăm local factura PDF folosind Files API. Files API gestionează stocarea fișierelor și caching-ul pe infrastructura Google:

	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)

Outputul din factura mea:

Toate cele 3 valori sunt corecte. Încărcarea se face o singură dată, iar fișierul rămâne disponibil pentru cereri ulterioare, ceea ce contează imediat ce pui mai mult de o întrebare despre același document. Răspunsul vine ca bullets markdown, ceea ce e ok pentru citit și nu ok pentru un pipeline.

Forțează JSON cu o schemă de răspuns

Ca să obții JSON în loc de proză, transmite o schemă în response_format. Pe Interactions API, acesta este un parametru de nivel superior; setarea responseMimeType din generationConfig pe care o vezi în tutoriale mai vechi aparține endpoint-ului legacy generateContent.

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)

Acesta este outputul pe care l-am primit: 

Clasa ta Pydantic definește câmpurile obligatorii și tipurile de date, în timp ce model_json_schema() generează schema JSON cerută de Gemini API. După procesare, json.loads() convertește outputul modelului într-un dicționar Python standard. Din acest punct, datele structurate sunt gata să fie convertite într-un rând de DataFrame, scrise într-o bază de date sau adăugate într-un Google Sheet.

Pune o întrebare de follow-up cu previous_interaction_id

Pentru a 2-a întrebare despre același document, transmite id-ul primei interacțiuni ca previous_interaction_id. Serverul are deja PDF-ul și primul schimb, deci nu mai trimiți niciunul:

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)

A returnat toate cele 4 poziții în ordine, inclusiv linia de compute repetată, fără să comenteze repetarea. Asta este comportamentul corect pentru întrebarea pusă; dacă vrei să marcheze anomalii, cere asta. 

Pentru ceea ce merită, 3.7 s-a comportat identic aici, deci diligența în plus a lui 3.8 se aplică raționamentului propriu, nu voluntariatului pentru audituri pe care nu le-ai cerut.

2 lucruri de știut despre acest apel: 

• response_format nu s-a păstrat, pentru că are scop pe interacțiune, deci acest turn a returnat proză. 

• Iar interacțiunile sunt stocate implicit (store=True) timp de 55 de zile pe planul plătit și 1 zi pe planul gratuit; store=False face apelul fără stare, dar nu mai poți înlănțui un previous_interaction_id din el.

Cum adaugi Function Calling în Gemini 3.8 Flash?

Function calling pe Gemini 3.8 Flash este un singur loop, în care modelul cere o unealtă, codul tău o rulează, trimiți rezultatul înapoi, iar modelul scrie răspunsul final. Această secțiune construiește manual acel loop.

Dacă vrei ca Google să-ți ruleze loop-ul cu agenți găzduiți multi-tool, citește următorul nostru tutorial despre „Managed Agents” în Gemini API. Iar dacă agenții sunt direcția pe termen lung, cursul Building AI Agents with Google ADK construiește un asistent complet de suport clienți pe aceleași primitive.

Definește o unealtă și execută loop-ul de interacțiune

Unealta este lookup_exchange_rate(currency, date), susținută de un mic dict în memorie, astfel încât exemplul rulează fără un API extern. Declarația este o schemă JSON. Modelul nu rulează niciodată funcția; el returnează un pas function_call cerând codului tău să:

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)

Outputul: 

S-au întâmplat 3 lucruri:  

1. Turnul 1 a returnat un pas function_call cu un nume, argumente structurate și un id.

2. Python-ul tău a rulat căutarea.

3. Turnul 2 a trimis un bloc function_result care face referire la acel apel. 

Parametrul tools este transmis din nou la turnul 2 din același motiv pentru care response_format a trebuit retransmis în secțiunea PDF: previous_interaction_id poartă istoric, nu configurare.

Greșeli de function calling pe Gemini 3.x

Dacă un loop de unelte se rupe, aproape întotdeauna e unul din 2 lucruri. 

Primul, fiecare rezultat trebuie să se map-eze înapoi la apelul lui. Pe Interactions API, asta înseamnă call_id și name pe blocul function_result; pe API-ul legacy generateContent, FunctionResponse trebuie să se potrivească cu id și name ale FunctionCall-ului precedent. Niciunul nu e opțional pe Gemini 3.x.

Al doilea, o eroare Malformed_Function_Call apare de obicei când modelul emite comentarii înainte de apelul uneltei. Ghidul pentru dezvoltatori 3.8 al Google spune să cureți textul de dinaintea uneltei, să formatezi instrucțiunile inline cu \n\n și să înfășori notițele de lucru într-un apel de funcție dedicat în loc de text brut. Strânge instrucțiunea de sistem; nu retrimite orbește.

Ce se strică atunci când treci la Gemini 3.8 Flash?

Depinde de unde pornești. 

• De la Gemini 3.7 Flash: nimic. Schimbă stringul modelului în gemini-3.8-flash, iar fiecare fragment din acest articol rulează nemodificat, pentru că suprafața API-ului este identică. 

• De la Gemini 3.6 Flash sau mai vechi, configurarea modelului cere același audit de 15 minute ca înainte.

Lista de migrare (de la 3.6 Flash sau mai vechi)

Parcurge-le în ordine. Elemente 1–3 provoacă imediat 400; elementele 4 și 5 provoacă probleme silențioase de calitate.

1. Schimbă ID-ul modelului la gemini-3.8-flash.

2. Șterge parametrii de sampling morți: temperature, top_p și top_k sunt ignorate sau respinse pe Gemini 3.x, iar frequency_penalty, presence_penalty și candidate_count aruncă o eroare activă de API. Elimină toate cele 6 din configurațiile legacy.

3. Înlocuiește thinking_budget cu thinking_level: folosește doar low, medium sau high. Valoarea veche minimal întoarce o eroare de validare. Trimiterea ambelor thinking_budget și thinking_level într-o singură cerere întoarce un 400.

4. Elimină turnurile modelului preumplute: scoate-le din orice conversație pe care o construiești și asigură-te că ultimul turn de user are text nevid. Payload-urile de istoric nu pot fi încheiate cu un turn de model.

5. Standardizează fluxurile multi-turn: bazează-te pe previous_interaction_id în loc de redarea istoricului pe client. Trebuie să re-specifici uneltele, system_instruction și generation_config la fiecare turn unde contează.

Google publică versiunea oficială în documentația modelelor Gemini API, inclusiv un traseu automatizat dacă agentul tău de coding suportă skills. Citește-o tu însuți o dată, chiar și așa; o migrare automată nu îți va spune de ce temperature=0.2 era acolo inițial.

Erori pe care le vei întâlni în producție

Iată cele 4 coduri de stare pentru care merită să cabl ezi handler-e și ce înseamnă fiecare pe acest API:

Încă 2 lucruri aici:

• Setează timeouts explicite pe client când combini thinking_level: "high" cu loop-uri lungi de unelte, pentru că o cerere blocată e mai rea decât una eșuată, iar diligența în plus a lui 3.8 face mai probabile, nu mai puțin probabile, rulările lungi de raționament. 

• Și loghează interaction.id la fiecare cerere; este mânerul tău pentru recuperarea, depanarea sau ștergerea interacțiunilor stocate ulterior.

Gânduri finale

Tot ce e în acest articol se leagă de 3 schimbări. Interactions API a schimbat convenția de apel, thinking_level a înlocuit toate reglajele de sampling pe care le foloseai, iar starea server-side prin previous_interaction_id este cea care a făcut atât follow-up-ul pe PDF, cât și loop-ul de unelte să fie turnuri one-liner în loc de exerciții de redare a istoricului. Gemini 3.8 Flash nu a schimbat nimic din acea suprafață; a schimbat cât de mult muncește modelul în interior, motiv pentru care măsurătorile din acest articol au fost făcute proaspăt pe 3.8, nu preluate din 3.7.

Înainte să iei pe încredere recomandările mele de nivel, îndreaptă scriptul de comparație către o sarcină din propriul backlog; nivelul care câștigă pe o cursă de reîncercare a plății poate pierde pe workload-ul tău de generare SQL. 

Când apelurile unice la API nu mai sunt suficiente și vrei sisteme AI de producție, track-ul nostru Associate AI Engineer for Developers acoperă întregul parcurs, iar Associate AI Engineer for Data Scientists face același lucru din perspectiva datelor.