⚙️ OVERTLI Provider Settings
Set your keys once, stop pasting them everywhere
- settings_status
Every API-based node pack eventually answers the same question: where do I put my keys so I'm not pasting them into fourteen nodes? For the Overtli Studio Suite, the answer is GZ_ProviderSettings - a small settings sink the pack's own README tells you to add first. It's not a generator and it produces no media; it's the file where your credentials live.
What it saves
apply_settings is the only required input, and it defaults to true. With it on, the node writes whatever you've filled in to a persisted settings file in your ComfyUI user directory (ComfyUI/user/overtli_studio_settings.json). The fields map to the suite's backends:
pollinations_api_key- for the free-tier cap or paid Pollinations models (generate one at enter.pollinations.ai).lmstudio_base_url/lmstudio_api_key- LM Studio local server, which usually needs no key at all.openai_compatible_api_key/openai_compatible_base_url/openai_compatible_model- your Groq, Together AI, LocalAI, whatever.copilot_executable/copilot_model- only if you need to point at a specific GitHub Copilot CLI binary or model rather than auto-detection.
Every one of those optional fields can be left blank and the node still runs - it just reports what it did.
How resolution works
Understanding the precedence order here saves you a confusing afternoon. When any Overtli node needs a key or endpoint, it resolves in this order: node input (highest) → environment variable → persisted settings → suite default (lowest). So GZ_ProviderSettings is a floor, not a ceiling. If a GZ_TextEnhancer has an api_key field filled in, that wins over the saved one - which is exactly how a stale key you forgot about quietly overrides the settings you meant to use. When something "stops working after I set my keys", the first thing to check is a leftover per-node override.
Output
settings_status is a plain STRING - a human-readable message confirming what was saved or skipped. The node is marked as an output node in the schema, so it renders its status text on the canvas. It's not meant to feed anything downstream; treat it as a save button with receipts.
Why bother
Three concrete reasons. The suite nodes accept keys directly in their own fields, so you can skip this node - but then every workflow that uses them has your key embedded in the workflow JSON. Saved settings keep the secret in one file (which also makes it easy to keep out of version control), environment variables override both for CI or shared rigs, and a new workflow can be built without re-typing anything.
Install and gotchas
It installs with the rest of the pack - search "Overtli" in ComfyUI Manager, or clone the repo into custom_nodes and pip install -r requirements.txt (the deps are just requests, Pillow, numpy), then restart. One gotcha: set apply_settings to false if you keep the node in a workflow you share with others - otherwise every time they run it, the node overwrites their settings file with whatever your saved values were. If a shared workflow suddenly points your whole suite at someone else's base URL, that's what happened.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| apply_settings | BOOLEAN | true | — |
| pollinations_api_keyopt | STRING | — | |
| lmstudio_base_urlopt | STRING | — | |
| lmstudio_api_keyopt | STRING | — | |
| openai_compatible_api_keyopt | STRING | — | |
| openai_compatible_base_urlopt | STRING | — | |
| openai_compatible_modelopt | STRING | — | |
| copilot_executableopt | STRING | — | |
| copilot_modelopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| settings_status | STRING | — |