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.

[Amitesh-AJ10]

I've rebased onto main and resolved the conflicts. It looks like the new Claude Review action is hitting an OIDC authentication error on this PR (Invalid OIDC token), so that failure seems to be an infra issue on the repo side.