3 Methoden zur Behebung des Konfliktfehlers zwischen thinking_budget und thinking_level in der Gemini API

Erhalten Sie beim Aufrufen der Modelle Gemini 3.0 Pro Preview oder gemini-3-flash-preview den Fehler thinking_budget and thinking_level are not supported together? Dies ist ein Kompatibilitätsproblem, das durch Parameter-Upgrades der Google Gemini API zwischen verschiedenen Modellversionen verursacht wird. In diesem Artikel analysieren wir die Ursache dieses Fehlers aus der Perspektive der API-Design-Evolution und zeigen Ihnen die korrekten Konfigurationsmethoden.

Zentraler Nutzen: Nach der Lektüre dieses Artikels werden Sie die korrekte Konfiguration der Denkmodus-Parameter für Gemini 2.5- und 3.0-Modelle beherrschen, häufige API-Aufruffehler vermeiden und die Inferenzleistung sowie die Kostenkontrolle optimieren.

Kernelemente der Evolution der Gemini API Denkmodus-Parameter

Kernunterschiede der Gemini Denkmodus-Parameter

Der Hauptgrund für die Einführung des Parameters thinking_level in Gemini 3.0 durch Google ist die Vereinfachung der Konfigurationserfahrung für Entwickler. Während thinking_budget in Gemini 2.5 verlangt, dass Entwickler die Anzahl der Denk-Token präzise schätzen, abstrahiert thinking_level in Gemini 3.0 diese Komplexität in vier semantische Stufen, was die Einstiegshürde für die Konfiguration senkt.

Diese Designänderung spiegelt die Abwägung von Google bei der API-Entwicklung wider: Ein gewisses Maß an Feinsteuerung wird zugunsten einer besseren Benutzerfreundlichkeit und Konsistenz über verschiedene Modelle hinweg geopfert. Für die meisten Anwendungsszenarien ist die Abstraktion durch thinking_level völlig ausreichend. Nur wenn eine extreme Kostenoptimierung oder eine spezifische Kontrolle des Token-Budgets erforderlich ist, sollte man auf thinking_budget zurückgreifen.

💡 Technischer Rat: Für die praktische Entwicklung empfehlen wir, Schnittstellentests über die Plattform APIYI (apiyi.com) durchzuführen. Diese Plattform bietet eine vereinheitlichte API-Schnittstelle und unterstützt Modelle wie Gemini 2.5 Flash, Gemini 3.0 Pro und Gemini 3.0 Flash. Dies hilft Ihnen, die tatsächlichen Auswirkungen und Kostenunterschiede verschiedener Denkmodus-Konfigurationen schnell zu validieren.

Grundursache des Fehlers: Strategie zur Aufwärtskompatibilität beim Parameterdesign

Analyse der API-Fehlermeldung

{
  "status_code": 400,
  "error": {
    "message": "Unable to submit request because thinking_budget and thinking_level are not supported together.",
    "type": "upstream_error",
    "code": 400
  }
}

Der Kern dieser Fehlermeldung ist, dass thinking_budget und thinking_level nicht gleichzeitig existieren dürfen. Als Google neue Parameter in Gemini 3.0 einführte, wurden die alten Parameter nicht sofort entfernt, sondern eine Exklusivitätsstrategie angewandt:

• Gemini 2.5 Modelle: Akzeptieren nur thinking_budget, ignorieren thinking_level.
• Gemini 3.0 Modelle: Bevorzugen thinking_level, akzeptieren aber auch thinking_budget zur Abwärtskompatibilität. Es dürfen jedoch niemals beide gleichzeitig übergeben werden.
• Fehlerauslöser: Die API-Anfrage enthält sowohl den Parameter thinking_budget als auch thinking_level.

Warum tritt dieser Fehler auf?

Entwickler stoßen normalerweise in den folgenden drei Szenarien auf diesen Fehler:

🎯 Auswahl-Tipp: Wenn Sie die Version des Gemini-Modells wechseln, empfehle ich, die Parameterkompatibilität zuerst über die Plattform APIYI (apiyi.com) zu testen. Diese Plattform unterstützt den schnellen Wechsel zwischen den Serien Gemini 2.5 und 3.0, was es einfach macht, die Antwortqualität und Latenzunterschiede verschiedener Denkmodus-Konfigurationen zu vergleichen und Parameterkonflikte in der Produktion zu vermeiden.

