> ## 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.

# Models

> Exposing a model under a name of your choosing

A model belongs to a provider and carries the name your applications will send.
Adding one is what makes it reachable through the gateway.

## The three names

This is the part worth reading carefully, because a model has three names and
they do different jobs.

| Name         | Who sees it       | What it is                                          |
| ------------ | ----------------- | --------------------------------------------------- |
| Gateway name | Your applications | `provider/alias`. The only name the gateway accepts |
| API name     | The provider      | What nemu sends upstream. Optional                  |
| Display name | You               | A label for the console                             |

The gateway name is built from the provider name and an alias you choose. If
you leave the API name blank, the alias is sent upstream as well.

Set the API name when the provider's own identifier is something you would
rather not expose. A model that upstream calls
`nvidia/nemotron-nano-9b-v2` can be `openrouter/nemotron` to everything you run.

<Note>
  The gateway name is the only name accepted from a client. The provider's own
  identifier does not work from outside, so nothing you run can reach a model
  you did not deliberately expose.
</Note>

## Automatic models

Adding a model to an automatic provider means picking it from the catalog.
Everything factual about it, the context window, the costs, whether it can see
images or call tools, is read live from models.dev on every page load.

You can still rename it. The edit form's gateway name field changes the public
name without touching what is sent upstream.

If a model leaves the catalog or is deprecated, it is disabled automatically and
labelled, so it stops counting against your plan once you delete it.

## Custom models

For a custom provider you describe the model yourself, across three tabs.

**General** is the names, the type and the display name. Types are chat,
embedding, moderation, vision, audio and image.

**Pricing** is costs per million tokens for input and output, optional cache
read and write costs, an optional higher rate above a context threshold, and per
image or per minute costs for those model types. Also the context window and the
maximum output.

**Configuration** is what the model can do: attachments, reasoning and tool
calling, plus how reasoning and speed should be expressed upstream.

## Reasoning style

Different providers ask for reasoning effort in different ways. Left on
automatic, nemu infers it from the model. Set it explicitly when the guess is
wrong.

| Style              | Sends                   |
| ------------------ | ----------------------- |
| Anthropic adaptive | An effort level         |
| Anthropic budget   | A thinking token budget |
| OpenAI effort      | `reasoning_effort`      |
| OpenAI Responses   | `reasoning.effort`      |
| DeepSeek           | A thinking block        |
| Qwen               | `enable_thinking`       |
| None               | Nothing                 |

Effort runs low, medium, high, xhigh and max, clamped to what each model
actually supports.

**Speed mode** does the same for the fast toggle, either Anthropic's fast mode
or OpenAI's priority service tier.

## Two names that always work

`auto` picks the cheapest enabled chat or vision model in the workspace.

A suffix in square brackets is a variant. `openrouter/nemotron[1m]` addresses
the same model with a one million token context window.

## Limits

|              | Free | Starter | Pro | Max | Enterprise |
| ------------ | ---: | ------: | --: | --: | ---------: |
| Models       |    5 |      30 | 100 | 500 |  unlimited |
| Per provider |    3 |       8 |  15 |  25 |  unlimited |