Azure is BYOK only. Pullfrog never proxies this traffic.
Setup
Pick Azure OpenAI in the model dropdown, then supply five values. Like Bedrock and Vertex it has no per-model variants — the model is whatever your deployment serves. Either store all five in the console: Model usage on the Billing card, then Azure OpenAI → Set up. Pullfrog injects them at run time and you never touchpullfrog.yml.
Or put AZURE_API_KEY in a GitHub Actions secret and the rest in your workflow env::
All five are required, and the two limits must parse as positive numbers —
128k is rejected. Values in your workflow env: win over Pullfrog-stored ones.
One optional sixth:
Responses API, and when to switch
Requests go to your resource’s Responses endpoint (/openai/v1/responses), which is what current Azure models speak. Deploy a GPT-5-family model (gpt-5-nano, gpt-5-mini, gpt-5) and it works as-is.
Older deployments — gpt-4, gpt-35-turbo — only speak Chat Completions and answer a Responses request with an error. Set AZURE_USE_CHAT_COMPLETIONS: "true" for those.
The deployment name is not the model name
Azure routes on the deployment name.AZURE_DEPLOYMENT is the name given to the deployment in the portal, which defaults to the model’s name but is often changed:
- Deployed
gpt-5, kept the default name →AZURE_DEPLOYMENT: gpt-5 - Named it
prod-reasoning→AZURE_DEPLOYMENT: prod-reasoning
404 at the first request.
Why the token limits are required
A deployment name tells Pullfrog nothing about the model behind it, so there is no catalog entry to read limits from. Undeclared, they break two things at once:- Completions get capped at 32000 tokens, which any model with a smaller cap rejects outright.
- Auto-compaction switches off. Compaction keys off the context limit, so a long session grows until Azure refuses it on context length.
AZURE_CONTEXT to the real window of whichever model your deployment serves. Understating it compacts earlier than necessary; overstating it defers compaction until Azure refuses the request.
Reasoning effort
The effort setting doesn’t apply to Azure runs. Effort levels belong to a specific model, and a deployment name doesn’t identify one — guessing wrong makes the run hang rather than fall back, so Pullfrog sends nothing and the model’s own default applies.Which models you can use
Whichever OpenAI models your Azure OpenAI resource has deployed — the GPT family, the reasoning models, and so on. Pullfrog sends the request to your deployment and doesn’t constrain which of them is behind it. Non-OpenAI models on Azure — Anthropic, DeepSeek, Llama, Mistral, Phi — are Foundry Models, served from a Foundry resource at a different endpoint rather than fromhttps://<name>.openai.azure.com. This integration can’t reach them. Point OpenAI-compatible endpoints at your Foundry inference URL instead.
Troubleshooting
404 from Azure
AZURE_RESOURCE_NAME doesn’t match your endpoint hostname, or AZURE_DEPLOYMENT isn’t a deployment on that resource. Check the deployment name in the portal — the deployment’s name, not the model’s. A Foundry model is also a 404 here; see above.
A Responses-API error, or Unrecognized request argument
The deployment serves a model that predates the Responses API. Set AZURE_USE_CHAT_COMPLETIONS: "true".
401 from Azure
The key doesn’t belong to that resource. Keys are per-resource.
The run says configuration is missing
The error names the values it couldn’t find. Check they’re stored in the console or mapped into your workflow env: — Actions only injects what the workflow file lists.