Context
We want Completions-compatible, Messages-compatible, and Responses-compatible as reusable base provider families. Named providers should compose these bases with endpoint/auth/defaults/options/model quirks rather than cloning protocol logic.
Scope
- Clarify or introduce base entrypoints for Completions-compatible, Messages-compatible, and Responses-compatible protocols.
- Define how named providers register endpoint/auth/defaults/options/model-specific quirks.
- Keep provider-specific behavior out of generic protocol code unless it is genuinely protocol-wide.
Acceptance Criteria
- There is a clear base for
/chat/completions compatible providers.
- There is a planned or implemented base for
/responses compatible providers.
- There is a planned or implemented base for Anthropic Messages-compatible providers.
- Named providers compose bases instead of duplicating protocol implementations.
Context
We want Completions-compatible, Messages-compatible, and Responses-compatible as reusable base provider families. Named providers should compose these bases with endpoint/auth/defaults/options/model quirks rather than cloning protocol logic.
Scope
Acceptance Criteria
/chat/completionscompatible providers./responsescompatible providers.