Skip to main content
snowglobe is configured through environment variables. They’re grouped into three layers so you can stop reading once you’ve found what you need:
  1. Connection & auth — the handful most setups touch.
  2. Throughput — three top-level knobs that cover the common “go faster / wait longer / retry more” cases. Prefer these.
  3. Advanced — the per-feature knobs the throughput knobs derive. Set these directly only when you have a specific reason.

​
Where to set them

Any of these work; later sources win over earlier ones:
  1. The built-in default (or, for an advanced knob, the value derived from a throughput knob).
  2. A line in .snowglobe/config.rc (KEY=value, one per line). This file is created by snowglobe init.
  3. An exported shell variable (export KEY=value) — always wins.
Values in .snowglobe/config.rc are loaded into the environment at startup, so a line in that file behaves exactly like exporting the variable in your shell.

​
Connection & auth

​
Changing the port

The wrapper runs a local server (bound to SNOWGLOBE_CLIENT_PORT) and then calls itself over HTTP to drive completions. The URL it uses, SNOWGLOBE_CLIENT_URL, defaults to http://localhost:<SNOWGLOBE_CLIENT_PORT>, so to move the server you set only the port:
Set SNOWGLOBE_CLIENT_URL explicitly only for the unusual case where the wrapper’s server is reached on a different host or through a proxy:
Don’t set the port inside SNOWGLOBE_CLIENT_URL while also setting SNOWGLOBE_CLIENT_PORT to a different value — the wrapper would bind one port and call another. Set the port once via SNOWGLOBE_CLIENT_PORT.

​
Throughput

These three knobs cover what most users want to tune. Set one and the CLI derives a consistent set of advanced values for you (any advanced variable you set explicitly still wins). A higher-throughput run is usually a single line:
At startup the CLI checks your values against Snowglobe’s server-side ceilings and prints a one-line warning (non-fatal) if one is too high — for example a completion timeout longer than upstream services honor.

​
What each knob derives

If you need to understand or override the underlying behavior, here’s the mapping:

​
Advanced

Set these directly only when the throughput knobs don’t give you the shape you need. They are process-wide, not per-agent: one wrapper serving three agents shares one set of limits.

​
Dispatch & rate limiting

Raise dispatch concurrency and the inbound rate limit together. As a rule of thumb keep COMPLETIONS_PER_SECOND ≥ COMPLETION_BATCH_SIZE × 5, or self-dispatched completions get rate-limited under bursty polling. Using the SNOWGLOBE_MAX_PARALLEL_COMPLETIONS knob keeps this ratio correct automatically.

​
Timeouts & retries

​
Polling & heartbeat

​
Misc