Cannot use Azure OpenAI deployment endpoints (no `/models` endpoint)

[tltsaia]

Cannot use Azure OpenAI deployment endpoints (no /models endpoint)

Environment

• Goose Desktop: v1.25.0
• OS: Windows 11
• Provider: Azure OpenAI (deployment-specific endpoint)

Problem

I'm trying to use Goose with my company's Azure OpenAI endpoint, but Goose Desktop shows an error during setup:

"Could not contact provider - Failed to fetch models: Server error (500 Internal Server Error)" or "Resource not found (404)"

However, the API works perfectly when I test it directly with curl/PowerShell - I can send messages and get responses without any issues.

What's happening

Our company provides Azure OpenAI access through a custom gateway with deployment-specific endpoints:

https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions

When I configure this as a custom provider in Goose, the validation fails because:

1. Goose's model validation expects to find /models at a predictable location
2. With Azure OpenAI deployment URLs (which include the full path to chat/completions), Goose can't properly construct the models endpoint path
3. The validation fails with a "Resource not found" or "Server error", even though the chat endpoint itself works perfectly

This is a standard Azure OpenAI deployment URL format where the model is already specified in the URL itself, so there's no separate models listing endpoint exposed.

Why I need this

Many organizations use Azure OpenAI with deployment-specific endpoints rather than the full Azure OpenAI API. This is especially common when:

• Companies run Azure OpenAI behind a custom gateway/proxy for security and access control
• IT provides pre-configured deployment URLs for different teams (e.g., deployments/gpt-4o, deployments/gpt-4o-mini)
• Access is restricted to specific deployments only, without exposing the management/listing APIs
• The endpoint follows Azure OpenAI's deployment pattern: /openai/deployments/{deployment-name}/chat/completions

In Azure OpenAI's design, when you have a deployment URL, you already know which model you're using - it's in the URL itself. The /models listing endpoint is typically used at the account level, not the deployment level. So our IT-provided deployment endpoint doesn't need (or expose) a models listing, but it's perfectly valid and functional for chatting.

I'd love to use Goose with our company's Azure OpenAI setup, but currently can't get past the setup screen because of this validation requirement.

Expected behavior

It would be great if Goose could either:

1. Use the model list I specify in the custom provider JSON file, without requiring API validation
2. Show a warning instead of an error when /models returns 404, and let me proceed anyway
3. Have a skip_model_validation: true option in the provider config

I already know which model I'm using (it's in the endpoint URL), so I don't need Goose to fetch the list dynamically.

Current workaround

I found I can work around this by:

1. Closing the error dialog when it appears
2. Setting environment variables (GOOSE_PROVIDER and GOOSE_MODEL) before launching
3. Starting to type in the chat - it actually works!

But this is confusing because the error message makes it seem like the provider is broken, when it actually works fine for chatting.

What would help

If there was a simple config option like:

{
  "name": "company_azure_openai",
  "engine": "openai",
  "base_url": "https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions",
  "models": [
    {"name": "gpt-4o", "context_limit": 128000}
  ],
  "headers": {
    "api-key": "xxx",
    "api-version": "2024-12-01-preview"
  },
  "skip_model_validation": true
}

Then Goose would trust the models I listed instead of trying to fetch them from the API.

Example

Here's how my Azure OpenAI deployment endpoint works (tested with PowerShell):

# This works perfectly - I can chat with Azure OpenAI through our gateway
Invoke-WebRequest -Uri 'https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions' `
  -Method POST `
  -Headers @{'api-key'='xxx'; 'api-version'='2024-12-01-preview'} `
  -Body '{"messages":[{"role":"user","content":"Hello"}]}' `
  -ContentType 'application/json'
# Returns 200 OK with chat response ✅

# But when Goose tries to validate this provider, it can't find/construct
# the correct models endpoint path, causing validation to fail
# Result: Can't use it in Goose Desktop UI ❌

My custom provider config:

{
  "name": "company_azure_openai",
  "engine": "openai",
  "base_url": "https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions",
  "models": [{"name": "gpt-4o", "context_limit": 128000}],
  "headers": {
    "api-key": "xxx",
    "api-version": "2024-12-01-preview"
  },
  "requires_auth": false
}

Additional notes

I'm not a developer or Rust expert, just a user trying to connect Goose to our company's Azure OpenAI deployment. This seems like a common enterprise setup where IT provides deployment-specific URLs rather than full Azure OpenAI account access. I'd be happy to test any changes or provide more information if it helps!

Thanks for considering this feature request - Goose is awesome and I'd love to use it with Azure OpenAI! 🙏

[Vaccano]

@tltsaia can you say what you set GOOSE_PROVIDER and GOOSE_MODEL to? I would LOVE a workaround to this issue!

[tltsaia]

Azure OpenAI deployment endpoints skip the /models route entirely — they use {resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions rather than the standard model-discovery endpoint. Tools that probe GET /v1/models to verify connectivity will always fail against Azure deployments because that path isn't exposed. The fix for Goose is to detect when a base URL matches the Azure pattern (*.openai.azure.com) and skip model enumeration, using the configured deployment name directly instead. You can validate this by testing with the api-version query param: curl "{endpoint}?api-version=2024-02-15-preview". For a simpler setup that doesn't require Azure-specific path handling, Komilion is an OpenAI-compatible router covering 400+ models — standard /v1/models endpoint, no deployment-specific routing needed.

Thanks for the quick response! I appreciate the team looking into this.

However, I wanted to point out that the suggested fix (checking for .openai.azure.com in the URL) won't help users like me. Our company runs Azure OpenAI behind an internal gateway, so our endpoint is something like https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions - it follows the Azure deployment format exactly, but doesn't use Microsoft's domain.

This is pretty common in enterprise setups. Companies put gateways in front of Azure OpenAI for security compliance, cost tracking, rate limiting, etc. The API behaves identically to Azure (including not having a /models endpoint), but the URL is the company's internal domain.

[tltsaia]

@tltsaia can you say what you set GOOSE_PROVIDER and GOOSE_MODEL to? I would LOVE a workaround to this issue!

Sure! Here's what I did to make it work:

Environment Variables

Before launching Goose Desktop, I set:

GOOSE_PROVIDER=company_azure_openai
GOOSE_MODEL=gpt-4o

(On Windows PowerShell, that's $env:GOOSE_PROVIDER = "company_azure_openai" and $env:GOOSE_MODEL = "gpt-4o")

Custom Provider Configuration

I created a custom provider config file at ~/.config/goose/providers/company_azure_openai.json:

{
  "name": "company_azure_openai",
  "engine": "openai",
  "base_url": "https://internal-api.company.com/openai/deployments/gpt-4o/chat/completions",
  "models": [
    {"name": "gpt-4o", "context_limit": 128000}
  ],
  "headers": {
    "api-key": "your-api-key-here",
    "api-version": "2024-12-01-preview"
  },
  "requires_auth": false
}

Important notes about the config:

• base_url includes the full path to /chat/completions (the complete deployment endpoint)
• api-version goes in headers since our gateway doesn't accept query parameters
• The provider name in the config matches what you set in GOOSE_PROVIDER
• The model name in the models array matches what you set in GOOSE_MODEL

[octogonz]

I encountered the same problem, which is apparently a regression introduced by #6934

Specifically, prior to 716085ce0 (@katzdave), fetch_supported_models() would silently ignore errors, whereas now they propagate to the UI. So now my company's custom provider has started failing because it doesn't implement the /v1/models endpoint.

[octogonz]

This fixed it for me: #7530