3 Lösungen: Den richtigen Parameter passend zur Modellversion wählen

Lösung 1: Konfiguration für Gemini 2.5 (Verwendung von thinking_budget)

Geeignete Modelle: gemini-2.5-flash, gemini-2.5-pro usw.

Parameter-Details:

• thinking_budget: 0 – Deaktiviert den Denkmodus vollständig (geringste Latenz und Kosten).
• thinking_budget: -1 – Dynamischer Denkmodus, das Modell passt sich der Komplexität der Anfrage an.
• thinking_budget: <positive Ganzzahl> – Legt die Obergrenze der Thinking-Token präzise fest.

Minimalistisches Beispiel

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

response = client.chat.completions.create(
    model="gemini-2.5-flash-preview-04-17",
    messages=[{"role": "user", "content": "Erkläre das Prinzip der Quantenverschränkung"}],
    extra_body={
        "thinking_budget": -1  # Dynamischer Denkmodus
    }
)
print(response.choices[0].message.content)

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

response = client.chat.completions.create(
    model="gemini-2.5-flash-preview-04-17",
    messages=[{"role": "user", "content": "Erkläre das Prinzip der Quantenverschränkung"}],
    extra_body={
        "thinking_budget": -1,  # Dynamischer Denkmodus
        "include_thoughts": True  # Rückgabe der Denk-Zusammenfassung aktivieren
    }
)

# Denkprozesse extrahieren (falls aktiviert)
for part in response.choices[0].message.content:
    if hasattr(part, 'thought') and part.thought:
        print(f"Denkprozess: {part.text}")

# Finale Antwort extrahieren
final_answer = response.choices[0].message.content
print(f"Finale Antwort: {final_answer}")

Hinweis: Gemini 2.5 Modelle werden am 3. März 2026 eingestellt. Es wird empfohlen, frühzeitig auf die Gemini 3.0 Serie zu migrieren. Über die Plattform APIYI (apiyi.com) können Sie Qualitätsunterschiede vor und nach der Migration schnell vergleichen.

Lösung 2: Konfiguration für Gemini 3.0 (Verwendung von thinking_level)

Geeignete Modelle: gemini-3.0-flash-preview, gemini-3.0-pro-preview

Parameter-Details:

• thinking_level: "minimal" – Minimales Denken, nahezu Null-Budget, erfordert die Übergabe von Denk-Signaturen (Thought Signatures).
• thinking_level: "low" – Geringe Denkintensität, geeignet für einfache Anweisungsfolge und Chat-Szenarien.
• thinking_level: "medium" – Mittlere Denkintensität, geeignet für allgemeine Reasoning-Aufgaben (nur von Gemini 3.0 Flash unterstützt).
• thinking_level: "high" – Hohe Denkintensität, maximiert die Reasoning-Tiefe, geeignet für komplexe Probleme (Standardwert).

Minimalistisches Beispiel

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

response = client.chat.completions.create(
    model="gemini-3.0-flash-preview",
    messages=[{"role": "user", "content": "Analysiere die Zeitkomplexität dieses Codes"}],
    extra_body={
        "thinking_level": "medium"  # Mittlere Denkintensität
    }
)
print(response.choices[0].message.content)

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# Erste Dialogrunde
response_1 = client.chat.completions.create(
    model="gemini-3.0-flash-preview",
    messages=[{"role": "user", "content": "Entwirf einen LRU-Cache-Algorithmus"}],
    extra_body={
        "thinking_level": "high",
        "include_thoughts": True
    }
)

# Denk-Signaturen extrahieren (Gemini 3.0 gibt diese automatisch zurück)
thought_signatures = []
for part in response_1.choices[0].message.content:
    if hasattr(part, 'thought_signature'):
        thought_signatures.append(part.thought_signature)

# Zweite Dialogrunde, Übergabe der Signaturen zur Aufrechterhaltung der Reasoning-Kette
response_2 = client.chat.completions.create(
    model="gemini-3.0-flash-preview",
    messages=[
        {"role": "user", "content": "Entwirf einen LRU-Cache-Algorithmus"},
        {"role": "assistant", "content": response_1.choices[0].message.content, "thought_signatures": thought_signatures},
        {"role": "user", "content": "Optimiere die Speicherkomplexität dieses Algorithmus"}
    ],
    extra_body={
        "thinking_level": "high"
    }
)
print(response_2.choices[0].message.content)

