# Harbor Boost Modules

Documentation for built-in modules in Harbor Boost.

## 3t

3T (Three-Turn) is a module that facilitates a three-turn conversation with the user.
  It prompts the user to answer a question three times, each time providing a different answer.
  The user is encouraged to correct any mistakes made in the previous answers.
  The final answer is derived from the three answers provided by the user.


## ambi

Analyzes the question in the chat and provides a detailed answer.
  The analysis includes identifying ambiguities, details, definitions, and discrepancies.
  The final answer is provided based on the analysis.
  This module is designed to help clarify complex questions and provide a comprehensive response.


## analogical

`analogical` grounds the response by generating a fitting analogy before answering.
The LLM first constructs a concrete, relatable analogy for the user's query,
then uses it as context to provide a more grounded answer.

```bash
# Enable the module
harbor boost modules add analogical
```


## autocheck

`autocheck` runs a lightweight self-check on coding deliverable turns before the
user sees the final answer. Non-deliverable turns (explanations, acknowledgments,
brainstorming) pass through unchanged to keep latency low.

On deliverable turns the module drafts a response, audits it with a structured
checklist (correctness, completeness, file-path grounding), optionally revises once,
then emits the final answer.

**When to use**

- Opt-in quality gate on **coding deliverable** turns — add via workflow or module list
- Enable when you want draft→audit→revise before the user sees code changes
- Safe to leave enabled in mixed chats: explanations and short acks pass through
- Set `HARBOR_BOOST_WORKSPACE_ROOT` so path citations require workspace evidence

Autocheck triggers when the latest user message carries **at least two**
deliverable signals (for example a coding keyword plus a repo-relative file path),
when the ``finish`` tool was called in recent chat history, or when the user sends
an explicit completion signal (`we're done`, `ship it`, `looks good`) after prior
coding work. Simple acknowledgments (`thanks`, `ok`, `continue`), research-only turns, and very
short messages are always skipped. In chained workflows, pass-through turns honor
`defer_final` so the explicit `final` workflow step streams the answer.

When `HARBOR_BOOST_WORKSPACE_ROOT` is set and paths are cited, the audit cannot
return `pass` without workspace evidence — either direct `read_workspace_file`
reads, `grep_workspace` symbol checks, `list_workspace_files` directory scans,
`git_diff_workspace` change summaries (git repos), or tool calls during workspace
exploration.

Before the LLM audit, mechanical pre-checks (no model call) run when a workspace
is configured:

- **Git diff context** — in a git repo, `git diff --stat` is included in audit context
  (models can also call `git_diff_workspace` for the same summary)
- **Path existence** — cited draft paths are verified with `read_workspace_file`
- **Code block grounding** — drafts with fenced code but zero file paths are flagged
- **Test hint** — when test files exist near changed paths, a non-blocking warning
  suggests running tests with a command inferred from `pyproject.toml` or
  `package.json` scripts when detectable
- **Linter hint** — when `.eslintrc`, `ruff.toml`, or `pyproject.toml` `[tool.ruff]`
  exist near changed paths, a non-blocking warning suggests a lint command for
  matching file types

Mechanical findings are structured blockers merged into the audit before delivery.
Audit debug logs include `triggered`, `gate_reason`, `tool_calls`, and `verdict`
for troubleshooting.

**Parameters**

- `enabled` — when false, pass through without auditing. Default: `true`
- `max_passes` — maximum audit-and-revise passes. Default: `1`
- `max_revise_passes` — maximum revise passes after a revise verdict. Default: `1`,
  max `2`. Strict mode allows one extra revise (capped at 2).
- `max_workspace_files` — workspace files read per request. Default: `5`
- `workspace_file_max_chars` — characters per workspace file. Default: `50000`
- `show_audit` — when true, append a brief audit footer to the final answer and emit
  an HTML findings summary artifact for the UI. Default: `false`. Overridable per
  request via `@boost_show_audit`.
- `strict` — when true, prepend a warning banner when critical or major findings
  remain after all revise passes. Default: `false`.
- `audit_model` — model for the structured audit sub-call. Default: empty (same as
  the request model). Set via `HARBOR_BOOST_AUTOCHECK_AUDIT_MODEL`.
- `draft_model` — model for the initial draft sub-call. Default: empty (same as
  the request model). Set via `HARBOR_BOOST_AUTOCHECK_DRAFT_MODEL`.
- `revise_model` — model for the revise sub-call. Default: empty (same as
  the request model). Set via `HARBOR_BOOST_AUTOCHECK_REVISE_MODEL`.

