Melious
Integrations

Claude Desktop

Run Claude Desktop's own inference on Melious through Anthropic's third-party gateway mode — Chat, Cowork, and Code on European infrastructure

Claude Desktop
by Anthropicclaude.ai/download

Claude Desktop is Anthropic's desktop app for macOS, Windows, and Linux (beta) — chat, the Cowork agent workspace, and Code sessions. Most of it you know from the browser. What makes it interesting here is a deployment mode Anthropic calls third-party inference, which routes model requests through a provider you nominate: one of the big clouds, or a gateway you run yourself.

The contract for a gateway is short: implement the Anthropic Messages endpoint with streaming and tool use. We already do, so Melious drops in as the provider — a base URL, a key, an explicit model list, and the picker holds open-weight models running in Europe. Conversation history stays on local disk, and inference comes to us.

This is the closest thing to a native integration in this section, and we built none of it. Anthropic documents the mode, and Ollama got there first — they shipped Anthropic Messages compatibility in v0.14.0 and then registered as a gateway provider. We're taking the same route with an endpoint we already serve. Fair warning: it's an enterprise deployment path, so expect more setup than pasting a base URL into a settings field.

Third-party inference replaces Anthropic rather than sitting alongside it. You don't sign in to a Claude account, and the model picker shows only what your gateway serves — point it at us and that means open-weight models, with no Claude in the list. To keep Claude answering and hand Melious specific jobs instead, see Keep Claude and delegate.

Setup

Install and skip sign-in

Download Claude Desktop from claude.com/download and launch it, but don't sign in or create an Anthropic account — the third-party configuration needs to land first.

These steps follow Anthropic's own third-party rollout guide, which covers macOS and Windows; the Linux build is configured through a root-owned /etc/claude-desktop/managed-settings.json instead.

Cowork wants macOS 14 or later, or Windows 10 build 19041 or later, with working hardware virtualization. On Windows the installer matters: the .msix package carries Cowork, the legacy .exe doesn't.

Open the configuration window

From the macOS menu bar — on Windows, the ☰ menu at the top left of the sign-in screen — go to Help → Troubleshooting → Enable Developer Mode, then Developer → Configure Third-Party Inference….

The window validates values as you type, tests the connection against the endpoint you give it, and computes the network egress allowlist for your settings. It beats hand-editing a plist or a registry key.

Point it at Melious

Fill in the Connection section, then the Gateway credentials card:

FieldValue
Inference providerGateway
Gateway base URLhttps://api.melious.ai
Gateway API keysk-mel-<YOUR_API_KEY>
Credential kindStatic API key
Gateway auth schemeBearer

The base URL is the root, without /v1 — the Anthropic client appends its own version prefix, the same rule as Claude Code. Anthropic's own examples disagree with each other on this point, so use the window's connection test to confirm it before you roll the config anywhere.

We accept x-api-key as well, if your deployment would rather send the key that way.

Apply and verify

Click Apply locally. The app relaunches, and the sign-in screen now offers to start in third-party mode instead of signing in to Anthropic.

Check the wiring with Help → Troubleshooting → Copy Managed Configuration Report. It lists which keys were read, where they came from, and whether the credentials validated. Secrets come back redacted.

To get your old setup back, choose the Anthropic sign-in option on the sign-in screen.

Choosing models

This is the step that catches everyone, so read it before you touch the model list.

Leave the list alone and the picker comes up empty. Auto-discovery calls GET /v1/models, then keeps only IDs that look like Claude models — which is none of ours. The app logs it plainly, with the raw count of what the endpoint returned:

Setting inferenceModels to Melious IDs doesn't fix it either. The app drops them one by one:

inferenceModels: "glm-5.2" is not an Anthropic model and was removed from the list
  — expected a gateway model route referencing an Anthropic model
  (e.g. claude-sonnet-4-5, anthropic/claude-*)

What it wants is Anthropic-shaped route names, and that happens to be exactly what our Messages endpoint already understands: we match the family name in the route and hand it to real open-weight models. So name the routes the way Anthropic names models, and use labelOverride to tell the truth in the picker:

inferenceModels
[
  { "name": "claude-sonnet-4-5", "labelOverride": "Melious — main" },
  { "name": "claude-3-5-sonnet", "labelOverride": "Melious — secondary" }
]

The first entry is the default. anthropic/claude-sonnet-4-5 works too if your gateway prefers a prefixed route.

Two things to know. Sonnet routes are the ones that work today — we currently have no working opus or haiku mapping, so leave both out. An opus route fails with 404 not_found_error when selected, and a haiku route with 400 invalid_request_error. And skip anthropicFamilyTier: the app derives the tier from an Anthropic-shaped name on its own, and it rejects the field outright when the name isn't one (value matches a known non-Anthropic model fragment; ignoring).

Which open-weight model actually answers each route is set by the tier mapping on our side, so melious.ai/hub/models is where you check what you're getting. For long tool chains, favor models flagged _meta.capabilities.function_calling on GET /v1/models?include_meta=true.

You'll know it took when the app logs picker = 2 (inferenceModels) and ConfigHealth recomputed { state: 'healthy' }.

In the configuration window this is a form. In an exported macOS profile or Windows registry policy it's a single key whose value is the whole JSON array encoded as a string; on Linux the managed file is real JSON, so the array stays native. Dotted names like inferenceModels.name are never read on any platform.

Keeping the traffic in Europe

Conversation content goes only to the endpoint you configured, and history is stored on the local machine. What remains is the app's own telemetry, which is separate traffic, on by default, and disabled by configuration:

