Four things #6694 left open. It stopped the model picker offering an OpenAI-compatible connection under a harness that cannot reach it. None of these blocked that, and they are grouped because they all sit on the same seam: deciding whether a model and a harness go together, from data that does not fully say.
Each can ship on its own.
1. A revision the server refuses says only "Message wasn't sent"
Open an agent whose saved model and harness the server refuses, for example the pair from #6692. The Model row shows an Unavailable pill, but that pill is inside a config section there is no reason to open. Type a message and send it. The composer accepts it, and the run fails with:
Message wasn't sent — try again.
Nothing says the model cannot run on this harness, or what to change. Expected: the composer says why, next to where the run starts, and points at the Model section.
A first attempt at this shipped and was reverted inside #6694 because its rule reported a false "cannot run" for three real configurations: a config authored through the API whose model id is spelled differently from the picker's, a model outside a connection's saved active-model list, and a subscription discovery failure while other candidates exist. Whatever replaces it has to be quiet in all three, and has to agree with the Unavailable pill rather than answering a different question. Today the pill reads harnessAllowsModel in @agenta/entity-ui and the composer reads connectModelGate in @agenta/chat.
2. The harness catalog does not publish which family each harness accepts through custom
GET /workflows/catalog/harnesses/ returns flat providers and deployments lists per harness. The pairing between them is not in the response, so the frontend infers it.
The SDK holds the real answer in HARNESS_CUSTOM_DEPLOYMENT_PROVIDERS (sdks/python/agenta/sdk/agents/capabilities.py), which harness_allows_pair enforces. Publishing it on the catalog would let the frontend read it instead.
Observable today: nothing, for the three harnesses that ship. A harness that reaches two families with neither being openai would lose every custom-connection model in the picker unless a harness policy is saved on the connection.
3. A connection whose name contains a slash can gain a harness it should not
Preconditions: a custom_provider record that carries model_keys but no saved models list, which is how records created before the saved-model list look.
Name such a connection anthropic/team and give it an OpenAI model. Its stored key is anthropic/team/custom/openai/gpt-4o-mini. The picker offers that model under Claude Code, which cannot run it. Expected: it appears under Pi only, the same as it does when the record has a saved model list.
4. The picker can highlight the wrong harness's row
Save an agent on a Claude Code model, then change the connection so that route is no longer offered. Open the model picker. The Pi row for the same model id is marked as selected, while the configuration still says Claude Code.
Nothing is rewritten, so the selection is intact; it is displayed as something it is not. selectedModelRowKey in web/packages/agenta-entity-ui/src/DrillInView/SchemaControls/connectionPicker.ts falls back across harnesses, which exists for saved selections that predate the connection slug. It needs to tell that case apart from a route that is simply unavailable now.
Where
web/packages/agenta-entities/src/secret/core/agentModelCandidates.tsweb/packages/agenta-entity-ui/src/DrillInView/SchemaControls/connectionPicker.tsweb/packages/agenta-chat/src/hooks/useAgentModelKeyStatus.tssdks/python/agenta/sdk/agents/capabilities.py
Follows #6692 and #6694. Items 2, 3 and 4 were raised in review of #6694 and accepted there as non-blocking.
Four things #6694 left open. It stopped the model picker offering an OpenAI-compatible connection under a harness that cannot reach it. None of these blocked that, and they are grouped because they all sit on the same seam: deciding whether a model and a harness go together, from data that does not fully say.
Each can ship on its own.
1. A revision the server refuses says only "Message wasn't sent"
Open an agent whose saved model and harness the server refuses, for example the pair from #6692. The Model row shows an
Unavailablepill, but that pill is inside a config section there is no reason to open. Type a message and send it. The composer accepts it, and the run fails with:Nothing says the model cannot run on this harness, or what to change. Expected: the composer says why, next to where the run starts, and points at the Model section.
A first attempt at this shipped and was reverted inside #6694 because its rule reported a false "cannot run" for three real configurations: a config authored through the API whose model id is spelled differently from the picker's, a model outside a connection's saved active-model list, and a subscription discovery failure while other candidates exist. Whatever replaces it has to be quiet in all three, and has to agree with the
Unavailablepill rather than answering a different question. Today the pill readsharnessAllowsModelin@agenta/entity-uiand the composer readsconnectModelGatein@agenta/chat.2. The harness catalog does not publish which family each harness accepts through
customGET /workflows/catalog/harnesses/returns flatprovidersanddeploymentslists per harness. The pairing between them is not in the response, so the frontend infers it.The SDK holds the real answer in
HARNESS_CUSTOM_DEPLOYMENT_PROVIDERS(sdks/python/agenta/sdk/agents/capabilities.py), whichharness_allows_pairenforces. Publishing it on the catalog would let the frontend read it instead.Observable today: nothing, for the three harnesses that ship. A harness that reaches two families with neither being
openaiwould lose every custom-connection model in the picker unless a harness policy is saved on the connection.3. A connection whose name contains a slash can gain a harness it should not
Preconditions: a
custom_providerrecord that carriesmodel_keysbut no savedmodelslist, which is how records created before the saved-model list look.Name such a connection
anthropic/teamand give it an OpenAI model. Its stored key isanthropic/team/custom/openai/gpt-4o-mini. The picker offers that model under Claude Code, which cannot run it. Expected: it appears under Pi only, the same as it does when the record has a saved model list.4. The picker can highlight the wrong harness's row
Save an agent on a Claude Code model, then change the connection so that route is no longer offered. Open the model picker. The Pi row for the same model id is marked as selected, while the configuration still says Claude Code.
Nothing is rewritten, so the selection is intact; it is displayed as something it is not.
selectedModelRowKeyinweb/packages/agenta-entity-ui/src/DrillInView/SchemaControls/connectionPicker.tsfalls back across harnesses, which exists for saved selections that predate the connection slug. It needs to tell that case apart from a route that is simply unavailable now.Where
web/packages/agenta-entities/src/secret/core/agentModelCandidates.tsweb/packages/agenta-entity-ui/src/DrillInView/SchemaControls/connectionPicker.tsweb/packages/agenta-chat/src/hooks/useAgentModelKeyStatus.tssdks/python/agenta/sdk/agents/capabilities.pyFollows #6692 and #6694. Items 2, 3 and 4 were raised in review of #6694 and accepted there as non-blocking.