feat(acp): list named custom providers (declared-models catalogs) in the ACP model selector

[israellot]

What & why

Named endpoints from the providers: mapping (and the legacy custom_providers: list) never appear in the ACP model selector. _build_model_state lists only the canonical current provider's catalog, and canonical provider enumeration does not include user-defined named endpoints — so editor clients (Zed, VS Code ACP integrations) silently hide endpoints the user configured.

This completes #47039 on the surface it missed: that issue was closed as implemented-on-main because the TUI /model picker renders named endpoints as distinct rows (hermes_cli/model_switch.py), resolves custom:<name> selections (hermes_cli/runtime_provider.py), and documents the /model custom:name:model syntax. The ACP surface never got the same treatment.

Concrete case: an OpenAI-compatible Bedrock Mantle Responses provider (providers.bedrock-mantle with key_env/api_mode: codex_responses) works via /model custom:bedrock-mantle:openai.gpt-5.5 in the TUI but is unselectable from an editor.

How

• New module-level _named_custom_provider_catalogs() in acp_adapter/server.py: builds (slug, label, models) groups from get_compatible_custom_providers() (covers both config shapes, deduplicated). Slugs use the existing custom:<name> shape, so encoded choice ids (custom:<name>:<model>) round-trip through parse_model_input / resolve_runtime_provider on set_session_model with zero changes to the selection path.
• _build_model_state appends these groups after the current provider's catalog.
• Model lists: declared models (default_model + models) first, extended by live /models discovery when a credential resolves and discover_models is not disabled. Declared models survive failed discovery by design — this is the load-bearing case, not an edge case (see below).
• Honors providers.<name>.enabled: false and skips entries with no credential and no declared models.

Why declared models are the mechanism (not pattern allowlists or discovery-only)

Some OpenAI-compatible endpoints expose no /models route at all yet serve their declared models fine. Bedrock Mantle is the concrete case: GET /openai/v1/models returns 404, while the Responses route serves exactly four GPT models (verified live against bedrock-mantle.us-east-1.api.aws, one smoke call per candidate id):

model	result
openai.gpt-5.5, openai.gpt-5.6-sol, openai.gpt-5.6-terra, openai.gpt-5.6-luna	✅ served
openai.gpt-5.5-pro, openai.gpt-5.6-*-pro, openai.gpt-5.4-mini	❌ "does not exist"

With no discovery route, a wildcard/pattern generalization (e.g. openai.gpt-*) cannot be validated against anything and would list models that 400 at runtime. The user's models: declaration is the only trustworthy source for such endpoints, and adding a newly-GA'd model is a one-line config change. Endpoints that DO expose /models still get live discovery layered on top of the declared list.

How to test

scripts/run_tests.sh tests/acp/test_named_provider_catalogs.py   # 8 new tests
scripts/run_tests.sh tests/acp/                                  # full ACP suite

Manual: add a named provider to config, e.g.

providers:
  bedrock-mantle:
    name: AWS Bedrock Mantle
    base_url: https://bedrock-mantle.us-east-1.api.aws/openai/v1
    key_env: BEDROCK_MANTLE_API_KEY
    api_mode: codex_responses
    default_model: openai.gpt-5.5
    models:
      openai.gpt-5.6-sol: {}
      openai.gpt-5.6-terra: {}
      openai.gpt-5.6-luna: {}

then connect an ACP client (hermes acp + Zed) and open the model selector — all four declared models appear under "AWS Bedrock Mantle" and selecting one switches the session to that endpoint. Verified end-to-end on a live config: the catalog helper returns custom:bedrock-mantle with exactly the four declared models despite the 404ing /models route.

Platforms tested

Linux fully verified (scripts/run_tests.sh tests/acp/ — 318 passed, 0 failed). Windows/macOS not manually tested; scripts/check-windows-footguns.py clean on both touched files.

Related

• Completes [Feature Request]: Support multiple API endpoints per provider with selectable list in custom provider #47039 (named custom endpoints — TUI-only implementation) on the ACP surface.
• Related: fix(acp): split custom:name/model and provider/model model names (#53545) #53558 — independent. That PR fixes custom:name/model parsing on the selection path; this PR fixes the listing side. They compose without overlap.
• Related: feat(bedrock): support OpenAI Responses models #53880 / feat(bedrock): add OpenAI GPT-5.6 family (Sol/Terra/Luna) to Mantle Responses routing #65076 — independent. Those route openai.gpt-5.x through the native bedrock provider via a Mantle/Responses allowlist; this PR makes any user-declared named endpoint selectable without core routing changes. If those merge, the named-endpoint path remains useful for every other /models-less OpenAI-compatible endpoint.

Open to renaming the helper or moving it into hermes_cli if maintainers prefer the catalog logic outside the ACP adapter.

Infographic

[amanning3390]

Hi @israellot — cross-posting from #70404 so this isn't only visible on my side. @alt-glitch flagged in triage that our two PRs overlap, and @Bartok9 asked us to agree on sequencing rather than have one closed as a duplicate.

Both PRs modify the same _build_model_state in acp_adapter/server.py:

• Mine (feat(acp): expose authenticated cross-provider model choices #70404) replaces the enumeration source — curated single-provider list → the shared authenticated inventory (load_picker_context / build_models_payload), the same substrate hermes model, the TUI, and the dashboard use.
• Yours (feat(acp): list named custom providers (declared-models catalogs) in the ACP model selector #70082) appends named custom-provider (declared-models) catalogs, for endpoints where declared models are the only trustworthy source.

Proposal: mine lands first as the substrate, yours rebases on top. Reasoning — mine is the structural change to where models come from; yours adds one more group. In that order yours becomes a small additive delta. Reversed, whichever lands second redoes work.

I want to be clear that mine does not subsume yours. I checked rather than assumed. My flags are explicit_only=True, include_unconfigured=False, probe_custom_providers=False, and on my live config that does emit a custom:api.z.ai row — so some custom endpoints do surface. But for your load-bearing case — an endpoint with no /models route at all (your Bedrock Mantle example 404s on GET /openai/v1/models) — the shared inventory can return an empty model list where your declared-models path still yields the four ids that actually serve. That's a real gap mine doesn't close, and it's why I think yours should land on top of mine rather than be closed as redundant.

One heads-up if you do rebase: I've since bounded the inventory call with max_models=ACP_MAX_MODELS_PER_PROVIDER (200, matching hermes_cli/moa_cmd.py) after review feedback about editors rendering the full array. It's a per-provider cap and a no-op at current catalog sizes, but worth knowing it's there so your appended groups get consistent treatment.

Genuinely no stake in the order — if you'd rather land first, I'll rebase mine under yours. I only care that we don't merge two conflicting rewrites of the same function. Maintainers, happy to follow whichever sequencing you prefer.

[Bartok9]

Sequencing looks right to me: land #70404 first as the substrate (it replaces the enumeration source), then rebase this on top as the additive declared-models group. Your non-subsumption check is the important part — an endpoint with no /models route (the Bedrock Mantle 404 case) yields an empty inventory row where the declared-models path still returns the four ids that actually serve, so these are complementary, not duplicate. Please keep the max_models=ACP_MAX_MODELS_PER_PROVIDER (200) per-provider cap consistent on the appended groups when you rebase. Deferring to maintainers on final order.

[israellot]

Sequencing looks right to me too. Thanks !