Share via

Claude Haiku 4.5 deployment fails (provisioningState=Failed) in Azure AI Foundry — Sonnet 4.6 and Opus 4.7 succeed in same account

Sophia 0 Reputation points
2026-04-27T06:16:38.7333333+00:00

Summary

I'm trying to deploy claude-haiku-4-5 to an Azure AI Foundry (AIServices) account, but the deployment consistently

ends in provisioningState: Failed. The same account successfully deploys claude-sonnet-4-6 and claude-opus-4-7,

so this is specific to the Haiku model.

Environment

  • Subscription ID: ce5a9cec-f5bb-4b38-8837-eeb95fefbf3f
  • Resource group: rg-Sophiadevcloud832-4299 (Sweden Central)
  • AIServices account: sophiadevcloud832-4299-resource
  • Failed deployment: 
    
    /subscriptions/ce5a9cec-f5bb-4b38-8837-eeb95fefbf3f/resourceGroups/rg-Sophiadevcloud832-4299/providers/Microsoft.Cog

nitiveServices/accounts/sophiadevcloud832-4299-resource/deployments/claude-haiku-4-5-1

```

What works

In the same AIServices account these two deployments succeed and run fine:

| Deployment name | Model | Version | State |

|----------------------|--------------------|----------|-----------|

| claude-sonnet-4-6-1 | claude-sonnet-4-6 | (latest) | Succeeded |

| claude-opus-4-7-1 | claude-opus-4-7 | (latest) | Succeeded |

So Anthropic ToS is clearly accepted at the subscription level, and the AIServices account itself is healthy.

What fails


  az cognitiveservices account deployment create \

    --resource-group rg-Sophiadevcloud832-4299 \

    --name sophiadevcloud832-4299-resource \

    --deployment-name claude-haiku-4-5-1 \

    --model-name claude-haiku-4-5 \

    --model-version 20251001 \

    --model-format Anthropic \

    --sku-name GlobalStandard \

    --sku-capacity 1

The CLI returns 200 with provisioningState: Creating, but a few seconds later show returns:


  {

    "name": "claude-haiku-4-5-1",

    "properties": {

      "model": {

        "format": "Anthropic",

        "name": "claude-haiku-4-5",

        "version": "20251001"

      },

      "provisioningState": "Failed",

      "raiPolicyName": "Microsoft.DefaultV2"

    },

    "sku": { "name": "GlobalStandard", "capacity": 1 }

  }

There is no error message anywhere in the deployment object — provisioningState flips to Failed silently.

Things I have already tried (dozens of attempts)

  1. Deleted and recreated the deployment with multiple different names (claude-haiku-4-5-1, haiku-v2, haiku-prod,

etc.) — all end in Failed.

  1. Created additional AIServices accounts in the same RG — Haiku still fails.
  2. Tried East US 2 region with a fresh resource group + fresh AIServices account — Haiku also fails there.
  3. Tried both the ai.azure.com portal Deploy button and the Azure CLI — same result either

way.

  1. Quota check shows it is not a quota issue: 
    
     Tokens Per Minute (thousands) - Claude Haiku 4.5   1 / 450

     Tokens Per Minute (thousands) - Claude Sonnet 4.6  225 / 450

     Tokens Per Minute (thousands) - Claude Opus 4.7    450 / 450
  2. Model catalog confirms availability: az cognitiveservices model list -l swedencentral returns claude-haiku-4-5

version 20251001 with SKU GlobalStandard.

Question

Could you please:

  1. Investigate why my subscription's claude-haiku-4-5 entitlement enters a Failed state, while claude-sonnet-4-6

and claude-opus-4-7 provision normally on the same subscription / account / region?

  1. Reset or repair whatever backend state is preventing Haiku deployments from completing.
  2. Retrieve the actual server-side error log for one of the failed deployments — none surface in the ARM API response.

Happy to provide additional correlation-request-id headers, ARM activity log entries, or screenshots from the portal

on request.

Thank you.

Foundry Models
Foundry Models

A catalog of AI models in Microsoft Foundry that you can discover, compare, and deploy using Azure’s built‑in tools for evaluation, fine‑tuning, and inference

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SRILAKSHMI C 18,390 Reputation points Microsoft External Staff Moderator
    2026-04-27T18:14:45.17+00:00

    Hello @Sophia

    Thank you for the detailed information and for the extensive troubleshooting you have already completed.

    Based on everything you’ve shared, this does not appear to be an issue with your Azure AI Foundry resource, subscription, quota, or Anthropic access. The fact that Claude Sonnet 4.6 and Claude Opus 4.7 deploy successfully in the same Azure AI Services account confirms that:

    • Your Azure AI Services resource is healthy
    • Anthropic marketplace terms have been accepted
    • Your subscription is properly entitled for Anthropic models
    • Regional access and quota are correctly configured
    • The deployment workflow is functioning for other Anthropic models

    This strongly suggests that the issue is isolated specifically to the Claude Haiku 4.5 provisioning pipeline.

    What the Current Behavior Indicates

    Your deployment request is successfully accepted by Azure Resource Manager and initially enters the Creating state. This confirms that:

    • The deployment command syntax is valid
    • The model name and version are recognized
    • The selected SKU (GlobalStandard) is supported
    • Regional validation succeeds
    • Quota checks pass

    The deployment then transitions to ProvisioningState = Failed without returning an explicit error message. This type of behavior typically indicates that the request passed initial validation but failed during the backend provisioning stage.

    Because this occurs:

    • Across multiple deployment names
    • Across newly created Azure AI Services resources
    • In multiple supported regions (Sweden Central and East US 2)
    • Through both Azure AI Foundry and Azure CLI

    the issue is very unlikely to be related to deployment syntax, client tooling, or resource configuration.

    Validation Steps

    Although your testing already rules out most common causes, you may wish to verify the following:

    Confirm that the Anthropic Marketplace offer is fully accepted for your subscription

    Ensure your subscription type supports Anthropic models (for example, Pay-As-You-Go or Enterprise)

    Verify your account has the necessary permissions:

    • Owner or Contributor on the resource group
    • Cognitive Services User on the Azure AI Services resource

    If using a service principal, confirm the token scope includes: https://ai.azure.com/.default

    You may also review:

    • Azure Service Health for any regional issues affecting Anthropic deployments
    • ARM Activity Logs for failed deployment events
    • Azure Monitor diagnostic logs, if enabled

    Given your successful Sonnet and Opus deployments, these checks are unlikely to reveal the root cause, but they may provide additional context.

    This pattern is generally consistent with a service-side issue specific to the Claude Haiku 4.5 model, such as:

    A temporary backend provisioning issue

    A model entitlement synchronization problem

    A deployment pipeline issue affecting this specific model version

    A regional or global service regression for the Haiku offering

    Since the issue reproduces across regions and newly created resources, it appears to be isolated to the Haiku deployment workflow itself rather than your environment.

    Please refer this

    Deploy & use Claude models in Foundry (preview): https://learn.microsoft.com/azure/foundry/foundry-models/how-to/use-foundry-models-claude

    Troubleshooting deployment issues in Azure AI Foundry / OpenAI Studio: https://learn.microsoft.com/azure/ai-foundry/openai/quotas-limits?tabs=REST#how-to-request-quota-increases

    I Hope this helps. Do let me know if you have any further queries.

    Thank you!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-04-27T06:16:54.52+00:00

    provisioningState: Failed for a single Claude model while other Claude deployments succeed is not directly explained in the provided material. However, the context does cover closely related deployment-failure patterns and the recommended mitigation steps.

    Based on that context, the only supported, actionable steps are:

    1. Confirm region and model availability
      • Claude models in Foundry are currently only available in East US 2 and Sweden Central.
      • The context explicitly notes that model availability can change and that the Foundry Models from partners page should be checked for the latest list of available Anthropic models.
      • Since claude-sonnet-4-6 and claude-opus-4-7 succeed in the same subscription and region, the subscription and Anthropic ToS acceptance are valid; this points to a model-specific backend or availability issue for claude-haiku-4-5.
    2. Retry the deployment after some time
      • For similar “deployment stuck / failed with poor error messaging” issues, the documented mitigation is to delete the failed deployment and recreate it later, which has resolved transient backend problems in other cases.
      • This aligns with the Q&A example where a failing Anthropic deployment started working after deleting and recreating the deployment a few hours later.
    3. Check for generic deployment and quota issues
      • Use the Foundry portal Operate → Quotas to confirm that quota is not exhausted for claude-haiku-4-5 (already done in this scenario, but this is the documented check).
      • For general deployment failures, the guidance is to use the standard Azure deployment troubleshooting flow (Activity Log, deployment details) as described for Foundry deployments. If the error is not surfaced in the deployment object, the backend issue is likely not diagnosable from the client side.
    4. When the problem persists, escalate to Microsoft Support
      • The Manufacturing data solutions troubleshooting guidance states that if deployment failures persist after retrying and basic checks, the next step is to contact Microsoft Support.
      • The same pattern applies here: a specific model (claude-haiku-4-5) failing while others succeed, with no surfaced error message, indicates a backend or entitlement issue that can only be investigated and fixed by the product group via a support case.
      • A support ticket allows the service team to:
        • Inspect internal logs and correlation IDs for the failed deployments.
        • Verify and, if necessary, repair subscription-level entitlements or backend configuration for claude-haiku-4-5.
        • Provide the actual server-side error details, which are not exposed through the ARM deployment object.

    Within the provided documentation, there is no direct mechanism to “reset or repair” Claude Haiku entitlements from the client side, and no documented way to retrieve internal server-side logs for these failures. Persistent, model-specific deployment failures with no surfaced error must be handled by Microsoft Support.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.