Proposal
Add AI/ML API as a branded provider preset on top of Zoo Code's existing OpenAI-compatible provider path.
The minimal scope would be:
- provider id/label:
aimlapi / AI/ML API
- API key field backed by
AIMLAPI_API_KEY
- fixed base URL:
https://api.aimlapi.com/v1
- bearer authentication through the existing OpenAI-compatible handler
- a small curated chat-model list for the first PR
- attribution headers on AI/ML API requests:
X-AIMLAPI-Partner-ID: Zoo-Code-Org
X-AIMLAPI-Integration-Repo: Zoo-Code-Org/Zoo-Code
X-AIMLAPI-Integration-Version: 1.0.0
Why this fits the current architecture
OpenAICompatibleHandler already accepts a fixed baseURL, API key, model id, and custom headers, so this should not require a new transport or inference implementation. The first version can avoid live model discovery and reuse the existing provider settings/model-picker patterns.
I can prepare the focused implementation, UI wiring, tests, and docs. Would maintainers accept a branded preset with this scope?
References:
Proposal
Add AI/ML API as a branded provider preset on top of Zoo Code's existing OpenAI-compatible provider path.
The minimal scope would be:
aimlapi/AI/ML APIAIMLAPI_API_KEYhttps://api.aimlapi.com/v1X-AIMLAPI-Partner-ID: Zoo-Code-OrgX-AIMLAPI-Integration-Repo: Zoo-Code-Org/Zoo-CodeX-AIMLAPI-Integration-Version: 1.0.0Why this fits the current architecture
OpenAICompatibleHandleralready accepts a fixedbaseURL, API key, model id, and custom headers, so this should not require a new transport or inference implementation. The first version can avoid live model discovery and reuse the existing provider settings/model-picker patterns.I can prepare the focused implementation, UI wiring, tests, and docs. Would maintainers accept a branded preset with this scope?
References: