Context
The AIProvider interface defines the contract for providers, but there is no framework for creating new providers. Users who want to integrate a private LLM endpoint, AWS Bedrock, Mistral, or any other service must implement the interface manually.
Problem
- No option validation. A custom provider receives raw options with no schema validation. A typo in the API key field name or a missing required field is only discovered at the first API call, not at construction time.
- No metadata contract. Custom providers have no standard way to declare their
kind, capabilities, displayName, or description. These fields are ad-hoc and inconsistent.
- Second-class citizens. Built-in providers (OpenAI, Anthropic, Gemini) have structured initialization, but custom providers are just raw class implementations with no shared tooling.
- No introspection. There is no way to inspect a provider's option schema programmatically (e.g., for generating configuration UIs or JSON Schema).
Expected behavior
- A
defineProvider() function that accepts a Zod schema for options, a create function, and metadata.
- Options validated at creation time with clear error messages.
- Static metadata accessible on the factory function without calling it.
- Custom providers treated identically to built-in ones in discovery and registration.
Context
The
AIProviderinterface defines the contract for providers, but there is no framework for creating new providers. Users who want to integrate a private LLM endpoint, AWS Bedrock, Mistral, or any other service must implement the interface manually.Problem
kind,capabilities,displayName, ordescription. These fields are ad-hoc and inconsistent.Expected behavior
defineProvider()function that accepts a Zod schema for options, acreatefunction, and metadata.