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.

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

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

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

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

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

Parameters

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

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:

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 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:

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):

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

Or skip SearXNG and use Tavily:

harbor config set HARBOR_BOOST_TAVILY_API_KEY <key>

harbor launch automation

harbor launch 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.

# 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 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 and diffscope cannot verify cited file paths against your repo.

In Harbor Compose, set HARBOR_BOOST_WORKSPACE to the host path (or harbor config set boost.workspace "$(pwd)"). Harbor mounts it at /workspace by default. Set 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

# 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 with --sandbox workspace-write wires workspace write tools.

Workspace tools

When HARBOR_BOOST_WORKSPACE_ROOT is set, the 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 in the configuration reference.

Standalone

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

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

# 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

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

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

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

Standalone

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.

# Enable the module
harbor boost modules add dnd

dot

⚠️ 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 paper.

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

# 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. Harbor also has a dedicated ol1 service (UI only) that implements the same technique.

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

Boosts model creativity by applying character-level random rewrites to the input. Read a full overview of the technique in the source repo.

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

# 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

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.

# Enable the module
harbor boost modules add logprobs

markov

⚠️ 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.

# Enable the module
harbor boost modules add markov

mcts

This is a less-cool version of the Visual Tree Of Thoughts 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.

# 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

# 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 - Narrative Beam Search

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

# 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 is similar to the concept module, but with a different approach to building of the concept graph.

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

Parameters

• level — lite, full (default), ultra, or off

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 (Prompt Mixer) implements dynamic metaprompting with real-time control.

# 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

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

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

This workflow allows you to add R1-like reasoning to any LLM (including older ones, like Llama 2, or Gemma 1). 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.

# Enable the module
harbor boost modules add r0

Parameters

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

# 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

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

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

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

Sample questions and 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.

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.

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

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.

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