feat: implement configurable LLM providers#853
Conversation
…ble) Implement the Configurable LLM Providers RFD so clients can discover and route the agent's LLM traffic through their own proxy or gateway without relying solely on the ad-hoc gateway auth _meta mechanism.
| providerId: PROVIDER_ID, | ||
| supported: SUPPORTED_PROTOCOLS, | ||
| required: true, | ||
| current: config ? { apiType: config.apiType, baseUrl: config.baseUrl } : null, |
There was a problem hiding this comment.
current: null` here means "unconfigured, using the agent's own default routing", but the schema defines it as disabled.**
The schema doc on
ProviderInfo.currentsays "Null or omitted means provider is disabled", and the RFD is stricter (behavior rule 5): a provider withcurrent: null"is disabled and MUST NOT be used by the agent for LLM calls."So a fresh agent (normal Claude login, no
providers/setor gateway auth) reports{ required: true, current: null }— per the spec that's a contradiction (a non-disableable provider that's disabled), and a strictly conformant client could render "main" as disabled or block prompting until a provider is configured, even though sessions work fine on default routing.Most clients will probably read
nullas "unconfigured" (which is what we mean), so nothing is broken today — but it'd be good to remove the ambiguity. Options:
- raise it upstream as an RFD clarification — the spec currently has no state for "enabled but agent-managed", which any agent with built-in default routing will hit, or
- report the actual effective default (
{ apiType: "anthropic", baseUrl: "https://api.anthropic.com" }) ascurrent— technically "current effective routing", though it risks implying client-managed routing is active when it isn't.
@anna239 got this from an agent review, I wonder if we need to handle this in the RFD somehow
There was a problem hiding this comment.
I rather don't understand why it has "required=true" if agent may be configured in other ways.
Disabling provider should be possible and will mean "unconfigured" -> default route.
Also I don't see reason why codex is treated differently then: https://github.com/agentclientprotocol/codex-acp/pull/272/changes#diff-ff482757b43f46e95ff8c07a2fca96aeab812e7d5d5f2076fbfedf81bdcfbd20R290
There was a problem hiding this comment.
Yeah that would also solve the concern
| providerId: PROVIDER_ID, | ||
| supported: SUPPORTED_PROTOCOLS, | ||
| required: true, | ||
| current: config ? { apiType: config.apiType, baseUrl: config.baseUrl } : null, |
There was a problem hiding this comment.
I rather don't understand why it has "required=true" if agent may be configured in other ways.
Disabling provider should be possible and will mean "unconfigured" -> default route.
Also I don't see reason why codex is treated differently then: https://github.com/agentclientprotocol/codex-acp/pull/272/changes#diff-ff482757b43f46e95ff8c07a2fca96aeab812e7d5d5f2076fbfedf81bdcfbd20R290
3 participants
According to custom endpoints rfd
Implement the Configurable LLM Providers RFD so clients can discover and route the agent's LLM traffic through their own proxy or gateway without relying solely on the ad-hoc gateway auth _meta mechanism.