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
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208

# Agent settings — mini-me served by llmman (https://github.com/llmmanorg/llmman)
# through its OpenAI-compatible endpoint (/v1/chat/completions).
#
#   llmman pull hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M   # optional: the first question pulls it otherwise
#   llmman serve                                       # 127.0.0.1:17434
#
# llmman loads the model on the first request (in its own llama-server) and
# unloads it after five idle minutes.
provider: llmman

# The model id exactly as `llmman list` / GET /v1/models spells it.
model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M
#model: hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M

# `llmman serve`'s default bind; the OpenAI routes sit under /v1.
baseUrl: http://127.0.0.1:17434/v1

# From a Docker sandbox, the daemon runs on the host.
fallback: http://host.docker.internal:17434/v1

# Only when the daemon was started with LLMMAN_API_KEYS (mandatory when it
# listens beyond loopback); unset otherwise. The key never goes in this file.
# apiKeyEnv: LLMMAN_API_KEY

# Yolo mode. `true` (default): the tools run without asking.
# `false`: every bash call, file write/edit, fetch_content save, lsp rename and plan change
# waits for your answer — [a] once, [s] for the session, [r] reject, [n] never — in the
# terminal, the window and the editor; MCP tools ask too.
# bashTool / editTools still decide which tools EXIST. Called through /ask (mmConfigs),
# an agent follows its asker's yolo, not this one. Override for one run: AGENT_YOLO=false.
yolo: true

# The `bash` tool. 
# `false` removes it: the model can still read and edit files (editTools) and load skills, 
# but never runs a command. If you turn it off, reword the system prompt below — it says "You have a bash tool".
bashTool: true

# The built-in file tools: read_file, write_file, edit_file. 
editTools: true

# The built-in plan tool for managing multi-step plans.
# Set to false to disable plan creation and tracking via the `plan` tool.
planTool: true

# Language servers for the `lsp` tool (definition, references, hover, symbols, diagnostics, rename).
# The file extension picks the server. A server missing from the PATH is skipped with a warning.
# No server listed = no `lsp` tool. Examples (uncomment what you have installed):
# lsp:
#   servers:
#     - name: gopls
#       command: gopls
#       extensions: [".go"]
#     - name: typescript
#       command: typescript-language-server
#       args: ["--stdio"]
#       extensions: [".ts", ".tsx", ".js", ".jsx"]
#     - name: python
#       command: pyright-langserver
#       args: ["--stdio"]
#       extensions: [".py"]
#     - name: rust
#       command: rust-analyzer
#       extensions: [".rs"]

# How many tokens the server actually serves.
# 0 = ask llmman: /api/ps tells it once the model is loaded, so the window is
# learned before the second question. Set it here if you want it from the start
# — and to the same value as LLMMAN_CONTEXT_LENGTH if you set that variable.
contextWindow: 0

# Max number of characters a tool returns to the model. 
# Context safeguard: beyond that, the output is truncated (beginning + end kept).
maxOutput: 16000

# Max number of model <-> tools round trips for a single question. 
# Raise it for tasks that need long chains of commands.
maxTurns: 40

# Where the `read_skill` tool looks for its markdown procedures. 
# The path is relative to the CURRENT DIRECTORY: run the agent from demo-llmman/.
# skillsDir: ../skills

# Persistent sessions, per project. 
# When enabled, every conversation is saved as one JSON file under `dir`.
# `/sessions` lists them, `/resume` continues one; in an editor, "Reload Agent" replays the thread.
sessions:
  enabled: true
  dir: .mm/sessions

# How many lines of a command's output are echoed to the terminal. 
# 0 disables it.
previewLines: 20

displayCommands: true
# Show what a thinking model reasons about before it answers (dim italic in the
# terminal, its own style in the window, a thought chunk in an editor).
# The reasoning is always READ — it is what keeps the watchdog alive while the
# model thinks — this only says whether to show it.
showThinking: true


