Add support for custom HTTP request headers in LlmProvider

[l2dy]

LlmProvider supports custom endpoint and access_key, but not HTTP headers. This is needed in case a provider mandates non-standard headers for authentication or telemetry.

archgw/crates/common/src/configuration.rs

Lines 254 to 267 in c4a4f3f

	pub struct LlmProvider {
	pub name: String,
	pub provider_interface: LlmProviderType,
	pub access_key: Option<String>,
	pub model: Option<String>,
	pub default: Option<bool>,
	pub stream: Option<bool>,
	pub endpoint: Option<String>,
	pub port: Option<u16>,
	pub rate_limits: Option<LlmRatelimit>,
	pub usage: Option<String>,
	pub routing_preferences: Option<Vec<RoutingPreference>>,
	pub cluster_name: Option<String>,
	}

[salmanap]

That's a fair ask @l2dy - but we do honor all headers from the client as passthrough. The code block doesn't reflect that part (which it should, we should be explicit about header shapes). Would that work if the client passes additional headers, or are you thinking that this should be fully transparent to the client?

[l2dy]

Would that work if the client passes additional headers, or are you thinking that this should be fully transparent to the client?

I'm thinking of the later because I need to support several clients with different configuration format, some of which may not even support custom headers, so being transparent is better.

[salmanap]

Fair. This should be in after we merge the agentic orchestration update.

[salmanap]

  - model: together_ai/openai/gpt-oss-20b
    access_key: $TOGETHER_API_KEY'
    http_headers:
      X-Custom-Header: "custom-value"
      X-API-Version: "v1"

here is what I am thinking as the fastest way to implement this, and it is still practical

[salmanap]

@l2dy would love the feedback on the developer experience. Getting ready to build it out and want to make sure this aligns with how you were thinking about this.

[l2dy]

would love the feedback on the developer experience. Getting ready to build it out and want to make sure this aligns with how you were thinking about this.

Yes, that sounds practical. Thanks for asking!