azure foundry for goose discussion

azure_foundry_for_goose.md

Hey team, thanks for the detailed feedback on the PR. Before investing more time we wanted to share what we found in the codebase and get your guidance.

On the "over-engineered" point

gcpvertexai.rs in the same codebase solves the same structural problem for GCP Vertex AI: one endpoint, multiple publishers, multiple API wire formats. It is 1 226 lines (836 + 390 for formats) and is already merged.

Azure Foundry is the same situation with a wider surface:

Provider	Lines	Publishers	API wire formats	Auth
gcpvertexai.rs ✅ merged	1 226	3 (Google, Anthropic, MaaS)	2 (rawPredict + generateContent)	GCP OAuth
azure_foundry.rs PR	2 099	8 (Microsoft, Anthropic, Meta, Mistral, Cohere, AI21, Zhipu, DeepSeek)	3 (chat, Responses, Anthropic Messages)	API key + Entra ID
openai.rs	1 518	1 (OpenAI)	2 (chat + Responses)	API key
gemini_oauth.rs	1 137	1 (Google)	1	Google OAuth

We followed the same pattern as gcpvertexai.rs. The size difference is proportional to the wider publisher surface, not to incidental complexity.

On the thin provider suggestion Two hard blockers:

1. OpenAiCompatibleProvider always calls chat/completions ; it has no path to /v1/responses. Models o1, o3, o4-mini, gpt-5 fail silently on Azure Foundry with the thin provider. Supporting them requires routing logic, which is exactly what openai.rs (1 518 lines) added for the same reason.

2. DeclarativeProviderConfig has no auth_type field; only api_key_env: String. Azure Foundry with Entra ID and no static key (the standard enterprise setup) cannot be expressed as a JSON declarative provider. Rust code is required either way.

A thin provider also forces enterprise users to configure the same endpoint and same key three times under different env var names (one per wire format), multiplied by environments. The complexity moves from code (maintained once by contributors) to configuration (repeated by every user).

Concrete question

We see two paths forward and want your guidance before writing more code:

• Option A : Follow the gcpvertexai.rs precedent: a single provider file per cloud platform that handles multi-publisher routing internally. We submit the current PR as-is (cleaned up, split, one commit per concern).

• Option B: Extend gcpvertexai.rs itself to cover Azure Foundry alongside GCP, creating a single "multi-cloud Model Garden" provider. More ambitious but avoids parallel structure.

Happy to jump on a call or continue async here.