Choosing the runner AI provider

A CloudRadial AutomationAI runner calls an AI provider for its AI activities, including the AI Playground and every Agent node, so nothing AI-driven on the runner works until a provider is set. AI Generate is separate: it runs on CloudRadial's Azure AI Foundry model and counts toward your workspace's Usage Credits. By default the runner's provider is the bundled private Azure AI Foundry, but you can point it at four other providers instead. This article explains the options, the settings each one needs, and how to switch an existing runner without redeploying it. It is for the technician operating a runner.

In this article:

• The five providers
• Foundry, the default
• The AI-provider Key Vault secrets
• Switching an existing runner
• The default model and requested models
• Egress and endpoint overrides

The Five Providers

Set the ai-provider secret to one of these values:

The two Foundry options keep AI traffic inside your own Azure environment and store no key at all, because the runner authenticates as itself. The three key-based providers call the vendor over the public internet.

A new runner deployed from the Azure Marketplace can select any of these providers in the wizard's AI provider tab. The steps below cover switching a runner that is already deployed.

Foundry, the Default

By default the runners call the bundled private Azure AI Foundry account, authenticated by the runner’s managed identity. The Foundry account is reachable only through a private endpoint, so all AI traffic stays inside the runner’s virtual network with no internet egress, and there is no API key to manage. This is the recommended posture for most installs. On foundry, the runner’s default model is the model deployment set up when the runner was installed.

foundry-claude works the same way, with the same private networking and managed-identity sign-in, and differs only in the model family it targets. Use it when you want Claude models but do not want AI traffic leaving your Azure environment.

The AI-Provider Key Vault Secrets

All of the AI-provider configuration lives as plain secrets in the shared runner Key Vault. Each key-based provider has its own set of secrets and never reuses another provider’s endpoint or credentials:

An -endpoint secret is optional for these three providers. Leave it empty and the runner uses the vendor’s documented default; set it to route through your own gateway or proxy instead. The openai provider uses OpenAI’s Responses API, so a gateway or proxy set in openai-endpoint must support the Responses API; one that serves only the older chat completions API returns an error. For a gateway that serves only chat completions, use openrouter instead. To edit these secrets you need the Key Vault Secrets Officer role on the vault and network access to its private endpoint. Because the vault is private, the installer can offer to allow your machine’s IP on the vault firewall at the end of a deploy; otherwise edit the secrets from a host on the runner virtual network or a peered network.

Switching an Existing Runner

Use these steps to move an already-deployed runner from one provider to another without redeploying it.

1. Seed the new provider’s key and model secrets first, so the runner never selects a provider it has no credentials for. For foundry-claude, always seed foundry-claude-endpoint, because it has no default. On managed identity, leave foundry-claude-api-key out: without that secret the runner uses its managed identity. If the runner already has a foundry-claude-api-key you are removing, restart the runner’s Function Apps afterward so every instance stops using it.
2. Set the ai-provider secret to the new value.
3. Once the runner works with the new provider, delete the previous provider’s API key secret from the Key Vault and revoke that key with the vendor.

The runner reads ai-provider from Key Vault on every AI call, so the switch takes effect on the next AI call with no restart. The key, model, and endpoint secrets are read when a call first needs them, and each running instance keeps a value it has already read. To change the key, model, or endpoint of the provider the runner is already using, for example to rotate an API key, update the secret and then restart the runner’s Function Apps. No redeploy is needed, and the runner’s identity, secret, and networking are untouched. This behavior requires runner version 1.7.2 or later. The runner’s README.md includes the exact PowerShell commands for setting each secret and restarting the apps.

The Default Model and Requested Models

The model secret for the active provider (for example openai-model), or the installed model deployment on foundry, is the runner’s default model. Agents, Agent nodes, and AI Prompt nodes can leave their model blank, which is the default, or name a model:

• A blank model uses the runner’s default model
• A named model is a request. The runner tries it on its own provider, and if the provider reports that the model does not exist, the runner falls back to its default model once and continues. Any other error is handled as usual and does not switch models.

A node cannot choose the provider; it always runs on the provider set in ai-provider. Model IDs differ by provider, for example gpt-5.4 on OpenAI, openai/gpt-5.4 on OpenRouter, claude-sonnet-5 on Anthropic, or a deployment name on Foundry, so a node that names a model can fall back after you switch providers. Each run records the model that actually answered and shows a notice when the runner fell back, so check a run’s detail after a switch. Keeping the default model secret current matters, because it is what every blank-model node and every fallback uses.

This behavior requires runner version 2.2.0 or later. Each agent model request waits up to 300 seconds, cut to the time left before the run’s deadline, so slower reasoning models can finish a turn; this applies to every provider from runner version 2.4.1. On the openai provider, runner version 2.4.1 and later use OpenAI’s Responses API, which lets newer reasoning models such as the gpt-6 family use extension tools. A self-updating runner picks up the current version automatically; see Upgrading a runner to a new version.

Egress and Endpoint Overrides

Important -> If your runner egress is locked down, allow the provider’s host before you switch, or the runners will fail to reach it: api.openai.com for OpenAI, api.anthropic.com for Anthropic, openrouter.ai for OpenRouter. If you set an -endpoint override, allow that host instead. See Runner network and egress requirements.

If a runner cannot read its endpoint override at the moment it needs it, it fails the call rather than falling back to the vendor’s public endpoint, so a transient fault can never send your prompt somewhere you did not choose.

With the provider set, finish setting up the runner: confirm it is registered and reporting healthy on the Runners page. See Registering and managing runners. Once it is, install the extensions your workflows will use. Next: Browsing and installing extensions.

If you are still having trouble, we’re here to help! Submit a ticket here for assistance, and don’t forget to check our status page to ensure there are no outages in your area.