Description
Currently, provider config structs (config.OpenAI, config.Anthropic, config.Copilot) serve as both provider and interceptor configs. This means interceptors receive fields they don't use (e.g. CircuitBreaker), and providers carry fields only interceptors need (e.g. SendActorHeaders, ExtraHeaders). For example, the Copilot provider builds a full config.OpenAI with unused fields just to pass to the interceptors.
This lack of separation makes it unclear which fields belong to which layer, and makes it easy to accidentally couple provider-level concerns with interceptor behavior. As more providers share the same interceptor format (e.g. Copilot using OpenAI interceptors), keeping the configs separate ensures each layer only has access to what it needs.
We should introduce separate interceptor config structs that contain only what interceptors need. The provider constructs the interceptor config in CreateInterceptor(), passing only the relevant fields.
Description
Currently, provider config structs (
config.OpenAI,config.Anthropic,config.Copilot) serve as both provider and interceptor configs. This means interceptors receive fields they don't use (e.g.CircuitBreaker), and providers carry fields only interceptors need (e.g.SendActorHeaders,ExtraHeaders). For example, the Copilot provider builds a fullconfig.OpenAIwith unused fields just to pass to the interceptors.This lack of separation makes it unclear which fields belong to which layer, and makes it easy to accidentally couple provider-level concerns with interceptor behavior. As more providers share the same interceptor format (e.g. Copilot using OpenAI interceptors), keeping the configs separate ensures each layer only has access to what it needs.
We should introduce separate interceptor config structs that contain only what interceptors need. The provider constructs the interceptor config in
CreateInterceptor(), passing only the relevant fields.