[Feature] ACP mode has no model picker: no config options and no session/set_config_option

[AndriyPytel]

Affected area

Coding agent and CLI (ACP mode)

What is the problem?

ACP mode exposes no way to see or change the session's model. session/new returns only a sessionId, there is no session/set_config_option handler, and nothing in src/modes/acp/ reads the model catalog. A client is stuck with whatever model the agent started on for the life of the connection.

The TUI has a full picker on /model; over ACP the same session offers nothing. /model is also not usable as a workaround, since it opens a selector UI and has no headless behavior, so submitting it as prompt text just talks to the model about the word "model".

This is the "expose model selection" bullet from #1040, which is still open.

Proposed direction

Use ACP's session config options, which are the protocol's model picker (session/set_model does not exist; configOptions with category: "model" replaced it).

session/new returns:

{
  "id": "model",
  "name": "Model",
  "category": "model",
  "type": "select",
  "currentValue": "anthropic/claude-sonnet-4-5",
  "options": [{ "value": "anthropic/claude-sonnet-4-5", "name": "claude-sonnet-4-5", "description": "anthropic" }]
}

and session/set_config_option switches the model, answering with the complete configuration state as the spec requires.

Details that decide behavior:

• Value ids are the canonical provider/id reference — the key findExactModelReferenceMatch and the TUI picker already use. The same model id is served by more than one provider, so an id alone does not identify a model. A submitted value is resolved by matching the advertised ids rather than splitting the string, because a model id can itself contain a slash (prime-inference/z-ai/glm-5.2).
• Only models with configured credentials are offered (getAvailableModels()). The TUI lists the rest and starts a sign-in when one is picked; ACP has no sign-in flow, so an unauthenticated model would be a choice that only fails at the next prompt.
• Labels mirror the TUI rows: the model id as the option name, the provider as the description. Ordering is the TUI's tail ordering — provider, flagship models first, then id.
• No option when the current model is not selectable (no model, or its provider lost credentials). A select whose currentValue is not among its options is worse than no selector.
• No daemon protocol change: ACP runs on the daemon connection, and get_available_models and set_model are already daemon commands.

Reasoning level (category: "thought_level") is the obvious next config option, but it is a separate change.

Alternatives considered

Advertising every model in the catalog and letting a pick fail on the next prompt: rejected, an ACP client cannot run the sign-in that would fix it.

Grouping options by provider (SessionConfigSelectGroup): the shipped schema supports it, but the protocol docs only describe the flat form, so a client built from the docs would not render groups. A flat list with the provider as each option's description carries the same information.

Putting the picker in the Prime Agent _meta envelope: rejected, only a Prime-Agent-aware client would read it, and ACP has the standard field.

Additional context

I have a patch locally: ~75 lines in src/modes/acp/acp-mode.ts, plus docs/acp.md, the changelog, and two tests in test/suite/acp-mode.test.ts that drive a real ACP client over an in-memory duplex — one asserts the advertised option and its values, one switches the model and checks that the connection state followed and that an unadvertised value is rejected. npm run check is clean and test/suite/acp-mode.test.ts + test/suite/acp-features.test.ts are green (27 tests).

One test-infrastructure note that a reviewer would hit: the suite harness registers the faux provider's models on the ModelRegistry but not its stream, and ModelRegistry.refresh() calls resetApiProviders(), so the first code path that refreshes the model list unregisters the faux api and every later prompt in that harness fails with No API provider registered for api: faux:.... Carrying the faux stream as the provider's streamSimple makes the refresh restore it (one line in test/suite/harness.ts).

Opening this as a Discussion rather than an Issue per the new contribution process; happy to send the patch if a maintainer wants it.

[seyfal]

I've implemented this and can offer it per the contribution process (discussion first, PR on maintainer invitation).

Branch: https://github.com/seyfal/prime-agent/tree/acp-config-options — one commit touching src/modes/acp/ only, plus a test, docs, and a changelog fragment. npm run check (biome + tsgo + installer/browser smoke) and the ACP test suite pass.

What it does: session/new now reports standard session config options: a model select (category model) and a thinking select (category thought_level), and session/set_config_option applies either one, returning the updated option state. Everything is built from the same connection surface the TUI and RPC mode already use (getAvailableModels, getState, setModel, setThinkingLevel), so ACP clients see exactly the set /model offers — the authenticated models, not the full known catalog, because setModel only resolves models the user can run.

Value encoding: provider/model-id, the same pattern --model accepts, split at the first slash — model ids containing slashes (e.g. prime-inference/anthropic/claude-fable-5 → provider prime-inference, model anthropic/claude-opus-4.1-style ids) round-trip correctly. A model configured outside the catalog (models.json overrides) still renders as the current selection. Config-option discovery on session/new is best-effort: a failed catalog read degrades to a session without selectors, not a refused session.

Verified live against an authenticated install (built from this branch on Linux, driven over stdio JSONL): session/new reported the current model and a 108-model catalog with a thinking selector; session/set_config_option switched the session's model and the response reflected it; malformed and unknown values came back as JSON-RPC -32602 with a readable reason.

Context for appetite: I maintain a T3 Code integration that drives prime-agent over ACP, where this gap currently forces model discovery via prime-agent model list output parsing and model changes via a full session restart with a new --model. This would also give Zed/JetBrains users the model picker their ACP UIs already render from config options.

Happy to open the PR if a maintainer wants it, and to adjust scope — e.g. dropping the thinking selector, or adding a config_options_update notification when the model changes from an attached TUI.

[jschwxrz]

+1 from me. I use prime agent in emdash, but acp mode is not really usable without being able to set model/thinking. happy to open a pr!