Waldo.

Only to the AI provider you configure, and only what's needed for the conversation. Waldo has no cloud of its own — there's no Waldo server between you and your model. Point it at a local model (Ollama, LM Studio, or any OpenAI-compatible endpoint) and nothing leaves your desktop at all — a real option for government, utility, and defense shops that can't use cloud AI.

The licensed version makes exactly one kind of network call of its own: a background license check to our payment provider carrying your license key and its activation id — nothing else. Activating a key sends, once, an anonymous machine-id hash and the add-in version. Clicking “Check for updates” in Settings fetches a version number from waldogis.com — the request carries nothing about you or your project, and it only ever happens when you click. Trial mode makes no network calls at all.

You bring your own: an Anthropic or OpenAI API key (pay-as-you-go, typically cents per session), or a local model at no per-use cost. Waldo never marks up or meters your AI usage. If you've only ever used AI through a chat app, our plain-language guide to bringing your own AI walks you through it in about fifteen minutes.

Less than you'd expect, for a structural reason: the heavy lifting happens in ArcGIS Pro, not in the model. Waldo's tools return names, schemas, and summaries — never bulk data. When the model runs a geoprocessing tool on a million-row dataset, Pro crunches the rows; the model sees a compact receipt of what ran and what came out. Your data's size has essentially no effect on token cost.

We also cap tool output deliberately — long error lists, search results, and result blobs are truncated to what's actually useful — so one noisy operation can't flood the context window.

In practice, GIS sessions are shorter than typical AI coding sessions. Most asks — style a layer, build a layout, run an analysis chain — resolve in a handful of tool calls, not hours of back-and-forth over a large codebase. And because Waldo is bring-your-own-key, token usage shows up on your own provider dashboard. You can verify all of this yourself.

Not without asking. Anything that spends credits — geocoding, enrichment, routing — gets an estimate first, and Waldo proceeds only when you say yes.

Built-in assistants point you at the right tool. Waldo runs it — executes the geoprocessing, applies the symbology, builds the layout, exports the PDF — in your live session, with a logged receipt for every action. And it's model-agnostic: your choice of AI provider, including fully local.

Waldo is built defensively: outputs auto-rename rather than overwrite, scratch work stays in a scratch workspace, side effects are disclosed, and the full untruncated tool log is saved locally for every session. Geoprocessing receipts let you reopen any tool dialog pre-filled with the exact parameters Waldo used — verify, tweak, or re-run yourself.

Email support@waldogis.com — a real person reads it. The fastest route is the Report an issue button in Settings → About: it opens your session-logs folder alongside a pre-addressed email, so you can drag the log from the session where the problem happened straight onto the message. Nothing sends until you hit Send in your own mail app.

The session log is the best bug report we can get — Waldo keeps a complete local record of every chat session (one file per session, named by date and time, in %APPDATA%\Waldo\logs), and it usually shows exactly what went wrong. Logs never contain logins or API keys, but they do include your prompts and data paths, so feel free to skim before sending. A plain description with a screenshot works too — ideally with your Waldo version (Settings → About) and which AI provider and model you were using.

Windows and ArcGIS Pro 3.7 or later (developed and tested on Pro 3.7.1). Earlier Pro releases can't load the add-in. If your organization is on an older Pro version, tell us at hello@waldogis.com — support for earlier releases will be prioritized by demand.

Yes — ArcGIS Pro's standard well-known-folder deployment works: point the registry key at a network share and every machine loads it; one drop updates the whole org. Code-signing for orgs that require signed add-ins is planned for launch.