How to use any OpenAI-compatible server

This guide shows how to run mini-me on a model server that has no dedicated provider — the OpenAI API itself, vLLM, LM Studio, OpenRouter, a company gateway — with the generic openai provider. It assumes the server speaks the OpenAI chat-completions protocol and supports tool calls.

Steps

Point the agent at the server, in its YAML:

provider: openai
model: my-model                       # as the server names it: GET <baseUrl>/models
baseUrl: http://localhost:8000/v1     # omit it for the OpenAI API
contextWindow: 32768                  # the window the server serves: this provider cannot ask for it

If the server needs a key, export it — it never goes in the YAML:
```
export OPENAI_API_KEY=sk-…
```
Another variable name: apiKeyEnv: MY_GATEWAY_KEY.
Start mm as usual (mm agent.yaml, mm -tui agent.yaml, mm -acp). Checked with llmman's OpenAI address used as a generic server: the start-up probe lists the models, and a bash tool call runs:
```
🛠️  bash: echo hello-from-openai-provider
   │ hello-from-openai-provider
🤖 The command printed: `hello-from-openai-provider`
```

mm init writes such a file for you: choose openai, then give the endpoint and the name of the variable that holds the key (or --provider openai --base-url <address> --api-key-env <VARIABLE>) (see Create an agent with mm init).

Variants

The OpenAI API. No baseUrl, OPENAI_API_KEY exported, a model such as gpt-5-mini. Its reasoning models accept only the default temperature and take max_completion_tokens instead of max_tokens: write temperature: 1.0 and max_completion_tokens in sampling. With provider: openai mm sends that block as written, without its own defaults (top_p, max_tokens), so remove a key the API still refuses and nothing else gets in the way. mm init writes such a block. (The request's content was checked against a local server; no call to the OpenAI API was made in this repository.)
"Function tools with reasoning_effort are not supported". Some OpenAI models (seen: gpt-6-luna) refuse tools on /v1/chat/completions while they reason; mm uses that route and always sends tools. Add reasoning_effort: none to sampling (it turns the reasoning off). Not verified in this repository: reported by a user.
The key is refused. The start-up warning says openai: <baseUrl> refused the key (HTTP 401) — export OPENAI_API_KEY.
Nothing answers. The warning says openai: nothing answers at <baseUrl> — check baseUrl: …: the address must be the OpenAI-compatible one, usually ending in /v1.
A server mm has a provider for. Prefer it (dmr, llamacpp, llmman, ollama): those know how the server reads a long prompt, turns reasoning off for a summary, unloads a model, and tell the window size. The generic provider does none of that.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


# How to use any OpenAI-compatible server

This guide shows how to run mini-me on a model server that has no dedicated provider — the OpenAI API itself, vLLM, LM Studio, OpenRouter, a company gateway — with the generic `openai` provider. It assumes the server speaks the OpenAI chat-completions protocol and supports tool calls.

## Steps

1. Point the agent at the server, in its YAML:

   ```yaml
   provider: openai
   model: my-model                       # as the server names it: GET <baseUrl>/models
   baseUrl: http://localhost:8000/v1     # omit it for the OpenAI API
   contextWindow: 32768                  # the window the server serves: this provider cannot ask for it
   ```

2. If the server needs a key, export it — it never goes in the YAML:

   ```bash
   export OPENAI_API_KEY=sk-…
   ```

   Another variable name: `apiKeyEnv: MY_GATEWAY_KEY`.

3. Start mm as usual (`mm agent.yaml`, `mm -tui agent.yaml`, `mm -acp`). Checked with llmman's OpenAI address used as a generic server: the start-up probe lists the models, and a `bash` tool call runs:

   ```text
   🛠️  bash: echo hello-from-openai-provider
      │ hello-from-openai-provider
   🤖 The command printed: `hello-from-openai-provider`
   ```

`mm init` writes such a file for you: choose `openai`, then give the endpoint and the name of the variable that holds the key (or `--provider openai --base-url <address> --api-key-env <VARIABLE>`) (see [Create an agent with `mm init`](create-an-agent.md)).

## Variants

- **The OpenAI API.** No `baseUrl`, `OPENAI_API_KEY` exported, a model such as `gpt-5-mini`. Its reasoning models accept only the default temperature and take `max_completion_tokens` instead of `max_tokens`: write `temperature: 1.0` and `max_completion_tokens` in `sampling`. With `provider: openai` mm sends that block as written, without its own defaults (`top_p`, `max_tokens`), so remove a key the API still refuses and nothing else gets in the way. `mm init` writes such a block. (The request's content was checked against a local server; no call to the OpenAI API was made in this repository.)
- **"Function tools with reasoning_effort are not supported".** Some OpenAI models (seen: `gpt-6-luna`) refuse tools on `/v1/chat/completions` while they reason; mm uses that route and always sends tools. Add `reasoning_effort: none` to `sampling` (it turns the reasoning off). Not verified in this repository: reported by a user.
- **The key is refused.** The start-up warning says `openai: <baseUrl> refused the key (HTTP 401) — export OPENAI_API_KEY`.
- **Nothing answers.** The warning says `openai: nothing answers at <baseUrl> — check baseUrl: …`: the address must be the OpenAI-compatible one, usually ending in `/v1`.
- **A server mm has a provider for.** Prefer it (`dmr`, `llamacpp`, `llmman`, `ollama`): those know how the server reads a long prompt, turns reasoning off for a summary, unloads a model, and tell the window size. The generic provider does none of that.

## See also

- [Configuration reference — provider defaults](../reference/configuration.md#provider-defaults): what `openai` sends and does not
- [Providers — explanation](../explanation/providers.md)