> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nemu.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Claude Desktop

> Point the Claude desktop app at your own models through Nemu

The Claude desktop app can send its requests to a gateway of your choosing
instead of Anthropic. It speaks the Anthropic Messages API, which Nemu serves,
so every message is billed, quota checked and logged against your workspace and
can be answered by any provider you have connected.

## 1. Create a gateway key

In the console, open **API keys** and create one. It is scoped to the workspace
you are in, and that matters here: the model list the app discovers is the model
list of that key's workspace, so a key from an empty workspace finds nothing.

## 2. Fill in the gateway settings

In the desktop app, open the gateway settings and set:

| Field               | Value                           |
| ------------------- | ------------------------------- |
| Credential kind     | Static API key                  |
| Gateway base URL    | `https://api.nemu.cc/anthropic` |
| Gateway API key     | your Nemu gateway key           |
| Gateway auth scheme | `bearer`                        |

The app appends `/v1/messages` and `/v1/models` itself. A bare
`https://api.nemu.cc` also works, but the `/anthropic` prefix is the one that
serves the Anthropic shaped model list, so prefer it.

<Note>
  Nemu gateway keys look like `sk_xxxxx-xxxxx.` followed by 40 characters. The
  bearer scheme sends `Authorization: Bearer`, which is what the key expects.
  Nemu also accepts `x-api-key` if you would rather use that.
</Note>

## 3. Name your models so the app will list them

This is the step that catches people out. The desktop app only lists models
whose identifier looks like a Claude model. Anything else is refused with:

```
Doesn't look like an Anthropic model: expected a gateway model route
referencing an Anthropic model (e.g. claude-sonnet-4-5, anthropic/claude-*).
```

So a model called `openrouter/nemotron` or `anthropic/gpt-5.6-luna` will not
appear, even though the gateway serves it happily.

The fix is to name the **gateway name** after a Claude model. The gateway name
is only the name clients ask for. Nemu matches the incoming request against it
and sends the provider its own identifier, so the two are completely
independent.

| Field in the console       | Example                 | Who sees it     |
| -------------------------- | ----------------------- | --------------- |
| Gateway name               | `anthropic/claude-luna` | the desktop app |
| Model name at the provider | `gpt-5.6-luna`          | your provider   |

Named that way the model is listed by the app and still routed to the provider
you configured. Use `claude-` or `anthropic/claude-` as the prefix.

If you would rather not rename anything, turn **Model discovery** off in the app
and add the model identifiers by hand under **Models**. Entries you add there
skip discovery.

## 4. Test the connection

The app's test does two separate things, and they can disagree.

**Model discovery** calls `/v1/models`. If it finds nothing, the key belongs to
a workspace with no models, or every model is named in a way the app filters
out. See step 3.

**Inference** calls `/v1/messages`. If discovery passes and this fails with
`API key not configured`, the model was found but the provider behind it has no
credential stored. Open **Providers** in the console and add the provider's own
API key.

## Notes

Anything you would normally do with the desktop app keeps working, including
tool use. Because the request is answered by whichever provider backs the model
you chose, the answer is only as capable as that model.

A provider with a low rate limit will make the app feel broken rather than slow:
Nemu retries an upstream `429` or `503` with backoff, so a provider capped at a
handful of requests a minute shows up as a long pause before the reply. Check
**Usage** in the console if a model is unexpectedly slow.