Rebrand Azure OpenAI to Azure AI Foundry - #1922
Conversation
Microsoft has rebranded Azure OpenAI Service to Azure AI Foundry. This updates user-facing references (docs, log messages, help text, and code comments) to use the new product name. Environment variable names, Azure role names, API paths, and endpoint domains remain unchanged because those are still the canonical Azure identifiers. - Rename docs/ai-providers/azure-openai.md to azure-ai-foundry.md - Update nav entries in mkdocs.yml and .nav.yml - Update provider pages, installation guides, env-var reference, eval docs, CONTRIBUTING, and benchmark CLI help text - Update log messages and code comments in holmes core and tests Signed-off-by: Claude <noreply@anthropic.com>
The page was renamed to azure-ai-foundry.md in the previous commit, but any existing external links to holmesgpt.dev/ai-providers/azure-openai/ would 404. Add a minimal stub with a meta-refresh so those links land on the new page. The stub is not listed in .nav.yml, so it does not appear in the sidebar navigation (awesome-nav only renders listed entries). Signed-off-by: Claude <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
📂 Previous Runs📜 #4 · Run @ __c683aa4__ (#24535662907) — Apr 16, 21:56 UTC✅ Results of HolmesGPT evalsAutomatically triggered by commit c683aa4 on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 48 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 #3 · Run @ __9c392bb__ (#24535519430) — Apr 16, 21:49 UTC✅ Results of HolmesGPT evalsAutomatically triggered by commit 9c392bb on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 48 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 #2 · Run @ __420be27__ (#24534696689) — Apr 16, 21:36 UTC✅ Results of HolmesGPT evalsAutomatically triggered by commit 420be27 on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 48 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 #1 · Run @ __e9535a4__ (#24534654455) — Apr 16, 21:28 UTC✅ Results of HolmesGPT evalsAutomatically triggered by commit e9535a4 on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 48 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
✅ Results of HolmesGPT evalsAutomatically triggered by commit 263274e on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 34 test/model combinations loaded Benchmark experiment:
No benchmark data available for comparison. Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📖 Legend
🔄 Re-run evals manually
Option 1: Comment on this PR with Or with more options (one per line): Run evals on a different branch (e.g., master) for comparison:
Quick re-run: Use Option 2: Trigger via GitHub Actions UI → "Run workflow" Option 3: Add PR labels to include extra evals (applies to both automatic runs and
Examples: 🏷️ Valid tags
🤖 Valid models
Commands: CLI: |
WalkthroughRenames provider branding from "Azure OpenAI" to "Azure AI Foundry" across docs, CLI/help text, comments, and logs; adds a new detailed azure-ai-foundry docs page with a redirect from the old page; removes an Azure-specific special-case in DefaultLLM.check_llm validation logic. Changes
Sequence Diagram(s)(Skipped — changes are documentation and a small validation logic edit; no new multi-component control flow requiring a sequence diagram.) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
✅ Docker images ready for
Use these tags to pull the images for testing. 📋 Copy commandsgcloud auth configure-docker us-central1-docker.pkg.dev
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:615589d2
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:615589d2 me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:615589d2
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:615589d2
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:615589d2
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:615589d2 me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:615589d2
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:615589d2Patch Helm values in one line (choose the chart you use): HolmesGPT chart: helm upgrade --install holmesgpt ./helm/holmes \
--set registry=me-west1-docker.pkg.dev/robusta-development/development \
--set image=holmes-dev:615589d2 \
--set operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set operator.image=holmes-operator-dev:615589d2Robusta wrapper chart: helm upgrade --install robusta robusta/robusta \
--reuse-values \
--set holmes.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.image=holmes-dev:615589d2 \
--set holmes.operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.operator.image=holmes-operator-dev:615589d2 |
✅ Deploy Preview for holmes-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@claude review |
🔬 CLI Performance Benchmark🟡 Startup Time (no LLM)Measures
🟡 Full CLI with LLMMeasures
PR: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/ai-providers/azure-ai-foundry.md`:
- Line 106: Several fenced code blocks in the markdown are missing a language
label and use inconsistent fencing; locate the code blocks that contain the
snippet
"Microsoft.CognitiveServices/accounts/OpenAI/deployments/chat/completions/action"
and the other flagged blocks and normalize them to the repo style by replacing
the opening fence with a language-labeled fence (e.g., ```text) and ensuring
matching closing fences (```), so update the blocks around the occurrences of
that snippet and the other flagged snippets to use consistent triple-backtick
fences with explicit language labels.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f7bde25d-8f16-4c35-839f-63ee9fc2ec57
📒 Files selected for processing (16)
CONTRIBUTING.mddocs/ai-providers/.nav.ymldocs/ai-providers/azure-ai-foundry.mddocs/ai-providers/azure-openai.mddocs/ai-providers/index.mddocs/ai-providers/using-multiple-providers.mddocs/development/evaluations/running-evals.mddocs/installation/cli-installation.mddocs/installation/kubernetes-installation.mddocs/reference/environment-variables.mdholmes/common/env_vars.pyholmes/core/azure_token.pyholmes/core/llm.pymkdocs.ymlrun_benchmarks_local.pytests/llm/utils/classifiers.py
… dead code Address two review comments on PR #1922: 1. The redirect stub azure-openai.md had an HTML comment before the YAML frontmatter delimiters, preventing MkDocs from parsing the title and hide directives. Move frontmatter to the top of the file. 2. Remove unreachable dead code in llm.py: the `if provider == "azure"` block inside the `else` branch could never execute because the `elif provider == "azure"` branch above already handles all Azure models. Signed-off-by: Claude <noreply@anthropic.com>
….0.0.1:27164/git/HolmesGPT/holmesgpt into claude/rename-azure-openai-foundry-TVcRs
There was a problem hiding this comment.
🧹 Nitpick comments (1)
holmes/core/llm.py (1)
87-87: Nit: grammar in renamed comment.The phrase "LLM configurations used services like Azure AI Foundry" reads awkwardly — it appears a word is missing. Consider rewording while you're touching this line.
✏️ Proposed fix
- # LLM configurations used services like Azure AI Foundry + # LLM configuration fields used by services like Azure AI Foundry🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@holmes/core/llm.py` at line 87, Fix the awkward comment above the LLM configuration block by rewording it to read clearly; replace "LLM configurations used services like Azure AI Foundry" with a concise phrase such as "LLM configurations for services like Azure AI Foundry" or "LLM configuration for services (e.g., Azure AI Foundry)"; update the comment located in holmes/core/llm.py near the LLM configuration section so it reads grammatically correct.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@holmes/core/llm.py`:
- Line 87: Fix the awkward comment above the LLM configuration block by
rewording it to read clearly; replace "LLM configurations used services like
Azure AI Foundry" with a concise phrase such as "LLM configurations for services
like Azure AI Foundry" or "LLM configuration for services (e.g., Azure AI
Foundry)"; update the comment located in holmes/core/llm.py near the LLM
configuration section so it reads grammatically correct.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 939d0299-6763-4b9e-983d-9a6f33d50eed
📒 Files selected for processing (2)
docs/ai-providers/azure-openai.mdholmes/core/llm.py
Signed-off-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM — both previously flagged issues (frontmatter ordering in redirect stub and dead code in llm.py) were addressed in commit 3d91175.
Extended reasoning...
Overview
Pure rebranding rename across 16 files: docs, nav config, code comments, log messages, and error strings. No logic, API, or environment variable changes.
Security risks
None. No authentication, authorization, or data-handling code was modified. Environment variable names remain unchanged.
Level of scrutiny
Low. The changes are mechanical text substitutions. The new azure-ai-foundry.md is a copy of the old azure-openai.md with updated terminology, and azure-openai.md is now a correctly-structured redirect stub (frontmatter first, then HTML comment, then meta-refresh). The llm.py diff removes a now-redundant AZURE_API_VERSION workaround that was replaced by a more general approach that strips already-set keys from missing_keys.
Other factors
All 11 regression evals pass. Bug hunting found no issues. Both concerns from my prior review were resolved.
fix asure model config Signed-off-by: Arik Alon <alon.arik@gmail.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/reference/troubleshooting.md (1)
21-38:⚠️ Potential issue | 🟡 MinorFix section numbering drift after RBAC section removal.
After renumbering Unclear Prompts to
## 3, the next heading should be## 4. Model Issues(it’s currently## 5), so the document remains sequential.Suggested patch
-## 5. Model Issues +## 4. Model Issues🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/reference/troubleshooting.md` around lines 21 - 38, The heading numbering is off after renaming "Unclear Prompts" to "## 3"; update the subsequent section header "## 5. Model Issues" to "## 4. Model Issues" so headings remain sequential; locate the "Model Issues" heading in the document and change its level number from 5 to 4.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@docs/reference/troubleshooting.md`:
- Around line 21-38: The heading numbering is off after renaming "Unclear
Prompts" to "## 3"; update the subsequent section header "## 5. Model Issues" to
"## 4. Model Issues" so headings remain sequential; locate the "Model Issues"
heading in the document and change its level number from 5 to 4.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 135c6a7d-6e54-44ed-bae9-b2b3dd63f6e6
📒 Files selected for processing (4)
docs/ai-providers/azure-ai-foundry.mddocs/ai-providers/index.mddocs/ai-providers/openai-compatible.mddocs/reference/troubleshooting.md
✅ Files skipped from review due to trivial changes (3)
- docs/ai-providers/openai-compatible.md
- docs/ai-providers/index.md
- docs/ai-providers/azure-ai-foundry.md
| model_requirements = litellm.validate_environment( | ||
| model=model, api_key=api_key, api_base=api_base | ||
| ) | ||
| # validate_environment does not accept api_version, and as a special case for Azure OpenAI Service, | ||
| # when all the other AZURE environments are set expect AZURE_API_VERSION, validate_environment complains | ||
| # the missing of it even after the api_version is set. | ||
| # TODO: There's an open PR in litellm to accept api_version in validate_environment, we can leverage this | ||
| # change if accepted to ignore the following check. | ||
| # https://github.com/BerriAI/litellm/pull/13808 | ||
| if ( | ||
| provider == "azure" | ||
| and ["AZURE_API_VERSION"] == model_requirements["missing_keys"] | ||
| and api_version is not None | ||
| ): | ||
| model_requirements["missing_keys"] = [] | ||
| model_requirements["keys_in_environment"] = True | ||
|
|
||
| if not model_requirements["keys_in_environment"]: | ||
| raise Exception( |
There was a problem hiding this comment.
🔴 The new azure-ai-foundry.md docs show AZURE_AD_TOKEN_AUTH=true working with anthropic/claude-opus-4-7 (labeled 'recommended'), but the code does not support this workflow. Two code paths fail: (1) check_llm() only skips AZURE_API_KEY validation inside the elif provider=="azure" branch — for anthropic/ models, litellm returns provider="anthropic", so the else branch calls validate_environment without AZURE_AD_TOKEN_AUTH awareness, raising a startup error requiring ANTHROPIC_API_KEY; (2) completion() only injects the azure_ad_token when litellm_model_name.startswith("azure/"), so Anthropic prefix models never receive the Entra ID token. The documented Entra ID workflow with Anthropic models on Azure AI Foundry is completely non-functional.
Extended reasoning...
What the bug is and how it manifests
The PR adds docs/ai-providers/azure-ai-foundry.md documenting two distinct use-cases for AZURE_AD_TOKEN_AUTH=true: (a) traditional azure/ models, and (b) anthropic/claude-opus-4-7 models accessed via the Azure AI Foundry Anthropic endpoint (https://XXXX.services.ai.azure.com/anthropic). The Anthropic option is labeled "recommended." However, the code only implements AZURE_AD_TOKEN_AUTH support for the azure/ prefix model format in both the startup validation path and the request execution path.
The specific code paths that fail
Failure 1 — startup validation in check_llm() (holmes/core/llm.py): The provider detection via litellm.get_llm_provider("anthropic/claude-opus-4-7") returns provider="anthropic", not "azure". The AZURE_AD_TOKEN_AUTH-aware code that removes AZURE_API_KEY from missing_keys lives exclusively inside the elif provider == "azure" branch. When provider="anthropic", execution falls to the else branch which calls litellm.validate_environment(model=model, api_key=api_key, api_base=api_base) with no AZURE_AD_TOKEN_AUTH awareness. With api_key=None and no ANTHROPIC_API_KEY set in the environment, validate_environment reports ANTHROPIC_API_KEY as a missing key, and check_llm raises an exception immediately at startup.
Failure 2 — token injection in completion() (holmes/core/llm.py): The azure_ad_token injection guard is: if AZURE_AD_TOKEN_AUTH and litellm_model_name.startswith("azure/"). For model="anthropic/claude-opus-4-7", the name starts with "anthropic/", so the condition is False, azure_ad_kwargs stays empty, and no azure_ad_token is passed to litellm. Even if startup validation somehow passed, actual API calls would go unauthenticated to the Foundry endpoint.
Why existing code does not prevent it
The AZURE_AD_TOKEN_AUTH feature was implemented only for azure/ prefix models. The new azure-ai-foundry.md docs introduce a new use-case — Anthropic models hosted on Azure AI Foundry — that requires the same Entra ID token flow but uses a different litellm provider string. The code was never extended to cover this case.
Impact
Users who follow the documented Entra ID workflow for Anthropic models on Azure AI Foundry will see a startup failure: "model anthropic/claude-opus-4-7 requires the following environment variables: ['ANTHROPIC_API_KEY']". This is a misleading error — the user is intentionally not providing an Anthropic API key, as the docs explicitly say "No AZURE_API_KEY is needed" and the Workload Identity examples show no api_key in the modelList entries. The entire documented feature is non-functional.
Step-by-step proof
- User sets: AZURE_AD_TOKEN_AUTH=true, AZURE_API_BASE=https://XXXX.services.ai.azure.com/anthropic, and runs: holmes ask ... --model="anthropic/claude-opus-4-7"
- DefaultLLM.init calls check_llm("anthropic/claude-opus-4-7", api_key=None, ...)
- litellm.get_llm_provider("anthropic/claude-opus-4-7") returns provider="anthropic"
- Code enters else branch: model_requirements = litellm.validate_environment(model="anthropic/claude-opus-4-7", api_key=None, api_base=api_base)
- validate_environment finds no ANTHROPIC_API_KEY in environment, returns {"missing_keys": ["ANTHROPIC_API_KEY"], "keys_in_environment": False}
- check_llm raises: Exception("model anthropic/claude-opus-4-7 requires the following environment variables: ['ANTHROPIC_API_KEY']")
- HolmesGPT fails to start. No request is ever made.
How to fix
Extend both code paths to also handle AZURE_AD_TOKEN_AUTH when the provider is "anthropic" but an Azure AI Foundry endpoint (api_base containing "ai.azure.com" or "azure") is configured. In check_llm, add a condition that skips ANTHROPIC_API_KEY validation when AZURE_AD_TOKEN_AUTH=True and the api_base suggests an Azure endpoint. In completion(), change the guard from startswith("azure/") to also trigger for anthropic/ models when AZURE_AD_TOKEN_AUTH is enabled.
|
|
||
| See [OpenAI Configuration](../ai-providers/openai.md) for more details. | ||
|
|
||
| === "Azure OpenAI" | ||
| === "Azure AI Foundry" | ||
|
|
||
| 1. **Set up API key**: | ||
| ```bash |
There was a problem hiding this comment.
🟡 The 'Azure AI Foundry' quick-start tab in cli-installation.md still shows the legacy openai.azure.com endpoint and the outdated 2024-02-15-preview API version, even though the tab label was renamed from 'Azure OpenAI'. The new azure-ai-foundry.md guide (linked via 'See Azure AI Foundry Configuration') uses cognitiveservices.azure.com and 2025-04-01-preview, creating a direct contradiction that will confuse new Azure AI Foundry users.
Extended reasoning...
What the bug is and how it manifests
The PR renames the quick-start tab from '=== "Azure OpenAI"' to '=== "Azure AI Foundry"' in cli-installation.md (and similarly in kubernetes-installation.md), but leaves the example configuration inside unchanged. Specifically, the updated cli-installation.md still exports:
export AZURE_API_VERSION="2024-02-15-preview"
export AZURE_API_BASE="https://your-resource.openai.azure.com"
The specific code path that triggers it
A user reading the quick-start guide follows the 'Azure AI Foundry' tab, copies the example configuration, and uses the legacy openai.azure.com endpoint with the 2024-02-15-preview API version. They are then directed to 'See Azure AI Foundry Configuration' (azure-ai-foundry.md), which shows entirely different endpoint patterns: https://XXXX.services.ai.azure.com/anthropic for Anthropic models and https://YYYY.cognitiveservices.azure.com/ with api_version: 2025-04-01-preview for Azure OpenAI-style deployments.
Why existing code does not prevent it
This is an incomplete rebrand: the PR updated the tab label and the 'see more' link, but did not update the inline example configuration to match the new authoritative guide. The old endpoint domain (openai.azure.com) and old API version (2024-02-15-preview) are only valid for the legacy Azure OpenAI Service pattern, which is exactly what the PR is deprecating from a documentation perspective.
What the impact would be
New Azure AI Foundry users (who have cognitiveservices.azure.com or services.ai.azure.com resources) will copy a configuration that does not work for their resource type. Users who already have legacy Azure OpenAI resources (openai.azure.com) will not notice a functional problem, but will be confused when the detailed guide they are directed to shows completely different endpoints. This creates an inconsistent onboarding experience for the renamed service.
How to fix it
Update the quick-start example in cli-installation.md (and kubernetes-installation.md) to match the authoritative azure-ai-foundry.md guide. The simplest fix is to show the Anthropic model path as the recommended option (matching the 'recommended' callout in azure-ai-foundry.md), with a note that Azure OpenAI-style deployments use a different endpoint and API version (2025-04-01-preview, cognitiveservices.azure.com).
Step-by-step proof
- User opens cli-installation.md and clicks the 'Azure AI Foundry' quick-start tab.
- They see: export AZURE_API_VERSION="2024-02-15-preview" and export AZURE_API_BASE="https://your-resource.openai.azure.com".
- They follow the 'See Azure AI Foundry Configuration' link to azure-ai-foundry.md.
- The new guide recommends https://XXXX.services.ai.azure.com/anthropic (no API version needed) or https://YYYY.cognitiveservices.azure.com/ with api_version: 2025-04-01-preview -- neither matches the quick-start.
- The user is left with contradictory instructions between the quick-start tab and the detailed guide it explicitly links to.
| @@ -18,26 +18,7 @@ HolmesGPT can't access logs, metrics, or traces from your observability stack. | |||
| - Verify toolset configuration connects to Prometheus/Grafana/logs | |||
There was a problem hiding this comment.
🟡 The troubleshooting doc now has sections numbered 1, 2, 3, 5 — skipping 4. When removing the old '## 3. RBAC Permissions' section and renumbering '## 4. Unclear Prompts' to '## 3. Unclear Prompts', the subsequent '## 5. Model Issues' was not renumbered to '## 4. Model Issues'. Fix by updating the heading to '## 4. Model Issues'.
Extended reasoning...
What the bug is and how it manifests
The PR removes the old '## 3. RBAC Permissions' section from docs/reference/troubleshooting.md and correctly renumbers old '## 4. Unclear Prompts' to '## 3. Unclear Prompts'. However, the final section '## 5. Model Issues' was left unchanged, resulting in a document with sections numbered 1, 2, 3, 5 — a visible gap at position 4.
The specific code path that triggers it
The renumbering was performed on the section heading at the deletion site (changing 4→3) but not propagated to the next downstream heading. The diff shows:
- removed
- → (correctly renumbered)
- — unchanged (should have become )
Why existing code doesn't prevent it
There is no automated enforcement of sequential section numbers in Markdown documents. The author manually renumbered one heading but missed the next one.
What the impact would be
Readers navigating the troubleshooting guide will see the sequence 1→2→3→5 and either assume content is missing between 3 and 5 or lose confidence in the document's accuracy. It's a minor cosmetic issue but degrades documentation quality.
How to fix it
Change to in docs/reference/troubleshooting.md.
Step-by-step proof
- Before PR: sections were 1 (Truncation), 2 (Missing Data Access), 3 (RBAC Permissions), 4 (Unclear Prompts), 5 (Model Issues).
- PR removes section 3 and renumbers 4→3: now 1, 2, 3 (Unclear Prompts), 5 (Model Issues).
- Section 5 was not decremented to 4, leaving the gap.
- The file as merged contains the heading at what is now logically the 4th section.
3 participants
This PR updates all references to "Azure OpenAI Service" to "Azure AI Foundry" across the codebase and documentation, reflecting Microsoft's rebranding of the service.
Summary
Azure OpenAI Service has been rebranded to Azure AI Foundry. This change updates all user-facing documentation, configuration examples, and internal references to use the new name while maintaining full backward compatibility with existing configurations.
Key Changes
Documentation:
docs/ai-providers/azure-openai.mdtodocs/ai-providers/azure-ai-foundry.mdazure-openai.mdto a redirect stub to preserve external linksCode Updates:
holmes/core/llm.py,holmes/core/azure_token.py, andholmes/common/env_vars.pyto reference "Azure AI Foundry"tests/llm/utils/classifiers.pyConfiguration & Setup:
Navigation & Metadata:
docs/ai-providers/.nav.ymlandmkdocs.ymlto point to new documentation filedocs/ai-providers/index.mdto reference Azure AI FoundryImplementation Details
azure-openai.mdfile is preserved as a redirect page using HTML meta refresh to avoid breaking external linksAZURE_API_KEY,AZURE_API_BASE, etc.) remain unchanged for backward compatibilityhttps://claude.ai/code/session_014a8UZvSnBVz9cbFizEL9De
Summary by CodeRabbit
Documentation
Bug Fixes