How to run mini-me on llmman

This guide shows how to point mm at llmman through its OpenAI-compatible endpoint. It assumes llmman is installed and you know how to build mm.

Steps

Start the daemon. It listens on 127.0.0.1:17434:
```
llmman serve
```
Optionally pull the model first. Otherwise llmman pulls it on the first question, and that question waits for the download:
```
llmman pull hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M
```
Run the demo configuration from its directory (its skillsDir is ../skills):
```
cd demos/llmman
../../mm agent.llmman.yaml
```
Check the banner. provider: llmman confirms the provider. ctx: 262144 (/api/ps) means the model was already loaded and mm read the window it is served with; ctx: unknown means it was not loaded yet — mm asks again before the next question and prints ctx: … (/api/ps) once it knows.

Variants

Another model. Set model: to the id exactly as llmman list (or GET /v1/models) spells it.
From a Docker sandbox. Nothing to change: when 127.0.0.1:17434 does not answer, mm falls back to http://host.docker.internal:17434/v1, the daemon on the host.
Daemon started with LLMMAN_API_KEYS (mandatory when it listens beyond loopback). Export one of the keys in LLMMAN_API_KEY, the provider's default variable, or name another variable under apiKeyEnv.
LLMMAN_CONTEXT_LENGTH set on the daemon. /api/ps already reports it once the model is loaded; set contextWindow to the same value if you want compression to know it from the first question.
Keep your own agent.yaml. AGENT_PROVIDER=llmman ./mm works as long as the file leaves baseUrl empty.

 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


# How to run mini-me on llmman

This guide shows how to point `mm` at [llmman](https://github.com/llmmanorg/llmman) through its OpenAI-compatible endpoint. It assumes llmman is installed and you know how to build `mm`.

## Steps

1. Start the daemon. It listens on `127.0.0.1:17434`:

   ```bash
   llmman serve
   ```

2. Optionally pull the model first. Otherwise llmman pulls it on the first question, and that question waits for the download:

   ```bash
   llmman pull hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M
   ```

3. Run the demo configuration from its directory (its `skillsDir` is `../skills`):

   ```bash
   cd demos/llmman
   ../../mm agent.llmman.yaml
   ```

4. Check the banner. `provider: llmman` confirms the provider. `ctx: 262144 (/api/ps)` means the model was already loaded and `mm` read the window it is served with; `ctx: unknown` means it was not loaded yet — `mm` asks again before the next question and prints `ctx: … (/api/ps)` once it knows.

## Variants

- **Another model.** Set `model:` to the id exactly as `llmman list` (or `GET /v1/models`) spells it.
- **From a Docker sandbox.** Nothing to change: when `127.0.0.1:17434` does not answer, `mm` falls back to `http://host.docker.internal:17434/v1`, the daemon on the host.
- **Daemon started with `LLMMAN_API_KEYS`** (mandatory when it listens beyond loopback). Export one of the keys in `LLMMAN_API_KEY`, the provider's default variable, or name another variable under `apiKeyEnv`.
- **`LLMMAN_CONTEXT_LENGTH` set on the daemon.** `/api/ps` already reports it once the model is loaded; set `contextWindow` to the same value if you want compression to know it from the first question.
- **Keep your own `agent.yaml`.** `AGENT_PROVIDER=llmman ./mm` works as long as the file leaves `baseUrl` empty.

## See also

- [Providers: one implementation per protocol](../explanation/providers.md) — why llmman's window comes from `/api/ps`, not `/props`.
- [Configuration reference](../reference/configuration.md) — provider defaults.