KeySet toWhat it costs you
disableEssentialTelemetrytrueNo crash reports or error traces. Anthropic support loses remote visibility into failures, so you collect logs by hand when you need help.
disableNonessentialTelemetrytrueNo product analytics. Also disables the Send button on diagnostic reports.
disableNonessentialServicestrueCosmetic only: connector favicons fall back to generic icons, artifact previews go static, and MCP App widgets are replaced by the tool's text result.
disableAutoUpdatestrueYour team owns the update pipeline.
skipWebFetchPreflighttrueCode sessions stop checking each fetched domain against api.anthropic.com.

skipWebFetchPreflight is new — it shipped in Claude Desktop 1.37937.0. On an older build, put WebFetch in disabledBuiltinTools instead.

With all five set, the app makes no runtime connections to Anthropic-operated hosts except downloads.claude.ai, which serves the sandbox bundle and CLI binary at session start. Anthropic publishes an offline installer with both components built in; on that variant your gateway is the only egress the app needs.

In an exported macOS profile or Windows registry policy, every value is written as a string — booleans included, so "true", not true. The Linux managed file is real JSON and takes real booleans.

Keep Claude and delegate

Third-party mode is all or nothing. If you'd rather keep Claude answering and hand Melious the work you want running in Europe, add MCP servers to a standard install instead. That's claude_desktop_config.json, reachable from Settings → Developer → Edit Config:

claude_desktop_config.json
{
  "mcpServers": {
    "melious": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://api.melious.ai/v1/mcp/jsonrpc",
        "--header", "Authorization: Bearer sk-mel-<YOUR_API_KEY>"
      ]
    },
    "melious-chat": {
      "command": "npx",
      "args": ["-y", "@pyroprompts/any-chat-completions-mcp"],
      "env": {
        "AI_CHAT_BASE_URL": "https://api.melious.ai/v1",
        "AI_CHAT_KEY": "sk-mel-<YOUR_API_KEY>",
        "AI_CHAT_NAME": "Melious",
        "AI_CHAT_MODEL": "<MODEL_ID>"
      }
    }
  }
}

melious is our hosted tool server — web search, scraping, a Python sandbox — reached through the mcp-remote bridge. MCP covers the transports and the kit.mcp scope it needs. melious-chat is an OpenAI-compatible bridge pointed at our /v1 surface; it shows up as one tool called chat-with-melious, and you name it in the prompt or Claude answers on its own. Watch the two base URLs — the bridge takes /v1, the tool server carries its path in the URL.

The honest limits: the bridge sends a single user message per call with no history and no streaming, and your prompt still reaches Melious by way of Anthropic, because Anthropic's model is what decides to call the tool. That's delegation, not relocation.

What's different

  • Routes are named after Claude, not after our models. The app only accepts Anthropic-shaped model names, so inferenceModels is required and every entry is a claude-* route we map on our side. The picker shows whatever labelOverride you give it.
  • Experimental beta headers are suppressed. Third-party mode turns off Claude Code's experimental features, MCP tool search included, because strict gateways reject the anthropic-beta headers they add. toolSearchEnabled turns tool search back on once you've confirmed we forward it.
  • environment_impact and billing_cost don't surface in the app. Our Messages endpoint records them server-side for your usage dashboard but doesn't return them in the Anthropic-shaped response, so the client never sees them either way.
  • No explicit cache_control. There's no handle for marking a prefix cacheable. Transparent prefix caching still happens provider-side and shows up as usage.cache_read_input_tokens. See Models.

When it breaks

  • The normal claude.ai sign-in screen appears instead of third-party mode — inferenceProvider is missing, misspelled, or set to something unrecognized, or the config was applied while the app was running. Quit fully and relaunch.
  • The model picker is empty — either discovery filtered every Melious ID, or inferenceModels was set to Melious IDs and the app removed them. Use claude-* route names, as in Choosing models.
  • A picker entry errors the moment you select it — most likely a claude-haiku-* or claude-opus-* route. Neither mapping works against us today: haiku returns 400 invalid_request_error, opus returns 404 not_found_error. Drop the route and use a claude-sonnet-* name.
  • no credential configured for provider "gateway" — the credential fields didn't reach the app. Re-enter them in the configuration window and apply again.
  • Cowork sessions won't start — hardware virtualization is off, the OS is below macOS 14 or Windows 10 build 19041, or the machine was provisioned from the legacy Windows .exe. Anthropic ships a standalone readiness check that names the cause.
  • Requests fail with 400 after you set toolSearchEnabled — the experimental request shape isn't getting through. Turn it back off.
  • Agentic sessions give up early — model capability, not protocol. Cowork and Code run long tool chains; move the route to a stronger model on our side.
  • Conversation titles stay generic while the chat itself works fine — title generation uses the default route, which is the first inferenceModels entry, while the session uses whatever you picked. If that one route is unhealthy you lose titles and nothing else. We watched exactly this: eight minutes of 503s on the default route while turns on the second route kept succeeding.
  • A run of 503s on one route while another is fine — we fan out across European providers, and a provider going unhealthy takes down whichever tier maps to it. It isn't always brief: expect to retry with backoff rather than assume it clears in a second. A streamed request can also come back 200 and then carry an api_error inside the stream, so treat in-band errors as retryable too.

Logs live under the third-party paths, not the standard app's: ~/Library/Logs/Claude-3p/main.log on macOS, %LOCALAPPDATA%\Claude-3p\Logs\main.log on Windows. cli-diagnostics.jsonl sits next to it and is the more useful file when a request fails — it records the HTTP status, the model, and every retry, which main.log summarizes as a single cli failed line.

Errors and retry patterns: Errors.

On this page