Provider Runtime

Provider runtime resolves an Anyy model selection into a concrete provider adapter call. It adapts provider APIs to agent.LLMProvider.

Provider Registry

Provider config is loaded from config.yaml and normalized into llm.ProviderConfig. Provider templates and setup metadata live in internal/providerprofiles.

Provider IDs, model IDs, aliases, auxiliary slots, auth modes, base URLs, and catalog policy are config/runtime data. They are not owned by sessions.

Request Builder

The request builder creates a provider-call copy from the persisted transcript. It may repair tool-call/tool-result pairing, apply provider prompt adaptation, derive cache policy, and trim oversized tool results.

It must not mutate the stored transcript or change Anyy identity text.

Streaming

Provider adapters emit agent.LLMStreamEvent values: message start, text delta, reasoning delta, tool call, message stop, usage, and error.

Adapters assemble provider-specific partial tool arguments before returning a complete tool call to the loop.

Fallback

Fallback is selected only when the provider error action hints allow it. A candidate must satisfy required capabilities such as tool calls, image input, video input, and reasoning replay unless config explicitly allows a drop.

Fallback attempts are visible through attempt traces, events, usage, and status.

Capability Resolution

Capabilities come from provider profile defaults, model catalog data, and tri-state config overrides. Runtime-resolved capabilities are plain booleans.

Capability checks should live in provider runtime or request building, not in TUI, dashboard, or channel clients.

Usage Accounting

Usage records include prompt/input/output/total tokens, cache read/write tokens, reasoning tokens, rate-limit metadata, retry count, and fallback routing when the provider exposes those fields.

Diagnostics must remain bounded and redacted. Do not log full provider payloads, secrets, or raw prompts.