# The system prompt: what the agent is, and what it is allowed to do.
# This is the knob to play with — it is the shortest path to changing behaviour.
system: |
  Your name is Bob.
  You are a coding agent working in a terminal.
  You have a "bash" tool to run shell commands.
  Use it to explore files, run tests, inspect the repository, etc.
  Chain several commands if needed, then answer clearly in English.

  A request often mixes things you answer from yourself ("say hello") with
  things only a command can answer ("list the files"). Handle every part, in
  the order asked, and run a command for each part that needs one.
  Never state the contents of a file, the output of a command, or the state of
  the repository unless a command in THIS answer returned it. What you did not
  read, you do not know: run the command instead of recalling it.

  SKILLS
  You have a second tool, `read_skill`. Its description lists the procedures
  available for this project — one per kind of task.

  Any request to DO something to a Go project is a skill, not a shell command
  you invent. Match the request against that list, call `read_skill` FIRST,
  before any bash command, and then follow what it says step by step.

  FILE EDITING
  You have three tools for files: `read_file`, `edit_file` and `write_file`.
  They are how a file gets read and changed here: each change is exact,
  checked before it is written, and comes back as a diff with line numbers.
  bash is for running things — building, testing, listing, searching.

  - Read before you write: call `read_file` on the file (numbered=true when
    you need line numbers). You cannot target text you have not seen; never
    rely on what you think you remember about a file.
  - To change an existing file, call `edit_file` with one or more {old, new}
    pairs. `old` is copied from the file character for character — same
    spaces, same indentation, same line breaks — and appears exactly once:
    add the surrounding lines until it is unique. Several pairs are applied
    together, against the original file. An empty `new` deletes the text.
  - Call `write_file` only to create a file, or to rewrite one entirely and
    on purpose. On an existing file it replaces everything, including what
    you did not intend to touch.
  - Read the diff the tool returns: it says exactly what changed and on which
    line. If `edit_file` refuses — text not found, ambiguous, overlapping
    edits — read the file again and fix `old`. Do not fall back to
    `write_file` to force the change through.
  - After editing code, run the narrowest check with bash: the formatter, the
    compiler, or the test covering that file.

  RULES
  - Keep everything the file already does, unless the user asked to remove it.
  - Touch only the files the request is about. Do not add tests, files or
    features that were not asked for.
  - Never run a git command unless the user says git, commit or push.
  - Never move, rename or delete a file unless the user asked for it.
  - Then answer in English, in a few lines.
  - If you don't know how to use a <cli>, run `<cli> --help` (or `<cli> help`)
    to understand the options, then run the command.

  BACKGROUND JOBS
  Never let a command block the answer. Anything that serves, watches or runs
  long goes to the background, with BOTH streams redirected and its pid kept:

    nohup <command> > /tmp/<job>.log 2>&1 & echo $! > /tmp/<job>.pid

  Redirecting only stdout still blocks until the process exits. Read the
  `bg-jobs` skill before you wait on, inspect or stop such a job — each has a
  rule you cannot guess. Stop every job you started before you finish, and say
  which ones you left running.

# Generation settings (OpenAI API keys). Low temperature for a coding agent:
# we want precise and reproducible answers, not creativity.
sampling:
  temperature: 0.0
  parallel_tool_calls: false
  top_p: 0.9
  max_tokens: 4096

# Silence allowed between two tokens once the answer has started.
watchdogTimeout: 30s

# Silence allowed while the model reads the prompt, before the first token:
# on a laptop a 25k-token prompt can take minutes. llama-server reports its
# progress meanwhile, through llmman ("Reading the prompt 12.0k/25.3k tokens"), and each report
# restarts this clock, so it only has to cover one batch of the prompt.
firstTokenTimeout: 3m

# Context compression. 
# ON here: the agent learns the window from /api/ps, so `threshold` has a number to apply to.
context:
  enabled: true

  # Compress when the history reaches this share of the window. 
  threshold: 75

  # Fallback on the message count, for when the window is unknown. 
  # One command costs 2 messages (call + response), so 80 is roughly 30 commands of history.
  maxMessages: 80

  # How many recent questions (with their commands and answers) are kept as-is instead of being summarised. 
  # The model works on the last few turns, so summarising them would make it redo what it just did.
  keepLastTurns: 3

  # max_tokens of the summary request. Reasoning is turned off for it on this provider
  # (a thinking model would otherwise spend the budget thinking and write nothing).
  summaryMaxTokens: 1200

  showStats: true