feat(cloud): support Anthropic provider base URL
Tests / Test passed: 665

This commit is contained in:
2026-07-14 07:58:38 +08:00
parent 8b7e5a2800
commit 9250254dec
13 changed files with 124 additions and 39 deletions
@@ -10,9 +10,9 @@ administrator Console, CSRF protection, and auth audit records that this
change can reuse.
The existing runtime clients instantiate provider SDKs with no arguments and
therefore read keys from their environment. Database-backed credentials and
an OpenAI-compatible base URL require those clients to accept explicit values
while preserving the unchanged direct-transport default.
therefore read keys from their environment. Database-backed credentials and a
custom base URL require those clients to accept explicit values while
preserving the unchanged direct-transport default.
## Goals / Non-Goals
@@ -22,8 +22,8 @@ while preserving the unchanged direct-transport default.
- Encrypt every stored Provider API key and never return or log its plaintext.
- Switch the provider/model used by all cloud-transport Host Agents without a
Host configuration change, Cloud API restart, or local credential.
- Support OpenAI-compatible endpoints through a configurable base URL and
API key using the existing Chat Completions tool-calling implementation.
- Support custom base URLs for Anthropic native tool use and OpenAI-compatible
Chat Completions tool calling without changing their respective protocols.
- Remove Cloud API environment-based planner Provider configuration so every
cloud-transport decision is governed by the active database profile.
@@ -32,8 +32,8 @@ while preserving the unchanged direct-transport default.
- Provider usage billing, connection-test endpoints, model discovery, or
support for protocols other than Anthropic native tool use and OpenAI Chat
Completions tool calling.
- Arbitrary Anthropic-compatible endpoints, custom request headers, or
different OpenAI-compatible parameter dialects.
- Custom request headers or different Anthropic/OpenAI-compatible parameter
dialects.
- Automatic encryption-master-key rotation. Provider API key rotation is
supported by updating a profile; master-key rotation remains an operational
migration until a key-ring design is separately proposed.
@@ -103,16 +103,16 @@ backup or read access would expose external-provider credentials. Alternative
considered: a database-held master key. Rejected because it does not create a
separate protection boundary.
### D4: Treat OpenAI-compatible as a concrete wire-protocol contract
### D4: Treat each provider wire protocol as a concrete contract
Profiles have `provider_type` of `anthropic` or `openai-compatible`. An
`openai-compatible` profile may omit `base_url` to use the official OpenAI
endpoint, or supply an absolute HTTP(S) base URL for a compatible service.
Profiles have `provider_type` of `anthropic` or `openai-compatible`. Either
profile may omit `base_url` to use its official provider endpoint, or supply
an absolute HTTP(S) base URL for a compatible proxy or provider service.
The runtime `OpenAIToolCallingClient` gains optional `api_key` and `base_url`
constructor arguments and constructs `OpenAI` explicitly when supplied.
`AnthropicToolCallingClient` gains an optional explicit API key for cloud-held
credentials; absent optional arguments retain current SDK environment
behavior for direct transport.
`AnthropicToolCallingClient` gains optional explicit API key and `base_url`
arguments and constructs `Anthropic` explicitly when supplied. Absent optional
arguments retain current SDK environment behavior for direct transport.
Compatibility means the endpoint accepts OpenAI Chat Completions requests
with the tool/function-calling fields emitted by the existing client and
@@ -10,7 +10,7 @@ control plane for its planner decisions.
- Add a durable, Cloud-wide catalog of planner Provider profiles. Each profile
records its supported provider kind (`anthropic` or `openai-compatible`),
model, timeout, optional OpenAI-compatible base URL, enabled state, and an
model, timeout, optional base URL, enabled state, and an
encrypted API key.
- Add an administrator-only Cloud API and Cloud Console view to create, list,
update, activate, disable, and retire Provider profiles. Read responses
@@ -25,10 +25,10 @@ control plane for its planner decisions.
credential.
- Add an encryption-key configuration for protecting Provider API keys at rest
and document deployment, rotation, and migration behavior.
- Extend the existing provider client construction so cloud-managed
OpenAI-compatible profiles pass their encrypted API key and configured base
URL explicitly to the OpenAI SDK, while Host Agent direct transport continues
to use its existing environment-based credentials.
- Extend the existing provider client construction so cloud-managed profiles
pass their encrypted API key and configured base URL explicitly to the
Anthropic or OpenAI SDK, while Host Agent direct transport continues to use
its existing environment-based credentials.
## Capabilities
@@ -6,7 +6,7 @@ credentials -- not any value supplied by the requesting Host Agent -- to
resolve a planner-decision request to exactly one tool name and one arguments
object, within the request's timeout. The endpoint SHALL resolve the active
database-managed Provider profile for every request and use its provider,
model, timeout, OpenAI-compatible base URL when applicable, and encrypted
model, timeout, configured base URL, and encrypted
cloud-held credential. It SHALL NOT read Cloud API planner Provider/model/
timeout/API-key environment variables.
@@ -4,9 +4,8 @@
The Cloud Control Plane SHALL persist administrator-managed LLM Provider
profiles with a unique name, provider type, model, timeout, enabled state,
revision, and timestamps. A profile's provider type SHALL be either
`anthropic` or `openai-compatible`; an OpenAI-compatible profile MAY specify
an absolute HTTP(S) base URL and SHALL use the official OpenAI endpoint when
it does not.
`anthropic` or `openai-compatible`; either profile MAY specify an absolute
HTTP(S) base URL and SHALL use its official provider endpoint when it does not.
#### Scenario: Administrator creates an OpenAI-compatible profile
- **WHEN** an authorized administrator submits a unique profile name,
@@ -15,6 +14,13 @@ it does not.
- **THEN** the Cloud Control Plane persists an enabled profile with a new
revision and returns its non-secret metadata
#### Scenario: Administrator creates an Anthropic profile with a custom base URL
- **WHEN** an authorized administrator submits a unique profile name,
`anthropic` provider type, model, valid timeout, API key, and a valid
Anthropic-compatible base URL
- **THEN** the Cloud Control Plane persists the normalized URL with the profile
and returns its non-secret metadata
#### Scenario: Invalid profile configuration is rejected
- **WHEN** an administrator submits an unsupported provider type, blank model,
non-positive timeout, duplicate name, or invalid base URL
@@ -81,6 +87,12 @@ reconfiguration.
tool-calling request to that base URL using the profile's decrypted API key
and returns the resulting single tool-call decision
#### Scenario: Active Anthropic profile is used with a custom base URL
- **WHEN** the active profile is Anthropic and includes a base URL
- **THEN** the Cloud Control Plane makes the existing Anthropic native
tool-calling request to that base URL using the profile's decrypted API key
and returns the resulting single tool-call decision
### Requirement: Cloud planner Provider configuration is database-only
The Cloud Control Plane SHALL resolve Cloud planner Provider, model, timeout,
base URL, and API key from the active database profile and SHALL NOT read
@@ -26,3 +26,9 @@
- [x] 5.1 Document encryption-key provisioning, required active-profile cutover, OpenAI-compatible configuration, removed planner environment variables, and rollback in Cloud deployment documentation.
- [x] 5.2 Run relevant backend tests, Console tests/build, format/lint, compile checks, and strict OpenSpec validation; resolve failures.
## 6. Anthropic custom base URL
- [x] 6.1 Allow Anthropic Provider profiles to validate and persist an optional custom base URL, and pass it to the Cloud planner client.
- [x] 6.2 Extend `AnthropicToolCallingClient` to construct the Anthropic SDK with an explicit base URL while preserving direct-transport defaults.
- [x] 6.3 Expose the Base URL field for Anthropic in the Cloud Console; add backend/runtime tests and update deployment/specification documentation.