Module verify 

Proving a provider credential actually works, before the config is written.

A key.starts_with("sk-ant-") check never touches the network, so ending lev setup with “All API keys look valid.” on that basis is a sentence that is false for a revoked key, a key pasted with a trailing space, a key for the wrong account, and every key belonging to a provider the check does not cover at all (Google, OpenRouter, Ollama). The first time the user learns otherwise is a failed agent run.

Every provider already implements list_models against a real endpoint - /v1/models on Anthropic and OpenAI, /v1beta/models on Gemini, /api/v1/models on OpenRouter, /api/tags on Ollama - so one call both proves the credential and returns the model list the wizard’s default-model picker needs. Two answers for the price of one round trip.

The seam

ProviderVerifier exists so no test ever reaches the network. Tests use a canned implementation, --no-verify uses SkipVerifier, and the binary wires in LiveVerifier. A failed check is always a warning and never a blocker: an offline laptop, a corporate proxy, or a provider outage must not stop someone finishing setup.

Structs

LiveVerifier

Production ProviderVerifier: really calls the provider.

SkipVerifier

--no-verify: report everything as unchecked without a round trip.

Enums

Outcome

What a verification attempt found out.

Traits

ProviderVerifier

Checks whether a set of provider credentials actually works.

Functions

verify_via_registry

Build a one-provider registry and ask it to list its models.

verify_via_registry_with

verify_via_registry, with client construction injected so the “no usable HTTPS client” outcome is reachable from a test.