Gemini 3.1 Pro Preview vs Customtools: Welche Variante passt?
Vergleichen Sie die beiden offiziellen Gemini 3.1 Pro Modell-IDs: Was Customtools ändert und wann das reguläre Preview zu Ihrer Anwendung passt.
Als Markdown lesenBeide Gemini 3.1 Pro Namen sind offizielle Google-Modell-IDs. gemini-3.1-pro-preview ist das reguläre Modell. gemini-3.1-pro-preview-customtools ist eine Variante, die benutzerdefinierte Tools besser nutzen soll, wenn ein Agent auch Zugriff auf bash hat. Das Suffix bedeutet nicht „mehr Thinking“, und das reguläre Modell unterstützt bereits Funktionsaufrufe.[1]
Für allgemeine Programmierung, Dokumentenanalyse und multimodale Fragen ist das reguläre Preview ein sinnvoller Ausgangspunkt. Ziehen Sie einen Vergleich mit Customtools in Betracht, wenn Ihr Agent wiederholt einen Shell-Befehl statt der von Ihnen vorgesehenen benutzerdefinierten Funktion auswählt. Diese Empfehlung folgt der dokumentierten Unterscheidung; dieser Artikel berichtet keinen neuen A/B-Benchmark.
Die beiden Gemini 3.1 Pro Modell-IDs
Kopieren Sie den vollständigen Bezeichner in Ihre Konfiguration. Beide IDs enthalten preview; Customtools ist eine separate Auswahl innerhalb dieser Versionsfamilie.
| Modell-ID | Dokumentierter Zweck | Hilfreiche Prüffrage |
|---|---|---|
gemini-3.1-pro-preview | Allgemeines Modell mit Reasoning und Funktionsaufrufen | Erledigt es die Aufgabe mit dem bereitgestellten Kontext korrekt? |
gemini-3.1-pro-preview-customtools | Bessere Priorisierung benutzerdefinierter Tools, wenn auch bash verfügbar ist | Wählt es das vorgesehene benutzerdefinierte Tool und verwendet dessen Ergebnis richtig? |
Google führt die beiden Namen gemeinsam auf der Modellseite auf. Google warnt außerdem, dass die Customtools-Version bei Anfragen, die nicht von diesem Tool-Ablauf profitieren, Qualitätsschwankungen zeigen kann. Ein anderes Suffix ist daher ein Anlass, ein bestimmtes Verhalten zu prüfen, und kein Beleg für eine allgemeine Verbesserung.[1]
Die gemeinsame Modellspezifikation nennt ein Eingabelimit von 1.048.576 Token, ein Ausgabelimit von 65.536 Token, multimodale Eingabe und Textausgabe. Diese Eckdaten sagen nicht aus, welches Tool ein Agent in einer bestimmten Unterhaltung auswählt. Betrachten Sie Modellbezeichner, Tool-Definitionen und Aufgabenergebnis beim Vergleich getrennt.
Was Customtools ändert
Google beschreibt eine Bevorzugung benutzerdefinierter Funktionen wie view_file und search_code, wenn auch bash verfügbar ist. Das ist relevant, wenn Ihre Anwendung bereits eng abgegrenzte Tools mit vorhersehbaren Ausgaben und Berechtigungen definiert hat.[1]
Stellen Sie sich einen hypothetischen Programmierassistenten mit drei Möglichkeiten vor: einer Funktion zum Lesen einer einzelnen Datei, einer weiteren zum Suchen nach Repository-Symbolen und einem allgemeinen Shell-Tool. Die Aufgabe besteht darin, die Definition einer Funktion zu finden. Sowohl eine Repository-Suchfunktion als auch ein Shell-Befehl könnten helfen. Die nützliche Frage ist, ob das Modell das Tool wählt, das am besten zum vorgesehenen Ablauf Ihrer Anwendung passt.
Dies ist ein veranschaulichendes Szenario, keine aufgezeichnete Antwort eines der Modelle. Customtools garantiert keinen bestimmten Aufruf, ersetzt nicht die Deklaration von Funktionen und übernimmt keine Berechtigungsprüfungen Ihrer Anwendung. Ihre Anwendung entscheidet weiterhin, ob sie einen Aufruf ausführt und welches Ergebnis sie zurückgibt.
Die Unterscheidung ist vor allem relevant, nachdem Sie ein Problem bei der Tool-Auswahl beobachtet haben. Wenn das reguläre Modell bereits die vorgesehene Funktion wählt und die Aufgabe erledigt, fügt ein Variantenwechsel eine weitere Variable hinzu, ohne zuvor eine messbare Verbesserung zu bestimmen.
Customtools ist keine Denkstufe
Gemini 3.1 Pro bietet die separaten Denkstufen low, medium und high. Der Standard für natives generateContent ist high; minimal wird für dieses Modell nicht unterstützt. Dies sind Generierungseinstellungen und keine alternativen Modell-IDs.[2]
Ein Wechsel von low zu high kann das für eine Aufgabe verwendete Reasoning-Budget verändern. Ein Wechsel der Modell-ID zu Customtools zielt auf das Verhalten bei der Tool-Auswahl. Ändern Sie beides gleichzeitig, lässt eine andere Antwort nicht erkennen, welche Änderung maßgeblich war.
Für einen aussagekräftigen Vergleich behalten Sie denselben Prompt, dieselben Tool-Deklarationen, denselben Gesprächsverlauf, dieselbe Denkstufe und dasselbe Ausgabelimit bei. Google empfiehlt außerdem, temperature für Gemini 3 bei 1.0 zu belassen. Vergleichen Sie, ob die angeforderte Arbeit erledigt wurde, welche Tools aufgerufen wurden, ob Argumente gültig waren und welchen Verbrauch die Antwort meldete. Dies sind Bewertungsvorschläge, keine gemessenen Vorteile einer der Varianten.
Funktionen lassen sich mit regulärem Preview nutzen
Die offizielle Spezifikation des regulären Modells nennt Funktionsaufrufe als unterstützt. Sie benötigen das Customtools-Suffix nicht, um eine Funktion zu deklarieren, einen Funktionsaufruf zu empfangen, ihn in Ihrer Anwendung auszuführen und das Ergebnis zurückzusenden.[1]
Verwenden Sie native tools[].functionDeclarations für die Funktionsschnittstelle. Bewahren Sie zurückgegebene Inhaltsteile und Denksignaturen beim Fortsetzen der Unterhaltung auf. Ein Fehler durch eine fehlende Signatur, ein ungültiges Argumentschema oder eine falsch zusammengesetzte Tool-Antwort ist ein Protokollproblem; ein Wechsel des Modellnamens belegt nicht, dass es behoben wurde.
Die Gemini 3.1 Pro API-Referenz nennt die nativen Felder und ihre Einschränkungen. Beginnen Sie mit einer kleinen Funktion und einem überprüfbaren Ergebnis, bevor Sie eine ganze Tool-Sammlung hinzufügen.
Für den tatsächlichen Arbeitsablauf wählen
Wählen Sie zunächst reguläres Preview, wenn es hauptsächlich um Textgenerierung, Codeerklärung, Dokumentenextraktion oder multimodale Analyse geht. Auch für eine Anwendung mit Tool-Nutzung ist es ein gültiger Ausgangspunkt. Definieren Sie vor der Bewertung, wie ein erfolgreiches Ergebnis aussieht.
Vergleichen Sie Customtools, wenn die Anwendung bash mit benutzerdefinierten Tools kombiniert und Sie ein konkretes Auswahlproblem reproduzieren können. Halten Sie eine kleine Sammlung repräsentativer Fälle bereit: einen, in dem die spezialisierte Funktion passt, einen, der tatsächlich die Shell benötigt, und einen, in dem kein Tool aufgerufen werden sollte. Prüfen Sie sowohl die gewählte Aktion als auch das Endergebnis.
Bewerten Sie eine Variante nicht nur danach, wie oft sie Ihr bevorzugtes Tool aufruft. Ein unnötiger Funktionsaufruf bleibt unnötig. Ein nützliches Modell muss eine passende Aktion auswählen, gültige Argumente liefern, das Ergebnis interpretieren und die ursprüngliche Anfrage beantworten.
Googles Preisseite führt beide IDs in derselben Modellpreistabelle. Das macht Denkaufwand, Wahl der Verarbeitungsstufe oder Tokenverbrauch nicht austauschbar. Prüfen Sie die jeweils geltenden aktuellen Tarife und den tatsächlichen Verbrauch beim Vergleich von Anfragen.[3]
Welche Version bindet SeedRouter an?
Die Gemini 3.1 Pro Seite verwendet gemini-3.1-pro-preview. Die Customtools-Variante ist durch diese Integration nicht angebunden. Die Seite bietet den Playground des regulären Modells und aktuelle Gruppenpreise; die API-Referenz dokumentiert die derzeitigen Prüfgrenzen.
USD pro 1 Mio. Token
| Posten | googlellm · ≤ 200.000 ungecachte Eingabe-Token | googlellm · > 200.000 ungecachte Eingabe-Token | googlellm-vertext · ≤ 200.000 ungecachte Eingabe-Token | googlellm-vertext · > 200.000 ungecachte Eingabe-Token |
|---|---|---|---|---|
| Eingabe | 0,80 $ | 1,60 $ | 1,00 $ | 2,00 $ |
| Ausgabe einschließlich Thinking | 4,80 $ | 7,20 $ | 6,00 $ | 9,00 $ |
| Zwischengespeicherte Eingabe | 0,08 $ | 0,16 $ | 0,10 $ | 0,20 $ |
Tarife für Standard-Verarbeitung. Die Schwelle von 200.000 Token zählt ungecachte Eingabe. Gecachte Token werden separat berechnet und nicht erneut als ungecachte Eingabe abgerechnet. Tool-Gebühren und Cache-Speicherung sind von diesen Token-Beispielen getrennt.
Verwenden Sie die exakte ID des regulären Modells in Ihrer Anwendung. Legen Sie Verarbeitungseinstellungen für eine kontrollierte Bewertung explizit fest und prüfen Sie das Ergebnis an Ihrer eigenen Aufgabe, bevor Sie eine Konfiguration als produktionsgeeignet einstufen.
Häufig gestellte Fragen
Sind beide Gemini 3.1 Pro Modellnamen offiziell?
Ja. Google dokumentiert sowohl gemini-3.1-pro-preview als auch gemini-3.1-pro-preview-customtools auf derselben Modellseite. Letzteres ist eine spezialisierte Variante und keine inoffizielle Schreibweise.
Ersetzt Customtools normale Funktionsaufrufe?
Nein. Normale Funktionsaufrufe stehen bereits im regulären Preview zur Verfügung. Customtools ändert die Präferenz des Modells in einem Ablauf mit benutzerdefinierten Tools und bash; Ihre Anwendung deklariert und führt Funktionen weiterhin selbst aus.
Ist Customtools beim Programmieren immer besser?
Google stellt keine solche pauschale Behauptung auf. Die dokumentierte Unterscheidung betrifft die Tool-Auswahl, und die Modellseite warnt vor Qualitätsschwankungen außerhalb des vorgesehenen Ablaufs. Vergleichen Sie das Verhalten, das Ihre Programmieranwendung tatsächlich benötigt.
Quellen
Geprüft am 17. Oktober 2026. Der obige Vergleich basiert auf Dokumentation und nicht auf einem neu durchgeführten Qualitätsbenchmark.
- Google: Gemini 3.1 Pro Modellspezifikation — offizielle IDs, Eingabe-/Ausgabelimits, Funktionsaufrufe und die Customtools-Unterscheidung.
- Google: nativer Gemini 3 Entwicklerleitfaden — Denkstufen, native Anfrageeinstellungen und Empfehlungen für temperature.
- Google: Gemini API Preise — die gemeinsame offizielle Preistabelle der beiden Modell-IDs.



