feat: obol buy inference <provider> — BYOK onboarding (Venice, OpenRouter & co.) on a single provider registry

[bussyjd]

Why

Give a new user the shortest path to a working agent: bring an OpenRouter or Venice key and go. The headline command is the requested verb —

obol buy inference venice
obol buy inference openrouter --free

— which opens the provider's API-key page in the browser (hermes-agent-style), takes the key, and wires the agent's LiteLLM gateway to it. obol buy inference <seller-url> (or no arg) is unchanged — still the x402 crypto-paid seller flow. Dispatch keys on whether the positional argument matches a known provider id, so the two doors coexist behind one verb.

Two front doors, one engine

• obol buy inference <provider> — friendly onboarding. Resolves the key (--api-key → provider env var → prompt), opens SignupURL via openBrowser (skipped when a key is already in hand or non-TTY), then wires LiteLLM and syncs agents.
• obol model setup <provider> --api-key <key> — the scriptable, no-browser equivalent (CI/automation).

Both call the same setupCloudProvider engine, so behavior can't drift.

The registry refactor (the DB smell)

Provider knowledge was smeared across five sites — adding one provider meant editing all of them: knownProviders, the setup dispatch switch, a default-model switch, detectCredentials, and buildModelEntries. This PR collapses them into one source of truth: a richer ProviderInfo row (id, EnvVar/AltEnvVars, Mode, BaseURL, Default, SignupURL, Free) + ProviderByID. Every layer — buy/setup dispatch, default-model selection, credential auto-detection, LiteLLM entry shaping, and model status labelling — reads the registry. Adding a provider is one row, no switch edits.

What's added

provider	base_url	env var
venice	https://api.venice.ai/api/v1	VENICE_API_KEY
openrouter	https://openrouter.ai/api/v1	OPENROUTER_API_KEY
nvidia	https://integrate.api.nvidia.com/v1	NVIDIA_API_KEY
gmi	https://api.gmi-serving.com/v1	GMI_API_KEY
novita	https://api.novita.ai/openai/v1	NOVITA_API_KEY
huggingface	https://router.huggingface.co/v1	HF_TOKEN

All Mode=openai-compatible: entries are openai/<id> + explicit api_base + key from env, no wildcard. litellm-secrets is envFrom-mounted and record.go persists model_list verbatim, so new providers authenticate and survive obol stack up with zero changes to the secret/record layers.

Model resolution (no guessed ids)

Aggregator catalogs rotate, so hardcoding model ids would ship 404s. With --model omitted: the registry Default is used if set (openrouter/auto; native flagships for anthropic/openai), otherwise setup lists the live GET <base>/v1/models — a picker in a TTY, or a non-TTY error naming real ids. --free seeds OpenRouter's curated free snapshot (mapped from our hermes-agent free list), documented as rotating.

Tests

buildModelEntries openai-compatible shape + legacy fallback; ProviderByID; detectProvider labelling aggregators by api_base; registry invariants; the model setup and buy inference flag surfaces (incl. --free/--api-key) and the provider-vs-ollama dispatch gate. Existing anthropic/openai/ollama entry tests pass unchanged. Full go build + vet + test ./... green.

Follow-ups (not here)

• OAuth PKCE for OpenRouter (hermes uses api-key today, so this matches; PKCE is a nice-to-have).
• Cache /v1/models; live free-tier discovery (filter pricing==0) instead of a static snapshot.

🤖 Generated with Claude Code