Gemini 3.1 Pro Preview vs Customtools: which should you use?
Compare the two official Gemini 3.1 Pro model IDs, what Customtools changes, and when the regular Preview model fits your application.
Read as MarkdownBoth Gemini 3.1 Pro names are official Google model IDs. gemini-3.1-pro-preview is the regular model. gemini-3.1-pro-preview-customtools is a variant designed to make better use of custom tools when an agent also has access to bash. The suffix does not mean “more thinking,” and the regular model already supports function calling.[1]
For general coding, document analysis and multimodal questions, the regular Preview is a reasonable starting point. Consider comparing Customtools when your agent repeatedly chooses a shell command instead of the custom function you intended it to use. That recommendation follows the documented distinction; this article does not report a new A/B benchmark.
The two Gemini 3.1 Pro model IDs
Copy the complete identifier into your configuration. Both IDs contain preview; Customtools is a separate choice within that release family.
| Model ID | Documented purpose | Useful evaluation question |
|---|---|---|
gemini-3.1-pro-preview | General model with reasoning and function calling | Does it complete the task accurately with the supplied context? |
gemini-3.1-pro-preview-customtools | Better prioritization of custom tools when bash is also available | Does it select the intended custom tool and use its result correctly? |
Google lists the two names together on the model page. It also warns that the Customtools version may show quality variation on queries that do not benefit from that tool workflow. A different suffix is therefore a reason to evaluate a specific behavior, not evidence of an across-the-board upgrade.[1]
The shared model specification lists a 1,048,576-token input limit, a 65,536-token output limit, multimodal input and text output. Those headline limits do not tell you which tool an agent will select in a particular conversation. Keep the model identifier, tool definitions and task outcome separate when comparing results.
What Customtools changes
Google describes a preference for custom functions such as view_file and search_code when bash is available too. This matters when your application has already defined narrow tools with predictable outputs and permissions.[1]
Consider a hypothetical coding assistant with three choices: a function that reads one file, another that searches repository symbols, and a general shell tool. The task is to locate the definition of a function. Both a repository search function and a shell command could help. The useful question is whether the model chooses the tool that best matches your application's intended workflow.
That is an illustrative scenario, not a captured response from either model. Customtools does not guarantee a particular call, remove the need to declare functions, or take over your application's permission checks. Your application still decides whether to execute a call and what result to return.
The distinction is most relevant after you have observed a tool-selection problem. If the regular model already chooses the intended function and completes the task, changing variants adds another variable without first identifying an improvement to measure.
Customtools is not a thinking level
Gemini 3.1 Pro has separate low, medium and high thinking levels. The native generateContent default is high; minimal is not supported for this model. These are generation settings, not alternate model IDs.[2]
Changing from low to high may change the reasoning budget used for a task. Changing the model ID to Customtools targets tool-selection behavior. If you change both at once, a different answer cannot tell you which change mattered.
For a useful comparison, keep the same prompt, tool declarations, conversation history, thinking level and output limit. Google also recommends keeping temperature at 1.0 for Gemini 3. Compare whether the requested work was completed, which tools were called, whether arguments were valid, and how much usage the response reported. Those are evaluation suggestions, not measured advantages of either variant.
You can use functions with regular Preview
The official regular-model specification lists function calling as supported. You do not need the Customtools suffix to declare a function, receive a function call, execute it in your application, and send the result back.[1]
Use native tools[].functionDeclarations for the function interface. Preserve returned content parts and thought signatures when continuing the conversation. A failure caused by a missing signature, an invalid argument schema or an incorrectly assembled tool response is a protocol problem; switching model names does not establish that it has been fixed.
The Gemini 3.1 Pro API reference lists the native fields and their constraints. Start with a small function and a result you can check before adding an entire tool collection.
Choose for the workflow you actually have
Choose regular Preview first when the work is primarily text generation, code explanation, document extraction or multimodal analysis. It is also a valid starting point for a tool-using application. Define what a successful result looks like before evaluating it.
Compare Customtools when the application combines bash with custom tools and you have a concrete selection issue to reproduce. Keep a short set of representative cases: one where the narrow function is appropriate, one that genuinely requires the shell, and one where no tool should be called. Review both the selected action and the final result.
Do not judge a variant only by how often it calls your preferred tool. An unnecessary function call is still unnecessary. A useful model must select an appropriate action, supply valid arguments, interpret the result and answer the original request.
Google's pricing page groups both IDs in the same model price table. That does not make thinking, processing-tier choices or token usage interchangeable. Check the applicable current rates and inspect actual usage when comparing requests.[3]
Which version does SeedRouter connect?
The Gemini 3.1 Pro page uses gemini-3.1-pro-preview. The Customtools variant is not connected by this integration. The page provides the regular model's Playground and live group pricing; the API reference records current verification limits.
USD per 1M tokens
| Item | googlellm · ≤ 200,000 uncached input tokens | googlellm · > 200,000 uncached input tokens | googlellm-vertext · ≤ 200,000 uncached input tokens | googlellm-vertext · > 200,000 uncached input tokens |
|---|---|---|---|---|
| Input | $0.80 | $1.60 | $1.00 | $2.00 |
| Output, including thinking | $4.80 | $7.20 | $6.00 | $9.00 |
| Cached input | $0.08 | $0.16 | $0.10 | $0.20 |
Standard processing rates. The 200,000-token boundary counts uncached input. Cached tokens are billed separately and are not billed again as uncached input. Tool charges and cache storage are separate from these token examples.
Use the exact regular model ID in your application. Keep processing settings explicit for a controlled evaluation, and check the result on your own task before treating a configuration as suitable for production.
Frequently asked questions
Are both Gemini 3.1 Pro model names official?
Yes. Google documents both gemini-3.1-pro-preview and gemini-3.1-pro-preview-customtools on the same model page. The latter is a specialized variant, not an unofficial spelling.
Does Customtools replace normal function calling?
No. Normal function calling is already available in regular Preview. Customtools changes the model's preference in a mixed custom-tool and bash workflow; your application still declares and executes functions.
Is Customtools always better for coding?
Google does not make that blanket claim. Its documented distinction concerns tool selection, and its model page warns of quality variation outside the intended workflow. Compare the behavior your coding application actually needs.
Sources
Checked on October 17, 2026. The comparison above is based on documentation, not a newly run quality benchmark.
- Google: Gemini 3.1 Pro model specification — official IDs, input/output limits, function calling and the Customtools distinction.
- Google: native Gemini 3 developer guide — thinking levels, native request settings and temperature guidance.
- Google: Gemini API pricing — the shared official price table for the two model IDs.



