Adding Providers
Add a provider when Anyy needs a new model transport or provider-specific auth/catalog behavior. Prefer provider profiles when the wire API already exists.
Provider Interface
Provider adapters implement the runtime path behind agent.LLMProvider. Common
provider types and config live in internal/llm; setup templates live in
internal/providerprofiles.
Do not call provider SDKs directly from gateway, TUI, dashboard, or channels.
Request Conversion
Request conversion maps agent.LLMRequest messages, tools, metadata, and
overlays into the provider wire format.
Keep provider-specific prompt adaptation in the provider runtime request copy. Do not mutate stored session messages.
Streaming Conversion
Streaming conversion maps provider events into agent.LLMStreamEvent values.
The loop expects complete tool calls and stable finish reasons.
Provider adapters are responsible for assembling partial tool-call arguments and mapping usage/rate-limit fields when present.
Capabilities
Declare capabilities for streaming, tool calls, JSON/schema support, context window, output limit, multimodal input, video input, reasoning, prompt cache, usage metadata, and credential refresh when supported.
Fallback compatibility depends on these values.
Catalog Metadata
Provider templates define display name, support level, API mode, default base URL, auth choices, catalog policy, default model, endpoint variants, and fallback model suggestions.
Setup and dashboard pages read this metadata. Keep wording user-facing and avoid embedding secrets or private endpoints.
Health Checks
Provider health and verification should classify errors through provider runtime: auth, quota, rate limit, overload, timeout, context overflow, model not found, payload too large, response format, and unknown.
Tests should cover request conversion, streaming conversion, error classification, capability defaults, fallback, and setup template output.