Two env vars make the OpenAI provider point at any compatible Responses API endpoint
geoffdavies-dt (Dovetail) added `OPENAI_BASE_URL` and `OPENAI_AUTH_HEADER` to the OpenAI provider so mike can talk to Azure OpenAI or any other Responses-compatible endpoint. About 20 lines of code, fully backwards-compatible.
backend/src/lib/llm/openai.ts previously had the OpenAI Responses URL hardcoded. This change replaces it with two small helpers: responsesUrl() reads OPENAI_BASE_URL, strips trailing slashes, and appends /responses; authHeaders() checks OPENAI_AUTH_HEADER and returns either Authorization: Bearer <key> or api-key: <key>. Both default to the existing OpenAI behavior when the env vars are absent.
The named use case is Azure OpenAI / Azure AI Foundry. Set OPENAI_BASE_URL=https://your-resource.cognitiveservices.azure.com/openai/v1 and OPENAI_AUTH_HEADER=api-key and the provider routes through Azure. The fork author notes that Azure deployment names need to match mike's model IDs (gpt-5.5, gpt-5.4-mini, gpt-5.4-nano) - they're aligning their Azure resource to mike's naming rather than adding a model-ID mapping layer, which keeps the patch minimal.
One caveat: this targets the Azure AI Foundry /openai/v1/responses endpoint, not the older deployments/{name}/completions?api-version=... shape. Anyone on an older Azure API version or using a Chat Completions-only proxy would need to adapt further.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?