Architecture

AI Providers is a provider-asset abstraction plus a shared request service. The design stays intentionally independent of Dialogue Graph System and AI Extension so other tools can reuse the same provider and transport layer.

High-level architecture

Caller
  -> AiProvidersService
  -> HTTP profile: LlmProviderDefinitionBase builds LlmHttpRequest
     -> HttpClient (async) or UnityWebRequest (coroutine)
     -> Provider API and provider-specific response extraction
  -> Codex / Claude Code profile: registered editor-only transport
     -> installed local tool

The async snapshot path sends through HttpClient; the coroutine adapter uses UnityWebRequest. Codex and Claude Code use editor-only registered transports instead of an HTTP provider endpoint.

Division of ownership

• Provider asset builds the concrete HTTP request and parses the provider-specific response.
• Service layer owns transport execution, timeout/retry behavior, and normalized HTTP error handling.
• DTO layer carries chat messages, model overrides, and the built request definition.

Base class contract

public abstract class LlmProviderDefinitionBase : ScriptableObject
{
    public abstract LlmHttpRequest BuildHttpRequest(LlmChatRequest chat);
    public abstract string ExtractTextFromResponse(string responseJson);
}

Package boundary and assemblies

The runtime and editor assemblies are AiProviders.Runtime and AiProviders.Editor; public namespaces use BekaForge.AIProviders. The package has no DGS assembly dependency. Protected local credential storage keeps API keys out of shared provider assets. Codex and Claude Code subscription transports remain editor-only and use local tool authentication.

Why provider assets matter

New providers are added as assets and subclasses rather than as giant switch statements in the service. That keeps endpoint rules, model defaults, and response parsing close to the specific provider implementation.