```bash
harbor boost modules add autocheck
harbor config set HARBOR_BOOST_AUTOCHECK_ENABLED true
harbor config set HARBOR_BOOST_AUTOCHECK_MAX_PASSES 1
harbor config set HARBOR_BOOST_AUTOCHECK_MAX_REVISE_PASSES 1
harbor config set HARBOR_BOOST_AUTOCHECK_SHOW_AUDIT true
harbor config set HARBOR_BOOST_AUTOCHECK_STRICT true
harbor config set HARBOR_BOOST_AUTOCHECK_AUDIT_MODEL gpt-4o-mini
harbor config set HARBOR_BOOST_AUTOCHECK_DRAFT_MODEL gpt-4o
harbor config set HARBOR_BOOST_AUTOCHECK_REVISE_MODEL gpt-4o
harbor config set HARBOR_BOOST_WORKSPACE_ROOT /workspace/myproject
```

**Standalone**

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=autocheck" \
  -e "HARBOR_BOOST_WORKSPACE_ROOT=/workspace" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## autotemp

![autotemp screenshot](./boost-autotemp.png)

The model will be given a tool to automatically adjust its own temperature based on the specific task.

```bash
# with Harbor
harbor boost modules add autotemp

# Standalong usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=autotemp" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## caveman

`caveman` compresses assistant prose while keeping technical accuracy intact.
It injects terse-communication rules (lite, full, ultra, or wenyan variants) into
the chat before the downstream completion — the well-known "why use many token when
few do trick" workflow adapted for OpenAI-compatible chat completions.

Inspired by [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman).

**Parameters**

- `level` — `lite`, `full` (default), `ultra`, `wenyan-lite`, `wenyan-full`,
  `wenyan-ultra`, or `off`

```bash
harbor boost modules add caveman
harbor config set HARBOR_BOOST_CAVEMAN_LEVEL full
```

Users can switch per request with `/caveman lite` or disable with `stop caveman`
/ `normal mode` in the latest user message.

Pair with `ponytail` for minimal code: caveman governs how the model talks,
ponytail governs what it builds.


## cea

`cea` - Cellular Automata

  Adds a cellular automata outputs to the chat.
  The idea is to introduce pseudo-random context that has innate structure and observe how that affects the LLM's response.
  In practice, most LLMs are efficient enough to not focus on such part of the input at all, so this module is useless.


## cex

`cex` - Context Expansion.

  Rephrases initial input content multiple times, generating variants of the original text.
  The idea is that reprojections of the original content can help avoiding otherwise overfit answers.



## Web search requirement

`quickhop`, `deephop`, and the `tools` module's `web_search` helper all require a
configured web search backend. Without one, research turns and tool calls fail or
return empty results.

Harbor Boost picks the provider the same way as [`harbor launch --web`](./3.-Harbor-CLI-Reference.md#harbor-launch-launch-options---service-servicetool-args):

1. **Tavily** — set `HARBOR_BOOST_TAVILY_API_KEY` (takes precedence when present)
2. **SearXNG** — set `HARBOR_BOOST_SEARXNG_URL` (default `http://searxng:8080` on the Harbor network)

See also the [SearXNG service guide](./2.3.1-Satellite&colon-SearXNG.md) for host port,
internal URL, and external-instance options.

### Manual setup

When Boost is enabled outside `harbor launch`, start SearXNG alongside Boost and
point Boost at the internal URL:

```bash
harbor up boost searxng
harbor boost modules add quickhop   # or deephop, or a custom workflow
harbor config set HARBOR_BOOST_SEARXNG_URL http://searxng:8080
```

For standalone Boost containers, use the host-reachable SearXNG port (default `33811`):

```bash
harbor config set HARBOR_BOOST_SEARXNG_URL http://host.docker.internal:33811
```

Or skip SearXNG and use Tavily:

```bash
harbor config set HARBOR_BOOST_TAVILY_API_KEY <key>
```

### `harbor launch` automation

