How to use Local Quench
The defaults are chosen per model: the app reads the model's name and size and picks the harness, the tools and the edit format for it. This page says what each choice does and when to change it. Every setting named here is in Settings, Agent, unless it says otherwise.
First task in a project
- Load the model in LM Studio (or start llama-server, Ollama or vLLM) with a context of at least 32k tokens; 64k is comfortable for a medium repository. Local Quench shows the context the server really loaded on the top bar.
- Open the project folder and type
/init. The agent writes the project memory (QUENCH.md): how to build and test, the layout, the rules from CLAUDE.md, AGENTS.md or Cursor rules if the project has them. Small models follow short rules better than long ones, so it keeps them short. - Set the check command for the project (Settings, Agent, Verify after changes), for example
pytest -qornpm test. The agent runs it when it says it is done, and a failing check sends it back to work. - Ask for one change at a time. A small model does well with a task that touches one to three files; give a bigger feature as a plan of such steps, one message each.
Permission modes
The button in the message box (Shift+Tab cycles through them). It decides what the agent may do without asking; edits are always revertable, commands are not.
| Mode | What it does | Use it when |
|---|---|---|
| Plan | Read-only: the agent investigates and writes a plan; no edits, only read-only commands. The Execute plan button switches back and carries it out. | A task bigger than a few files, a repository the model has not seen, or a new model you want to watch before trusting it. |
| Ask | Edits apply right away (revertable in Diffs); asks before every shell command and delete. | Day-to-day work. The default. |
| Auto (safe) | Read-only commands (ls, git status, grep, cat) run without asking; everything else asks. | You trust the model and want fewer prompts while it explores. |
| Skip permissions | Never asks. Commands and deletes run at once. | Only in a project under version control: benchmarks, night tasks, a separate copy of the repository. |
| Autopilot | Never asks, and the model decides itself whether to plan first. | Strong models on bigger tasks, in a separate copy or a repository you can reset. |
Harness: Small models, Auto, Strong models
The harness is the set of rules around the model: a nudge when it announces a step and stops, hints after errors, a reminder when it keeps testing its own check, a look at its diff before it finishes, old tool outputs dropped near the context limit, and a cap on how long it may think. These help a 9B or 30B model and cost a frontier model tokens and interruptions.
- Auto picks by the model: a local model under about 100B parameters gets the small-model harness; a frontier-size model, a cloud model such as Claude, GPT or Gemini, or a name marked mini, nano or lite is handled accordingly. The Model tab shows which one was chosen and why.
- Small models forces the guard rails on, for example for a 70B model that still stalls after errors.
- Strong models turns them off, for a local model that you know reads errors and plans its own checks.
Each rule also has its own switch below the harness choice, and QuenchBench can measure what a switch is worth for your model (Benchmarks, ablation).
Tool set: Auto, All, Light, Core
Every tool the model may call costs tokens in every request, because its description is in the prompt. A small model also picks the wrong tool more often when there are many.
- Core: read, edit, create and delete files, list and search, run commands and tests, check a background process, the task list. Eleven tools. Chosen by Auto when the context is under 24k tokens.
- Light: Core plus the file outline, git, web search and page fetch. Chosen by Auto for the small-model harness.
- All: everything, including the browser, sub-agents, waiting on a process and the symbol tools from a language server. Chosen by Auto for strong models.
MCP servers and skills appear in every set, but only once you configured some, so a small model does not see an empty list.
Edit format
How the model writes a change. Auto picks by size: whole files for models of 12B and under (a 4B model writes a whole file more reliably than a patch), the old-text/new-text tool for 12B to 32B models and for coder models trained on it, edit blocks for larger ones, and OpenAI's apply_patch for GPT and gpt-oss. Change it when a model keeps producing edits that do not apply: the Diffs panel shows every failed one.
Thinking
The Thinking button in the message box turns the model's reasoning on and off and sets a token budget (also /think on, /think off, /budget 4096). Reasoning helps on bugs with a cause to find and hurts on simple edits, where the model reasons for minutes and then times out. The harness caps the budget by the context and by the model's speed, so a slow model is not left thinking for most of the task. For LM Studio, set the same budget in its model settings: the app asks the server for it on every request, but only llama-server enforces it.
More than one chat, more than one attempt
- Work in a separate copy (the folder menu on the top bar): the chat gets its own git worktree on a new branch, so several chats can change the same repository at once, and a failed attempt is discarded without touching your folder. Merge it back when done.
- Sub-agents: on the All tool set the agent can send parallel explorers through a large repository; each one appears as a row in the chat and opens as its own conversation.
- Best of N (Settings, Agent, Experimental): N attempts at the same task, judged by your check command. For a task with a clear test and a GPU you can leave running.
- Night tasks (Settings, Night tasks): QuenchBench, the harness tuner, fixing tests or updating dependencies on a branch while you sleep, with a report in the morning.
A bigger task with a small model
A model of 30B parameters on a repository of tens of thousands of lines will not deliver a whole feature from one message. It will, step by step, if each step is checkable. Start in Plan mode and ask for the plan of a feature; cut it into steps of one to three files each, with a test at the end of every step; then give the steps one by one in Ask mode, in a separate copy of the repository, and run the check command after each. Export the chat afterwards (the download icon next to the chat): where the harness had to intervene, the export shows it.