Vertex Generation Config
One generation-config object to rule both generators
- generation_config
This node doesn't call any API and needs no credentials. It exists to build one GENERATION_CONFIG object that you can hand to both the image and text generators, so your sampling preferences live in one place instead of being scattered across widgets.
It's the pack's answer to a genuinely good question: the image node and text node each carry their own temperature and safety settings, and if you want them to agree (or to reuse a setup across workflows), you'd be retyping the same numbers everywhere. Wire a VertexGenerationConfig into either generator's generation_config input and it becomes the source of truth for those parameters.
What it builds
The node assembles the config dict that gets sent to Google, in the camelCase shape the Vertex API expects (topP, maxOutputTokens, responseModalities), plus a safetySettings block covering all four harm categories (hate speech, dangerous content, sexually explicit, harassment) at whatever threshold you pick. The fields, from the node's schema:
temperature(0–2) andtop_p(0–1) - sampling knobs.thinkingLevel- HIGH or LOW. This maps to Gemini 3 Pro Image's "thinking mode," the reasoning pass before generation that made Nano Banana Pro famous for following complicated instructions. HIGH is the default here.max_output_tokens(up to 32768) - how much output the model is allowed.safety_filter_level-BLOCK_NONE,BLOCK_ONLY_HIGH,BLOCK_MEDIUM_AND_ABOVE, orOFF. Default isOFF, i.e. no blocking, which tracks with how Google's own filters still apply server-side regardless.response_modalities-TEXT_AND_IMAGE,TEXT, orIMAGE; a config node connected to the image generator should stay on the image-bearing options.system_instruction(optional, multiline) - if you set it here, it overrides the generator's own system instruction.
One output: generation_config (GENERATION_CONFIG type).
The gotcha: the two generators read it differently
This is the part the README won't tell you. The image node honors temperature, topP, maxOutputTokens, responseModalities, safetySettings and systemInstruction from a connected config. The text node only picks up temperature, safetySettings, responseModalities and systemInstruction - it never reads the config's maxOutputTokens or topP keys, because the code looks for snake_case versions of those that this node never emits.
Practical upshot: if you build one config and feed it to both generators, the text node silently ignores your token and top-p settings and falls back to its own widgets. It's not a crash, just a quiet surprise. Sharing a config between the two nodes is fine - just know that the image side gets the full picture and the text side gets most of it.
Installing and using it
Same pack install as everything here - ComfyUI Manager → search comfyUI_Vertex_API, or the git clone + pip install -r requirements.txt route, then restart. In the graph: add it, set your parameters, and connect its generation_config output to the matching input on VertexGeminiImageGenerator or VertexGeminiTextGenerator. It's also the node you'll most want to pair with VertexSaveConfig - save it once, and VertexLoadConfig can pull the same setup back for every workflow.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| temperature | FLOAT | 1.00–2 | — |
| top_p | FLOAT | 0.950–1 | — |
| thinkingLevel | COMBO | HIGH | 2 options: HIGH, LOW |
| max_output_tokens | INT | 81921–32768 | — |
| safety_filter_level | COMBO | OFF | 4 options: BLOCK_NONE, BLOCK_ONLY_HIGH, BLOCK_MEDIUM_AND_ABOVE, OFF |
| response_modalities | COMBO | TEXT_AND_IMAGE | 3 options: TEXT_AND_IMAGE, TEXT, IMAGE |
| system_instructionopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| generation_config | GENERATION_CONFIG | — |