💰 Kostenoptimierung: Für budgetsensible Projekte empfiehlt es sich, die Gemini 3.0 Flash API über die Plattform APIYI (apiyi.com) aufzurufen. Diese bietet flexible Abrechnungsmodelle und günstigere Preise, ideal für kleine bis mittlere Teams und Einzelentwickler. In Kombination mit thinking_level: "low" lassen sich die Kosten weiter senken.

Lösung 3: Strategie zur Parameteranpassung bei dynamischem Modellwechsel

Anwendungsfall: Wenn Ihr Code gleichzeitig Gemini 2.5 und 3.0 Modelle unterstützen muss.

Intelligente Funktion zur Parameteranpassung

def get_thinking_config(model_name: str, complexity: str = "medium") -> dict:
    """
    Wählt automatisch den richtigen Denkmodus-Parameter basierend auf der Modellversion.

    Args:
        model_name: Name des Gemini-Modells
        complexity: Denk-Komplexität ("minimal", "low", "medium", "high", "dynamic")

    Returns:
        Ein Dictionary mit Parametern für extra_body
    """
    # Gemini 3.0 Modell-Liste
    gemini_3_models = [
        "gemini-3.0-flash-preview",
        "gemini-3.0-pro-preview",
        "gemini-3-flash",
        "gemini-3-pro"
    ]

    # Gemini 2.5 Modell-Liste
    gemini_2_5_models = [
        "gemini-2.5-flash-preview-04-17",
        "gemini-2.5-flash-lite",
        "gemini-2-flash",
        "gemini-2-flash-lite"
    ]

    # Modellversion bestimmen
    if any(m in model_name for m in gemini_3_models):
        # Gemini 3.0 verwendet thinking_level
        level_map = {
            "minimal": "minimal",
            "low": "low",
            "medium": "medium",
            "high": "high",
            "dynamic": "high"  # Standardmäßig hoch
        }
        return {"thinking_level": level_map.get(complexity, "medium")}

    elif any(m in model_name for m in gemini_2_5_models):
        # Gemini 2.5 verwendet thinking_budget
        budget_map = {
            "minimal": 0,
            "low": 512,
            "medium": 2048,
            "high": 8192,
            "dynamic": -1
        }
        return {"thinking_budget": budget_map.get(complexity, -1)}

    else:
        # Unbekanntes Modell, standardmäßig Gemini 3.0 Parameter verwenden
        return {"thinking_level": "medium"}

# Anwendungsbeispiel
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

model = "gemini-3.0-flash-preview"  # Dynamisch umschaltbar
thinking_config = get_thinking_config(model, complexity="high")

response = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Ihre Frage"}],
    extra_body=thinking_config
)

🚀 Schnellstart: Wir empfehlen die Plattform APIYI (apiyi.com) für den schnellen Aufbau von Prototypen. Sie bietet sofort einsatzbereite Gemini API-Schnittstellen ohne komplexe Konfiguration. In nur 5 Minuten ist die Integration abgeschlossen und Sie können per Mausklick zwischen verschiedenen Denkmodus-Parametern wechseln, um die Ergebnisse zu vergleichen.

Detaillierte Erläuterung des Gemini 3.0 Thought Signatures Mechanismus

Was sind Thought Signatures?

Die in Gemini 3.0 eingeführten Thought Signatures (Gedankensignaturen) sind verschlüsselte Repräsentationen der internen Schlussfolgerungsprozesse (Reasoning) des Modells. Wenn Sie include_thoughts: true aktivieren, gibt das Modell eine verschlüsselte Signatur des Denkprozesses in der Antwort zurück. Diese Signaturen können Sie in nachfolgenden Dialogen übergeben, damit das Modell die Kontinuität der Reasoning-Kette beibehält.

Kernmerkmale:

• Verschlüsselte Darstellung: Der Inhalt der Signatur ist nicht lesbar und kann nur vom Modell selbst analysiert werden.
• Erhalt der Reasoning-Kette: Durch die Übergabe von Signaturen in Multi-Turn-Dialogen kann das Modell auf Basis seiner vorherigen Überlegungen weiter schlussfolgern.
• Automatische Rückgabe: Gemini 3.0 gibt Thought Signatures standardmäßig zurück, auch wenn diese nicht explizit angefordert wurden.

