[GH-ISSUE #15992] Claude Desktop Cowork 3P Gateway shows only Legacy Model; /v1/models returns 39 models but 0 usable #87869

Open
opened 2026-05-10 06:29:04 -05:00 by GiteaMirror · 15 comments
Owner

Originally created by @lowaszwillie on GitHub (May 6, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/15992

What is the issue?

Issue

Claude Desktop Cowork with Ollama Cloud Gateway starts in Cowork 3P · Gateway mode, but the model selector only shows Legacy Model.

When sending a message, Cowork fails because it tries to use claude-sonnet-4-6:

There's an issue with the selected model (claude-sonnet-4-6).
It may not exist or you may not have access to it.
Run --model to pick a different model.

### Relevant log output

```shell
[custom-3p] Credentials loaded from enterprise config { provider: 'gateway', mcpServerCount: 0 }
[custom-3p] 3P mode active { provider: 'gateway' }
[custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' }
[custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 }
[custom-3p] Model discovery: not supported by provider; picker = 0 (empty)

OS

Windows

GPU

Nvidia

CPU

Intel

Ollama version

0.23.1

Originally created by @lowaszwillie on GitHub (May 6, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/15992 ### What is the issue? ### Issue Claude Desktop Cowork with Ollama Cloud Gateway starts in `Cowork 3P · Gateway` mode, but the model selector only shows `Legacy Model`. When sending a message, Cowork fails because it tries to use `claude-sonnet-4-6`: ```text There's an issue with the selected model (claude-sonnet-4-6). It may not exist or you may not have access to it. Run --model to pick a different model. ### Relevant log output ```shell [custom-3p] Credentials loaded from enterprise config { provider: 'gateway', mcpServerCount: 0 } [custom-3p] 3P mode active { provider: 'gateway' } [custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' } [custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 } [custom-3p] Model discovery: not supported by provider; picker = 0 (empty) ``` ### OS Windows ### GPU Nvidia ### CPU Intel ### Ollama version 0.23.1
GiteaMirror added the bug label 2026-05-10 06:29:05 -05:00
Author
Owner

@lowaszwillie commented on GitHub (May 6, 2026):

Additional verification

The Ollama Gateway chat completion endpoint also works with the same API key.

PowerShell test:

$body = @{
  model = "kimi-k2.6"
  messages = @(
    @{ role = "user"; content = "Reply with exactly: OLLAMA_GATEWAY_OK" }
  )
} | ConvertTo-Json -Depth 10

Invoke-RestMethod -Uri "https://ollama.com/v1/chat/completions" `
  -Method Post `
  -Headers @{ Authorization = "Bearer $env:OLLAMA_API_KEY"; "Content-Type" = "application/json" } `
  -Body $body | ConvertTo-Json -Depth 10
<!-- gh-comment-id:4387729194 --> @lowaszwillie commented on GitHub (May 6, 2026): ### Additional verification The Ollama Gateway chat completion endpoint also works with the same API key. PowerShell test: ```powershell $body = @{ model = "kimi-k2.6" messages = @( @{ role = "user"; content = "Reply with exactly: OLLAMA_GATEWAY_OK" } ) } | ConvertTo-Json -Depth 10 Invoke-RestMethod -Uri "https://ollama.com/v1/chat/completions" ` -Method Post ` -Headers @{ Authorization = "Bearer $env:OLLAMA_API_KEY"; "Content-Type" = "application/json" } ` -Body $body | ConvertTo-Json -Depth 10
Author
Owner

@shayaansarfraz-crypto commented on GitHub (May 6, 2026):

Can confirm this on macOS as well.

Environment:

  • macOS (latest)
  • Ollama CLI with ollama launch claude-desktop
  • Valid Ollama Cloud API key with active subscription

Symptoms:

  • Claude Desktop Cowork shows empty model dropdown (only "Legacy Model" option)
  • Gateway mode appears active but no models populate

Additional findings:

  • ollama launch claude-desktop writes config pointing to non-existent npm package mcp-server-ollama (returns 404 on npm)
  • Manually changing to ollama-mcp package didn't resolve the issue
  • ollama launch claude (Claude Code CLI) works perfectly with same API key - all Ollama Cloud models visible and usable

This suggests the issue is specific to Claude Desktop's gateway integration, not the Ollama Cloud API or authentication. Claude Code's integration works fine, so there's a working reference implementation.

Would be great to see parity between Desktop and Code integrations!

<!-- gh-comment-id:4388093469 --> @shayaansarfraz-crypto commented on GitHub (May 6, 2026): Can confirm this on **macOS** as well. **Environment:** - macOS (latest) - Ollama CLI with `ollama launch claude-desktop` - Valid Ollama Cloud API key with active subscription **Symptoms:** - Claude Desktop Cowork shows empty model dropdown (only "Legacy Model" option) - Gateway mode appears active but no models populate **Additional findings:** - `ollama launch claude-desktop` writes config pointing to non-existent npm package `mcp-server-ollama` (returns 404 on npm) - Manually changing to `ollama-mcp` package didn't resolve the issue - `ollama launch claude` (Claude Code CLI) **works perfectly** with same API key - all Ollama Cloud models visible and usable This suggests the issue is specific to Claude Desktop's gateway integration, not the Ollama Cloud API or authentication. Claude Code's integration works fine, so there's a working reference implementation. Would be great to see parity between Desktop and Code integrations!
Author
Owner

@lowaszwillie commented on GitHub (May 6, 2026):

I can confirm the same issue on Windows.

Environment:

  • Windows 11
  • Ollama 0.23.1
  • Claude Desktop 1.6259.1
  • Valid Ollama Cloud API key with active subscription
  • Claude Desktop installed as MSIX / WindowsApps app

Symptoms:

  • Claude Desktop Cowork starts in Cowork 3P · Gateway mode
  • The model selector only shows Legacy Model
  • The dropdown opens only as a tiny empty panel/line, with no models listed
  • Sending a message fails because Cowork tries to use claude-sonnet-4-6

Relevant Claude Desktop log:

[custom-3p] Credentials loaded from enterprise config { provider: 'gateway', mcpServerCount: 0 }
[custom-3p] 3P mode active { provider: 'gateway' }
[custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' }
[custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 }
[custom-3p] Model discovery: not supported by provider; picker = 0 (empty)

Additional API checks:

The Ollama Cloud API itself works correctly with the same API key.

/v1/models returns 39 models, including:

kimi-k2.6
qwen3-coder:480b
glm-5.1
minimax-m2.7
nemotron-3-super
deepseek-v4-pro
gpt-oss:120b
devstral-2:123b

/v1/chat/completions also works.

/v1/messages also works directly with kimi-k2.6.

Example result:

OLLAMA_MESSAGES_OK

I also tested the route that Claude Desktop Cowork appears to fall back to:

model = "claude-sonnet-4-6"

Against the Ollama /v1/messages endpoint, Ollama returns:

404
model "claude-sonnet-4-6" not found

This suggests that Claude Desktop Cowork expects Claude/Anthropic-style model routes, while Ollama Cloud returns raw Ollama model IDs.

To verify this, I created a temporary local test proxy that exposes Claude-compatible model IDs and maps them internally to Ollama Cloud models, for example:

claude-sonnet-4-6 -> kimi-k2.6
claude-opus-4-6   -> qwen3-coder:480b
claude-haiku-4-6  -> minimax-m2.7

With this alias mapping, Claude Desktop Cowork works. The model selector shows multiple models, and messages are successfully sent through Cowork using Ollama Cloud models.

So this does not look like an API key, subscription, authentication, or Ollama Cloud inference issue.

It looks like the missing/broken part is the Claude Desktop Cowork Gateway model discovery / alias routing layer.

Claude Desktop seems to filter out the raw Ollama model IDs and ends up with:

rawCount: 39
usable models: 0

This matches the macOS report above and strongly suggests that the issue is specific to Claude Desktop’s Cowork/Gateway integration. The Claude Code integration working with the same API key is a useful reference point.

<!-- gh-comment-id:4388693612 --> @lowaszwillie commented on GitHub (May 6, 2026): I can confirm the same issue on Windows. Environment: * Windows 11 * Ollama 0.23.1 * Claude Desktop 1.6259.1 * Valid Ollama Cloud API key with active subscription * Claude Desktop installed as MSIX / WindowsApps app Symptoms: * Claude Desktop Cowork starts in `Cowork 3P · Gateway` mode * The model selector only shows `Legacy Model` * The dropdown opens only as a tiny empty panel/line, with no models listed * Sending a message fails because Cowork tries to use `claude-sonnet-4-6` Relevant Claude Desktop log: ```text [custom-3p] Credentials loaded from enterprise config { provider: 'gateway', mcpServerCount: 0 } [custom-3p] 3P mode active { provider: 'gateway' } [custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' } [custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 } [custom-3p] Model discovery: not supported by provider; picker = 0 (empty) ``` Additional API checks: The Ollama Cloud API itself works correctly with the same API key. `/v1/models` returns 39 models, including: ```text kimi-k2.6 qwen3-coder:480b glm-5.1 minimax-m2.7 nemotron-3-super deepseek-v4-pro gpt-oss:120b devstral-2:123b ``` `/v1/chat/completions` also works. `/v1/messages` also works directly with `kimi-k2.6`. Example result: ```text OLLAMA_MESSAGES_OK ``` I also tested the route that Claude Desktop Cowork appears to fall back to: ```text model = "claude-sonnet-4-6" ``` Against the Ollama `/v1/messages` endpoint, Ollama returns: ```text 404 model "claude-sonnet-4-6" not found ``` This suggests that Claude Desktop Cowork expects Claude/Anthropic-style model routes, while Ollama Cloud returns raw Ollama model IDs. To verify this, I created a temporary local test proxy that exposes Claude-compatible model IDs and maps them internally to Ollama Cloud models, for example: ```text claude-sonnet-4-6 -> kimi-k2.6 claude-opus-4-6 -> qwen3-coder:480b claude-haiku-4-6 -> minimax-m2.7 ``` With this alias mapping, Claude Desktop Cowork works. The model selector shows multiple models, and messages are successfully sent through Cowork using Ollama Cloud models. So this does not look like an API key, subscription, authentication, or Ollama Cloud inference issue. It looks like the missing/broken part is the Claude Desktop Cowork Gateway model discovery / alias routing layer. Claude Desktop seems to filter out the raw Ollama model IDs and ends up with: ```text rawCount: 39 usable models: 0 ``` This matches the macOS report above and strongly suggests that the issue is specific to Claude Desktop’s Cowork/Gateway integration. The Claude Code integration working with the same API key is a useful reference point.
Author
Owner

@santorres commented on GitHub (May 6, 2026):

Same here on Mac. It was working fine before Update to Claude 1.6259.1 (5095e7) 2026-05-06T03:26:09.000Z in the afternoon.

<!-- gh-comment-id:4390566252 --> @santorres commented on GitHub (May 6, 2026): Same here on Mac. It was working fine before Update to Claude 1.6259.1 (5095e7) 2026-05-06T03:26:09.000Z in the afternoon.
Author
Owner

@lowaszwillie commented on GitHub (May 6, 2026):

This is useful confirmation.

I am seeing the same broken state on Windows after the Claude Desktop 1.6259.1 update.

Environment:

Windows 11
Claude Desktop 1.6259.1
Package: Claude_1.6259.1.0_x64__pzs8sxrjxfjjc
Ollama 0.23.1
Valid Ollama Cloud API key
Active Ollama Cloud subscription

In the failing state, Claude Desktop Cowork starts in Gateway mode, but the model selector only shows:

Legacy Model

<!-- gh-comment-id:4391543476 --> @lowaszwillie commented on GitHub (May 6, 2026): This is useful confirmation. I am seeing the same broken state on Windows after the Claude Desktop 1.6259.1 update. Environment: Windows 11 Claude Desktop 1.6259.1 Package: Claude_1.6259.1.0_x64__pzs8sxrjxfjjc Ollama 0.23.1 Valid Ollama Cloud API key Active Ollama Cloud subscription In the failing state, Claude Desktop Cowork starts in Gateway mode, but the model selector only shows: Legacy Model
Author
Owner

@psorii commented on GitHub (May 6, 2026):

+1 macOS after 1.6259.1 update

<!-- gh-comment-id:4392763406 --> @psorii commented on GitHub (May 6, 2026): +1 macOS after 1.6259.1 update
Author
Owner

@Alakeel commented on GitHub (May 7, 2026):

+1 same facing this issue ...

<!-- gh-comment-id:4393276077 --> @Alakeel commented on GitHub (May 7, 2026): +1 same facing this issue ...
Author
Owner

@thangnt4411 commented on GitHub (May 7, 2026):

+1 windows 11 arm

<!-- gh-comment-id:4395088015 --> @thangnt4411 commented on GitHub (May 7, 2026): +1 windows 11 arm
Author
Owner

@cwm003 commented on GitHub (May 7, 2026):

+1 on macOS 1.6259.1 update

<!-- gh-comment-id:4396202995 --> @cwm003 commented on GitHub (May 7, 2026): +1 on macOS 1.6259.1 update
Author
Owner

@Br1-data commented on GitHub (May 7, 2026):

same problem, windows 11

<!-- gh-comment-id:4396329633 --> @Br1-data commented on GitHub (May 7, 2026): same problem, windows 11
Author
Owner

@omarbouguelta commented on GitHub (May 7, 2026):

same issue, windows 11

<!-- gh-comment-id:4397003801 --> @omarbouguelta commented on GitHub (May 7, 2026): same issue, windows 11
Author
Owner

@vlados412 commented on GitHub (May 7, 2026):

+1 on macOS 1.6259.1 update

<!-- gh-comment-id:4398885410 --> @vlados412 commented on GitHub (May 7, 2026): +1 on macOS 1.6259.1 update
Author
Owner

@JihadFenix commented on GitHub (May 8, 2026):

+1 windows11 Claude Version 1.6259.1 (5095e7)

<!-- gh-comment-id:4405068585 --> @JihadFenix commented on GitHub (May 8, 2026): +1 windows11 Claude Version 1.6259.1 (5095e7)
Author
Owner

@lowaszwillie commented on GitHub (May 8, 2026):

Update after additional testing and checking the latest Ollama release/docs.

It looks like this is no longer just a local setup issue.

I updated Ollama and confirmed that I am now on:

ollama version is 0.23.2

winget upgrade --id Ollama.Ollama also reports:

No available upgrade found.
No newer package versions are available from the configured sources.

Claude Code CLI is installed and available on my system:

claude --version
2.1.131 (Claude Code)

The important new finding is that Ollama 0.23.2 appears to have removed Claude Desktop support from ollama launch.

The current Ollama documentation for Claude Desktop now says that Claude Desktop is no longer supported by ollama launch, and existing installations should be restored with:

ollama launch claude-desktop --restore

It also points users to Claude Code instead for Anthropic-compatible coding workflows with Ollama.

This matches what we observed during debugging:

  • Ollama Cloud API works
  • /v1/models returns the available Ollama Cloud models
  • /v1/messages works directly with Ollama Cloud models
  • /v1/chat/completions also works
  • Claude Desktop Cowork enters Gateway mode
  • but the model picker only shows Legacy Model
  • Claude Desktop logs show:
[custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 }
[custom-3p] Model discovery: not supported by provider; picker = 0 (empty)

This now seems consistent with the explanation that Claude Desktop’s third-party gateway integration is limited to Anthropic-compatible model routes, while Ollama Cloud returns raw Ollama model IDs such as:

kimi-k2.6
qwen3-coder:480b
glm-5.1
minimax-m2.7
nemotron-3-super

So the issue does not appear to be authentication, subscription, or the Ollama Cloud API itself.

Given Ollama 0.23.2, it looks like the intended path is now:

ollama launch claude

or a specific Claude Code model, for example:

ollama launch claude --model kimi-k2.6:cloud

In other words, Claude Desktop/Cowork integration appears to be removed/unsupported now, while Claude Code CLI remains the supported Ollama integration path.

This may be worth documenting clearly in the issue because earlier Ollama 0.23.0/0.23.1 documentation and behavior suggested that Claude Desktop + Cowork was supported, but in 0.23.2 that no longer seems to be the case.

<!-- gh-comment-id:4405098078 --> @lowaszwillie commented on GitHub (May 8, 2026): Update after additional testing and checking the latest Ollama release/docs. It looks like this is no longer just a local setup issue. I updated Ollama and confirmed that I am now on: ```text ollama version is 0.23.2 ``` `winget upgrade --id Ollama.Ollama` also reports: ```text No available upgrade found. No newer package versions are available from the configured sources. ``` Claude Code CLI is installed and available on my system: ```text claude --version 2.1.131 (Claude Code) ``` The important new finding is that Ollama 0.23.2 appears to have removed Claude Desktop support from `ollama launch`. The current Ollama documentation for Claude Desktop now says that Claude Desktop is no longer supported by `ollama launch`, and existing installations should be restored with: ```powershell ollama launch claude-desktop --restore ``` It also points users to Claude Code instead for Anthropic-compatible coding workflows with Ollama. This matches what we observed during debugging: * Ollama Cloud API works * `/v1/models` returns the available Ollama Cloud models * `/v1/messages` works directly with Ollama Cloud models * `/v1/chat/completions` also works * Claude Desktop Cowork enters Gateway mode * but the model picker only shows `Legacy Model` * Claude Desktop logs show: ```text [custom-3p] Gateway /v1/models returned 0 usable models { rawCount: 39 } [custom-3p] Model discovery: not supported by provider; picker = 0 (empty) ``` This now seems consistent with the explanation that Claude Desktop’s third-party gateway integration is limited to Anthropic-compatible model routes, while Ollama Cloud returns raw Ollama model IDs such as: ```text kimi-k2.6 qwen3-coder:480b glm-5.1 minimax-m2.7 nemotron-3-super ``` So the issue does not appear to be authentication, subscription, or the Ollama Cloud API itself. Given Ollama 0.23.2, it looks like the intended path is now: ```powershell ollama launch claude ``` or a specific Claude Code model, for example: ```powershell ollama launch claude --model kimi-k2.6:cloud ``` In other words, Claude Desktop/Cowork integration appears to be removed/unsupported now, while Claude Code CLI remains the supported Ollama integration path. This may be worth documenting clearly in the issue because earlier Ollama 0.23.0/0.23.1 documentation and behavior suggested that Claude Desktop + Cowork was supported, but in 0.23.2 that no longer seems to be the case.
Author
Owner

@francescogruner commented on GitHub (May 8, 2026):

After additional testing with Ollama 0.23.2 and Claude Desktop/Cowork in third-party inference (3P) mode, it seems the issue is not authentication-related but rather related to the model discovery compatibility system used by Claude Desktop.

What currently works:

  • "/v1/messages"
  • "/v1/chat/completions"
  • direct Anthropic-compatible requests
  • Ollama Cloud authentication
  • Claude Code via "ollama launch claude"

I tested both:

  • direct provider configuration through "claude_desktop_config.json"
  • a local HTTP proxy that rewrites model IDs

With direct configuration, providers such as DeepSeek and MiniMax work correctly using Anthropic-compatible endpoints and mappings like:

{
"id": "anthropic/claude-sonnet-4-5",
"providerModelId": "deepseek-v4-flash"
}

or:

{
"id": "anthropic/claude-sonnet-4-5",
"providerModelId": "MiniMax-M2.7"
}

With Ollama Cloud, however, the situation appears different.

Claude Desktop seems to expect Anthropic-compatible model naming during gateway probing, while Ollama Cloud returns native Ollama model IDs such as:

  • "gpt-oss:120b-cloud"
  • "gemma4:31b-cloud"
  • "glm-5.1"
  • "qwen3-coder:450b"

Observed logs:

[custom-3p] Gateway /v1/models returned 0
[custom-3p] Model discovery: not supported

This explains why:

  • the APIs themselves work correctly
  • Claude Code works
  • but Claude Desktop/Cowork fails during the discovery phase

To work around the issue, I built a local HTTP proxy that:

  • exposes Claude-compatible model aliases
  • intercepts "/v1/models"
  • rewrites model IDs before forwarding requests to Ollama Cloud

For example:

claude-sonnet-4-5-20250929
→ gemma4:31b-cloud

claude-haiku-4-5-20251001
→ gpt-oss:120b-cloud

With this workaround, Claude Desktop is actually able to use Ollama Cloud models successfully.

Additionally, based on the updated Ollama 0.23.2 documentation, it appears the focus has shifted toward Claude Code rather than Claude Desktop/Cowork.

For example:

ollama launch claude
ollama launch claude-desktop --restore

This suggests that Claude Desktop 3P mode may primarily be designed to run Claude models through external providers (Bedrock, Vertex, Anthropic-compatible gateways), rather than arbitrary models.

It would be very helpful to clarify in the documentation whether:

  • Ollama Cloud support for Claude Desktop/Cowork is still intended
  • has been deprecated
  • or is no longer supported starting from 0.23.2

Proxy: https://github.com/francescogruner/claude-3p-ollama-proxy

<!-- gh-comment-id:4407041350 --> @francescogruner commented on GitHub (May 8, 2026): After additional testing with Ollama 0.23.2 and Claude Desktop/Cowork in third-party inference (3P) mode, it seems the issue is not authentication-related but rather related to the model discovery compatibility system used by Claude Desktop. What currently works: - "/v1/messages" - "/v1/chat/completions" - direct Anthropic-compatible requests - Ollama Cloud authentication - Claude Code via "ollama launch claude" I tested both: - direct provider configuration through "claude_desktop_config.json" - a local HTTP proxy that rewrites model IDs With direct configuration, providers such as DeepSeek and MiniMax work correctly using Anthropic-compatible endpoints and mappings like: { "id": "anthropic/claude-sonnet-4-5", "providerModelId": "deepseek-v4-flash" } or: { "id": "anthropic/claude-sonnet-4-5", "providerModelId": "MiniMax-M2.7" } With Ollama Cloud, however, the situation appears different. Claude Desktop seems to expect Anthropic-compatible model naming during gateway probing, while Ollama Cloud returns native Ollama model IDs such as: - "gpt-oss:120b-cloud" - "gemma4:31b-cloud" - "glm-5.1" - "qwen3-coder:450b" Observed logs: [custom-3p] Gateway /v1/models returned 0 [custom-3p] Model discovery: not supported This explains why: - the APIs themselves work correctly - Claude Code works - but Claude Desktop/Cowork fails during the discovery phase To work around the issue, I built a local HTTP proxy that: - exposes Claude-compatible model aliases - intercepts "/v1/models" - rewrites model IDs before forwarding requests to Ollama Cloud For example: claude-sonnet-4-5-20250929 → gemma4:31b-cloud claude-haiku-4-5-20251001 → gpt-oss:120b-cloud With this workaround, Claude Desktop is actually able to use Ollama Cloud models successfully. Additionally, based on the updated Ollama 0.23.2 documentation, it appears the focus has shifted toward Claude Code rather than Claude Desktop/Cowork. For example: ollama launch claude ollama launch claude-desktop --restore This suggests that Claude Desktop 3P mode may primarily be designed to run Claude models through external providers (Bedrock, Vertex, Anthropic-compatible gateways), rather than arbitrary models. It would be very helpful to clarify in the documentation whether: - Ollama Cloud support for Claude Desktop/Cowork is still intended - has been deprecated - or is no longer supported starting from 0.23.2 Proxy: https://github.com/francescogruner/claude-3p-ollama-proxy
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#87869