Remove provider setup templates: named OpenAI-compatible hosts should be ordinary providers

[Hmbown]

The decision

Founder, 2026-09-16: the ProviderSetupTemplate layer "was never supposed to
happen — they should be normal providers like everyone else."

SenseNova, Baseten, Groq, Cerebras, Command Code and friends are currently
special-cased as named setup templates. They are ordinary OpenAI-compatible
Chat Completions hosts and should be configured the way every other custom
route already is.

Deleting this loses no capability

A full generic named-custom-provider mechanism already exists in
crates/config/src/lib.rs: parse_custom_provider_config_key (:1073),
named_custom_provider_id (:2795), named_custom_provider_table (:2802),
named_custom_provider_config (:2830), custom_provider_table_mut (:2843),
set_custom_provider_value (:2858). Any host with a base URL, a model and a
key env is already expressible as [providers.<name>].

Templates only pre-fill those three values for ten named vendors and put them
in a picker. That is a convenience list, not a capability — which is exactly
why it should not be a compiled-in enum of blessed vendors.

The module's own doc already concedes the architecture: "Hosted Chat
Completions backends are descriptor rows — not new enum variants and not
compiled model rosters. Live GET /v1/models and the Codewhale catalog are the
offering list." The templates are the last place that rule is not followed.

Blast radius (measured, not estimated)

crates/config/src/provider_templates.rs is 543 lines with 10 template rows.
Fourteen files reference the concept:

File	Notes
crates/config/src/provider_templates.rs	the module itself
crates/tui/src/tui/provider_picker.rs	188 mentions — the picker flow is the bulk of the work
crates/tui/src/tui/ui/apply.rs	AppAction::OpenTemplateSetup, new_for_template_list, new_for_template_setup
crates/tui/src/tui/app/types.rs	the AppAction variant
crates/tui/src/tui/views/mod.rs, model_picker.rs	view plumbing
crates/tui/src/commands/groups/core/provider.rs, setup.rs	/provider and /setup entry points
crates/config/src/lib.rs, settings_schema.rs	config surface
crates/tui/src/client.rs, pricing.rs, provider_catalog_live.rs, provider_lake.rs	route/pricing lookups

docs/PROVIDERS.md carries a table headed Template that goes with it.

What replaces it

/provider and /setup keep a path for "paste a Base URL and a key" — that is
the generic route, and it is what these vendors always were. The vendor list
becomes documentation (a table of known-good base URLs, models and key env
names) rather than compiled-in rows and a picker.

Sequencing

Not one sweep. provider_picker.rs is the bulk and should move on its own,
after the config-side rows are gone and the docs say what to do instead.

Related

• feat(providers): add AICraft OpenAI-compatible provider template #6171 / feat(providers): add the AICraft OpenAI-compatible provider template (#6171) #6288 added AICraft as an eleventh template. Closed in favour of this:
  AICraft is a legitimate provider (Hainan AICraft Matrix Technology Co., Ltd.,
  ICP 琼ICP备2026009730号-1) and stays supported as an ordinary configured
  provider. Note for whoever writes the replacement docs: that PR listed
  claude-4.6-sonnet as AICraft's default model, but AICraft advertises
  DeepSeek, Qwen, GLM, MiniMax and Doubao and lists no Anthropic models at all —
  do not carry that default across.

[BX166]

Thanks for #6288 — landing our two commits verbatim with authorship intact was a generous way to handle the fork-push 404, and the Lint fix was never ours to owe you.

No objection to #6289; nothing here to argue with. One correction for the record, though, since it is exactly the kind of note that gets copied forward into the replacement docs:

AICraft advertises DeepSeek, Qwen, GLM, MiniMax and Doubao and lists no Anthropic models at all

AICraft does list Anthropic models:

• Homepage hero: "支持 DeepSeek、Qwen、GLM、Claude、Gemini 等"
• https://aicraftapi.com/models.html — 11 Claude ids: claude-4.5-haiku, claude-4.5-sonnet, claude-4.5-opus, claude-4.6-sonnet, claude-4.6-opus, claude-4.7-opus, claude-4.8-opus, claude-fable-5, claude-fable-5.1, claude-opus-5, claude-sonnet-5. claude-4.6-sonnet is listed at ¥20.7/M in, ¥103.5/M out.

So the default we shipped was not off-brand — it is a model we actually sell. (Your review bot's read was right on this point: it is a plain Chat Completions literal, never pattern-matched for routing.)

That said, it is your docs, and a domestic-family default may well fit better — DeepSeek / Qwen / GLM are all live on the same endpoint, and we will go with whatever the person writing the table prefers. We would just rather the reason on the record not be "AICraft serves no Anthropic models", because that one is not true.

Two smaller things that may help whoever writes it:

• Happy to send the PR against the replacement docs once Remove provider setup templates: named OpenAI-compatible hosts should be ordinary providers #6289 lands. If you would rather write it yourself, ignore this.
• The unaddressed finding on feat(providers): add the AICraft OpenAI-compatible provider template (#6171) #6288 — the parallel crates/config/assets/provider_descriptors.json registry that the pricing-coverage safety net reads — probably belongs in the same pass, since a known-good table is the natural place to record what has pricing coverage.

[Hmbown]

Implemented on main: f8d00a3 deleted the setup-template picker stage and commands, d23ce39 replaced the template table with known-good-hosts docs, 6934619 keyed runtime behavior off endpoint, and 3d47149 deleted crates/config/src/provider_templates.rs outright. Verified zero remaining references and the file is gone. Named hosts are now ordinary providers.