A small model reads.
Your big model thinks.

How it works

1. The main model calls a tool, say read big_file.py. The tool runs as usual.
2. If the tool is mapped to a helper model and its output is longer than min_chars (default 3,000), hexiel sends the output and your request to the helper with an instruction to keep exact identifiers, paths, line numbers and errors.
3. The main model receives the summary, labelled with who wrote it and how big the original was. It can call the tool again with full: true to get the raw text.
4. The same output for the same request is only summarised once; repeats come from a cache.
5. If the helper doesn’t answer within timeout or errors, the next model in your list is tried (a helper that just failed is skipped for two minutes); after the last one, or if the output is bigger than max_input, you get the raw output. Nothing is ever lost or hidden.

Set it up

Add a profile for the small model, then map tools to it in config.toml (see the config reference).

[models.pi]
provider = "openai"
base_url = "http://192.168.4.2:11434/v1"
model = "qwen3-1.7b-pi"
context_window = 4096
max_output_tokens = 600
extra_body = { reasoning_effort = "none" }   # no thinking: it would triple the wait

[tool_models]
read      = { models = ["pi"], min_chars = 3000, max_input = 6500, timeout = 100, max_tokens = 220 }
grep      = { models = ["pi"], min_chars = 3000, max_input = 6500, timeout = 100, max_tokens = 220 }
web_fetch = "pi"
search    = ["minipc"]            # alias for web_search; a list tries models in order, preferring one that isn't busy

A value can be a profile name, a list, or a table with limits for that tool: min_chars (smaller outputs aren’t touched), max_input (bigger ones aren’t sent), timeout (seconds to wait), max_tokens (how long the digest may be — shorter is much faster on a slow helper).

Check it

• /toolmodels lists each tool’s models, whether they’re ready or busy, and the limits.
• /toolmodels test sends a one-word request to each and times it.
• /usage adds how many outputs were condensed and roughly how many tokens that kept out of the main model’s context.

Example: a Raspberry Pi 5 as the helper

We put this on the Pi that already runs our home DNS, and measured it. Numbers below are from a Pi 5 with 8 GB, three cores, no GPU, reading a ~1,400-token chunk of real hexiel code and asked to answer four questions about it (did the summary keep the facts that answer the question?).

Keep the Pi healthy

• Pin Ollama to some cores (CPUAffinity=1 2 3) and leave one free. Don’t use CPUQuota: the model’s threads spin-wait, and a quota made it about 2.5× slower.
• One request at a time, one model loaded, unloaded after ten idle minutes, a memory cap, and OOMScoreAdjust so the OOM killer picks Ollama before anything important.
• Bind it to the LAN address only and allow just your own network in the firewall. Use num_thread 3 and a 4k context for the model.
• Pi 5s throttle when hot; a fan or heatsink matters. Keep the model files off a nearly-full SD card.

“Another window is using this model”

A local model serves one request at a time, so with several hexiel windows or background runs sharing it, requests queue silently and hexiel looks hung. Now hexiel tells you:

⏳ minipc is busy with 1 other request from another hexiel window or background run — this one may wait its turn

It works across processes and applies to models served from your machine or network (including Tailscale addresses). Cloud models, including Ollama Cloud models, serve everyone at once and aren’t tracked.

Questions