[`harbor launch`](./3.-Harbor-CLI-Reference.md#harbor-launch-launch-options---service-servicetool-args)
configures the same web-search stack automatically:

| Flag | Behavior |
|------|----------|
| `--web` | Starts Boost + SearXNG; routes the tool to a generated `boost-web-<model>` workflow with `web_search` and `read_url` tools |
| `--workflow <module>` | Starts Boost with one module; **auto-starts SearXNG** for `quickhop` and `deephop` |

SearXNG auto-starts when the active workflow includes web research modules
(`quickhop` and/or `deephop`). Workflows that only use workspace modules
(`autocheck`, `diffscope`) do not start SearXNG.

```bash
# Module workflow with quickhop — auto-starts SearXNG
harbor launch --workflow quickhop --backend ollama --model qwen3.5:4b codex

harbor launch --web --backend ollama --model qwen3.5:4b codex
```

`--web` and `--workflow` cannot be combined on the same launch.

## Workspace bind mount

Agentic Boost modules and the [`tools`](#tools) module's workspace file helpers require a host directory bind-mounted into the container and an in-container jail root. Without both, workspace file tools are disabled and modules like [`autocheck`](#autocheck) and [`diffscope`](#diffscope) cannot verify cited file paths against your repo.

In Harbor Compose, set [`HARBOR_BOOST_WORKSPACE`](./5.2.2-Harbor-Boost-Configuration.md#harbor_boost_workspace_root) to the host path (or `harbor config set boost.workspace "$(pwd)"`). Harbor mounts it at `/workspace` by default. Set [`HARBOR_BOOST_WORKSPACE_ROOT`](./5.2.2-Harbor-Boost-Configuration.md#harbor_boost_workspace_root) to the in-container mount point, typically `/workspace`. When `HARBOR_BOOST_WORKSPACE` is empty, Harbor uses `./services/boost/workspace` as a scratch directory.

### Harbor setup

```bash
# From your project repo
harbor config set boost.workspace "$(pwd)"
harbor config set boost.workspace.root /workspace

# Enable workspace tools for coding workflows
harbor config set HARBOR_BOOST_TOOLS 'read_workspace_file;grep_workspace;list_workspace_files;write_workspace_file'
harbor config update
harbor restart boost
```

`write_workspace_file` is opt-in — add it to `HARBOR_BOOST_TOOLS` when you want the model to edit files in the mounted repo.

### Modules that use workspace

| Module | Workspace use |
|--------|---------------|
| `autocheck` | Verifies cited file paths against the repo |
| `diffscope` | Scope-checks mentioned files against user-stated constraints |

[`harbor launch`](./3.-Harbor-CLI-Reference.md#harbor-launch-launch-options---service-servicetool-args) with `--sandbox workspace-write` wires workspace write tools.

### Workspace tools

When `HARBOR_BOOST_WORKSPACE_ROOT` is set, the [`tools`](#tools) module exposes:

- `read_workspace_file`, `grep_workspace`, `list_workspace_files`
- `git_diff_workspace` (when the root is a git repository)
- `write_workspace_file` (opt-in — add to `HARBOR_BOOST_TOOLS`)

Paths are jailed to `HARBOR_BOOST_WORKSPACE_ROOT`. See [workspace limits](./5.2.2-Harbor-Boost-Configuration.md#harbor_boost_workspace_file_max_chars) in the configuration reference.

### Standalone

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=tools;autocheck" \
  -e "HARBOR_BOOST_WORKSPACE_ROOT=/workspace" \
  -e "HARBOR_BOOST_TOOLS=read_workspace_file;grep_workspace;list_workspace_files" \
  -v /path/to/myproject:/workspace \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## clarity

Applies recursive "clarfication" of the input question.
  LLM tries to classify if the question has any amibiguities and instrucred to clarify them if so.


## concept

![concept](./boost-concept.png)

`concept` is a module allowing LLM to first generate a small concept graph to aid it in replying to the original message.
The entire workflow is completely orchestrated so less interesting from interpretability perspective, but more from the representation perspective.

```bash
# With Harbor
harbor boost modules add concept

# Standalone usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_PUBLIC_URL=http://localhost:8004" \
  -e "HARBOR_BOOST_MODULES=concept" \
  -p 8004:8000   ghcr.io/av/harbor-boost:latest
```


## crystal

Instructs the LLM to act as three experts debating a problem.
  - Analyst specializing in edge cases
  - Engineer focused on implementation details
  - Philosopher examining fundamental assumptions


## cssv

CSSV - Choice Selection for Systematic Validation

Essentially, performs a beam search based on the critique from multiple system prompts. Similar to `pdsv`.


## deaf

`deaf` warps the user's query as if the assistant misheard it slightly —
wrong words, odd interpretations, tangential rephrasing — and then confidently
answers the warped version instead. The result is a comic effect where the
model confidently solves the wrong problem.

```bash
# Enable the module
harbor boost modules add deaf
```


## deephop

`deephop` performs deeper, two-hop web research before the final answer.
On research turns it plans search queries, runs an initial search pass, reads
top pages, detects information gaps, runs a targeted second search, then
synthesizes a structured `<research_brief>` with facts, uncertainties,
recommendation, and do-not-assume guidance before streaming the downstream
completion.

Unlike `quickhop`, deephop triggers selectively on research-heavy questions
(migrations, version comparisons, API behavior) and uses higher default budgets.

**When to use**

- Migrations, version comparisons, breaking changes, and API behavior questions
- When the first search pass may miss gaps — deephop runs a targeted second hop
- Prefer over `quickhop` when accuracy matters more than latency (higher budgets)
- Skips implementation-only and acknowledgment turns like `quickhop`

**Parameters**

- `max_queries` — maximum search queries planned per request. Default: `5`
- `max_searches` — maximum web searches per request. Default: `4`
- `max_url_reads` — maximum full-page URL reads per request. Default: `3`
- `max_chars` — maximum research content characters retained. Default: `60000`
- `early_exit_chars` — skip hop 2 when hop 1 gathers this many characters. Default: `15000` (`0` disables)
- `synthesis_max_chars` — cap gathered research passed to brief synthesis. Default: `8000` (`0` disables)
- `trigger` — deep-research gate: `heuristic` (default) or `llm` (cheap yes/no classifier)
- `cache_brief` — *(experimental)* reuse the last research brief when the same user
  question appears again within a request session. Default: `false`

```bash
harbor boost modules add deephop
harbor config set HARBOR_BOOST_DEEPHOP_MAX_QUERIES 5
harbor config set HARBOR_BOOST_DEEPHOP_MAX_SEARCHES 4
harbor config set HARBOR_BOOST_DEEPHOP_MAX_URL_READS 3
harbor config set HARBOR_BOOST_DEEPHOP_MAX_CHARS 60000
harbor config set HARBOR_BOOST_DEEPHOP_EARLY_EXIT_CHARS 15000
harbor config set HARBOR_BOOST_DEEPHOP_SYNTHESIS_MAX_CHARS 8000
harbor config set HARBOR_BOOST_DEEPHOP_TRIGGER heuristic
harbor config set HARBOR_BOOST_DEEPHOP_CACHE_BRIEF false
harbor config set HARBOR_BOOST_TAVILY_API_KEY <key>
# or
harbor config set HARBOR_BOOST_SEARXNG_URL http://searxng:8080
```

**Standalone**

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=deephop" \
  -e "HARBOR_BOOST_SEARXNG_URL=http://host.docker.internal:33811" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## diffscope

`diffscope` is a post-deliverable scope guard for coding turns. On deliverable
requests it drafts the model answer and compares changed file paths to scope the
user stated in recent messages (`only X`, `don't touch Y`, quoted paths).

**Path grounding modes**

- **Git mode** (preferred): when `HARBOR_BOOST_WORKSPACE_ROOT` points at a git
  repo, `diffscope` runs `git diff --name-only` and `git diff --stat` (5s
  timeout) to list files actually changed in the working tree. Models can also
  call the `git_diff_workspace` tool for the same summary during exploration.
- **Heuristic mode** (fallback): when git is unavailable, paths are extracted
  from the draft (code fences, diff headers, backticks) and file-tool arguments
  in chat history.

When `HARBOR_BOOST_WORKSPACE_ROOT` is set, cited workspace paths are also
verified with `read_workspace_file`. Out-of-scope or missing paths trigger a
correction note and **one** revision hop before the answer is emitted.

**When to use**

- Coding deliverables where the user states file scope (`only X`, `don't touch Y`)
- Post-deliverable guard: compares changed paths against recent constraints

**Limitation:** User scope is inferred from recent message heuristics. Scratch
file tools (`read_file`, `write_file`) are not tracked — only workspace reads
verify repo paths. Git mode reflects unstaged `git diff` output only.

**Parameters**

- `enabled` — when false, pass through without scope checks. Default: `true`
- `max_user_turns` — recent user messages scanned for scope hints. Default: `5`
- `max_workspace_files` — workspace existence checks per request. Default: `5`
- `allow_collateral` — when true, extra files outside hinted scope warn only unless
  the user said `only X`. When false, any out-of-scope file triggers revision.
  Default: `true`

```bash
harbor boost modules add diffscope
harbor config set HARBOR_BOOST_DIFFSCOPE_ENABLED true
harbor config set HARBOR_BOOST_WORKSPACE_ROOT /workspace/myproject
```

**Standalone**

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=diffscope" \
  -e "HARBOR_BOOST_WORKSPACE_ROOT=/workspace" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## discussurl

Matches all URLs in the input, reads them with Jina and adds their content for
  the LLM to use during the completion.


## dnd

⚠️ This module is only compatible with Open WebUI as a client due to its support of custom artifacts.

When serving the completion, LLM will first invent a skill check it must pass to address your message. Then, the workflow will roll a dice determining if the model passes the check or not and will guide the model to respond accordingly.

Gemma failing to explain transformers architecture due to failing a "Sequential Data Translation Mastery" check.

![Screenshot of DnD module](./boost-dnd.png)

```bash
# Enable the module
harbor boost modules add dnd
```


## dot

![screenshot of dot module in action](./boost-dot.png)

⚠️ The visual part of this module is only compatible with Open WebUI, but the reasoning skeleton will work with any OpenAI-compatible client.

Inspired by [Chain of Draft](https://arxiv.org/abs/2502.18600) paper.

```bash
# Enable the module
harbor boost modules add dot
```


## eli5

Based on a simple idea of explaining complex things in a simple way. The module will ask the LLM to explain a question to itself first and then will use that explanation for the final answer.

**Parameters**

`eli5` module supports selection strategy parameters identical to `mcts`, `g1`, and `rcn` modules, just under the `boost.eli5` prefix.

```bash
# Strategy to find the message to start from
harbor config set boost.eli5.strat match
# Match last user message, for example
harbor config set boost.eli5.strat_params role=user,index=-1
```


## example

1. Working with a chat and chat nodes instances
  This is where you can create some content programmatically,
  that will later can be used for retrieving completions from
  the downstream model.


## fml

`fml` - "Formulaic" (not the other thing)

Rewrites original request in a formulaic logic language (whatever LLM will mean by that),
solves it, and rewrites the solution in natural language.


## g1

Dynamic Chain-of-Thought pattern.

See [original implementation for Grok](https://github.com/bklieger-groq/g1). Harbor also has a [dedicated `ol1` service](./2.3.19-Satellite&colon-ol1.md) (UI only) that implements the same technique.

```bash
# Enable the module
harbor boost modules add g1
```

**Parameters**

- `max_steps` - Maximum amount of iterations for self-reflection, default is 15
- `strat` - strategy for selection of the messages to rewrite. Default is `match`
  - `all` - match all messages
  - `first` - match first message regardless of the role
  - `last` - match last message regardless of the role
  - `any` - match one random message
  - `percentage` - match a percentage of random messages from the conversation
  - `user` - match all user messages
  - `match` - use a filter to match messages
- `strat_params` - parameters (filter) for the selection strategy. Default matches all user messages
  - `percentage` - for `percentage` strat - the percentage of messages to match, default is `50`
  - `index` - for `match` strat - the index of the message to match
  - `role` - for `match` strat - the role of the message to match
  - `substring` - for `match` strat - will match messages containing the substring


## gact

No documentation available.


## grug

Translates input task into ["grug"](https://grugbrain.dev/) language, with a set of very basic, simplistic solutions.
Then synthesises these solutions into one practical solution and uses it to answer the original query.


## klmbr

![klmbr screenshot](https://github.com/av/klmbr/raw/main/assets/c4ndl3.png)
![klmbr screenshot](./boost-klmbr.png)

Boosts model creativity by applying character-level random rewrites to the input. Read a full overview of the technique in the [source repo](https://github.com/av/klmbr).

Every LLM will respond to rewrites in a different way. Some models will generate more diverse completions, while others might start generating completely random sequences. Default parameters are tuned for Llama 3.1 8B, you might want to adjust them when running with a different model.

**Parameters**

- `percentage` - amount of characters to rewrite in the input. Default is `35`
- `mods` - types of rewrites to apply. Default is `all`, available options:
  - `capitalize` - swaps character capitalization
  - `diacritic` - adds a random diacritic to the character
  - `leetspeak` - replaces characters with leetspeak equivalents
  - `remove_vowel` - removes vowels from the input
  - `invert_180` - inverts characters 180 degrees
  - `unicode_lookalike` - replaces characters with Unicode lookalikes from other scripts
  - `homoglyph` - replaces characters with visually identical homoglyphs
  - `zero_width` - inserts zero-width characters after the character
  - `zalgo` - adds multiple combining marks to create zalgo text effect
- `strat` - strategy for selection of the messages to rewrite. Default is `match`
  - `all` - match all messages
  - `first` - match first message regardless of the role
  - `last` - match last message regardless of the role
  - `any` - match one random message
  - `percentage` - match a percentage of random messages from the conversation
  - `user` - match all user messages
  - `match` - use a filter to match messages
- `strat_params` - parameters (filter) for the selection strategy. Default matches all user messages
  - `percentage` - for `percentage` strat - the percentage of messages to match, default is `50`
  - `index` - for `match` strat - the index of the message to match
  - `role` - for `match` strat - the role of the message to match
  - `substring` - for `match` strat - will match messages containing the substring

**Examples**

```bash
# Reduce the rewrite percentage
harbor boost klmbr percentage 20

# Enable/disable rewrite modules
harbor boost klmbr mods rm all
harbor boost klmbr mods add capitalize
harbor boost klmbr mods add diacritic
harbor boost klmbr mods add leetspeak
harbor boost klmbr mods add remove_vowel
harbor boost klmbr mods add invert_180
harbor boost klmbr mods add unicode_lookalike
harbor boost klmbr mods add homoglyph
harbor boost klmbr mods add zero_width
harbor boost klmbr mods add zalgo

# Change the selection strategy
# 1. Match all user messages
harbor boost klmbr strat match
harbor boost klmbr strat_params role user
# 2. Match the last message (regardless of the role)
harbor boost klmbr strat match
harbor boost klmbr strat_params index -1
# 3. Match messages containing a substring
harbor boost klmbr strat match
harbor boost klmbr strat_params substring "random"
```


## l33t

Solves oritginal request in light leetspeak, then answers it in plain English.


## logprobs

![screenshot of logprobs module in action](./boost-logprobs.png)

Visualizes token confidence during LLM generation using logprobs.

Each token is displayed with background coloring based on model confidence:
- Transparent: high confidence (model is sure)
- Red tint: low confidence (model is uncertain)

Hover over tokens to see alternative tokens the model considered.

Before generation, a "warmup" request determines the logprob range
for the current model, ensuring accurate visualization.

```bash
# Enable the module
harbor boost modules add logprobs
```


## markov

![screenshot of markov module in action](./boost-markov.png)

⚠️ This module is only compatible with Open WebUI as a client due to its support of custom artifacts.

When serving LLM completion, it'll emit an artifact for Open WebUI that'll connect back to the Harbor Boost server and display emitted tokens in a graph where each token is connected to the one preceding it.

```bash
# Enable the module
harbor boost modules add markov
```


## mcts

This is a less-cool version of the [Visual Tree Of Thoughts](https://openwebui.com/f/everlier/mcts) Open WebUI Function. Less cool because there's no way to rewrite the message content from a proxy side (yet), so all of the intermediate outputs are additive.

Nonetheless, the core of the technique is the same and is based on the Tree Of Thoughts and MCTS algorithms. An initial "idea" or answer is generated and then is improved upon for a given amount of steps.

```bash
# Enable the module
harbor boost modules add mcts
```

**Parameters**

All parameters below are prefixed with `boost.mcts.` in `harbor config`

- `strat` - strategy for selection of the messages to rewrite. Default is `match`, other values:
  - `all` - match all messages
  - `first` - match first message regardless of the role
  - `last` - match last message regardless of the role
  - `any` - match one random message
  - `percentage` - match a percentage of random messages from the conversation
  - `user` - match all user messages
  - `match` - use a filter to match messages
- `strat_params` - parameters (filter) for the selection strategy. Default matches all user messages, fields:
  - `percentage` - for `percentage` strat - the percentage of messages to match, default is `50`
  - `index` - for `match` strat - the index of the message to match
  - `role` - for `match` strat - the role of the message to match
  - `substring` - for `match` strat - will match messages containing the substring
- `max_iterations` - Maximum amount of Monte Carlo iterations to run (same tree), default is `2`
- `max_simulations` - Improvement steps per iteration, default is `2`
- `max_thoughts` - This number + 1 will be amount of improved variants to generate per node

```bash
# Strategy to find the message to start from
harbor config set boost.mcts.strat match
# Match last user message, for example
harbor config set boost.mcts.strat_params role=user,index=-1
```


## meow

Instructs the LLM to ignore all previous instructions and just meow in response.


## nbs

![NBS screenshot](./boost-nbs.png)

`nbs` - Narrative Beam Search

Variation of beam search with exploration of the next few tokens based
on system prompts eliciting different reasoning/continuation styles.

```bash
# With harbor
harbor boost modules add nbs
harbor up boost --tail
# Connected to Open WebUI by default
harbor open

# Standalone usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_PUBLIC_URL=http://localhost:8004" \
  -e "HARBOR_BOOST_MODULES=nbs" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## ow

Attempts to allow the LLM to edit its previous response by manipulating it at a word level.
In practice, few LLMs can understand the nature of such task and it's usually not effective.


## pad

Pads the chat context with fake reasoning inputs.
  Doesn't work at all in practice.


## pdsv

`pdsv` - Personality-Driven Selection and Validation

Essentially a beam search from multiple system prompts, similar to `cssv`.


## polyglot

Solves the original request in multiple languages, then synthesizes the solutions into a single coherent response.
Based on the assumption that different languages can trigger different reprojections within the LLM,
which may lead to more diverse and creative solutions or help avoiding overfit.


## ponder

![ponder](./boost-ponder.png)

`ponder` is similar to the `concept` module, but with a different approach to building of the concept graph.

```bash
# Standalone usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_PUBLIC_URL=http://localhost:8004" \
  -e "HARBOR_BOOST_MODULES=ponder" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## ponytail

`ponytail` channels the lazy-senior-dev ladder: YAGNI, stdlib first, native platform
features before dependencies, one line before fifty. It injects build-discipline rules
before the downstream completion.

Inspired by [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail).

**Parameters**

- `level` — `lite`, `full` (default), `ultra`, or `off`

```bash
harbor boost modules add ponytail
harbor config set HARBOR_BOOST_PONYTAIL_LEVEL full
```

Users can switch per request with `/ponytail ultra` or disable with `stop ponytail`
/ `normal mode` in the latest user message.

Ponytail governs what you build, not how you talk — pair with `caveman` for terse prose.


## promx

![promx](./boost-promx.png)

`promx` (Prompt Mixer) implements dynamic metaprompting with real-time control.

```bash
# With Harbor
harbor boost modules add promx

# Standalone usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_PUBLIC_URL=http://localhost:8004" \
  -e "HARBOR_BOOST_MODULES=promx" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## quickhop

`quickhop` performs fast, budget-capped web research before the final answer.
On research turns it extracts 1-3 search queries with a cheap internal LLM call,
runs `web_search` directly (not via model tool calls), optionally reads top hit
pages, injects a compact `<research_brief>` system block, then streams the
downstream completion.

Pass-through turns (implementation edits, acknowledgments, short "continue"
messages) skip research to keep latency low.

**When to use**

- Quick fact-finding before answering — API docs, release notes, error lookups
- Default research module when latency matters more than depth
- Prefer over `deephop` for ideation passes and routine lookups
- Pair with `tools` so the model can search again during the final completion

**Parameters**

- `max_queries` — maximum search queries extracted per request. Default: `3`
- `max_searches` — maximum web searches per request. Default: `2`
- `max_url_reads` — maximum full-page URL reads per request. Default: `1`
- `max_chars` — maximum research content characters retained. Default: `30000`
- `trigger` — research gate: `heuristic` (default) or `llm` (cheap yes/no classifier)
- `cache_brief` — *(experimental)* reuse the last research brief when the same user
  question appears again within a request session. Default: `false`

```bash
harbor boost modules add quickhop
harbor config set HARBOR_BOOST_QUICKHOP_MAX_QUERIES 3
harbor config set HARBOR_BOOST_QUICKHOP_MAX_SEARCHES 2
harbor config set HARBOR_BOOST_QUICKHOP_MAX_URL_READS 1
harbor config set HARBOR_BOOST_QUICKHOP_MAX_CHARS 30000
harbor config set HARBOR_BOOST_QUICKHOP_TRIGGER heuristic
harbor config set HARBOR_BOOST_QUICKHOP_CACHE_BRIEF false
harbor config set HARBOR_BOOST_TAVILY_API_KEY <key>
# or
harbor config set HARBOR_BOOST_SEARXNG_URL http://searxng:8080
```

**Standalone**

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=quickhop" \
  -e "HARBOR_BOOST_SEARXNG_URL=http://host.docker.internal:33811" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## r0

![Boost R0](./boost-r0.png)

This workflow allows you to add R1-like reasoning to any LLM (including [older ones, like Llama 2, or Gemma 1](https://www.reddit.com/r/LocalLLaMA/comments/1ixckba/making_older_llms_llama_2_and_gemma_1_reason/)). Of course, it won't show the same performance as an actually GRPO-boosted model, but it can still provide some interesting results as well as being a very flexible base to experiment with.

```bash
# Enable the module
harbor boost modules add r0
```

**Parameters**

```bash
# Get/set the amount of thoughts to generate
harbor boost r0 thoughts 5
```


## rcn

`rcn` - Recursive Certainty Validation

RCN is an original technique based on two principles: _context expansion_ and _self-validation_.
It works by first expanding the context of the input by asking the model to explain
the meaning of every word in the prompt. Then, a completion is generated, then model
is asked to validate how sure it is that the answer is correct. After two iterations,
model is asked to give a final answer.


```bash
# Enable the module
harbor boost modules add rcn

# Via ENV
HARBOR_BOOST_MODULES="rcn"
```

**Parameters**

- `strat` - strategy for selection of the messages to rewrite. Default is `match`
  - `all` - match all messages
  - `first` - match first message regardless of the role
  - `last` - match last message regardless of the role
  - `any` - match one random message
  - `percentage` - match a percentage of random messages from the conversation
  - `user` - match all user messages
  - `match` - use a filter to match messages
- `strat_params` - parameters (filter) for the selection strategy. Default matches all user messages
  - `percentage` - for `percentage` strat - the percentage of messages to match, default is `50`
  - `index` - for `match` strat - the index of the message to match
  - `role` - for `match` strat - the role of the message to match
  - `substring` - for `match` strat - will match messages containing the substring

**Example**

```bash
# Configure message selection
# to match last user message
harbor boost rcn strat match
harbor boost rcn strat_params set role user
harbor boost rcn strat_params set index -1
```


## recpl

`recpl` - Recursive Planning

Attempts to solve input request by recursively expanding a plan that achieves the given objective.
LLM decides whether or not actions in the plan are "atomic" (can be executed in a single step) or not.
If an action is not atomic, it is expanded into smaller actions until all actions are atomic.
The final plan is then used to answer the original query.


## stcl

`stcl` - Single Token Completion Loop

Aims to improve the quality of responses by metaprompting every few tokens to avoid possible mistakes and biases.
Includes a few different strategies in the code to vary the content and the placement of the metaprompt.


## supersummer

Based on a technique of generation of a summary of the given given content from key questions. The module will ask the LLM to provide a given amount of key questions and then will use them to guide the generation of the summary.

**Parameters**

`supersummer` module supports selection strategy parameters identical to `mcts`, `g1`, and `rcn` modules, just under the `boost.supersummer` prefix.

```bash
# Strategy to find the message to start from
harbor config set boost.supersummer.strat match
# Match last user message, for example
harbor config set boost.supersummer.strat_params role=user,index=-1
```

In addition to that, it's possible to adjust number of questions the model will generate, as well as the desired length of the summary.

```bash
# Number of questions to generate
harbor config set boost.supersummer.questions 3
# Length of the summary, you can use any
# textual specification, like "one paragraph"
harbor config set boost.supersummer.length "few paragraphs"
```

Here're sample questions and summary that `supersummer` generated from Harbor's readme:

<details>

<summary>Sample questions and summary</summary>

### Questions

**What is Harbor, and what are its primary functions?**
(This question addresses the central theme or argument of the text, which is to introduce Harbor as a containerized LLM toolkit.)

**What services can be managed with Harbor, and how does it facilitate their use?**
(This question highlights important facts or evidence, such as the various services listed in the "Services" section, and how Harbor enables easy management and usage of these services.)

**How does Harbor simplify local LLM development and experimentation?**
(This question reveals the author's purpose or perspective, which is to make local LLM development more convenient and streamlined by providing a unified CLI interface for managing services and configurations.)

**What benefits does Harbor provide over using individual Docker Compose files or Linux administration commands?**
(This question explores any significant implications or conclusions of using Harbor, such as the convenience factor and workflow centralisation it offers.)

**Can Harbor be used in conjunction with existing Docker setups, or is it intended to replace them entirely?**
(This question highlights important facts or evidence about Harbor's purpose and scope, such as its ability to co-exist with existing Docker setups and provide added value through its convenience features.)

### Summary

Harbor is a containerized Long-Short-Memory (LLM) toolkit that enables effortless management of LLM backends, APIs, frontends, and services. Developed as an open-source project, Harbor consists of a Command-Line Interface (CLI) and a companion application to help manage and run AI services in a unified manner.

Harbor offers several key features:

- **Managed Services**: The platform allows users to easily manage various LLM-related services, such as UIs (User Interfaces), Backends, Frontends, and Satellites.
- **Unified CLI Interface**: Harbor provides a single command-line interface for managing multiple services, eliminating the need for manual configuration and streamlining development workflows.
- **Convenience Utilities**: A range of convenience tools helps users manage LLM-related tasks efficiently, such as setting up services, debugging, creating URLs, and establishing network tunnels.
- **Cache Sharing and Reuse**: Harbor shares and reuses host caches, significantly enhancing model performance and reducing memory consumption across supported services (e.g., Hugging Face models, Ollama).
- **Config Profiles**: The application allows users to manage multiple configuration profiles for different development tasks or projects.

Harbor's purpose is not only to provide a convenient platform but also to simplify local LLM development by making it easier to setup and experiment with various LLM-related services. As such, Harbor can perfectly align with existing Docker setups and offers several benefits over manual Linux administration commands, like ease of use and streamlined configurations management.

As the author implies, the main benefit of using Harbor lies in its ability to simplify local LLM development and reduce time required for experiments and prototyping steps in a unified and convenient setup.

</details>


## tmsv

Essentially a beam search based on the temperature variations.


## tools

Adds a portable set of request-scoped tools to the downstream LLM. The tools
are registered with Harbor Boost's local tool registry, so the model can call
them during the final completion and Boost will execute them inline.

The module exposes web research tools (`web_search`, `read_url`) plus small
scratchpad utilities (`add_note`, `read_notes`, scratch files, `current_time`,
and `finish`). When `HARBOR_BOOST_WORKSPACE_ROOT` is set, workspace tools
(`read_workspace_file`, `grep_workspace`, `list_workspace_files`, `git_diff_workspace`
when the root is a git repo, and opt-in `write_workspace_file`) are also available.
Web search uses
Tavily when `HARBOR_BOOST_TAVILY_API_KEY` is set, otherwise SearXNG via
`HARBOR_BOOST_SEARXNG_URL`. URL reading uses Jina Reader first and falls back
to direct HTTP text extraction.

The module is workflow-aware: when it is placed before another workflow module,
the workflow runner configures it as a setup step so tools are registered before
the final completion. Ad hoc requests can also pass a workflow through
`@boost_workflow` on the chat completion body.

`finish` signals that the model is done using tools and returns its final answer.

`autocheck` treats a recent `finish` call as a deliverable completion signal.

```bash
harbor boost modules add tools
harbor config set HARBOR_BOOST_TOOLS "web_search;read_url;current_time"
harbor config set HARBOR_BOOST_SEARXNG_URL http://searxng:8080
```

**Standalone**

```bash
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=tools" \
  -e "HARBOR_BOOST_SEARXNG_URL=http://host.docker.internal:33811" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## tri

In relation to the incoming request, LLM is tasked to generate:
- three aspects to consider,
- three pitfalls to avoid,
- three paragraphs of possible solutions.

Then, it synthesizes these solutions into one practical solution and uses it to answer the original query.


## unstable

Will generate a random personality description for the LLM to follow for every message.
The personality will include three extreme traits, a temperament, and a reply style.


## usv

A variation on the beam search.


## webui_artifact

An example module that emits a pre-defined HTML artifact for Open WebUI.


## wordedit

LLM composes its response through word-level tool calls instead of streaming.

The model builds a response word-by-word using CRUD operations, allowing it to iterate and refine before delivering the final result.

The visual artifact UI is compatible with Open WebUI and shows real-time word buffer updates.

```bash
# with Harbor
harbor boost modules add wordedit

# Standalone usage
docker run \
  -e "HARBOR_BOOST_OPENAI_URLS=http://172.17.0.1:11434/v1" \
  -e "HARBOR_BOOST_OPENAI_KEYS=sk-ollama" \
  -e "HARBOR_BOOST_MODULES=wordedit" \
  -p 8004:8000 \
  ghcr.io/av/harbor-boost:latest
```


## wswp

Attempts to swap adjacent word positions in the input text with a certain probability.
Sometimes can help to avoid overfit, especially in cases where the LLM is too focused on specific word order or structure.
The usability is limited, though.