Praktische Anwendungsszenarien für Thought Signatures

import openai

client = openai.OpenAI(
    api_key="IHR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# Runde 1: Das Modell einen Algorithmus entwerfen lassen
response_1 = client.chat.completions.create(
    model="gemini-3.0-pro-preview",
    messages=[{"role": "user", "content": "Entwirf einen verteilten Rate-Limiting-Algorithmus"}],
    extra_body={
        "thinking_level": "high",
        "include_thoughts": True
    }
)

# Thought Signatures extrahieren
signatures = []
for part in response_1.choices[0].message.content:
    if hasattr(part, 'thought_signature'):
        signatures.append(part.thought_signature)

# Runde 2: Optimierung basierend auf dem vorherigen Reasoning
response_2 = client.chat.completions.create(
    model="gemini-3.0-pro-preview",
    messages=[
        {"role": "user", "content": "Entwirf einen verteilten Rate-Limiting-Algorithmus"},
        {
            "role": "assistant",
            "content": response_1.choices[0].message.content,
            "thought_signatures": signatures  # Thought Signatures übergeben
        },
        {"role": "user", "content": "Wie geht man mit Inkonsistenzen bei verteilten Uhren um?"}
    ],
    extra_body={"thinking_level": "high"}
)

💡 Best Practice: In Szenarien, die komplexes Multi-Turn-Reasoning erfordern (wie Systemdesign, Algorithmus-Optimierung oder Code-Reviews), empfiehlt es sich, die Auswirkungen der Signatur-Übergabe über die Plattform APIYI (apiyi.com) zu testen. Die Plattform unterstützt den vollständigen Gemini 3.0 Thought Signature Mechanismus, was die Verifizierung der Reasoning-Qualität unter verschiedenen Konfigurationen erleichtert.

Häufig gestellte Fragen (FAQ)

# Nur thinking_level übergeben und Antwort beobachten
response = client.chat.completions.create(
    model="ihr-modell-name",
    messages=[{"role": "user", "content": "test"}],
    extra_body={"thinking_level": "low"}
)
# Wenn ein 400-Fehler mit dem Hinweis erscheint, dass thinking_level nicht unterstützt wird, handelt es sich um Gemini 2.5.

Zusammenfassung

Die wichtigsten Punkte zu den Fehlermeldungen bei thinking_budget und thinking_level in der Gemini API:

1. Parameter-Exklusivität: Gemini 2.5 verwendet thinking_budget, während Gemini 3.0 thinking_level nutzt. Diese Parameter dürfen nicht gleichzeitig übermittelt werden.
2. Modellerkennung: Die Version wird anhand des Modellnamens identifiziert. Für die 2.5-Serie wird thinking_budget verwendet, für die 3.0-Serie thinking_level.
3. Dynamische Anpassung: Nutzen Sie eine Anpassungsfunktion, die basierend auf dem Modellnamen automatisch den richtigen Parameter auswählt, um Hardcoding zu vermeiden.
4. Denk-Signaturen (Thinking Signatures): Gemini 3.0 führt einen Mechanismus für Denk-Signaturen ein. Bei komplexen Szenarien mit mehreren Interaktionsrunden muss die Signatur übermittelt werden, um die Schlussfolgerungskette (Reasoning Chain) aufrechtzuerhalten.
5. Migrationsempfehlung: Gemini 2.5 wird am 3. März 2026 eingestellt. Es wird empfohlen, frühzeitig auf die 3.0-Serie zu migrieren.

Wir empfehlen APIYI (apiyi.com), um die tatsächlichen Auswirkungen der verschiedenen Konfigurationen des Denkmodus schnell zu validieren. Die Plattform unterstützt die gesamte Gemini-Modellreihe, bietet eine einheitliche Schnittstelle sowie flexible Abrechnungsmodelle und eignet sich ideal für schnelle Vergleichstests sowie den produktiven Einsatz.

Autor: APIYI-Technikteam | Bei technischen Fragen besuchen Sie bitte APIYI (apiyi.com), um weitere Lösungen für die Integration von Großes Sprachmodellen zu erhalten.