feat(core): discover Azure deployments - #50053

Issue for this PR

Closes #

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Azure only serves a model through a deployment, but OpenCode showed the whole Azure catalog (89 models) and sent the catalog ID as the deployment name. This PR lists the resource's deployments and shows those instead.

What it fixes

Startup

Startup does no network calls and never runs az. The plugin reads the stored credential and serves the full catalog; discovery runs in a background fiber and narrows the list when it answers. On v2, loading the plugin resolved the connection, so an expired Azure CLI token was refreshed through az before startup could continue.

Measured against a real AIServices resource, with the real az and the real 89-model catalog, both sides on the same v2 commit. "Ready" is the time until the plugin has loaded, which startup waits for. The deployment times come from one fresh process per run, in shuffled order, so every run starts with cold connections like a real startup; medians of 6 runs:

The two Azure Resource Manager requests vary by a few hundred milliseconds between runs, which hides most of the extra refresh in the medians; the az calls themselves stay at 167–176 ms.

gantt
  title Azure CLI with an expired token (one run)
  dateFormat x
  axisFormat %S.%L s
  section v2
  az token refresh, startup waits        :crit, 0, 197
  section This PR
  plugin loads, catalog shown            :done, 0, 5
  az token refresh                       :5, 177
  az management token                    :178, 347
  Resource Graph                         :347, 966
  deployment list, then the list narrows :970, 1488

az answered from its own token cache here. When that cache has expired too, az refreshes over the network, and on v2 startup waits for all of it, up to the 10 s command timeout. With this PR that time only delays the background list. If discovery fails, or settings.baseURL is custom, the full catalog stays. Tests assert that no request and no az call happen before the plugin finishes loading.

There is no polling. Discovery runs at startup, after connecting, and after switching accounts, so a deployment added later appears after a restart or reconnect.

How it works

flowchart TD
  T["startup · connect · account switch"] --> RB["rebind (local, no network)<br/>read the active connection and its resource<br/>tie the provider to that connection"]
  RB --> D{"credential"}
  D -- "Azure CLI" --> RG["Resource Graph: resource ID<br/>(cached per resource)"]
  RG --> MG["management API: every deployment page<br/>(nextLink must stay on management.azure.com)"]
  MG -- "fails" --> LEG
  D -- "API key" --> LEG["resource's own list<br/>/openai/deployments?api-version=2022-12-01"]
  MG -- "ok" --> P
  LEG -- "ok" --> P{"still the active connection?"}
  LEG -- "fails" --> KEEP["log a warning, keep the last list<br/>(or the catalog)"]
  P -- "yes" --> PUB["show the deployed models"]
  P -- "no" --> DROP["discard"]

The management API is Azure's documented deployment list, but Azure Resource Manager only accepts Entra tokens. API keys therefore use the data-plane list, which only exists in 2022-12-01; later versions dropped /deployments, and /openai/v1/models lists models the resource can deploy rather than its deployments. Links to the Azure docs are next to each caveat in the code.

Switching accounts

sequenceDiagram
  participant U as User
  participant P as Azure plugin
  participant A as discovery (account A)
  participant B as discovery (account B)
  Note over A: still waiting on Azure
  U->>P: switch to account B
  P->>P: rebind locally, reload the provider
  Note over P: Azure is back immediately with<br/>the full catalog for B
  P--xA: interrupt
  P->>B: start
  B->>P: B's deployments

The previous account's list is never shown for the new one. The interrupted discovery cannot publish, and every discovery checks that its connection is still active before publishing.

Deployments to models

The ID is the deployment name in lowercase; Azure compares names without case, and requests send the name exactly as Azure returned it. Limits, costs, and capabilities come from the catalog model the deployment deploys, or, when Azure spells it differently (gpt-4 for GPT-4 Turbo, gpt-35-turbo), from the catalog model the deployment is named after.

Models configured explicitly are always kept.

Compatibility

• Stored credentials keep their format, so connections need no migration or reconnect.
• A session stores azure/<id>. Any deployment named after a catalog ID keeps that ID, so every session that worked before keeps working; only models without any deployment disappear, and those already failed with a 404.
• The resource name saved with the connection now wins over settings.resourceName in config. This only matters if config was changed to another resource after connecting; reconnecting picks it up.

How did you verify your code works?

• bun test test/plugin/provider-azure.test.ts in packages/core: 29 tests against a local Bun.serve fake of Azure, repeated to check the switch timing. bun run check passes.
• Against a real AIServices resource with gpt-5-mini and DeepSeek-V4-Flash deployed:
  • The legacy list with an API key returns both, including the non-OpenAI deployment.
  • The real plugin narrowed the 89-model catalog to exactly those two, with an API key and with the Azure CLI through the management API.
  • Azure accepted DeepSeek-V4-Flash, deepseek-v4-flash, and DEEPSEEK-V4-FLASH as the deployment name.
• Not covered live: an Azure CLI identity without management read access (the legacy fallback), several resources or tenants, and deployments whose Azure model name differs from the catalog.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR