feat: support Azure OpenAI via azure/ prefix

[Amitesh-AJ10]

Summary: Adds support for Azure OpenAI models (including OAuth/Entra ID) by recognizing the azure/ model prefix.

The Fix:

• Routing: Added azure/ as a recognized direct API prefix in llm_params.py and model_switcher.py. This stops the agent from incorrectly treating Azure models as Hugging Face router models.
• Auth: This change allows litellm to natively handle Azure credentials (like AZURE_AD_TOKEN or DefaultAzureCredential).
• UX: Updated CLI help text and docstrings to include azure/<model> as a supported format.

Verification: Verified locally that ml-intern --model azure/gpt-4o now bypasses the HF router check and correctly attempts to initialize the Azure client.

Fixes #59

[akseljoonas]

@claude please review this PR. Focus on correctness, security, LiteLLM/Bedrock routing impact, and whether it's safe to merge against current main. Keep it concise and prefer inline comments where it matters.

[claude]

Claude finished @akseljoonas's task in 1m 12s —— View job

---

PR Review: feat: support Azure OpenAI via azure/ prefix

• Read changed files and gather context
• Analyze correctness, security, routing impact
• Post review findings

---

Verdict: LGTM — safe to merge after rebase. The change is minimal, well-scoped, and follows the exact same pattern already established for openai/.

---

Correctness

The two core logic changes are correct:

llm_params.py:157 — startswith("openai/") → startswith(("openai/", "azure/")):
Routes azure/<model> into the direct-API branch instead of falling through to the HF router. LiteLLM natively handles azure/ by reading AZURE_API_KEY / AZURE_API_BASE / AZURE_API_VERSION (or AZURE_AD_TOKEN for Entra ID). No custom credential handling needed — correct delegation.

model_switcher.py:67 — HF catalog bypass for azure/:
Azure models don't exist in the HF router catalog, so skipping _print_hf_routing_info for them is the right call. Same logic as openai/.

The provider-aware error message in UnsupportedEffortError ("Azure" vs "OpenAI") is a nice touch.

is_valid_model_id (note from @statikkkkk)

The validator function itself (len(parts) >= 2 and all(parts)) already accepts azure/<model> — the docstring update is documentation-only, not a logic change. No gap here.

Security

No credential handling is introduced. The change relies entirely on LiteLLM's built-in Azure credential resolution chain (env vars → DefaultAzureCredential). Nothing sensitive is added or exposed. No injection surface — model string handling is identical to openai/.

LiteLLM Routing Impact

• Azure: Correctly bypasses the HF router; LiteLLM resolves Azure creds from env. ✓
• OpenAI / Anthropic / HF: Untouched. The startswith tuple is evaluated in order; no behavioral change for other prefixes. ✓
• Bedrock: Not present in this codebase — no impact.

Minor Notes (non-blocking)

1. Missing env-var startup hint: If AZURE_API_BASE is not set, the user will get a LiteLLM error at call time, not at model switch. Same pattern as OpenAI's OPENAI_API_KEY, so it's consistent — but a quick warning in _print_hf_routing_info (similar to the HF catalog warning) could improve first-use DX. Fix this →

2. reasoning_effort on non-o-series Azure models: Forwarding effort to e.g. azure/gpt-4o will be silently ignored or rejected by Azure. Not a new problem — same behavior as openai/gpt-4o. Fine as-is.

3. Rebase: Community commenter flags a conflict with current main. Maintainer should verify a clean rebase before merging.

---

Summary: Two startswith tuple expansions + doc/UX text updates. No routing regressions, no security concerns. The only action needed is a rebase.